> 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
