Lee, Responses inline.
On Mon, Jun 8, 2020 at 9:57 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I know very little about this, but just checking: > > - I trust that a network that mixes routers that use application > attributes, > > and not, will not lead to long-term routing loops in spite of them not > having a > > common picture of the network? > > > [Les:] Traffic engineering policies are calculated by the headend/ingress > node. Based on the calculation a set of forwarding instructions are imposed > on a packet (e.g., MPLS labels) which direct forwarding of the packet > towards the destination. Intermediate nodes are unaware of the policy - > they simply forward the packet based on the forwarding instruction. So the > fact that intermediate nodes may not themselves process link attribute > advertisements does not introduce loops. > I see, thanks, that makes sense. > > > - It is odd that a link that advertises a zero-length flags field means > support > > for RSVP-TE is “ambiguous” (sec 5). What are the implications of this? > When > > is > > it OK to use a zero-length flags field given this ambiguity? In a > standard, can > > we not decide on a meaning to eliminate the uncertainty? I would > appreciate > > some language here to answer at least the first two questions. > > > [Les:] The use of zero length application bit mask is discussed in Section > 4.2 and Section 6.2. This can be convenient in that one set of link > attribute advertisements can be used for all applications and as > applications are enabled/disabled the advertisement of link attributes does > not have to be modified in any way. But it can also lead to unintended use > of link attribute advertisements by an application. This latter point is > discussed in Section 6.2. > > Section 5 is discussing whether the presence of link attribute > advertisements serve to indicate enablement of a given application on the > associated link for the three applications defined in this draft (RSVP-TE: > yes, SRTE and LFA: no). > The text in Section 5 that you ask about indicates that in the special > case where zero length Application Bit Mask is associated with link > attribute advertisements, for an application (RSVP-TE) which utilizes link > attributes to indicate application enablement, the lack of an explicit > application bit introduces ambiguity as to whether the application should > be considered enabled on the link or not. This is why we include the > cautionary statement: > > " This needs to be considered when making use of the "any application" > encoding." > > So I believe the draft does address your concerns. > Thank you for clarifying. Your explanation conforms with my understanding from reading the document. Maybe this obvious to people in the field, but under what circumstances would I decline to use "any application" encoding? I think the draft indicates the first level implications (we don't have confirmed enablement) but under what circumstances is that OK? If there is out of band information that it's globally enabled? Or can RSVP-TE function if it turns out some aren't enabled? > > > - as the TSVart review points out, the length field wastes 3 bits of 7 > because > > the maximum length is 8. You could reserve them or even use them to > > encode > > these three legacy applications. > > > [Les:] As indicated in my previous response to this comment, the > limitation to 8 bytes maximum was put in late based upon a review comment.. > There are already implementations of the draft deployed. Changing the > format of the fields would result in backwards compatibility issues with > these early implementations. The very minor savings in encoding (1 byte maxi > mum) is not significant enough to warrant introducing backwards > compatibility issues. > I do appreciate that you (and Kyle) have frugality in mind. > Yeah, transport guys are famous for fighting for years over a bit :-) > > > Nits: > > > > Abstract: > > In “these link attributes for a given attribute” add a comma after both > > instances of attribute(s) > > [Les:] Done. > > > > > Sec 4 2)Application. Add a space > > [Les:] Apologies - but I cannot find an instance in which a space is > needed and not already present. Perhaps you could provide more context so I > could locate the specific sentence involved. I did search for all > occurrences of "Application". > It's the fifth line down here: https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-14#section-4
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
