Hi Dino, On 7/29/14 1:08 AM, "Dino Farinacci" <[email protected]> wrote:
> > >> On Jul 28, 2014, at 9:52 PM, Marc Binderberger <[email protected]> wrote: >> >> Hello Dino, >> >> thanks for this comment - that's an interesting point of view. >> >> Hmm, how do the O (or RA in another draft) and the P bit fit into this > >O-bit in LISP is not needed. I told the LUSP-GPE authors this. Because >OAM-packets like all other control packets go in UDP port 4342 (where >encapsulated packets go in UDP port 4341). I can see the O-bit being useful when you want to use port 4341 to help ensure that OAM packets use the same path through the network as the user data packets. > > >And P-bit is not needed and the authors indicated the main motivation was >to keep consistent with VXLAN so same hardware design could do both. LISP >already has port 8473 for L2 frames. I assume you meant 8472 (assigned to OTV and used by VXLAN implementation pre-IANA assignment). I'm not sure you can technically call this a LISP port. >And NSH is a service protocol and should run above the transport layer so >should have its own port and can address packets anywhere. I think the intent of NSH is to be generic enough to work at different layers. The recent addition of the Metadata Type field in the NSH header allows for it to be used for purposes beyond SFC. It could theoretically be used to essentially extend the header of the layer below it (e.g. VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 bit VNI authentication. - Larry >Just like any other UDP application. If that packet needs to be >encapsulated that is a lower level function. Just like IP packets can go >in an MPLS based LSP. > >> picture? They do mean something about how the packet is handled, don't >>they? > >I won't answer that because those bit introductions into the design are >indeed design bugs IMO. > >Dino >_______________________________________________ >nvo3 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
