Subject: Re: draft-raggarwa-rsvpte-pw-01.txt

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Mar 2005 10:54:16 -0500

Nurit> The  existing  two  protocols  ...  can  not  signal  explicit  route
Nurit> information,    not   QoS   parameters,    not   Diffserv/Diffserv-TE
Nurit> information, not traffic priorities, not requirements for resiliency,
Nurit> not  resource  classes,  no   crouchback  information,  etc.  The  TE
Nurit> information  must  be signaled  to  allow  the  S-PEs to  select  the
Nurit> appropriate Tunnel for the PWs. 

Nurit, first I  would like to thank you for making  a technical argument. It
almost seems out of place in this thread ;-(

If the only reason  for the PW setup protocol to signal  TE parameters is so
that  those  parameters  can  be  used to  select  the  appropriate  traffic
engineered tunnel, then a very straightforward solution would be to: 

- use RSVP-TE to set up the tunnels

- add a TE parameter to LDP/L2TPv3. 

It doesn't seem to call for a new PW setup protocol.  

I am  still not seeing  that applying  TE to the  PWs is anything  more than
applying TE to the PSN tunnels.   True, a PW switching point needs to choose
the right  sort of tunnel, but today  PW endpoints need to  choose the right
sort of tunnel, and making that choice is not really a protocol issue. 

Someone mentioned CAC support as being a reason for requiring a new PW setup
protocol.  I  didn't quite follow that, because  it seems to me  that PW CAC
should be applied only  at the PW ingress.  Once data is  put into the PW, I
can see that the  PSN tunnels may need to apply CAC,  but "admission" to the
PW is already done. 

I have  the same  issue with regard  to QoS; it  seems to  me that QoS  is a
property of the PSN tunnels, not of the PW itself. 

You may wish to elaborate on the resiliency and crankback requirements.