[spring] Re: [pim] Re: wglc: draft-ietf-pim-p2mp-policy-ping

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Hooman,

Based upon your provided section, i took liberty to rewrite the textblob while doing my best to keep original descriptive normative intent. (modified the observation from Loa during the process)

Newly proposed:
"
The scope of RFC 6425 encompasses fault detection and isolation for P2MP MPLS LSPs. RFC 6425 extends the techniques described in RFC 8029 to apply them to P2MP MPLS LSPs, emphasizing the reuse of existing LSP ping mechanisms used for P2P LSPs. This approach aims to simplify implementation and network operations.

The fault detection procedures defined in RFC 6425 for P2MP MPLS LSPs are applicable to all P2MP MPLS protocols, including P2MP RSVP-TE, Multicast LDP, and now P2MP SR Policy. While RFC 6425 outlines some minor differences for P2MP RSVP-TE and Multicast LDP, this draft specifically addresses these differences for P2MP SR Policy as follows:

1) Egress Address P2MP Responder Sub-TLVs: According to section 3.2.1 of RFC 6425, these sub-TLVs cannot be included for Multicast LDP, as upstream LSRs do not know the identity of downstream leaf nodes. This limitation also applies to P2MP LSPs of P2MP SR Policy, where most transit routers are programmed via a PCE and lack knowledge of the leaf nodes. Only the Root node, where the P2MP SR Policy is programmed, might have knowledge of the leaf nodes. Therefore, these sub-TLVs SHOULD be used with an echo request carrying a P2MP Policy MPLS Candidate Path FEC.

2) End of Processing for Traceroutes: Unlike P2MP RSVP-TE, the initiating LSR for Multicast LDP LSPs might not always know about all the egress nodes. For P2MP SR Policy, the Root can be aware of all egress nodes in the case of PCC-initiated P2MP SR Policy and optionally might be aware of all egress nodes if the P2MP SR Policy is PCE-initiated. Thus, P2MP SR Policy should follow the recommendations of section 4.3.1 of RFC 6425, depending on the Root's awareness of all egress nodes. For instance, with PCC-initiated P2MP SR Policy, the Root can learn the identities of egress nodes via Next Generation MVPN procedures and BGP as per RFC 6514. However, with PCE-initiated P2MP SR Policy, the egress nodes might not be downloaded to the Root by the PCE, as this is optional and implementation-specific.

3) Identification of the LSP Under Test: Section 3.1 of RFC 6425 details the identifiers for each protocol to identify the LSP under test. This draft introduces a new Target FEC Stack TLV for P2MP SR Policy to identify its CPs and PIs.

In addition to these specific differences, P2MP SR Policy should adhere to the common procedures for P2MP MPLS LSPs as outlined in RFC 6425.
"

Hope it helps for this draft.

Brgds,
G/

-----Original Message-----
From: Loa Andersson <[e-mail]> 
Sent: Wednesday, July 10, 2024 2:34 PM
To: Alvaro Retana <[e-mail]>; Michael McBride <[e-mail]>; Hooman Bidgoli (Nokia) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [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)
> ([e-mail]) 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=[e-mail]>
>> Sent: Tuesday, July 9, 2024 6:15 PM
>> To: Alvaro Retana <[e-mail]>; Michael McBride 
>> <[e-mail]>; [e-mail]
>> Cc: [e-mail]
>> 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 <[e-mail]>
>> Sent: Tuesday, July 9, 2024 6:05 PM
>> To: Michael McBride <[e-mail]>; Hooman Bidgoli
>> (Nokia) <[e-mail]>; [e-mail]
>> Cc: [e-mail]
>> 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 -- [e-mail] To unsubscribe send an email 
>> to [e-mail]
>
> _______________________________________________
> spring mailing list -- [e-mail] To unsubscribe send an email to 
> [e-mail]

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]

_______________________________________________
spring mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]