Hi Loa Thank you! Noted!
Hooman -----Original Message----- From: Loa Andersson <l...@pi.nu> Sent: Wednesday, July 10, 2024 8:34 AM To: Alvaro Retana <aretana.i...@gmail.com>; Michael McBride <michael.mcbr...@futurewei.com>; Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; p...@ietf.org Cc: spring@ietf.org Subject: Re: [spring] 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. Alvaro and Hooman, The text itself looks fine, but RFC 4379 has been obsoleted for more than seven years, the correct reference is RFC 8029. /Loa Den 2024-07-10 kl. 12:59, skrev Alvaro Retana: > > Much better — thanks! > > On July 9, 2024 at 10:23:40 PM, Hooman Bidgoli (Nokia) > (hooman.bidg...@nokia.com) wrote: > >> 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 >> <http://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 >> > HB> RSVP-TE 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 >> > HB> policy 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 -- Loa Andersson Senior MPLS Expert Bronze Dragon Consulting l...@pi.nu loa.pi....@gmail.com _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
