Greg,
We are close, though I hope the rules are that GAL is bottom of stack,
and that a packet with a GACh does not carry user payload.
I should have said that "if you want a GACg for the
I don't understand why we need a "new" SR tunnel, the GAL/GACh can
ride with the GAL as bottom of stack with the label stack for
Sub-path(B->C), right? If you put it on "another" tunnel, how do
you guarantee fate sharing?
/Loa
/Loa
On 2019-02-23 11:55, Greg Mirsky wrote:
Hi Loa,
I think it will be similar to SPME and we'll need to have another
SR-tunnel B-C with its own Path segment allocated by node C. But GAL
will still be BoS.
Regards,
Greg.
On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson <l...@pi.nu
<mailto:l...@pi.nu>> wrote:
Rakesh, authors,
I have not been thinking about this too much. But if you look at fig 2
of draft-cheng-spring-mpls-path-segment, and you need a GACh between
A and D, I'd say that the GAL will be at the bottom of stack.
What if you need the CACh for the sub-path B to C, where will the GAL
go?
/Loa
On 2019-02-23 09:25, Rakesh Gandhi wrote:
> Hi Greg,
>
> I am not sure if the question has been answered. I would think
GAL is at
> the bottom of the label stack.
>
> Thanks,
> Rakesh
>
>
> On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky
<gregimir...@gmail.com <mailto:gregimir...@gmail.com>
> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>> wrote:
>
> Hi Weiqiang Cheng,
> thank you for your expedient response to my questions. The
document
> states that one of the use cases for the Path segment is to
be used
> as a performance, packet loss and/or delay, measurement session
> identifier. I think that RFC 6374 is the most suitable for PM
OAM in
> SR-MPLS environment. Of course, the type of the
encapsulated message
> can be identified using the destination UDP port number with
IP/UDP
> encapsulation. But another option is to use G-ACh encapsulation.
> That would require the use of GAL. And that is how I've
arrived at
> my original question (I should have explained it better, my
apologies):
>
> How the Path segment and GAL are placed relative to each
other
> in the SR-MPLS label stack?
>
> Regards,
> Greg
>
> On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
> <chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>
> <mailto:chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>>> wrote:
>
> Hi Greg,____
>
> Thanks a lot for your comments.____
>
> My comments are in-line.____
>
> __ __
>
> B.R.____
>
> Weiqiang Cheng____
>
> __ __
>
> *发件人:*Greg Mirsky [mailto:gregimir...@gmail.com
<mailto:gregimir...@gmail.com>
> <mailto:gregimir...@gmail.com
<mailto:gregimir...@gmail.com>>]
> *发送时间:*2019年2月15日3:37
> *收件人:*Alexander Vainshtein
> *抄送:*spring@ietf.org <mailto:spring@ietf.org>
<mailto:spring@ietf.org <mailto:spring@ietf.org>>; Stewart Bryant;
> draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>
> <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>>;
> m...@ietf.org <mailto:m...@ietf.org> <mailto:m...@ietf.org
<mailto:m...@ietf.org>>; Loa Andersson
> *主题:*Re: [spring] to progress
> draft-cheng-spring-mpls-path-segment____
>
> __ __
>
> Dear All,____
>
> I concur with all what has been said in support of the
adoption
> of this draft by SPRING WG. The document is well-written,
> addresses the real problem in SR-MPLS, and the proposed
solution
> is technically viable.____
>
> My comments and questions are entirely for further
discussion:____
>
> * would the draft be expanded to demonstrate how "the Path
> Segment may be used to identify an SR-MPLS Policy, its
> Candidate-Path (CP) or a SID List (SL)"?____
>
> [Weiqiang] Yes, It is necessary and we will add some text to
> demonstrate this in the future version. ____
>
> * as many use cases for the Path Segment are related to OAM
> operations, it would be helpful to expand on the use
of GAL
> and the Path Segment.____
>
> [Weiqiang] It is always helpful to have more use cases.
However,
> The GAL is used today in MPLS-TP LSPs to flag the G-Ach
and is
> used for OAM packets only while the Path segment is used for
> data packets for the each traffic flow. It is a little bit
> different. ____
>
> Regards,____
>
> Greg____
>
> __ __
>
> On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein
> <alexander.vainsht...@ecitele..com
> <mailto:alexander.vainsht...@ecitele.com
<mailto:alexander.vainsht...@ecitele.com>>> wrote:____
>
> +1.____
>
> ____
>
> I have been following this draft from its -00
revision. The
> current revision has resolved most of the issues I (and
> others) have been raised (e.g., elimination of excessive
> options).____
>
> ____
>
> From my POV, in its current state the draft meets
two basic
> requirements for the WG adoption:____
>
> 1.It addresses a real and relevant problem, namely
the MPLS
> Flow Identification problem discussed in general in
RFC 8372
> <https://tools.ietf.org/html/rfc8372> and scoped to
SR-MPLS
> LSPs in this draft. Specifics of SR-MPLS include the
need to
> provide end-to-end liveness check that is one of the
> requirements explicitly specified in Section 2 of RFC
8355
> <https://tools.ietf.org/html/rfc8355>. ____
>
> 2.It provides a reasonable (from my POV) approach to
> solution of this problem.____
>
> ____
>
> I also concur with Stewart’s comment about strong
similarity
> between the approach taken in this draft for SR-MPLS and
> generic work in progress on synonymous flow labels
>
<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>
> that has been already adopted as a MPLS WG item. To
me this
> is yet another indication that the draft should be
adopted.____
>
> ____
>
> My 2c,____
>
> Sasha____
>
> ____
>
> Office: +972-39266302____
>
> Cell: +972-549266302____
>
> Email: alexander.vainsht...@ecitele.com
<mailto:alexander.vainsht...@ecitele.com>
> <mailto:alexander.vainsht...@ecitele.com
<mailto:alexander.vainsht...@ecitele.com>>____
>
> ____
>
> -----Original Message-----
> From: spring <spring-boun...@ietf.org
<mailto:spring-boun...@ietf.org>
> <mailto:spring-boun...@ietf.org
<mailto:spring-boun...@ietf.org>>> On Behalf Of Stewart Bryant
> Sent: Wednesday, February 13, 2019 12:48 PM
> To: Loa Andersson <l...@pi..nu <mailto:l...@pi.nu
<mailto:l...@pi.nu>>>;
> spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
<mailto:spring@ietf.org>>;
> draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>
> <mailto:draft-cheng-spring-mpls-path-segm...@ietf.org
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>>
> Subject: Re: [spring] to progress
> draft-cheng-spring-mpls-path-segment____
>
> ____
>
> I have just read the draft and agree that it should be
> adopted by the WG. It solves an important problem in
> instrumenting and protecting an SR path.____
>
> ____
>
> It should be noted that we needed to do something very
> similar in mainstream MPLS via the synonymous label work
> which is already adopted. ____
>
> However SL did not address the SR case.. We therefore
need
> this path label work to be progressed.____
>
> ____
>
> - Stewart____
>
> ____
>
> On 10/02/2019 08:11, Loa Andersson wrote:____
>
> > Working Group,____
>
> > ____
>
> > I have reviewed
draft-cheng-spring-mpls-path-segment and as far as I ____
>
> > can see, it is ready for wg adoption.____
>
> > ____
>
> > There were some comments in Bangkok, but due to the
many collisions ____
>
> > between working groups at that meeting I couldn't
attend the SPRING ____
>
> > f2f.____
>
> > ____
>
> > The minutes are not clear, but as far as I
understand, there is ____
>
> > nothing that can't be resolved in the wg process.____
>
> > ____
>
> > /Loa____
>
> ____
>
> ___________________________________________________
>
> spring mailing list____
>
> spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
<mailto:spring@ietf.org>>____
>
> https://www..ietf.org/mailman/listinfo/spring____
<http://ietf.org/mailman/listinfo/spring____>
>
>
>
___________________________________________________________________________
>
> This e-mail message is intended for the recipient
only and
> contains information which is
> CONFIDENTIAL and which may be proprietary to ECI
Telecom. If
> you have received this
> transmission in error, please inform us by e-mail,
phone or
> fax, and then delete the original
> and all copies thereof.
>
_______________________________________________________________________________
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
<mailto:spring@ietf.org>>
> https://www.ietf.org/mailman/listinfo/spring____
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
<mailto:spring@ietf.org>>
> https://www.ietf.org/mailman/listinfo/spring
>
--
Loa Andersson email: l...@pi.nu <mailto:l...@pi.nu>
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--
Loa Andersson email: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
