Just to confirm, yes, that change Peter has made removing END.T resolves
my concerns.
Thanks,
Joel
On 10/8/2020 9:38 AM, Peter Psenak wrote:
Hi Chris,
please see inline:
On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature
wrote:
Thanks for the update, a couple issues remain.
[ ] 7.1 and 8.1
The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are
defined differently (and probably incorrectly) than the other reserved
bits.
Reserved bits "MUST" be set to zero, not "SHOULD", I believe.
fixed.
[ ] 11. Implementation Status
I know you mentioned that the section should be removed, but how about
adding a note to the editor in the next revision e.g., "RFC Ed.:
Please remove this section prior to publication"?
done
[ ] 12.5. Sub-Sub-TLVs for SID Sub-TLVs
This section needs to better conform to registry creation standards (see
https://tools.ietf.org/html/rfc8126). In particular there is no guidance.
I have modified the section 12.5.
It looks like there is more discussion from Joel on this draft, so I
will hold off on submission for that to resolve.
I have removed the END.T in the latest version. The discussion with Joel
is closed.
thanks,
Peter
Thanks,
Chris.
On Sep 23, 2020, at 4:36 PM, Peter Psenak
<[email protected]> wrote:
Hi Chris,
thanks for your comments.
Please see inline (##PP):
On 18/09/2020 16:08, Christian Hoppsprotocol=
application/pgp-signature wrote:
During my review and while doing the Shepherd writeup for
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I
came up with the following comments:
4.3 - Maximum H.Encaps MSD Type:
- what is the default if not advertised?
##PP
added "or no value is advertised" as for other MSD types.
6. Advertising Anycast Property
Should "Locator that is advertised..." be:
"An SRv6 Locator that is advertised..."?
or:
"A prefix/SRv6 Locator that is advertised..."?
##PP
fixed.
7.1 SRv6 Locator TLV Format
The R fields and their handling, are not defined.
##PP
added
8. Advertising SRv6 Adjacency SIDs
"must be" "in order to be correctly applied" -> "are" and ""?
##PP
I replaced with:
Certain SRv6 Endpoint behaviors
[I-D.ietf-spring-srv6-network-programming] are associated with a
particular adjacency.
8.1. SRv6 End.X SID sub-TLV
"Other bits" -> "Reserved bits" -- labels should match
##PP
fixed.
8.2. SRv6 LAN End.X SID sub-TLV
I'm sympathetic to Bruno's comment, and so I think it would be
better to say:
Diagram: "System ID (1-6 octets)" and in text:
"6 octets" -> "System ID: 1-6 octets"
I see no reason to mess with this even if the commonly-implemented
value is 6 at
this point. IS-IS implementations that only support 6 octets are
free to only
support 6 in this sub-TLV as well. They won't be talking with other
IS-IS
routers that are configured to have a non-6 octet system ID value.
What other
extension RFCs may or may-not do WRT this doesn't really matter I
think.
##PP
I have updated the text to match what is being used in RFC8667,
section 2.2.2
"Other bits" -> "Reserved bits" -- labels should match
##PP
fixed
11. Implementation Status
Does this section need a "RFC Ed.: Please Remove prior to
publications"? It
seems pretty wrong to document current status of implementations
permanently in
an Standards Track RFC.
##PP
yes this section will be removed prior to publication. This is a
standard procedure we follow.
12. IANA Considerations
An odd space between "sub- TLV".
##PP
fixed
12.5. Sub-Sub-TLVs for SID Sub-TLVs
This section needs to better conform to registry creation standards
(see
https://tools.ietf.org/html/rfc8126).
##PP
I updated the IANA section format similar to RFC8667.
ID-NITS:
There are 19 instances of too long lines in the document, the
longest one
being 5 characters in excess of 72.
##PP
fixed.
References:
Normative:
Published: RFC 8754 draft-6man-segment-routing-header
##PP
fixed.
Out of date reference: [I-D.ietf-6man-spring-srv6-oam]
Out of date reference: [I-D.ietf-spring-srv6-network-programming]
##PP
Whenever the new version of draft-ietf-lsr-isis-srv6-extension is
published it picks the latest version, but as these drafts keep
changing the reference may get out of date quickly.
Informative:
Published: RFC 8402 draft-ietf-spring-segment-routing
##PP
fixed
thanks,
Peter
_______________________________________________
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
