Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

[Yimin Shen <[e-mail]>]

Hi Huaimo,

In the traditional RSVP FRR (RFC 4090), an ingress router requests link protection, node protection and/or bandwidth protection by setting some flags in the Path message, and it's the decision of a transit router whether to actually set up FRR, based on its capability, local policy and local topology.

In this draft, the model seems completely ingress-driven. The ingress not only requests FRR, but also pushes an explicit bypass route to the PLR to force to set it up. So I have a doubt whether this is always desirable and possible? IMO, we may not assume that the ingress router can always  have the visibility of the topology of entire network (including the location of protected node, PLR and protector) and the knowledge of local policies of each PLR. For example, there are cases where a P2MP LSP needs to traverse multiple domains, some kind of topology abstraction/hiding is required between domains, and loose hop expansion has to be performed at domain boundaries.

Thanks,

/Yimin


From: mpls [mailto:[e-mail]] On Behalf Of Huaimo Chen
Sent: Thursday, December 12, 2013 8:21 AM
To: [e-mail]
Cc: Raveendra Torvi
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team prior to being polled for WG adoption. The authors have updated the draft according to the comments. We have had responses from some of the reviewers that they are comfortable with how the comments have been addressed. We would like to have the same response from the other two reviewers.

Best Regards,
Huaimo