> On Mar 11, 2020, at 6:13 AM, Peter Psenak <[email protected]> wrote: > > On 11/03/2020 09:24, Christian Hopps wrote: >>> 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? > > I'm not saying above is not useful, otherwise it would not be in the draft in > a first place. What I'm saying is that we do not need a registry for it, it's > sufficient to have a table we have, I believe.
Do you think we should get rid of the "used in" columns in the IS-IS TLV and sub-TLV registries? The documents that define those TLVs and sub-TLVs already indicate which PDUs and TLVs they go in, so why do we need that info in the registry? Thanks, Chris. [as WG member] > > thanks, > Peter > >>> 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
