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

["Rabadan, Jorge (Nokia - US)" <[e-mail]>]

Hi Ravi,

Of course, in case of vlan-aware bundle services. But should be zero in case of VLAN-based or VLAN-bundle.
Thx
Jorge 




On 5/4/16, 10:45 PM, "EXT Ravi Shekhar" <[e-mail]> wrote:

>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:[e-mail]] On Behalf Of Rabadan, Jorge (Nokia - US)
>Sent: Wednesday, May 04, 2016 12:53 PM
>To: John E Drake <[e-mail]>; EXT - [e-mail] <[e-mail]>; BESS <[e-mail]>; IDR <[e-mail]>; [e-mail]; Ali Sajassi (sajassi) <[e-mail]>
>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" <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bess