Dear all,
I did an early RtgDir review of
draft-ietf-spring-segment-routing-mpls-13<https://www.ietf.org/mail-archive/web/spring/current/msg03762.html>
in June, and since then has been discussing the draft with the authors.
Now that a -16 version of the
draft<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-16>
has been published, I think that all the issues I have raised then have been
resolved - one way or another.
The table below summarizes the current status of these issues (including a nit
that I have raised following publication of the -14 version of the draft):
Issue
Current status
Comments
1. Encapsulation of SR-MPLS packets:
a. RFC 3032 (referenced by the draft) and RFC 5332 (not mentioned in the
draft) depend two encapsulations of labeled packets - one for
Downstream-allocated labels and another for Upstream-allocated ones.
b. From my POV the ST-MPLS only uses Downstream-allocated labels - but I
expect the draft to state that explicitly, one way or another. (If
Upstream-allocated labels are relevant for SR-MPLS, I would see it as a major
gap, so I hope that this is not the case).
Fully resolved
The last para in Section 2.2 explicitly states that "Labels allocated in this
document are considered per platform down-stream allocated labels" and
explicitly references RFC 3031.
2. Label spaces in SR-MPLS
a. RFC 3031 (referenced by the draft) defines per-platform and
per-interface label spaces, and RFC 5331 (not mentioned in the draft) adds
context-specific label spaces and context labels.
b. The draft does not say which of these are or are not relevant for
SR-MPLS
c. From my POV:
i. Labels representing
all kinds of SIDs mentioned in the draft MUST be allocated from the
per-platform label space only
ii. At the same time,
instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment
Routing Architecture draft using MPLS data plane clearly calls for context
labels and context-specific label spaces
Fully resolved
See the previous comment.
In addition, Section 2.7.3.1 explicitly defines Mirror SIDs and their
relationship with context labels and context label spaces defined in RFC 5331.
Note: I am not sure that the Mirror SID can be considered as a generalization
of the context label (the last sentence in Section 2.7.3.1).
The relevant text in 8402 says:
In the event of a failure, a Point of Local Repair (PLR) diverting traffic
from A to B does a PUSH of the Mirror SID on the protected traffic. When
receiving the traffic with the Mirror SID as the active segment, B uses that
segment and processes underlying segments in the context of A.
>From my POV, in SR-MPLS the "underlying segments" (in the highlighted text
>above) are labels following the Mirror SID label, i.e., per RFC 8402 a Mirror
>SID cannot be the last label in the stack.
It would be nice to clarify this point.
3. SR-MPLS and Hierarchical LSPs
a. SR LSPs that include more than one segment are hierarchical LSPs from
the POV of the MPLS data plane. Therefore some (possibly, all) of the models
for handling TTL and TC bits that have been defined in RFC 3443 (not mentioned
in the draft) should apply to SR-MPLS
b. RFC 8287 (not referenced in the draft) specifically discussed operation
of the LSP Traceroute function for SR LSPs in the case when Pipe/Short Pipe
model for TTL handling is used
c. I expect the draft to provide at least some guidelines regarding
applicability of each specific model defined in RFC 3443 (separately for TTL
and TC bits) to SR-MPLS.
Fully resolved
The relevant text has been added to Section 2.7.1. It has been copied from RFC
8277.
4. Inferring network protocol in SR-MPLS (the details are omitted)
Withdrawn
This has been discussed with the authors who have pointed out that prefix- and
Adj-SIDs are always associated with a specific network protocol (IPv4 and IPv6).
5. Resolution of Conflicts:
a. Are the conflict resolution procedures listed in section 2.5 mandatory
to implement?
b. If they are mandatory to implement, are they also mandatory to deploy,
or can the operators simply treat any detected conflict as requiring human
intervention and preventing normal operation of SR-MPLS?
c. For the reference, the IETF capitalized MUST appears just in a few
places in Section 2.5, and each appearance has very narrow context
d. The tie-breaking rules in section 2.5.1 include some specific values
for encoding FEC types and address families - but these values are not supposed
to appear in any IANA registries (because the draft does not request any IANA
actions). Can you please clarify what is so special about these values?
e. I also doubt that comparison of FECs that represent IPv4 and IPv6
prefix SIDs makes much sense (for conflict resolution or else), because, among
other things, there are valid scenarios when an IPv4 /32 prefix is embedded in
an IPv6 /128 one
f. Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all
SID types defined in the Segment Routing Architecture draft can be
unambiguously mapped to one of these types. Problematic examples include at
least the following
i. Parallel Adjacency SID
ii. Mirror SID
Explicit mapping of SID types to SR-MPLS FEC types would be most useful IMO. If
some SID types cannot be mapped to SR-MPLS FECs, this must be explicitly stated
in the draft
Fully resolved
Parallel adjacencies and Mirror SIDs have been added to the section describing
conflict resolution.
6. Node SIDs in SR-MPLS:
a. Node SIDs are explicitly defined and discussed in the Segment Routing
Architecture draft but are not mentioned even once in this draft
b. AFAIK, the common implementation practice today includes assignment of
at least one Node SID to every node in the SR-MPLS domain
c. Is there a requirement to assign at least one Node SID per {routing
instance, topology, algorithm} in SR-MPLS? If not, can the authors explain
expected behavior of such a node? (See also my comment about routing instances
below)
Fully resolved
The text discussing the need for Node-SIDs in SR-MPLS, potential conflicts that
can be associated with these SIDs and their recommended resolution in the last
para in Section 2.
7. SRGB Size in SR-MPLS
Fully Resolved
The current revision of the draft explicitly marks this issue as left FFS in
Section 2.3.
8. Algorithms and Prefix SIDs:
a. The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, but
it does not explicitly link them with the Prefix-SID algorithms defined in
section 3.1.1 of the Segment Routing Architecture draft
b. From my POV, the draft should explicitly state that the default
Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers
c. The Segment Routing Architecture draft states (in section 3.1.3) that
"Support of multiple algorithms applies to SRv6". But neither draft states
whether multiple algorithms apply to SR-MPLS. Can you please clarify this point?
Withdrawn
9. Routing instances and the context for Prefix-SIDs
Fully Resolved
The authors have clarified that routing instances are only mentioned in the
context of incoming conflict resolution, and the draft explicitly states that.
10. Example of PUSH operation in Section 2.10.1
Withdrawn
TI-LFA mentioned as an example of PUSH operation
11. Numerous nits reported by Adrian
Fully resolved
12. NIT: TI-LFA spelled as Ti-LFA
Fully resolved
13. NIT: Missing Informational reference to TI-LFA draft
Fully resolved
The reference to the TI-LFA draft has been added
14. NIT: Missing references to RFC 3443, 5332 and 5331
Fully resolved
References to RFC 3443 and RFC 5331 have been added. I agree that there is no
need for a reference to RFC 5332.
15. NIT: Missing reference to RFC 8287
Fully Resolved
The reference has been added
16. NIT: Problematic grammar in the first statement of the last para in
Section 2.3:
Local segments MAY be allocated from the Segment Routing Local Block (SRLB)
[RFC8402<https://tools.ietf.org/html/rfc8402>] or from any unused label as long
as it does not use a special purpose label
Fully resolved
The grammar issue (introduced in the -14 version) has been fixed.
Hopefully this summary will be useful.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
__________________________________________________________________________________________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
