Hi Marc,
VXLAN-GPE have next protocol field, so it can combine multiple data planes into
one VXLAN-gpe. Currently inner destination MAC can be used to distinguish layer
2 and layer 3 traffic at egress NVE.
Thanks
weiguo
发件人: Marc Binderberger
A minor correction, LISP does have a unified encapsulation where the packet
demux function, that has been defined for a few years, is done with UDP ports.
As for VXLAN, the packet demux, has been recently introduced, is done with the
P-bit.
Dino
On Jul 29, 2014, at 8:15 PM, Haoweiguo
On Jul 30, 2014, at 2:29 AM, Haoweiguo haowei...@huawei.com wrote:
VXLAN-GPE have next protocol field, so it can combine multiple data planes
into one VXLAN-gpe. Currently inner destination MAC can be used to
distinguish layer 2 and layer 3 traffic at egress NVE.
You can do what you say
Hi Dino,
On 7/29/14 1:08 AM, Dino Farinacci farina...@gmail.com wrote:
On Jul 28, 2014, at 9:52 PM, Marc Binderberger m...@sniff.de 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
On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger)
kree...@cisco.com wrote:
Hi Tom,
First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 for
NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly following
the VXLAN-GPE header would be an NSH header. One would
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
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
