On 7/30/14 5:51 PM, "Dino Farinacci" <[email protected]> wrote:
>> 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. > >Well there is no reason they wouldn't go the same as the user packets if >the destination IP address was the same. Also, the OAM proposal for LISP >is to measure paths between RLOCs. The same RLOCs that are used for data >packets. You don't need a data-plane header to achieve the same paths. >And again, you give more work for the hardware to do. I'm assuming that routers and switches will be multipathing based on the UDP port numbers, so I would expect different destination UDP ports to take different equal cost paths. > >> >>> 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. > >Yes, typo. > >We will call it a port used by LISP because it is documented in >draft-smith-lisp-layer-2. But don't miss the point of referencing it. > >> 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. > >No one is questioning the intent of NSH. But it should use a UDP header >not a VXLAN header. Why is it any different than DNS or SMTP? I agree that for service chaining, NSH can certainly ride within UDP. I'm referring to using NSH to extend the VXLAN header (or similar encapsulation...I'm not sure what layer to call it). I responded to Tom on this thread regarding a potential use case for this. > >If the NSH UDP packet gets encapsulated downstream by a VXLAN or LISP >device, so be it. But why should NSH prepend a VXLAN header. And why >would NSH prepend a MAC header before the VXLAN header. I talked to the >authors about this, so it is not news to them. > >Dino > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
