Re: concerns about tunnels

Hi Albert,

An LDP full mesh doesn't scale very well.
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.

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.

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.

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
> > Rtgwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
Rtgwg mailing list
Rtgwg@ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg