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

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

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