Sounds good.
Thanks,
-Thomas
2016-06-15, John E Drake:
Thomas,
Comments inline.
Yours Irrespectively,
John
-----Original Message-----
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Wednesday, June 15, 2016 8:47 AM
To: John E Drake; Rabadan, Jorge (Nokia - US); BESS; draft-ietf-bess-evpn-
over...@tools.ietf.org; Ali Sajassi (sajassi)
Subject: draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re:
[Idr] draft-ietf-
bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps)
Hi John, Ali,
Through the discussion below it appeared that section 9 and section
5.1.3 needed adjustments to be brought in sync, and indeed there were some
changes in
last revision.
However, I don't think the cleanup/precision is complete yet:
- section 5.1.3 says "the MPLS label field in the [...] Inclusive Multicast
Ethernet Tag routes is
used to carry the VNI" although the "Inclusive Multicast Ethernet Tag Route" has no
"MPLS
label field"
- (directly related to the above) none of these section talks about using the
MPLS field of
the PMSI Tunnel Attribute as the VNI, although the discussion below concluded
that it is
what implementations actually do
[JD] Accordingly, and specifically to support the option of locally assigned
VNIs, the MPLS label1 field in the MAC Advertisement route, the MPLS label
field in the Ethernet AD per EVI route, and the MPLS label field in the PMSI
Tunnel Attribute of the Inclusive Multicast Ethernet Tag route are used to
carry the VNI.
- also, section 9 now says "The Ethernet Tag field of this route is set as
described in section
5.1.3.", but I find this sentence useless and redundant (precisely because
5.1.3 already says
it and nothing would indicate that section 9 would be exempt of what 5.1.3 says)
[JD] We should strike the sentence.
Additionally, it occurred to me that "the MPLS field" is not, strictly
speaking, unambiguous
for MAC Advertisement routes, because the route actually has two MPLS fields.
The text
should just say "MPLS Label1 field" for the MAC/IP advertisement route.
[JD] See above.
Best,
-Thomas
2016-05-04, John E Drake:
Jorge,
We put the VNI value in the MPLS label field of the PMSI attribute for all
service types,
and we put a value in the Ethernet Tag field following the rules for each
service type as
described in 5.1.3
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-
5.1.3).
You're right that we need to clean up section 9.
Yours Irrespectively,
John
-----Original Message-----
From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, May 04, 2016 3:53 PM
To: John E Drake; EXT - thomas.mo...@orange.com; BESS; IDR;
draft-ietf-bess-evpn- over...@tools.ietf.org; Ali Sajassi (sajassi)
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps
Hi John,
About this:
[JD] For the IMET route the MPLS label field is carried in the PMSI
attribute. I think we need to ask everyone whether they used the
Ethernet Tag or the PMSI attribute to carry the VNI
In case it helps, I’ve seen a few implementations running and they
all encode the VNI in the MPLS label field in the PTA. And a couple
of them, encode the VNI in the ethernet-tag, in addition to the MPLS
label in the PTA. In any case, I think section 9 contradicts section 5.1.3 and
should be
clarified.
"5.1.3 Constructing EVPN BGP Routes
<snip>
the MPLS label field in the MAC Advertisement, Ethernet AD per EVI,
and **Inclusive Multicast Ethernet Tag** routes is used to carry the VNI or
VSID."
Thanks.
Jorge
On 5/4/16, 8:34 PM, "EXT John E Drake" <jdr...@juniper.net> wrote:
Thomas and Jorge,
Snipped, comments inline.
Yours Irrespectively,
John
draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
Encapsulation extended to encode the tunnel encap to use for BUM
traffic, but contrary to other E-VPN routes, relies on the
Ethernet Tag field of the NLRI to encode the VNI/VSID.
[JORGE] This is certainly a leftover from an old version where the
VNI/VSID was encoded in the ethernet tag for all the routes. The
VNI should be encoded in the Label field in all the routes. This has to be
corrected.
In fact, section 5.1.3 says:
5.1.3 Constructing EVPN BGP Routes
<snip>
Accordingly, and
specifically to support the option of locally assigned VNIs, the MPLS
label field in the MAC Advertisement, Ethernet AD per EVI, and
Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
VSID. For the balance of this memo, the MPLS label field will be
referred to as the VNI/VSID field. The VNI/VSID field is used for
both local and global VNIs/VSIDs, and for either case the entire 24-
bit field is used to encode the VNI/VSID value.
<snip>
[JD] For the IMET route the MPLS label field is carried in the PMSI
attribute. I think we
need to ask everyone whether they
used the Ethernet Tag or the PMSI attribute to carry the VNI
There are minor things that could be improved in
draft-ietf-bess-evpn-overlay wrt. consistency with
draft-ietf-idr-tunnel-encaps :
* since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
would be better that draft-ietf-bess-evpn-overlay refers to
draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
[JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the
encapsulation extended community. There are a few implementations
using this community and it is enough when only the encapsulation type is
needed.
[JD] I agree and the tunnel encaps draft does keep the EC
* I think it would be better to avoid the explicit list of encap
types in section 5.1.3, and rather refer to
draft-ietf-idr-tunnel-encaps instead
[JORGE] I agree.
[JD] According to IANA, it allocated the five tunnels types to the
overlay draft so I think we need to keep them
* the following minor modification was proposed, but not yet incorporated:
John Drake, 2015-11-13 (to BESS ML):
For the overlay draft, replace this text in section 5.1.3:
"If the BGP Encapsulation extended community is not present,
then the default MPLS encapsulation or a statically configured
encapsulation is assumed."
With the following:
"Note that the MPLS encapsulation tunnel type is needed in
order to distinguish between an advertising node that only
supports non-MPLS encapsulations and one that supports MPLS and
non-MPLS encapsulations. An advertising node that only
supports MPLS encapsulation does not need to advertise any
encapsulation tunnel types; i.e., if the BGP Encapsulation
extended community is not present, then either MPLS
encapsulation or a statically configured encapsulation is assumed."
I think this change is useful and should be incorporated,
although skipping the last sentence would be wise if the full
list of tunnel types is removed.
[JD] Fine with me either w/ or w/o the last sentence
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
