The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Reply: draft-weilian-mpls-fast-reroute-ext-00
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
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
|
|