Ben - Top posting the open issues - as I think there are only two.
Issue #1 > > What is the scope over which the user-defined application bits are > > defined/allocated? > LES: User defined applications are - by definition - outside the scope of this document/standardization. We have simply defined the syntax of how to advertise associated bit mask. How, for example, interoperability is achieved is up to implementors. Whether they want an application to be area scoped or domain-wide is also up to them. Issue #2 > > 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. > > > You replied: " If everyone expects a sequential allocation policy, then when developing/testing, it's natural to look at "what's in the registry now" and write code that uses the next value. If three people do that at the same time, we can end up with deployed software that has conflicting interpretation of that value. (This has happened for TLS, yes, with three different extensions using the same value.) My suggestion would be to not say "SHOULD be assigned in ascending bit order", and perhaps just note (without normative language) that it is advisable to allocate from the lowest byte that has bits remaining, to allow for compact encoding. It's not actually necessary to be strictly sequential in order to minimize the number of octets transmitted." LES: I understand this concern. How about if we change policy to "Expert Review"? Les > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Friday, June 12, 2020 11:57 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-isis-te-...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) <a...@cisco.com>; > aretana.i...@gmail.com > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with > DISCUSS and COMMENT) > > Getting back to the comment section (inline)... > > On Thu, Jun 11, 2020 at 04:48:00PM +0000, Les Ginsberg (ginsberg) wrote: > > Benjamin - > > > > > > > > Thanx for your review. > > > > Responses inline. > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk via Datatracker <nore...@ietf.org> > > > > > Sent: Thursday, June 11, 2020 12:42 AM > > > > > To: The IESG <i...@ietf.org> > > > > > Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; > > > Acee > > > > > Lindem (acee) <a...@cisco.com>; aretana.i...@gmail.com; Acee Lindem > > > > > (acee) <a...@cisco.com> > > > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with > DISCUSS > > > > > and COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-isis-te-app-14: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > > email addresses included in the To and CC lines. (Feel free to cut this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > ---------------------------------------------------------------------- > > > > > > > > > > My apologies if this is super-obvious and I'm just missing it ... but > > > > > Section 4.3 dictates that part of the value for the application-specific > > > > > SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)". Where > > > > > are these defined? (We don't exactly say that we're reusing the > structure > > > > > from, e.g., TLV 138, which I note refers to the seventh octet as > > > > > "pseudonode number", not "pseudo-node ID". Similarly for the > > > > > interpretation of the SRLG value(s). Do we just need to reference that > > > > > we're reusing the encoding from RFC 5307 (or similar) or are some > > > > > changes needed? > > > > > > > > > [Les:] “system ID” and “pseudo-node ID” derive from the IS-IS base > specification [ISO 19589] > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > ---------------------------------------------------------------------- > > > > > > > > > > What is the scope over which the user-defined application bits are > > > > > defined/allocated? > > > > > > > > [Les:] Sorry – I do not understand this question. > > The "user-defined" application bits are, well defined by the user. In > order to make sure that the bits are interpreted by the recipient in the > way that the sender intends, there needs to be agreement among all parties > in question as to which bits map to which applications. By its nature this > user-defined mapping is deployment-specific (and presumably not IS-IS > area-specific given Level 2 routing), but I would appreciate an explicit > statement about what the expected "deployment boundary" is where these > user-defined bits have a specific meaning. > > > > > > > > > > > > > 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.) > > > > > > > > > [Les:] You are correct. > > > > Whether multiple occurrences of the same sub-TLV is allowed is codepoint > specific. > > > > Section 4.2 states: > > > > > > > > “Multiple Application Specific Link Attribute sub-TLVs for the same > > > > link MAY be advertised.” > > Thanks for confirming. > > > > > > > > Section 3.1 > > > > > > > > > > Maybe mention (again, I know) that this is only the subset of sub-TLVs > > > > > that are used for RSVP-TE? > > > > > > > > [Les:] The point of Section 3.1 is to list the legacy sub-TLVs which are > relevant to this draft. There are other sub-TLVs defined in > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- > codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 > > > > which are not relevant – but categorizing them as “not used by RSVP-TE” > wouldn’t be completely accurate. For example, endpoint addresses > (codepoints 6,8,12,13) are quite relevant to RSVP-TE as they are required to > uniquely identify the link – but they aren’t in the set of sub-sub-TLVs being > defined. > > Fair point. I was trying to focus on the "this is not all sub-TLVs" part, > in case a reminder of that is helpful. (It's certainly not required.) > > > > > > > > > > > > > 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, [...]"? > > > > [Les:] The top level TLVs are the containers in which link advertisements > are present. A given link advertisement consists of the fixed portion of the > TLV and a set of sub-TLVs. > > > > I think the existing text is correct. > > Okay. I was just noticing that we use the same "found in TLVs" > construction for the 22/23/... case and the 138/139 case, even though the > specific sub-structure in question takes a different form between those > groupings. > > > > > > > > > > > > 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? > > > > > > > > > [Les:] The scope is the set of sub-TLVs associated with the same link and > the same application(s). > > Okay, I think that matches what I expected, from reading this text. > > > > > > > > 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". > > > > > > > > > [Les:] This seems redundant given the first sentence of the paragraph. > > > > ?? > > > > > > > > Note that if L-flag is set, no link attribute advertisements are permitted > > in > the sub-TLV – so there is no reason to have multiple sub-TLVs for the same > link/application in such a case. > > Agreed, there is no reason to do so. Part of my job as SEC AD is to make > sure that the proper behavior is clear (and not harmful) if someone decides > to do so anyway, triggering an edge case. :) > This particular edge case doesn't seem especially risky, so I'm happy to > leave this as-is if you want to leave it. > > > > > > > > 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))? > > > > > > > > > [Les:] An earlier paragraph discusses conflicts and states: > > > > > > > > “In cases where conflicting values for the same > > > > application/attribute/link are advertised all the conflicting values > > > > MUST be ignored by the specified application.” > > > > > > > > I think that covers the “any application” case as well. > > I think I was looking at that text when I wrote this comment, and wanting > the language used for the explicit-bitmask and zero-length-bitmask cases to > match as closely as possible. But I do not insist. > > > > > > > > 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). > > > > > > > > > [Les:] I also have trouble seeing how this could be misinterpreted. > > > > Do you have a suggestion? > > I think my suggestion would be s/with a matching Application Identifier Bit > set/that has that application's bit set/. Leaving it as-is should be fine, > too -- I was a bit prone to confusion when I was reading this just due to > my own mental state. > > > > > > > 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? > > > > > > > > > [Les:] The points being made in Sections 4.2.x are: > > > > > > > > 1)Maximum Bandwidth is not application specific > > > > 2)Reserved/Unreserved bandwidth are RSVP-TE specific > > > > 3)Extended TE Metrics MAY be application specific, but there are > challenges in doing application specific performance measurement > > > > > > > > Sooo, you are following along quite well, but in the case of Extended TE > Metrics I would not use the term “exception”. > > Understood. I was just trying to match up the "except as noted below"; > "exception" is not the best word to indicate that. > > > > > > > > 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.) > > > > > > > > > [Les:] You are correct. I have added: > > > > > > > > “It is also possible to advertise a single advertisement with zero length > SABM and UDABM so long as the constraints discussed in Section 4.2 and > Section 6.2 are acceptable.” > > Thanks! (My main goal here was to avoid having the text diverge between > sections when there is not any functional difference.) > > > > > > > > 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? > > > > > > > > [Les:] It would require a definition of an alternative RSVP protocol. > > If/when > that occurs a revision to this restriction could be specified. > > Okay, thanks for confirming. > > > > > > > > > > > > > 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? > > > > > > > > > [Les:] It might be useful to include both IPv4 and IPv6 addresses. > > > > It does not seem useful to include Link Identifiers and IPvX addreesses – > though not in and of itself harmful. > > > > > > > > I have added: > > > > > > > > “Multiple occurrences of the same identifier type MUST NOT be present.” > > Okay, thanks. I assume this feels pretty natural to people that run this > stuff, and recognize that there's a lot of common knowledge that I don't > have :) > > > > > > > > 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? > > > > [Les:] This property exists – largely because existing RSVP-TE > > specifications > never defined a standard definition of enablement. Implementations > therefore had to come up with an ad hoc solution. > > > > We are simply reflecting the deployed reality. > > Okay. > > > > > > > > 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. > > > > > > > > > [Les:] My understanding of this oft discussed point is that the choice of > Informative vs Normative Reference depends on the relationship between > the two documents – not the current document status of the referenced > document. > > > > In this case nothing in this draft depends on content in the SR Policy > > draft, > but it is informative in providing context for the content of this draft. > > > > ?? > > I agree that it's correctly characterized as an informative reference. I > was just noting that a consequence of that characterization, > draft-ietf-isis-te-app could be published/finalized before > draft-ietf-spring-segment-routing-policy, which introduces a (theoretical) > risk that we make a statement about the SR behavior that later becomes > false. Given your explanation, I agree this risk seems purely theoretical > in this case, so we shouldn't do anything about it. > > > > > > > > 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"? > > > > > > > > > [Les:] There are limitations (discussed immediately below in the draft) to > when this can be done. > > > > I am comfortable with the current text. > > Okay. > > > > > > > > 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? > > > > > > > > > [Les:] Perhaps this is a matter of style. I prefer that a draft confine > > itself to > normative statements whenever possible. > > > > You are suggesting that we should add some explanation – but as this > aspect of L-bit is clearly defined earlier in the document I would prefer not > to > distract from the normative statement by adding an explanation which has > already been provided. > > > > I am open to revision if you really think this is important – so let me > > know if > you feel strongly about this. > > This is an editorial matter, and your preference reigns. > > > > > > > > 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". > > > > > > > > > [Les:] I have added “At this point both legacy and application specific > advertisements are being sent.” > > > > > > > > > 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? > > > > > > > > [Les:] Current format in the registries is to have only one reference. > > > > Changing that is out of scope for this document. > > > > FWIW, I am fine with a single reference. > > Okay, I didn't know that the registry format was restricted in that way. > > > > > > > > > > > > > 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? > > > > [Les:] These notes will be part of the final RFC. > > > > The RFC number will also be listed in the “Reference” at the beginning of > the registry. For example, currently we have: > > > > > > > > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- > codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 > > > > … > > > > Reference > > > > [RFC5305][RFC5316][RFC7370][RFC8668] > > Sounds good. > > > > > > > > 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. > > > > > > > > > [Les:] Not sure why you are worried nor what you are suggesting should be > changed. > > > > ?? > > If everyone expects a sequential allocation policy, then when > developing/testing, it's natural to look at "what's in the registry now" > and write code that uses the next value. If three people do that at the > same time, we can end up with deployed software that has conflicting > interpretation of that value. (This has happened for TLS, yes, with three > different extensions using the same value.) My suggestion would be to not > say "SHOULD be assigned in ascending bit order", and perhaps just note > (without normative language) that it is advisable to allocate from the > lowest byte that has bits remaining, to allow for compact encoding. It's > not actually necessary to be strictly sequential in order to minimize the > number of octets transmitted. > > Thanks, > > Ben > > > > > > > > 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?) > > > > > > > > [Les:] See my response above. > > > > > > > > Les > > > > > > > > > > > > > > > > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
