Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Christian Hopps <[e-mail]>]

> On Mar 10, 2020, at 8:06 PM, Les Ginsberg (ginsberg) <ginsberg=[e-mail]> 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 <[e-mail]> On Behalf Of Christian Hopps
> > Sent: Tuesday, March 10, 2020 4:51 AM
> > To: Peter Psenak (ppsenak) <[e-mail]>
> > Cc: [e-mail]; Christian Hopps <[e-mail]>; Acee Lindem (acee)
> > <[e-mail]>; [e-mail]; Peter Psenak
> > <ppsenak=[e-mail]>
> > Subject: Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-
> > extensions-06.txt]
> >
> >
> > Peter Psenak <[e-mail]> 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-
> > [e-mail] on behalf of [e-mail]> wrote:
> > >>
> > >>                > On Mar 9, 2020, at 6:36 AM, Peter Psenak
> > >> <ppsenak=[e-mail]> 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
> > >>      > [e-mail]
> > >>      > https://www.ietf.org/mailman/listinfo/lsr
> > >>      >
> > >>           _______________________________________________
> > >>      Lsr mailing list
> > >>      [e-mail]
> > >>      https://www.ietf.org/mailman/listinfo/lsr
> > >>
> > >>
> > >>
> > >>
>  
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr