Subject: [mpls] Feedback on draft-iqbal-spring-mpls-ping-algo

From: "Faisal Iqbal (faiqbal)" <[email-masked]>
Date: Wed, 18 Jul 2018 18:07:49 +0000

Hi SPRING/MPLS WG,
We presented draft-iqbal-spring-mpls-ping-algo<https://tools.ietf.org/html/draft-iqbal-spring-mpls-ping-algo-00> to SPRING and MPLS WG during IETF 102 at Montreal. The chairs decided to progress this draft via SPRING WG. We wanted to take this opportunity to seek if there's any additional feedback by either WG.

Below is the abstract:
RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for
Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier
(SIDs) with an MPLS data plane.  [I-D.ietf-lsr-flex-algo] proposes a
mechanism to allow IGPs to compute constraint based path over network
and use Segment Routing Prefix-SIDs to steer packets along the
constraint-based paths.  All Prefix-SIDs associated with the Flexible
Algorithm are assigned to the same IPv4/IPv6 Prefix.  Any Segment
Routing network that uses Flexible Algorithm based path computation
needs additional details to be carried in the FEC Stack sub-TLV for
FEC validaiton.

This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix
Segment ID FEC sub-TLVs to also include algorithm identification.

Regards,
Faisal

---

From: <[email-masked]>
Date: Thu, 19 Jul 2018 20:54:15 +0000

Hi Faisal, all

As an individual contributor, please find below some proposed comments.

1) "Supporting Flexible Algorithm Prefix SIDs"
I don't think this document should be specific / tied to Flex Algo. Indeed the SR Architecture & IGP extensions do have the Algorithm field, independently of Flex Aglo.
IOW, this extension is useful independently of Flex Algo.
In all cases, the document needs to provide a solution for all SR Algo, not just the Flex Algo ones.

This impacts some of the introductory / motivation text, including abstract and title.
This also impacts the specification. e.g.

OLD:
"   Algo field must be set to 0 if the default algorithm is used.  Algo
   field is set to 1 if Strict Shortest Path First (Strict-SPF)
   algorithm is used.  For Flex-Algo, the Algo field must be set with
   the algorithm value (values can be 128-255)."

Proposed NEW:
Algo field must be set to the SR Algo as defined in the SR architecture.

2) Incremental deployment
Please correct me:
- If the responder does not support this extension, it will reply, just like today, with error code 10, which is an "incorrect" answer ("incorrect" from the Initiator standpoint)
- If the responder does support this extension but finds out that that label used is incorrect,  it will reply with error code 10, which is a correct answer.

Is there a way for the Initiator to distinguish between these 2 scenarios?

3) Multi Topology
It's good to include the Algo field which, IMO, was missing in RFC 8287.
Now what about IGP Multi topology?
SR architectures says:

"Multiple SIDs

   MAY be allocated to the same prefix so long as the tuple <prefix,

   topology, algorithm> is unique. >

So it seems that the problem is the same for MT.

Thanks,
Best regards,
--Bruno

From: spring [mailto:[email-masked]] On Behalf Of Faisal Iqbal (faiqbal)
Sent: Wednesday, July 18, 2018 2:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [spring] Feedback on draft-iqbal-spring-mpls-ping-algo

Hi SPRING/MPLS WG,

Below is the abstract:

Regards,
Faisal

_________________________________________________________________________________________________________________________

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.