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

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Xiaohu,

please see inline (“...FB“)

From: nvo3 <[e-mail]> On Behalf Of ???(??)
Sent: Freitag, 13. April 2018 09:42
To: Int-area <[e-mail]>; Frank Brockners (fbrockne) <[e-mail]>
Cc: NVO3 <[e-mail]>; int-area <[e-mail]>; Service Function Chaining IETF list <[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: 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<https://tools.ietf.org/html/draft-brockners-ippm-ioam-vxlan-gpe-00#ref-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 regular data payload / customer

   traffic must not set the O bit.  Packets that carry only IOAM data

   fields without any payload must set the O bit."



My first question is: if the Next Protocol field within the VXLAN-GPE header should be resorted to indicate the IOAM, why do we still need the "O" bit?



...FB: What this paragraph states is that IOAM is orthogonal to the O-bit in traffic and will not impact the use of the O-bit. I.e. if the O-bit is set on traffic (because it is OAM traffic), then you’ll continue to have it set with IOAM data added to the packet. If the O-bit isn’t set on the original packet, then it also won’t be set with IOAM data added to the packet.



It said in draft-brockners-ippm-ioam-vxlan-gpe-00:



"Next Protocol:  8-bit unsigned integer that determines the type of

      header following IOAM protocol.  The value is from the IANA

            registry setup for VXLAN GPE Next Protocol defined in

      [I-D.ietf-nvo3-vxlan-gpe<https://tools.ietf.org/html/draft-brockners-ippm-ioam-vxlan-gpe-00#ref-I-D.ietf-nvo3-vxlan-gpe>]."



My second question is: why the "Next Protocol" is designed to be context-specific (i.e., specific to the tunnel over which the IOAM data fields are contained). In other words, wouldn't it be better to make the Next Protocol tunnel-independant since the IOAM is intended to be added into various tunnel encapsulations?



...FB: In those cases where IOAM data encapsulation uses the “next protocol” approach, the encapsulation will borrow next-protocol code points from the “parent” protocol. It is the parent protocol that determines how these code points are structured and defined – and in some cases they are 16-bit (like with GRE, where “next protocol” is an Ethertype value) or 8-bit, like for example for “NSH next protocol”



My third question is: does it means intermediate nodes must be aware of various tunnel encapsulations since the IOAM data field is behind the tunnel header? wouldn't it be better to carry the IOAM data just behind the outer IP header?



...FB: This is really a deployment question. E.g. if you run VXLAN-GPE over IPv6, you could choose to encapsulate IOAM data natively into IPv6, or you could choose to encapsulate IOAM data into VXLAN-GPE, or even both.



Cheers, Frank





Best regards,

Xiaohu


On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>> wrote:
Back at the IPPM meeting in London, we discussed several drafts dealing with the encapsulation of IOAM data in various protocols (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00, draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take to the list was the question on whether draft-ooamdt-rtgwg-ooam-header could be leveraged.  After carefully considering draft-ooamdt-rtgwg-ooam-header, I came to the conclusion that the “OOAM header” does not meet the needs of IOAM:
* Efficiency: IOAM adds data to live user traffic. As such, an encapsulation needs to be as efficient as possible. The “OOAM header” is 8 bytes long. The approach for IOAM data encapsulation in the above mentioned drafts only requires 4 bytes. Using the OOAM header approach would add an unnecessary overhead of 4 bytes – which is significant.
GIM>> The difference in four octets is because OOAM Header:

  *   provides more flexibility, e.g. Flags field and Reserved fields;
  *   supports larger OAM packets than iOAM header;
  *   is future proof by supporting versioning (Version field).
* Maturity: IOAM has several implementations, which were also shown at recent IETF hackathons – and we’re expecting additional implementations to be publicized soon. Interoperable implementations need timely specifications. Despite the question being asked, the recent thread on OOAM in the NVO3 list hasn’t revealed any implementation of the OOAM header. In addition, the thread revealed that several fundamental questions about the OOAM header are still open, such as whether or how active OAM mechanisms within protocols such as Geneve would apply to the OOAM header. This ultimately means that we won’t get to a timely specification.
GIM>> May I ask which encapsulations supported by the implementations you refer to. Until very recently all iOAM proposals were to use meta-data TLV in, e.g. Geneve and NSH. And if these or some of these implementations already updated to the newly proposed iOAM shim, I don't see problem in making them use OOAM Header. Would you agree?

* Scope: It isn’t entirely clear to which protocols the OOAM header would ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit field for “Next Prot”, the next protocol. Some protocols that IOAM data needs to be encapsulated into use 16-bits for their next protocol code points. See e.g. the GRE encapsulation – as specified in draft-weis-ippm-ioam-gre-00.
GIM>> The first paragraph of the Introduction section states:
   New protocols that support overlay networks like VxLAN-GPE
   [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve
   [I-D.ietf-nvo3-geneve], BIER [I-D.ietf-bier-mpls-encapsulation], and
   NSH [I-D.ietf-sfc-nsh] support multi-protocol payload, e.g.
   Ethernet, IPv4/IPv6, and recognize Operations, Administration, and
   Maintenance (OAM) as one of distinct types.  That ensures that
   Overlay OAM (OOAM)packets are sharing fate with Overlay data packet
   traversing the underlay.
I'm updating the OOAM Header draft and along with cleaning nits will update reference to GUE. I think that the list and the statemnt are quite clear in identifying the scope of networks that may benefit from using not only common OOAM Header but common OOAM mechanisms, e.g. Echo Request/Reply<https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-03>.

With the above in mind, I’d suggest that the WG moves forward with specific definitions for encapsulating IOAM data into protocols – per the above mentioned drafts.

Regards, Frank

_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm