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

From: "Nurit Sprecher" <[email-masked]>
Date: Mon, 28 Mar 2005 12:44:42 +0200

Hi Richard,

Thanks for your response. Please see my comments in-line.

Best regards,

Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 24, 2005 6:07 PM
To: Nurit Sprecher; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

Nurit,

Please can you expand on what you mean by TE MS-PW?

There are a number of definitions of what TE means but I would say that
the purpose of TE is to increase resource utilisation and network
performance, and to guarantee resources for high priority traffic under
failure conditions.

[Nurit] I agree. \[Nurit]

To achieve this I think there are two key functions:

[1] Use of offline network monitoring/modelling techniques or CSPF to
calculate optimal paths through the network.

[Nurit] I guess that by CSPF you mean online. Is it? 

For TE sake, the required path may be of course subjected to constrains.
\[Nurit]

[2] Use of mechanisms/techniques (e.g. signalling of LSPs with explicit
paths) to ensure traffic follows the optimal paths determined in [1].

[Nurit] Correct. \[Nurit]

Optimal path calculation for tunnel LSPs is based on the
physical/logical link topology. To perform optimal path calculation for
MS-PWs, then the calculations need to be based on the tunnel LSP
topology, i.e. the bandwidth available in each tunnel LSP.

If we want to support end-to-end path computation at the source using
CSPF for MS-PWs, then I believe we will need to advertise tunnel LSPs as
FA-LSPs into the TE database. 

[Nurit] It may be (as for TE tunnels), that the source calculates the
entire route or only part of the route, putting into the explicit route
information loose hops, and intermediate nodes (i.e. S-PEs) extends the
loose hops with more precise information. I guess we should not have any
restriction on this. \[Nurit]

An alternative would be to perform the end-to-end MS-PW path calculation
using offline tools based on per tunnel LSP utilisation information. In
both cases we need a setup mechanism with an ERO capability to ensure
traffic follows the optimal path.

[Nurit] Correct. \[Nurit]

An alternative method of providing path optimisation would be to perform
hop-by-hop tunnel selection. Hop-by-hop tunnel selection first of all
would require reachability information, (i.e. knowledge of which tunnels
can be used to reach the destination). Also, in order to avoid following
the shortest path, per hop policies would be required in order to select
the most appropriate tunnel (e.g. always choose the tunnel with the most
bandwidth available or always choose a red tunnel over a blue tunnel).
Hop-by-hop CAC would be required to check at each hop that bandwidth is
available, and crankback would be needed for cases where the next hop
doesn't have a tunnel available that meets the MS-PW resource
requirements. 

[Nurit] Correct. \[Nurit]

This approach makes the assumption that reachability information is
available, and this requires route calculation based on the tunnel LSP
topology. There are a number of ways route calculation based on the
tunnel LSP topology could be performed, but this is a problem that has
not yet been addressed within PWE3 or L2VPN.

[Nurit] However, this has been addressed in the MPLS WG, the LSP
Hierarchy draft. \[Nurit]

An alternative to route calculation based on the tunnel LSP topology
would be to use flooding, which is one of the approaches proposed in
"draft-shah-bocci-pwe3-ms-pw-signaling-00.txt".

>From my own perspective, based on a BT specific network topology, I do
not need TE at the MS-PW layer. The core (with S-PEs at the edge) will
be constructed using TE-LSPs which will take care of core network
resource utilisation and provide protection against core failures. 

[Nurit] It could be very interesting for me to discuss the end-to-end
solution for BT specific network topology. I understand that you assume
2 S-PEs in the network only. But we may have more. In general, MS-PWs
are established from U-PE to U-PE and it at each ingress point to a
segment care should be taken for CAC, optionally Diffserv-TE classes,
optimal path, resiliency, hops that the MS-PW should transmit via (for
policy/accounting sakes), etc. 

Using the RSVP-TE mechanism for establishing the MS-PWs, we could
restrict the configuration to the U-PEs only, and signal the information
such that the S-PEs have the necessary information to make the
right/best selection/decision. Otherwise, the information should be
configured at each S-PE.

Please note that the solution could be good and helpful for TE over
multi-area case (within the core), etc. 

I'll be glad to discuss it to you off the list.

\[Nurit]

As U-PEs are likely to be dual homed to S-PEs I might perform some load
balancing, but there is no need for TE. Therefore, the MS-PW setup
mechanism needs to support CAC and backup MS-PWs, but does not need to
support MS-PW TE.

[Nurit] Please see my comment above regarding the path calculation. I
believe that in certain cases, where the S_PEs are involved in
determining the route, we need much more information, such that explicit
route, QoS parameters (for CAC), Diffserv/Diffserv-TE information,
traffic priorities, etc. \[Nurit]

Regards,

Richard

      -----Original Message----- 

      From: [email-masked] on behalf of Nurit Sprecher 

      Sent: Thu 24/03/2005 07:17 

      To: Thomas D. Nadeau; Stewart Bryant 

      Cc: pwe3 

      Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

      Hi Tom,

      We should distinguish between MS PWs and SS PWs.

      The protocol that we have is appropriate for non-TE MS PWs and
also for

      SS PWs (both TE and non-TE). However for TE MS PWs it is not
appropriate

      because the requirements of the TE MS PW should be signaled such
that

      the S-PEs can use the information to select the appropriate
Tunnel/link

      for the PW. For example, to select a Tunnel that its egress is hop

      through which the MS PW should transmit (fro policy sake for
example), a

      Tunnel that has enough BW, and support the required Diffserv-TE
class,

      that its traffic priority is not smaller than the priority of the
PW,

      that the Tunnel is protected with mechanism that provides up to
50ms

      restoration time in case of a failure, etc. I think that the
(only)

      example above indicates that there are "significant advantage to

      signaling PWs using an alternative means". So maybe now you should

      "think otherwise" as you said.

      The natural protocol that already provides us with this capability
is

      the RSVP-TE protocol (which is already used and deployed for TE

      Tunnels). As I already stated, it should only be extended to
support the

      PW identifier (PW ID/Type) and the control word, which is a very
little

      extension (especially relatively to the extension that LDP
protocol

      should go through to support the signaling of the TE information).

      Nurit.

      -----Original Message-----

      From: [email-masked] [mailto:[email-masked]] On
Behalf Of

      Thomas D. Nadeau

      Sent: Wednesday, March 23, 2005 5:41 PM

      To: Stewart Bryant

      Cc: pwe3

      Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

      -----BEGIN PGP SIGNED MESSAGE-----

      Hash: SHA1

              Personally speaking, I don't think that it is useful

      for the WG to spend time and effort re-inventing

      the wheel, so to speak, which is what this draft

      represents. We already have a protocol for

      signaling PWs that works, and is deployed. If

      there were some significant advantage to signaling

      PWs using an alternative means, I would think

      otherwise, but it seems this is just being proposed

      as an alternative means for achieving the same

      end result.

              --Tom

      > At IETF62 the authors of

      > Setup and Maintenance of Pseudowires using RSVP-TE

ftp://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-01.txt

      > asked for the draft to become a WG draft.

      > What is the view of members of the PWE3 WG?

      > Stewart

      > _______________________________________________

      > pwe3 mailing list

      > [email-masked]

      > https://www1.ietf.org/mailman/listinfo/pwe3

      -----BEGIN PGP SIGNATURE-----

      Version: GnuPG v1.2.4 (Darwin)

      iD8DBQFCQY4dHwfkLUURkkwRAgbtAJ9Bpc/zSm0TungLQ/LOQOD8VXDr+ACfXkWS

      obq/1BEDNhqeTW+u8DzaYGU=

      =s7XE

      -----END PGP SIGNATURE-----

      _______________________________________________

      pwe3 mailing list

      [email-masked]

      https://www1.ietf.org/mailman/listinfo/pwe3

      _______________________________________________

      pwe3 mailing list

      [email-masked]

      https://www1.ietf.org/mailman/listinfo/pwe3

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