Hi Alvaro How the below text to address your comment?
Thanks Hooman "RFC 6425 scope is fault detection and isolation for P2MP MPLS LSPs. RFC 6425 extends the techniques described in [RFC4379] such that they may be applied to P2MP MPLS LSPs. RFC 6425 stresses the reuse of existing LSP ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation. The RFC 6425 procedures for fault detection of a P2MP MPLS LSP are common for all P2MP MPLS protocol types including P2MP RSVP-TE and Multicast LDP and now P2MP SR Policy. There are minor differences pointed out in RFC 6425 with regards to P2MP RSVP-TE and Multicast LDP which this draft will specifically address for SR P2MP Policy, these minor differences are as follow: 1. Including Egress Address P2MP Responder Sub-TLVs which can not be included for Multicast LDP as per section 3.2.1 of RFC 6425. In Multicast LDP, there is no way for upstream LSRs to know the identity of the downstream leaf nodes. This is also true for P2MP LSPs of P2MP SR Policy as most transit routers are programmed via a PCE and have no knowledge of the leaf nodes. The only node that might have knowledge of the leaf nodes is the Root where the P2MP SR Policy is programmed. Hence these sub-TLVs SHOULD BE used with an echo request carrying a P2MP Policy MPLS Candidate Path FEC. 2. End of Processing for Traceroutes, for Multicast LDP LSPs, the initiating LSR might not always know about all the egress nodes unlike P2MP RSVP-TE. For P2MP SR Policy the Root of the tree can be aware of the all the egress nodes in the case of PCC initiate P2MP SR Policy and optionally it "MIGHT" be aware of the all the egress nodes if the P2MP SR Policy is PCE initiated. There for P2MP SR Policy should follow the recommendation of section 4.3.1 of RFC 6425 depending on if the root is aware of the all the egress nodes or not. As an example for PCC initiate P2MP SR Policy the root can learn the identities of egress nodes via the Next Generation MVPN procedures and BGP as per RFC 6514, but with PCE initiated P2MP SR Policy the egress nodes "MIGHT" not be downloaded to root by the PCE, as this is optional and implementation specific. 3. Another major difference between P2MP RSVP-TE and Multicast LDP in RFC 6425 is section 3.1 for identifying the LSP under test. Each protocol has its own identifier. This draft defines a new Target FEC Stack TLV for P2MP SR Policy to identify the its CPs and PIs. Beside the major differences explained above the P2MP SR Policy should follow RFC 6425 common procedures for P2MP MPLS LSPs." -----Original Message----- From: Hooman Bidgoli (Nokia) <hooman.bidgoli=40nokia....@dmarc.ietf.org> Sent: Tuesday, July 9, 2024 6:15 PM To: Alvaro Retana <aretana.i...@gmail.com>; Michael McBride <michael.mcbr...@futurewei.com>; p...@ietf.org Cc: spring@ietf.org Subject: [spring] Re: [pim] Re: wglc: draft-ietf-pim-p2mp-policy-ping Hi Alvaro I am all for better text to make it more clarify, but then I need to copy paste from rfc6425 into this draft. This is how we implemented the P2MP Policy ping 1. we used procedures from RFC6425 for mLDP. In short we went through RFC 6425 and any procedure for mLDP we implemented it. 2. then to identify the packet as SR P2MP Policy we changed the Target FEC Stack sub tlv to specific P2MP policy identifiers. In short anyone that has a mLDP ping implemented should have the bases of the implementation and they only need to change the "target FEC Stack" Given the above 2 points what do you suggest should be added to the draft. As of now the draft is based on the above 2 points. I don't think copy pasting mLDP procedures from rfc6425 to this draft will help at all, it is redundant. What do you suggest? Thanks Hooman -----Original Message----- From: Alvaro Retana <aretana.i...@gmail.com> Sent: Tuesday, July 9, 2024 6:05 PM To: Michael McBride <michael.mcbr...@futurewei.com>; Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; p...@ietf.org Cc: spring@ietf.org Subject: RE: [pim] Re: wglc: draft-ietf-pim-p2mp-policy-ping CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. On June 24, 2024 at 11:59:13 PM, Hooman Bidgoli wrote: Hooman: Hi! Sorry it took me so long to get back. ... > > My main concern is that there is no specification contained in the > > document. Instead, this sentence appears in §3.1: "This draft reuses > > most procedures for mLDP in RFC [RFC6425]" > > > > It is not clear from the text which procedures from rfc6425 are > > reused and which are not. Specifically, rfc6425 didn't deal with SR, > > so the procedures specified there, even if similar, are different. > > It should be clear in this document how the procedures in rfc6425 > > relate to the new functionality and which don't apply. > > > > I am sure the people working on the existing implementation (and the > > authors) know exactly what the sentence in §3.1 means, but I doubt > > that an interoperable implementation can be coded just from the text > > in this document. > > HB> thanks, as you know RFC 6425 is common procedures for P2MP RSVP-TE > HB> and > Multicast LDP. The only specific section for the two is section 3.1.1 > where the identification of P2MP LSP is done and 3.2.1 where egress > Address P2MP responder sub-tlv is only for P2MP RSVP-TE and multicast LDP. > > HB> so how about the following text > > HB> “This draft reuses procedures for mLDP in [RFC6425]. A P2MP policy > HB> and > its corresponding Candidate Paths and path instances do not have a > signaling layer and are setup manually via CLI or automatically via a > controller. As an example, as per [RFC6425] section 3.2.1 just like > Multicast LDP for each replication segment acting as LSR, there is no > way to know the identity of the downstream leaf nodes. This draft will > follow the Multicast LDP procedures in section 3, 4, 5 and 6 with > exception of section 3.1 which explains the procedures and TLVs needed > to identify the LSP under test. The procedures to identify the LSP is > explained in this draft. “ To be completely honest, this text doesn't make me feel good -- it feels like something's missing. But because the WG is not in the business of making me happy and no one else is commenting on this point, then I'm happy to be in the rough. :-) Thanks! Alvaro. _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
