Re: concerns about tunnels

[Albert Tian <[e-mail]>]

Hi, Alia,

First I need to clarify that if we are doing link protection only (for LDP
traffic or multicast traffic), we need NO change to LDP, and need very little
extension to RSVP/PIM to fix the RPF interface. In this case the repair path
terminates at the nexthop, which is exactly the node where you learned the LDP
labels from. So no need for extra LDP sessions at all for link protection. Still
the repair path has to be fully encapsulated (tunneled) to make sure multicast
traffic arrive at the nexthop, which is guaranteed to have proper (*,G) or (S,G)
state.

The complexity comes in when we want to do node protection, in which case the
repair paths terminate at the next-nexthops. This is where we need to learn
next-nexthop LDP labels, and next-nexthop group memberships.

Alia Atlas wrote:
> 
> Hi Albert,
> 
> An LDP full mesh doesn't scale very well.

I was thinking the same way as you do before San Diego. But from the feed back I
got from San Diego, LDP full mesh is fine, at least according to those who
spoke. BTW I do have solutions even if LDP full mesh don't scale :-)

> As for learning the LDP next-nexthop labels via your proposed extension, I
> am concerned about the potential gaps where the next-nexthop
> changes.  Also, just next-nexthop labels isn't sufficient for the proposed
> mechanism with directed forwarding or non-TE tunnels.

I feel you maybe mixing how directed forwarding is implemented and how directed
forwarding is used. Any tunnel as long as it can deliver rerouted traffic to
nexthop or next-nexthop, it is sufficient. To use such tunnels to implement node
protection for LDP traffic, next-nexthop LDP labels are the only thing extra we
need. The LDP next-nexthop label scheme works with any kind of tunneling
technology.

> 
> It seems to me that you are prioritizing a solution which allows easier
> support of multicast at the cost of more complex support of LDP.

The problem is that this seems to be the only way to support multicast.

> 
> As for the idea of TE tunnels for the backups, I don't see how that
> simplifies a solution beyond what TE fast-reroute can provide today.  It
> seems to me to be equally operationally complex.

To use TE tunnels as backups does not mean the operator also has to use TE for
his/her normal traffic.

The existing TE fast-reroute scheme can only protect TE traffic. So before IP
traffic can be protected, it has to be placed on some TE tunnels first, which is
VERY complex. You need a lot of (mesh of some kind) TE tunnels in your network
for normal day to day operation even without any protection being activated.

We are proposing to use TE tunnels as backups, and only as backups. This does
not require the operator to place IP traffic onto TE tunnels in the normal
operation. The TE tunnels are needed only when some failure happens. Therefore
there will be far less of these TE tunnels to maintain.

Here are some numbers posted by Mike earlier on this mailing list:

"the highest neighbor's neighbor count we have observed in a real network is 129
(with a max neighbor count of 22)"

This basically means to support link protection we need maximum 22 TE tunnels
per PLR, and to support node protection we need max 129 TE tunnels per PLR.
These numbers are far below the thousands normally required to form a full mesh
of TE tunnels.

So IMHO there is huge advantage for using TE tunnels as backups comparing to the
existing TE fast-reroute.

Thanks,

Albert

> 
> Alia
> 
> At 03:03 PM 9/27/2004, Albert Tian wrote:
> >Hi, Alia,
> >
> >Yes that is an issue needs to be solved, but it may not be as serious:
> >
> >a) there are solutions that do not require LDP full mesh. For example,
> >draft-shen-mpls-ldp-nnhop-label-01.txt that would let you learn LDP
> >next-nexthop
> >labels.
> >
> >b) there are people who would not mind LDP full mesh.
> >
> >Thanks,
> >
> >Albert
> >
> >Alia Atlas wrote:
> > >
> > > The other complexity which any type of tunnel introduces is for additional
> > > protocols, such as LDP, which requires a label from the tunnel end-point.
> > >
> > > With tunnels, X would need to maintain an LDP adjacency with every
> > > potential tunnel-endpoint Y, so that the labels are available.  If you go
> > > to a mechanism like the directed forwarding, then an adjacency would need
> > > to be maintained with every router to whom the traffic might be directed.
> > >
> > > Since VPNs and pseudo-wires are a source of the traffic which needs better
> > > resiliency, this is a serious concern.
> > >
> > > Alia
> > >
> > > _______________________________________________
> > > Rtgwg mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
Rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg