[mpls] Comments to draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01

"Zengxinzong (Paul)" <zengxinzong@huawei.com> Thu, 13 June 2013 12:53 UTC

From: "Zengxinzong (Paul)" <zengxinzong@huawei.com>
To: "mpls@ietf.org" <mpls@ietf.org>, "zali@cisco.com" <zali@cisco.com>, "rgandhi@cisco.com" <rgandhi@cisco.com>, "tsaad@cisco.com" <tsaad@cisco.com>, "y.kamite@ntt.com" <y.kamite@ntt.com>, "robert.h.venator.civ@mail.mil" <robert.h.venator.civ@mail.mil>
Thread-Topic: Comments to draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01
Thread-Index: Ac5oNPRPEcUj4e5gSdK7l002xkcB1Q==
Date: Thu, 13 Jun 2013 12:53:10 +0000
Message-ID: <54B334E2F9AB214C80ABE154F4E754792AF225F5@nkgeml507-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_54B334E2F9AB214C80ABE154F4E754792AF225F5nkgeml507mbschi_"
MIME-Version: 1.0
Cc: Loa Andersson <loa@pi.nu>
Subject: [mpls] Comments to draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01
Precedence: list

Dear Authors,

I've prepared some comments and I hope you'll kindly consider:

1. In RFC 4875, it is not clearly defined the remerge behavior, some implementation will accept remerge and some will not based on local policy.

- From section 4.3:
When a node that does not support data plane based re-merge handling
receives an S2L sub-LSP Path message with LSP Attributes sub-object
that has "P2MP-TE Re-merge Recording Request" Flag set, and if the
S2L is causing a re-merge condition, the node MUST reject the S2L
sub-LSP Path message and send the PathErr with the error code
"Routing Problem" and the error value "ERO resulted in re-merge" as
specified in [RFC4875].

In this draft section 4.3, it says must send PathErr when remerge happened, if the implementation do not support this draft, the behavior is discard the "P2MP-TE Re-merge Recording Request" Flag and do not send PathErr back, so it will cause backward compatibility issue.

I think the default behavior of remerge process should not be changed.

2. From section 3.2:
If the ingress node receives a PathErr message with error code
"Routing Problem" and error value "ERO resulted in re-merge", then it
SHOULD attempt to signal an alternate path through a different domain
or through a different border node for the affected S2L sub-LSPs.

When CSPF calculate for the affected S2L sub-LSPs, the un-affected S2L sub-LSPs path maybe also be changed. Each calculation of CSPF must consider all the S2L sub-LSPs, so in some scenario the un-affected S2L sub-LSPs change cannot be avoided.
If the affected and un-affected S2L sub-LSPs do the crank-back process, it maybe cause new remerge and fall in a deadlock. How to solve this?

3. From section 3.1: Single Border Node For All S2Ls

I think double border node is very common in the inter area, so if restrict to single border node, it seems not meet most requirement.

4. From section 6, LSP reoptimization and Sub-LSP reoptimization is different, I think we need to clarify when to do the lsp reoptimization and when do the Sub-LSP reoptimization, it seems very confusing here.

Regards,
Paul zeng

[mpls] Comments to draft-ietf-mpls-inter-domain-p… Zengxinzong (Paul)