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

[Cheng Li <[e-mail]>]

Hi Bruno,

Many thanks for your reply. I think most of your comments have been addressed. Please check.

I copy the only one left here for better discussion.

-----
§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.
[Cheng]I agree with you of removing TTL text, but will anyone in the future have the similar question. How about we say the TTL value can be any value except 0?

Regarding the implementation, an email has been sent to the list, I believe you will see the text in the next revision. 😊

Thank you very much!
Li Cheng





From: [e-mail] <[e-mail]>
Sent: Wednesday, August 2, 2023 8: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?
[Cheng]Sure, will do it in next revision.

---

[…]

-----
§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.
[Cheng]I agree with you of removing TTL text, but will anyone in the future have the similar question. How about we say the TTL value can be any value except 0?


-----
§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
[Cheng]Thank you! Replaced


---
[…]

 ----
§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, 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)
[Cheng]Fixed.

---
[…]


 ----
§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.
[Cheng]Done.

---
§ 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)
[Cheng]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.