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

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

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 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.