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

From: "Nurit Sprecher" <[email-masked]>
Date: Sun, 27 Mar 2005 14:47:42 +0200

Hi Eric,

Thanks for your response.

Please see my comments in-line.

Best regards,

Nurit.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Thursday, March 24, 2005 5:54 PM
To: Nurit Sprecher
Cc: Stewart Bryant; pwe3
Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt 

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. 

[Nurit] There is much to add to the LDP to support the TE. If you use
the RSVP-TE protocol you gain the following:

*         The TE information is already there.

*         Your can use the Tunnel Hierarchy for selecting the
appropriate TE Tunnel (the tunnels are advertised as links in the
IGP-TE, The CSPF is activated to select a tunnel with enough BW, etc.).

*         You have a single protocol to manage and maintain in a TE only
environment (for both tunnels and PWs).

*         Minimal extension for the PW parameters.

\[Nurit]

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. 

[Nurit]

At the ingress, the CAC is performed only on the first tunnel that the
MS PW transmits via in its way toward the remote PE. At each S-PE, a CAC
should also be performed (for the PW over the TE Tunnel to verify that
there is enough BW on the TE Tunnel for the service). The CAC is
performed for the PW over the TE Tunnel (with CAC for tunnels is
perfomed over the links).

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

[Nurit]

The TE tunnel has QoS parameters (CIR, PIR, etc.), and each service
(i.e. PW) within the TE tunnel also has QoS parameters and we should
guarantee for example that the sum of the CIRs of the PWs within a
tunnel is not larger than the CIR of the Tunnel (unless overbooking is
allowed).

\[Nurit]

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

[Nurit]

Ofcourse. If the service (which is emulated by a PW) has strong
requirements for resiliency (maximum 50 ms of traffic disruption in case
of a failure) for example, it should transmit with a TE tunnel that is
protected by a FRR mechanism. We should elaborate on global protection
(end-to-end), etc.

\[Nurit]

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