Subject: 答复: Re: [mpls] Reply: draft-weilian-mpls-fast-reroute-ext-00

From: [email-masked]
Date: Tue, 24 Jan 2006 16:00:21 +0800

Hi,Vishnu

First thanks for your letter, and so sorry for reply too late.

According to your letter, we would like clarify our’s draft as follows:
1、
> 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).

As in our present draft, if the bypass provides protection for n LSPs, and 
when a failover occurs,  the 
FRR_SWITCH object would have n sub-objects in deed. 
But our mechanism is: these transit nodes along the path of bypass Tunnel 
first parse the FRR_SWITCH object 
to get MP Router ID, then use this Router ID to compare with themselves’s 
TE Router ID, if the result is 
not same, it indicates that this node is not the MP node,so there is no 
any more thing need to do(no need to 
care the change to any of these sub-objects) and just send the object to 
the downstream node along the path.

For this, we improve our draft. Because PLR and MP node have confirmed the 
FRR relation between the protected 
tunnel and bypass tunnel by the MP_NOTIFY and MP_NOTIFY_ACK in messages of 
the protected tunnel, so we make 
the FRR_SWITCH and FRR_SWITCH_ACK to be more simpler. All of the two 
objects no need to contain any sub-objects, 
only contain PLR and MP Router ID. So when a failover occurs, PLR use the 
Path messages of bypass tunnel 
containing FRR_SWITCH to notify the FRR switchover to MP, and MP use the 
Resv messages of bypass tunnel containing 
FRR_SWITCH_ACK to notify the acknowledgment to FRR switchover to PLR, and 
then PLR and MP use the messages of bypass 
tunnel to refresh the states of the protected tunnel that has confirmed 
the FRR relation with this bypass tunnel.

2、
> 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.

As Vishnu Pavan say that our draft scores here but it does come with an 
overhead of its own and that sort of 
undermines its utility, we think maybe it is based on first point in 
front.

So through the explanation to the first point, we wish that Vishnu Pavan 
can clearly realize our mechanism does not 
come with an overhead of its own .

Regard,
Jiang Weilian
>............................................... 
>Add:   No.68 Zijinghua Rd,Yuhuatai District, 
>        Nanjing. P.R.China. 
>Zip:   210012 
>Tel:   0086-25-52871644 
>Mail:  [email-masked] 
>............................................. 

Vishnu Pavan Beeram <[email-masked]>

2005-12-28 01:01
 
        收件人：        "[email-masked]" 
<[email-masked]>
        抄送：  Alia Atlas <[email-masked]>, [email-masked], IETF 
MPLS List <[email-masked]>, [email-masked], [email-masked]
        主题：  Re: [mpls] Reply: draft-weilian-mpls-fast-reroute-ext-00

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!
>
> 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
>
>
> 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
>
>
>
>  ************************************************
>  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
>
>
>

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

***********************************************
信息安全声明：本邮件包含信息归发件人所在组织所有，
发件人所在组织对该邮件拥有所有权利。请接收者注意
保密，未经发件人书面许可，不得向任何第
三方组织和个人透露本邮件所含信息的全部
或部分。以上声明仅适用于工作邮件。
Information Security  Notice：
The information contained in this mail is
solely property of  the sender's organization. 
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