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]> 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]> on behalf of Greg Mirsky < > [email protected]> > *Date: *Monday, May 14, 2018 at 5:24 PM > *To: *NVO3 <[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
