Mohamed Boucadair has entered the following ballot position for draft-ietf-bess-mvpn-evpn-sr-p2mp-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Rishabh, Daniel, Clarence, Hooman, and Jeffrey, Thank you for the effort put into this specification. Please find some points for discussion: # Updates RFC 6514 CURRENT: For SR P2MP P-Tunnels, these procedures remain unchanged except as described in the following paragraphs. … Procedure for receiving Intra-AS I-PMSI A-D routes, as described in RFC 6514 Section 9.1.2 (https://tools.ietf.org/html/rfc6514#section- 9.1.2), remain unchanged for SR P2MP P-Tunnels except as described in the following paragraphs. .. RFC 6514 Section 12.1 (https://tools.ietf.org/html/rfc6514#section- 12.1) describes procedures for originating S-PMSI A-D routes. For SR P2MP P-Tunnels, these procedures remain unchanged except as described in the following paragraphs. .. Etc. The spec seems to update many parts of RFC6514. # Updates RFC 7988 CURRENT: The PTA carried in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, Selective PMSI A-D and Leaf A-D routes is constructed as specified in RFC 7988 with modifications as below: ..but this is not reflected as an explicit update header. # RFC 7899 is normative CURRENT: PEs MAY also implement procedures for damping other Auto-Discovery and BGP C-multicast Source Tree Join and Shared Tree Join routes as described in [RFC7899]. 7899 is required to address this key operational issue. # RFC 8293 is normative CURRENT: SRv6 P2MP trees MAY be used as an underlay multicast mechanism, as described in RFC 8293 Section 3.4 (https://tools.ietf.org/html/ rfc8293#section-3.4). In this case, a Network Virtualization Edge (NVE) MUST encapsulate tenant packets in an SRv6 header and deliver them over SRv6 P2MP trees to other NVEs. ## RFC 8293 is normative. Please note that when added, this will create a downref. ## Why this is discussed at the first place? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # I’m not sure the first sentence of the abstract adds much. # Better flow OLD: P-Tunnels can be instantiated via different technologies. A service provider network that uses NEW: P-Tunnels can be instantiated via different technologies. For example, a service provider network that uses # Precision CURRENT: In a Segment Routing network, a P2MP tree allows efficient delivery of traffic from a Root to set of Leaf nodes. It is an optimization if that traffic has to be sent to all these nodes. I’m not sure this sentence is t currently stands is accurate or adds much to the discussion. # Tree or Tree instance I guess OLD: An SR P2MP tree is defined by a Candidate path of an SR P2MP policy [I-D.ietf-pim-sr-p2mp-policy]. Should be NEW: An SR P2MP tree instance is defined by a Candidate path of an SR P2MP policy [I-D.ietf-pim-sr-p2mp-policy]. # The document does not discuss operational (including manageability) considerations ## For example, consider: CURRENT: The PTA identifies the P-Tunnel that is used to instantiate a Provider Multicast Service Interface (PMSI). Can we clarify in the text the intended behavior for making use of the attributes, especially: ### Should the use of the PTA with SR-triggered tunnel be conditioned by explicit activation or should be by default used when at least of the ### Should a node advertise an SR tunnel type independent of whether the underlying SR data plane function is supported/enabled? ## There is also no discussion on scalability implications, means to diagnose and installed state, etc. Pointing to where these are discussion would be sufficient. ## Let's consider this one: CURRENT: A P2MP tree PTA is constructed as specified below: * Tunnel Type: From the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry - 0x0C for SR-MPLS P2MP Tree - TBD for SRv6 P2MP Tree ## The introductory sentence should scope it the use defined in this document. Reading separately this text can be interpreted as if these are the only allowed values, which is not the intent here. ## The tunnel type should be configurable. # Without an SLA CURRENT: Procedures of [RFC7988] are sufficient to create a SR-MPLS Ingress Replication for MVPN service without a SLA. I don’t parse this sentence, especially the last part. # IMET OLD: BGP MPLS Ethernet VPN specified in [RFC7432] specifies Inclusive Multicast Ethernet Tag route to support Broadcast, Unknown Unicast and Multicast (BUM) traffic. NEW: BGP MPLS Ethernet VPN specified in [RFC7432] specifies Inclusive Multicast Ethernet Tag (IMET) route to support Broadcast, Unknown Unicast and Multicast (BUM) traffic. # Ambiguity CURRENT: That document defines new BGP route types that MUST be advertised with a PMSI Tunnel Attribute (PTA), including the Selective PMSI (S-PMSI) Auto-Discovery route. Which doc? Why normative language is used here? Cheers, Med _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
