IS-IS Application-Specific Link Attributes
Note: This ballot was opened for revision 13 and is now closed.
Comment (2020-06-08 for -14)
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? - 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. - 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. Nits: Abstract: In “these link attributes for a given attribute” add a comma after both instances of attribute(s) Sec 4 2)Application. Add a space Sec 5. Missing a period at the end of “existence of link attribute advertisements”
(was Discuss) No Objection
Comment (2020-06-11 for -15)
EDIT: Thanks for setting me straight on my DISCUSS point. -- Since this document is in many parts a copy of draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between them here: https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14 Section 2: * "... expected to continue - so any discussion ..." -- change to "... expected to continue. Therefore, any discussion ..." * "... key points identified in the introduction - which are:" -- change hyphen to a comma Section 3: * "... advertisements include sub-TLVs for TLVs ..." -- Please define or expand "TLV" on first use. * Please just name the registries, rather than giving multi-line URLs to them. Section 3.1: * As with the matching OSPF document, I don't see the benefit of citing current registry contents rather than just referencing the registry. Section 4.3: * Interestingly, the entries for IPv4 are not capitalized (e.g., "interface address"), but they are for IPv6 (e.g., "Interface Address"). Section 6.3.2: * These two paragraphs read like they're in the wrong order. Sections 7.1 and 7.2: * These should refer back to Sections 4.2 and 4.3, respectively, where the new values are fully described.
Comment (2020-06-10 for -14)
I'm not sure whether this should really be a discuss ... I raised a similar concern on the OSPF document as part of a discuss, and presume consistency is helpful. 4.1. Application Identifier Bit Mask UDABM Length: Indicates the length in octets (0-8) of the User Defined Application Identifier Bit Mask. The length SHOULD be the minimum required to send all bits which are set. User Defined Application Identifier Bits have no relationship to Standard Application Identifier Bits and are not managed by IANA or any other standards body. It is recommended that bits are used starting with Bit 0 so as to minimize the number of octets required to advertise all UDAs. In section 4.1, I think that the document should also add the sentence (taken from the previous paragraph) "Bits that are not transmitted MUST be treated as if they are set to 0 on receipt." Note, that I also think that this behaviour is implicitly required from the description of UDABM Length. Regards, Rob
Comment (2020-06-10 for -14)
(revised) ** Section 4.1. As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field represents that length and has 7 bits to do that. However, the maximum number of bits needed to represent 8 is only 4 bits. What’s the thinking on those three extra bits? Should they be marked as reserved? I would have the same question for the UDABM mask. ** Section 6.2. I didn’t follow what it means to send the sub-TLV in Section 4.2 with a zero length SABM Length and UDABM Length – that is two empty bitmasks? Is that permitted? What would it convey? ** Section 8. Per “Tampering with the information defined in this document may have an effect on applications using it, including impacting Traffic Engineering.”, I have no disagreement with this statement. However, I would recommend adding a brief statement what is the security impact of “impacting Traffic Engineering”. ** Section 8. Per “This is similar in nature to the impacts associated with (for example) [RFC5305]”, what specific text in RFC5305 was envisioned? The SecCon section (Section 6) of RFC5305 contains only one sentence that points to RFC5304? ** Section 8. Consider using the editorial framing of the first paragraph of Section 13 in draft-ietf-ospf-te-link-attr-reuse to introduce how the RFC5304 applies here. ** Editorial -- Section 3. Editorial. Consider providing a reference for the registries instead of an inline URL. -- Section 4.1. The rendering of the sub-TLV diagram was split between Page 6 and 7 when this draft is read in TXT format. IMO, it would be more readable if it was on one page. -- Per Section 4.1. Editorial. Per “See the following section for a description …”, please explicitly name the section. -- Section 4.2. Typo. s/Identifer/Identifier/
Comment (2020-06-09 for -14)
I am balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense, but I do have some concerns. I found the document to be really hard to read, enough so that I largely gave up - this might just be that I'm overcommitted/grumpy this week, but the lack of punctuation in sentences like: "In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link." certainly don't help... I was largely unable to follow Section 4.1. Application Identifier Bit Mask, but as others / the responsible AD seem to get it, I'm just going to assume that my wife secretly swapped out my coffee for decaf this week, or that I'm just being dumb. As an example, I am unable to sensibly parse: "Standard Application Identifier Bits are defined/sent starting with Bit 0. ... Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.", especially the "Bits that are not transmitted" part.
Comment (2020-06-08 for -14)
Thank you for the work put into this document. I have only one nits in section 4.3: while I appreciate IPv6, there is no need to capitalize 'IPv6 Interface Address' as "IPv4 interface address" is not capitalized ;-) Special thanks to Acee, as the document shepherd he managed to represent the conflicts within the WG. I hope that this helps to improve the document, Regards, -éric
Barry Leiba Former IESG member
No Objection (2020-06-08 for -14)
My co-AD has this covered.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-06-11 for -15)
What is the scope over which the user-defined application bits are defined/allocated? And, a general question, just to check my understanding: if I do need to specify different values of a given attribute for different applications, I do that by putting multiple copies of the new sub-TLV in TLV 22/23/etc., with the flags set according to which application the contained attributes apply to? (Mostly I ask because I forget what the rules are for having multiple instances of a given TLV/sub-TLV as siblings in the same container.) Section 3.1 Maybe mention (again, I know) that this is only the subset of sub-TLVs that are used for RSVP-TE? Section 4.2 When the L-flag is set in the Application Identifier Bit Mask, all of the applications specified in the bit mask MUST use the legacy advertisements for the corresponding link found in TLVs 22, 23, 25, 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link nit(?): is this "found in sub-TLVs of TLVs 22, [...]"? attribute sub-sub-TLVs for the corresponding link attributes MUST NOT be advertised for the set of applications specified in the Standard/ User Application Identifier Bit Masks and all such advertisements MUST be ignored on receipt. Does this apply to just the (sub-)TLV with the L-flag set, or to other instances of that (sub-)TLV as well? For a given application, the setting of the L-flag MUST be the same in all sub-TLVs for a given link. In cases where this constraint is violated, the L-flag MUST be considered set for this application. editorial: I suggest "the L-flag MUST be considered set for this application for all sub-TLVs on the link in question". If link attributes are advertised associated with zero length Application Identifier Bit Masks for both standard applications and user defined applications, then any Standard Application and/or any Do we need to talk about conflicts if there are multiple such sub-TLVs for the link in question (that contain different values in the sub-sub-TLV(s))? User Defined Application is permitted to use that set of link attributes so long as there is not another set of attributes advertised on that same link which is associated with a non-zero length Application Identifier Bit Mask with a matching Application Identifier Bit set. nit: this phrasing of "matching Application Identifier Bit set" does not seem as clear as it could be that the bit for the application in question is what's checked (though I have a hard time believing that someone would accidentally misinterpret the meaning). the link attribute sub-sub-TLV code points. This document defines a sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 except as noted below. The format of the sub-sub-TLVs matches the Just to check that I'm matching things up properly: this leaves the only attributes that do not have some form of exception noted as administrative group, extended administrative group, and TE default metric? Section 4.2.1 Maximum link bandwidth is an application independent attribute of the link. When advertised using the Application Specific Link Attributes sub-TLV, multiple values for the same link MUST NOT be advertised. This can be accomplished most efficiently by having a single advertisement for a given link where the Application Identifier Bit Mask identifies all the applications which are making use of the value for that link. If I want the same maximum link bandwidth to apply to all applications, couldn't I just put it in a sub-TLV with both SABM and UDABM length of zero? (Is this somehow less efficient than setting all the bits for the applications making use of the value?) Section 4.2.3 seems to discuss using the zero-length bit mask option in the context of TE metrics... (I do note the note at the end of Section 5 about the "any application" encoding leaving ambiguous whether an application is enabled, but I don't see how this consideration differs between maximum link bandwidth and extended TE metrics.) Section 4.2.2 Maximum Reservable Link Bandwidth and Unreserved Bandwidth are attributes specific to RSVP-TE. When advertised using the Application Specific Link Attributes sub-TLV, bits other than the RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit Just to confirm: we find the risk of some future application that also wants to do reservation-like things sufficiently low that we're okay with preventing it from using these attributes? Section 4.3 What are the semantics when I specify more than one link identifier sub-TLV? They are all supposed to identify the same link, and in some case might be needed to disambiguate if there are (e.g.) multiple links to the same neighbor? Section 5 In the case of SRTE, advertisement of application specific link attributes does not indicate enablement of SRTE on that link. The Is the SRTE specification sufficiently final that we're comfortable enshrining in a (different) RFC this property of it? I note that we only list draft-ietf-spring-segment-routing-policy as an informative reference, so it's entirely possible that this document will be published as an RFC before that document is done. Section 6.1 the writing of this document. Therefore, such applications have been deployed using the legacy advertisements. The Standard Applications defined in this document may continue to use legacy advertisements for a given link so long as at least one of the following conditions is true: nit(?): do we want to say something like "may safely continue" or "may continue to use without ill effect"? Section 6.3.2 advertisements as defined in this document. Attributes for applications other than RSVP-TE MUST be advertised using application specific advertisements which have the L-flag clear. In cases where some link attributes are shared with RSVP-TE, this requires duplicate advertisements for those attributes. Maybe repeat that this duplication is required because the L flag applies per-application per-link, for all attributes? Section 6.3.4 2)Advertise all legacy link attributes using application specific advertisements with L-flag clear and R-bit set. nit: I suggest clarifying that this involves duplicate advertisements (legacy plus application-specific). Or at least, I assume it does, since step (3) is "remove legacy advertisements". Section 7.3 Note to IANA: For future codepoints, in cases where the document which defines the encoding is different from the document which assigns the codepoint, the encoding reference MUST be to the document which defines the encoding. Why not list both as the reference? Note to designated experts: If a link attribute can be advertised both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- sub-TLV of the Application Specific Link Attributes sub-TLV defined in this document, then the same numerical code should be assigned to the link attribute whenever possible. Are these notes intended to end up in the final RFC, attached to the registry, both places, or neither place? Section 7.4 policy for this registry is "Standards Action" [RFC8126]. Bit definitions SHOULD be assigned in ascending bit order beginning with Bit 0 so as to minimize the number of octets that will need to be transmitted. The following assignments are made by this document: I worry a little bit that this will encourage codepoint squatting, though in theory the user-defined bitmask should avoid the need for squatting. Section 7.5 Note to IANA: For future codepoints, in cases where the document which defines the encoding is different from the document which assigns the codepoint, the encoding reference MUST be to the document which defines the encoding. (As above, why not list both?)
Martin Vigoureux Former IESG member
No Objection (for -14)
Deborah Brungard Former IESG member
(was Discuss) Abstain
Abstain (2020-06-18 for -17)
Thanks for resolving my discuss on aligning SR terms with SPRING's work. I remain unconvinced on backward compatibility with RSVP-TE, hence my abstain ballot. Similar to other operators, I have serious concerns with operational aspects and the unfair burden placed on operators. A simple on/off control would have provided a much more elegant solution. From the discussion, this is obviously a multi-vendor agreement on their preferred way, so while I disagree, I will not stand in the way.
Magnus Westerlund Former IESG member
Abstain (2020-06-11 for -14)
Have to side with Warren that this document is hard to follow.