Re: [Last-Call] Last Call: <draft-ietf-spring-mpls-path-segment-08.txt> (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ketan,

 

You may not have seen the reply from Mach, especially since for some reason, you don’t seem to be in the recipient list…

 

Does the reply address your comments or do you want to follow up?

 

If the latter, you may want to read and refer to latest version as there has been to modification since then.

https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment

 

Thanks again for your review and comments.

 

Thanks,

--Bruno

 

 

Orange Restricted

From: spring <spring-bounces@xxxxxxxx> On Behalf Of Cheng Li
Sent: Wednesday, July 5, 2023 9:57 AM
To: Mach Chen <mach.chen@xxxxxxxxxx>; draft-ietf-spring-mpls-path-segment@xxxxxxxx
Cc: ietf-announce@xxxxxxxx; andrew-ietf@xxxxxxxxxxx; james.n.guichard@xxxxxxxxxxxxx; spring-chairs@xxxxxxxx; spring@xxxxxxxx; last-call@xxxxxxxx; Pengshuping (Peng Shuping) <pengshuping@xxxxxxxxxx>
Subject: Re: [spring] Last Call: <draft-ietf-spring-mpls-path-segment-08.txt> (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard

 

Hi Ketan,

 

Many thanks for your thorough review, and sorry for my delay.

Please see my reply inline. BTW, the proposed update is attached, authors please review as well.

 

You can also review it from the Github repository. https://github.com/muzixing/SR-MPLS-Path-Segment/commit/343f7efe3f67a0bc2c02a239d575a2cc658c0aa5

 

 

Thanks,

Cheng

 

 

 

 

From: Ketan Talaulikar <ketant.ietf@xxxxxxxxx>
Sent: Monday, November 28, 2022 3:39 PM
To:
last-call@xxxxxxxx
Cc: IETF-Announce <
ietf-announce@xxxxxxxx>; andrew-ietf@xxxxxxxxxxx; draft-ietf-spring-mpls-path-segment@xxxxxxxx; james.n.guichard@xxxxxxxxxxxxx; spring-chairs@xxxxxxxx; spring@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-spring-mpls-path-segment-08.txt> (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard

 

Hello Authors,

 

Please find below some comments on the draft. I hope these can be addressed to fix/improve the document.

 

Major:

 

1) Sec 1: The term "SR path" is not defined in either RFC8402 or RFC9256. It seems this document is trying to introduce this terminology/concept. If so, it needs to be defined more formally with respect to the SR Policy. There is some text about this buried further in the document that perhaps needs to be specified more formally. Most of the document is dependent on this term.

 

[Cheng]Ketan, In the document, the description of the Path Segment is shown below.

---------

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.

---------

 

2) Sec 1: One of the key aspects of SR is that the state is on the SR Source Node and not the destination. I think it is important to cover/say

that remains the case for most situations and it is only in very specific cases that this Path Segment and the need to introduce a "per-path" state or awareness may be required at the destination/egress node.

 

[Cheng] How about adding a sentence in the last paragraph of introduction section?

 

__OLD___

 

Therefore, this document introduces a new segment type that is

referred to as the Path Segment. A Path Segment is defined to uniquely

identify an SR path in an SR-MPLS network. It MAY be used by the egress

nodes for path identification hence to support various use-cases

including SR path PM, end-to-end 1+1 SR path protection, and

bidirectional SR paths correlation.

 

__NEW__
Therefore, this document introduces a new segment type that is

referred to as the Path Segment. A Path Segment is defined to uniquely

identify an SR path in an SR-MPLS network. It MAY be used by the egress

nodes for path identification hence to support various use-cases

including SR path PM, end-to-end 1+1 SR path protection, and

bidirectional SR paths correlation. Note that, Per-path states will be maintained in the egress node due to the requirements in these use cases, though in normal cases that the per-path states will be maintained in the ingress node only in the SR architecture.

 

 

 

3) Sec 1:

QOUTE

   However, to support various use-cases in SR-MPLS networks, like end-
   to-end 1+1 path protection (Live-Live case) [RFC4426], bidirectional
   path [RFC5654], or Performance Measurement (PM) [RFC7799], the
   ability to implement path identification on the egress node is a pre-
   requisite.

UNQOUTE
It is very difficult to glean out what parts of these references make the assertion for the need for a Path Segment. More specific references to sections along with text that explains why Path Segment is necessary would help. Perhaps that goes into a use-cases or applicability section?

[Cheng] No problem, added a reference to the use case sections.

 

 

4) Sec 2:

QUOTE

If the Path Segment is used by an intermediate node to identify a SR path, the SRGB MUST be used.

UNQOUTE

Is there an assumption that there is no service label (or flow label) following the PSID label? How can an intermediate node know where the PSID label lies in the label stack?

[Cheng]First of all, an intermediate node can know the PSID in the top of the label stack in an error(Path Segment is not used for forwarding, so intermediate node should not read it unless it is an error). If it needs to know where is a PSID, it has to scan the label stack I think.

 

Regarding flow label and others, it is irrelevant with PSID. A flow label can be inserted after a PSID, that is fine.

 

 

5) Sec 2

QOUTE

   The term of SR path used in this document is a general term that can
   be used to describe a SR Policy, a Candidate-Path (CP), or a Segment-
   List (SL) [RFC9256].  Therefore, the Path Segment may be used to
   identify an SR Policy, its CP, or a SL terminating on an egress node

   depending on the use-case.

UNQOUTE

See my previous comment. Can it be defined more formally? Who determines what the Path Segment is associated with? The egress
allocates it but it is used by the ingress by associating with a specific SR Policy or specific Candidate Path or specific Segment List?

[Cheng]When PSID is allocated, it can be used for a Segment list, in this case, this PSID identifies a Segment List.

A PSID can be allocated for multiple Segment list in the Candidate Path, which means that multiple Segment Lists use the same PSID. In this case, a PSID is associated with a CP.

Same logic for SR Policy if you decide to use one PSID in the SR Policy.

 

Egress node and Ingress node will learn the mapping between PSID and SL. The details are described in PCEP/BGP extension drafts.

 

 

6) Sec 2

QOUTE

When Path Segment is allocated from the SRGB pool, an intermediate node MAY see the Path Segment label at the top of the label stack.

UNQOUTE

See previous comment and I am not able to understand how intermediate nodes can figure this out.

[Cheng] Already addressed in the latest revision, please review the update.

 

7) Sec 2

QOUTE

     A Path Segment 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 Path Segment MUST NOT be popped off until it

   reaches at the egress node.

UNQOUTE

How or why would the PH pop path segment? Is there any issue with misrouting if the PSID label was exposed at the top of the label
stack at other than the egress node? Especially if it is not allocated from the SRGB and is not unique in the domain.

 

[Cheng] I think you misunderstand this text. OR probably, the text is incorrect. I think the meaning is A path segment can be used in the case that the previous label is a PHP label, and Path Segment MUST NOT be popped off until it reaches at the egress node. But the previous label is irrelevant with PSID, so no need to explain more. I prefer to make some modifications shown below:

 

__NEW__

 

Some labels can 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.

 

 

8) Sec 2

QOUTE

   There may be multiple paths (or sub-path(s)) carried in the label
   stack, for each path (or sub-path), there may be a corresponding Path

   Segment carried.  A use case can be found in Section 4.

UNQOUTE

Please define what a sub-path is at the beginning of the document.

 

[Cheng] OK, any suggestion? How about adding the below text in Terms section?

 

Sub-Path: A sub-path is a part of the a path, which contains a sub-set of the nodes and links of the path. 

 

 

9) Sec 4

QOUTE

   Figure 2 shows the details of the label stacks when PSID and BSID are
   used to support both sub-path and end-to-end path monitoring in a
   multi-domain scenario.

UNQOUTE
What specific monitoring is required/used here when the path is end to end. By using PSID for sub-paths, are we not exposing the issue
to many more nodes in the network. In the figure below, has the scalability impact on a mid-point aggregation node B
through which a large number of SR Paths may be transiting been considered? Does that not go against the SR paradigm?

 

[Cheng] It depends on the use case. I can say that in some cases, E2E monitoring is needed, then allocates a PSID for the E2E path is good enough.

But we can not block people to do anything they want and they need. For example, they may need to know the traffic from ingress to the egress node in different domains respectively, that we can do it by encoding labels. But this is not required for sure.

 

This is not related to SR paradigm, it is only about the need. I wont say we encourage people to use path segment like that, but it is not prohibited. 😊

 

 

10) Sec 6

QOUTE

   In the current SR architecture, an SR path is a unidirectional path
   [RFC8402].  In order to support bidirectional SR paths, a
   straightforward way is to bind two unidirectional SR paths to a
   single bidirectional SR path.  Path Segments can then be used to
   identify and correlate the traffic for the two unidirectional SR
   paths at both ends of the bidirectional path.

UNQOUTE

RFC5654 does not seem to justify the need for a Path Segment for the bidirectional use-case. The computation aspect of bidir paths
is already covered and there is no issue there. I don't see the justification for the need of a PSID to be used in the data path. It would help if a description of the use-case about why the egress node needs to know the reverse path context and what it can or may do with it were covered.

[Cheng] Well, the egress node must know the path so that it can support APS(Automatic Protection Switching) for Bidiretional path. Therefore the PSID is required for Bidirectional Path.

 

Also, you can see RFC5654 section 2.1


9 The end points of a co-routed bidirectional transport path MUST
be aware of the pairing relationship of the forward and reverse
paths used to support the bidirectional service.

 

Egress can know the relationship and perform actions based on PSIDs.

 

 

 

11) Sec 7

QOUTE

   There then needs to be a method of binding this SR path identifiers
   into equivalence groups such that the egress node can determine for
   example, the set of packets that represent a single primary path.  It
   is obvious that this equivalence group can be instantiated in the

   network by an SDN controller using the Path Segments of the SR paths.

UNQOUTE

Unlike the other use-cases, there does not seem to be an equivalent description or specification on how this use-case is realized
using PSID for SR Policy

[Cheng]I think this is not a case of PSID for SR policy. In the case of PSID for SR policy, each CP/SL use the same PSID value.

In this case, different PSIDs are allocated to Primary and Secondary path, the egress node will always receive the packets from the Primary path and discard the packets from the secondary path.

Therefore, it is required that the egress node knows that from which path the packets come.

 

 

Minor:

 

a) Please consider shortening the abstract. Right now it is almost mirroring the Introduction.

[Cheng]Good suggestion, please see diff.

 

b) Sec 2

QOUTE

   In addition, adding a Path Segment to a label stack will increase the
   depth of the label stack, the Path Segment should be accounted when
   considering Maximum SID Depth (MSD)[RFC8992].
UNQOUTE

This is a repetition of text just a few paragraphs above.

[Cheng]deleted

 

Thanks,

Ketan

 

 

On Sun, Nov 6, 2022 at 3:48 PM The IESG <iesg-secretary@xxxxxxxx> wrote:


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Path Segment in MPLS Based
Segment Routing Network'
  <draft-ietf-spring-mpls-path-segment-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2022-11-20. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.

   In SR for MPLS data plane (SR-MPLS), the segment identifiers are
   stripped from the packet through label popping as the packet transits
   the network.  This means that when a packet reaches the egress of the
   SR path, it is not possible to determine on which SR path it
   traversed the network.

   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.  When used, it is inserted by the ingress node of the SR
   path and immediately follows the last segment identifier in the
   segment list of the SR path.  The Path Segment is preserved until it
   reaches the egress node for SR path identification and correlation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/5009/
   https://datatracker.ietf.org/ipr/3492/
   https://datatracker.ietf.org/ipr/3455/
   https://datatracker.ietf.org/ipr/5063/






_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce

____________________________________________________________________________________________________________
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.
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux