Re: [PWOT] draft-cai-vc-rsvp-te-01.txt

["Andrew G. Malis" <[e-mail]>]

Jim,

End-to-end LDP is just a better solution than RSVP signaled VCs for this 
particular application.  And LDP isn't being used in an N^2 manner, since 
point-to-point circuits are usually not deployed as full meshes, but rather 
as star networks.  Regarding discovery, etc., there is always a tradeoff 
between provisioning complexity in the NMS or end user and what is done in 
the network.  Using LDP removes the need to, for example, manually assign 
and keep track of thousands of labels and ensure their consistency at the 
two VC endpoints.

Cheers,
Andy

--------

At 3/6/2001 08:44 AM -0700, Jim Boyle wrote:



>Hmmm, RSVP signalled VCs, sounds a lot like PNNI and ATM, yeah, maybe it
>won't scale.
>
>But will LDP be the first information distribution protocol that can be
>configured in a N^2 manner w/o any form of hierarchy or strict rules on
>what information is propagated?
>
>Would some form of discovery, ephemeral state establishment, and session
>protocol approach be more scalable?
>
>Jim
>
>
>
>On Mon, 5 Mar 2001, Andrew G. Malis wrote:
>
> > Ting,
> >
> > I've got some comments on your draft.
> >
> > Unfortunately, this is not one of those cases where LDP and RSVP-TE can be
> > roughly equivalent.  For this application, they have very different
> > operational and scaling properties.
> >
> > The nice thing about the LDP approach is that you can have many thousands
> > of L2 circuits on one forwarding LSP and only the tunnel's two endpoints
> > keep any state for them, since the LDP signaling is ONLY seen by the VC's
> > endpoint LERs.  The signaling is completely invisible to the interior LSRs
> > within the network - it's just labeled IP packets within the traffic 
> tunnels.
> >
> > However, that does not happen with this draft: even if only the ingress 
> LSR
> > interprets the VC_LABEL (and only the egress LSR interprets the
> > VC_LABEL_REQUEST), these are sent in RSVP PATH messages with router alert
> > set.  Every LSR along the way will process those packets on the slow path,
> > if only to decide it shouldn't be looking at the VC_LABEL object.  And the
> > size of the RSVP messages will grow to the extent that they won't fit
> > within in a single datagram, meaning that a potentially very large number
> > of RSVP messages will be required for setup and at each refresh period for
> > a single traffic tunnel.  And again, because router alert is set, there's
> > always a cost for taking these packets out of the fast path and then
> > reinserting them at every intermediate LSR.
> >
> > And once the VCs are set up, RSVP requires these to be refreshed
> > periodically. Since summary refresh from the refresh reduction draft only
> > works between neighbors, it can't be used in this case (since the
> > intermediate nodes aren't supposed to know about the VCs).  And of course,
> > the regular RSVP refresh has the same scaling problems as above and
> > requires state at intermediate LSR's.
> >
> > So, unless these scaling problems can be overcome, this is one case where
> > LDP really is superior for the application.
> >
> > Thanks,
> > Andy
> >
> > -------
> >
> > At 3/1/2001 10:44 PM -0800, Ting Cai wrote:
> > >FYI,
> > >
> > >A new internet draft has been submitted.  Before it becomes available at
> > >IETF web site, you can find a copy at
> > >
> > >http://www.pavoucek.cz/drafts/draft-cai-vc-rsvp-te-01.txt
> > >
> > >Your comments and questions are greatly appreciated.
> > >
> > >
> > >Ting Cai
> > >Martin Machacek
> > >
> > >Terabeam Networks, Inc.
> > >
> > >PS:
> > >
> > >Introduction of the draft:
> > >Martini et. al. proposed in [5] a method of encapsulating L2 PDUs in MPLS
> > >packets. The method uses a stack of two labels: one specifying the LSP
> > >tunnel across the MPLS network and the other identifying the virtual 
> circuit
> > >(VC) to which the L2 PDUs belong. Martini et. al. proposed a method for
> > >distributing VC labels using LDP in downstream-unsolicited mode in [2]. We
> > >propose a simple extension to RSVP-TE [3] to signal VC labels using 
> RSVP-TE
> > >in downstream-on-demand mode. The extension includes two new RSVP object
> > >classes, VC LABEL and VC LABEL REQUEST. The data formats including their
> > >interpretations are taken from [2] with only minor modifications 
> required by
> > >the RSVP object format. This should simplify implementations 
> supporting both
> > >LDP and RSVP-TE.
> > >
> > >
> > >
> > >_______________________________________________
> > >pwot mailing list
> > >[e-mail]
> > >http://www.ietf.org/mailman/listinfo/pwot
> >
> >
> > _______________________________________________
> > pwot mailing list
> > [e-mail]
> > http://www.ietf.org/mailman/listinfo/pwot
> >


_______________________________________________
pwot mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pwot