Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi Jorge,
The VNI field in Ethernet Tag has been used to differentiate two BGP routes that have same MAC but different VNI/VLAN-ID. Ideally, it should not be used for nexthop creation. May be we can add that clarification.
Thanks.
- Ravi.

-----Original Message-----
From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - US)
Sent: Wednesday, May 04, 2016 12:53 PM
To: John E Drake <jdrake@juniper.net>; EXT - thomas.morin@orange.com <thomas.morin@orange.com>; BESS <bess@ietf.org>; IDR <idr@ietf.org>; draft-ietf-bess-evpn-overlay@tools.ietf.org; Ali Sajassi (sajassi) <sajassi@cisco.com>
Subject: Re: [bess] [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" <jdrake@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