The MPLS-OPS Archive

[Pavan Beeram <pbeeram@avici.com>]

Pls see comments inline...

Smitha Kalyani wrote:

> Hi,
>
> This is with reference to draft-ietf-mpls-rsvp-lsp-fastreroute-01. I have a question about associating a backup LSP with its corresponding protected LSP in One-to-one protection scenario.
>
> According to the sender-template specific method, the protected LSP and the backup LSP have the same Session object and LSP ID and differ only in the IPv4 Tunnel Sender address in the Sender template object. When a merge point gets a Path message for the backup LSP, then it must be able to associate the backup LSP with the LSP it is trying to protect. But the Merge Point (MP) could also get a path message for a normal LSP with the same Session object and LSP ID as that of the protected LSP, and differing only in the IPv4 tunnel sender address. In this scenario, the MP might associate the normal path with a protected LSP.
>
> If we consider the following scenario, that 2 different senders use the same Session object and LSP ID for 2 LSPs
> 1. Both are protected or one of them is protected
> 2. Both have the same ERO from the MP onwards
> 3. A PLR has originated a backup path for the protected
>
> Then how are the backup and protected LSPs associated?
> Is this scenario possible?

yep, theoretically this scenario is possible, if both the senders decide
to fill in all zeros in the Extended Tunnel ID field of the SESSION.
I am not really aware of any implementation which does that.
Ideally the sender's IPv4 address should be filled in here as a globally
unique identifier. Not sure why anyone doing TE wouldn't want to do
that. If this is done, there should be no confusion at the merge point.

Having said that, suppose there are implementations which do that,
the net result of this would be the occurence of some unwarranted
merging at nodes which were not meant to be merge nodes. Local
protection might still work with only one side-effect. When a Resv
Tear is received at the merge point (which is not locally protected
- no backup to fall on], it would propogate the Resv Tear upstream
and also to all those backups that are merged into it. So this would
mean that some LSPs which were not supposed to get the Resv
Tear end up getting it.

If Iam not making it clear enough, consider the following figure
__________
|         |
|    A----B
|    |    |
C----D----E----F

Say there are 2 LSPs
L1 - CDEF
L2 - ABEF

You mentioned 2 cases...
[A] One of them is protected.

Say CDEF is protected and ABEF is not. If they meet the conditions
that you put forth, they would end up merging at E. CDEF is the
primary, so it gets refreshed downstream. Both continue to stay up.
No problem until a Resv Tear comes in for L1(CDEF) at E, this
gets propogated to L2  (ABEF) as well, even though it shouldnt.

[B] Both are protected.

Say the backup at C takes CBEF and the backup at A takes
ADEF. Ideally both the backups should merge with their respective
primaries at E. But given ur conditions, the backup at C(for L1)
would end up merging with L2 at B and the backup at A (for L2)
would end up merging with L1 at D. Even though this is not desirable,
both the backups would still come up and local -protection would
still continue to work for both the LSPs. Again, the drawback is
with the Resv Tear. Say D receives a Resv Tear for L1 or B
receives a Resv Tear for L2. Either case, the Resv Tear gets
propogated for unrelated backups - which is not desirable.

So here is the bottom line - it is advisable that to make things really
work for all corner cases in an inter-operable fast reroute network,
the Extended Tunnel ID field in the SESSION object be filled
in with a unique global identifier.

-Pavan



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml