Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22

[Alvaro Retana <[e-mail]>]

On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) ([e-mail])
wrote:

Les:

Hi!

Thanks for the update.

I have a couple of comments on your replies — no showstoppers.  However, it
looks like my original comments were truncated; I added the remaining
comments at the end.

I am starting the IETF LC.  The remaining comments can be addressed with
any other comments that are received during LC.

Thanks!!

Alvaro.

...

> 445 V-Flag: Value flag. If set, then the Adj-SID carries a value.

> 446 By default the flag is SET.
>
> [minor] Is the description the same at the V-Flag in §2.1? If so, then
> indicating that, or at least also pointing out here that the value is
> carried instead of an index would be helpful.
>
[Les:] Done.

I think you missed this one.


...

> 544 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as
> 545 defined in [ISO10589].
>
> [major] Which System-ID?
>
[Les:] Text has been altered to indicate it is the system-id of the
neighbor.

> [major] "6 octets of...length "ID Length"" ??
>
[Les:] Done.

I was trying to point out that the text is confusing where it says that the
System-ID, which is (from the figure) a 6-octet field, is represented by "6
octets…of length "ID Length”.  Is the length 6 octets or “ID Length”?

ISO10589 says: "System identifier — a variable length field from 1 to 8
octets”…RFC1195 suggests this: "N is a system identifier. In the level 1
algorithm, N is a 6 octet ID for OSI end systems, a 7 octet ID for routers,
or an 8 octet IP Internal Reachability Information entry.”  For both cases,
it the length of the System ID is > 6 octets, which bits are expected to be
in the sub-TLV?  If the system ID is < 6 octets (which I doubt, but just to
cover ISO10589), what next?

Maybe I’m just confused...

Do you want to specify any check to make sure that the System ID in fact
corresponds to a valid neighbor?


...

> 812 The other flags defined in Section 2.1 are not used by the Mapping
> 813 Server and MUST be ignored at reception.
>
> [major] How does the receiver know that the sub-TLV was originated by a
> Mapping Server? Is it the case that it would originate a Binding TLV?
> IOW, would the other flags always be ignored when the sub-TLV is included
> in the Binding TLV (but not other TLVs)? Does this apply also to the
> Multi-Topology SID/Label Binding TLV (§2.5)?
>
[Les:] "Yes" to all of your questions.

Please add some text to clarify.

...

> 1075 3.3. SR Local Block Sub-TLV
>
> 1077 The SR Local Block (SRLB) Sub-TLV contains the range of labels the
> 1078 node has reserved for local SIDs. Local SIDs are used, e.g., for
> 1079 Adjacency-SIDs, and may also be allocated by other components than
> 1080 IS-IS protocol. As an example, an application or a controller may
> 1081 instruct the router to allocate a specific local SID. Therefore, in
> 1082 order for such applications or controllers to know what are the local

> 1083 SIDs available in the router, it is required that the router
> 1084 advertises its SRLB.
>
> [nit] s/than IS-IS protocol/than the IS-IS protocol

[Les:] Done.

>
>
> ...
> 1122 The originating router MUST NOT advertise overlapping ranges.
>
> [major] What should the receiver do if the ranges overlap? I'm assuming
> the same thing as what was specified before...please be specific.
>
[Les:] Similar question is relevant to SRGB and the behavior has been
specified in
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-18#section-2.3
and this draft references it. I would do the same here, but the SR MPLS
draft does not specify behavior for SRLB - even though the referenced
section is entitled "Segment Routing Global Block and Local Block". Best
solution I would think is to update SR MPKS draft so that a reference to it
could be added here.

Please go ahead and add the reference.  I’ll make sure to address the
issues when that document comes to the IESG (should be soon as it already
finished IETF LC).


...

> 1190 5. IANA Considerations
>
> 1192 This documents request allocation for the following TLVs and subTLVs

Hmmm…. It looks like my comments were truncated (I’ve seen this happen a
couple of times). :-(

Here’s the rest:

1190 5.  IANA Considerations


1192   This documents request allocation for the following TLVs and subTLVs.


[minor] IANA may be ok, but I find the formatting below a little
confusing.  A table may be a better option.


...

1313   This document creates the following sub-TLV Registry:

...

[major] Please indicate what the range is.


…

1317      Registration Procedure: Expert review
[] We’re going to need Designated Experts.  Volunteers?

[major] Are there specific instructions/considerations that the DEs should
be aware of when assigning from this new registry?  If so, please add some
text.


...

1333 6.  Security Considerations


1335   With the use of the extensions defined in this document, IS-IS

1336   carries information which will be used to program the MPLS data plane

1337   [RFC3031].  In general, the same types of attacks that can be carried

1338   out on the IP/IPv6 control plane can be carried out on the MPLS

1339   control plane resulting in traffic being misrouted in the respective

1340   data planes.  However, the latter may be more difficult to detect and

1341   isolate.  Existing security extensions as described in [RFC5304] and

1342   [RFC5310] apply to these segment routing extensions.


[nit] Maybe break up the paragraph into multiple ones with independent
points.


[major] With the last sentence, are you implying that authentication is
required when IS-IS is carrying SR extensions?  If so, please be explicit.
Why would these extensions be different than any other extension?


[minor] The companion OSPF documents added the following paragraph to the
Security Considerations as a result of one of the reviews...perhaps
consider including something similar:


   Implementations MUST assure that malformed TLV and Sub-TLV defined in

   this document are detected and do not provide a vulnerability for

   attackers to crash the OSPFv2 router or routing process.  Reception

   of malformed TLV or Sub-TLV SHOULD be counted and/or logged for

   further analysis.  Logging of malformed TLVs and Sub-TLVs SHOULD be

   rate-limited to prevent a Denial of Service (DoS) attack (distributed

   or otherwise) from overloading the OSPF control plane.



...

1415 9.1.  Normative References

...

[minor] I think that these references can be Informative:


1463   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic

1464              Engineering", RFC 5305, DOI 10.17487/RFC5305, October

1465              2008, <https://www.rfc-editor.org/info/rfc5305>.


1467   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,

1468              DOI 10.17487/RFC5308, October 2008,

1469              <https://www.rfc-editor.org/info/rfc5308>.



...

1527   Les Ginsberg (editor)

1528   Cisco Systems, Inc.

1529   IT

[nit] I didn't know you had moved. ;-)