Re: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

Bruno,

Thanks for the detailed review and support.

Pls find responses below.

§4.1 "The S bit SHOULD be zero upon transmission, and MUST be ignored upon reception."

So essentially the flag has no meaning? If so, what about making it as reserved?
<SH> This is definition has been directly derived from draft-ietf-idr-segment-routing-te-policy.
I think its defined this way so as to keep the definition same as MPLS label in the packet.
Since this extension is used in control plane, it does not need to imply any meaning.
I will remove the bottom of stack meaning associated eith the flag and make it reserved.

----
§4
"   [I-D.ietf-spring-segment-routing-policy] defines various types of
   segments.  The segments applicable to this document have been re-
   defined here."

I'm not found of "re-defined". Surely this document is not meant to update SR-policy and redefine those types. Could you propose a different wording?
<SH> Agree. Modified text below. Let me know if this sounds better.
"The types of segments applicable to this document have been defined in this section  for the use of
MPLS OAM.
The motivation has been to keep the definitions same as in <xref target="I-D.ietf-spring-segment-routing-policy"/>
with minimal modifications if it is absolutely needed."
---

§4
"   Below types of segment sub-TLVs are applicable for the Reverse Path
   Segment List TLV.

   Type 1: SID only, in the form of MPLS Label

   Type 3: IPv4 Node Address with optional SID

   Type 4: IPv6 Node Address with optional SID for SR MPLS"

SR-policy renamed those to Type A, C, D. Is there a reason to change the name or could the same name be used?
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-14*section-4__;Iw!!NEt6yMaO-gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WGdqqC6TrhGjX$

<SH> No good reason to change. I'll update to use type A, C, D
---

§4.2 "  SID: 4 octet MPLS label."

MPLS label is not encoded using 4 octet. Please clarify how the label is encoded. (e.g. "as per Type 1 encoding" would work for me).
<SH> sure. will update
---
§4.2
"   If length is 12, then the IPv4 Node Address and the MPLS SID are present."

Please specify the behavior when the label is not consistent with the IP+SR fields. (e.g. which info is preferred)
<SH> sure. 
---
§ 13
   [I-D.ietf-spring-segment-routing-central-epe] Is now RC9087.
   <SH> will update.

---
§3 "For traceroute purposes, the headend/PMS need to acquire the
   entire database or use dynamically computed return path as described
   in Section 8"

"entire database" may be an overstatement. Maybe only the knowledge of the ABRS could be enough?
<SH> During traceroute, ever node is visited on the path and return path would have to be built from every node.
If the entire database is not known at the headend, I am not sure if the headend can figureout which ABR SID to be
used for return path.In any case this part is implementation dependent and doesn't have to be standardized.
The text was added as there were comments in the RT review that some suggestion of how the headend calculates the
return path should be explained.
Will change the text as below.

"One of the ways this can be
implemented on headend is to acquire the entire database (of all domains) and build return path
for every node along the SR path based on the knowledge of the database. 
Another mechansim is to  use dynamically
computed return path as described in <xref target="Dynamic_TLV_building"/>"

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: bruno.decraene@orange.com <bruno.decraene@orange.com> 
Sent: Monday, November 29, 2021 6:51 PM
To: Loa Andersson <loa@pi.nu>; mpls@ietf.org
Cc: draft-ninan-mpls-spring-inter-domain-oam@ietf.org; mpls-chairs@ietf.org
Subject: RE: [mpls] working group adoption poll on draft-ninan-mpls-spring-inter-domain-oam

[External Email. Be cautious of content]

Hi Loa, WG.

Support.

Please find below some proposed comments.

§4.1 "The S bit SHOULD be zero upon transmission, and MUST be ignored upon reception."

So essentially the flag has no meaning? If so, what about making it as reserved?

----
§4
"   [I-D.ietf-spring-segment-routing-policy] defines various types of
   segments.  The segments applicable to this document have been re-
   defined here."

I'm not found of "re-defined". Surely this document is not meant to update SR-policy and redefine those types. Could you propose a different wording?

---

§4
"   Below types of segment sub-TLVs are applicable for the Reverse Path
   Segment List TLV.

   Type 1: SID only, in the form of MPLS Label

   Type 3: IPv4 Node Address with optional SID

   Type 4: IPv6 Node Address with optional SID for SR MPLS"

SR-policy renamed those to Type A, C, D. Is there a reason to change the name or could the same name be used?
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-14*section-4__;Iw!!NEt6yMaO-gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WGdqqC6TrhGjX$
---
§4.2 "  SID: 4 octet MPLS label."

MPLS label is not encoded using 4 octet. Please clarify how the label is encoded. (e.g. "as per Type 1 encoding" would work for me).
---
§4.2
"   If length is 12, then the IPv4 Node Address and the MPLS SID are present."

Please specify the behavior when the label is not consistent with the IP+SR fields. (e.g. which info is preferred)
---
§ 13
   [I-D.ietf-spring-segment-routing-central-epe] Is now RC9087.

---
§3 "For traceroute purposes, the headend/PMS need to acquire the
   entire database or use dynamically computed return path as described
   in Section 8"

"entire database" may be an overstatement. Maybe only the knowledge of the ABRS could be enough?

Thanks,
Regards,
--Bruno

Orange Restricted

> -----Original Message-----
> From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
> Sent: Tuesday, November 16, 2021 9:59 AM
> To: mpls@ietf.org
> Cc: draft-ninan-mpls-spring-inter-domain-oam@ietf.org; 
> mpls-chairs@ietf.org
> Subject: [mpls] working group adoption poll on 
> draft-ninan-mpls-spring-inter- domain-oam
>
> Working Group,
>
> This is to start a two week poll on adopting
>
> draft-ninan-mpls-spring-inter-domain-oam
>
> as a MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working 
> group mailing list (mpls@ietf.org) Please give a technical motivation 
> for your support/not support, especially if you think that the 
> document should not be adopted as a working group document.
>
> There is one IPR disclosure against this document. The data tracker 
> says that there are 2 disclosure, but that depends on that the IPR 
> holder updated the disclosure when the filename of the was changed.
>
> All the authors and contributors have stated on the MPLS wg mailing 
> list that they are unaware of any other IPRs that relates to this document.
>
> The working group adoption poll ends November 30, 2021.
>
> /Loa
> --
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls
> __;!!NEt6yMaO-gk!TrHENaXz96xEeCgDM_ixH95FaX0F3YZ1mIo6gpWBt5zDOLAI2r4WG
> dqqC1MGald-$

_________________________________________________________________________________________________________________________

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.