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

From: Luca Martini <[email-masked]>
Date: Thu, 24 Mar 2005 09:30:04 -0700

Ben

I think that the main problem here is that we have not yet arrived at a 
good set of requirements. The work is not completed.

It may be that in the end we have an RSVP-TE solution, however right now 
we are attempting to finish the definition of the requirements , then 
figure out what protocols are needed.

Assuming that we want RSVP-TE, we would need the following steps:

   1. Have a setup of requirements, and a matching framework.
   2. Define the  RSVP-TE based setup protocol  for SS-PW.
   3. Define the Interworking between RSVP-TE and the other PW setup
      protocols , like L2TPV3, Static, And LDP
   4. Define the RSVP-TE interprovider protocol setup and maintenance
      for PWs.

So do we want to start with #4 ?
Maybe we should  not build houses starting from the roof down .....

This is exactly why I did not submit an LDP interprovider solution draft 
in the first place. Maybe that is not the right solution.

We are always striving to improve the IETF process , so for once we are 
starting from the right direction .... let's not turn around...

Luca

[email-masked] wrote:

>Colleagues,
>
>I would support this draft (draft-raggarwa-rsvpte-pw-01.txt) becoming a WG draft because as an operator I would like a common set of control protocols across my connection orientated networks (at least one instance of each control protocol per layer network) in order to ultimately reduce my opex.
>
>Couple of comments/observations:
>>From what I can tell only 2 or 3 service providers/operators have expressed an opinion and most of the opinions expressed have been from two companies (one for and one against).  I would like to see more operator input & opinion on this draft, especially by the other operators that participated in producing the MS-PW requirements draft (FT, AT&T, Verizon) as I presume those are the operators with the most interest in MS-PWs at the moment.
>
>Also, I've found the LDP Vs RSVP argument for PW setup interesting, but I think it somewhat misses the point, when MPLS signalling was being done it seemed perfectly acceptable to have a signalling protocol for cl-ps MPLS (LDP) and a signalling protocol for co-ps MPLS (RSVP-TE).  Now that PWs are moving from a simple layer network adaptation (SS-PW) into a full layer network in themselves (MS-PW) it does not logically follow that the protocol used to signal session associations between two end points is necessarily the most appropriate one to use to signal a trail association across multiple link connections.  Therefore I believe the WG shouldn't just assume 'we have LDP already, let's re-use that' but should assess both LDP & RSVP and then make an informed (and impartial if possible) choice as to which is the most appropriate.
>
>Finally, given the moves I see in the CCAMP & MPLS WGs on MPLS->GMPLS migration, then considering the use of RSVP for MS-PW signalling makes sense to me, as one of the key benefits to an operator of deploying a GMPLS control plane is the ability to take that control plane out of band with respect to the traffic data plane.  (GMPLS) RSVP-TE supports this, LDP (to my knowledge) does not.  As a full service operator I would like the option to take all (or just some subset at my discretion) of my control/management planes out of band.  By not considering RSVP as a possible solution I am left in the situation where my "MPLS transport network" can have an out of band control/management plane but my "MPLS service network" (aka MS-PWs) can not support an out of band control/management network.
> 
>
>Ben
>
>  
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 24 Mar 2005 08:36:46 -0800

Hi,

I agree with you that we need to hear more from the carriers.

IMHO, MH-PW is an extension from single-hop PW. Here is the deployment 
situation and reasons for using LDP:

http://www.ietf.org/internet-drafts/draft-minei-ldp-operational-experience-00.txt

If the above draft reflects any reality at all, (1) should we pursue an 
alternative solution? (2) is the changes introduced in MH-PW so huge 
that we have to use a different signaling protocol for PW's?

I guess I am just confused here.

Thanks!

- Ping

---

From: David McDysan <[email-masked]>
Date: Thu, 24 Mar 2005 13:11:28 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, March 24, 2005 9:58 AM
> To: [email-masked]
> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
> 
> Colleagues,
> 
> I would support this draft (draft-raggarwa-rsvpte-pw-01.txt) 
> becoming a WG draft because as an operator I would like a 
> common set of control protocols across my connection 
> orientated networks (at least one instance of each control 
> protocol per layer network) in order to ultimately reduce my opex.
> 
> >From what I can tell only 2 or 3 service providers/operators 
> have expressed an opinion and most of the opinions expressed 
> have been from two companies (one for and one against).  I 
> would like to see more operator input & opinion on this 
> draft, especially by the other operators that participated in 
> producing the MS-PW requirements draft (FT, AT&T, Verizon) as 
> I presume those are the operators with the most interest in 
> MS-PWs at the moment.
> 
> Also, I've found the LDP Vs RSVP argument for PW setup 
> interesting, but I think it somewhat misses the point, when 
> MPLS signalling was being done it seemed perfectly acceptable 
> to have a signalling protocol for cl-ps MPLS (LDP) and a 
> signalling protocol for co-ps MPLS (RSVP-TE).  Now that PWs 
> are moving from a simple layer network adaptation (SS-PW) 
> into a full layer network in themselves (MS-PW) it does not 
> logically follow that the protocol used to signal session 
> associations between two end points is necessarily the most 
> appropriate one to use to signal a trail association across 
> multiple link connections. 

Nor does it imply that the same protocol is used as each segment. For,
example different protocols are used at the "UNI" and "NNI" for telephone,
FR, ATM, and some IP service networks (e.g., BGP MPLS - BGP used at "UNI"
and MP BGP at "NNI.) 

 Therefore I believe the WG 
> shouldn't just assume 'we have LDP already, let's re-use 
> that' but should assess both LDP & RSVP and then make an 
> informed (and impartial if possible) choice as to which is 
> the most appropriate.
> 

I think that an LDP versus RSVP debate is too limiting at this point. I
point out that as part of the solution space, I think that the group also
needs to consider the work in the L2VPN wg using MP BGP for inter-AS VPWS.
Also, I think that not enough thought nor discussion has occurred to pick a
particular solution at this point.

> Finally, given the moves I see in the CCAMP & MPLS WGs on 
> MPLS->GMPLS migration, then considering the use of RSVP for 
> MS-PW signalling makes sense to me, as one of the key 
> benefits to an operator of deploying a GMPLS control plane is 
> the ability to take that control plane out of band with 
> respect to the traffic data plane.  (GMPLS) RSVP-TE supports 
> this, LDP (to my knowledge) does not.  As a full service 
> operator I would like the option to take all (or just some 
> subset at my discretion) of my control/management planes out 
> of band.  By not considering RSVP as a possible solution I am 
> left in the situation where my "MPLS transport network" can 
> have an out of band control/management plane but my "MPLS 
> service network" (aka MS-PWs) can not support an out of band 
> control/management network.
>  
> 
> Ben
> 
> --
> Ben Niven-Jenkins
> Networking Specialist, BT Exact
> 
> e-mail: [email-masked]
> tel: +44(0) 1473 648225
> mob: +44(0) 7918 077205
> 
> pp34/161 B81 Callisto House, Adastral Park, Martlesham, 
> Ipswich IP5 3RE, UK
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Ina Minei <[email-masked]>
Date: Thu, 24 Mar 2005 10:40:37 -0800 (PST)

Ping,

> http://www.ietf.org/internet-drafts/draft-minei-ldp-operational-experience-00.txt

	The draft that you are pointing to is for LDP deployment in
general, not specific to pseudo-wire setup. Also note that this draft only
reflects the situation for LDP deployments - operators running RSVP
networks did not reply to this survey.

> alternative solution?

	If anything, the conclusion from the survey should be yes,
pursuing an alternative solution is in order. Imagine an operator
runnin an RSVP network If the only reason for LDP deployment is pw
support, then an RSVP-based pw solution is attractive, since the operator
will have less protocols to manage.

				Ina

(2) is the changes introduced in MH-PW so huge

---

From: Ping Pan <[email-masked]>
Date: Thu, 24 Mar 2005 11:39:43 -0800

Ina,

I made the previous observation based on this in the draft:
...
    The list of applications is as follows. L3VPNs: 9, pseudo-wires: 4
    current (and one planned deployment), L2VPNs: 4, forwarding based on
    labels: 2, BGP-free core: 1

    There are two major options for label distribution protocols, LDP and
    RSVP-TE. One of the key differences between the two is that RSVP-TE
    has support for Traffic Engineering (TE), while LDP does not.  The
    reasons cited for picking LDP as the label distribution protocol are:
      o The deployment does not require traffic engineering - 6
      o Inter-operability concerns if a different protocol is used - 5
      o Equipment vendor only supports LDP - 5
      o Ease of configuration - 4
      o Ease of management - 3
      o Scalability concerns with other protocols - 3
      o Required for a service offering of the service provider - 1
...

So I assume that, today, in the context of PWE3, LDP is the protocol for 
those 4 carriers (actually I know there are more than 4). The rest of 
the paragraph seems to argue for the reasons for carriers to use LDP for 
various applications.

This goes back to the question: what would be the impact for supporting 
MH-PW? I do concern about the scope of the change. If it's not huge, 
what's the point?

Thanks!

- Ping