Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

Hi Stewart,

The SR-MPLS path segment (MPLS label) is used to count received packets on
a particular path on the egress node. This allows us to measure PM packet
loss on a given path. The (incoming) MPLS label as path segment has an
advantage of using existing implementations for RX packet count.

Thanks,
Rakesh

On Thu, Jul 22, 2021 at 10:06 AM Stewart Bryant <stewart.bryant@gmail.com>
wrote:

> Once you find yourself needing to include path identifiers in an SR
> packet, I begin to wonder whether the segment routing design has gone off
> track.
>
> In MPLS we have the ability in both PCE and RSVP to lay out end to end
> paths in such a way that the forwarding label is the path identifier. If
> you recall the MPLS-TP approach you could deduce everything about the
> packet’s origin and path from the arrival label which was not PHPed.
>
> Assuming there are technical reasons why such a classic approach is not
> possible, I wonder why it is necessary to encode the path identifier within
> label stack itself with all of the constraints that imposes on the size and
> semantics of the identifier.
>
> An alternative approach is to look at the meta/ancillary data work that is
> going on in MPLS and carry the path identifier below the bottom of stack.
>
> At  its most basic level this analogous to the approach to constructing a
> Pseudowires, with an outgoing label stack, a control word (which can be an
> extended control word carrying the path information) and then the payload.
>
> Such an approach would allow the packet designer to carry either the
> identity of the path, or the actual set of labels use to construct the
> path, or the reverse path or some combination of these. The latter two
> approaches are more dynamic than the approach proposed in this draft and
> more in keeping with the fundamental design philosophy of SR.
>
> - Stewart
>
>
> On 22 Jul 2021, at 14:02, James Guichard <james.n.guichard@futurewei.com>
> wrote:
>
> Dear WG:
>
> The WGLC for this document will be extended for a further 2 weeks ending
> August 4th 2021 so that feedback can be obtained from the WG. Other than
> the authors there has been little input so please respond on the mailing
> list with any comments etc.
>
> Thanks!
>
> Jim, Joel & Bruno
>
> *From:* James Guichard <james.n.guichard@futurewei.com>
> *Sent:* Wednesday, July 7, 2021 11:49 AM
> *To:* spring@ietf.org
> *Cc:* spring-chairs@ietf.org
> *Subject:* WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
>
> Dear WG:
>
> This email starts a 2 week Working Group Last Call for
> draft-ietf-spring-mpls-path-segment [1].
>
> Please read this document if you haven’t read the most recent version and
> send your comments to the SPRING WG list no later than July 21st 2021.
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
> Lastly, if you are an author or contributor please response to indicate
> whether you know of any undisclosed IPR related to this document.
>
> Thanks!
>
> Jim, Joel & Bruno
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C4336eaaa34f543cc4c9e08d9415ebd06%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637612697462524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v18Zntmw18jYiIXCNMDa7bYNQMZ90U29GVEkuPh5CjE%3D&reserved=0>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>