Re: [bess] Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04

[[e-mail]]

Hi authors,










I also have some other comments on draft-ietf-bess-rfc7432bis-04, 


they are about entropy label, flow label and control word,


maybe some of them are also related to the OPE TLV of draft-heitz-bess-evpn-option-b or RFC7447.









5) Is the entropy label in the following paragraph (in section 18) an entropy label of PSN tunnel (e.g. LDP LSP)?


or is it just an entropy label inside the EVPN label?


I noticed that RFC7447 (after RFC7432) had deprecated the BGP Entropy Label Capability (ELC) attribute.


and RFC7447 says that "A forthcoming document will propose a replacement".


Has the replacement of old BGP ELC attribute been defined?


Does the following paragraph have any relation with (new) BGP ELC attribute?





<rfc7432bis>





" *  If a network uses entropy labels per [RFC6790], then the control


      word SHOULD NOT be used when sending EVPN-encapsulated packets


      over an MP2P LSP."


</rfc7432bit>




6）In previous question 2, I am a little confused in the option b scenario where ASBR may change all inter-AS RT-2 routes' nexthop


     into the same IP address (identifying that ASBR).


     But some of these RT-2 route  may  originate from PEs with flow label capability,


     while some of these RT-2 route may originate from PEs without flow label capability,


     How can these different flow label capabilities of RT-2 routes be distinguished?


     I think the IMET route's Originator IP Address may help, 


     but RT-2 routes don't carry an originator IP address, maybe the OPE TLV of draft-heitz-bess-evpn-option-b-01 can be used,


     in order to find out the correct flow label capability and avoid the black-hole caused by incorrect flow label capability.


     I think this is very similar to the procedures used to select leaf labels for EVPN E-Tree services.









7) I noticed that RFC7432 has already used a control-word, although RFC7432 don't recognize a C bit (or L2-Attr EC).


    So when PE1 sends a Inclusive Multicast route to an old RFC7432-only node PE2 along with a C bit = 1,


    but PE2 doesn't insert a control-word for it in the data packet, 


    I think PE1 may not decapsulate that data packet correctly.


    Because PE1 can't know that PE2 doesn't insert a control word.


    It may be easy to determine whether a data packet is inserted with a flow label,


    but it is not easy to determine whether a data packet is inserted with a control word.


    I think there may be compatibility issues in such scenarios.


    Otherwise maybe the IMET route from PE1 to PE2 and the IMET route from PE2 to PE1 should be used together to determine whether a control word can be expected in the data plane. This may requires a PED label similar to that is in draft-ietf-bess-evpn-virtual-hub.



    But a special purpose label (similar to ELI label) may be easier to indicate there is (or isn't) a control-word in the data packet.


 






8) IMHO, the problem which is pointed out by RFC7447 is a common problem, not just the ELC Attribute will be affected.


     Other BGP Attributes (e.g. flow label, control word)  which can match the following features will  all have the similar problems:


     8.1) these attributes are optional transitive BGP attributes


     8.2) these attributes has a corresponding protocol-header in the data packets (e.g. flow label, control word, leaf label by OPE TLV)






     Maybe  we need a new attr. flag (thus we don't have to set the transitive flag in the future optional attributes when we want such optional attributes to pass through a future RR which can't recognize it) to address these problems. 






9) How can the egress PE know whether the ingress PE will use a P2P RSVP-TE LSP or not ?


    how should the egress PE know whether it can expect there is a control word in corresponding data packet or not?


    In RFC7432, these responsibilities is left to manual configurations,


    but now it is a dynamical signalling/negotiation, the manual work may not need to care about these things any more.






<rfc7432bis>

   *  When sending EVPN-encapsulated packets over a P2MP or P2P RSVP-TE

      LSP, then the control word SHOULD NOT be used.


</rfc7432bis>










Thanks


Yubao














原始邮件



发件人：王玉保10045807
收件人：[e-mail];
抄送人：[e-mail];
日 期 ：2022年03月17日 13:36
主 题 ：Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04








Hi authors,





I read draft-ietf-bess-rfc7432bis-04 and I have the follwing questions and comments:





1) In section 7.11.1, F bit (flow label capability) of L2 Attr Extended Community is conveyed in Inclusive Multicast routes only,


and F bit will not be conveyed in Etherne A-D per EVI routes.


It will mean that the Inclusive Multicast route (which is used for BUM packets only in RFC7432) will be used for known-unicast packets too?


Because that the flow label is not pushed onto BUM packets, it is only pushed onto known-unicast packets.


Is my understanding correct?






2) If my previous understanding is correct, then I have the following questions and I can't find explicit describing in rfc7432bis.


When PE1 received an Inclusive Multicast route with (tunnel type=ingress-replication, Tunnel Identifier of PMSI tunnel attr = IP1, nexthop = IP2, originator IP address = IP3), 


so which one of the following cases should be inserted with a flow label?


2.1) a RT-2 route whose nexthop is IP1 and ESI is 0;


2.2) a RT-2 route whose nexthopp is IP2 and ESI is 0;


2.3) a RT-2 route whose nexthop is IP3 and ESI is 0;


2.4) a RT-2 route whose nexthop is IP1(or IP2) and ESI is an all-active ESI, but the Ethernet A-D per EVI route's nexthop is IP4





2.5) a RT-2 route whose nexthop is IP4 and ESI is a single-active ESI and MPLS label is L2, but the Ethernet A-D per EVI route's nexthop is IP1(or IP2) and MPLS label is L1.


In question 2.5, I also don't find any explicit describing about which MPLS label should be used in such case.


so which MPLS label should be used L2 or L1 in such case according to rfc7432bis? 





I think it will be more clear than this way if the Flow label capability is carried by RT-2 routes themselves.






3) How to interpret "a given MAC address is only  reachable only via the PE announcing the associated MAC/IP  Advertisement route" ?


 I mean that: When PE1 receives a RT-2 route whose nexthop is IP1, and the corresponding Etherne A-D per EVI route (whose nexthop is also IP1) conveys a non-zero B bit, but there is another Ethernet A-D per EVI route whose P bit is not zero, but its nexthop is IP4 (not IP1, who has announced that RT-2 route), should that RT-2 route be installed into the dataplane and be used to forwarding traffics?


This case may happens in some temporary conditions.









<rfc7432bis>


   This means that for a given [EVI, BD], a given MAC address is only


   reachable only via the PE announcing the associated MAC/IP


   Advertisement route - this PE will also have advertised an Ethernet


   A-D per EVI route for that [EVI, BD] with an L2-Attr extended


   community in which the P bit is set.  I.e., the Primary DF Elected PE


   is also responsible for sending known unicast frames to the CE and


   receiving unicast and BUM frames from it.  Similarly, the Backup DF


   Elected PE will have advertised an Ethernet AD per EVI route for


   [EVI, BD] with an L2-Attr extended community in which the B bit is


   set.


</rfc7432bis>





4)  When flow label is not used (as per RFC7432) in Ingress Replication mode,


I try to find out whether the downstream assinged VPN label for known unicast must be different than for BUM traffic.


And I don't find any explicit describing for this, and I just noticed that in EVPN VXLAN they can be the same.


So when flow label is not used in MPLS EVPN, 


can the downstream assinged VPN label for known unicast be the same as for BUM traffic following rfc7432bis?


If this is just for flow-label only, I think it will be better to say "If flow-label is used, the downstream assigned VPN label for known unicast can/should be different than for BUM traffic"





<rfc7432bis> 


   *  If a PE receives a unicast packet with two labels, then it can


      differentiate between [VPN label + ESI label] and [VPN label +


      Flow label] and there should be no ambiguity between ESI and Flow


      labels even if they overlap.  The reason for this is that the


      downstream assigned VPN label for known unicast is different than


      for BUM traffic and ESI label (if present) comes after BUM VPN


      label.  Therefore, from the VPN label, the receiving PE knows


      whether the next label is a ESI label or a Flow label - i.e., if


      the VPN label is for known unicast, then the next label MUST be a


      flow label and if the VPN label is for BUM traffic, then the next


      label MUST be an ESI label because BUM packets are not sent with


      Flow labels.


</rfc7432bis>





Thanks,


Yubao