Subject: Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06

From: "lizho.jin" <[email-masked]>
Date: Sat, 14 Oct 2017 01:03:23 +0800

Hi, Authors

I've been asked to do MPLS-RT review. Overall this kind of egress protection is much easy to deploy, and the mechanism is useful, and technically sound.

It is ready to consider for WG adoption. And I still have some questions as below:

1. section 1. " example of such extension is [RSVP-EP]."

Typo? It should be RSVP-TE?

2. section 5.9. The protected egress {E, P} which is called a "context ID" is actually an anycast address, right? The terminology of "anycast" used here will be much clear, but it depends on you to choose.

3. section 5.12. It seems bypass tunnel sharing or facility backup scenario missed in this section.

4. section 8. "On PE3, a context label 100 is assigned to the context ID, "

The label 100 should be assigned to the RSVP-TE tunnel with address of context ID, not only to the context ID, since one-to-one backup is used in this example.

5. section 8.1. "R1 computes a bypass path to 198.51.100.1 while avoiding PE2. "

Could you give more explicit way to achieve above without RSVP-TE protocol extensions?

Regards

Lizhong

On 9/28/2017 01:14，Loa Andersson<[email-masked]> wrote：

Carlos, Eric, Ignas and Lizhong

You have been selected as MPLS-RT reviewers for draft-shen-mpls-egress-

protection-framework-06.

Note to authors: You have been CC'd on this email so that you can know

that this review is going on. However, please do not review your own

document.

Reviews should comment on whether the document is coherent, is it

useful (ie, is it likely to be actually useful in operational networks),

and is the document technically sound?

We are interested in knowing whether the document is ready to be

considered for WG adoption (ie, it doesn't have to be perfect at this

point, but should be a good start). Please remember that it often is

easier to progress the document when it has become a working group

document. All comments in the MPLS-RT review needs to be addressed,

but please think carefully about whether a comment is gating the

adoption or could just as easily be addressed after the adoption.

Reviews should be sent to the document authors, WG co-chairs and WG

secretary, and CC'd to the MPLS WG email list. If necessary, comments

may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what

needs to be resolved before adopting it as a working group document, and

what can wait until the document is a working group document and the

working group has the revision control.

Are you able to review this draft by October 13, 2017? Please respond

whether you are available to do the review in a timely fashion.

Thanks, Loa

(as MPLS WG co-chair)

--

Loa Andersson                        email: [email-masked]

Senior MPLS Expert

Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Yimin Shen <[email-masked]>
Date: Tue, 17 Oct 2017 16:33:28 +0000

Hi, Lizhong

Thanks very much for your kind review! Please see inline for our response.

Thanks,
Yimin Shen
Juniper Networks

From: "lizho.jin" <[email-masked]>
Date: Friday, October 13, 2017 at 1:03 PM
To: loa <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "'Carlos Pignataro (cpignata)'" <[email-masked]>, 'Eric Gray' <[email-masked]>, Ignas Bagdonas <[email-masked]>, mpls-chairs <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Jeyananth <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Friday, October 13, 2017 at 1:04 PM

Hi, Authors

[yshen] This is supposed to refer to draft-ietf-teas-rsvp-egress-protection, which is missing in the reference section. We will add it.

[yshen] The section 5.9 describes context ID strictly from reachability’s perspective. We want to avoid the word “anycast”, because a context ID should not be used in anycast. IOW, it should not be the destination address in any IP headers.

[yshen] The section 5.12 does talk about bypass sharing at the beginning. Bypass sharing is also talked about in some other sections. This framework does not use facility backup.

[yshen] The context label is assigned to the context ID. If any RSVP tunnel is destined to the context ID, yes, it will automatically get bound to the context label as well. 

[yshen] Section 5.10 and 5.11.

Regards
Lizhong

Thanks, Loa 
(as MPLS WG co-chair) 
--

---

From: "lizho.jin" <[email-masked]>
Date: Thu, 19 Oct 2017 23:05:23 +0800

Hi Yimin

Thanks for the reply. See inline below.

Regards

Lizhong

On 10/18/2017 00:33，Yimin Shen<[email-masked]> wrote：

Hi, Lizhong

Thanks,

Yimin Shen

Juniper Networks

Hi, Authors

[Lizhong] this section talks about the label swapping operation on PLR, and I do not see similar words for bypass tunnel sharing. I consider the bypass tunnel sharing as similar mechanism of facility backup, is that correct?

[Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same context label will be used for the two RSVP-TE bypass tunnel, right? In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream labels assigned from different ingress if there are two P2MP share one of the same egress.

Regards

Lizhong

protection-framework-06.

document.

Thanks, Loa

(as MPLS WG co-chair)

--

Senior MPLS Expert

---

From: Yimin Shen <[email-masked]>
Date: Tue, 24 Oct 2017 14:19:27 +0000

Hi Lizhong,

Thanks for the comments. Please see below for [yshen_1].

[yshen_1] Yes, that is correct. The description in this section is generic and applicable to the case of bypass tunnel sharing. We can add text to mention this.

[yshen] The context label is assigned to the context ID. If any RSVP tunnel is destined to the context ID, yes, it will automatically get bound to the context label as well.
[Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same context label will be used for the two RSVP-TE bypass tunnel, right?

[yshen_1] Correct.

In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream labels assigned from different ingress if there are two P2MP share one of the same egress.

[yshen_1] Not sure about the septic case of P2MP LSP using upstream labels. In general, a PLR should pop all the labels of a transport tunnel, before sending a packet (with only a service label) through a bypass tunnel to a protector.

Thanks,

-- Yimin

From: "lizho.jin" <[email-masked]>
Date: Thursday, October 19, 2017 at 11:05 AM
To: Yimin Shen <[email-masked]>
Cc: loa <[email-masked]>, "[email-masked]" <[email-masked]>, "'Carlos Pignataro (cpignata)'" <[email-masked]>, 'Eric Gray' <[email-masked]>, Ignas Bagdonas <[email-masked]>, mpls-chairs <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Yimin

Regards
Lizhong
On 10/18/2017 00:33，Yimin Shen<[email-masked]><mailto:[email-masked]> wrote：
Hi, Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 24 Oct 2017 15:03:41 +0000

Hi all,
I have looked up RFC 4875<https://tools.ietf.org/html/rfc4875> that defines setup of P2MP LSPs using RSVP-TE and found the following text  in section 6.2 (irrelevant text is skipped):

   As usual, the Resv message carries the label allocated by the

   egress LSR.

        ...

   A node upstream of the egress node MUST allocate its own label and

   pass it upstream in the Resv message.

        ...

   The node that sends the Resv message, for a P2MP LSP, upstream MUST

   associate the label assigned by this node with all the labels

   received from downstream Resv messages, for that P2MP LSP.

IMHO and FWIW, this means that P2MP LSPs set up by RSVP-TE only used downstream-allocated labels - hardly surprising since RFC 4875 has been published in May-2007, while RFC 5331<https://tools.ietf.org/html/rfc5331> (that defines upstream-allocated labels) – only in Aug-2008. And I am not aware of any extensions to RFC 4875 that would result in using upstream-allocated labels in P2MP LSPs that can be set up with RSVP-TE.

At the same time, P2MP and MP2MP LSPs set up by mLDP may use upstream-allocated labels as described in RFC 6389<https://datatracker.ietf.org/doc/rfc6389/?include_text=1>.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: mpls [mailto:[email-masked]] On Behalf Of Yimin Shen
Sent: Tuesday, October 24, 2017 5:19 PM
To: lizho.jin <[email-masked]>
Cc: Ignas Bagdonas <[email-masked]>; [email-masked]; [email-masked]; mpls-chairs <[email-masked]>
Subject: Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

From: "lizho.jin" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 19, 2017 at 11:05 AM
To: Yimin Shen <[email-masked]<mailto:[email-masked]>>
Cc: loa <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "'Carlos Pignataro (cpignata)'" <[email-masked]<mailto:[email-masked]>>, 'Eric Gray' <[email-masked]<mailto:[email-masked]>>, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

From: "lizho.jin" <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 13, 2017 at 1:03 PM
To: loa <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "'Carlos Pignataro (cpignata)'" <[email-masked]<mailto:[email-masked]>>, 'Eric Gray' <[email-masked]<mailto:[email-masked]>>, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, Jeyananth <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Friday, October 13, 2017 at 1:04 PM

Hi, Authors

Regards
Lizhong
On 9/28/2017 01:14，Loa Andersson<[email-masked]<mailto:[email-masked]>> wrote：
Carlos, Eric, Ignas and Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

___________________________________________________________________________

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.
___________________________________________________________________________

---

From: Yimin Shen <[email-masked]>
Date: Tue, 24 Oct 2017 15:48:08 +0000

Hi Sasha,

Thanks for the comment. Yes, RFC 6389<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6389_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=ZzameNNmRJBo1AMtKHH-_cOZlR-Zp2fRoUsoZ65xSWM&e=> describes a case where LDP may use upstream assigned label across a LAN for a P2MP tunnel. In particular, section 6 says the following.

   Ru transmits the MPLS packet using the procedures defined in
   [RFC5331] and [RFC5332].  The MPLS packet transmitted by Ru contains
   as the top label the context label assigned by Ru on the LAN
   interface, Li.  The bottom label is the upstream label assigned by Ru
   to the LDP P2MP LSP.  The top label is looked up in the context of
   the LAN interface (Li) by a downstream LSR on the LAN.  This lookup
   enables the downstream LSR to determine the context-specific label
   space in which to look up the inner label.

For local repair in egress node protection, the “inner/bottom” label of the LDP tunnel is swapped to the label (or label stack) of a bypass tunnel. So, there is really no difference than the case of “down-stream assigned” label. IOW, whether the label is up-/down-stream assigned doesn’t matter.

Thanks,

-- Yimin

From: Alexander Vainshtein <[email-masked]>
Date: Tuesday, October 24, 2017 at 11:03 AM
To: Yimin Shen <[email-masked]>, "lizho.jin" <[email-masked]>
Cc: Ignas Bagdonas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, mpls-chairs <[email-masked]>
Subject: RE: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi all,
I have looked up RFC 4875<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4875&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=pUL9vngZDS914eQ-0W9a8h2s-LnemCXr59z8S94SwNg&e=> that defines setup of P2MP LSPs using RSVP-TE and found the following text  in section 6.2 (irrelevant text is skipped):

   egress LSR.

        ...

        ...

IMHO and FWIW, this means that P2MP LSPs set up by RSVP-TE only used downstream-allocated labels - hardly surprising since RFC 4875 has been published in May-2007, while RFC 5331<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5331&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=W7GZMW6Kf6XeRJTuKwLN3JLDMwg9ReAix-ibVHBAnuM&e=> (that defines upstream-allocated labels) – only in Aug-2008. And I am not aware of any extensions to RFC 4875 that would result in using upstream-allocated labels in P2MP LSPs that can be set up with RSVP-TE.

At the same time, P2MP and MP2MP LSPs set up by mLDP may use upstream-allocated labels as described in RFC 6389<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6389_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=ZzameNNmRJBo1AMtKHH-_cOZlR-Zp2fRoUsoZ65xSWM&e=>.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 24 Oct 2017 15:56:50 +0000

Yimin,
Lots of thanks for the clarification regarding mLDP.

My purpose was mainly to clarify that upstream-allocated labels are not used in P2MP LSPs that are set up by RSVP-TE, so that the original scenario mentioned  by Lizhong,   does not exist.

You have now gone beyond that by explaining that even in the scenarios where upstream-allocated labels can be  encountered, they can be handled as specified in the draft.

I suggest to the corresponding text to the next revision of the draft  (hopefully after it is adopted by the WG).

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Yimin Shen [mailto:[email-masked]]
Sent: Tuesday, October 24, 2017 6:48 PM
To: Alexander Vainshtein <[email-masked]>; lizho.jin <[email-masked]>
Cc: Ignas Bagdonas <[email-masked]>; [email-masked]; [email-masked]; mpls-chairs <[email-masked]>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Sasha,

Thanks,

-- Yimin

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 24, 2017 at 11:03 AM
To: Yimin Shen <[email-masked]<mailto:[email-masked]>>, "lizho.jin" <[email-masked]<mailto:[email-masked]>>
Cc: Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>
Subject: RE: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi all,

   egress LSR.

        ...

        ...

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: mpls [mailto:[email-masked]] On Behalf Of Yimin Shen
Sent: Tuesday, October 24, 2017 5:19 PM
To: lizho.jin <[email-masked]<mailto:[email-masked]>>
Cc: Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; mpls-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Lizhong Jin <[email-masked]>
Date: Wed, 25 Oct 2017 18:18:40 +0800

Sasha,
Sorry, I should say the service over RSVP-TE P2MP LSP, like MVPN in
RFC6513. Thanks for point out this.

to Yimin,
Let me explain my concern again. If two RSVP-TE P2MP LSP is used by two
MVPN service, and two different upstream multicast hops allocate same
upstream label. And the two RSVP-TE P2MP LSP share one egress PE and same
P, then if the two different RSVP-TE tunnel label is switched to the same
context label, how could P distinguish the two different MVPN service with
same upstream label? As we know, the upstream label is per tunnel based
context label space, but the context label space in this draft is per
context ID.

Regards
Lizhong

On Tue, Oct 24, 2017 at 11:56 PM, Alexander Vainshtein <
[email-masked]> wrote:

> My purpose was mainly to clarify that upstream-allocated labels are not
> used in P2MP LSPs that are set up by RSVP-TE, so that the original scenario
> mentioned  by Lizhong,  * does not exist*.
>
>
>
> You have now gone beyond that by explaining that even in the scenarios
> where upstream-allocated labels can be  encountered, they can be handled as
> specified in the draft.
>
>
>
> I suggest to the corresponding text to the next revision of the draft
>  (hopefully after it is adopted by the WG).
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> *From:* Yimin Shen [mailto:[email-masked]]
> *Sent:* Tuesday, October 24, 2017 6:48 PM
> *To:* Alexander Vainshtein <[email-masked]>; lizho.jin <
> [email-masked]>
> *Cc:* Ignas Bagdonas <[email-masked]>; draft-shen-mpls-egress-
> [email-masked]; [email-masked]; mpls-chairs <
> [email-masked]>
> *Subject:* Re: MPLS-RT review draft-shen-mpls-egress-
> protection-framework-06
>
>
>
> Hi Sasha,
>
>
>
> Thanks for the comment. Yes, RFC 6389
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6389_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=ZzameNNmRJBo1AMtKHH-_cOZlR-Zp2fRoUsoZ65xSWM&e=>
> describes a case where LDP may use upstream assigned label across a LAN for
> a P2MP tunnel. In particular, section 6 says the following.
>
>
>
> For local repair in egress node protection, the “inner/bottom” label of
> the LDP tunnel is swapped to the label (or label stack) of a bypass tunnel.
> So, there is really no difference than the case of “down-stream assigned”
> label. IOW, whether the label is up-/down-stream assigned doesn’t matter.
>
>
>
> Thanks,
>
>
>
> -- Yimin
>
>
>
>
>
> *From: *Alexander Vainshtein <[email-masked]>
> *Date: *Tuesday, October 24, 2017 at 11:03 AM
> *To: *Yimin Shen <[email-masked]>, "lizho.jin" <[email-masked]>
> *Cc: *Ignas Bagdonas <[email-masked]>, "draft-shen-mpls-egress-
> [email-masked]" <draft-shen-mpls-egress-
> [email-masked]>, "[email-masked]" <[email-masked]>,
> mpls-chairs <[email-masked]>
> *Subject: *RE: MPLS-RT review draft-shen-mpls-egress-
> protection-framework-06
>
>
>
> Hi all,
>
> I have looked up RFC 4875
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4875&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=pUL9vngZDS914eQ-0W9a8h2s-LnemCXr59z8S94SwNg&e=>
> that defines setup of P2MP LSPs using RSVP-TE and found the following text
>  in section 6.2 (irrelevant text is skipped):
>
>
>
> IMHO and FWIW, this means that P2MP LSPs set up by RSVP-TE only used downstream-allocated labels - hardly surprising since RFC 4875 has been published in May-2007, while RFC 5331 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5331&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=W7GZMW6Kf6XeRJTuKwLN3JLDMwg9ReAix-ibVHBAnuM&e=> (that defines upstream-allocated labels) – only in Aug-2008. And I am not aware of any extensions to RFC 4875 that would result in using upstream-allocated labels in P2MP LSPs that can be set up with RSVP-TE.
>
>
>
> At the same time, P2MP and MP2MP LSPs set up by mLDP may use upstream-allocated labels as described in RFC 6389 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc6389_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=RACb_2-5a7D6F3yJr9p2mhvx8Z06zeGfZ21zgMRj1ms&s=ZzameNNmRJBo1AMtKHH-_cOZlR-Zp2fRoUsoZ65xSWM&e=>.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Yimin Shen
> *Sent:* Tuesday, October 24, 2017 5:19 PM
> *To:* lizho.jin <[email-masked]>
> *Cc:* Ignas Bagdonas <[email-masked]>; draft-shen-mpls-egress-
> [email-masked]; [email-masked]; mpls-chairs <
> [email-masked]>
> *Subject:* Re: [mpls] MPLS-RT review draft-shen-mpls-egress-
> protection-framework-06
>
>
>
> Hi Lizhong,
>
>
>
> 3. section 5.12. It seems bypass tunnel sharing or
> facility backup scenario missed in this section.
>
> [yshen] The section 5.12 does talk about bypass sharing at
> the beginning. Bypass sharing is also talked about in some
> other sections. This framework does not use facility backup.
>
> [Lizhong] this section talks about the label swapping operation on PLR,
> and I do not see similar words for bypass tunnel sharing. I consider
> the bypass tunnel sharing as similar mechanism of facility backup, is that
> correct?
>
>
> [yshen_1] Yes, that is correct. The description in this section is generic
> and applicable to the case of bypass tunnel sharing. We can add text to
> mention this.
>
>
> The label 100 should be assigned to the RSVP-TE tunnel with address of
> context ID, not only to the context ID, since one-to-one
> backup is used in this example.
>
> [yshen] The context label is assigned to the context ID.
> If any RSVP tunnel is destined to the context ID,
> yes, it will automatically get bound to the context label as well.
>
> [Lizhong] It seems I understand you meaning. If there are two RSVP-TE
> bypass tunnel to the same context ID, then same context label will be used
> for the two RSVP-TE bypass tunnel, right?
>
>
>
> [yshen_1] Correct.
>
>
>
> In that case, how about the upstream label in P2MP LSP? It is not possible
> for the P to distinguish different upstream labels assigned from different
> ingress if there are two P2MP share one of the same egress.
>
>
>
> [yshen_1] Not sure about the septic case of P2MP LSP using upstream
> labels. In general, a PLR should pop all the labels of a transport tunnel,
> before sending a packet (with only a service label) through a bypass tunnel
> to a protector.
>
>
>
> Thanks,
>
>
>
> -- Yimin
>
>
>
>
>
> *From: *"lizho.jin" <[email-masked]>
> *Date: *Thursday, October 19, 2017 at 11:05 AM
> *To: *Yimin Shen <[email-masked]>
> *Cc: *loa <[email-masked]>, "draft-shen-mpls-egress-
> [email-masked]" <draft-shen-mpls-egress-
> [email-masked]>, "'Carlos Pignataro (cpignata)'" <
> [email-masked]>, 'Eric Gray' <[email-masked]>, Ignas Bagdonas
> <[email-masked]>, mpls-chairs <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Subject: *Re: MPLS-RT review draft-shen-mpls-egress-
> protection-framework-06
>
>
>
> Hi Yimin
>
> On 10/18/2017 00:33，Yimin Shen<[email-masked]> <[email-masked]>
> wrote：
>
> Hi, Lizhong
>
> To: loa <[email-masked]>, "[email-masked]
> " <[email-masked]>
> Cc: "'Carlos Pignataro (cpignata)'" <[email-masked]>, 'Eric Gray' <
> [email-masked]>, Ignas Bagdonas <[email-masked]>, mpls-
> chairs <[email-masked]>, "[email-masked]" <[email-masked]>
> Resent-To: <[email-masked]>, Jeyananth <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>
> I've been asked to do MPLS-RT review. Overall this kind of
> egress protection is much easy to deploy, and the
> mechanism is useful, and technically sound.
> [yshen] This is supposed to refer to draft-ietf-teas-rsvp-
> egress-protection, which is missing in the reference section. We will add it.
>
>
> 2. section 5.9. The protected egress {E, P} which is called
> a "context ID" is actually an anycast address, right? The
> terminology of "anycast" used here will be much clear, but it depends on you to choose.
>
>
> [yshen] The section 5.9 describes context ID strictly from reachability’s
> perspective. We want to avoid the word “anycast”, because a
> context ID should not be used in anycast. IOW, it should
> not be the destination address in any IP headers.
>
> 3. section 5.12. It seems bypass tunnel sharing or
> facility backup scenario missed in this section.
>
> [yshen] The section 5.12 does talk about bypass sharing at
> the beginning. Bypass sharing is also talked about in some
> other sections. This framework does not use facility backup.
>
> [Lizhong] this section talks about the label swapping operation on PLR,
> and I do not see similar words for bypass tunnel sharing. I consider
> the bypass tunnel sharing as similar mechanism of facility backup, is that
> correct?
>
> The label 100 should be assigned to the RSVP-TE tunnel with address of
> context ID, not only to the context ID, since one-to-one
> backup is used in this example.
>
> [yshen] The context label is assigned to the context ID.
> If any RSVP tunnel is destined to the context ID,
> yes, it will automatically get bound to the context label as well.
>
> [Lizhong] It seems I understand you meaning. If there are two RSVP-TE
> bypass tunnel to the same context ID, then same context label will be used
> for the two RSVP-TE bypass tunnel, right? In that case, how about the
> upstream label in P2MP LSP? It is not possible for the P to distinguish
> different upstream labels assigned from different ingress if there are two
> P2MP share one of the same egress.
>

---

From: Yimin Shen <[email-masked]>
Date: Wed, 25 Oct 2017 12:50:19 +0000

Hi Lizhong,

You are talking about a very specific P2MP service case where service labels are up-stream assigned, i.e. not down-stream assigned by egress routers. This is out of the general scope of this framework.

However, if you do want to study that case, I think you would need to have two context IDs (hence two context labels). On the protector, the two context IDs point to two separate label spaces of the two upstream routers (who assigned the service labels). The same service label (as you mentioned) assigned by the two upstream routers is installed in both label spaces. The PLR needs to establish two bypass tunnels destined for the two context IDs, and use the two bypass tunnels respectively for the two P2MP transport tunnels. Then you should have the egress protection ready.

Thanks,

-- Yimin

From: Lizhong Jin <[email-masked]>
Date: Wednesday, October 25, 2017 at 6:18 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Yimin Shen <[email-masked]>, Ignas Bagdonas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, mpls-chairs <[email-masked]>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Sasha,
Sorry, I should say the service over RSVP-TE P2MP LSP, like MVPN in RFC6513. Thanks for point out this.

to Yimin,
Let me explain my concern again. If two RSVP-TE P2MP LSP is used by two MVPN service, and two different upstream multicast hops allocate same upstream label. And the two RSVP-TE P2MP LSP share one egress PE and same P, then if the two different RSVP-TE tunnel label is switched to the same context label, how could P distinguish the two different MVPN service with same upstream label? As we know, the upstream label is per tunnel based context label space, but the context label space in this draft is per context ID.

Regards
Lizhong

On Tue, Oct 24, 2017 at 11:56 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Yimin,
Lots of thanks for the clarification regarding mLDP.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
Email:   [email-masked]<mailto:[email-masked]>

From: Yimin Shen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 24, 2017 6:48 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; lizho.jin <[email-masked]<mailto:[email-masked]>>
Cc: Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; mpls-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Sasha,

Thanks,

-- Yimin

Hi all,

   egress LSR.

        ...

        ...

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
Email:   [email-masked]<mailto:[email-masked]>

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Lizhong Jin <[email-masked]>
Date: Wed, 25 Oct 2017 21:32:11 +0800

Hi Yimin,

Then back to my original question, the label allocated based on RSVP-TE tunnel ID containing the context ID as the destination IP address is a general case in my view. In that way, per tunnel based context label space could be achieve to adapt any kind of service label, whatever upstream or downstream.

And the rules in this draft to allocate label only based on context ID is a special case, where the first service label MUST be also allocated from the egress PE which P is protected. What's your consideration for this way? Save label switch hardware resource?

Regards

Lizhong

On 10/25/2017 20:50，Yimin Shen<[email-masked]> wrote：

Hi Lizhong,

You are talking about a very specific P2MP service case where service labels are up-stream assigned, i.e. not down-stream assigned by egress routers. This is out of the general scope of
this framework.

However, if you do want to study that case, I think you would need to have two context IDs (hence two context labels). On the protector, the two context IDs point to two separate label
spaces of the two upstream routers (who assigned the service labels). The same service label (as you mentioned) assigned by the two upstream routers is installed in both label spaces. The PLR needs to establish two bypass tunnels destined for the two context
IDs, and use the two bypass tunnels respectively for the two P2MP transport tunnels. Then you should have the egress protection ready.

Thanks,

-- Yimin

From:
Lizhong Jin <[email-masked]>

Sasha,

to Yimin,

Let me explain my concern again. If two RSVP-TE P2MP LSP is used by two MVPN service, and two different upstream multicast hops allocate same upstream label. And the two RSVP-TE P2MP LSP share one egress PE and same P, then if the two different
RSVP-TE tunnel label is switched to the same context label, how could P distinguish the two different MVPN service with same upstream label? As we know, the upstream label is per tunnel based context label space, but the context label space in this draft is
per context ID.

Regards

Lizhong

On Tue, Oct 24, 2017 at 11:56 PM, Alexander Vainshtein <[email-masked]> wrote:

Yimin,

My purpose was mainly to clarify that upstream-allocated labels are not used in P2MP LSPs that are set up by RSVP-TE,
so that the original scenario mentioned  by Lizhong,   does not exist.

You have now gone beyond that by explaining that even in the scenarios where upstream-allocated labels can be  encountered,
they can be handled as specified in the draft.

Regards,

Sasha

Office:
+972-39266302

Cell:
+972-549266302

Email:
[email-masked]

Cc: Ignas Bagdonas <[email-masked]>;

[email-masked];
[email-masked]; mpls-chairs <[email-masked]>

Hi Sasha,

Thanks for the comment. Yes,

RFC 6389 describes a case where LDP may use upstream assigned label across a LAN for a P2MP tunnel. In particular, section 6 says the following.

For local repair in egress node protection, the “inner/bottom” label of the LDP tunnel is swapped to the label (or label stack)
of a bypass tunnel. So, there is really no difference than the case of “down-stream assigned” label. IOW, whether the label is up-/down-stream assigned doesn’t matter.

Thanks,

-- Yimin

From:
Alexander Vainshtein <[email-masked]>

Cc: Ignas Bagdonas <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>, mpls-chairs <[email-masked]>

Hi all,

I have looked up

RFC 4875 that defines setup of P2MP LSPs using RSVP-TE and found the following text  in section 6.2 (irrelevant text is skipped):

egress LSR.

...

...

IMHO and FWIW, this means that P2MP LSPs set up by RSVP-TE only used downstream-allocated labels - hardly surprising since RFC 4875 has been published in May-2007, while RFC 5331 (that defines upstream-allocated labels) – only in Aug-2008. And I am not aware of any extensions to RFC 4875 that would result in using upstream-allocated labels in P2MP LSPs that can be set up with RSVP-TE.

At the same time, P2MP and MP2MP LSPs set up by mLDP may use upstream-allocated labels as described in RFC 6389.

Regards,

Sasha

Office:
+972-39266302

Cell:
+972-549266302

Email:
[email-masked]

From: mpls [mailto:[email-masked]]
On Behalf Of Yimin Shen

Cc: Ignas Bagdonas <[email-masked]>;

[email-masked];
[email-masked]; mpls-chairs <[email-masked]>

Hi Lizhong,

[Lizhong] this section talks about the label swapping operation on PLR, and I do not see similar words for bypass tunnel sharing.
I consider the bypass tunnel sharing as similar mechanism of facility backup, is that correct?

[Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same context
label will be used for the two RSVP-TE bypass tunnel, right?

[yshen_1] Correct.

In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream labels
assigned from different ingress if there are two P2MP share one of the same egress.

[yshen_1] Not sure about the septic case of P2MP LSP using upstream labels. In general, a PLR should pop all the labels of a transport
tunnel, before sending a packet (with only a service label) through a bypass tunnel to a protector.

Thanks,

-- Yimin

From:
"lizho.jin" <[email-masked]>

Cc: loa <[email-masked]>, "[email-masked]" <[email-masked]>,
"'Carlos Pignataro (cpignata)'" <[email-masked]>, 'Eric Gray' <[email-masked]>, Ignas Bagdonas <[email-masked]>,
mpls-chairs <[email-masked]>, "[email-masked]" <[email-masked]>

Hi Yimin

Regards

Lizhong

On
10/18/2017 00:33，Yimin
Shen<[email-masked]> wrote：

Hi, Lizhong

Thanks,

Yimin Shen

Juniper Networks

Hi, Authors

[Lizhong] this section talks about the label swapping operation on PLR, and I do not see similar words for bypass tunnel sharing. I consider
the bypass tunnel sharing as similar mechanism of facility backup, is that correct?

[Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same context label will be
used for the two RSVP-TE bypass tunnel, right? In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream labels assigned from different ingress if there are two P2MP share one of the same egress.

Regards

Lizhong

protection-framework-06.

document.

Thanks, Loa

(as MPLS WG co-chair)

--

Senior MPLS Expert

and all copies thereof.

and all copies thereof.

---

From: Yimin Shen <[email-masked]>
Date: Wed, 25 Oct 2017 13:44:46 +0000

Hi Lizhong,

In any case, you need only one context ID (hence one context ID) for each protected label space on a protector. IOW, the number of context IDs (context labels) is the same as the number of protected label spaces. This number is not tied to the number of transport tunnels involved.

In your specific example, you need two context IDs (context labels), not because you have two transport tunnels, but because you have two protected label spaces (of the two upstream routers who allocated the service labels).

Thanks,

-- Yimin

From: Lizhong Jin <[email-masked]>
Date: Wednesday, October 25, 2017 at 9:32 AM
To: Yimin Shen <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>, Ignas Bagdonas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, mpls-chairs <[email-masked]>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Yimin,

Regards
Lizhong
On 10/25/2017 20:50，Yimin Shen<[email-masked]><mailto:[email-masked]> wrote：
Hi Lizhong,

Thanks,

-- Yimin

Sasha,

to Yimin,

Regards
Lizhong

Regards,
Sasha

Hi Sasha,

Thanks,

-- Yimin

Hi all,

   egress LSR.

        ...

        ...

Regards,
Sasha

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Lizhong Jin <[email-masked]>
Date: Wed, 25 Oct 2017 22:31:05 +0800

Hi Yimin, see inline below.

Lizhong

On 10/25/2017 21:44，Yimin Shen<[email-masked]> wrote：

Hi Lizhong,

In any case, you need only one context ID (hence one context ID) for each protected label space on a protector. IOW, the number of context IDs (context labels) is the same as the number
of protected label spaces. This number is not tied to the number of transport tunnels involved.

In your specific example, you need two context IDs (context labels), not because you have two transport tunnels, but because you have two protected label spaces (of the two upstream routers
who allocated the service labels).

[Lizhong] for the upstream assigned label, we have to rely on the tunnel to provide label space. And for most service over P2MP LSP, the service label is upstream assigned, where the egress protection should not be applied. Please explicitly add some words to describe the limitation or say "out of scope" if you insist current approach.

Thanks,

-- Yimin

From:

Cc: Alexander Vainshtein <[email-masked]>, Ignas Bagdonas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, mpls-chairs
<[email-masked]>

Hi Yimin,

Then back to my original question, the label allocated based on RSVP-TE tunnel ID containing the context ID as the destination IP address is a general case in my view.
In that way, per tunnel based context label space could be achieve to adapt any kind of service label, whatever upstream or downstream.

And the rules in this draft to allocate label only based on context ID is a special case, where the first service label MUST be also allocated from the egress PE which
P is protected. What's your consideration for this way? Save label switch hardware resource?

Regards

Lizhong

On
10/25/2017 20:50，Yimin

Hi Lizhong,

You are talking about a very specific P2MP service case where service labels are up-stream assigned, i.e. not down-stream assigned by egress routers. This is out of the general
scope of this framework.

However, if you do want to study that case, I think you would need to have two context IDs (hence two context labels). On the protector, the two context IDs point to two separate
label spaces of the two upstream routers (who assigned the service labels). The same service label (as you mentioned) assigned by the two upstream routers is installed in both label spaces. The PLR needs to establish two bypass tunnels destined for the two
context IDs, and use the two bypass tunnels respectively for the two P2MP transport tunnels. Then you should have the egress protection ready.

Thanks,

-- Yimin

From:

Sasha,

to Yimin,

Let me explain my concern again. If two RSVP-TE P2MP LSP is used by two MVPN service, and two different upstream multicast hops allocate same upstream label. And the two RSVP-TE P2MP LSP share one egress PE and
same P, then if the two different RSVP-TE tunnel label is switched to the same context label, how could P distinguish the two different MVPN service with same upstream label? As we know, the upstream label is per tunnel based context label space, but the context
label space in this draft is per context ID.

Regards

Lizhong

Yimin,

Regards,

Sasha

Office:
+972-39266302

Cell:
+972-549266302

Email:

Hi Sasha,

For local repair in egress node protection, the “inner/bottom” label of the LDP tunnel is swapped to the label (or
label stack) of a bypass tunnel. So, there is really no difference than the case of “down-stream assigned” label. IOW, whether the label is up-/down-stream assigned doesn’t matter.

Thanks,

-- Yimin

From:

Hi all,

I have looked up

egress LSR.

...

...

Regards,

Sasha

Office:
+972-39266302

Cell:
+972-549266302

Email:

Hi Lizhong,

[Lizhong] It seems I understand you meaning. If there are two RSVP-TE bypass tunnel to the same context ID, then same
context label will be used for the two RSVP-TE bypass tunnel, right?

[yshen_1] Correct.

In that case, how about the upstream label in P2MP LSP? It is not possible for the P to distinguish different upstream
labels assigned from different ingress if there are two P2MP share one of the same egress.

[yshen_1] Not sure about the septic case of P2MP LSP using upstream labels. In general, a PLR should pop all the labels
of a transport tunnel, before sending a packet (with only a service label) through a bypass tunnel to a protector.

Thanks,

-- Yimin

From:

Hi Yimin

Regards

Lizhong

On
10/18/2017 00:33，Yimin

Hi, Lizhong

Thanks,

Yimin Shen

Juniper Networks

Hi, Authors

Regards

Lizhong

protection-framework-06.

document.

Thanks, Loa

(as MPLS WG co-chair)

--

Senior MPLS Expert

and all copies thereof.

and all copies thereof.

---

From: Yimin Shen <[email-masked]>
Date: Mon, 30 Oct 2017 13:17:41 +0000

Hi Lizhong,

In the specific case of P2MP service over P2MP tunnel where you want to avoid ingress replication by using up-stream assigned service label, you will need context IDs on a per <egress router, protector, ingress router> basis. In particular, the “ingress router” is added to the granularity to indicate the ingress router’s label space on the protector.

Since it is a special case, it will not be the focus of this document, but we will add some text to mention and clarify it. Does this approach sound ok to you?

Thanks,

-- Yimin

Date: Wednesday, October 25, 2017 at 10:31 AM

Lizhong
On 10/25/2017 21:44，Yimin Shen<[email-masked]><mailto:[email-masked]> wrote：
Hi Lizhong,

Thanks,

-- Yimin

Hi Yimin,

Regards
Lizhong

Thanks,

-- Yimin

Sasha,

to Yimin,

Regards
Lizhong

Regards,
Sasha

Hi Sasha,

Thanks,

-- Yimin

Hi all,

   egress LSR.

        ...

        ...

Regards,
Sasha

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 31 Oct 2017 06:07:31 +0000

Yimin, Lizhong and all,
From my POV a just saying something like “egress protection of P2MP LSPs is out of scope of this document and left for further study” would be preferable.

This is because mLDP P2MP and MP2MP LSPs (as opposed to RSVP-TE P2MP LSPs) may, under certain circumstances, use upstream-allocated labels (see RFC 6389). My gut feeling (FWIW) is that upstream-allocated LSP labels combined with upstream-allocated service labels can make things much more complex. And the draft, with its current scope, is quite useful.   It would be a pity to postpone its adoption for trying to cover all aspects of upstream-allocated labels in detail.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Yimin Shen [mailto:[email-masked]]
Sent: Monday, October 30, 2017 3:18 PM
To: Lizhong Jin <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; Ignas Bagdonas <[email-masked]>; [email-masked]; [email-masked]; mpls-chairs <[email-masked]>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Lizhong,

Thanks,

-- Yimin

From: Lizhong Jin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 25, 2017 at 10:31 AM
To: Yimin Shen <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Lizhong

Thanks,

-- Yimin

From: Lizhong Jin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 25, 2017 at 9:32 AM
To: Yimin Shen <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Hi Yimin,

Regards
Lizhong

Thanks,

-- Yimin

From: Lizhong Jin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 25, 2017 at 6:18 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: Yimin Shen <[email-masked]<mailto:[email-masked]>>, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Sasha,

to Yimin,

Regards
Lizhong

Regards,
Sasha

Hi Sasha,

Thanks,

-- Yimin

Hi all,

   egress LSR.

        ...

        ...

Regards,
Sasha

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Yimin Shen <[email-masked]>
Date: Tue, 31 Oct 2017 12:34:32 +0000

Hi Sasha,

I agree with your proposal. We can clarify the scope as you suggested.

Thanks,

-- Yimin

From: Alexander Vainshtein <[email-masked]>
Date: Tuesday, October 31, 2017 at 2:07 AM
To: Yimin Shen <[email-masked]>, Lizhong Jin <[email-masked]>
Cc: Ignas Bagdonas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, mpls-chairs <[email-masked]>
Subject: RE: MPLS-RT review draft-shen-mpls-egress-protection-framework-06

Yimin, Lizhong and all,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Lizhong,

Thanks,

-- Yimin

Lizhong

Thanks,

-- Yimin

Hi Yimin,

Regards
Lizhong

Thanks,

-- Yimin

Sasha,

to Yimin,

Regards
Lizhong

Regards,
Sasha

Hi Sasha,

Thanks,

-- Yimin

Hi all,

   egress LSR.

        ...

        ...

Regards,
Sasha

Hi Lizhong,

[yshen_1] Correct.

Thanks,

-- Yimin

Hi Yimin

Regards
Lizhong

Thanks,
Yimin Shen
Juniper Networks

Hi, Authors

Regards
Lizhong

Thanks, Loa
(as MPLS WG co-chair)
--