Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Greg, it depends on the individual encapsulation, i.e. the parent protocol used. IOAM data encapsulation depends on what the parent protocol offers as encapsulation mechanism. As such, you’d depend on the procedures used by the parent protocol. Let’s consider two examples Geneve and NSH: For

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Greg, I never stated "that mere fact of existing implementation should cancel discussion of technical characteristics of the proposed approaches to hybrid OAM". I just noted implementation status as AN important thing to consider. I also noted that "I've seen several good arguments for why the

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank, thank you for your expedient response. Yes, clarification and consistent terminology, of course as different encapsulations allow that, will help. What I'm looking through the iOAM encapsulation drafts is the answer to this question How a system that is not using iOAM can get to the data

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Greg, good catch – there is a bit of loose language in some of the drafts. We’ll make things crisper in the next rev. Note that there is no generic “IOAM header” but that definition is always within the context of a particular encapsulation protocol. draft-weis-ippm-ioam-gre-00 already has a

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi John, I don't argue with the importance of interoperable implementations (though early implementations accept the risk of non-compliance with the final specification, for example, SFC NSH). At the same time, I don't think that mere fact of existing implementation should cancel discussion of tech

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank, et. al, we have a very good discussion, thank you. I have a question and appreciate your consideration: - encapsulation documents refer to IOAM HDR, its length is reflected in the field labeled either Length or IOAM HDR len. But I cannot find the definition of IOAM HDR. What is

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

I never saw a response to the request for a pointer to an OOAM implementation, so I assume none exist. I've seen several good arguments for why the existing IOAM implementation, for which several implementations exist, meets the needs for IOAM. I think it is time to put to bed the request to exam

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Mon, Apr 16, 2018 at 6:31 AM, Tianran Zhou wrote: > Hi Shwetha, > > You are talking about the outer encapsution. It is straight forward for the > underlay to record by the header. But what about the overlay, i.e., inner > encapsulation(e.g. geneve)? Without special configuration, intermediate n

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Shwetha, You are talking about the outer encapsution. It is straight forward for the underlay to record by the header. But what about the overlay, i.e., inner encapsulation(e.g. geneve)? Without special configuration, intermediate node will not read the inner header, hence not be able to pro

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Tianran, IOAM is a domain specific feature (see also draft-ietf-ippm-ioam-data-02 sections 3 and 4), which allows an operator to control by means of configuration where and for which traffic IOAM data fields are added/updated/removed from the customer traffic. Using your example of Geneve o

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Tianran, > If I recall right, it is not written in the ioam data draft. Data draft is defining the data to be carried in IOAM in an encapsulation agnostic way, it does not specify how the encapsulation protocol is configured. > Yes, node by node configuration is an easy way. While it is,

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank, How does a forwarder know when and where to insert the data? In the case of Geneve over IPv6, do you mean the device need to scan all the protocol stack? Or just the outer encapsulation? Tianran From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Frank Brockners (fbrockne) Sent: M

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank, If I recall right, it is not written in the ioam data draft. Yes, node by node configuration is an easy way. In the draft-zhou-ippm-ioam-yang, we have the “protocol-type” to indicate the layering. +--rw ioam +--rw ioam-profiles +--rw enabled?boolean +-

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Tom, a quick addition to what Mickey mentioned below: What you seem to have in mind is what draft-ietf-ippm-ioam-data-02 refers to as “layering” (see section 3.), i.e. if you’re running for example Geneve over IPv6, then IOAM data could be encapsulated in both protocols, Geneve and IPv6 – givi

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Fri, Apr 13, 2018 at 11:22 AM, Mickey Spiegel wrote: > Tom, > > On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert wrote: >> >> Mickey, >> >> Looking at these ippm drafts more closely, I have a much more >> fundamental concern. >> >> In draft-brockners-ippm-ioam-geneve-00 for instance, there is the

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Tom, On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert wrote: > Mickey, > > Looking at these ippm drafts more closely, I have a much more > fundamental concern. > > In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text > in the introduction: > > "In-situ OAM (IOAM) records OAM infor

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi, It said in draft-brockners-ippm-ioam-vxlan-gpe-00: " [I-D.ietf-nvo3-vxlan-gpe] defines an "O bit" for OAM packets. Per [I-D.ietf-nvo3-vxlan-gpe] the O bit indicates that the packet contains an OAM message instead of data payload. Packets that carry IOAM data fields in addition to r

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

TH. Frank -Original Message- From: Tom Herbert Sent: Donnerstag, 12. April 2018 23:53 To: Greg Mirsky Cc: Frank Brockners (fbrockne) ; NVO3 ; int-area@ietf.org; Service Function Chaining IETF list ; IETF IPPM WG Subject: Re: [Int-area] [ippm] encapsulation of IOAM data in various

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Mickey, Looking at these ippm drafts more closely, I have a much more fundamental concern. In draft-brockners-ippm-ioam-geneve-00 for instance, there is the text in the introduction: "In-situ OAM (IOAM) records OAM information within the packet while the packet traverses a particular network dom

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel wrote: > Tom, > > On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert wrote: >> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky >> wrote: >> > Hi Frank, >> > thank you for sharing your points. Please find my notes in-line and >> > tagged >> > GIM>>. I bel

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi, Greg, Thanks for the quick response — Frank provided answers to your points, but I do have one question about your response (and I will squeeze in a couple of additional comments). Please see inline. On Apr 12, 2018, at 12:54 PM, Greg Mirsky mailto:gregimir...@gmail.com>> wrote: Hi Frank

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Tom, On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert wrote: > On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky > wrote: > > Hi Frank, > > thank you for sharing your points. Please find my notes in-line and > tagged > > GIM>>. I believe that this is very much relevant to work of other working > > group

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Tom, I'll let Frank answer your question as it is on iOAM, not OOAM. Regards, Greg On Thu, Apr 12, 2018 at 11:53 PM, Tom Herbert wrote: > On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky > wrote: > > Hi Tom, > > could you please mention which drafts, iOAM or OOAM, you refer to. Please > > note,

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky wrote: > Hi Tom, > could you please mention which drafts, iOAM or OOAM, you refer to. Please > note, that OOAM supports both active and hybrid OAM methods, while iOAM only > the latter. Section 3 of draft-brockners-ippm-ioam-geneve-00 for instance. >

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Tom, could you please mention which drafts, iOAM or OOAM, you refer to. Please note, that OOAM supports both active and hybrid OAM methods, while iOAM only the latter. Regards, Greg On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert wrote: > On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky > wrote:

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky wrote: > Hi Frank, > thank you for sharing your points. Please find my notes in-line and tagged > GIM>>. I believe that this is very much relevant to work of other working > groups that directly work on the overlay encapsulations in the center of the >

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank, I think you've misunderstood my response to your statements: - the scope of OOAM, contrary to what you've stated, is clearly stated in the draft; - what you present as "efficiency" I consider to be serious limitations (lack of versioning, limited size for data, and no future

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Tom, I think you refer to the proposal on how to apply RFC 8321 in IPv6 networks. Using two bits-long field for Alternate Marking is just one option as you can find in the draft on compact Alt.marking

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky wrote: > Hi Frank, > thank you for sharing your points. Please find my notes in-line and tagged > GIM>>. I believe that this is very much relevant to work of other working > groups that directly work on the overlay encapsulations in the center of the >

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Greg, thanks – and it seems that we’re on the same page with regards to efficiency (4 bytes of non-required overhead) and maturity (or lack of) of OOAM. On the IOAM implementation: There are several implementations of IOAM. Some of which have recently been worked on and shown at an IETF hack

Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank, thank you for sharing your points. Please find my notes in-line and tagged GIM>>. I believe that this is very much relevant to work of other working groups that directly work on the overlay encapsulations in the center of the discussion and hence I've added them to the list. Hope we'll ha