Hi, Greg, Thanks for the clarification and apologies for the omission — my main point was that, if it is not all, it is not “for use in Overlay Networks”.
The title could be “OAM Header for use in Geneve, SFC NSH, and BIER, and maybe GUE and VxLAN-GPE”. Would that be inclusive? Reminded me of https://xkcd.com/927/ Thanks, — Carlos Pignataro On May 14, 2018, at 6:56 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Hi Carlos, you've missed a couple other protocols where OOAM Header may be used - GUE and VxLAN-GPE as mentioned in the Introduction. Regards, Greg On Mon, May 14, 2018 at 3:51 PM, Carlos Pignataro (cpignata) <[email protected]<mailto:[email protected]>> wrote: Dear Greg, One follow-up request, based on one of your comments: GIM>> GRE is not in scope of this proposal. As noted in the Introduction, OOAM Header aimed at Geneve, SFC NSH and BIER. It may be used in VXLAN-GPE and GUE: Do you think the draft “OAM Header for use in Overlay Networks” should be renamed to something like “OAM Header for use in a rather small and very limited number of Overlay Networks” or “OAM Header for use in Geneve, SFC NSH, and BIER”? (It is not clear what Geneve, NSH, and BIER have in common that scopes them in and scopes others out, but…) Otherwise, it is deceiving. Thanks, Carlos. From: nvo3 <[email protected]<mailto:[email protected]>> on behalf of Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Monday, May 14, 2018 at 5:24 PM To: NVO3 <[email protected]<mailto:[email protected]>> Subject: [nvo3] Follow-up the discussion of OOAM Header at NVO3 meeting in London Dear All, following the presentation of the OOAM Header we had very good discussion in London. Many thanks to all who have asked so many good questions. Below please find my answers, follow-up notes in-lined in the minutes from the meeting under GIM>> tag: Frank Brockners: Would help the document if you added the applicability section that said how that particular header would be slotted in with Geneve, GRE, and the likes. What you have now work well for protocols that have a pointer of next header of 8 bits. That would not work for 16 bit protocol pointers. GIM>> GRE is not in scope of this proposal. As noted in the Introduction, OOAM Header aimed at Geneve, SFC NSH and BIER. It may be used in VXLAN-GPE and GUE: 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 [RFC8296], and NSH [RFC8300] 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. GIM>> Regarding use of 16 bits long field for Protocol Type in Geneve. I think that this is valid question that NVO3 WG should discuss not only for OOAM Header but for the Geneve proposal. Benefits of using EtherType rather than new protocol registry like, for example in VxLAN-GPE, are not obvious to me. Showing how that fits in a general way would give more appeal for people to care about it. Greg: Are you suggesting that different encapsulations have different length of the next protocol field? Frank: It depends where you want to go with this. If you have GRE, next type will be ethertype. I wonder where it does apply, how does that apply, and adding that to the document would be of great help. Greg: I will look into the document, but our original goal was to use ion new encapsulations like BIER, Geneve, SFC. Whether that is applicable to GRE we need to discuss. Frank. Having applicability and deployment section would be good. Greg: In BIER, Geneve, and NSH it looks not different. Sam: []. ?/Cisco: Curious to know - this seems to be an inband OAM type. How would this relate to IOAM work in IPPM? Greg: I would stress that inband behavior of OAM is the function of the encapsulation layer. If it draws only from the encapsulation layer and not from the payload then any type of OAM will be inband. In order to ensure that active OAM is inband with the data flow it puts certain restrictions on how the following decision should be drawn. One of the examples that we have is an example how this type of encapsulation can be used for IOAM. The format of the header is something that we can discuss. ?/Cisco: Can you explain how the next protocol is supposed to be used? Do you need to look at the first part of the header? Greg: Yes. If next protocol is 0 it means you have only OAM control packet. If you have nonzero it means that there is something following after the control packet. ?/Cisco: I will take this offline. Greg: Next protocol registry is something that we can discuss. Ilango: The OAM proposal that you have is applicable at different layers, it could be on the overlay layer, it could be on the service layer. Both could coexist, and the document does not have enough applicability information for this case. GIM>> If this is in reference to, for example, SFC NSH over Geneve, then yes, one can construct a packet with OAM message on each layer. Consider Geneve header, followed by its OAM, i.e. OOAM header and OAM message. This Geneve OAM message, in turn, is followed by NSH. And the NSH header is followed by SFC OAM, which includes OOAM Header and SFC OAM message. Is this the scenario you consider? It is certainly interesting but, I think, may not necessarily be described in this document. It may be more suitable to be analyzed in SFC OAM document. Greg: I would personally think that the same packet for the OAM for different layers. Ilango: Not necessarily. NSH can be transported on multiple different transports. If you go through multiple encapsulations before reaching the service node. OAM as part of the NSH header is independent from OAM in the overlay layer. Greg: It would be interesting and helpful to get some operational considerations where one packet is OAM for NSH and overlay transport at the same time. How to identify where the fault happened. It is much easier if it is done on the on the different layers. Ilango: Can you clarify that in the further version of the document? Greg: This can be applied on both layers but independently. Parviz: Back to Frank’s question on applicability - you are going to change behavior of SFC nodes? Is it going to impact the behavior of the SF node, or is it transparent? Greg: If we talk about active OAM, we have multilayer OAM individual document in SFC WG, the scope is SFF. Parviz: Forwarding behavior? Greg: Forwarding behavior is based on SFF, not SF. Parviz: The behavior of the forwarding node is captured? Greg: The expected behavior - the document introduces echo request and reply, and SFF can reply to the sender out of band as requested. Sam: Clarification question. Are you going to pursue this in other WGs? Are you going to pursue to get a common solution? Greg: If the WG in the current work in the header - there is a dependency between OOAM DT and this work in header. If both documents get adopted I will pursue a common solution, if not I will continue with SFC. GIM>> As was mentioned, in draft-wang-sfc-multi-layer-oam<https://tools.ietf.org/html/draft-wang-sfc-multi-layer-oam-06> have proposed use the header for SFC OAM with introduction of SFC Echo Request and Echo Reply.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
