Greg,
On 2019-02-23 12:31, Greg Mirsky wrote:
Hi Loa,
another tunnel with the Path segment from node C is, in my view, very
close to SPME tunnel. The Path segment from C is needed because Path
segment from D is not known to the node C, cannot be associated with the
right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be
achieved by using exactly the same SIDs as in the A-D tunnel for the B-C
segment. And GAL is still BoS on B-C tunnel. Are we getting closer?
Not sure, you lose me somewhere between the "B", "C", "D", "from" and
"another".
So let me check I was talking about
So the stack transporting payload from B-C looks like this:
+------------+
~B->C SubPath~
+------------+
|s-PSID(B->C)|
+------------+
| BSID(C->D) |
+------------+
|e-PSID(A->D)|
+------------+
figure 1
The "~" at the top means that there might be more than one label that
can be popped or swapped, right?
So the stack transporting GACh from B-C looks like this:
+--------------+
~ B->C SubPath ~
+--------------+
| GAL |
+--------------+
| GACh info-1 |
+--------------+
| GACh info-2 |
+--------------+
figure 2
Now my question is the "B->C SubPath" in the first figure identical
to the "B->C SubPath" in the second figure?
Now
--
Regards,
Greg
On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson <l...@pi.nu
<mailto:l...@pi.nu>> wrote:
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>
> <mailto: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>>
> > <mailto: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>>
> > <mailto: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>>
> > <mailto:gregimir...@gmail..com
<mailto:gregimir...@gmail.com>
> <mailto:gregimir...@gmail.com <mailto:gregimir...@gmail.com>>>]
> > *发送时间:*2019年2月15日3:37
> > *收件人:*Alexander Vainshtein
> > *抄送:*spr...@ietf..org <mailto:spring@ietf.org>
<mailto:spring@ietf.org <mailto:spring@ietf.org>>
> <mailto: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>>
> >
<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
<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>>>;
> > m...@ietf.org <mailto:m...@ietf.org> <mailto:m...@ietf.org
<mailto:m...@ietf.org>> <mailto: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>
> <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>>
> > <mailto: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>>
> > <mailto: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>
> <mailto:l...@pi.nu <mailto:l...@pi.nu>>>>;
> > spring@ietf.org <mailto:spring@ietf.org>
<mailto:spring@ietf.org <mailto:spring@ietf.org>>
<mailto: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>>
> >
<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
<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>>
<mailto: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____>
> <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>>
<mailto: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>>
<mailto: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> <mailto: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 <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
