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 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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 
discussion and hence I've added them to the list. Hope we'll have more opinions 
to reach the conclusion that is acceptable to all.


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

Comment: engineering is usually about making trade-offs. Having Reserved 
fields, unnecessary (and over-generalized) Flags, and a Version field for this 
extra OOAM header does not seem to justify the ROI in adding an extra header 
and extra parsing. This goes back to ‘what problem?'. Having a lot of extra 
fields to parse adds overhead, not only in size, but also in complexity tax. 
Please see Fundamental Truths (6a), (10), and (12) [RFC 1925].
* 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.

Question: The “like” in the first sentence, basically implies “not all 
encapsulations”. Therefore, https://xkcd.com/927/.

Further, what are “protocols that support overlay networks”, and how are you 
choosing your examples?

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 

Question: I do not think this is quite clear as you state, given the fact that 
the word “like” adds imprecision and ambiguity. IP-in-IP? L2TPv3? Etc?

Thank you for considering these questions!
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


— Carlos Pignataro

nvo3 mailing list

Reply via email to