On 10/03/2020 12:50, Christian Hopps wrote:
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?
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
Thanks,
Chris.
(as WG member)
thanks,
Peter
Thanks,
Acee
On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" <[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
