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

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 23 Mar 2005 15:19:01 -0800 (PST)

Hi Hamid,

>
> Add to it that judging from the discussion we don't seem to
> agree on what problem(s) the proposal is actually addressing.
> For the discussion I can sense 3 problem spaces being proposed
> by this draft and it is not clear to me which one is really
> intended:
>
> -  Problem space (PS) 1: proposes rsvp-te as an alternative
>    to LDP/PW for PW regardless what problem is
>    being solved (single-segment, multi-segment, QoS,
>    explicit route, etc). Looks to me the draft-id
>    reflects this problem space (and hence the current
>    debate on protocols).

This is not the intention. The primary motivation for RSVP-TE is "MS-PW
Traffic Engineering". I will be happy to work with you to clarify the
problem space definition in the ID.

> And the draft solves all these
>    problems. In my view to follow this option the wg needs to
>    discuss whether a new protocol for pw is needed
>    in general.
>
> -  PS 2: proposes that RSVP-TE is a better proposal
>    than LDP for the WG to pursue in order to address
>    "in a single shot" both QoS/TE and MS-pw problem spaces.

Yes.

thanks,
rahul

>    In that option the WG will leave these 2 problems to rsvp-te
>    solution and will *not* pursue any LDP-based solution for
>    these 2 problem spaces. This option explains (to me at least)
>    why we hear some arguments about rsvp-te versus cr-ldp
>    for pw.
>
> -  PS 3 proposes that the WG works on both LDP and RSVP-TE
>    for QoS and multi-segment PW problems only.
>
> It is not clear what problem space is actually intended, and
> it is clear that in fact we don't seem to agree on the problem
> being addressed.
>
> My suggestion (inline with Vach suggestion) would be to first:
>
> a) refine the new charter with respect to the objective
>    and clarifies the problem spaces and the type of
>    mechanisms pwe3 will work on for ms-pw (and QoS if any).
> b) identify what other WG will work on based on the
>    requirements identified.
> c) get the charter accepted and then we can progress
>    what appropriate solution needs to be pursued.
>
> Unless we close on that it seems to me the debate on
> progressing at this point in time specific solutions for
> unknown/misunderstood problem(s) will not be fruitful.
>
> Hamid.
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

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

A few reponses in-line below.

Dave 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hamid Ould-Brahim
> Sent: Wednesday, March 23, 2005 4:29 PM
> To: [email-masked]; 'Stewart Bryant'; 'pwe3'
> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
> 
> 
> Vach, All,
>  
> > 
> > I don't think either this or any other solution to the M{H|S}-PW 
> > problem should be a WG document until the charter is 
> modified and the 
> > requirements are accepted as a WG document.
> > 
> 
> The new proposed charter actually captured that mechanisms 
> need to be defined for multi-segment pw and the current 
> charter captured that requirements need to be gathered for 
> inter-as pw. I actually preferred the new charter includes 
> both requirements and mechanisms (and why not work on a 
> simple framework document on mh/s pw) before even discussing 
> solutions, etc. 
> 
> As I mentioned before the new charter needs to provide 
> further clarification on what type of mechanisms that need to 
> be pursued in pwe3. 
> 
> I do agree that unless we agree on the new charter and what 
> problem space and mechanisms pwe3 and l2vpn will work on for 
> ms-pw, the debate on accepting/rejecting solutions is a bit 
> premature at this point in time. 
> 
> For the discussion I can sense 3 problem spaces being 
> proposed by this draft and it is not clear to me which one is really
> intended:
> 
>    debate on protocols). And the draft solves all these

At this time, I would not want to exclude Problem Statement 3. I can see at
least one use case in the MS-PW requirements where a large number of small,
simple access devices that do not run IGP-TE could use simple extensions to
PW-LDP. For an MS-PW that must traverse multiple PW segments (term still to
be precisely defined), then a control protocol that has richer QoS, FRR, and
routing functions could be used (e.g., RSVP-TE). I think the LDP extension
set is small: a Quantity TLV (e.g., RSVP sender Tspec), something
identifying the eventual target U-PE (either what we proposed or something
else), and possibly something that indicates the desired quality (this is
where I believe RSVP-TE is not complete and additional work may be necessary
here). The choice of the PW-LDP extensions could be identical to RSVP-TE, as
suggested by Kireeti at the Minneapolis meeting to ease interworking where
it is needed. 

These simple, small U-PE devices could be singly attached to an S-PE by some
underlying L1 or L2 technology to provide resiliency. Even dual homing ogf
such a U-PE to two S-PEs could be done with simple static routing at the
U-PE. I had suggested that this be added to the MH-PW requirements and it
was not included in the -01 version. Does anyone have an objection or
clarification to including this clarification and extension of the use case
into the MS-PW requirements WG document?

> it is clear that in fact we don't seem to agree on the 
> problem being addressed. 
> 

Since most of the protocol discussion is occurring on PWE3, I recommend that
the PWE3 charter interpretation on "mechanisms" should be to include this
work in PWE3.