Also inline. On Sat, Jun 13, 2020 at 05:01:41PM +0000, Les Ginsberg (ginsberg) wrote: > Ben - > > Inline. > > > -----Original Message----- > > From: Benjamin Kaduk <[email protected]> > > Sent: Friday, June 12, 2020 9:15 PM > > To: Les Ginsberg (ginsberg) <[email protected]> > > Cc: The IESG <[email protected]>; [email protected]; lsr- > > [email protected]; [email protected]; Acee Lindem (acee) <[email protected]>; > > [email protected] > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with > > DISCUSS and COMMENT) > > > > On Fri, Jun 12, 2020 at 07:45:00PM +0000, Les Ginsberg (ginsberg) wrote: > > > 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. > > > > Yes. > > > > > We have simply defined the syntax of how to advertise associated bit > > mask. > > > > But if my implementation is built around (say) the meanings of the bits in > > the bit mask being local to a single area, and your implementation is built > > around them having meaning local to a full domain, when you try to send me > > something from out of area it's not going to work so well. Even without > > saying what any given bit means, we can still say that "all systems in the > > same <X> need to interpret each bit in the same way. What is the smallest > > <X> such that deployment is safe? > > > > > 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. > > > > I think leaving the question of area vs. domain up to the application is a > > recipe for interop failures. > > > > (A similar question presumably applies to the OSPF document, though I > > didn't get a chance to actually review that one.) > > > > [Les:] If interoperability between implementations is a concern, then the > obvious choice is to use a standardized application. > > Placing limits on the scope of a user defined application is both unnecessary > and unenforceable. I say "unenforceable" because, if you have a mixed vendor > network, there is no guarantee that User Bit X means the same thing to both > implementations. And since I cannot tell the identity of the implementation > originating an advertisement, I cannot tell if the User Bit advertised in > Area Scoped LSPs (Level-1 in IS-IS speak) has the same meaning as the same > bit advertised in Domain-wide LSPs. So I cannot detect when a violation > occurs.
I see your point about being able to "detect a violation". That you are focusing on this aspect makes me suspect that my point did not come across quite as intended, though. I don't feel a need to make a normative statement like "User Bits MUST be agreed upon at Domain-wide scope", since if anything that's trying to place a requirement on the operator, and our role is mostly just to inform the operator so they can make their own decisions. As such, I'd be thinking more along the lines of "when user-defined bits are used, all routers that receive such information have to agree on their meaning, or breakage can occur. Minimally, this implies that all machines in a given area need to use the same mapping of user-bit to application, and it's safest to ensure agreement across the entire domain." (But with more wordsmithing, of course.) > To me, User Defined Application is a space for implementations to do whatever > they choose - subject to the syntax rules defined in the draft. Maybe they > use it as an experimental space for something they will eventually > standardize. Maybe they use it to implement a proprietary application that > they have no intention of standardizing. As it does not impact operation of > the standard applications, I see no reason or benefit for the draft to impose > restrictions. It's also interesting to me that you are picturing this as a per-implementation thing -- the "user" in the name had me expecting it to be something that implementations expose as a configuration knob, so that the operator would control what bit maps to which application. If there is such a configuration knob then our guidance to the operator gains importance; if not, then any discussion of how to choose user-bits would only be targetted to the implementation, in which case your stance of not saying anything makes a fair bit of sense. > As context, User Defined was added based on comments received from some WG > members. It isn't needed to support the goals of the draft. It is an option > that at least some members felt was desirable to have. It does seem useful to me, to have a defined path for experimentation that cannot conflict with the standards-assigned space. > > > > 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"? > > > > I think that's moving on an orthogonal axis -- the TLS registry where we > > had three extensions squatting on the same codepoint is a registry with > > expert review. (My expectation is that Standards Action is actually safer > > in this regard than Expert Review would be, since there's enough points of > > coordination in the process of advancing a standard that someone is likely > > to notice the issue, but I don't have any hard data or proof to support > > that expectation.) > > > [Les:] Standards action is limited (by > https://tools.ietf.org/html/rfc8126#section-4.9 ) to Standards track and BCP. > This does not allow for Experimental track. So I think it is better to move > to "Expert Review". > > > To throw another concrete suggestion out there for focusing comments, > > perhaps > > > > OLD: > > > > 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. > > > > NEW: > > > > Allocating all bits from the first octet before allocating any bits from > > the second octet, etc., provides for the smallest possible encoding when > > transmitted. > > [Les:] OK. How about: > > "Bit definitions SHOULD be assigned such that all bits in the lowest > available octet are allocated before assigning bits in the next octet. This > minimizes the number of octets that will need to be transmitted." > > ?? Ship it :) Thanks, Ben > Les > > > > > (After all, who is supposed to adhere to the original's "SHOULD"? The IETF, > > as it undertakes its Standards Actions? Our track record on one RFC > > constraining what future RFCs do is hardly perfect.) > > > > -Ben _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
