Subject: Re: [mpls-tp] [mpls] LSP merging in data-plane-draft

From: <[email-masked]>
Date: Wed, 3 Feb 2010 09:43:23 -0000

Re-sending as plain text and snipped to mpls-tp list....got a 'too big' bounce on 1st attempt to mpls-tp list...apologies for duplicates.

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 03 February 2010 09:33
	To: 'LEVRAU, LIEVEN (LIEVEN)'; Alexander Vainshtein; [email-masked]; 'Dan Frost'; Bocci, Matthew (Matthew)
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls] LSP merging in data-plane-draft

Yes, please be clear on merging.  I have seen folks remark that PBB-TE causes merging too because it only forwards on the (unswapped) DA label + VID label....which can be the same for 2 different connections from sources A and B say travelling towards the same sink Z.  This is completely missing the point however. 
	 
All networks (any mode) create "merging" if you think about it as traffic from N different sources makes its way towards some common sink X say.  The critical issue however is that of resource reservation AND whether one can distinguish the correct source at the sink.  The LDP form of MPLS takes no account of either of these points.  Moreover, the lost source information can only be recovered in a higher layer client....be this from the absolute SA label in a cl-ps client like IP (or in principle Ethernet) or an added label (the PW label) which proxies for the lost SA information for a non-cl-ps mode client.
	 
So the issue is not the common forwarding labels but preservation of source information and the fact that *each* connection must have its resource requirements OK'd before it can be placed.
	 
	regards, Neil

________________________________

		From: [email-masked] [mailto:[email-masked]] On Behalf Of LEVRAU, LIEVEN (LIEVEN)
		Sent: 03 February 2010 07:07
		To: Alexander Vainshtein; [email-masked]; 'Dan Frost'; Bocci, Matthew (Matthew)
		Cc: [email-masked]; [email-masked]
		Subject: [mpls] LSP merging in data-plane-draft

		Hello Shasha

		Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> LSP merging in data-plane-draft'

		On the topic of LSP merging... I think we need to define merging or elaborate on what merging is.

		Afai understand the LSP are not merged continuously. But only when/if a failure has occurred.

		So, for the concern when the FRR is operationally up and used, the other (primary) LSP is down, so in that case, I'm not sure we can still call it merging.

		PHP is by default not allowed in the MPLS-TP and I think that is clear in the frame work document.

		Suggestion - worth to mention but a non- issue.

		./

		Lieven

		1.      LSP Merge:

		o    In MPLS, nothing prevents LSPs from merging at some point:

		§  One well-known usage of LSP merge is FRR

		§  PHP can be considered as a special case of LSP merge

		o    One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. 

		o    It is not clear (at least, to me):

		§  Whether this limitation has to be respected at the data plane level, and if yes, then how

		§  Whether it means that FRR cannot be used in MPLS-TP

		o    Status of this topic in the -00 draft: not mentioned at all

<snipped>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 03 Feb 2010 14:59:19 +0100

Connection merging is used more often then most of us may believe. 

E.g. linear protection switching (e.g. 1+1 SDH VC-n SNC/N, 1:1 ODUk SNC/S))
includes a form of merging... The working and protection connections are
merged at the tail end of the protected domain... But an explicit set of
forwarding rules (controlled by the protection switch controller) prevents
that bad things happen.

Merging is also present in rmp and mp2mp Ethernet VCs. With the right OAM
design there is nothing wrong with those merging cases.

In PBB-TE p2p ESP connections are carried over mp2p ESP sublayer
connections. Those mp2p EPS sublayer connections are solely used to improve
scalability of the switching tables in the P nodes of PBB-TE. All monitoring
is done on the basis of the p2p ESP connections carried by those merging
mp2p connections. 

In general mp2p connections have their application space, and can be well
maintained with OAM that is designed to operate in a mp2p connection (e.g.
Y.1731 like OAM).

In MPLS(-TP) it is possible to use such mp2p (merging) LSPs in e.g. the
following scenario:
- assume that there are N PE nodes, which are interconnected by means of a
full mesh of p2p edge-to-edge LSPs.
- each edge-to-edge LSP is mapped into a mp2p edge-to-edge-tunnel LSP (N-1
input ports, 1 output port)
- each p2p edge-to-edge LSP packet gets a label stack entry header in which
the lable field has a value that is unique within the mp2p
edge-to-edge-tunnel LSP; values can be arbitrary selected, or can be
structured with e.g. MSB bits indicating a value in the range 0 to N-1
(encoding N NNI ports) and LSB bits encoding edge-to-edge instance per input
port
- each mp2p edge-to-edge-tunnel (e2et) LSP packet gets a label stack entry
header in which the label field has a value that distinguishes this e2et LSP
from any of the other e2et LSPs
- the P nodes in between the N PE nodes forward on the basis of the e2et LSP
label value
- the receiving PE is able to uniquely identify each p2p edge-to-edge LSP
packet by means and forward those packets on this basis
- the mp2p e2et LSP connection can be monitored for connectivity and
continuity problems using properly designed CC/CV OAM (like CCM OAM)
- the mp2p e2et LSP connection under normal cases can not monitor for packet
loss; but this is not an issue, as packet loss can be monitored in the p2p
edge-to-edge LSP connections. If monitoring would be a must, then the output
port MEP must support N-1 packet loss counters (i.e. one per p2p ME) and the
packet loss counting is using the MSB bits of the edge-to-edge LSP label as
identifier (i.e. all packets have a unique input port identifier value).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: woensdag 3 februari 2010 10:43
To: [email-masked]
Subject: Re: [mpls-tp] [mpls] LSP merging in data-plane-draft

 Re-sending as plain text and snipped to mpls-tp list....got a 'too big'
bounce on 1st attempt to mpls-tp list...apologies for duplicates.

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 03 February 2010 09:33
	To: 'LEVRAU, LIEVEN (LIEVEN)'; Alexander Vainshtein;
[email-masked]; 'Dan Frost'; Bocci, Matthew (Matthew)
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls] LSP merging in data-plane-draft

Yes, please be clear on merging.  I have seen folks remark that PBB-TE
causes merging too because it only forwards on the (unswapped) DA label +
VID label....which can be the same for 2 different connections from sources
A and B say travelling towards the same sink Z.  This is completely missing
the point however. 
	 
All networks (any mode) create "merging" if you think about it as traffic
from N different sources makes its way towards some common sink X say.  The
critical issue however is that of resource reservation AND whether one can
distinguish the correct source at the sink.  The LDP form of MPLS takes no
account of either of these points.  Moreover, the lost source information
can only be recovered in a higher layer client....be this from the absolute
SA label in a cl-ps client like IP (or in principle Ethernet) or an added
label (the PW label) which proxies for the lost SA information for a
non-cl-ps mode client.
	 
So the issue is not the common forwarding labels but preservation of source
information and the fact that *each* connection must have its resource
requirements OK'd before it can be placed.
	 
	regards, Neil

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of LEVRAU, LIEVEN (LIEVEN)
		Sent: 03 February 2010 07:07
		To: Alexander Vainshtein; [email-masked]; 'Dan Frost';
Bocci, Matthew (Matthew)
		Cc: [email-masked]; [email-masked]
		Subject: [mpls] LSP merging in data-plane-draft

		Hello Shasha

		Changed title from Comments on
draft-fbb-mpls-tp-data-plane-00 -> LSP merging in data-plane-draft'

		On the topic of LSP merging... I think we need to define
merging or elaborate on what merging is.

		Afai understand the LSP are not merged continuously. But
only when/if a failure has occurred.

		So, for the concern when the FRR is operationally up and
used, the other (primary) LSP is down, so in that case, I'm not sure we can
still call it merging.

		PHP is by default not allowed in the MPLS-TP and I think
that is clear in the frame work document.

		./

		Lieven

		1.      LSP Merge:

		o    In MPLS, nothing prevents LSPs from merging at some
point:

		o    One of the often repeated mantras of MPLS-TP is that
its LSPs cannot be merge. 

		§  Whether this limitation has to be respected at the data
plane level, and if yes, then how

		o    Status of this topic in the -00 draft: not mentioned at
all

<snipped>
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Wed, 3 Feb 2010 14:22:56 -0000

There is one point in here I take a strong exception to...please see in-line: 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 03 February 2010 13:59
> To: [email-masked]
> E.g. linear protection switching (e.g. 1+1 SDH VC-n SNC/N, 
> 1:1 ODUk SNC/S)) includes a form of merging... The working 
> and protection connections are merged at the tail end of the 
> protected domain... ***But an explicit set of forwarding rules 
> (controlled by the protection switch controller) prevents 
> that bad things happen.***

NH=> Oh yes indeed!  This last high-lighted sentence holds the key point about resource occupancy that is, for some reason, not explicity made clear above...see below now.
> 
> Merging is also present in rmp and mp2mp Ethernet VCs. With 
> the right OAM design there is nothing wrong with those merging cases.
> 
> In PBB-TE p2p ESP connections are carried over mp2p ESP 
> sublayer connections.

NH=> This is not correct.  There is no such animal as a mp2p *connection*....you can create a *merging construct* in the co-ps mode but is NOT a connection.  And note this point carefully:  If a merging construct was such a great/universal idea try creating such a beast end-end between trail termination points of 2 (or more) real traffic stream sources in the co-cs mode sometime and see what happens at the common sink (see the Note below)...well we are trying to make everything look alike aren't we ;-)   A connection MUST only have a single source.  

> Those mp2p EPS sublayer connections are 
> solely used to improve scalability of the switching tables in 
> the P nodes of PBB-TE. 

NH=> It is NOT the connections it is the fact one is using shared forwarding entries.  The actual BW of *each* different connection must still be accounted for independently....that is the key point.

Note - In the co-cs mode it is the *regular position/duration time-slices* that both provide the (forwarding) label AND explicitly tell us that we are allocating BW resource.  It is a physical impossibility for 2 such co-cs mode connections to have resource occupying the same space/time position, and that is why you cannot merge in the co-cs mode...it is quite different to the co-ps mode in this respect.

regards, Neil

> All monitoring is done on the basis of 
> the p2p ESP connections carried by those merging mp2p connections. 

> 
> In general mp2p connections have their application space, and 
> can be well maintained with OAM that is designed to operate 
> in a mp2p connection (e.g.
> Y.1731 like OAM).
> 
> In MPLS(-TP) it is possible to use such mp2p (merging) LSPs 
> in e.g. the following scenario:
> - assume that there are N PE nodes, which are interconnected 
> by means of a full mesh of p2p edge-to-edge LSPs.
> - each edge-to-edge LSP is mapped into a mp2p 
> edge-to-edge-tunnel LSP (N-1 input ports, 1 output port)
> - each p2p edge-to-edge LSP packet gets a label stack entry 
> header in which the lable field has a value that is unique 
> within the mp2p edge-to-edge-tunnel LSP; values can be 
> arbitrary selected, or can be structured with e.g. MSB bits 
> indicating a value in the range 0 to N-1 (encoding N NNI 
> ports) and LSB bits encoding edge-to-edge instance per input port
> - each mp2p edge-to-edge-tunnel (e2et) LSP packet gets a 
> label stack entry header in which the label field has a value 
> that distinguishes this e2et LSP from any of the other e2et LSPs
> - the P nodes in between the N PE nodes forward on the basis 
> of the e2et LSP label value
> - the receiving PE is able to uniquely identify each p2p 
> edge-to-edge LSP packet by means and forward those packets on 
> this basis
> - the mp2p e2et LSP connection can be monitored for 
> connectivity and continuity problems using properly designed 
> CC/CV OAM (like CCM OAM)
> - the mp2p e2et LSP connection under normal cases can not 
> monitor for packet loss; but this is not an issue, as packet 
> loss can be monitored in the p2p edge-to-edge LSP 
> connections. If monitoring would be a must, then the output 
> port MEP must support N-1 packet loss counters (i.e. one per 
> p2p ME) and the packet loss counting is using the MSB bits of 
> the edge-to-edge LSP label as identifier (i.e. all packets 
> have a unique input port identifier value).
> 
> Regards,
> Maarten
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Yes, please be clear on merging.  I have seen folks remark 
> that PBB-TE causes merging too because it only forwards on 
> the (unswapped) DA label + VID label....which can be the same 
> for 2 different connections from sources A and B say 
> travelling towards the same sink Z.  This is completely 
> missing the point however. 
> 	 
> All networks (any mode) create "merging" if you think about 
> it as traffic from N different sources makes its way towards 
> some common sink X say.  The critical issue however is that 
> of resource reservation AND whether one can distinguish the 
> correct source at the sink.  The LDP form of MPLS takes no 
> account of either of these points.  Moreover, the lost source 
> information can only be recovered in a higher layer 
> client....be this from the absolute SA label in a cl-ps 
> client like IP (or in principle Ethernet) or an added label 
> (the PW label) which proxies for the lost SA information for 
> a non-cl-ps mode client.
> 	 
> So the issue is not the common forwarding labels but 
> preservation of source information and the fact that *each* 
> connection must have its resource requirements OK'd before it 
> can be placed.
> 	 
> 	regards, Neil
> 
> 
> 		From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of LEVRAU, LIEVEN (LIEVEN)
> 		On the topic of LSP merging... I think we need 
> to define merging or elaborate on what merging is.
> 
> 		Afai understand the LSP are not merged 
> continuously. But only when/if a failure has occurred.
> 
> 		So, for the concern when the FRR is 
> operationally up and used, the other (primary) LSP is down, 
> so in that case, I'm not sure we can still call it merging.
> 
> 		 
> 
> 		PHP is by default not allowed in the MPLS-TP 
> and I think that is clear in the frame work document.
> 
> 		§  Whether this limitation has to be respected 
> at the data plane level, and if yes, then how
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 03 Feb 2010 16:18:57 +0100

Neil,

> NH=> It is NOT the connections it is the fact one is using shared
> forwarding entries.  The actual BW of *each* different connection
> must still be accounted for independently....that is the key point.

Now you touch upon a new topic... i.e. the administration of BW... As far as
I know there are two alternatives for such administration:
1) divide the resource BW (i.e. of the phy media) into smaller pieces and
allocate one piece to each transport path layer transport path (i.e.
edge-to-edge LSP); in my terminology each VP connection get a BW. Then
allocate a piece of each VP's BW to a transport service layer transport path
(e.g. ms-pw, service-lsp).

2) don't fragment the resource BW into pieces per transport path layer
transport path; i.e. edge-to-edge LSPs have unspecified BW, they just are
used as a scalable forwarding entity in a domain. Then allocate a piece of
each resource BW to a transport service layer transport path (e.g. to a
ms-pw or service-lsp).

In alternative 1, each connection (edge-to-edge lsp, ms-pw, service-lsp)
have a reserved BW.

In alternative 2, only the transport service layer transport paths (VC
connections) have a reserved BW; the transport path layer transport paths
(VP connections) have unspecified BW. Their BW is the sum of transport
service layer transport path BWs.

Alternative 2 has a better performance, as it prevents fragmentation of the
resource BW.

As such, "BW" is a parameter of a "connection", and this BW parameter can
have different values: e.g. an allocated fixed bandwidth, a reserved fixed
bandwidth, a reserved fixed plus a variable bandwidth, an unspecified
bandwidth (i.e. just the sum of client BWs).

With this BW <=> connection relationship it should be clear to you that a
mp2p connection is a connection; its BW can be unspecified (i.e. sum of its
client BWs).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 3 februari 2010 15:23
To: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [mpls] LSP merging in data-plane-draft

There is one point in here I take a strong exception to...please see
in-line: 

> 1:1 ODUk SNC/S)) includes a form of merging... The working and 
> protection connections are merged at the tail end of the protected 
> domain... ***But an explicit set of forwarding rules (controlled by 
> the protection switch controller) prevents that bad things happen.***

NH=> Oh yes indeed!  This last high-lighted sentence holds the key point
about resource occupancy that is, for some reason, not explicity made clear
above...see below now.
> 
> Merging is also present in rmp and mp2mp Ethernet VCs. With the right 
> OAM design there is nothing wrong with those merging cases.
> 
> connections.

NH=> This is not correct.  There is no such animal as a mp2p
*connection*....you can create a *merging construct* in the co-ps mode but
is NOT a connection.  And note this point carefully:  If a merging construct
was such a great/universal idea try creating such a beast end-end between
trail termination points of 2 (or more) real traffic stream sources in the
co-cs mode sometime and see what happens at the common sink (see the Note
below)...well we are trying to make everything look alike aren't we ;-)   A
connection MUST only have a single source.  

> Those mp2p EPS sublayer connections are solely used to improve 
> scalability of the switching tables in the P nodes of PBB-TE.

NH=> It is NOT the connections it is the fact one is using shared forwarding
entries.  The actual BW of *each* different connection must still be
accounted for independently....that is the key point.

Note - In the co-cs mode it is the *regular position/duration time-slices*
that both provide the (forwarding) label AND explicitly tell us that we are
allocating BW resource.  It is a physical impossibility for 2 such co-cs
mode connections to have resource occupying the same space/time position,
and that is why you cannot merge in the co-cs mode...it is quite different
to the co-ps mode in this respect.

regards, Neil

> All monitoring is done on the basis of the p2p ESP connections carried 
> by those merging mp2p connections.

> 
> In general mp2p connections have their application space, and can be 
> well maintained with OAM that is designed to operate in a mp2p 
> connection (e.g.
> Y.1731 like OAM).
> 
> In MPLS(-TP) it is possible to use such mp2p (merging) LSPs in e.g. 
> the following scenario:
> - assume that there are N PE nodes, which are interconnected by means 
> of a full mesh of p2p edge-to-edge LSPs.
> - each edge-to-edge LSP is mapped into a mp2p edge-to-edge-tunnel LSP 
> (N-1 input ports, 1 output port)
> - each p2p edge-to-edge LSP packet gets a label stack entry header in 
> which the lable field has a value that is unique within the mp2p 
> (encoding N NNI
> - each mp2p edge-to-edge-tunnel (e2et) LSP packet gets a label stack 
> entry header in which the label field has a value that distinguishes 
> this e2et LSP from any of the other e2et LSPs
> - the P nodes in between the N PE nodes forward on the basis of the 
> e2et LSP label value
> - the receiving PE is able to uniquely identify each p2p edge-to-edge 
> LSP packet by means and forward those packets on this basis
> - the mp2p e2et LSP connection under normal cases can not monitor for 
> packet loss; but this is not an issue, as packet loss can be monitored 
> in the p2p edge-to-edge LSP connections. If monitoring would be a 
> must, then the output port MEP must support N-1 packet loss counters 
> (i.e. one per p2p ME) and the packet loss counting is using the MSB 
> bits of the edge-to-edge LSP label as identifier (i.e. all packets 
> causes merging too because it only forwards on the (unswapped) DA 
> label + VID label....which can be the same for 2 different connections 
> from sources A and B say travelling towards the same sink Z.  This is 
> completely missing the point however.
> 	 
> All networks (any mode) create "merging" if you think about it as 
> traffic from N different sources makes its way towards some common 
> sink X say.  The critical issue however is that of resource 
> reservation AND whether one can distinguish the correct source at the 
> sink.  The LDP form of MPLS takes no account of either of these 
> points.  Moreover, the lost source information can only be recovered 
> in a higher layer client....be this from the absolute SA label in a 
> cl-ps client like IP (or in principle Ethernet) or an added label (the 
> PW label) which proxies for the lost SA information for a non-cl-ps 
> mode client.
> 	 
> So the issue is not the common forwarding labels but preservation of 
> source information and the fact that *each* connection must have its 
> resource requirements OK'd before it can be placed.
> 	 
> 	regards, Neil
> 
> 
Bocci, 
> Matthew (Matthew)
merging or 
> elaborate on what merging is.
> 
only 
> when/if a failure has occurred.
> 
used, the 
> other (primary) LSP is down, so in that case, I'm not sure we can 
> still call it merging.
> 
> 		 
> 
that is 
> clear in the frame work document.
> 
plane 
> level, and if yes, then how
>

---

From: [email-masked]
Date: Wed, 3 Feb 2010 18:26:47 -0500

All,

I agree with Neil, we need to be very careful with terminology.

We should define a connection as a communication between one source and 
one sink.

Shared forwarding is a case where two or more communication share the same 
resources and forwarding label e.g. PBB-TE or MPLS with label merge

If we use shared forwarding then merging occurs when the traffic unit 
(packet/data frame) does not contain sufficient information to identify 
the source. e.g. MPLS with LDP; PBB-TE does not merge since each traffic 
unit includes the SA.
Note: Merging is not possible on a circuit switched communication - by 
definition the resources cannot be shared.

Regards,

Malcolm

[email-masked] wrote on 03/02/2010 09:22:56 AM:

> There is one point in here I take a strong exception to...please 
seein-line: 
> NH=> Oh yes indeed!  This last high-lighted sentence holds the key 
> point about resource occupancy that is, for some reason, not 
> explicity made clear above...see below now.
> > 
> *connection*....you can create a *merging construct* in the co-ps 
> mode but is NOT a connection.  And note this point carefully:  If a 
> merging construct was such a great/universal idea try creating such 
> a beast end-end between trail termination points of 2 (or more) real
> traffic stream sources in the co-cs mode sometime and see what 
> happens at the common sink (see the Note below)...well we are trying
> to make everything look alike aren't we ;-)   A connection MUST only
> have a single source. 
> 
> Note - In the co-cs mode it is the *regular position/duration time-
> slices* that both provide the (forwarding) label AND explicitly tell
> us that we are allocating BW resource.  It is a physical 
> impossibility for 2 such co-cs mode connections to have resource 
> occupying the same space/time position, and that is why you cannot 
> merge in the co-cs mode...it is quite different to the co-ps mode in
> this respect.
> 
> regards, Neil
>

---

From: <[email-masked]>
Date: Sun, 7 Feb 2010 11:03:48 -0000

Maarten,

Resource management is not a new topic...I have been mentioning its importance for a long time as you really should know.  But before we go any further on this one let me ask you 2 questions:

1	Why do mp2p constructs never appear in any co-cs mode network as end-end traffic entities?  Hint:  It will help if you go through the logic of how the co-cs mode works wrt labelling and its resource management (at all geographic scales).

2	Why, in the co-ps mode case, does MPLS-TP not allow mp2p constructs when there is so much practical experience of mp2p constructs in LDP?  (I assume you understand how LDP works sufficiently well to complete this exercise).

If you are not able to figure this out then I'll provide a follow-up mail that spells out why we do not want mp2p constructs in a co-ps mode network when it is providing a transport service to different client layer instances.

regards, Neil  

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 03 February 2010 15:19
> To: Harrison,N,Neil,DKQ7 R; [email-masked]
> > forwarding entries.  The actual BW of *each* different 
> connection must 
> > still be accounted for independently....that is the key point.
> 
> Now you touch upon a new topic... i.e. the administration of 
> BW... As far as I know there are two alternatives for such 
> administration:
> 1) divide the resource BW (i.e. of the phy media) into 
> smaller pieces and allocate one piece to each transport path 
> layer transport path (i.e.
> edge-to-edge LSP); in my terminology each VP connection get a 
> BW. Then allocate a piece of each VP's BW to a transport 
> service layer transport path (e.g. ms-pw, service-lsp).
> 
> 2) don't fragment the resource BW into pieces per transport 
> path layer transport path; i.e. edge-to-edge LSPs have 
> unspecified BW, they just are used as a scalable forwarding 
> entity in a domain. Then allocate a piece of each resource BW 
> to a transport service layer transport path (e.g. to a ms-pw 
> or service-lsp).
> 
> In alternative 1, each connection (edge-to-edge lsp, ms-pw, 
> service-lsp) have a reserved BW.
> 
> connections) have a reserved BW; the transport path layer 
> transport paths (VP connections) have unspecified BW. Their 
> BW is the sum of transport service layer transport path BWs.
> 
> Alternative 2 has a better performance, as it prevents 
> fragmentation of the resource BW.
> 
> As such, "BW" is a parameter of a "connection", and this BW 
> parameter can have different values: e.g. an allocated fixed 
> bandwidth, a reserved fixed bandwidth, a reserved fixed plus 
> a variable bandwidth, an unspecified bandwidth (i.e. just the 
> sum of client BWs).
> 
> With this BW <=> connection relationship it should be clear 
> to you that a mp2p connection is a connection; its BW can be 
> unspecified (i.e. sum of its client BWs).
> 
> Regards,
> Maarten
> 
> NH=> Oh yes indeed!  This last high-lighted sentence holds 
> the key point about resource occupancy that is, for some 
> reason, not explicity made clear above...see below now.
> > 
> the right 
> *connection*....you can create a *merging construct* in the 
> co-ps mode but is NOT a connection.  And note this point 
> carefully:  If a merging construct was such a great/universal 
> idea try creating such a beast end-end between trail 
> termination points of 2 (or more) real traffic stream sources 
> in the co-cs mode sometime and see what happens at the common 
> sink (see the Note
> NH=> It is NOT the connections it is the fact one is using 
> shared forwarding entries.  The actual BW of *each* different 
> connection must still be accounted for independently....that 
> is the key point.
> 
> Note - In the co-cs mode it is the *regular position/duration 
> time-slices* that both provide the (forwarding) label AND 
> explicitly tell us that we are allocating BW resource.  It is 
> a physical impossibility for 2 such co-cs mode connections to 
> have resource occupying the same space/time position, and 
> that is why you cannot merge in the co-cs mode...it is quite 
> different to the co-ps mode in this respect.
> 
> regards, Neil
> 
> header in 
> label stack 
> edge-to-edge 
> connectivity and 
> monitor for 
> that PBB-TE 
> preservation of 
> at the data