My point to Tony was that there may be subTLVs out there that normative prescribe a restriction that only a single occurrence may exist. For flex-algo that is exactly one FAD for each algorithm.
Coming back to flex-algo FAD. It is indeed easy to mix things up sometimes, however this time maybe I am not? I believe that your assumption is that the FAD for a single algorithm can never grow bigger as a 256 octets. While that is a realistic and pragmatic assumption, it may not necessary be 100% correct in all use-cases. What if the FAD use SRLGs? Each of these SRLGs are big (4 octets) in size and will consume significant subTLV space resources and many of those may overrun the size of the FAD. So if we have a theoretical network with a theoretical use-case that wants to exclude, lets say 64, SRLGs, then how would that fit into a single FAD for a single algorithm? Anyway, my point was that draft-pkaneria-lsr-multi-tlv may benefit to call-out subTLVs that by normative reference can only exist one time, in one place, like for example the flex-algo FAD. G/ -----Original Message----- From: Peter Psenak <ppse...@cisco.com> Sent: Wednesday, March 2, 2022 8:40 AM To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>; Tony Li <tony...@tony.li>; lsr <lsr@ietf.org> Subject: Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt Gunter, I'm afraid you are mixing two different things. Flex-algo draft limits the FAD advertisement for a SINGLE algo to one on any originator. It DOES NOT limit in any way how many FADs for DIFFERENT algos any originator can send. There are implementations that already support more FADs than can fit in a single TLV-242, in which case FADs are sent in multiple of them. thanks, Peter On 02/03/2022 07:23, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Tony, > > Interesting write-up. The proposal seems more operation friendly at > first sight as the alternate solutions. > > A while ago I was bumping into limitation of advertising a flex-algo > FAD, and realized that only one is allowed and more seem to be > forbidden by the draft > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#section > -5.1 > <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#sectio > n-5.1> > > The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number, > but > > a router MUST NOT advertise more than one IS-IS FAD Sub-TLV for a > > given Flexible-Algorithm. A router receiving multiple IS-IS FAD > Sub- > > TLVs for a given Flexible-Algorithm from the same originator MUST > > select the first advertisement in the lowest numbered LSP. > > Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are > explicitly restricted to only a single entry? > > G/ > > *From:*Lsr <lsr-boun...@ietf.org> *On Behalf Of *Tony Li > *Sent:* Saturday, January 22, 2022 1:57 AM > *To:* lsr <lsr@ietf.org> > *Subject:* [Lsr] Fwd: New Version Notification for > draft-pkaneria-lsr-multi-tlv-00.txt > > Hi all, > > This draft attempts to codify existing practice. If you run out of > space in a TLV, generate another TLV of the same type and continue. > Ditto sub-TLVs and sub-sub-TLVs. > > Comments welcome. > > T > > > > Begin forwarded message: > > *From: *internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > > *Subject: New Version Notification for > draft-pkaneria-lsr-multi-tlv-00.txt* > > *Date: *January 21, 2022 at 4:55:01 PM PST > > *To: *<ant...@ietfa.amsl.com <mailto:ant...@ietfa.amsl.com>>, "Chris > Bowers" <cbo...@juniper.net <mailto:cbo...@juniper.net>>, "Les > Ginsberg" <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>, "Parag > Kaneriya" <pkane...@juniper.net <mailto:pkane...@juniper.net>>, > "Shraddha Hegde" <shrad...@juniper.net > <mailto:shrad...@juniper.net>>, <t...@ietfa.amsl.com > <mailto:t...@ietfa.amsl.com>>, "Tony Li" <tony...@tony.li > <mailto:tony...@tony.li>>, "Tony Przygienda" <p...@juniper.net > <mailto:p...@juniper.net>> > > > A new version of I-D, draft-pkaneria-lsr-multi-tlv-00.txt > has been successfully submitted by Tony Li, and posted to the > IETF repository. > > Name:draft-pkaneria-lsr-multi-tlv > Revision:00 > Title:Multiple TLV Instances in IS-IS > Document date:2022-01-21 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt > <https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt> > Status: > https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ > <https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv > > <https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv> > > > Abstract: > Emerging technologies are adding information into IS-IS TLVs at a > steady pace while deployment scales are simultaneously increasing. > This causes the contents of many critical TLVs to exceed the > currently supported limit of 255 octets. Extensions such as > [RFC7356] require significant IS-IS changes that could help address > the problem, but a less drastic solution would be beneficial. This > document codifies the common mechanism of extending the TLV space > through multiple TLV instances. > > > > > The IETF Secretariat > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
