Re: [Tsv-art] Tsvart last call review of draft-ietf-isis-te-app-13

[Kyle Rose <[e-mail]>]

On Thu, May 21, 2020 at 2:28 AM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> > * Update language?
> >
> > There are several places in which it is possible that normative language
> in
> > prior RFCs is revised. For example, in section 6.1, the last paragraph
> states:
> >
> >   New applications which future documents define to make use of the
> >   advertisements defined in this document MUST NOT make use of legacy
> >   advertisements.
> >
> > This looks like it was written in such a way as to avoid requiring such
> > updates, but it would be good to confirm that there is no normative
> language
> > in
> > older documents that would conflict with this requirement.
> >
> [Les:] For applications which preexisted the writing of this draft (the
> ones defined in Section 7.4) there are existing deployments which use
> legacy advertisements.
> Transitioning to use new advertisements has to account for partial
> deployment of such support.
> And the transition has to be managed by the network operator using knobs
> provided by implementations. This is onerous - but unavoidable in these
> cases.
>
> For new applications we want to avoid this complexity/pain. So we specify
> new applications MUST use the new advertisements from day ONE.
>
> As these are new applications there is no legacy to deal with and no
> existing specification which would be in conflict.
>

That's what I figured. Is it the case that new standardized applications
require an RFC? If so, I think this is fine.


> > * Encoding
> >
> > In section 4.1, the bit masks are defined with a 7 bit length field for
> which
> > only 4 bits are useful (values 0-8). It may make sense to keep the 3
> high order
> > bits as "reserved" and set to zero, but either way it would be nice to
> > understand the justification for whatever design decision is made.
> >
> > You go to some length to save space (e.g., a zero-length SABM means "all
> > applications") but always include an octet for UDABM length, which I
> > presume
> > will be zero outside the lab in most cases. How much does an extra octet
> > cost?
> > If it's a lot, you could use the three high-order bits to represent the
> first
> > three applications (RSVP-TE, SRTE, and LFA) and save yourself an octet
> until a
> > fourth application appears.
> >
> > For that matter, how likely are you to get to 256 standardized
> applications
> > under IS-IS?
> >
> [Les:] The limitation for the xABM length to be no more than 8 bytes was
> introduced only recently based on a review comment.
> The concern was that without a limit, it would be theoretically possible
> for the ABM itself to consume the full sub-TLV space, leaving no room for
> the actual link attribute advertisements.
> So we placed a maximum length to avoid this potential issue.
> As each application consumes one bit, with an 8 byte maximum length we can
> support 64 applications.
>
Sigh... yes, math is hard.


> This seems more than we will ever get to - but if anyone in the WG thinks
> this is not large enough they should speak now so we can increase the
> maximum.
>

I suspect even 64 is safely more than you'll need, but if not there's
always the possibility of a new TLV later on. :-)


> There are existing implementations of this draft which have been deployed.
> Changing the bit positions as you suggested would not be backwards
> compatible.
> I do not think the small space savings would be worth the trouble.
>

Understood, though I will point out that this illustrates the potential
harm in deploying something hard to change prior to standardization.
Thankfully, IS-IS is not interdomain, meaning that any such change would
impose costs only on those who deployed early.

> > In effect, use of legacy advertisements vs. app-specific advertisements
> is
> > all-or-nothing. If that's the case, wouldn't a top-level TLV specifying a
> > legacy mask for applications be more compact, less redundant, and further
> > reduce the overall number/size of advertisements?
> >
> [Les:] The information being advertised here (link attributes) is
> necessarily associated with a top level TLV describing a link to a neighbor
> (TLVs 22, 23, 25, 141, 222, and 223) . Without that context the link
> attribute information is meaningless.
>

Yes, this makes sense, and probably would have been obvious were I more
familiar with IS-IS and link state routing in general.
Thanks,
Kyle