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

From: Christian Hopps <[email-masked]>
Date: Sat, 7 Mar 2020 09:46:36 -0500

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.

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.

Are these suggestions or are they documenting the required behavior?

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Sat, 7 Mar 2020 09:49:49 -0500

Oops,

That was "Speaking as a WG member".

> On Mar 7, 2020, at 9:46 AM, Christian Hopps <[email-masked]> wrote:
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 9 Mar 2020 11:36:24 +0100

Hi Chris,

> 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 wh…

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.

> 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…

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

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

---

From: Christian Hopps <[email-masked]>
Date: Mon, 9 Mar 2020 08:26:30 -0400

> On Mar 9, 2020, at 6:36 AM, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Chris,
> 
> 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).

> 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
> 

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.
> 
> these are limitations as to which behavior is allowed to be advertised in which TLV.
> thanks,
> Peter
> 
>> Thanks,
>> Chris.
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 9 Mar 2020 13:49:45 +0000

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

Thanks,
Acee

On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    Thanks,
    Chris.
    (as WG member)

---

From: Peter Psenak <[email-masked]>
Date: Tue, 10 Mar 2020 11:09:49 +0100

Hi Acee,

> 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.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 10 Mar 2020 11:10:33 +0100

Chris,

On 09/03/2020 13:26, Christian Hopps wrote:
> 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. 

yes.

> That new document would update this registry to track that. Keeping track of this stuff is what registries are for.
> 

I still do not see a need for an ISIS (or any protocol specific) registry.

> 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.\

sure, I can update the text as above.

thanks,
Peter

---

From: Christian Hopps <[email-masked]>
Date: Tue, 10 Mar 2020 07:50:52 -0400

Peter Psenak <[email-masked]> writes:

> 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)

>>                > On Mar 9, 2020, at 6:36 AM, Peter Psenak
>> <ppsenak=[email-masked]> wrote:
>>      >
>>      > Hi Chris,
>>      >
>>           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.
>>           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.
>>      >
>>           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)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 11 Mar 2020 00:06:52 +0000

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-masked]> On Behalf Of Christian Hopps

> Sent: Tuesday, March 10, 2020 4:51 AM

> To: Peter Psenak (ppsenak) <[email-masked]>

> Cc: [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee)

> <[email-masked]>; [email-masked]; Peter Psenak

> <ppsenak=[email-masked]>

> Subject: Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-

> extensions-06.txt]

> Peter Psenak <[email-masked]<mailto:[email-masked]>> writes:

> >> 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

> specific

> 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?

> >> On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" <lsr-<mailto:[email-masked][email-masked]>

> [email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

> >> <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>> 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

> >>           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

> >>           Your table literally looks like a template for the initial content

> >> of a registry. :)

> >> 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

> >> advertised in the TLV[s] as indicated by "Y" in the table below, and MUST

> NOT

> >>                > 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?

> >>      > [email-masked]<mailto:[email-masked]>

> >>      [email-masked]<mailto:[email-masked]>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Mar 2020 04:24:16 -0400

> On Mar 10, 2020, at 8:06 PM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Chris/Acee -
>  

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]

> > >> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
> > codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> > >
> > >> On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" <lsr-
> > [email-masked] on behalf of [email-masked]> wrote:
> > >>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 11 Mar 2020 11:10:09 +0100

> Do you think its better to modify the SRv6 registry directly and add protocol specific columns to it?

no.

I believe what we have in SRv6 ISIS draft is sufficient. We are 
referring to a protocol independent registry and we specify which ISIS 
TLVs can carry which values out of that registry. I don't believe we 
need an ISIS registry to do that.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Wed, 11 Mar 2020 11:13:27 +0100

> | C     | New Behavior C | Y     | N       | N           | RFC-C000  |

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.

thanks,
Peter

---

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Mar 2020 06:38:37 -0400

> On Mar 11, 2020, at 6:13 AM, Peter Psenak <[email-masked]> wrote:
> 
> 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]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 11 Mar 2020 14:38:28 +0000

Chris -

> 
> 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?
> 
[Les:] The difference for me is that the definition of sub-TLVs associated with the related set of TLVs is scattered across multiple RFCs. The additional information in the registry allows us to find this information in one place.
Here, there is only one relevant IS-IS draft on this technology (SRv6). If the set of behaviors which can be advertised in IS-IS changes, then an additional IS-IS document (or a bis) will be written - and it likely would be required for other reasons.

We still may not agree - but I hope we at least understand each other better.

   Les

---

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Mar 2020 11:52:27 -0400

> On Mar 11, 2020, at 10:38 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Chris -
> 
> 
>> 

Is the SR network programming document expected to respin a -bis for adding a behavior?

Anyway, unless someone else thinks this is important, I guess we can just revisit it when the next SR End behavior gets added and we're faced with re-spinning this document, the OSPF companion document, and whatever other protocols support documents for advertising the new behavior, in order to support it (rather than e.g., it just going directly in a base document or a combined protocols document and updating a couple registries).

Thanks,
Chris.
[as WG member]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Mar 2020 13:41:41 -0400

It does seem to me that using a registry to capture the relationship 
between the OSPF or IS-IS advertisement (TLV, sub-TLV, ...) and the SR 
behavior (as defined in the NP registry and subsequent additions) is 
useful.  I would not want to have to respin the base draft to add 
additional behaviors.  We use registries for a reason.

Now, if the advertisement registry has a note column, we could use that 
to record the information.  As far as I know the current registries are 
not well-structured for such auxiliary information.

Yours,
Joel

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Mar 2020 19:16:38 +0000

I looked at this again and the long Email thread and agree with Peter, Les, and Joel that we don't need a protocol specific registry for the Endpoint behaviors and associated SIDs. 
Thanks,
Acee

On 3/11/20, 1:42 PM, "Lsr on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    
    Yours,
    Joel

---

From: Christian Hopps <[email-masked]>
Date: Fri, 13 Mar 2020 07:05:33 -0400

> Here, there is only one relevant IS-IS draft on this technology (SRv6). If the set of behaviors which can be advertised in IS-IS changes, then an additional IS-IS document (or a bis) will be writte…

I believe you're saying that in the future we will have new documents (if you don't respin) that define the legal behaviors to be advertised. And yet that's how I read your first paragraphs reason for this info being justified for sub-TLVs (where they are advertised being spread around multiple RFCs). I don't see how they are different, which makes me think I am misunderstanding what your saying.

I'm happy to move on from this surprisingly contentious ask, as we could always back-add the registry in the next document that gets published.

Thanks,
Chris.
[as WG member]

---

From: Peter Psenak <[email-masked]>
Date: Mon, 23 Mar 2020 17:19:11 +0100

Hi Chris,

> sure, I can update the text as above.

your proposed text has been added to the 07 version that has been posted 
today.

thanks,
Peter