Chris/Acee -
I strongly agree with Peter. There is no point in creating a protocol specific registry for behavior values which are protocol agnostic. This only adds duplication (which is NOT the same as redundancy 😊 ). What I find unfortunate is that the table in Section 10 of draft-ietf-lsr-isis-srv6-extensions-06.txt has a "Behavior Endpoint Codepoint" column. That should be removed. The legal behaviors to be advertised by IS-IS are then defined by name in column 1. If you want to find the numerical value(s) associated with that name then you refer to the registry created by draft-ietf-spring-srv6-network-programming. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Christian Hopps > Sent: Tuesday, March 10, 2020 4:51 AM > To: Peter Psenak (ppsenak) <[email protected]> > Cc: [email protected]; Christian Hopps <[email protected]>; Acee Lindem (acee) > <[email protected]>; [email protected]; Peter Psenak > <[email protected]> > Subject: Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6- > extensions-06.txt] > > > Peter Psenak <[email protected]<mailto:[email protected]>> writes: > > > Hi Acee, > > > > On 09/03/2020 14:49, Acee Lindem (acee) wrote: > >> Hi Peter, Chris, > >> > >> I agree that a number of IS-IS IANA registries have this level of > specification. For example: > >> > >> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223> > codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223> > > > > above is an ISIS specific registry and all external documents just updates > this > > protocol specific registry - e.g. the same link attribute defined in some > > external document has different value in ISIS, OSPF, OSPFv3, etc. > > > > SRv6 SID behaviors are different, because they are not ISIS (protocol) > specific > > values - they apply to other protocols (OSPF, BGP-LS, ...). As such a > > protocol > > independent registry defines them and each protocol just refers to it. > > The equivalent to these IS-IS sub-TLV registries would be to add "carried in > IS-IS sub-TLV/OSPF-Sub-TLV/etc" columns to the SRv6 protocol-agnostic > behavior registry. This does not seem the correct path to me as now you > have various transport protocols adding columns to the protocol agnostic > registry. Instead, I'm suggesting that we create protocol specific registries > along-side the behavior value registry to document the protocol specific use, > leaving a reference to these protocol registries in the behavior registry to > link > them. > > Registries are non-normative, and you're not usurping or duplicating the role > of the SRv6 behavior value registry by tracking additional protocol specific > restrictions elsewhere by using one. Registries are there to help us keep > track of stuff. In all the above cases (what goes where) it also helps make > sure people *have* normatively documented *somewhere* all the cases > they need to when adding new values/tvls. > > Do you think its better to modify the SRv6 registry directly and add protocol > specific columns to it? > > Thanks, > Chris. > (as WG member) > > > > > thanks, > > Peter > > > >> > >> Thanks, > >> Acee > >> > >> On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" > >> <lsr-<mailto:[email protected]%20on%20behalf%20of%[email protected]> > [email protected] on behalf of > [email protected]<mailto:[email protected]%20on%20behalf%20of%[email protected]>> > wrote: > >> > >> > On Mar 9, 2020, at 6:36 AM, Peter Psenak > >> <[email protected]<mailto:[email protected]>> > >> wrote: > >> > > >> > Hi Chris, > >> > > >> > On 07/03/2020 15:46, Christian Hopps wrote: > >> >> 1) I think we should have an IANA registry instead of just a table > defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06. > >> >> The registry could be cross-referenced by and to "SRv6 Endpoint > Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...). > If/when new behaviors are added they could then update where they are > supposed to be advertised in the underlying protocols. > >> > > >> > why do we need a protocol specific registry to advertise values that > are defined in another protocol independent registry? I have never seen > such a duplication. Looks completely redundant to me. > >> You are creating some new sub TLVs (End, End.X, LAN End.X), and > you > >> are restricting and directing which externally defined behaviors (values) > can > >> be advertised in which of these TLVs. The registry would keep track of this > >> (e.g., "Valid behaviors for sub-TLVs End, End.X, LAN End.X") > >> What happens when new behaviors are defined (externally), which > TLVs > >> are they supposed to be advertised in? Either the document that defines > the > >> new behavior or a related LSR document will have to indicate where this > new > >> behavior should be advertised too. That new document would update > this > >> registry to track that. Keeping track of this stuff is what registries are > >> for. > >> Your table literally looks like a template for the initial > >> content > >> of a registry. :) > >> Later in your IANA section you are updating other registries that > >> bear a striking resemblance to this (e.g., what sub-TLV types are valid to > >> advertise in what TLVs). > >> >> 2) It's odd that we are referring to the section as "Legal > >> Behaviors" in the TLV definitions, and then in the actual section using > "MAY" > >> terms and no "MUST"/"MUST NOT", but then using "Yes" and "No" in the > table. > >> > > >> > a) Legal Behavior - refers to the set of values defined in the > >> [I-D.ietf- > spring-srv6-network-programming] which can be advertised in a particular > TLV > >> > > >> > b) We can not use MUST in section 10, as all these TLVs are optional > >> What's wrong with "If this behavior is advertised it MUST only be > >> advertised in the TLV[s] as indicated by "Y" in the table below, and MUST > NOT > >> be advertised in the TLV[s] as indicated by "N" in the table below." or > >> something like that. > >> Thanks, > >> Chris. > >> (as WG member) > >> > c) Yes/No means whether the particular behavior is > >> allowed in > >> the particular END-SID TLV. > >> > > >> >> Are these suggestions or are they documenting the required > behavior? > >> > > >> > these are limitations as to which behavior is allowed to be > >> advertised > in which TLV. > >> > thanks, > >> > Peter > >> > > >> >> Thanks, > >> >> Chris. > >> > > >> > _______________________________________________ > >> > Lsr mailing list > >> > [email protected]<mailto:[email protected]> > >> > https://www.ietf.org/mailman/listinfo/lsr > >> > > >> _______________________________________________ > >> Lsr mailing list > >> [email protected]<mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> > >> > >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
