> On Mar 10, 2020, at 8:06 PM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > 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 😊 ).
This was and is not my suggestion. > 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. Or remove the names and just leave the values, whatever, since mapping names or registering values isn't the point of the table you could do either. > The legal behaviors to be advertised by IS-IS are then defined by name in > column 1. This table isn't "the legal value to be advertised in IS-IS" it's "Which sub-TLV in IS-IS are allowed to advertise a given behavior value". Again this table looks just like other IS-IS sub-TLV registries where we list which values are allowed in which TLV. To be clear here *IF* SR were an IS-IS only thing we would have a registry that looked like this: ** IF SR were only an IS-IS thing ** | Value | Description | [End] | [End.X] | [LAN End.X] | Reference | | A | Behavior A | Y | N | N | RFC-A000 | | B | Behavior B | N | Y | Y | RFC-B000 | | C | New Behavior C | Y | N | N | RFC-C000 | | ... | ... | | | | | But it's not, so we have protocol agnostic SR behaviors ** SR (protocol agnostic -- already exists) ** | Value | Name/Description | Reference | | A | Behavior A | SR-RFC-A111 | | B | Behavior B | SR-RFC-B111 | | C | New Behavior C | SR-RFC-C111 | | ... | ... | | | | | | And then we have IS-IS restrictions on where those are advertised. ** IS-IS "legal values" registry ** | Name/Description | [End] | [End.X] | [LAN End.X] | Reference | | Behavior A | Y | N | N | LSR-RFC-A222 | | Behavior B | N | Y | Y | LSR-RFC-B222 | | Behavior C | Y | N | N | LSR-RFC-C222 | | ... | | | | | Name/Description or Value whatever you want in column 1 as long as it is always going to be unambiguous. If you're saying this is not useful, do you perhaps also think our current "where to advertise" columns in our sub-TLV registries are useless? > 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. Yes, but again, I wasn't talking about this. Thanks, Chris. [as WG member] > > 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]> 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- > > 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- > > [email protected] on behalf of [email protected]> wrote: > > >> > > >> > On Mar 9, 2020, at 6:36 AM, Peter Psenak > > >> <[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] > > >> > https://www.ietf.org/mailman/listinfo/lsr > > >> > > > >> _______________________________________________ > > >> Lsr mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/lsr > > >> > > >> > > >> > > >> > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
