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

From: "Gray, Eric" <[email-masked]>
Date: Thu, 24 Mar 2005 12:06:42 -0500

Richard,

	As a point of clarification, while signalling protocols 
do not need to define how CAC works, they do need to support a 
common set of CAC related outcomes - assuming that some form of 
CAC is taking place during the signaling process. Otherwise, it 
is hard to imagine how the signaling protocol can convey the 
success or failure of the CAC process.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, March 24, 2005 11:56 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

Eric,
 
> 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.
 
If this was the only reason then I would agree. However, in addition to
signalling bandwidth/QoS parameters, the MS-PW setup protocol also needs to
support the setup of backup MS-PWs associated with the primary, and also
needs to support crankback (depending on the network topology). There may be
other things but I would say these are required as a minimum.
 
> 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.
 
In my view TE at the MS-PW layer (i.e. the ability to calculate optimum
MS-PW paths based on the tunnel LSP topology) is not required although there
may be other operators that want to do MS-PW TE. I agree that PW endpoints
select the right tunnel today, but this is possible because the PW endpoints
terminate on the same PE that the ACs do. In the MS-PW case, S-PEs have no
knowledge of ACs and therefore need to receive information about per MS-PW
bandwidth/QoS requirements via a signalling protocol in order to dynamically
select the appropriate tunnel. 
 
> 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 agree that CAC isn’t relevant to this discussion. Although when CAC is
being discussed here my understanding is that we are talking about
performing CAC based on the available tunnel LSP bandwidth during MS-PW
signalling, not CAC at the MS-PW ingress based on the available MS-PW
bandwidth.
 
> 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.
 
Again I agree, packets will be forwarded based on the tunnel LSP QoS
markings. I think the main point about QoS is that if multiple DS-TE tunnels
are being used then during signalling the required class of service
information must be signalled along with the required bandwidth in order to
select the appropriate DS-TE tunnel and to reseve the bandwidth accordingly.
 
> You may wish to elaborate on the resiliency and crankback requirements.
 
In order to protect against S-PE failure, backup MS-PWs will be required for
at least a subset of MS-PWs. The current protocol does not support the setup
of backup PWs. Cranckback will be required in cases where a selected
next-hop S-PE does not have a tunnel LSP with enough bandwidth available to
be able to setup the MS-PW. Crankback may or may not be required depending
on the topology and how the network is engineered/provisioned.
 
Regards,
Richard