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 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? 
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
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 

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?
Best regards,Xiaohu
On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) 
<fbroc...@cisco.com> 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, 
 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 
 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.
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

Int-area mailing list

Reply via email to