Subject: [mpls] draft-weilian-mpls-fast-reroute-ext-00

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Dec 2005 15:56:21 -0800

On reading the introduction of this draft, I am unclear about the
motivation and problem that it is trying to solve.  The draft says:

"However, for N:1 backup, after the protected tunnel switches to the
backup tunnel, the protocol state should still be refreshed through
sending protocol messages of the protected tunnel along the path of
backup tunnel. Once FRR switchover occurs, abundant Refresh messages
of the protected tunnel are transmitted along the path of backup
tunnel, intermediate and tail nodes of the backup tunnel will allocate
abundant useless labels."

As I understand the bypass tunnel mechanism, the Refresh messages for
the protected tunnels are sent to the merge node via the backup
tunnel; this means that the Refresh messages are encapsulated and not
seen by the intermediate nodes of the backup tunnel.
When the refresh message is seen by the tail node of the backup tunnel
(which is the MP), the MP will look-up the state and label assigned to
the associated protected LSP and refresh the state and provide the
label back.

I don't see that there is any allocation of useless labels.  Could you
clarify an example where this happens?  In particular, could you pull
the problem from RFC4090?

Thanks,
Alia

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

---

From: [email-masked]
Date: Tue, 27 Dec 2005 13:50:45 +0800

Thanks a lot for Alia’s opinions!

There are two purposes in our proposal:
1. We think that there is no need for establishing PSB、RSB and 
allocating labels for the protected tunnel along the path of the 
bypass tunnel. And it looks like both of us agree on this point 
from Alia’s email. In RFC 4090, it says PLR sends the control 
traffic for the protected LSP onto the bypass tunnel, and the 
intermediate nodes of the backup tunnel will not allocate labels 
for the protected tunnel. So we have mistakes about the bypass 
tunnel mechanism, we will correct them.

2. We also think there is no need for transmitting the Refresh 
messages for the protected tunnels through the bypass tunnel. We 
know that in RFC4090, it says PLR needs to send the control 
traffic for the protected LSP onto the bypass tunnel. Maybe the 
Refresh messages are encapsulated as normal labeled data and 
transmitted in the bypass tunnel. But as in our extensions to the 
Fast Reroute (FRR) mechanism of Facility Backup defined in RFC4090, 
PLR and MP nodes can refresh the protocol state of protected tunnel 
by the Refresh messages of bypass tunnel, so there is not any extra 
spending on sending the control traffic for the protected LSP onto 
the bypass tunnel.

In the present draft, our extensions only consider the global label 
spaces mode. But with a little modification, we can also support 
per-interface label spaces mode. Based our present extensions, after 
the relation between the protected tunnel and the bypass tunnel being 
confirmed at MP node, MP node will have the input- interface of the 
protected tunnel while link or/and node failure occurs（that is, the 
input- interface of the bypass tunnel）. If the MP node is per-interface 
label spaces mode, we want the MP node to fill the label for the 
corresponding interface into MP_NOTIFY_ACK object, and it will be carried 
by the RESV messages sent to the PLR node. Then PLR node can discover the 
appropriate MP label. Now, we can also support per-interface label spaces 
mode.

Regard,
Jiang Weilian

Alia Atlas <[email-masked]>

2005-12-22 07:56
 
        收件人：        IETF MPLS List <[email-masked]>, 
[email-masked], [email-masked], [email-masked], 
[email-masked]
        抄送： 
        主题：  draft-weilian-mpls-fast-reroute-ext-00

Thanks,
Alia

************************************************
The email has  been scanned by Anti-Spam
system,  if you find Spam or Virus in this mail,
please forward it to: [email-masked]
************************************************

***********************************************
信息安全声明：本邮件包含信息归ZTE所有，
ZTE对该邮件拥有所有权利。请接收者注意
保密，未经发件人书面许可，不得向任何第
三方组织和个人透露本邮件所含信息的全部
或部分。以上声明仅适用于工作邮件。
Information Security  Notice：
The information contained in this mail is
solely property of  ZTE Corporation. 
This mail communication is confidential.
Recipients named above are obligated to
maintain secrecy and are not permitted to
disclose the contents of this communication
to others.
***********************************************
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 27 Dec 2005 12:01:37 -0500

Jiang,

You mentioned two purposes for making changes to the
"facility backup" technique.
(1) To remove the need for establishing state blocks
and allocating labels for the protected tunnel along
the path of the bypass tunnel.
(2) To remove the need for transmitting Refresh
messages for the protected tunnel through the
bypass tunnel.

In the "facility backup" technique, (as Alia mentioned)
the control messages for the protected LSPs are sent
through the bypass tunnel and are not visible on the
transit nodes along the path of the bypass tunnel.
There are no unnecessary PSBs/RSBs/Labels being
allocated along the path of the bypass tunnel. This
effectively means that purpose (1) does not
really serve anything.

I'm also not sure if I understand the motivation behind
the second purpose (to remove the need to transmit
Refresh messages for the protected tunnel through the
bypass tunnel). The basic idea behind the concept
of bypass tunnels is to improve scalability. As per
RFC4090, the transit nodes along the path of the bypass
tunnel are oblivious of all the protected LSPs that the
bypass tunnel is protecting. With your proposal,
these transit nodes come into play when a failover
occurs and they have to process all the trigger messages
that are generated by the PLR whenever the FRR_SWITCH
object gets updated (if the bypass provides protection
for n LSPs, the FRR_SWITCH object would have n sub-objects
and any change to any of these sub-objects would have to
be processed all along the path of the bypass tunnel).

The only downside  to the "facility backup" technique
discussed in RFC4090 is that the merge node
might end up receiving lots of messages on one interface
(as opposed to being distributed on multiple) after the
failover. I dont think this is an issue but is one area
where some optimization would be useful. Your draft scores
here but it does come with an overhead of its own and that
sort of undermines its utility.

Let me know if I missed anything.

- Vishnu Pavan
Movaz Networks

On 12/27/05, [email-masked] <[email-masked]> wrote:
>
> Thanks a lot for Alia's opinions!
>
> from Alia's email. In RFC 4090, it says PLR sends the control
>         收件人：        IETF MPLS List <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
>         抄送：