Hi authors,
Since Jim is now the responsible AD, the shepherd for this document has been
changed from Jim to myself.
As a result you/this document benefit/suffer from another review.
Please find below my comments/questions.
On a side note, I have two questions for you (for the shepherd writeup):
Are there existing implementations of the protocol?
Have a significant number of vendors indicated their plan to implement the
specification?
---
Abstract
"This document defines a new type of segment that is referred to as Path
Segment, which is used to identify an SR path in an SR-MPLS network."
Given that the path segment may be allocated from a local label of the egress
node, (e.g. SRLB, dynamic pool), I believe that only the egress node may use
that label to identify an SR-path. (not any node on the path/in the network).
If so I believe the following change would be more accurate:
OLD; to identify an SR path in an SR-MPLS network.
NEW: to identify an SR path on the egress LER
Same comment for the §1 Introduction. ("A Path Segment is defined to uniquely
identify an SR path in an SR-MPLS network.")
-------
Abstract:
"A Segment Routing (SR) path is identified by an SR segment list. Only the
complete segment list can identify the end-to-end SR path, and a sub-set of
segments from the segment list cannot distinguish one SR path from another as
they may be partially congruent. SR path identification is a pre-requisite for
various use-cases such as Performance Measurement (PM), bidirectional paths
correlation, and end-to-end 1+1 path protection."
This seems to be saying that "Performance Measurement (PM), bidirectional paths
correlation, and end-to-end 1+1 path protection" is not possible without MPLS
Path Segment. I don't feel that this is correct. Eventually you mean that "a
form of path identification/discrimination", which is different as this
identification may be performed at a different layer than the SR-path. (e.g.
different egresss loopbacl/prefix SID, any form of ID below that MPLS stack
(e.g. different IP address, L4 source/destination port, application specific ID
(e.g. My Miscriminator?)...
May be consider rephrasing.
Same text/comment in the §1 Introduction.
-------
§1 Introduction
"or IPv6 data plane using an SRH header via SRv6 [RFC8986]"
Since this document is specific to SR-MPLS, I don't think that this text and
reference are needed.
-------
§1.2
"SRv6: Instantiation of SR on the IPv6 data plane."
Since this document is specific to SR-MPLS, I don't think that this text is
needed.
-----
§1 Introduction
"Thus, the egress node cannot determine along which SR path the packet came."
As per a previous comment, may be restricting this statement to the SR-path.
e.g. NEW: Thus, the egress node cannot use the SR label stack to determine
along which SR path the packet came.
------
§2
"If the Path Segment is used by an intermediate node to identify an SR path,
the SRGB MUST be used."
I don't think that the use of a label from the SRGB allows to identify the path
on a intermediate node. e.g. this label may have been chosen by LDP/BGP LU/BGP
VPN by a non SR compliant router. Also the MPLS WG is discussing MNA which
allows inserting any number/thing in the stack (so including a value which is
part of the SRGB).
I would propose to remove this sentence (alternatively define another technical
solution for this, but any significant technical change may justify returning
the document to the WG)
-----------
§2
"The term of SR path used in this document is a general term that can be used
to describe an SR Policy, a Candidate-Path (CP), or a Segment-List (SL)
[RFC9256]. Therefore, the PSID may be used to identify an SR Policy, its CP, or
a SL terminating on an egress node depending on the use-case."
>From a general standpoint, the PSID may probably be used to identify whatever
>you want _assuming_ a coordination between the ingress and the egress to
>specify the scope of the identification.
So IMO,
- either this document specify the scope of the identification, in which case
no additional coordination is required, but this may limit the future use
cases. I would suggest that a PSID identifies a Candidate-Path as this seems
inline with RFC 9256.
- or this document defines how this scope/meaning is coordinated between the
ingress and egress. ( section 3 says that this is out of scope). In which case
this document can't say what this PSID identify. (it could be a SR Policy, or a
Candidate-Path or just anything including application specific (e.g. Altnernate
marking). To some extend the name of the ID (PSID) and even the name of the
Segment type (Path Segment) is debatable as you may not be identifying a path.
This looks like a bigger change.
(More generally MPLS is about making an association between a label value (any
number) and a FEC/signification. In this document you propose to use a label
value but you declare that assigning the FEC/signification is out of scope. To
me this significantly reduce the interest of this document and the ability to
have interoperability between two nodes implementing this document making it
more a framework and than a STD track document.)
I think my suggestion would be to say that a PSID identifies a Candidate Path
[RFC9256]. That way both the ingress and the egress knowns that using a
different PSID means using a different candidate path. This still leave out of
scope how the ingress knows about the PSID to use for each CP (let's say it's
part of the SR policy configured/pushed) and what is the behavior on the
receiver. And if one really needs to identify the SR Policy, one could achieve
by either configuring, on the ingress, the same PSID for all the CP of the SR
Policy.; or by configuring on the egress all the PSID used by the CP of a given
SR Policy.
-----
§2
"The value of the TTL field in the MPLS label stack entry containing the PSID
MUST be set to the same value as the TTL of the last label stack entry for the
last segment in the SR path."
"MUST" is a pretty strong statement. What is the reason for this? What is the
egress supposed to do if this is not the case?
Interestingly, RFC 6790 has a oppositive position with regards to the Entropy
Label: "The TTL for the EL MUST be zero to ensure that it is not used
inadvertently for forwarding." while the case seems similar (addition of a
label "not used for forwarding")
https://datatracker.ietf.org/doc/html/rfc6790#section-4.2
Is there any rule for the TC field? (if not, please say so; if so, please
specify the rule)
---
§2
"Normally, an intermediate node will not process the PSID in the label stack
because the PSID is inserted after the routing segment pointing to the egress
node. But in some use cases, an intermediate node MAY process the PSID in the
label stack by scanning the label stack or other means. In these cases, the
PSID MUST be learned before processing. The detailed use cases and processing
is out of the scope of this document."
I think that this text is about coordinating the semantic of the PSID between
the node writing it (ingress) and the node(s) reading it (egrees or transit).
Hence I think this point should rather be moved to section " 3. PSID Allocation
and Distribution "
------
§2
"A PSID can be used in the case of Penultimate Hop Popping (PHP), where some
labels are be popped off at the penultimate hop of an SR path, but the PSID
MUST NOT be popped off until it reaches at the egress node."
You cannot define a behavior, not to mention a "MUST" on a node which may not
be compliant with this document.
I personally don't believe that you need to define a new behavior and I would
propose:
OLD:
A PSID can be used in the case of Penultimate Hop Popping (PHP), where some
labels are be popped off at the penultimate hop of an SR path, but the PSID
MUST NOT be popped off until it reaches at the egress node.
NEW:
A PSID can be used in the case of Penultimate Hop Popping (PHP), where some
labels are be popped off at the penultimate hop of an SR path. As per regular
MPLS processing, the label below (including the PSID in this case) will not be
popped by the penultimate node.
-----
§2
"In some deployments, service labels may be added after the Path Segment label
in the MPLS label stack. In this case, the egress node MUST be capable of
processing more than one label. The additional processing required, may have an
impact on forwarding performance."
I belive that when the PSID is used, there is _always_ an extra processing work
on the data plane (the processing of the PSID). So I don't think that this is
specific to "some deployments" or "service label".
If so, please rephrase.
---
§2
"Entropy label and Entropy Label Indicator (ELI) as described in [RFC8662] for
SR-MPLS path, can be placed before or after the PSID in the MPLS label stack."
You seem to be re-specifying the EL spec. From the perspetive of this egress
node, the ELI, EL MUST be placed before the tunnel label (as per RFC6790) and
the PSID MUST be placed after the tunnel label (as per this document).
So IMO this sentence is adding unnecessary confusion.
I would propose
OLD:
Entropy label and Entropy Label Indicator (ELI) as described in [RFC8662] for
SR-MPLS path, can be placed before or after the PSID in the MPLS label stack.
NEW:
If Entropy Label is also used on this egress node, as per [RFC6790] the Entropy
label Indicator (ELI) and Entropy Label (EL) would be placed before the tunnel
label and hence does not interfere with the PSID which is placed below.
----
§2
"Generic Associated Label (GAL) MAY be used for Operations, Administration and
Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be
added at the bottom of the label stack after the PSID."
Reading RFC 5586, that seems to be already the rule for GAL. Hence I don't
think that this needs to be defined as a new rule (MUST). Especially as this
seems to indicate a variation (before BoS vs after BoS) hence this may add
confusion.
I would propose:
OLD: Generic Associated Label (GAL) MAY be used for Operations, Administration
and Maintenance (OAM) in MPLS networks [RFC5586]. When GAL is used, it MUST be
added at the bottom of the label stack after the PSID.
NEW: Generic Associated Label (GAL) MAY be used for Operations, Administration
and Maintenance (OAM) in MPLS networks. As per [RFC5586], when GAL is used, it
the ACH appears immediately after the bottom of the label stack.
---
§2
"The MSD used for path computation MUST include the PSID."
MSD is already defined and you cannot redefine it with a new rule (MUST).
Actually RC 8491 already states that the MSD include all labels that can be
imposed ("the total number of MPLS labels that can be imposed, including all
service/transport/special labels")
https://www.rfc-editor.org/rfc/rfc8491.html#section-5
I would propose
OLD: The MSD used for path computation MUST include the PSID.
NEW: As per RFC8491 the MSD signals the total number of MPLS labels that can be
imposed. This includes the PSID.
-----
§2
"In addition, adding a PSID to a label stack will increase the depth of the
label stack, the PSID should be accounted when considering Maximum SID Depth
(MSD)[RFC8992]."
The above last sentence of §2 seems to be duplicating some previous text
(below) and hence seem not useful. I would propose to remove it.
"The SR path computation needs to know the Maximum SID Depth (MSD) that can be
imposed at each node/link of a given SR path [RFC8664]. This ensures that the
SID stack depth of a computed path does not exceed the number of SIDs the node
is capable of imposing. The MSD used for path computation MUST include the
PSID."
----
§3
"If an egress cannot support the use of the PSID, it MUST reject the attemption
of configuration."
If a egress doest not support PSID, how would it support the above rule?
It would seem easier to put the rule/burden on one pushing the PSID (e.g. the
'centralized controller" although the latter is "out of scope of this document")
--
§7 (and also mostly §6)
To some extend, this whole section is about signaling the context and semantic
of the PSID between the ingress and the egress. Personally I would rather move
this section inside section 3.
---
§ 8. Security Considerations
"no new security threats are introduced comparing to current SR-MPLS"
In general, such statement may be read by security guys as "we did not really
bothered studying the security implications". IMO it's better to put more text
to explain _why_ there is no impact on security.
As a matter of fact, I'm not sure to agree with this statement: the one (e.g.
an attacket) having the ability to signal a PSID value to an ingress, would
have the ability to signal any label including a label value used as a service
(VPN) label. This would trigger a VPN breach (injecting packets in the VPN).
This may not be not specific to the PSID, but even an "old" RFC with "old"
security considerations is doing an effort well beyond "nothing new".
https://datatracker.ietf.org/doc/html/rfc5036#section-5
So please consider enhancing the security consideration.
Thanks,
BR
--Bruno
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
