Snipped. Comments inline.
Yours irrespectively,
John
JD: RD is strictly a control plane construct used to keep BGP happy. It has
never been used as a data plane packet demux.
SR: I did admit that it's not been used before, but my point is that it serves
the same purpose as the VNID, and should be used as such. MPLS based
implementations wouldn't use it on the wire, but VXLAN based implementations
already have the equivalent on the wire.
JD: As a semantic conservative you should be ashamed of yourself for
suggesting this 8->, particularly as it is completely unnecessary.
Semantic arguments aside, the chief reason I preferred using the RD instead of
the MPLS label is that it would allow us to encode the complete 24 bit VNID in
the BGP route, instead of truncating it to 20 bits to fit inside the MPLS label
field.
JD: You did not read the text carefully enough. The contents of the 3 octet
MPLS label field are copied directly into the VNID/Tenant ID field of a packet.
SR: I was referring to the truncation described here:
This memo specifies that when E-VPN is to be used with a VXLAN or
NVGRE data plane that a VNI or Tenant ID is twenty bits in
length and may have either global or local significance, that
the remaining four bits are reserved,
JD: You clipped the remaining part of the sentence which reads : "and that
the value advertised in the MPLS label field is to be treated as a three octet
quantity to be placed directly in the VNI or tenant ID field of a packet."
There is no MUST or SHOULD associated with the four bits being reserved. If it
will make folks happier I can reword the sentence to indicate that the
advertised three octet label is nominally the VNID or Tenant ID but should be
considered to be opaque.
--
Sunny
From: Kireeti Kompella
<[email protected]<mailto:[email protected]>>
To: Aldrin Isaac <[email protected]<mailto:[email protected]>>,
Cc: Sunny Rajagopalan/Santa Clara/IBM@IBMUS,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: 09/26/2012 09:39 AM
Subject: Re: [nvo3] comments on draft-drake-nvo3-evpn-control-plane
________________________________
Thanks, Aldrin!
More inline.
On Sep 25, 2012, at 21:23, Aldrin Isaac
<[email protected]<mailto:[email protected]>> wrote:
>> 1) I would suggest *not* altering the semantics of the MPLS label in the BGP
>> route.
Note that no one is suggesting altering the semantics of an MPLS label. What's
proposed is altering the interpretation of a three-byte field in the NLRI.
>> Instead, use the route distinguisher to carry the 24-bit VNID (this
>> is arguably better since the semantics of the RD align better with the
>> semantics of the VNID). I would suggest encoding this as a type 0 RD, with
>> the VNID going into the Assigned number sub-field. In addition, call out
>> that an MPLS label value of 0 in the BGP route is a valid value, and will be
>> used by PEs which do not support MPLS encap.
>
> The RD was not intended to be used to signal data plane bits. That's
> what the label field is for.
Exactly. Worse than that, the RD is responsible for _distinguishing_ routes. If
VNIDs are locally generated (an option well worth holding on to), all manner of
hell will break loose.
Kireeti
_______________________________________________
nvo3 mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
