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

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

Hi Himanshu,

Thanks for your response.

Please see my comments in-line. 

Best regards,

Nurit.

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

Hi Nurit,

I do not agree with your assertion. Here is why.

1) As far as I know most current products today do CAC

   for SS-PW when mapped to TE tunnel. The information

   used for CAC purposes is derived from AC characteristics

   and the services sold by SP to the customer. LDP 'protocol'

   is not extended nor it is required.

[Nurit] I definitely agree with you and I cannot understand why you
think that I do not. As I stated in my previous mails, I said that for
SS-PW (both TE and non-TE) and for non-TE MS_PWs I think that the LDP
protocol is satisfactory and work. We also use the LDP for a TE SSPW.
However for TE MS_PWs I think the LDP is lack with a lot of necessary
information. \[Nurit]

2) We have proposed (shah-pw-qos-signaling) exchanging this same QOS 

   related information in LDP Label Mapping message as OPAQUE
parameters, 

   so both PEs (in case of SS-PW) can do consistent CAC when mapping PW

   to their respective TE-tunnel. LDP 'protocol' is not extended

   nor it is required to. This same OPQAUE paramters can  also

   be used for MS-PW, statically configured or dynamically signalled.

   Again LDP 'protocol' is not extended nor it is required.

[Nurit] This is a philosophy argument. The LDP is extended by opaque
information.  

In any case, as I stated in the meeting, the QoS opaque information is
very important for TE but it is not enough. We need much more
information, such as explicit route, traffic priorities,
Diffserv/Diffserv-TE information, resource affinities, requirements for
resiliency, etc. This should also be send as opaque information using
the LDP. These TLVs should be defined. This is already supported
inherently in the RSVP-TE protocol. Why should we invent the wheel
again? 

The RSVP-TE should be extended with opaque information on the PW
identifier. This is much less to add than the opaque information that
should be added to the LDP.

In addition, as I already stated, RSVP_TE is already there for the TE
tunnels (within which the TE MS-PWs transmit). Why should we manage and
maintain two different protocols in a TE environment? 

\[Nurit]

3) The MS-PW can also be dynamically signaled using T-LDP's DU LM

   messages. LDP 'protocol' is not changed. PW management entity

   at each S-PE, which is used for static purposes
(draft-martini-pw-stitching)

   is extended to process 'opaque' parameters passed in the LM messages.

[Nurit] In RSVP-TE we use the same mechanisms that are already defined.
There is hardly to extend. For example, LSP Hierarchy, etc. \[Nurit]

4) Note also that S-PEs are PE after all. They may already be doing,

   SS-PW (using LDP), MS-PW static but using LDP on each segment. There

   is no reason to now add, yet another way to create PW on that PE box.

5) The requirement is to be able to support TE for MS-PW. That does not

   preclude cases where in fact transport tunnel within ASes is LDP. If

   that is the case, one can argue equally against using RSVP-TE in all

   LDP based networks. 

[Nurit] we are talking on using the RSVP-TE for TE MS-PWs. I do not
argue about the use of LDP for non-TE MS-PWs or even for a SS_PW (TE or
non-TE). \[Nurit]

In fact, for hierarchical VPLS or inter-area or

   inter-routing domain but intra-AS MS-PWs may or may not have TE
requirements

   and LDP for transport on each PSN may be common. 

[Nurit] The requirement draft deals with TE MS-PWs as well. \[Nurit]

6) Also, RSVP-TE as a scalable solution for large number of MS-PW needs
to 

   be studied and how will it work for VPLS that spans multiple domains

   and passes through ASes that are not necessarily transient (i.e. has
VPLS

   members).

By simply labelling any solution other than RSVP-TE to be CR-LDP as a 

basis for an arguement for RSVP-TE has no merit. Besides, current
RSVP-TE

implementations do not have all the extensions that are required for

MS-PW signaling nor does the associated routing protocol. So in that
sense,

it is 'new' work, either way.

{Nurit} On this we have an argument. :-(. \[Nurit]

regards,

himanshu

> -----Original Message-----

> From: Nurit Sprecher [mailto:[email-masked]]

> Sent: Thursday, March 24, 2005 6:59 AM

> To: Shah, Himanshu; Stewart Bryant; pwe3

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

> Hi himanshu,

> In the discussion in the last IETF meeting I found no argument on the

> requirements for The TE MS PWs. We have a very strong idea on the

> requirements for the TE MS PWs. The LDP protocol as defined 

> today has no

> means to signal the required information for TE PWs. The LDP protocol

> should be extended to support the missing information. I guess that at

> the end we will get the CR-LDP back. But we are much behind this

> argument and we should respect the decision that RSVP-TE is 

> the protocol

> for TE. Since very little is required to add to the RSVP_TE to support

> the signaling of the TE MS PWs (i.e. PW ID/type/ control 

> word), I think

> that it just natural that the already appropriate protocol which

> requires just minimum extension is used for TE MS PWs. This is very

> natural also taking into consideration that the RSVP-TE is already

> deployed for the signaling of the TE Tunnels.

> I think this is the right stage to make this draft a WG document, when

> the requirements for the TE MS PWs are already specified and known.

> Nurit.

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On 

> Behalf Of

> Shah, Himanshu

> Sent: Wednesday, March 23, 2005 5:37 PM

> To: Stewart Bryant; pwe3

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

> I think it is too early to make this draft a WG draft.

> We are still finalizing the requirements. We don't know

> (at least I don't know) how many other drafts/extensions

> in other WG has to be finalized. This draft depends on

> lot of work that may or may not be progressing in other WGs. 

> Hence I do not support making this draft a WG draft 

> at this time.

> /himanshu

> > -----Original Message-----

> > From: [email-masked] 

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

> Stewart Bryant

> Sent: Wednesday, March 23, 2005 6:32 AM

> To: pwe3

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

> 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

_______________________________________________

pwe3 mailing list

[email-masked]

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

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