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

[Alvaro Retana <[e-mail]>]

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 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 -- [e-mail]
To unsubscribe send an email to [e-mail]