Subject: Requirements +

From: "cagatay koc" <[email-masked]>
Date: Mon, 9 Aug 2004 22:45:16 -0400

WG,
In the PWE3 session of the IETF meeting on last monday, after I presented Du
Ke's draft we had a discussion with Peter Busschbach and Mark Townsley and
it became clear that the 
'switching/stiching' solutions (functionality/location), are a bit premature
given the fact that a detailed requirement document is missing which should
also iron out terminology and other critical issues. It would make sense to
quickly put down a draft on intra-AS, inter-AS requirements relevant to PW
switching points, taking into account operator needs as well 
as requirements already implied in the existing documents. These points are
made several times here but it would make sense to form a group of
volunteers to draft a common document. I also  talked with Luka Martini and
he thinks there might be a requirement document (which I could not find) and
Nabil Bitar also agrees with this 
'soft concensus', obviously Neil from his mails agrees with this assessment.
Latest exchange between Mustafa and Peter also can be resolved with a
requirement document.
I am willing to work on this as long as we have a few other volunteers (at
least 1 from operator side).
Best regards,
Cagatay Buyukkoc

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 10 Aug 2004 08:53:04 +0200

Cagatay, Luca and all,
I agree that the present requirements document does not
address fully thie issues associated with multi-hop PWs.
I also agree that some issues should rather be addressed 
in the L2VPN WG, but I think that there is quite a sunstantial
amount of work to be done in the PWE3.

I am interested in participating in the requirements effort.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2004 12:30 AM
> To: cagatay koc
> Cc: [email-masked]; Chris Metz
> Subject: Re: [PWE3] Requirements +
> 
> 
> Cagatay,
> 
> I believe that we should have a short draft to spell out the 
> requirements, but we should be careful to avoid any 
> autoprovisioning/autodiscovery requirements for PWE3.
> A separate draft addressing autodiscovery requirements, for 
> PWs needs to 
> be submitted in L2VPN.
> We also need a draft in L2VPN to expand the existing solution of BGP 
> autodiscovery, and Radius autodiscovery to include 
> intraAS/Interprovider 
> requirements.
> 
> The requirement document I was talking about is :
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requiremen
> ts-08.txt
> 
> In particular the section :
> 
> 10 Inter-domain Issues
> PWE is a matter between the PW end-points and is transparent to the
>    network devices between the PW end-points.  Therefore, inter-domain
>    PWE is fundamentally similar to intra-domain PWE.  As long as PW
>    end-points use the same PWE approach, they can communicate
>    effectively, regardless of whether they are in the same domain.
>    Security may become more important in the inter-domain 
> case and some
>    security measure such as end-point authentication MAY be applied.
>    QoS may become more difficult to deliver too, as one 
> service provider
>    has no control over another service provider's provisioning and
>    traffic management policy. To solve the inter-domain QoS problem,
>    service providers have to cooperate. Once they agree at a 
> contractual
>    level to provider high quality of service to certain traffic (e.g.
>    PWE traffic), the mechanisms defined in other working groups, e.g.
>    Diffserv WG, can be used.
> 
>    Inter-domain PSN tunnels are generally more difficult to 
> set up, tear
>    down and maintain than intra-domain ones. But that is an issue for
>    PSN tunneling protocols such as MPLS and L2TPv3 and is outside the
>    scope of PWE3.
> 
> Obviously this is not adequate. I think we need to be careful 
> to focus a 
> requirement document in on this particular topic only.
> 
> We can start working on the PWE3 requirement document if you want.
> 
> Luca
> 
> 
> 
> cagatay koc wrote:
> 
> >WG,
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >  
> >
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Tue, 10 Aug 2004 10:15:10 +0100

Rahul....

>
> 
> Hi Cagatay,
> 
> On Mon, 9 Aug 2004, cagatay koc wrote:
> 
> >
> > WG,
> > In the PWE3 session of the IETF meeting on last monday, after I 
> > presented Du Ke's draft we had a discussion with Peter 
> Busschbach and 
> > Mark Townsley and it became clear that the 'switching/stiching' 
> > solutions (functionality/location), are a bit premature 
> given the fact 
> > that a detailed requirement document is missing which 
> should also iron 
> > out terminology and other critical issues.
> 
> Agreed.
> 
> > It would make sense to
> > quickly put down a draft on intra-AS, inter-AS requirements 
> relevant 
> > to PW switching points, taking into account operator needs 
> as well as 
> > requirements already implied in the existing documents.
> 
> This requirements effort should be viewed as the next set of 
> requirements to evolve MPLS PWs, being driven by the natural 
> curve of technology evolution.
NH=> I think agree with what you are hinting at here....and I note you
also seem to differentiate 'MPLS PWs' from 'IP PWs' (explicit or
subconscious?).  And when you realise this, the key objective to make
sure MPLS is properly specified both per se and wrt to a client/server
relationship.

> It should not be viewed as a 
> narrow effort focussing on PW stitching.
NH=> Absolutely.....this is creating a new layer network which is
unnecessary and is not addressing the real requirements of operators
like BT.

> More specifically 
> the following issues should also be part of this effort:
>    - Multi-hop PW traffic engineering
>    - PW QoS
NH=> Careful.....QoS tends to crop-up as a throw-way line all the time.
There is a specific ordering:  Valid mode
arch=>Defects=>(un)availability=>PM.  Qos is not an objective metric, it
is subjective and varies from application to application for a fixed
level of network performance impairment.

>    - PW Redundancy
NH=> If you change 'PW' to 'MPLS' in the above bullets I am with you.
Also need to add:
-	consistent access point IDs of LSPs
-	OOB control/management to provide increased security and
stability (of these key protocols).....note that the GMPLS folks had to
make RSVP-TE work with an OOB control network, so folks have already
been here with this signalling protocol
-	the right in-band OAM that can do the ordering noted above, and
with activation/deactivation that is tightly coupled with (signalling)
LSP set-up/tear-down.

Do this and we would have a solution that would be very good.
> 
> draft-raggarwa-rsvpte-pw-00.txt has a discussion on some of this.
NH=> I'd like RSVP-TE for sure to be considered.  Not sure how close you
are to what I am driving at above...I'll go look.
> 
> Auto-discovery/routing issues should also be part of this 
> (beaten to death in another thread). If it so happens that 
> some of these requirements need to be handed off to another 
> group (l2vpn for example) that is fine. But let us start with 
> the big picture in mind.
> 
> > I am willing to work on this as long as we have a few other 
> volunteers 
> > (at least 1 from operator side).
NH=> We for sure would want some input on this.  But IMO its operators
who should largely set the requirements here.
> 
> I would be open to participating.
> 
> Thanks,
> rahul
> 
> > Best regards,
> > Cagatay Buyukkoc
> >
> >
> >