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