Subject: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt

From: [email-masked]
Date: Wed, 01 Mar 2006 10:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Label Distribution Protocol Extensions for
                          Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
	Author(s)	: I. Minei, et al.
	Filename	: draft-ietf-mpls-ldp-p2mp-00.txt
	Pages		: 20
	Date		: 2006-3-1
	
This document describes extensions to the Label Distribution Protocol
(LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
Label Switching (MPLS) networks.  The solution relies on LDP without
requiring a multicast routing protocol in the network.  Protocol
elements and procedures for this solution are described for building
such LSPs in a receiver-initiated manner.  There can be various
applications for P2MP/MP2MP LSPs, for example IP multicast or support
for multicast in BGP/MPLS L3VPNs.  Specification of how such
applications can use a LDP signaled P2MP/MP2MP LSP is outside the
scope of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-ldp-p2mp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ldp-p2mp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Thu, 2 Mar 2006 05:59:25 EST

Some  critical notes wrt mp2mp LSP: 
The terms  upstream and downstream relate to the terms ingress and egress, 
but not to root (and three times not to root while keeping open  whether the 
root is an ingress(+egress) at  all). 
The mp2mp  LSP is supposed to be a mesh-less delivery channel which 
interconnects a  specific set of leaf nodes such that at any junction traffic is 
forwarded to all  other directions except the one from where it is received. This is 
my  understanding about the mp2mp stream direction. The presented design with 
its  upstreams and downstreams all over the place is fairly a sign of 
ossification,  isn’t it ? 
Heiner  Hummel
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Fri, 3 Mar 2006 12:21:57 -0000

An observation.  There is no such construct as a mp2mp
*connection*.....one can have any-any in a cl-ps mode network (precisely
because there are no connections) but it is NOT possible to have mp2mp
connections in either a co-ps or co-cs mode network.  This can be proved
by an appeal to (Shannon) information theory.....but it would require a
very lengthy explanation, especially wrt how labelling works (its not as
simple as some folks might assume).
 
However, let me simply state here what the bottom-line conclusions/rules
are:

A connection must:
- only have a single source
- only have connectivity of 1 

....so only p2p and p2mp connection constructions are allowed.

Further, and consequential from the above:
- ordering of traffic units is preserved in a connection
- once created there is no routing choice available in a connection

A trail is 'the source to a specific-sink' relationship in these
connection constructs.

regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 02 March 2006 10:59
To: [email-masked]
Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt 

The terms upstream and downstream relate to the terms ingress and
egress, but not to root (and three times not to root while keeping open
whether the root is an ingress(+egress) at all).

The mp2mp LSP is supposed to be a mesh-less delivery channel which
interconnects a specific set of leaf nodes such that at any junction
traffic is forwarded to all other directions except the one from where
it is received. This is my understanding about the mp2mp stream
direction. The presented design with its upstreams and downstreams all
over the place is fairly a sign of ossification, isn't it ?

Heiner Hummel

---

From: "Rutemiller, John" <[email-masked]>
Date: Fri, 3 Mar 2006 09:04:25 -0500

A construct that has not been mentioned, but is useful in this discussion is
mp2p.
 
Based on Neil's definition, mp2p is not a connection. This makes sense when
you think about it. At the reciever, additional information is needed to
identify the sender of each packet in order to recover the individual
streams. So, mp2p is a multiplexing action which requires demultiplexing at
the receiver.
 
This is useful to keep in mind when talking about mp2mp. A mp2mp construct
is actually a combination of p2mp and mp2p.
 
>From the point of view of the sender, mp2mp looks like a p2mp connection. In
the MPLS world, any packet entering the network will take a fixed and known
path to the recievers. Looking at only this behavior, mp2mp looks like a
connection.
 
>From the point of view of the receiver, mp2mp looks like mp2p. The receiver
requires additional information in order to identify and recover the
different traffic streams.

John

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 7:22 AM
To: [email-masked]; [email-masked]
Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt 

An observation.  There is no such construct as a mp2mp *connection*.....one
can have any-any in a cl-ps mode network (precisely because there are no
connections) but it is NOT possible to have mp2mp connections in either a
co-ps or co-cs mode network.  This can be proved by an appeal to (Shannon)
information theory.....but it would require a very lengthy explanation,
especially wrt how labelling works (its not as simple as some folks might
assume).

A connection must:

A trail is 'the source to a specific-sink' relationship in these connection
constructs.

regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 02 March 2006 10:59
To: [email-masked]
Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt 

The mp2mp LSP is supposed to be a mesh-less delivery channel which
interconnects a specific set of leaf nodes such that at any junction traffic
is forwarded to all other directions except the one from where it is
received. This is my understanding about the mp2mp stream direction. The
presented design with its upstreams and downstreams all over the place is
fairly a sign of ossification, isn't it ?

Heiner Hummel

---

From: <[email-masked]>
Date: Fri, 3 Mar 2006 15:06:43 -0000

John,
 
I think you've put in a nushell.
 
Regards,
 
Andy

Andy Reid 
Chief Network Services Architect 

  _____  

	From: Rutemiller, John [mailto:[email-masked]] 
	Sent: 03 March 2006 14:04
	To: [email-masked]
	Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt 

	A construct that has not been mentioned, but is useful in this
discussion is mp2p.
	 
	Based on Neil's definition, mp2p is not a connection. This makes
sense when you think about it. At the reciever, additional information
is needed to identify the sender of each packet in order to recover the
individual streams. So, mp2p is a multiplexing action which requires
demultiplexing at the receiver.
	 
	This is useful to keep in mind when talking about mp2mp. A mp2mp
construct is actually a combination of p2mp and mp2p.
	 
	From the point of view of the sender, mp2mp looks like a p2mp
connection. In the MPLS world, any packet entering the network will take
a fixed and known path to the recievers. Looking at only this behavior,
mp2mp looks like a connection.
	 
	From the point of view of the receiver, mp2mp looks like mp2p.
The receiver requires additional information in order to identify and
recover the different traffic streams.

	John

  _____  

	 
	However, let me simply state here what the bottom-line
conclusions/rules are:
	
	A connection must:

	Further, and consequential from the above:
	- ordering of traffic units is preserved in a connection
	- once created there is no routing choice available in a
connection

	regards, Neil

		-----Original Message-----

		Sent: 02 March 2006 10:59
		To: [email-masked]
		Subject: Re: [mpls] I-D
ACTION:draft-ietf-mpls-ldp-p2mp-00.txt 

		The terms upstream and downstream relate to the terms
ingress and egress, but not to root (and three times not to root while
keeping open whether the root is an ingress(+egress) at all).

		The mp2mp LSP is supposed to be a mesh-less delivery
channel which interconnects a specific set of leaf nodes such that at
any junction traffic is forwarded to all other directions except the one
from where it is received. This is my understanding about the mp2mp
stream direction. The presented design with its upstreams and
downstreams all over the place is fairly a sign of ossification, isn't
it ?

		Heiner Hummel

---

From: [email-masked]
Date: Sat, 4 Mar 2006 05:31:56 EST

Ice,
 
 It is a MP2MP LSP from the point of view of the leafs, there is an  
upstream path to send to and a downstream path to receive from. 
 
HH>:I guess, you wanted to say: there is an upstream path to receive  from 
and a downstream path to send to.
 
If you 
look at the internals, it is a P2MP LSP from the root to all  the leafs. 
There is a P2P LSP from the leaf to the next upstream LSR until  you 
reach the root. While MPLS packets are forwarded upstream, they are  
allowed to go down the P2MP LSP if there are receivers.

HH>: Look at the mp2mp-LSP as a whole. Data is sent from any  particular leaf 
node to all other leaf nodes inside the LSP by forwarding the  data at any 
junction to all adjacent neighbor nodes (and nodes of the LSP)  except the one 
from where it is received. Depending on which leaf is the data  originator, any 
link or trail inside the LSP is once upstream and once  downstream. It is 
this basic understanding I am after. Accordingly the label  mapping process could 
be organized. But I have my doubts that it will. Let's see  what the 
respective draft will look like.
 
Heiner

Thx,

Ice.