Subject: Re: draft-kini-mpls-frr-ldp-01 for review

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2011 14:35:27 -0400

In message <[email-masked]>
Sriganesh Kini writes:
>  
> Hello,
>  
> Regarding draft-kini-mpls-frr-ldp-01.
>  
> We had feedback from the mpls WG to present this draft at RTGWG. Since
> our request for a slot was late, there is a chance that we may not
> have adequate time at the end of the session for this draft. In any
> case we wanted to make the WG aware of the draft and would appreciate
> any comments.
>  
> Regards
>  
> - Sri

Protection is inherently a traffic engineering problem.  IPFRR
provides mostly limited coverage protection, without the benefit of
signaled SRLG, and with increased potential of transient route loops
in the abense of complete and accurate SRLG information or when
multiple failures occur that are not covered by SRLG.

LDP FRR has all the same issues as IPFRR.  So in general I don't
support LDP FRR.

Even if I did support an LDP FRR, I don't think this draft offers a
good approach to LDP FRR.

Curtis

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Aug 2011 14:06:58 -0700

Protection requires avoiding failures that can use some path
computation infrastructure that is also useful for TE, but that does
not make it the same as a TE problem.

LDP FRR that relies on IPFRR (LFA) has limited coverage and associated
issues. The proposal is not relying on IPFRR. LDP is widely deployed,
so not supporting fast-reroute for LDP is definitely not a good
choice. Many providers protect LDP traffic today by running it over a
layer of RSVP-TE FRR. That adds complexity and that is what this draft
is trying to solve.

On Wed, Aug 3, 2011 at 11:35 AM, Curtis Villamizar <[email-masked]> wrote:
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

-- 
- Sri

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2011 17:23:27 -0400

In message <[email-masked]>
> layer of RSVP-TE FRR. That adds complexity and that is what this draft

I don't know of any providers that are asking for this solution.

It may be a solution without a problem (and IMHO not a good solution
at that).

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Wed, 3 Aug 2011 17:25:13 -0400

Speaking with the WG chair-hat off:

I, obviously, agree that LDP fast-reroute is a useful feature to have.

This draft, however, appears to trade off the computation of not-via
alternates
by each hop for PLR computation of the not-via and extending LDP to
specifically
signal an explicitly routed alternate.  It adds back in EROs to LDP

This requires more time after a failure to be protected against another one,
because
it depends on signaling the alternates after the failure.  The ability to
troubleshoot the new tunnels would appear necessary.

The concerns with notvia have been related to the state installed in the
forwarding plane, rather than the computation.  In that regard, the only
benefit is not requiring forwarding state for not-via addresses (or labels)
that do not go through a particular node.   However, it potentially adds
state for each PLR that goes through a given node to a particular
next-next-hop.  Understanding the changes in state might be useful.

It suffers from the same issues as not-via in that it requires tunneling and
therefore requires targeted LDP sessions.  It does not address how to handle
multi-homed-prefixes where the next-next-hop is not in the local area.

The basic idea doesn't go beyond LDP unicast, though IP unicast wouldn't be
too hard to do.

The only theoretical benefit appears to be not using RSVP-TE - but I don't
see actual simplification of the created state or operation.  I don't
believe that avoiding RSVP-TE  is its own goal - rather simplification (ok -
1 protocol) and ease of operation are important.

Alia

On Wed, Aug 3, 2011 at 5:06 PM, Sriganesh Kini
<[email-masked]>wrote:

> > In message <
> [email-masked]>
> > Sriganesh Kini writes:
> >>
> >> Hello,
> >>

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Aug 2011 15:05:08 -0700

inline

> signal an explicitly routed alternate.  It adds back in EROs to LDP

The explicit backup-path is used only in cases where shortest-path is
not available. In many common topologies that we analyzed, the
shortest-path is sufficient as backup. Even when a single
shortest-path is insufficient, a combination of shortest-paths
interconnected by a minimal number of explicit label-swap actions are
sufficient.

> troubleshoot the new tunnels would appear necessary.

Multiple failures that are covered within an SRLG are protected when
the first failure occurs. Those that are not covered have a low
probability and/or will have traffic loss till re-computation. With
modern hw the re-computation time should be fairly small. The order of
traffic loss should be the same as that with shortest-path
re-computation.

> next-next-hop.  Understanding the changes in state might be useful.

The presentation (in MPLS WG) described the change in state for some
sample topologies. We are planning to add an applicability
section/draft especially for topologies of interest from service
providers.

> multi-homed-prefixes where the next-next-hop is not in the local area.

The number of targeted LDP sessions is not much in our analysis of
common topologies. Some of the results were presented. Even if number
of LDP sessions is indeed a big concern, the protocol extensions
defined can use explicit routing for label advertisements and avoid
the targeted sessions.

Multi-homed prefixes are handled.  Correct that when going across
areas more topology info and/or more (redundant) link-state
advertisements may be needed.

> The basic idea doesn't go beyond LDP unicast, though IP unicast wouldn't be

This can handle multicast too. But we haven't worked out all the
details/cases yet. The draft will be updated for this.

> 1 protocol) and ease of operation are important.

The simplification of state is mainly due to re-using most of the
existing shortest-path state. Simplification and opex-reduction due to
less protocols is an important practical consideration.

>
> Alia
>
> On Wed, Aug 3, 2011 at 5:06 PM, Sriganesh Kini <[email-masked]>
> wrote:
>>
>> > In message
>> > <[email-masked]>
>> > Sriganesh Kini writes:
>> >>
>> >> Hello,
>> >>

-- 
- Sri

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 3 Aug 2011 18:52:53 -0400

Hi Curtis,

Irrespectively of this draft thanks to GMPLS IGP extensions as per
RFC's 4203 & 5307 SRLG info is there, it is up to implementation how to use it.  

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Wednesday, August 03, 2011 11:35
To: Sriganesh Kini
Cc: [email-masked]
Subject: Re: draft-kini-mpls-frr-ldp-01 for review 

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Aug 2011 19:32:52 -0400

In message <[email-masked]>
> RFC's 4203 & 5307 SRLG info is there, it is up to implementation how

Those are in the extensions for GMPLS which is a superset of RSVP-TE
based MPLS.  These are sub-TLV added to the Link TLV which provides
a good part of the TE-LSDB used by RSVP-TE.  With that you get
available bandwidth at each priority level, the RSVP-TE 32 bit link
attribute vector and other niceties that should have nothing to do
with LDP.

For example, in RFC-3060 where Link TLV is defined for OSPF.

   The following sub-TLVs of the Link TLV are defined:

      1 - Link type (1 octet)
      2 - Link ID (4 octets)
      3 - Local interface IP address (4 octets)
      4 - Remote interface IP address (4 octets)
      5 - Traffic engineering metric (4 octets)
      6 - Maximum bandwidth (4 octets)
      7 - Maximum reservable bandwidth (4 octets)
      8 - Unreserved bandwidth (32 octets)
      9 - Administrative group (4 octets)

That is what is being extended in RFC4203.

So don't run RSVP-TE, just half of it.  Then compute LDP paths?
Sounds too much like CR-LDP to me.

If we reinvent half of RSVP-TE, why not all of it.  OTOH, why not just
run half of it.  Use RSVP-TE LSP with zero BW and MPLS FRR [RFC4090]
and forget LDP except for PW signaling.

Curtis

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Aug 2011 17:01:08 -0700

We are re-using whatever is available and is needed. SRLG info is
needed at the nodes computing paths to protect the SRLG failure. Using
an existing IGP mechanism to do just that is an option. Stretching this to
imply that RSVP-TE is reinvented doesn't make sense. Many service
providers who have LDP deployed simply don't want the additional
complexity of deploying RSVP-TE but they do want sub 50msec protection
with full coverage. Moreover RSVP-TE doesn't scale as well.

-- 
- Sri

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 4 Aug 2011 01:51:40 -0700

On Aug 3, 2011, at 16:34, "Curtis Villamizar" <[email-masked]> wrote:

> forget LDP except for PW signaling

Or better yet, not even for that.

[donning Kevlar]

K

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 09:13:42 -0400

In message <[email-masked]>
> with full coverage. Moreover RSVP-TE doesn't scale as well.

Additional complexity.

  Enable IGP-TE extensions and configure links, minimum is enable TE
  per link and advertise defaults.

  Define a mesh group.

  Configure defaults for mesh group at zero bandwidth and use of FRR.

Done.

That is not much complexity.  The configuration is identical per node,
except per link config since different nodes have different number and
naming of links.  This is both easy to set up and easily manageable.

If later TE is desired, then either set autobandwidth on the mesh
group or capture per LSP traffic measurements and begin configuring
bandwidth amounts per LSP.  The latter takes a small amount of work
but is preferred by many service providers.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 09:42:46 -0400

In message <[email-masked]>
> Or better yet, not even for that.

Yes.  I agree.  With MS-PW it is now time to define a PW signaling
based on RSVP-TE.  But we are not there yet.

The good news is it appears that Kireeti just volunteered.  We look
forward to the -00 draft.  :-)

Thanks,

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 4 Aug 2011 08:02:05 -0700

Hi Curtis,

On Aug 4, 2011, at 6:44, "Curtis Villamizar" <[email-masked]> wrote:

> With MS-PW it is now time to define a PW signaling

Yes, with MS-PW: "EROs" to thread the MS-PW through the stitching points, "Traffic Params" for the MS-PW, and "detours" to protect against failures.

Been there, had the discussions, suggested RSVP-TE, needed the Kevlar. No -00 from me any time soon.

However, since then, (three years ago?), I've come to the conclusion that the MS-PW idea is flawed; the protocol used is secondary. 

(Yes, Alia, doesn't belong on this list. Back to your regularly scheduled IP/LDP FRR sans RSVP debate.)

Kireeti

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 4 Aug 2011 09:00:09 -0700

Inline

- Sri

Sent from my iPad

>> with full coverage. Moreover RSVP-TE doesn't scale as well.

No. Operationally the complexity is similar to running an LDP network.

>  Configure defaults for mesh group at zero bandwidth and use of FRR.

Full mesh is not as scalable.

> but is preferred by many service providers.

Maybe this is true for some providers that you are aware of. But I have seen many providers prefer to run an LDP network and want full coverage protection.

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 4 Aug 2011 11:16:06 -0500

You say that your solution is simpler than a TE deployment, but you're
comparing the wrong things. 

It is possible to use LFA or something similar for the cases where it
works and to use an explicitly routed RSVP-TE path to provide a backup
path for cases where LFA doesn't work.  This is what you ought to
compare to your solution.

How much simpler is your solution than what I've described above?  They
both need
 - link-state information available for explicit paths
 - srlg info available, should one want to use it
 - explicit routing control, even if the paths are dynamically
calculated per PLR

At that point the only difference I see between what RSVP does and what
you want to do with LDP is you have two different protcols.  If you want
to argue that LDP is 'simple' and RSVP is 'complex' you can't take all
the good stuff out of RSVP which gives it its complexity in the first
place, put it in LDP and then argue that LDP is still 'simple'.

Also, CR-LDP is dead.  rfc3468.
What is different between your proposed changes to LDP and what CR-LDP
did?

eric

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sriganesh Kini
> Sent: Thursday, August 04, 2011 12:00 PM
> To: [email-masked]
> Cc: [email-masked]; Sriganesh Kini
> > <[email-masked]>
> > Sriganesh Kini writes:
> >>
> >> needed at the nodes computing paths to protect the SRLG failure.
> >> Using an existing IGP mechanism to do just that is an option.
> >> Stretching this to imply that RSVP-TE is reinvented doesn't make
> >> sense. Many service providers who have LDP deployed simply don't
want
> >> the additional complexity of deploying RSVP-TE but they do want sub
> >> 50msec protection with full coverage. Moreover RSVP-TE doesn't
scale as
> well.
> Maybe this is true for some providers that you are aware of. But I
have
> seen many providers prefer to run an LDP network and want full
coverage
> protection.
> 
> >
> > Curtis
> >
> >
> >
> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar
<[email-masked]>
> >>> In message
<[email-masked]
> >>> son.se>
> >>> If we reinvent half of RSVP-TE, why not all of it.  OTOH, why not
> >>> just run half of it.  Use RSVP-TE LSP with zero BW and MPLS FRR
> >>> [RFC4090] and forget LDP except for PW signaling.
> >>>
> >>> Curtis
> >>>
> >>>
<[email-masked]
> >>>>> We had feedback from the mpls WG to present this draft at RTGWG.
> >>>>> Since our request for a slot was late, there is a chance that we
> >>>>> may not have adequate time at the end of the session for this
> >>>>> draft. In any case we wanted to make the WG aware of the draft
and
> >>>>> would appreciate any comments.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> - Sri
> >>>>
> >>>>
> >>>> signaled SRLG, and with increased potential of transient route
> >>>> loops in the abense of complete and accurate SRLG information or
> >>>> when multiple failures occur that are not covered by SRLG.
> >>>>

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Aug 2011 10:00:48 -0700

Nice

Sent from my iPhone

> Of Eric Osborne (eosborne)
> Sent: Thursday, August 04, 2011 9:16 AM
> To: Sriganesh Kini; [email-masked]
> Cc: Sriganesh Kini; [email-masked]
> Subject: RE: draft-kini-mpls-frr-ldp-01 for review
> 
> > >>>> Even if I did support an LDP FRR, I don't think this draft
> offers
> a

---

From: Alia Atlas <[email-masked]>
Date: Thu, 4 Aug 2011 13:22:29 -0400

I agree that is a reasonable comparison.  At least RSVP-TE has significant
troubleshooting tools
and training available.

The other question is what is your protection
time - i.e. how much time after a topology change does it take to become
fully protected?

Alia

On Thu, Aug 4, 2011 at 12:16 PM, Eric Osborne (eosborne) <[email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 13:51:00 -0400

Sri,

This is turning into a RSVP-TE vs LDP debate.

In message <[email-masked]>
> Full mesh is not as scalable.

No protocol so far is infinitely scalable.

Computation in LDP is one SPF, order(N*logN).  RSVP-TE needs N of
these CSPF computations, order(N^2*logN).

LDP uses multipoint to point (P2MP) LSP, making TE impractical, but
using N labels at any given point.  RSVP-TE uses point to point (PTP)
LSP so it needs order N^2 total LSP of which absolut worst case is
N^2/4 crossing a thin cutset in the graph (one or two links).

When bumping into OSPF scaling limits, use areas.  With ISIS use
levels.  Both offer a two level hierarchy with some differences.  If
that isn't enough, at some size neither protocol will function.

With RSVP-TE you have to use hierarchy sooner but there are more
levels of hierarchy available.

First make core one mesh group.  Make each region its own mesh group.
Some LSR sit on both core and one or more region.  The create a mesh
group for the edge routers which use the hierarchy in core and regions
to go edge to edge.  Any restoration is done in the H-LSP and not in
the edge mesh group if you just set the "resilience" parameters to
make it so.

I don't know of anyone who took this out further to access, but add
one more layer of hierarchy and build a lot of small access mesh
groups and repeat process.

There are five levels of hierarchy available.  PSC-0 (implied) and
PSC-1 to PSC-4.

Scaling is solvable to largest networks today.  But the FUD remains.

That is the short explanation without turning this email thread into a
thesis on scalability.

> have seen many providers prefer to run an LDP network and want full
> coverage protection.

It is entirely possible that RSVP-TE is used much more in core and LDP
much more in edges.  It could be which target market the product
focuses on.

Regards,

Curtis

---

From: Sri <[email-masked]>
Date: Thu, 4 Aug 2011 15:03:22 -0700

inline

> comparing the wrong things.

That was a point brought up in the email thread. The draft only
compares it with other approaches used currently to protect LDP
traffic. One of them is LDP over RSVP-TE FRR and and that requires
running two protocols. The draft doesn't claim that the approach is
simpler for TE. We can explicitly state this in the next version to
make it clear.

>  - explicit routing control, even if the paths are dynamically

In most practical topologies we do not see the need for explicit
routing control in LDP. As an example see the link protection topology
in the preso. In fact as we analyze more practical topologies, we are
seeing lesser need for it. So the explicit routing is more for
providing a completeness of the solution to address all topologies.
Most practical cases are addressed sufficiently by using the
shortest-path LSPs as backup LSPs. It is possible that the way the
sections in the draft are currently organized, it gives the impression
that explicit routing is always needed. Pls see the presentation, that
lists multiple topologies none of which require explicit routing. The
draft will be structured to reflect these cases ahead of the
exceptional cases. Another option is to have a "simplified-version" of
this draft that provides better coverage than IPFRR-LFA with full
coverage of LDP for many practical topologies but leave the explicit
routing for future consideration.

SRLG information is needed if one wants to protect against its
failure. If one chooses not to advertise it there is no protection
against it, but it is still possible to protect against independent
link/node failures.

> place, put it in LDP and then argue that LDP is still 'simple'.

We are using the minimal extension to LDP to get around failures. The
"RSVP protocol" is much more than just that.

> What is different between your proposed changes to LDP and what CR-LDP

As stated earlier the explicit routing extension to LDP is minimal and
that too can be removed for the "simplified-version". CR-LDP can stay
as-is !

-- 
Sriganesh Kini (Sri)

---

From: Sri <[email-masked]>
Date: Thu, 4 Aug 2011 15:12:33 -0700

inline

> I agree that is a reasonable comparison.  At least RSVP-TE has significant

LDP has that too. And it shouldn't need much change to apply that to
backup LDP LSPs.

> time - i.e. how much time after a topology change does it take to become

We will discuss the empirical data as it becomes available. We don't
anticipate it being significant enough to be of concern.

>
> Alia
>
> On Thu, Aug 4, 2011 at 12:16 PM, Eric Osborne (eosborne)

-- 
Sriganesh Kini (Sri)

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 4 Aug 2011 17:27:22 -0500

One question inline with EO#
...

> >
> > How much simpler is your solution than what I've described above?
> > They both need
> In most practical topologies we do not see the need for explicit routing
> control in LDP. As an example see the link protection topology in the
> preso. In fact as we analyze more practical topologies, we are seeing
> lesser need for it. So the explicit routing is more for providing a
> completeness of the solution to address all topologies.

...

> that too can be removed for the "simplified-version". CR-LDP can stay as-
> is !

EO#
If you remove the explicit routing from LDP, aren't you just left with an approach that looks a lot like LFA or MRT?  What's unique to what you're presenting other than the need to occasionally use contstraint-routed LDP?

eric

> >> > <[email-masked]
> >> > >
> >> > Sriganesh Kini writes:
> >> >>
> >> >> the additional complexity of deploying RSVP-TE but they do want
> >> >> sub 50msec protection with full coverage. Moreover RSVP-TE doesn't
> > scale as
> >> well.
> >> >
> >> >
> >> > Additional complexity.
> >>
> >> >>> attribute vector and other niceties that should have nothing to
> >> >>> do with LDP.
> >> >>>
> >> >>>>> Since our request for a slot was late, there is a chance that
> >> >>>>> we may not have adequate time at the end of the session for
> >> >>>>> this draft. In any case we wanted to make the WG aware of the
> >> >>>>> draft
> > and

---

From: Sri <[email-masked]>
Date: Thu, 4 Aug 2011 16:17:31 -0700

inline

> If you remove the explicit routing from LDP, aren't you just left with an approach that looks a lot like LFA or MRT?  What's unique to what you're presenting other than the need to occasionally use…

IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplified
version of FRR-LDP uses LDP LSPs with stacking such that they are loop
free and avoid the failure. A simple example is the link-protection
case in the preso. They could also avoid SRLG failures if the
appropriate shortest-path LSPs exist in that topology.

MRT uses redundant trees.

-- 
Sriganesh Kini (Sri)

---

From: Alia Atlas <[email-masked]>
Date: Thu, 4 Aug 2011 20:05:34 -0400

Sri,

It sounds like you are advocating the P-Q option that Mike & Stewart
originally suggested.  From the draft, I couldn't tell whether you were
suggesting that or simply computing not-via alternates from the PLR and then
signaling them using LDP DoD with an ERO.

The key in the fast-reroute discussions is what is the algorithm to compute
or create the alternates.

In RTGWG, we had a long discussion about what properties we wanted for
IP/LDP Fast-Reroute.  At the time, of course, I was suggesting U-turn
alternates; they don't require tunnels or additional signaling and increased
the coverage up to 98% or so.  Beyond that, minor topology changes could get
a lot - and one could always go to cascaded U-turns if necessary.

There was a strong push for a solution that could provide 100% coverage
whenever the network couldn't be partitioned by a single failure.  That is
what led to not-via which gained WG consensus to become a WG draft.

At this point, I think we've seen a lack of progress on not-via due to the
scalability issues.

The need for a solution and the scalability issues around not-via are what
have motivated me to suggest MRT fast-reroute.  MRT fast-reroute can provide
100% coverage regardless of topology.

I'm deeply amused by having this discussion on the other side of the fence -
arguing for the 100% solution.

Regardless, I'd have to see some pretty convincing arguments before saying
that we should compromise on something less.  I haven't seen any evidence
that the WG opinion has changed on this point.

Alia

P.S.  For topology coverage, how many cases still don't require any directed
forwarding once a single or multiple failures have happened to the network?

On Thu, Aug 4, 2011 at 7:17 PM, Sri <[email-masked]> wrote:

> as-
> > If you remove the explicit routing from LDP, aren't you just left with an
> approach that looks a lot like LFA or MRT?  What's unique to what you're
> presenting other than the need to occasionally use contstraint-routed LDP?
>
> >> >> > <
> [email-masked]
> >> >> > >
> >> >> > Sriganesh Kini writes:
> >> >> >>

---

From: Sri <[email-masked]>
Date: Thu, 4 Aug 2011 17:06:45 -0700

Curtis,

This should not be a RSVP vs LDP debate. RSVP-TE is best positioned to
do some things (e.g. TE) and this draft is not changing any of it.

I agree that there are many techniques available to scale a network.
But there are many existing deployments of LDP. Many of these service
providers do not want to (re)design their network using RSVP. In fact
they do not want to introduce RSVP anywhere in their network. But they
are interested in a local repair mechanism that provides better
coverage than current available without increasing complexity.

Agree that depending on the part of the network the service provider
may look for a different protocol/toolkit to solve his problem.

Thanks

-- 
Sriganesh Kini (Sri)

---

From: Sri <[email-masked]>
Date: Fri, 5 Aug 2011 15:57:34 -0700

Alia,

inline

> signaling them using LDP DoD with an ERO.

The proposal currently has some commonality with the other work you
mentioned. We had discussed with Stewart and it seems there are some
differences with the way the upstream is defined in this draft versus
the other drafts. Also we handle SRLGs differently. But there are
overlaps too. This draft currently re-uses existing shortest-path
state as far as possible and handles SRLG failures. We have also not
encountered scalability issues in practical topologies that we
analyzed.

> or create the alternates.

Is it necessary to standardize the algorithm iff it has to be executed
in a distributed manner. The draft currently defines protocol
extensions, but SPF algos can be re-used to find backup LSPs. The
other nodes only need to signal the LSP. There should be room for
better algorithms in the future.

> a lot - and one could always go to cascaded U-turns if necessary.

Yes, we understand that has associated issues.

> what led to not-via which gained WG consensus to become a WG draft.

The current proposal has full coverage. The "simplified-version" that
was mentioned can be an implementation/deployment option.

> 100% coverage regardless of topology.

AFAIK it does not handle SRLG failures.

> forwarding once a single or multiple failures have happened to the network?

That depends on the topology and the failure.

>> >> routing
>> > If you remove the explicit routing from LDP, aren't you just left with
>> > an approach that looks a lot like LFA or MRT?  What's unique to what you're
>> >> >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to
>> >> >> >>>> implementation
>> >> >> >>>> how to use it.
>> >> >> >>>>
>> >> >> >>>> Regards,
>> >> >> >>>> Jeff
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> provides mostly limited coverage protection, without the
>> >> >> >>>> benefit
>> >> > of

-- 
Sriganesh Kini (Sri)

---

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Aug 2011 11:12:11 -0400

Sri,

The algorithm is important to allow evaluation of the feasibility and
trade-offs of this approach
versus others.  For instance, an algorithm for LFA is clearly defined even
though the LFA computation
is a purely local matter.

Statements in the draft such as "An LSR computes the failures and prefixes
for which it can act as a
BSP MP and advertises a label mapping for the BSP LSP by including the
Failure Element TLV and
the Backup Path Vector TLV." are particularly unclear as to their expected
algorithm and computational
complexity.

One of the strong reasons for 100% coverage is to handle the case where the
existing network topology
has already been impacted by one or more failures that haven't been
repaired.  An analysis of a method
and claim of 100% coverage based solely on topologies as planned misses this
issue - which is the strong
argument for needing 100% coverage.  A method that uses explicitly routed
paths for the alternates can have
100%, of course, assuming that multi-homed prefixes are properly covered.

Finally, the proposed mechanisms do not describe any mechanism for handling
IP traffic.  One of the initial goals
for IP/LDP fast-reroute in RTGWG was to have mechanisms that work for IP
traffic as well as LDP.   I don't believe
it is necessary or desirable to have different mechanisms for IP and LDP
traffic.

Similarly, having a common mechanism that also applies for IP and mLDP
multicast is preferable.

Alia

On Fri, Aug 5, 2011 at 6:57 PM, Sri <[email-masked]> wrote:

> >> >> >> > except per link config since different nodes have different
> number
> >> >> > and
> >> >> >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions
> as
> >> >> > per
> >> >> >> >>>> From: [email-masked] [mailto:[email-masked]]
> On
> >> >> >> >>>> Behalf Of Curtis Villamizar
> [email-masked]
> >> >> >> >>>> >
> >> >> >> >>>> Sriganesh Kini writes:
> >> >> >> >>>>>
> >> >> >> >>>>> Hello,
> >> >> >> >>>>>