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

From: "Nurit Sprecher" <[email-masked]>
Date: Mon, 28 Mar 2005 13:11:20 +0200

Hi again Richard,

Please see my comments in-line.

Best regards,

Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 24, 2005 6:56 PM
To: [email-masked]; Nurit Sprecher
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.

[Nurit] CAC for the MS-PW over the TE tunnel at each S-PE. \[Nurit]

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

[Nurit] Correct. \[Nurit]

> 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

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3