From: John E Drake <[email protected]>
To: Sunny Rajagopalan/Santa Clara/IBM@IBMUS,
Cc: Kireeti Kompella <[email protected]>, Aldrin Isaac
<[email protected]>, "[email protected]" <[email protected]>
Date: 09/26/2012 12:16 PM
Subject: Re: [nvo3] use of RD vs MPLS label for VNID encoding (was
Re: comments on draft-drake-nvo3-evpn-control-plane)
Sent by: [email protected]
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.
SR: Actually, in my mind the RD is semantically the same as the VNID, so
the use is appropriate. The semantic conservative in me wouldn't take out
any protest rallies if we used it as such, and might even celebrate a bit
inwardly.
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.
SR: This works for me, if using the last four bits won't lead to problems
with BGP software parsing the packet (won't setting S=0 confuse it?). To
be clear, the text will state that the 24-bit VNID will be carried in an
opaque manner in the 3-octet label field, right? Specifically, I'm looking
for removing the language that says the last four bits are reserved.
--
Sunny
From: Kireeti Kompella <[email protected]>
To: Aldrin Isaac <[email protected]>,
Cc: Sunny Rajagopalan/Santa Clara/IBM@IBMUS, "[email protected]" <
[email protected]>, "[email protected]" <[email protected]>, "[email protected]
" <[email protected]>, "[email protected]" <[email protected]>, "
[email protected]" <[email protected]>, "
[email protected]" <[email protected]>, "[email protected]" <
[email protected]>, "[email protected]" <
[email protected]>, "[email protected]" <[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]> 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]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
