[bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html

["Allu, Ramaprasad" <[e-mail]>]

Hi Authors of draft https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html

I have a following query on the draft.  Please help with your response.


Context of section https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-09.html#section-3.1,

In the section, it is mentioned that the construction of the IP A-D per EVI route is same as that of the Ethernet A-D per EVI route. The NLRI consists of the following,

                +---------------------------------------+

                |  Route Distinguisher (RD) (8 octets)  |

                +---------------------------------------+

                |Ethernet Segment Identifier (10 octets)|

                +---------------------------------------+

                |  Ethernet Tag ID (4 octets)           |

                +---------------------------------------+

                |  MPLS Label (3 octets)                |

                +---------------------------------------+



And as per https://www.rfc-editor.org/rfc/rfc7432.html#section-7.1, “ for the purpose of BGP route key processing, only the Ethernet

   Segment Identifier and the Ethernet Tag ID are considered to be part

   of the prefix in the NLRI.  The MPLS Label field is to be treated as

   a route attribute as opposed to being part of the route”



If MPLS label field is not considered for BGP route key, then BGP RIB will have only one route entry at any given point of time.

That is, IP A-D per EVI route overwrites Ethernet AD per EVI and vice-versa if same RD is used for IP-VRF and MAC-VRF.



Is there any reason for explicit mention of not using MPLS label field as key for BGP route?

In this case, I see only MPLS Label (VNI in case of VXLAN) is the distinguisher.

And to keep these two routes in BGP RIB, we need to use MPLS label also one of the keys in addition to RD, ESI and ETAG fields.



Please let me know what you think.



Thanks,

Ramaprasad