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

Hi Xiaohu, please see inline (“...FB“) From: nvo3 On Behalf Of ???(??) Sent: Freitag, 13. April 2018 09:42 To: Int-area ; Frank Brockners (fbrockne) Cc: NVO3 ; int-area ; Service Function

Re: [nvo3] [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

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

Tom, the term "overhead" here refers to the number of extra bytes used in the parent protocol to carry IOAM data. IOAM data itself is of course not counted for the comparison, because it would need to be carried in both cases. Using your Geneve reference as an example, in order to carry IOAM

Re: [nvo3] [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

Re: [nvo3] [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

Re: [nvo3] [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

Re: [nvo3] [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,

Re: [nvo3] [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

Re: [nvo3] [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: [nvo3] [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