Subject: Invitation to discuss: "P2MP problem statement" - decision

From: Loa Andersson <[email-masked]>
Date: Tue, 09 Sep 2003 19:04:45 +0200

WG,

I have the working group consensus to ask the ADs to
add the p-2-mp milestones to our charter. In fact we
have only seen support :).

Alex,

could you start the process to add the following milestone
the the mpls wg charter.

Milestones

- produce a requirement specification that defines the scope,
   requirements, and issues to resolve for how to setup a P2MP TE LSPs
   by Minneapolis 2003 meeting.

- produce a small number of solution draft(s) which specify protocol
   extensions, enhancements and mechanisms for P2MP TE LSPs by spring
   2004 IETF meeting.

/Loa

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 Sep 2003 15:21:48 -0400

Loa,
         Just want to clarify a point:  Do P2MP TE LSPs include all GMPLS 
switching types or just PSC?  I think inclusion of all types is 
important/goodness.

Thanks,
Lou

---

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Tue, 9 Sep 2003 14:37:53 -0700

Lou,

   Yes it does. In fact, the P2MP TE LSPs can be used in
   both packet based (MPLS) or non-packet based (GMPLS)
   networks, as originally intended.

Dean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou
Berger
Sent: Tuesday, September 09, 2003 12:22 PM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: Invitation to discuss: "P2MP problem statement" - decision

Loa,
         Just want to clarify a point:  Do P2MP TE LSPs include all
GMPLS 
switching types or just PSC?  I think inclusion of all types is 
important/goodness.

Thanks,
Lou

---

From: Loa Andersson <[email-masked]>
Date: Wed, 10 Sep 2003 00:04:50 +0200

Lou and Dean,

I guess this is what should be classified as "good question".
What Dean says about the possibility to use the P2MP TE LSPs
both in packet based and non-packet based networks is true.
When it comes to the scope of what the MPLS working group
will define it could be another matter, extending this to
include specifications that are applicable for non-packet
based networks would require that we explicitly says so in
the wg charter and that it is OKed by the ADs.

Having said this it is my opinion that we should do the work
only once and in the mpls wg.

/Loa

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Sep 2003 13:03:01 +0100

To summarize the answers I got to this same question when I asked it last month:
the problem statement will be enhanced to cover packet and non-packet traffic

Are we due a revision of the problem statement following the discussions from the last
month?

I also asked that the ADs and CCAMP be consulted on this work. It is unclear to me that
- MPLS should work on something that is not packet oriented
- we should risk a solution in MPLS that does not fit GMPLS
- we should risk inventing new techniques in MPLS when GMPLS techniques
  may already exist.

Adrian

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 10 Sep 2003 14:41:06 -0700 (PDT)

> the problem statement will be enhanced to cover packet and non-packet traffic

I am in favor of that as we discusssed last month. The problem statement
should be generic.

> Are we due a revision of the problem statement following the discussions from the last

The intention was to incorporate the problem statement in the requirements
draft, along with the changes.

rahul

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 9 Sep 2003 13:51:41 +0200

Hi Loa and all

1: This problem statement is IMHO very well written, and fits our
expectations.
As Adrian mentionned earlier, it could be good to highlight that routing
and tree computation are out of the scope.

2: I'm in favor of adding this item in the charter.

JL  

-----Message d'origine-----
De : Loa Andersson [mailto:[email-masked]]
Envoye : mercredi 13 aout 2003 23:34
A : Kullberg Alan-G19424; [email-masked]
Objet : Invitation to discuss: "P2MP problem statement"

Alan + both teams,

thanks for preparing this!

Working Group,

below you will find the p2mp problem statement prepared by the
autors behind the drafts:
    draft-yasukawa-mpls-rsvp-p2mp-02.txt
    draft-raggarwa-mpls-p2mp-te-00.txt

I would like to have your response on

1. the content of the problem statement
2. whether the mpls working group should ask the ADs
    that a new milestone om p2mp mpls should be added
    to our charter

If there is support we plan to take this as an separate item
(not include it in the more general charter update) to the
ADs. Again this is a question for which I would like boths
the pros and cons to speak up. Silence will not be interpreted
(one way or another).

/Loa

Kullberg Alan-G19424 wrote:
> Loa & George,
> 
> Below is a problem statement for point-to-multipoint using MPLS.
> This problem statement has been prepared jointly by the authors
> of the drafts:
>   draft-yasukawa-mpls-rsvp-p2mp-02.txt
>   draft-raggarwa-mpls-p2mp-te-00.txt
> 
> Please use this problem statement as a basis to get the MPLS WG
> charter updated to include P2MP work.
> 
> Thanks,
> Alan
> 
> #########################
> 
> Problem statement
> 
> 
> Content Distribution (CD), Interactive multi-media (IMM), and VPN
multicast
> are
> applications that are best supported with multicast capabilities.
> 
> IP Multicast provides P2MP communication. However, there are no
Traffic
> Engineering (TE) capabilities or QoS guarantees with existing IP
multicast
> protocols.  Note that diff-serv combined with IP multicast routing is
not
> sufficient for P2MP applications for many of the same reasons that it
is not
> sufficient for unicast applications - TE and CSPF are required to
enable and
> scale the intelligent management of network resources, to prevent
> congestion, and
> to enable sub-second rerouting around network failures.
> 
> One possible solution would be to setup multiple P2P TE LSPs, one to
each of
> the
> required  egress PEs. This requires replicating incoming packets to
all the
> P2P
> LSPs at the ingress PE to accommodate multipoint communication. This
is sub-
> optimal. It places the replication burden on the ingress PE and hence
has
> very
> poor scaling characteristics. It also wastes bandwidth resources,
memory and
> MPLS
> (e.g. label) resources in the network.
> 
> Hence, to provide TE for a P2MP application in an efficient manner in
a
> large
> scale environemnt, P2MP TE mechanisms are required.  Existing MPLS P2P
TE
> mechanisms have to be enhanced to support P2MP TE LSP setup.
> 
> We propose that MPLS be enhanced to setup P2MP TE LSPs. This should be
> achieved
> without running a multicast routing protocol in the network core and
with
> maximum
> re-use of the existing MPLS protocols. A P2MP LSP will be setup with
TE
> constraints and will allow efficient packet replication at various
branching
> points in the network. RSVP-TE will be used for setting up a P2MP LSP
with
> enhancements to existing P2P TE LSP procedures. The P2MP TE LSP setup
> mechanism
> will include the ability to add/remove receivers to/from an existing
P2MP
> LSP.
> 
> The MPLS WG will specify only how to setup a P2MP TE LSP. The usage of
this
> will
> be application dependent.
> 
> (Milestones)
> 
> To produce a requirement draft that specifies the scope, requirements,
and
> issues
> to resolve for this enhancement by Minneapolis 2003 meeting.
> 
> To produce a small number of solution draft(s) which specify protocol
> extensions,
> enhancements and mechanisms to fill the requirement and solve the
above
> problem
> by spring 2004 IETF meeting. 
> 
> 
> 
> 
> 
> 
>  (Example)
> 
>      Consider the following figure.
> 
>                         Source 1 (S1)
>                                |
>                               PE1
>                              |   |
>                              |   |
>                  R2----PE3--P1   P2---PE2--Receiver 1 (R1)
>                              |
>                             PE4----R3
>                              |
>                              |
>                             R4
> 
>                            Figure 1.
> 
>       The above figure shows PE1, PE2, PE3 and PE4. PE1 is attached to
a
> traffic
> source that is generating traffic for a P2MP application. PE2, PE3 and
PE4
> are
> attached to receivers that are interested in receiving traffic for the
> application. The following are the objectives that we wish to achieve:
> 
>       a) Set up a P2MP TE LSP from PE1 to PE2, PE3 and PE4.
>       b) Packet replication should be efficient. In this case, the
branch
> node P1
>          should replicate incoming packets and send them to PE3 and
PE4.
>       c) The P2MP TE LSP should be setup by enhancing existing RSVP-TE
P2P
>          procedures and without running a multicast routing protocol
in the
>          network core.

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Sep 2003 09:21:52 -0400

Loa,
         Thanks for the response.  I agree that the work should be done 
only once.   I'm happy for the work to be done in MPLS WG.  If the ADs want 
to move it, that's fine too as the same people will work on it in either case!

Lou

At 06:04 PM 9/9/2003, Loa Andersson wrote:

> > From: [email-masked] 
> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of Lou
> > Berger