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

["Hooman Bidgoli (Nokia)" <[e-mail]>]

Hi Loa

Thank you! Noted!

Hooman

-----Original Message-----
From: Loa Andersson <[e-mail]> 
Sent: Wednesday, July 10, 2024 8:34 AM
To: Alvaro Retana <[e-mail]>; Michael McBride <[e-mail]>; Hooman Bidgoli (Nokia) <[e-mail]>; [e-mail]
Cc: [e-mail]
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)
> ([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]