Re: [mpls] Note on p2mp ingress and egress protection proposals

Hi Greg,

Can you briefly summarize what part of the problem ICCP is solving and why
you think it can be improved to offer fast protection?  From a quick glance
at the first couple pages, it looks like it does the state coordination for
the service - but not setting up the transport LSPs??

The RSVP-TE ingress protection draft describes different failure detection
modes so that the appropriate action on detecting a failure is clearly
agreed before the failure occurs.

Handling a failure in a non fast fashion is fairly rivial; for instance,
the backup ingress could run BFD to the ingress node's loopback and see if
it fails after the network has converged.

I do think that there are basic RSVP-TE mechanisms required to set up the
backup LSPs, indicate the traffic to insert, and what type of failure
detection will be used.  Those seem to require standardization for
interoperability - not just informational.

Perhaps you can more clearly describe what you are proposing?  Of course,
if you already have a draft written, please just point me at it.

Regards,
Alia

On Tue, Dec 17, 2013 at 12:11 PM, Gregory Mirsky <
gregory.mirsky@ericsson.com> wrote:

>  Dear All,
>
> I’ve been following these proposals for a quite some time and actively
> participated in the discussion with authors. I do believe that both
> scenarios represent use of redundancy and hence explicit coordination of
> Active/Standby roles is required. That certainly would simplify OAM for
> both cases. And I believe that ICCP is good candidate for coordination
> within Redundancy Group. Though it would hardly be “fast protection” then.
>
> Hence I believe that all pieces needed to address both scenarios already
> exist and Informational documents may be needed if anything at all.
>
>
>
>                 Regards,
>
>                                 Greg
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>