[bess] 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. 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. 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" * 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. Thanks, Yubao___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
Hi, I fully support this document for WG adoption. 1) Does this technology support the SR P2MP features that distributes candidate paths which connect a multicast distribution tree (tree to leaves). Yes, it does. 2) Is the technology correctly specified for the NLRI (AFI/SAFI) and the tunnel encapsulation attribute additions (sections 2 and 3)? Yes, it is correctly specified. The text can be improved if needed once adopted. 3) Does the P2MP policy operation (section 4) provide enough information for those implementing this technology and those deploying the technology? Yes, it does. Again the text can be refined once adopted. 4) Do you think this multicast technology is a good Place to start for P2MP policy advertisement via BGP? Yes. 5) Do you think this SR P2MP policies should not be advertised via BGP? This SR P2MP policies should be able to be advertised in BGP as an option, just like it is done for unicast SR policies. Thanks. Jorge From: BESS on behalf of Susan Hares Date: Thursday, March 10, 2022 at 6:56 AM To: i...@ietf.org , p...@ietf.org , bess@ietf.org Subject: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) This begins a 2 week WG adoption call for: draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022) You can obtain the draft at: https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/ In your comments for this call please consider: 1) Does this technology support the SR P2MP features that distributes candidate paths which connect a multicast distribution tree (tree to leaves). 2) Is the technology correctly specified for the NLRI (AFI/SAFI) and the tunnel encapsulation attribute additions (sections 2 and 3)? 3) Does the P2MP policy operation (section 4) provide enough information for those implementing this technology and those deploying the technology? 4) Do you think this multicast technology is a good Place to start for P2MP policy advertisement via BGP? 5) Do you think this SR P2MP policies should not be advertised via BGP? Cheers, Susan Hares ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)
Hi Ketan I reviewed the updated security considerations section and the update looks good. As well section 10.3 Data plane considerations and read again the referenced documents security considerations section of RFC 8402, RFC 8986, RFC 8754 and RFC 8996. All looks very good. One question I had was that if operators only advertises the SRv6 summary block B:N::/48 to the internet, the summarization route would not contain the embedded BGP Prefix SID attribute encoding of L2 and L3 Service SID in the FUNCT field of the SRv6 SID. If you agree with what I have stated , then that would limit the exposure drastically related to service SID leakage to the internet. The security exposure is related to only the inter-as peering lateral, provider or RS peering and not customer peering as the SRv6 source node encapsulates customer traffic into payload of outer IPv6 header. So I think customer PE-CE edge peering would not be a security issue. Also another thought is that within an SRv6 domain as next hop self is used internally on any inter-as lateral, provider or RS ties which is done on both ends of the peering between operators, does the SRv6 B:N::/48 underlay block even need to be advertised externally. As the BGP overlay is what holds the internet table and that is all that needs transitivity for internet route reachability. That would further reduce the exposure of data plane service sid encoding in SRv6 SID leaking to the internet. As far as SRv6 service capabilities draft below, my thoughts are as any parallel multi transport that exists would only be done within the confines of a domain within the same operators Administrative domain and not between providers which would also be limited during a transition from brown field MPLS or SR-MPLS to a parallel Green field SRv6 transport. As this use case is all within the same domain, careful design is on the onus of the operator as relates to SRv6 to MPLS BGP overlay interoperability for SAFI 128. So I don’t see this as a major issue for operators as all the careful considerations will be taken for that interoperability as well as there are many underlying solutions for SRv6 to MPLS or SR-MPLS interoperability. This is more of an interoperability issue use case that could be considered orthogonal to this draft that only exists within an operators network during migration. https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02 Kind Regards Gyan On Sat, Mar 5, 2022 at 4:40 AM Ketan Talaulikar wrote: > Hi John, > > We've just posted an update to the draft to address the comments raised > and to clarify the security considerations. > > https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12 > > Thanks, > Ketan > > > On Thu, Feb 24, 2022 at 3:42 PM Robert Raszuk wrote: > >> Hi John, >> >> You have highlighted below a very important point. It was discussed among >> co-authors, but perhaps not sufficiently during the BESS process as the >> issue is really not a BESS WG problem. >> >> In BGP protocol any new service deployment using existing AFI/SAFI is not >> easy. Especially when you are modifying content of MP_REACH or MP_UNREACH >> NLRI attributes. Main reason being is that using capabilities only goes one >> hop. In full mesh it all works perfect, but the moment you put RR in >> between BGP speakers things are getting ugly as capabilities are not >> traversing BGP nodes. /* Even in full mesh mixing transports for the same >> service is a serious challenge for routers when say multihomes sites are >> advertised from different PEs with different transport options */. >> >> Imagine RR signals SRv6 Service Capability to the PE. Then this PE >> happily sends a new format of the UPDATE messages. Well as today we also do >> not have a notion of conditional capabilities (only send when received from >> all) so if some of the RR peers do not support it you end up in partial >> service. One can argue that in this case the only deterministic model is to >> push the configuration from the management station and control partial >> deployment of the new service from mgmt layer. >> >> The natural alternative would be to never modify NLRI format once shipped >> by RFC. When needed issue a new SAFI. Yes that is an option (and has always >> been) but it also comes with its own set of issues. New SAFI is really >> great to define for new service/feature etc ... Here however in the context >> of this discussion we are changing transport for existing service. And >> just like it was the case with MPLS over UDP or tunnel attribute etc ... >> using a new SAFI would be very hard to deploy as there would need to be >> well defined behaviour of BGP speakers receiving duplicate information for >> the same VPN prefixes or receiving at one time only from single SAFI then a >> bit later from the other one .. Of course one solution is to permit only >> one SAFI for a given service at any given time, but that seems way too >>
