New version of draft-brockners-inband-oam-data

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New version of draft-brockners-inband-oam-data

Frank Brockners (fbrockne)

Dear IPPM WG,

 

we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.

 

We appreciate your thoughts and comments.

 

Regards, Frank

 


_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: New version of draft-brockners-inband-oam-data

Ruediger.Geib

Hi Frank,

 

the text relevant to keeping IOAM data within the IOAM domain is fine with me. I quote it below:

 

      “Designers of

   carrier protocols for IOAM must specify mechanisms to ensure that in-

   situ OAM data stays within an IOAM domain.  In addition, the operator

   of such a domain is expected to put provisions in place to ensure

   that IOAM data does not leak beyond the edge of an IOAM domain, e.g.

   using for example packet filtering methods.”

 

Regards,

 

Ruediger

 

Von: ippm [mailto:[hidden email]] Im Auftrag von Frank Brockners (fbrockne)
Gesendet: Montag, 29. Mai 2017 17:26
An: [hidden email]
Betreff: [ippm] New version of draft-brockners-inband-oam-data

 

Dear IPPM WG,

 

we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.

 

We appreciate your thoughts and comments.

 

Regards, Frank

 


_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Adoption call for draft-brockners-inband-oam-data

Brian Trammell (IETF)
In reply to this post by Frank Brockners (fbrockne)
Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Nagendra Kumar Nainar (naikumar)
Hi,
 
(1) whether you support addition of the following milestone to the IPPM charter:

Yes/Support
       
(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone
Yes/Support.
   
    (3) whether you commit to reviewing the document if adopted
    Yes.
   
Thanks,
Nagendra    
   
    > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
    >
    > Dear IPPM WG,
    >
    > we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
    >
    > We appreciate your thoughts and comments.
    >
    > Regards, Frank
    >
    > _______________________________________________
    > ippm mailing list
    > [hidden email]
    > https://www.ietf.org/mailman/listinfo/ippm
   
    _______________________________________________
    ippm mailing list
    [hidden email]
    https://www.ietf.org/mailman/listinfo/ippm
   

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Sarah Banks-3
In reply to this post by Brian Trammell (IETF)
Hello,
        Although I do have reservations about this draft, I do think it deserves the chance to be worked on by the group and come to the penultimate consensus (or not) to move it forward to publication. That said, I do not believe the current charter allows this draft to come in; the charter is pretty clear that network OAM is out of scope, and so a charter change has to happen. If we recharter, are we planning to do so to accommodate this one draft, or future OAM work as well?
        Given Brian's Q's below:
        1. I support the addition of the milestone. I can't decide on another place to take this work; IPPM seems most apropos.
        2. I support the adoption of draft-brockners-etc as the basis document for the milestone
        3. I think there are minutes somewhere that signed me up for this reviewing already :)


Thanks
Sarah

> On May 30, 2017, at 1:17 AM, Brian Trammell (IETF) <[hidden email]> wrote:
>
> Greetings, IPPM,
>
> At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.
>
> This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the IPPM charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG
>
> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone
>
> (3) whether you commit to reviewing the document if adopted
>
>
> We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.
>
> Many thanks, best regards,
>
> Brian (as IPPM co-chair)
>
>
>
>> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>>
>> Dear IPPM WG,
>>
>> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>>
>> We appreciate your thoughts and comments.
>>
>> Regards, Frank
>>
>> _______________________________________________
>> ippm mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Carlos Pignataro (cpignata)
In reply to this post by Brian Trammell (IETF)
Hi, Brian,

Thank you for driving this poll.

I clearly support this work and believe it will be IETF-cycles very well invested to advance and publish this work.

To that end, a couple of comments:

(1) I support the addition of a milestone to IPPM, to hat this work from. That may require a one-liner “recharter”, but let’s not bloat the process-ware.

However, a couple of comments:

Let’s change “inband OAM based” for “in-situ” or “hybrid model something”, or anything that does not causes potential confusion.

We could generalize “ measurement methodologies” as “ methodologies including performance measurement”.

I know the draft is now labeled as Experimental, but frankly this is no “research project”, and there’s no experiment per-se. Consequently, I’d support standards track.

(2) Definitely. draft-brockners-inband-oam-data continues to incorporate community feedback and review and is a solid starting point for said milestone.

Thanks,

— Carlos.


> On May 30, 2017, at 4:17 AM, Brian Trammell (IETF) <[hidden email]> wrote:
>
> Greetings, IPPM,
>
> At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.
>
> This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the IPPM charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG
>
> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone
>
> (3) whether you commit to reviewing the document if adopted
>
>
> We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.
>
> Many thanks, best regards,
>
> Brian (as IPPM co-chair)
>
>
>
>> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>>
>> Dear IPPM WG,
>>
>> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>>
>> We appreciate your thoughts and comments.
>>
>> Regards, Frank
>>
>> _______________________________________________
>> ippm mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Vengada Prasad Govindan (venggovi)
In reply to this post by Brian Trammell (IETF)
Hello Brian/ all,
   As an implementer of the inband-oam-data draft (fd.io), I support the WG adoption of this document. I suggest that this be considered for Standards track instead of the experimental track since we have working code of IOAM across three different transport protocols (IPv6, VxLAN-GPE and NSH).
Thanks
Prasad

-----Original Message-----
From: ippm [mailto:[hidden email]] On Behalf Of Brian Trammell (IETF)
Sent: Tuesday, May 30, 2017 1:48 PM
To: [hidden email]
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data

Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Srihari Raghavan (srihari)
All,

   Having read the draft, I support the WG adoption of this document.  I
can review the document as needed, upon adoption.

Thanks
Srihari



>-----Original Message-----
>From: ippm [mailto:[hidden email]] On Behalf Of Brian Trammell
>(IETF)
>Sent: Tuesday, May 30, 2017 1:48 PM
>To: [hidden email]
>Subject: [ippm] Adoption call for draft-brockners-inband-oam-data
>
>Greetings, IPPM,
>
>At our Chicago meeting, we decided we needed a single, cleaned-up
>document containing appropriate scoping and rationale in order to make a
>decision as to whether we'd like to adopt IOAM within IPPM. This revision
>of draft-brockners-inband-oam-data is that document.
>
>This message, therefore, starts a call for adoption on
>draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday
>20 June 2017. Please reply to [hidden email] indicating:
>
>(1) whether you support addition of the following milestone to the IPPM
>charter:
>
>date TBD: Submit an Experimental draft on inband OAM based measurement
>methodologies to the IESG
>
>(2) whether you support the adoption of
>draft-brockners-inband-oam-data-05 as the basis document for this
>milestone
>
>(3) whether you commit to reviewing the document if adopted
>
>
>We are aware that there is an open question as to whether we can adopt
>draft-brockners-inband-oam-data under our current charter; we'd like to
>see if there is IPPM WG consensus on adoption before discussing a
>recharter, hopefully before Prague, though we can take face-to-face time
>in Prague for this if necessary. Our intention, as chairs, is to make the
>minimal necessary change to the charter should there be consensus for
>adoption. However, if you have particular opinions as to how this should
>be done, please also address these in your message.
>
>Many thanks, best regards,
>
>Brian (as IPPM co-chair)
>
>
>
>> On 29 May 2017, at 17:26, Frank Brockners (fbrockne)
>><[hidden email]> wrote:
>>
>> Dear IPPM WG,
>>
>> we¹ve just posted an updated version of
>>draft-brockners-inband-oam-data:
>>https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is
>>to address the recent comments on the mailing list. The main change is
>>the verbiage around the need to ensure that IOAM data is kept within the
>>IOAM domain. In addition, several editorial nits have been cleaned up.
>>
>> We appreciate your thoughts and comments.
>>
>> Regards, Frank
>>
>> _______________________________________________
>> ippm mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/ippm
>
>_______________________________________________
>ippm mailing list
>[hidden email]
>https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Tal Mizrahi-2
In reply to this post by Brian Trammell (IETF)
As a coauthor, I support the adoption of this draft, I support adding it to the charter, and I am committed to take part in editing the document based on the working group feedback.

Cheers,
Tal.

On Tue, May 30, 2017 at 11:17 AM, Brian Trammell (IETF) <[hidden email]> wrote:
Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm


_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm



_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Tianran Zhou
In reply to this post by Brian Trammell (IETF)
Hi All,

I have read all the draft-brockners-inband-oam-** series. I support the adoption.
I would like to review the documents if adopted.

Cheers,
Tianran

> -----Original Message-----
> From: ippm [mailto:[hidden email]] On Behalf Of Brian Trammell (IETF)
> Sent: Tuesday, May 30, 2017 4:18 PM
> To: [hidden email]
> Subject: [ippm] Adoption call for draft-brockners-inband-oam-data
>
> Greetings, IPPM,
>
> At our Chicago meeting, we decided we needed a single, cleaned-up document
> containing appropriate scoping and rationale in order to make a decision
> as to whether we'd like to adopt IOAM within IPPM. This revision of
> draft-brockners-inband-oam-data is that document.
>
> This message, therefore, starts a call for adoption on
> draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday
> 20 June 2017. Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the IPPM
> charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement
> methodologies to the IESG
>
> (2) whether you support the adoption of draft-brockners-inband-oam-data-05
> as the basis document for this milestone
>
> (3) whether you commit to reviewing the document if adopted
>
>
> We are aware that there is an open question as to whether we can adopt
> draft-brockners-inband-oam-data under our current charter; we'd like to
> see if there is IPPM WG consensus on adoption before discussing a recharter,
> hopefully before Prague, though we can take face-to-face time in Prague
> for this if necessary. Our intention, as chairs, is to make the minimal
> necessary change to the charter should there be consensus for adoption.
> However, if you have particular opinions as to how this should be done,
> please also address these in your message.
>
> Many thanks, best regards,
>
> Brian (as IPPM co-chair)
>
>
>
> > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]>
> wrote:
> >
> > Dear IPPM WG,
> >
> > we’ve just posted an updated version of draft-brockners-inband-oam-data:
> https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is
> to address the recent comments on the mailing list. The main change is the
> verbiage around the need to ensure that IOAM data is kept within the IOAM
> domain. In addition, several editorial nits have been cleaned up.
> >
> > We appreciate your thoughts and comments.
> >
> > Regards, Frank
> >
> > _______________________________________________
> > ippm mailing list
> > [hidden email]
> > https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

nalini.elkins
In reply to this post by Brian Trammell (IETF)
All,

>1) whether you support addition of the following milestone to the IPPM charter:

> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

I support addition of this milestone.    


> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

Yes.  But, I have some comments as to the various data fields most of which I will save for the actual discussion of the draft.   For example, we may be able to
compress the number of fields.   I also need to think a bit more about time synchronization issues as well as the granularity of the timestamps.


> (3) whether you commit to reviewing the document if adopted

Yes.   I commit to reviewing the document.  I have provided some comments to the authors in early versions of the document.   I found the other documents in this series helpful in
understanding the data layout so it may be good to have pointers to them, possibly as white papers.
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360



________________________________
From: Brian Trammell (IETF) <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Tuesday, May 30, 2017 1:17 AM
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data



Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)




> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Ackermann, Michael

 
  +1
  On  all three questions.
   
 
 My additional comments   are:
  There are a few architectural and
  technical details to  be worked out, but this
 draft  proposes constructs and  metrics that would be
 very  valuable to network and  enterprise operators.  I
 would  look  forward to reviewing and assisting in any way
 I can  to  achieve such advancements in network
 management.  I  also foresee the information  &
 metrics to be delivered  by inband OAM,  as a great
 partner and supplement to what  PDM  purveys.  As an
 enterprise  operator,  I need PDM ASAP for the high level
 triage and  fault domain isolation it provides.    Later,
 (at least in  my chronological sequence of preferential
 events),  I would  like to then use Inband OAM, if the PDM
 triage results deem  those metrics to be necessary fault
 domain details I might  need to solve a problem or improve
 performance quickly.
Look forward to working together in this  regard as  well.

Thanks,
Mike
 
 

-----Original Message-----
From: ippm [mailto:[hidden email]] On Behalf Of Nalini J Elkins
Sent: Thursday, June 8, 2017 10:44 PM
To: Brian Trammell (IETF) <[hidden email]>; [hidden email]
Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

All,

>1) whether you support addition of the following milestone to the IPPM charter:

> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

I support addition of this milestone.    


> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

Yes.  But, I have some comments as to the various data fields most of which I will save for the actual discussion of the draft.   For example, we may be able to
compress the number of fields.   I also need to think a bit more about time synchronization issues as well as the granularity of the timestamps.


> (3) whether you commit to reviewing the document if adopted

Yes.   I commit to reviewing the document.  I have provided some comments to the authors in early versions of the document.   I found the other documents in this series helpful in
understanding the data layout so it may be good to have pointers to them, possibly as white papers.
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360



________________________________
From: Brian Trammell (IETF) <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Tuesday, May 30, 2017 1:17 AM
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data



Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)




> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Greg Mirsky-2
In reply to this post by Brian Trammell (IETF)
Hi Brian,
thank you for listing all the questions so clearly. To me answer depends upon where the required update of the IPPM WG charter takes us. In the current version of the draft I see very little of performance measurement support and no new performance metrics or significant benefits when comparing to existing measurement methods to justify change to the charter. Most of the functionality supported by current version of the draft, as it appears, is to serve not performance measurement but network operation (tracing flow, collecting buffer utilization statistics, etc.) One of the use cases, proof of transit, is, in my view, in the same category. Thus, I don't see much of relevance between draft-brockners-inband-oam-data-05 and performance measurement, performance metrics whether in IP network or overlay network that uses IP as transport. What the update of the WG charter could be? To me it it the first priority question with all others following it.
Couple comments on the draft:
  • I suggest updating the boilerplate and section Conventions to reference RFC 8174 and use the following:
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

Resulting, do not use capitals but only lower case as this is Experimental document. And because this is Experimental document, remove IANA Consideration section.

In conclusion, I'd prefer to discuss the change to the WG charter before updating Milestones and considering adoption of the draft-brockners-inband-oam-data-05. As of now, I don't support either as I don't see any relevance of the draft-brockners-inband-oam-data-05 to the WG charter.

Regards,
Greg

On Tue, May 30, 2017 at 1:17 AM, Brian Trammell (IETF) <[hidden email]> wrote:
Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm


_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm



_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Adoption call for draft-brockners-inband-oam-data

Singh, Gurpreet-2
In reply to this post by Brian Trammell (IETF)

(1) whether you support addition of the following milestone to the IPPM charter:

 

Yes, I support setting the milestone. Date may be decided through consensus and feasibility.

 

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

Yes, I support

 

(3) whether you commit to reviewing the document if adopted

Yes, I will review the document

 

Regards

Gurpreet Singh

 





Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Remy Chang
In reply to this post by Brian Trammell (IETF)
Hi Brian,
Thanks for helping on this.  I do believe this is a worthy effort and agree to the 3 questions.

Regards,
Remy



-----Original Message-----
From: ippm [mailto:[hidden email]] On Behalf Of Brian Trammell (IETF)
Sent: Dienstag, 30. Mai 2017 10:18
To: [hidden email]
Subject: [ippm] Adoption call for draft-brockners-inband-oam-data

Greetings, IPPM,

At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.

This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:

(1) whether you support addition of the following milestone to the IPPM charter:

date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

(3) whether you commit to reviewing the document if adopted


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.

Many thanks, best regards,

Brian (as IPPM co-chair)



> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>
> Dear IPPM WG,
>
> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>
> We appreciate your thoughts and comments.
>
> Regards, Frank
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm



_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Mickey Spiegel
In reply to this post by Brian Trammell (IETF)
Greetings, IPPM,
At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.
This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:
(1) whether you support addition of the following milestone to the IPPM charter:
date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG

I support adding this milestone to the IPPM charter.
 
(2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone

I support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone.
 
(3) whether you commit to reviewing the document if adopted

I commit to reviewing this document, and plan to help with edits to the document and technical details.

Mickey Spiegel


We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.
Many thanks, best regards,
Brian (as IPPM co-chair)


_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

MORTON, ALFRED C (AL)
In reply to this post by Brian Trammell (IETF)
Hi Brian and IPPMers,

> -----Original Message-----
> From: ippm [mailto:[hidden email]] On Behalf Of Brian Trammell
> (IETF)
...

>
> This message, therefore, starts a call for adoption on draft-brockners-
> inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017.
> Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the IPPM
> charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement
> methodologies to the IESG
[ACM]
Given that most have concluded that in-situ OAM is categorized as
Hybrid Type I (according to RFC 7799), the I would say that this
statement in the charter is *pretty close*:

   Additional methods will be defined for the composition and calibration of
   IPPM-defined metrics, as well as active, passive and hybrid measurement
   methods for these metrics.

and I agree we can either adopt the draft now, or with a small tweak to
the charter text. The measurement methods mostly concern the data fields,
and do not define complete protocol solutions that will be subjected
to more complete review.

Question: In the proposed milestone text, was "inband" used to have
generality before "in-situ" is considered and adopted?
I suggest s/inband/in-situ/ if the milestone and the
draft are adopted together, to have clear limits.

>
> (2) whether you support the adoption of draft-brockners-inband-oam-data-
> 05 as the basis document for this milestone
[ACM]
Yes, I support this draft in particular.

>
> (3) whether you commit to reviewing the document if adopted
>
[ACM]
Yes, I attach a review of the first three sections, below.

regards,
Al

Internet-Draft           In-situ OAM Data Fields                May 2017


1.  Introduction

   This document defines data fields for "in-situ" Operations,
   Administration, and Maintenance (OAM).  In-situ OAM records OAM
   information within the packet while the packet traverses a particular
   network domain.  The term "in-situ" refers to the fact that the OAM
   data is added to the data packets rather than is being sent within
   packets specifically dedicated to OAM.  A discussion of the
   motivation and requirements for in-situ OAM can be found in
   [I-D.brockners-inband-oam-requirements].  In-situ OAM is to
   complement mechanisms such as Ping or Traceroute, or more recent
   active probing mechanisms as described in
[ACM]  Not clear to me why we need two different definitions of "type".
RFC7799 considers OAM measurements in its categorization.
It would be good to include the specific phrases of the definitions
that place in-situ OAM in the Hybrid Type 1 Category, some of which
were exchanged in recent e-mail discussion of this draft.

   [I-D.lapukhov-dataplane-probe].  In terms of "active" or "passive"
   OAM, "in-situ" OAM can be considered a hybrid OAM type.  While no
   extra packets are sent, in-situ OAM adds information to the packets
   therefore cannot be considered passive.  In terms of the
   classification given in [RFC7799] in-situ OAM could be portrayed as
   "hybrid OAM, type 1".
[ACM] s/hybrid OAM, type 1/Hybrid Type 1/
I suggest to resist the urge to use double-quotes when indicating terms
that have formal definitions elsewhere. The definitions are primarily for
active/passive/hybrid *methods* of measurement (and for *metrics*, although
I'm not sure we need to define metrics yet.)
   "In-situ" mechanisms do not require extra
   packets to be sent and hence don't change the packet traffic mix
   within the network.  In-situ OAM mechanisms can be leveraged where
   mechanisms using e.g.  ICMP do not apply or do not offer the desired
   results, such as proving that a certain traffic flow takes a pre-
   defined path, SLA verification for the live data traffic, detailed
   statistics on traffic distribution paths in networks that distribute
   traffic across multiple paths, or scenarios in which probe traffic is
   potentially handled differently from regular data traffic by the
   network devices.

2.  Conventions

[ACM] no comments this section

3.  Scope, Applicability, and Assumptions

   In-situ OAM deployment assumes a set of constraints, requirements,
   and guiding principles which are described in this section.

   Scope: This document defines the data fields and associated data
   types for in-situ OAM.  The in-situ OAM data field can be transported
   by a variety of transport protocols, including NSH, Segment Routing,
[ACM] s/transport/network/
? In IETF, transport protocols are UDP and TCP (and QUIC)

   Geneve, IPv6, or IPv4.  Encapsulation details for these different
   transport protocols are outside the scope of this document.
[ACM] s/Encapsulation/Specification/
Clearly, some of the protocols mentioned above perform encapsulation
of other protocol headers. This memo describes the additional fields
to insert when forming a new header, or optional fields to insert in
an *existing* header (e.g., IPv4 and IPv6). I think the Scope
should clearly indicate that these two possibilities are included.

   Deployment domain (or scope) of in-situ OAM deployment: IOAM is a
   network domain focused feature, with "network domain" being a set of
   network devices or entities within a single administration.  For
   example, a network domain can include an enterprise campus using
   physical connections between devices or an overlay network using
   virtual connections / tunnels for connectivity between said devices.
   A network domain is defined by its perimeter or edge.  Designers of
   carrier protocols for IOAM must specify mechanisms to ensure that in-
[ACM] s/must/MUST/  
   situ OAM data stays within an IOAM domain.  In addition, the operator
   of such a domain is expected to put provisions in place to ensure
   that IOAM data does not leak beyond the edge of an IOAM domain, e.g.
   using for example packet filtering methods.  The operator should
   consider potential operational impact of IOAM to mechanisms such as
   ECMP processing (e.g. load-balancing schemes based on packet length
   could be impacted by the increased packet size due to IOAM), path MTU
   (i.e. ensure that the MTU of all links within a domain is
   sufficiently large to support the increased packet size due to IOAM)
   and ICMP message handling (i.e. in case of a native IPv6 transport,
   IOAM support for ICMPv6 Echo Request/Reply could desired which would
   translate into ICMPv6 extensions to enable IOAM data fields to be
   copied from an Echo Request message to an Echo Reply message).

[ACM] Comments on the control point definition below...
   In-situ OAM control points: IOAM data fields are added to or removed
   from the live user traffic by the devices which form the edge of a
   domain.  Devices within an IOAM domain can update and/or add IOAM
   data-fields.  Domain edge devices can be hosts or network devices.

   Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on
   all or only on subsets of the live user traffic.  It SHOULD be
   possible to enable in-situ OAM on a selected set of traffic (e.g.,
   per interface, based on an access control list or flow specification
   defining a specific set of traffic, etc.)  The selected set of
   traffic can also be all traffic.

   Encapsulation independence: Data formats for in-situ OAM SHOULD be
   defined in a transport-independent manner.  In-situ OAM applies to a
   variety of encapsulating protocols.  A definition of how IOAM data
   fields are carried by different transport protocols is outside the
   scope of this document.

   Layering: If several encapsulation protocols (e.g., in case of
   tunneling) are stacked on top of each other, in-situ OAM data-records
   could be present at every layer.  The behavior follows the ships-in-
   the-night model.

   Combination with active OAM mechanisms: In-situ OAM should be usable
   for active network probing, enabling for example a customized version
   of traceroute.  Decapsulating in-situ OAM nodes may have an ability
   to send the in-situ OAM information retrieved from the packet back to
   the source address of the packet or to the encapsulating node.
[ACM] I'd like to see a slightly more complete naming scheme for
the nodes participating in IOAM methods. You already define
*IOAM control points* above which seem to be the originators and terminators
of the inserted IOAM fields. These nodes are sometimes encapsulating and
decapsulating nodes, but not always (I think, see comment on IPv4+v6).
There are also nodes which participate in the IOAM methods located
internal to the administrative/IOAM domain. I suggest that:
"Devices within an IOAM domain can update and/or add IOAM data-fields."
could have a different name that distinguishes their role.
For a given path, these devices are simply members of the IOAM domain
and perform a subset of the IOAM functions.
Although the role of these devices could change with a different path,
there could also be devices (or functions) that are always intended to
be internal to the IOAM domain, and need only a subset of
IOAM capabilities.
I'll let the authors name these "members-only" nodes, but I think
this role is useful to distinguish. My guess is that there will be
a linkage between these roles and the three main types of in-situ data
defined elsewhere.

   In-situ OAM implementation: The IOAM data-field definitions take the
   specifics of devices with hardware data-plane and software data-plane
   into account.

-=-=-=-=-=-=-=-=-=-=-

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Frank Brockners (fbrockne)
In reply to this post by Carlos Pignataro (cpignata)
Hi Carlos,

on your note: " I know the draft is now labeled as Experimental, but frankly this is no “research project”, and there’s no experiment per-se. Consequently, I’d support standards track.".

IMHO it does make sense to move to standards tacks, because we already have a few implementations, including the open source implementation in FD.io. And just recently, Broadcom and Netronome published a video featuring their IOAM implementation: https://www.youtube.com/watch?v=j9FbD4a3F4E 

Regards, Frank

-----Original Message-----
From: ippm [mailto:[hidden email]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Dienstag, 6. Juni 2017 04:03
To: Brian Trammell (IETF) <[hidden email]>
Cc: [hidden email]
Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

Hi, Brian,

Thank you for driving this poll.

I clearly support this work and believe it will be IETF-cycles very well invested to advance and publish this work.

To that end, a couple of comments:

(1) I support the addition of a milestone to IPPM, to hat this work from. That may require a one-liner “recharter”, but let’s not bloat the process-ware.

However, a couple of comments:

Let’s change “inband OAM based” for “in-situ” or “hybrid model something”, or anything that does not causes potential confusion.

We could generalize “ measurement methodologies” as “ methodologies including performance measurement”.

I know the draft is now labeled as Experimental, but frankly this is no “research project”, and there’s no experiment per-se. Consequently, I’d support standards track.

(2) Definitely. draft-brockners-inband-oam-data continues to incorporate community feedback and review and is a solid starting point for said milestone.

Thanks,

— Carlos.


> On May 30, 2017, at 4:17 AM, Brian Trammell (IETF) <[hidden email]> wrote:
>
> Greetings, IPPM,
>
> At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.
>
> This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the IPPM charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG
>
> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone
>
> (3) whether you commit to reviewing the document if adopted
>
>
> We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.
>
> Many thanks, best regards,
>
> Brian (as IPPM co-chair)
>
>
>
>> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>>
>> Dear IPPM WG,
>>
>> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>>
>> We appreciate your thoughts and comments.
>>
>> Regards, Frank
>>
>> _______________________________________________
>> ippm mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Brian Trammell (IETF)
In reply to this post by Brian Trammell (IETF)
Greetings, all,

This call for adoption is concluded.

It appears from the discussion that there is broad but not unanimous support for adoption of this document, but some concerns about how exactly the charter would need to be modified to bring this work into IPPM. In any case, there appears to be more than enough support to investigate a rechartering. The chairs will work with the authors and the working group to suggest a charter revision for discussion at our face-to-face meeting in Prague.

Cheers,

Brian



> On 30 May 2017, at 10:17, Brian Trammell (IETF) <[hidden email]> wrote:
>
> Greetings, IPPM,
>
> At our Chicago meeting, we decided we needed a single, cleaned-up document containing appropriate scoping and rationale in order to make a decision as to whether we'd like to adopt IOAM within IPPM. This revision of draft-brockners-inband-oam-data is that document.
>
> This message, therefore, starts a call for adoption on draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the IPPM charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement methodologies to the IESG
>
> (2) whether you support the adoption of draft-brockners-inband-oam-data-05 as the basis document for this milestone
>
> (3) whether you commit to reviewing the document if adopted
>
>
> We are aware that there is an open question as to whether we can adopt draft-brockners-inband-oam-data under our current charter; we'd like to see if there is IPPM WG consensus on adoption before discussing a recharter, hopefully before Prague, though we can take face-to-face time in Prague for this if necessary. Our intention, as chairs, is to make the minimal necessary change to the charter should there be consensus for adoption. However, if you have particular opinions as to how this should be done, please also address these in your message.
>
> Many thanks, best regards,
>
> Brian (as IPPM co-chair)
>
>
>
>> On 29 May 2017, at 17:26, Frank Brockners (fbrockne) <[hidden email]> wrote:
>>
>> Dear IPPM WG,
>>
>> we’ve just posted an updated version of draft-brockners-inband-oam-data: https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to address the recent comments on the mailing list. The main change is the verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editorial nits have been cleaned up.
>>
>> We appreciate your thoughts and comments.
>>
>> Regards, Frank
>>
>> _______________________________________________
>> ippm mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adoption call for draft-brockners-inband-oam-data

Frank Brockners (fbrockne)
In reply to this post by MORTON, ALFRED C (AL)
Hi Al,

thanks a lot for your comments. While integrating your comments into the doc, a question on the roles of IOAM nodes arose. So far we have

* IOAM encapsulating nodes (nodes which add IOAM container(s) )
* IOAM decapsulating nodes (nodes which removed IOAM container(s) )
* IOAM transit nodes (nodes which update/add IOAM data fields )

You suggest to add another role for "Devices within an IOAM domain can update and/or add IOAM data-fields.". What isn't entirely clear to me is how those devices would differ from IOAM transit nodes. Could you detail your thinking a bit more?

Thanks, Frank

-----Original Message-----
From: ippm [mailto:[hidden email]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Sonntag, 18. Juni 2017 15:17
To: Brian Trammell (IETF) <[hidden email]>; [hidden email]
Subject: Re: [ippm] Adoption call for draft-brockners-inband-oam-data

Hi Brian and IPPMers,

> -----Original Message-----
> From: ippm [mailto:[hidden email]] On Behalf Of Brian Trammell
> (IETF)
...

>
> This message, therefore, starts a call for adoption on
> draft-brockners- inband-oam-data, to run until EOB CEST (UTC +2) Tuesday 20 June 2017.
> Please reply to [hidden email] indicating:
>
> (1) whether you support addition of the following milestone to the
> IPPM
> charter:
>
> date TBD: Submit an Experimental draft on inband OAM based measurement
> methodologies to the IESG
[ACM]
Given that most have concluded that in-situ OAM is categorized as Hybrid Type I (according to RFC 7799), the I would say that this statement in the charter is *pretty close*:

   Additional methods will be defined for the composition and calibration of
   IPPM-defined metrics, as well as active, passive and hybrid measurement
   methods for these metrics.

and I agree we can either adopt the draft now, or with a small tweak to the charter text. The measurement methods mostly concern the data fields, and do not define complete protocol solutions that will be subjected to more complete review.

Question: In the proposed milestone text, was "inband" used to have generality before "in-situ" is considered and adopted?
I suggest s/inband/in-situ/ if the milestone and the draft are adopted together, to have clear limits.

>
> (2) whether you support the adoption of
> draft-brockners-inband-oam-data-
> 05 as the basis document for this milestone
[ACM]
Yes, I support this draft in particular.

>
> (3) whether you commit to reviewing the document if adopted
>
[ACM]
Yes, I attach a review of the first three sections, below.

regards,
Al

Internet-Draft           In-situ OAM Data Fields                May 2017


1.  Introduction

   This document defines data fields for "in-situ" Operations,
   Administration, and Maintenance (OAM).  In-situ OAM records OAM
   information within the packet while the packet traverses a particular
   network domain.  The term "in-situ" refers to the fact that the OAM
   data is added to the data packets rather than is being sent within
   packets specifically dedicated to OAM.  A discussion of the
   motivation and requirements for in-situ OAM can be found in
   [I-D.brockners-inband-oam-requirements].  In-situ OAM is to
   complement mechanisms such as Ping or Traceroute, or more recent
   active probing mechanisms as described in [ACM]  Not clear to me why we need two different definitions of "type".
RFC7799 considers OAM measurements in its categorization.
It would be good to include the specific phrases of the definitions that place in-situ OAM in the Hybrid Type 1 Category, some of which were exchanged in recent e-mail discussion of this draft.

   [I-D.lapukhov-dataplane-probe].  In terms of "active" or "passive"
   OAM, "in-situ" OAM can be considered a hybrid OAM type.  While no
   extra packets are sent, in-situ OAM adds information to the packets
   therefore cannot be considered passive.  In terms of the
   classification given in [RFC7799] in-situ OAM could be portrayed as
   "hybrid OAM, type 1".
[ACM] s/hybrid OAM, type 1/Hybrid Type 1/ I suggest to resist the urge to use double-quotes when indicating terms that have formal definitions elsewhere. The definitions are primarily for active/passive/hybrid *methods* of measurement (and for *metrics*, although I'm not sure we need to define metrics yet.)
   "In-situ" mechanisms do not require extra
   packets to be sent and hence don't change the packet traffic mix
   within the network.  In-situ OAM mechanisms can be leveraged where
   mechanisms using e.g.  ICMP do not apply or do not offer the desired
   results, such as proving that a certain traffic flow takes a pre-
   defined path, SLA verification for the live data traffic, detailed
   statistics on traffic distribution paths in networks that distribute
   traffic across multiple paths, or scenarios in which probe traffic is
   potentially handled differently from regular data traffic by the
   network devices.

2.  Conventions

[ACM] no comments this section

3.  Scope, Applicability, and Assumptions

   In-situ OAM deployment assumes a set of constraints, requirements,
   and guiding principles which are described in this section.

   Scope: This document defines the data fields and associated data
   types for in-situ OAM.  The in-situ OAM data field can be transported
   by a variety of transport protocols, including NSH, Segment Routing, [ACM] s/transport/network/ ? In IETF, transport protocols are UDP and TCP (and QUIC)

   Geneve, IPv6, or IPv4.  Encapsulation details for these different
   transport protocols are outside the scope of this document.
[ACM] s/Encapsulation/Specification/
Clearly, some of the protocols mentioned above perform encapsulation of other protocol headers. This memo describes the additional fields to insert when forming a new header, or optional fields to insert in an *existing* header (e.g., IPv4 and IPv6). I think the Scope should clearly indicate that these two possibilities are included.

   Deployment domain (or scope) of in-situ OAM deployment: IOAM is a
   network domain focused feature, with "network domain" being a set of
   network devices or entities within a single administration.  For
   example, a network domain can include an enterprise campus using
   physical connections between devices or an overlay network using
   virtual connections / tunnels for connectivity between said devices.
   A network domain is defined by its perimeter or edge.  Designers of
   carrier protocols for IOAM must specify mechanisms to ensure that in- [ACM] s/must/MUST/  
   situ OAM data stays within an IOAM domain.  In addition, the operator
   of such a domain is expected to put provisions in place to ensure
   that IOAM data does not leak beyond the edge of an IOAM domain, e.g.
   using for example packet filtering methods.  The operator should
   consider potential operational impact of IOAM to mechanisms such as
   ECMP processing (e.g. load-balancing schemes based on packet length
   could be impacted by the increased packet size due to IOAM), path MTU
   (i.e. ensure that the MTU of all links within a domain is
   sufficiently large to support the increased packet size due to IOAM)
   and ICMP message handling (i.e. in case of a native IPv6 transport,
   IOAM support for ICMPv6 Echo Request/Reply could desired which would
   translate into ICMPv6 extensions to enable IOAM data fields to be
   copied from an Echo Request message to an Echo Reply message).

[ACM] Comments on the control point definition below...
   In-situ OAM control points: IOAM data fields are added to or removed
   from the live user traffic by the devices which form the edge of a
   domain.  Devices within an IOAM domain can update and/or add IOAM
   data-fields.  Domain edge devices can be hosts or network devices.

   Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on
   all or only on subsets of the live user traffic.  It SHOULD be
   possible to enable in-situ OAM on a selected set of traffic (e.g.,
   per interface, based on an access control list or flow specification
   defining a specific set of traffic, etc.)  The selected set of
   traffic can also be all traffic.

   Encapsulation independence: Data formats for in-situ OAM SHOULD be
   defined in a transport-independent manner.  In-situ OAM applies to a
   variety of encapsulating protocols.  A definition of how IOAM data
   fields are carried by different transport protocols is outside the
   scope of this document.

   Layering: If several encapsulation protocols (e.g., in case of
   tunneling) are stacked on top of each other, in-situ OAM data-records
   could be present at every layer.  The behavior follows the ships-in-
   the-night model.

   Combination with active OAM mechanisms: In-situ OAM should be usable
   for active network probing, enabling for example a customized version
   of traceroute.  Decapsulating in-situ OAM nodes may have an ability
   to send the in-situ OAM information retrieved from the packet back to
   the source address of the packet or to the encapsulating node.
[ACM] I'd like to see a slightly more complete naming scheme for the nodes participating in IOAM methods. You already define *IOAM control points* above which seem to be the originators and terminators of the inserted IOAM fields. These nodes are sometimes encapsulating and decapsulating nodes, but not always (I think, see comment on IPv4+v6).
There are also nodes which participate in the IOAM methods located internal to the administrative/IOAM domain. I suggest that:
"Devices within an IOAM domain can update and/or add IOAM data-fields."
could have a different name that distinguishes their role.
For a given path, these devices are simply members of the IOAM domain and perform a subset of the IOAM functions.
Although the role of these devices could change with a different path, there could also be devices (or functions) that are always intended to be internal to the IOAM domain, and need only a subset of IOAM capabilities.
I'll let the authors name these "members-only" nodes, but I think this role is useful to distinguish. My guess is that there will be a linkage between these roles and the three main types of in-situ data defined elsewhere.

   In-situ OAM implementation: The IOAM data-field definitions take the
   specifics of devices with hardware data-plane and software data-plane
   into account.

-=-=-=-=-=-=-=-=-=-=-

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/ippm
12