Subject: [CCAMP] requirements on establishing an associated bi-directional LSP

From: Loa Andersson <[email-masked]>
Date: Fri, 05 Aug 2011 10:49:04 -0700

CCAMP and MPLS working groups,

The CCAMP working group has a working group document
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01.

The document specifies a way of establishing an associated
bi-directional LSP based on single ended signaling as well
as to associate two unidirectional LSPs. There is a requirement
in RFC5654:

     50  The MPLS-TP control plane MUST support establishing all the
         connectivity patterns defined for the MPLS-TP data plane (i.e.,
         unidirectional P2P, associated bidirectional P2P, co-routed
         bidirectional P2P, unidirectional P2MP) including configuration
         of protection functions and any associated maintenance
         functions.

The MPLS working group owns the requirements for transport LSPs, while
CCAMP owns definition of GMPLS extensions.

If you have comments on the above requirements as it relates to this
draft, please send you comments to the MPLS WG list. If you have
comments on the proposed mechanism, please send your comments to the
ccamp WG list.

MPLS and CCAMP working group co-chairs

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: [email-masked]
Date: Mon, 8 Aug 2011 17:57:36 +0800

Hi all

I gave two presentations in the past IETF81 meeting, one is in the MPLS WG 
discussing the requirements, and the other is in CCAMP session discussing 
the solution.

the presentation materials for reference are here.
http://tools.ietf.org/wg/mpls/agenda
http://tools.ietf.org/wg/ccamp/agenda

The requirement (R50 in RFC5654) did not specify the exact solution, and 
the definition of associated bidirectional transport path said that "The 
forward and backward directions are setup, monitored, and protected 
independently ".

My opinion about the requirement and definition is listed below, 

(1) what is the indication of independence? It means that one direcion can 
not tigger the establishment of the other direction? Or It just means that 
there are two signaling procedures? Since MS-PW is a kind of associated 
bidirectional transport path, I tend to interpretate the definition as the 
second case 

As to the solution:

(2) Since MPLS-TP MUST support asymmetric bandwith LSPs (R14), consider 
the following topology:
                                100M      100M
                             A----------D-------B
                              \ 50M    /  100M
                          100M \60M   /100M
                                \    /
                                 \ C/
One bidirectional LSP with 80M symmetric bandwidth needs to be set up 
between node A and B, the unreserved bandwidth on the links are 
descripted.

the path along [A-D-B] can not meet the requirement for the unreverved 
bandwidth on link[D->A] is 50M. But the combination of [A->D->B] and 
[B->D->C->A] can 
meet the requirement well.

In this case, the single sided provisioning will be more convenient in 
MPLS enviroment.

Hope to hear more comments or suggestions from WG

Best regards

Fei

Loa Andersson <[email-masked]> 
发件人:  [email-masked]
2011-08-06 01:49

收件人
[email-masked], "[email-masked]" <[email-masked]>
抄送

主题
[mpls] requirements on establishing an associated bi-directional LSP

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: John Smith <[email-masked]>
Date: Mon, 8 Aug 2011 14:06:33 +0100 (BST)

Hi,

Is this related to the bi-directional LSP draft that was presented in Quebec?

http://tools.ietf.org/html/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-01

The above draft discusses FRR that seems to be missing from the ccamp wg draft?

John

----- Original Message ----
From: Loa Andersson <[email-masked]>
To: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Fri, 5 August, 2011 23:19:04
Subject: [mpls] requirements on establishing an associated bi-directional LSP

--

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 8 Aug 2011 15:42:52 +0100

Fei,

On 8 Aug 2011, at 10:57, [email-masked] wrote:
> Hi all 
> 
> I gave two presentations in the past IETF81 meeting, one is in the MPLS WG discussing the requirements, and the other is in CCAMP session discussing the solution. 
> 
> The requirement (R50 in RFC5654) did not specify the exact solution, and the definition of associated bidirectional transport path said that "The forward and backward directions are setup, monitored, and protected independently ". 

I was one of the folks that pushed for inclusion of associated bi-directional paths in RFC5654 and what I was thinking at the time was something similar to PWs - i.e that although both ingress & egress end points are on the same nodes the path between the ingress and egress may differ for each direction.

"independently" in the text of RFC5654 is not meant to suggest that single sided provisioning of associated bi-directional paths is unacceptable, it just means that you cannot assume that you can provision the forward & backward directions of the path simultaneously in each node (as the forward & backward directions may not traverse the same nodes). The same is true for monitoring & protection.

HTH
Ben
 
> (1) what is the indication of independence? It means that one direcion can not tigger the establishment of the other direction? Or It just means that there are two signaling procedures? Since MS-PW is a kind of associated bidirectional transport path, I tend to interpretate the definition as the second case   
> 
> As to the solution: 
> 
> (2) Since MPLS-TP MUST support asymmetric bandwith LSPs (R14), consider the following topology: 
>                                 100M      100M 
>                              A----------D-------B 
>                               \ 50M    /  100M 
>                           100M \60M   /100M 
>                                 \    / 
>                                  \ C/ 
> One bidirectional LSP with 80M symmetric bandwidth needs to be set up between node A and B, the unreserved bandwidth on the links are descripted. 
> 
> the path along [A-D-B] can not meet the requirement for the unreverved bandwidth on link[D->A] is 50M. But the combination of [A->D->B] and [B->D->C->A] can 
> In this case, the single sided provisioning will be more convenient in MPLS enviroment. 
>

---

From: [email-masked]
Date: Tue, 9 Aug 2011 08:21:32 +0800

Hi John

For clarification

It is about the requirement and solution of associated bidirectional LSP

Below is the link

http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01

Thanks

Fei

John Smith <[email-masked]> 
发件人:  [email-masked]
2011-08-08 21:06

收件人
Loa Andersson <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
抄送
[email-masked], [email-masked], 
[email-masked]
主题
Re: [CCAMP] [mpls] requirements on establishing an associated 
bi-directional LSP

Hi,

Is this related to the bi-directional LSP draft that was presented in 
Quebec?

The above draft discusses FRR that seems to be missing from the ccamp wg 
draft?

John

----- Original Message ----
From: Loa Andersson <[email-masked]>
To: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Fri, 5 August, 2011 23:19:04
Subject: [mpls] requirements on establishing an associated bi-directional 
LSP

-- 

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Tue, 9 Aug 2011 08:45:23 +0800

Hi Ben

Thanks for sharing your idea, this will help us push the related work more 
quickly.

B.R. :-)

Fei

Ben Niven-Jenkins <[email-masked]> 
2011-08-08 22:42

收件人
[email-masked]
抄送
Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>, 
[email-masked], [email-masked]
主题
Re: [mpls] requirements on establishing an associated bi-directional LSP

Fei,

On 8 Aug 2011, at 10:57, [email-masked] wrote:
> Hi all 
> 
> I gave two presentations in the past IETF81 meeting, one is in the MPLS 
WG discussing the requirements, and the other is in CCAMP session 
discussing the solution. 

I was one of the folks that pushed for inclusion of associated 
bi-directional paths in RFC5654 and what I was thinking at the time was 
something similar to PWs - i.e that although both ingress & egress end 
points are on the same nodes the path between the ingress and egress may 
differ for each direction.

"independently" in the text of RFC5654 is not meant to suggest that single 
sided provisioning of associated bi-directional paths is unacceptable, it 
just means that you cannot assume that you can provision the forward & 
backward directions of the path simultaneously in each node (as the 
forward & backward directions may not traverse the same nodes). The same 
is true for monitoring & protection.

HTH
Ben
 
> (1) what is the indication of independence? It means that one direcion 
can not tigger the establishment of the other direction? Or It just means 
that there are two signaling procedures? Since MS-PW is a kind of 
associated bidirectional transport path, I tend to interpretate the 
definition as the second case 
MPLS enviroment.