Subject: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp

From: Manav Bhatia <[email-masked]>
Date: Fri, 15 Apr 2011 22:33:12 +0530

Hi,

I have posted a new draft:
http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-00.txt

Abstract

There are several applications that require symmetric Multiprotocol
Label Switching (MPLS) path between two points.  This cannot be
achieved with regular MPLS as the LSPs are unidirectional.  If
symmetry is required, a separate LSP in each direction is required for
bidirectional traffic flow.  Generalized MPLS on the other hand, has
provisions for setting up a bidirectional LSP.  This document uses the
extensions introduced for GMPLS and applies it to regular MPLS for
establishing bidirectional LSPs.  Additionally, it also describes how
bi-directional symmetrical Fast Reroute using both one-to-one and
facility backup can be achieved.

Would be great if the WG can provide some feedback on this.

Cheers, Manav

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 13:01:26 -0400

> Would be great if the WG can provide some feedback on this.

Manav,

In practice, FRR provides a fast temporary protection after which a
reroute should occur.  The existing mechanism makes use of a merge
point which is very often further down the working path than the other
side of the repair, as it would be for a transport style segment
protection.  This provides a more efficient use of bandwidth during
the temporary protection for the common case where zero signaled
bandwidth is reserved on the protect path and diffserv marking is
used.

As a result FRR is not symetric but instead results in lower
congestion for the lowest priority service carried (BE, often used for
plain old Internet service).  If the path were symetric, then a
different FRR backup would be needed depending on whether the far end
node failed or the link to that node failed.  If node failure is
assumed, then the backup paths are not symetric.  For example, in
A-B-C-D-E-F, where link C-D fails, C sends to E and D sends to B.

If using FRR it is better to just live with the existing behavior
where protection makes efficient use of capacity, not trying to loop
back to the other side of the fault, is assymetric, and is temporary.

Curtis

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 20 Apr 2011 06:33:25 +0530

Hi Curtis,
> A-B-C-D-E-F, where link C-D fails, C sends to E and D sends to B.

With the mechanism described in this draft when link C-D fails, C will
set up a bi-directional FRR tunnel from C to E. Thus all traffic
arriving from E will get switched to C.Its only the nodes upstream to
the fault that set up the protection tunnel. I should have mentioned
this explicitly in the draft.

> back to the other side of the fault, is assymetric, and is temporary.

What lead me to this work was 1588 or PTP (precision time protocol)
that requires symmetric paths for precise delay measurement and is
used to distribute highly accurate time and frequency information over
IP/MPLS networks. In case of a failure, however temporary, the paths
because of the existing FRR mechanisms would be assymetrical, which
will break 1588 as packets in one direction will follow one path,
while the packets in reverse will follow the other. I wanted to
provide a bidirectional LSP where the FRR would also be bidirectional.
This may result in some non-optimization, buts that probably the cost
of achieving complete symmetry.

Cheers, Manav

---

From: John Smith <[email-masked]>
Date: Wed, 20 Apr 2011 02:10:29 +0100 (BST)

----- Original Message ----
From: Curtis Villamizar <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Sent: Tue, 19 April, 2011 22:31:26
Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp

Manav,

Curtis

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

---

From: John Smith <[email-masked]>
Date: Wed, 20 Apr 2011 02:15:14 +0100 (BST)

Manav,

If you remove FRR as Curtis suggests then you will have a very simple draft 
(basically just your section 2) that will explain how bidirectional LSPs can be 
set up for regular MPLS (as opposed to GMPLS). You could have a small section 
that says bidirectional FRR is not required.

I support having a draft that explicitly says how regular MPLS can set up 
bidirectional LSPs - even if it uses the same mechanism as defined for GMPLS.

Regards,
John

----- Original Message ----
From: Curtis Villamizar <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Sent: Tue, 19 April, 2011 22:31:26
Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp

Manav,

plain old Internet service).  If the path were symetric, then a++

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 23:58:05 -0400

> this explicitly in the draft.

FRR today requires no signaling at the time of failure.

> of achieving complete symmetry.

So for under a second, PTP with get bad information and should be able
to figure out that it is bad.

End-to-end PTP with multiple LSR in the middle is no more accurate
than a purely software based NTP.  In fact, it is less accurate.

This IMHO is clearly not worth the cost.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 20 Apr 2011 00:05:59 -0400

In message <[email-masked]>
John Smith writes:
>  
> Manav,
>  
> If you remove FRR as Curtis suggests then you will have a very simple
> draft (basically just your section 2) that will explain how
> bidirectional LSPs can be set up for regular MPLS (as opposed to
> GMPLS). You could have a small section that says bidirectional FRR is
> not required.
>  
> I support having a draft that explicitly says how regular MPLS can set
> up bidirectional LSPs - even if it uses the same mechanism as defined
> for GMPLS.

Nothing prevents you from doing this now so this draft is not needed.

---

From: [email-masked]
Date: Thu, 21 Apr 2011 13:50:59 +0800

Hi Manav，

In the abstract of your draft, you said " Additionally, it also describes 
how
bi-directional symmetrical Fast Reroute using both one-to-one and
facility backup can be achieved."

I have two questions needs your clarification, they are both about the 
bidirectional FRR:

First, under the node protection condition, if a faliure occurs on the 
link between the upstream PLR and the protected node, such as link B--C in 
figure 3, then the upstream PLR can derect this faliure and do protection, 
but how can the downstream PLR know it also needs to switch to the detour 
lsp?

second, in bypass method, how can the downstream MP(or downstream PLR) 
binds the protected LSP with the bypass tunnel?

best regards,

xuehui

Manav Bhatia <[email-masked]> 
发件人:  [email-masked]
2011-04-16 01:03

收件人
[email-masked]
抄送

主题
[mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp

Hi,

Abstract

Cheers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 21 Apr 2011 14:31:52 +0530

Hi Xuehui,

I should have added text to cover this.

During the failure, the PLR must keep sending Path messages in order for the
protected LSP to keep refreshing the PSB of the MP router for the
protected tunnel. This prevents the protected tunnel from a refresh
time-out. In the case of a facility bypass tunnel, the PLR sends the
Path message for the protected tunnel towards the MP router (NHop or NNHop
router) through the bypass tunnel. This path message is encapsulated with
the bypass tunnel label (like the traffic that is being protected). In
addition to this, the PLR must also modify the first IPv4 sub-object of the
ERO. This is because the original ERO on the egress Path message for the
protected tunnel will contain the IP address of the failed interface. If the
PLR does not replace that IP address with an active IP address of its own,
the MP will reject the refresh as the MP router will consider the IP address
in the failed interface as invalid.

Can we consider a change in the ERO as a trigger for FRR on the downstream
MP?

Alternatively, we could explore using BFD between the PLR-MP (suggested by
Lizhong in an offline discussion).

Cheers, Manav

2011/4/21 <[email-masked]>

> "
> First, under the node protection condition, if a faliure occurs on the link
> between the upstream PLR and the protected node, such as link B--C in figure
> 3, then the upstream PLR can derect this faliure and do protection, but how
> can the downstream PLR know it also needs to switch to the detour lsp?
>
>  *Manav Bhatia <[email-masked]>*

---

From: Autumn Liu <[email-masked]>
Date: Thu, 21 Apr 2011 13:14:46 -0400

Manav,

The fact that PATH message of the protected LSP is received on new interface on the MP indicates that FRR is in use on the forward direction and this can be used as a trigger to switch over on the MP for backward direction. However this method or other method with control message notification are most likely not able to achieve 50 ms switch over time.
How about running BFD on the bypass tunnel with new notification to trigger the switch over on other end when one end has FRR failure switch over.

Regards,
Autumn

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manav Bhatia
Sent: Thursday, April 21, 2011 2:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] draft-bhatia-mpls-rsvp-te-bidirectional-lsp

Hi Xuehui,

During the failure, the PLR must keep sending Path messages in order for the protected LSP to keep refreshing the PSB of the MP router for the protected tunnel. This prevents the protected tunnel from a refresh time-out. In the case of a facility bypass tunnel, the PLR sends the Path message for the protected tunnel towards the MP router (NHop or NNHop router) through the bypass tunnel. This path message is encapsulated with the bypass tunnel label (like the traffic that is being protected). In addition to this, the PLR must also modify the first IPv4 sub-object of the ERO. This is because the original ERO on the egress Path message for the protected tunnel will contain the IP address of the failed interface. If the PLR does not replace that IP address with an active IP address of its own, the MP will reject the refresh as the MP router will consider the IP address in the failed interface as invalid.

Can we consider a change in the ERO as a trigger for FRR on the downstream MP?

Alternatively, we could explore using BFD between the PLR-MP (suggested by Lizhong in an offline discussion).

Cheers, Manav

2011/4/21 <[email-masked]<mailto:[email-masked]>>

Hi Manav，

In the abstract of your draft, you said " Additionally, it also describes how

I have two questions needs your clarification, they are both about the bidirectional FRR:

First, under the node protection condition, if a faliure occurs on the link between the upstream PLR and the protected node, such as link B--C in figure 3, then the upstream PLR can derect this faliure and do protection, but how can the downstream PLR know it also needs to switch to the detour lsp?

second, in bypass method, how can the downstream MP(or downstream PLR) binds the protected LSP with the bypass tunnel?

best regards,

xuehui

Manav Bhatia <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2011-04-16 01:03

收件人
        [email-masked]<mailto:[email-masked]>
抄送

主题

Hi,

Abstract

Cheers, Manav
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 21 Apr 2011 11:00:22 -0700

Dear Manav,
I'd point that using control plane as trigger for protection switchover will
make bi-directional FRR un-applicable to MPLS-TP networks, at least to those
TP networks that will not be using control plane. I think that trigger must
be in the data plane if we want to make this mechanism applicable to MPLS,
not limited to non-TP networks. Perhaps G-ACh based PSC solution is more
suitable.

Regards,
Greg

2011/4/21 Manav Bhatia <[email-masked]>

> During the failure, the PLR must keep sending Path messages in order for
> the protected LSP to keep refreshing the PSB of the MP router for the

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 22 Apr 2011 06:11:04 +0530

Hi Greg and Autumn,

I agree that a control plane mechanism to trigger FRR at the downstream PLR
will not be sufficient to guarantee 50ms failover. Let me work on that and
i'll update the draft to use a data plane mechanism like FRR to do this.

Cheers, Manav

2011/4/21 Greg Mirsky <[email-masked]>

> Dear Manav,
> I'd point that using control plane as trigger for protection switchover
> will make bi-directional FRR un-applicable to MPLS-TP networks, at least to
> those TP networks that will not be using control plane. I think that trigger
> must be in the data plane if we want to make this mechanism applicable to
> MPLS, not limited to non-TP networks. Perhaps G-ACh based PSC solution is
> more suitable.
>
> Regards,
> Greg
>
>

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 22 Apr 2011 07:04:17 +0530

Hi Xuehui,

>
> <xuehui>: From my understanding, the ERO may is not suitable to be used as
> a trigger for FRR, since when a node receives a path message containing an
> ERO, it will check  if this node is part of the abstract node described by
> the first subobject, and finally will replace the first subobject with any
> subobject that denotes an abstract node containing the next hop, for this
> point, please see section 4.3.4.1 of RFC3209. so, the MP node will not know
> the IP address changes  of the PLR.  Further, it can't acheive fast
> switching, such as 50ms.
>

In case of a facility bypass tunnel, the PLR sends the PATH message for the
protected LSP towards the MP through the bypass tunnel by encapsulating the
PATH message with the bypass tunnel label (like the data traffic). In the
PATH message the PLR must modify the first IPv4 subobject of the ERO since
the original ERO will be containing the IP address of the interface that has
gone down. If the PLR doesnt change this address with an active interface of
its own the MP will reject the refresh as it will find the interface address
to be invalid. The PLR, must thus modify the ERO before sending out the PATH
message. I was initially thinking of using this change as the trigger for
the MP to switch to the FRR path, but i agree that this will take more than
50ms, and something in the data plane should be used. I will work on this in
the next revision.

> <xuehui> where is the BFD running on？ the protected lsp or the bypass
> tunnel? can you clarify it to me? thanks!
>

Between the MP and the PLR - needs some more thought.

>
> Besides, you haven't answer my second question, that is how can the MP
> knows which is the bypass tunnel it should switch to? since, the bypass
> tunnel is created by the upstream PLR, how can the MP bind with the same
> bypass tunnel?
>

Since the bypass tunnel is itself a bi-directional tunnel the MP will know
that it can use this tunnel to send the traffic back to the upstream PLR.

Cheers, Manav