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