---------- Forwarded message --------- From: Tony Przygienda <[email protected]> Date: Fri, Jul 17, 2026 at 9:10 AM Subject: Re: [Lsr] Comments on draft-prz-lsr-ash-packets-00 To: Les Ginsberg (ginsberg) <[email protected]>
On Fri, Jul 17, 2026 at 3:31 AM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > 1)I see you have now defined a TLV for hellos to advertise the capability > to support ASH > > >From Section 5.1: > > " The ASH Capability TLV is a zero-length TLV (type TBD) included in IIH > PDUs." > > I ask that you consider defining something more generic/extensible so that > we can use the same TLV codepoint to advertise other per link capabilities > in the future (yes - I have some in mind...) > The TLV would be formatted analogous to the IPv4/IPv6 Extended > Reachability Attribute Flags sub-TLV defined in RFC 7794 - but would be a > TLV (not a sub-TLV) only to be sent in hellos. > > Link Capability TLV > Type - TBD > Length - Number of octets in the Value field > Value - Extensible bit string > > We create a registry to define the bit assignments. You get the first bit > (or perhaps two bits if you want to advertise ASH support per level). > > This is more flexible and forward looking. > Les, sure, easily done. > > 2)The context for this draft is high scale. Section 9 states: > > " we focus on realistic scenarios on the order of 50,000 nodes and 1 > million fragments. " > > Given that, I think it likely that you will encounter a case where some > nodes need to advertise more than 256 LSPs at a given level. > The defined solution for that is RFC 7356 - which defines flooding scoped > PDUs - including FS-LSPs and FS-CSNPs and FS-PSNPs. > > Given that your current choice is to define new PDU types, you will then > need to define new FS-CSNP/FS-PSNP PDUs to support such deployments. > NOTE: The same TLV format for advertising Node Range Hash Entries will > still work. > > I think this should be discussed in the draft. > reasonable take. We can and should do that. Agree that a _uuuuge scale the 256 fragment problem becomes more pressing but IMO 2 system IDs will be more likely to be deployed rather than 7356 (which I'd love to see fielded but all I see is significantly harder to introduce in the field). > > Which brings me to my next comment... > > 3)You currently choose to define new PDU types for CSNPs/PSNPs to > advertise ASH information - but this is not necessary. > > The existing CSNP/PSNP formats are fully compatible and can support the > existing LSP entry TLVs and the new Hash Entry TLVs in the same PDU so long > as order is preserved in CSNPs. > Given that the finest granularity of ASH TLVs is all the LSPs from a > single node, it is obvious that the use of LSP entry TLVs is still needed > to synchronize LSPDBs. > As one of the primary goals of the extensions of this draft is to reduce > the number of PDUs, being able to combine LSP Entry TLVs and ASH TLVs in > the same PDU has the potential to reduce the number of PDUs required even > further. > In addition, using existing PDUs would eliminate the need to define > additional PDU types to address the RFC 7356 cases > > I ask that you give this idea some thought. > Les, we discussed that if you look at the old thread. Yes, I originally was thinking around "hacking" CSNPs and PSNPs to be somehow "ranged". Well, having thought through some implications, the amount of possible semantic problems in such encoding in the same LSP is simply not worth it. You cannot "just add a TLV', CSNPs are not TLVs, they rely on some extra range fields, ordering, you'd have to do some hacks piggy backing in the end maybe, interspersing maybe (since otherwise you cannot order), deal with overlaps etc etc etc. All to save 1 more packet maybe. -- tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
