On Thu, May 21, 2020 at 2:28 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
