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

[Jim Boyle <[e-mail]>]

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