RE: [PWE3] RSVP MS-PW ? HOW?

Hi Luca,

Please see my comments in-line.

Regards,

Nurit.

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
Luca Martini
Sent: Tuesday, November 29, 2005 02:51
To: PWE3 WG (E-mail)
Subject: [PWE3] RSVP MS-PW ? HOW?

WG,

I have many questions about the use of RSVP for MS-PWs. The current

draft (draft-raggarwa-rsvpte-pw-03.txt) contains a lot of discussion of

why we should use RSVP, but does not contain detail on how to use RSVP

to signal PWs. In the IETF we standardize protocols and not arguments.

<<<Nurit: I believe that it contains pretty much detail on how to use
the RSVP to signal PWs in order to make it an IETF draft. An IETF draft
is not an RFC.>>>

I still claim that this draft is not ready to be a WG draft, as it does

not contain a real complete protocol definition that meets the stated

requirements.

Let's look at different points that would have to be explained.

Traffic engineering of the PW layer has not been a clear requirement,

however I believe that traffic engineering of an MPLS network used to

carry PWs is a requirement.

<<<Nurit: I don't really understand your point. We have the MPLS
infrastructure and we still have requirements for TE services (which are
emulated by PWs). The service has requirements for example for QoS, for
Diffserv TE class, for resiliency (in order to avoid service disruption
in case of a failure), traffic priorities, resource affinities, etc. The
S-PEs should be aware of such requirements in order to select an
appropriate tunnel for the PW. For example, if we have a requirement for
a service that it should nut be disturbed for more than 50 ms in case of
a failure, the S-PE should know it in order to select a TE Tunnel that
is FRR protected. The FRR recovery would be of the TE Tunnel of course,
but the S-PE should know this information for the tunnel selection sake
(otherwise it should be manually configured with information). If the
service needs a certain amount of BW and a certain Diffserv TE class,
the S-PEs should be aware of this in order to select the most
appropriate tunnel for the PW. And so on..........

For MS PWs, where the S-PE should stitch/switch/whatever the PWs from
one Tunnel to another, it should be aware of the requirements for the TE
PWs. Either this information is manually configured at each S-PE for
each PW or the information is signaled via the control plane. One of the
purposes of the control plane is to automate the process, adjust it to
live networks and avoid of manual configuration. >>>

In today's deployments RSVP-TE is used to setup MPLS tunnels that carry

PWs.  These tunnels are sometimes dedicated to PWs, 

and are traffic engineered in the MPLS network along with other MPLS

tunnels that may be used for other purposes. One of the main parameters

used for TE is bandwidth utilization.  If we are proposing to traffic

engineer the PW layer itself, then we would presumably be able to select

a certain subset of statically pre-configured MPLS-TE tunnels to carry

the PWs and reserve the utilized bandwidth once the PW is signaled.  

<<<Nurit: Why statically pre-configured MPLS-TE tunnels? The tunnels are
signaled via the control plane. The PW is configured in the U-PE and
signaled along the network, allowing the S-PE to select the most
appropriate TE tunnel for the signaled TE PW. TE PWs has requirements
for QoS, for a certain Diffserv TE class, they have priority (for
pre-emption), they have requirement for resiliency, etc. This should be
signaled to provide the S-PEs with this information in order to find the
most appropriate tunnel.>>> 

Traffic engineering of PW would mean that S-PEs are selected based on
available bandwidth to reach them.

The question is why?  

<<<Nurit: S-PEs are selected also based also on the best route towards
the Egress U-PE. Etc.>>>

We already traffic engineered the MPLS tunnels across 

the MPLS network, why should be make this network an order of magnitude

more complicated by traffic engineering PWs on top of already traffic 

engineered tunnels?

<<<Nurit: In order to supply the TE requirement of the PWs. Requirements
like QoS, TE priority, resiliency, etc. Please see more above>>>

I think that TE of PW themselves is not a useful feature. For example,

if an MPLS-TE tunnel runs out of available 

bandwidth, we can simply make it bigger, by re-signaling the RSVP-TE LSP

with new parameters.  

<<<Nurit: This 'path-resizing' is done by a manual operation, and this
make the provisioning more complicated. We want to automate the process.
We want to put the PW in a tunnel that has sufficient BW, or may preempt
other traffic, etc. 

Between a pair of U-PEs we may have a few MPLS TE tunnels, each with
different characteristics. Since a TE PW has requirements that should be
satisfied by the tunnels (enough BW, Diffserv TE class, protection,
etc.), the S-PEs should be aware of such requirements in order to select
an appropriate TE tunnel to the destination when switching/stitching the
PW.

The basic point if that a PW is actually a service, like an Ethernet
service, etc. and the service has requirements for TE. >>> 

This point applies regardless of what protocol is

used to setup the PW: the PW layer itself should NOT be traffic

engineered.

<<<Nurit: I believe it does have. We traffic engineer a service. Please
see above.>>>

There are two stages required in traffic engineering an MPLS network:

First a constrained shortest path calculation is performed to select a

path through the network. This path is calculated 

based on a database that gives a picture of all available links and

resources on each link in the network.

<<<Nurit: Correct. A TE tunnel for a PW is like a link. We still want to
find the best route/path for the PW/service. This best route is the
shortest path the applies the requirements of the PW/service.
Requirements like QoS, Diffserv TE class, protection, etc.>>>

Second the path is signaled using RSVP-TE with an Explicit Route

Object, and a T-Spec object.

<<<Nurit: Correct: We may like to enforce the PW to transmit via certain
S-PEs. This can be for accounting sake, or for security sake, etc. This
S-PEs should be contained in the Explicit Route Object. The T-spec is
important as well, to provide the S-PEs the information in order to
select the appropriate TE tunnel when switching/stitching the PW>>>. 

The MS-PW RSVP-TE draft has failed to explain how PW specific

information would be propagated in an MPLS network in a manner analogous

to the first step above. Using OSPF-TE? Maybe ISIS-TE? Maybe Marking

MPLS tunnels for PW use only?

<<<Nurit: IGP-TE is used and the LSP hierarchy may be used to advertise
the TE tunnel as FA LSPs. This is defined in the draft.>>>

I propose that using the PCE architecture would be the only reasonable

method to perform PW TE across multiple domain and multiple providers.

Another major problem that is yet unresolved is the fact the RSVP-TE

signaling does not have the concept of a session. (RSVP-TE refresh

reduction is not a session).

A session consists of initialization, and a well defined message

transport layer.  In LDP we have an LDP session setup 

phase, and a TCP/IP session is used to transport messages numbered in a

sequence. The PW is then set up by sending 

messages that are multiplexed within the TCP/IP transport session - so

the messages themselves do not require globally unique addresses.

<<<Nurit: A session is an approach. I cannot see the problem in the
RSVP-TE approach. IS it a requirement o have session?>>>

RSVP, does not have the concept of a session, however independent PW
addressing

can be achieved by using the the SESSION object, and the
SENDER_TEMPLATE. 

The problem arises when a status message needs to be returned by an

intermediate S-PE in the MS-PW. The RSVP protocol is 

only defined for IPV4 and IPV6, hence we cannot send a message back to

say that, for example, TX direction of S-PE 102:10.0.0.1 failed for PW

102:10.0.0.45:401. (In LDP this is done by using the PW status TLV in

the LDP status notification).

How can this be done in RSVP-TE?  Maybe by creating the new address

family for PW, and using RSVP notification mechanisms?   Another

possibility would be to use a RSVP notification mechanism to just

transport a message to the T-PE.

It is also unclear how the RSVP protocol would be used to set up PWs 

in a network that has duplicate IP addresses.

<<<Nurit: Duplicate IP addresses? How LDP can work in such a case? LDP
is based on IGP? How can you establish LDP session between the U-PEs?
How end-to-end management (e.g. SNMP) can work inband in such a network?
Etc.

It seems that only manual configuration can help in such a case. Isn't
it one of missions of the control plane to automate the process?>>>

This is very common in service providers' internal networks,

not used to directly carry public IP traffic. Nodes are generally

addressed out of private IP space, and node IP addresses will be

commonly duplicated between providers (in this case a status message

from 10.0.0.1 would be effectively anonymous, unless some other form of

addressing is used). In the LDP MS-PW proposal this is solved by

allocating a unique L2 PW address to the nodes acting as S-PE or T-PE.

<<<Nurit: If there is a requirement, we can think of something similar
to the RSVP-TE. Such an enhancement or definitions can be done also to
an IETF draft. An IETF draft is not an RFC. Work is still required on
the draft.>>>

None of these problems are addressed in draft-raggarwa-rsvpte-pw-03.txt.

Also a clear list of changes required to RSVP would need to be included

in the draft in order for the WG to judge whether the protocol is

implementable and worthwhile.

GMPLS resolves some of these problems, however there are 2 major

differences I can see:

1) GMPLS is used hop by hop in the PSN.

2) IP addressing of GMPLS nodes is reserved, and not used for IP traffic

- other then control traffic.

I believe that if there is a need for a GMPLS RSVP PW it should be

defined as a flavor of draft-kompella-ccc-02.txt.  This is a classical

layer collapsing argument: we only need to piggy back the PW information

on the RSVP signaled LSP.

In this case there is a one to one mapping between PWs and RSVP-TE LSPs.

>From a service provider point of view there would be a few advantages
to

this methodology: 

1) this traffic engineering technology is well established

2) only one protocol/session per PW is needed

3) OAM methods are all already well defined.

If a GMPLS PW that interfaces seamlessly with a GMPLS network is needed

then PWE3 and CCAMP should work on this together.

PWE3 has already defined the PW encapsulation, and it was envisioned by

myself and by the ADs at the time of the PWE3 WG 

creation, that other WGs would also use these encapsulation methods with

other setup protocols that better fit their application.

Luca

_______________________________________________

pwe3 mailing list

pwe3@ietf.org

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