[bess] 答复: A question regarding draft-wang-bess-evepn-control-word

["Wanghaibo (Rainsword)" <[e-mail]>]

Hi Alexander,

The number of routes advertised by the Sender router in our solution will not change, but only carries a next hop capability attribute with control word capability
The Receiver router determines whether to carry the control word when forwarding packets according to its own capabilities.

The following figure is an example.:
PE1----------PE2
|-----------PE3
When PE1 advertises a route, it carries the next hop attribute of the control word capability. The routes received by PE2 and PE3 are the same.

If  PE2 do not support the control word, it will not carry the control word when forwarding packets to PE1.
PE1 cannot find the control word indication label when parsing the PE2 packet. PE1 will treat the packet as normal.

If  PE3 support the control word, it can add a control word when forwarding the packet to the PE1, and add the control word indication label specified by the PE1.
When the PE1 receives the packet and finds the control word indication label in the packet. PE1 will correctly process the control word.

Thanks
Haibo

发件人: Alexander Vainshtein [mailto:[e-mail]]
发送时间: 2018年10月23日 16:46
收件人: [e-mail]
抄送: [e-mail]
主题: A question regarding draft-wang-bess-evepn-control-word

Dear authors of draft-wang-bess-evpn-control-word<https://tools.ietf.org/html/draft-wang-bess-evpn-control-word-00>00>,
I have doubts regarding at least one of the approaches for negotiating the CW usage in the EVPN encapsulation between egress and ingress PE that is defined in the draft.

In the case when the egress PE can receive EVPN-encapsulated packets both with and without CW, the draft seems to propose (as one of the possibilities) advertisement of two EVPN routes for each ES or MAC/IP pair:

-          One of these routes would use the CW Capability to indicate that it refers to the EVPN encapsulation that uses the CW, and would carry the appropriate label in its NLRI

-          The other route would not use the CW Capability to indicate that it refers to the EVPN encapsulation that does not use the CW, and carry a different label in its NLRI

The ingress PE that accepts these routes would then use one of them based on its own ability to use the CW (or lack thereof), and use the corresponding label it its EVPN encapsulation, while  the DP in the egress PW would infer presence or absence of the CW from the received EVPN application label.

Unfortunately, I do not think that this can work because, as per RFC 7432<https://tools.ietf.org/html/rfc7432>32>, labels in the labeled NLRI of EVPN routes are not part of the route key for the purpose of the BGP route key processing, while the label is treated just as the BGP attribute. This means that, unless some form of BGP multi-path is enabled in the ingress PE (and in all RRs on the way between the egress PE and ingress PE) for the L2VPN/EVPN  AFI/SAFI, only one of these routes will be selected by the BGP selection process.

Did I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________