Chris,
On 09/03/2020 13:26, Christian Hopps 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.
yes.
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. :)
I still do not see a need for an ISIS (or any protocol specific) 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.\
sure, I can update the text as above.
thanks,
Peter
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
