Re: [spring] draft-ietf-spring-mpls-path-segment

[[e-mail]]

Hi Cheng,

Following the publication of -10, please find below some additional comments.

-10 has clarified that the PSID is a local identifier on the egress. (not a global one). I think that this calls for some cleaning in some sentences:

§2 “If the PSID is only used by the egress node to identify an SR path, the SRLB, SRGB or dynamic MPLS label pool can be used.”
I would propose to remove that historic sentence.

BTW, is there still any reason to allocate a PSID from the SRGB?
If not, I would propose to remove that case..

That would make the “Path Segment” a “Local Segment” as per RFC 8402. I would propose to state this.
e.g.
OLD: A Path Segment Identifier(PSID) is a single label that is assigned from the Segment Routing Local Block (SRLB) [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] or Segment Routing Global Block (SRGB) [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] or dynamic MPLS label pool of the egress node of an SR path.
NEW: A Path Segment is a Local Segment [RC8402]. The Path Segment Identifier (PSID)  is a single label assigned as per [8402]

“because of mis-matching if the PSID is allocated from a SRLB.”
PSID is allocated from the SRLB, so there is no such “if”. If would propose to remove the quoted text.


Other comments:
§2 “When a PSID is used, the PSID MUST be inserted at the ingress node and MUST immediately follow the last label of the SR path, in other words, inserted after the routing segment (adjacency/node/prefix segment) pointing to the egress node of the SR path.”

  *   Actually “MUST” would be violated if multiple PSDI were used. e.g. when nested in used (cf §4) in a single Segment List (not requiring binding SID as §4 described)
  *   This sentence is not needed if we say that the Path Segment is a local segment (see above) as this is how Local Segment are used.


“3. PSID Allocation and Distribution

There are some ways to assign and distribute the PSID. The PSID can be configured locally or allocated by a centralized controller or by other means, this is out of the scope of this document”

The first sentence does not say much (if anything) and the formulation does not seem precise enough for a STD track document.
Regarding allocation, if we say the Path Segment is a Local Segment (just like a BSID) I don’t think that there is anything new. Hence probably there is nothing to say about this.
Regarding signaling, I think it’s ok to say this this is out of cope of the document.

So proposed NEW

3. PSID and Distribution

Signaling of the PSID between the egress, ingress and possibly a centralized controller is out of the scope of this document.

-----

§5, §6, §7.
My reading is that those 3 sections do not specify behaviors (which would typically be specified in other WGs) but are uses cases that could leverage the Path Segment.
I would propose to move those 3 sections into a new section “Use cases”.
Proposed NEW

§5 Uses cases
This section described uses cases which can leverage the Path Segment.
§5.1 Path Segment for Performance Measurement
[…]
§5.2 Path Segment for Bidirectional SR Path
[…]
§5.3 Path Segment for End-to-end Path Protection
[…]

----
“Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks. As per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>], when GAL is used, it the ACH appears immediately after the bottom of the label stack.”
IMO :s/MAY/may

Also this sentence could be rephrase to use the same style than the Entropy Label case.
e.g. proposed NEW
If Generic Associated Label (GAL) MAY be used for Operations, Administration and Maintenance (OAM) in MPLS networks, as per [RFC5586<https://www.rfc-editor.org/rfc/rfc5586>], the ACH would appear immediately after the bottom of the label stack and hence does not interfere with the PSID which is placed above.”

---
§8
“A Path Segment is used within an SR-MPLS domain [RFC8402<https://www.rfc-editor.org/rfc/rfc8402>] and SHOULD not leak outside the domain,”

“SHOULD not’ is not allowed. It’s either SHOULD NOT or should not.
IMO is in this context it’s “should not”

Thanks,
--Bruno




Orange Restricted
From: DECRAENE Bruno INNOV/NET
Sent: Wednesday, August 2, 2023 2:47 PM
To: Cheng Li <[e-mail]>
Cc: James Guichard <[e-mail]>; [e-mail]; Stewart Bryant <[e-mail]>; [e-mail]; SPRING WG <[e-mail]>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Cheng,

Thanks for the updated draft.

Please see some follow-up points inline [Bruno].




Orange Restricted
From: Cheng Li <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 17, 2023 12:43 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-spring-mpls-path-segment

Hi Bruno,

Many thanks for your work! I am addressing the comments received from the WG, so it is fine/good to me that address your comments in the same time 😊
Please see my reply inline. The diff is generated by comparing with 09. The proposed update tries to address the comments from you, Ketan and Stewart.

If you like to use Github, the link is here: https://github.com/muzixing/SR-MPLS-Path-Segment/commit/3ace59b1e87859950dfac8a967ee560128843b6b

Respect and thanks,
Cheng


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 12, 2023 10:41 PM
To: [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>
Subject: draft-ietf-spring-mpls-path-segment

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?

[Cheng]Weiqiang has replied to you on these two questions. Path Segment has been implemented by a significant number of vendors for several years, and it has been used in large scale networks.

[Bruno] Thank you.
Actually the SPRING WG has a policy to mandate an implementation section in the document. https://wiki.ietf.org/en/group/spring/WG_Policies
Could you please add one?

---

[…]

-----
§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)
[Cheng] because we do not use Path Segment for forwarding, so IMHO, the TTL can be any, like 0, or same as the previous one.  How about the following modifications?
___OLD____
"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."

___NEW___
"The value of the TTL field in the MPLS label stack entry containing the PSID can be set to any value including 0, or the same value as the TTL of the last label stack entry for the last segment in the SR path."

[Bruno] I disagree with the setting of the TTL to zero. If PHP is enabled, the PSID will appear top of stack and sending an MPLS packet with a TTL zero in the top of stack is not allowed in MPLS
cf https://datatracker.ietf.org/doc/html/rfc3032#section-2.4.2
(Entropy Label could do that because it never appears top of stack)

Actually, the TTL field in the path segment does not seem much different than the TTL field in a binding or adjacency segment. So may be the whole text on TTL may be removed.

-----
§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.


[Cheng]Well, to me, the sentence is trying to explain the cases that the egress node needs to support processing of multiple labels. But we do have some use cases that the only label is processed on the egress node is the PSID. For example, we only encode the labels of the LSP and PSID in the label stack while the last forwarding label is a PHP enable label. Therefore, when a packet arrives on the egress node, only one single label(The PSID) will be processed. In this case, multiple labels processing is not required.

In other words, this paragraph is only for info that it explains we may have differences with or without services label. If without services label, then the requirement of processing multiple labels MAY not changed. Indeed, the processing of PSID is new in any cases.

[Bruno] A label below the PSID is not limited to the use of service label. e.g, cf section 4 but also with a single PSID followed by transit labels. So at minimum the first sentence is misleading.
Again, I would rather cover the general case. Some proposed text as replacement.
The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing (such as a below MPLS label or the MPLS payload). The additional processing required, may have an impact on forwarding performance


---
[…]

 ----
§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.
[Cheng] OK, thank you!

[Bruno] Actually I introduced a typo  (:s/it the/the)

---
[…]


 ----
§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")
[Cheng]You are right. We might delete it directly, because it is obvious as well.

[Bruno] You did remove this sentence. However the sentence was written _twice_ in -09, so as a result, in -10 the sentence is still present so there is still a need to remove it.

---
§ 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.

[Cheng] I have to say sorry here, because I am not an expert of security. How about the following modifications?

___NEW___
A Path Segment in SR-MPLS is a label similar to other labels/Segment, such as a VPN label or a Prefix SID, defined in MPLS and SR-MPLS. The data plane processing of a PSID is a local implementation of an ingress node, or an egress node, which follows the same logic of existing MPLS dataplane.

A Path Segment is used within an SR-MPLS domain {{RFC8402}} and SHOULD not leak outside the domain, therefore no new security threats are introduced comparing to current SR-MPLS. The security consideration of SR-MPLS, such as boundary filtering described in {{Section 8.1 of RFC8402}} applies to this document.

A PSID is allocated by an egress node and distributed to an ingress. The distribution is performed within an SR trusted domain. However, the mechanism of distributing a PSID is out of the scope of this document, and its security consideration will be described in other documents.

[Bruno] I think that you mean :s/SHOULD/should
(there is no special new thing to be done)

Thanks,
Bruno

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.
____________________________________________________________________________________________________________
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.