The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] =?GB2312?B?tPC4tDogUmU6IFttcGxzXSBSZXBseTog?==?GB2312?B?ZHJhZnQtd2VpbGlhbi1tcGxzLWZhc3QtcmVyb3V0ZS1leHQtMDA=?=
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: jiang.weilian@zte.com.cn >.............................................
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, jiang.weilian@zte.com.cn <jiang.weilian@zte.com.cn> 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 <akatlas@gmail.com> > > > 2005-12-22 07:56 > 收件人： IETF MPLS List <mpls@lists.ietf.org>, jiang.weilian@zte.com.cn, kong.yong@zte.com.cn, luo.jian@zte.com.cn, Feng.jun99@zte.com.cn > 抄送： > 主题： 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: helpdesk@zte.com.cn > ************************************************ > > > > > > *********************************************** > 信息安全声明：本邮件包含信息归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 > mpls@lists.ietf.org > 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: helpdesk@zte.com.cn ************************************************ *********************************************** 信息安全声明：本邮件包含信息归发件人所在组织所有， 发件人所在组织对该邮件拥有所有权利。请接收者注意 保密，未经发件人书面许可，不得向任何第 三方组织和个人透露本邮件所含信息的全部 或部分。以上声明仅适用于工作邮件。 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 mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|