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

From: "Ting Cai" <[email-masked]>
Date: Tue, 6 Mar 2001 15:26:32 -0800

Andrew, 

Thanks for your comments. 

Please see below. 

Ting

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 8:38 PM
> To: Ting Cai
> Cc: [email-masked]; 'Martin Machacek'
> Subject: Re: [PWOT] draft-cai-vc-rsvp-te-01.txt
> 
> 
> 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.   

To set up virtual path, we need to signal both tunnel label and VC label. In
our proposal, VC label signaling is piggybacked with the tunnel label
signaling using RSVP. For tunnel labels, intermediate LSRs need to process
RSVP Path/RESV messages in slow path anyway.  The overhead caused by VC
objects on top of RSVP message processing is minimal.  

In the LDP scenario, you need one mechanism to configure the tunnel label,
and a completely separate LDP session with Extended Discovery to signal the
VC label.  If RSVP is already used to signal the tunnel label, the
complexity of supporting another similar protocol to signal the VC label is
not trivial. 

> 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.  

Speaking of scalability in terms of message size. Let's take RSVP VC_LABEL
message as an example. 

size of the message = Existing RSVP message headers and objects + n *
VC_LABEL objects, where n is the number virtual circuits that can be
tunneled within one RSVP message.  For the sake of analyzing VC scalability,
let's say existing RSVP messages headers and objects has a fixed length of
192 bytes. VC_LABEL Object has 16 bytes + interface parameters fields. Say
on average we have 2 interface parameter fields with 8 bytes each, the total
size for each VC_LABEL object is 32 bytes.  The limit of RSVP message size
is 64K bytes. Thus 65536 = 192 + n * 32 and n = 2042.  So one RSVP message
can on average support 2042 VCs before we do semantic fragmentation or IP
fragmentation. Correct me if I am wrong, but LDP need IP fragmentation as
well right? I think the message size limitation does not worsen the
scalability issues of RSVP.  

> 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.
> 
Same argument as before. 

> 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).  

Summary refresh messages are sent to the neighbors, and neighbors propagate
refresh messages to their neighbors and eventually to the egress router.
Intermediate LSRs does not need to know about the VC objects, they just look
at Message IDs and propagate the refresh. I think refresh reduction can be
applied to opaque objects like VC*. 

> And of course, 
> the regular RSVP refresh has the same scaling problems as above and 
> requires state at intermediate LSR's.

I agree with you that RSVP unnecessarily requires intermediate LSRs to store
VC objects.  As the number of VC objects grows, the memory requirement on
the LSRs could be huge. 

Comparing to LDP, we still prefer RSVP because if an edge device is already
using RSVP to signal the tunnel label, it is much more overhead to support
another label distribution protocol.  We know that scaling is an issue and
we are considering alternative solution to signal and refresh VC label
end-to-end using RSVP. 

Thanks again for your comments. 

> 
> 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
> >[email-masked]
> >http://www.ietf.org/mailman/listinfo/pwot
> 

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