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

From: [email-masked]
Date: Fri, 3 Mar 2006 13:12:45 EST

John,
 
I guess, it is not the task of the LSP to de-multiplex the received  data at 
any particular leaf node of the mp2mp-LSP, although this needs  to be done, 
too, however by some entity elsewhere. I think there are two  alternatives wrt 
the mp2mp-LSP:
(1) n p2mp-LSPs
(2) n mp2p-LSPs.
 
Whereas mp2mp-LSP is a third and different solution and should be  handled 
accordingly.
It is NOT a special p2mp-LSP, but I am afraid this is the view of the  
designers - for 2 reasons:
1: because all is designed in the light of upstream/downstream
2: it is not worth a separate draft, instead is like an appendix to  section 
2 which deals with the p2mp-LSP.
 
Heiner

In einer eMail vom 03.03.2006 15:05:03 Westeuropäische Normalzeit schreibt  
[email-masked]:

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).
 
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 

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

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 3 Mar 2006 21:02:11 +0100

> I guess, it is not the task of the LSP to de-multiplex the received 
> data at any particular leaf node of the mp2mp-LSP, although this needs 
> to be done, too, however by some entity elsewhere. I

Just to make a clarification. A true leaf of a MP2MP LSP does not need 
to do any de-multiplexing. Packets are received on one label, and are 
send using one label.

> think there are two alternatives wrt the mp2mp-LSP:
> (1) n p2mp-LSPs
> (2) n mp2p-LSPs.
>  
> Whereas mp2mp-LSP is a third and different solution and should be 
> handled accordingly.

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. 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.

Thx,

Ice.

> 2: it is not worth a separate draft, instead is like an appendix to 
> section 2 which deals with the p2mp-LSP.
>  
> Heiner
>  
>  
> In einer eMail vom 03.03.2006 15:05:03 Westeuropäische Normalzeit 
> schreibt [email-masked]:
>>
>> 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
>>  
>>  
>>
>> 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 trail is 'the source to a specific-sink' relationship in these 
>> connection constructs.
>> regards, Neil
>>> 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).
>>>  
>>> 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
>>