Gunter,

On 02/03/2022 10:02, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
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.

yes, that is indeed a limitation.

While that is a realistic and pragmatic assumption, it may not necessary be 
100% correct in all use-cases.

true.


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?

you would not be able to do that. Realistically, it looks like an academical problem to me.


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.

I don't believe draft-pkaneria-lsr-multi-tlv should go into business of specifying the restriction of any particular Sub-TLVs. These restrictions are specific to Sub-TLV itself and should be covered by the specification that defines the Sub-TLV.


thanks,
Peter


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


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to