Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

From: "Pandian, Vijay" <[email-masked]>
Date: Mon, 5 Mar 2007 14:07:07 -0500

Hi,
 
I have some basic questions, primarily trying to understand the scope of this ID as well as the application behind such a requirement.
 
1. Does this ID address just an asymmetric Bandwidth requirement?
2. How about other attributes? in particular LSP Protection & Recovery (P&R) related attributes?
3. If P&R are indeed different, doesn't it make sense to route them separately (separate CSPF calculation at each end) and eventually signal them independently as well?
4. Is there a need for the forward and reverse flows to be on the same path?
5. What is "fate sharing"? I couldn't find this in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?
 
Regards,
 
Vijay

---

From: "Don Fedyk" <[email-masked]>
Date: Mon, 5 Mar 2007 18:41:24 -0500

Hi Vijay

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pandian, Vijay
	Sent: Monday, March 05, 2007 2:07 PM
	To: [email-masked]
	Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

	Hi,
	 
	I have some basic questions, primarily trying to understand the
scope of this ID as well as the application behind such a requirement.
	 
	1. Does this ID address just an asymmetric Bandwidth
requirement? 

The postulation was that GMPLS today supports bi-directional service
with a single RSVP-TE session creating a bidirectional LSP.  The most
common implementation of this is Optical TDM networks.  Since this was
the starting point, the ID postulates setting up an asymmetric service
with a single asymmetric LSP.  (Like many new drafts it sets a
requirement and postulates a an implementation.)  
 
So to your question besides bandwidth there is also underlying
requirement to align with GMPLS single session procedures and support a
bi-directional packet data plane as Ethernet does today.  A single
bidirectional (in this case asymmetric BW capable) LSP.  In other words
a single RSVP-TE session.  Several people have pointed out this is also
achievable with two unidirectional RSVP-TE sessions (one at each end).
Rather than reopen that debate on this thread I will acknowledge the
authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)
 
|  2. How about other attributes? in particular LSP Protection &
Recovery (P&R) related attributes? 
 
With respect to GMPLS, the plan was to allow bi-directional Protection
or Recovery LSPs controlled by separate RSVP-TE sessions in separate
from the single RSVP-TE session associated with the primary
bidirectional LSP.   

	3. If P&R are indeed different, doesn't it make sense to route
them separately (separate CSPF calculation at each end) and eventually
signal them independently as well? 

Hopefully I addressed part of this already. Recovery of the
bi-directional LSP could be handled by another RSVP-TE session & LSP.
The data plane in our case must have a bi-directional symmetric path so
you can only do a CSPF at one end and/or force the paths to align. 

	4. Is there a need for the forward and reverse flows to be on
the same path? 

That is the way an Ethernet data plane works, and in my case this is
where the requirement comes from. There is Ethernet data plane OAM and
in some cases Ethernet forwarding rules that both require bi-directional
symmetric paths.  The requirement is to be able to support native
Ethernet loopback and data plane trace functions and bi-directional
symmetry in the data plane is required. 

	5. What is "fate sharing"? I couldn't find this in other RFCs or
IDs. Is it same as link/node/SRLG disjoint paths? 

Yes it is related.  A shared resource link group identifies shared
resources at some granularity. Fate shared paths have shared resources
at a very high level of granularity.  Disjoint paths have none or very
few shared resources.  For a bidirectional path the shared fate comes
from the fact that both direction have common resources and if one fails
the other is likely to fail.    
 
Regards,
Don 

	Regards,
	 
	Vijay

---

From: "Pandian, Vijay" <[email-masked]>
Date: Mon, 5 Mar 2007 19:36:23 -0500

Don,
 
The question I had regarding P&R was trying to figure out if one direction required a better P&R (say 1+1) and the reverse direction probably required some basic P&R (say Re-routing).
 
So the requirement is to use the same "physical link" for the forward and reverse direction. Am I right?
 
Regards,
 
Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: [email-masked]
Subject: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi,

The postulation was that GMPLS today supports bi-directional service with a single RSVP-TE session creating a bidirectional LSP.  The most common implementation of this is Optical TDM networks.  Since this was the starting point, the ID postulates setting up an asymmetric service with a single asymmetric LSP.  (Like many new drafts it sets a requirement and postulates a an implementation.)  
 
So to your question besides bandwidth there is also underlying requirement to align with GMPLS single session procedures and support a bi-directional packet data plane as Ethernet does today.  A single bidirectional (in this case asymmetric BW capable) LSP.  In other words a single RSVP-TE session.  Several people have pointed out this is also achievable with two unidirectional RSVP-TE sessions (one at each end).  Rather than reopen that debate on this thread I will acknowledge the authors had a single session in mind more as a requirement of the technology.  Ethernet data forwarding is bi-directional symmetric and there are efficiencies in a single session of a bi-directional LSP.  On the other hand the issue is there is currently no way to specify the asymmetric BW. If you want to discuss the pros and cons of multiple sessions versus single there is already a thread on this (RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt)
 
|  2. How about other attributes? in particular LSP Protection & Recovery (P&R) related attributes? 
 
With respect to GMPLS, the plan was to allow bi-directional Protection or Recovery LSPs controlled by separate RSVP-TE sessions in separate from the single RSVP-TE session associated with the primary bidirectional LSP.   

Hopefully I addressed part of this already. Recovery of the bi-directional LSP could be handled by another RSVP-TE session & LSP.  The data plane in our case must have a bi-directional symmetric path so you can only do a CSPF at one end and/or force the paths to align. 

That is the way an Ethernet data plane works, and in my case this is where the requirement comes from. There is Ethernet data plane OAM and in some cases Ethernet forwarding rules that both require bi-directional symmetric paths.  The requirement is to be able to support native Ethernet loopback and data plane trace functions and bi-directional symmetry in the data plane is required. 

Yes it is related.  A shared resource link group identifies shared resources at some granularity. Fate shared paths have shared resources at a very high level of granularity.  Disjoint paths have none or very few shared resources.  For a bidirectional path the shared fate comes from the fact that both direction have common resources and if one fails the other is likely to fail.    
 
Regards,
Don 

Regards,
 
Vijay

---

From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
Date: Tue, 6 Mar 2007 11:34:53 +0100

Hi Vijay,
 
let me answer this. 
 
If you need different protection for each direction then you likely will
need differently routed LSPs. In this case one better uses separate
sessions for the two directions since all the benefits of having a
single session (like fate sharing) is gone if the LSPs take different
routes. The ID only proposes to relax the symmetrical bandwidth property
of the bidirectional LSP establishment given in RFC3471.
 
Regards,
Attila

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

	Don,
	 
	The question I had regarding P&R was trying to figure out if one
direction required a better P&R (say 1+1) and the reverse direction
probably required some basic P&R (say Re-routing).
	 
	So the requirement is to use the same "physical link" for the
forward and reverse direction. Am I right?
	 
	Regards,
	 
	Vijay

		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt

		Hi Vijay

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pandian, Vijay
			Sent: Monday, March 05, 2007 2:07 PM
			To: [email-masked]
			Subject: Questions on
draft-takacs-asym-bw-lsp-00.txt

			Hi,
			 
			I have some basic questions, primarily trying to
understand the scope of this ID as well as the application behind such a
requirement.
			 
			1. Does this ID address just an asymmetric
Bandwidth requirement? 

		The postulation was that GMPLS today supports
bi-directional service with a single RSVP-TE session creating a
bidirectional LSP.  The most common implementation of this is Optical
TDM networks.  Since this was the starting point, the ID postulates
setting up an asymmetric service with a single asymmetric LSP.  (Like
many new drafts it sets a requirement and postulates a an
implementation.)  
		 
		So to your question besides bandwidth there is also
underlying requirement to align with GMPLS single session procedures and
support a bi-directional packet data plane as Ethernet does today.  A
single bidirectional (in this case asymmetric BW capable) LSP.  In other
words a single RSVP-TE session.  Several people have pointed out this is
also achievable with two unidirectional RSVP-TE sessions (one at each
end).  Rather than reopen that debate on this thread I will acknowledge
the authors had a single session in mind more as a requirement of the
technology.  Ethernet data forwarding is bi-directional symmetric and
there are efficiencies in a single session of a bi-directional LSP.  On
the other hand the issue is there is currently no way to specify the
asymmetric BW. If you want to discuss the pros and cons of multiple
sessions versus single there is already a thread on this (RE: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt)
		 
		|  2. How about other attributes? in particular LSP
Protection & Recovery (P&R) related attributes? 
		 
		With respect to GMPLS, the plan was to allow
bi-directional Protection or Recovery LSPs controlled by separate
RSVP-TE sessions in separate from the single RSVP-TE session associated
with the primary bidirectional LSP.   

			3. If P&R are indeed different, doesn't it make
sense to route them separately (separate CSPF calculation at each end)
and eventually signal them independently as well? 

		Hopefully I addressed part of this already. Recovery of
the bi-directional LSP could be handled by another RSVP-TE session &
LSP.  The data plane in our case must have a bi-directional symmetric
path so you can only do a CSPF at one end and/or force the paths to
align. 

			4. Is there a need for the forward and reverse
flows to be on the same path? 

		That is the way an Ethernet data plane works, and in my
case this is where the requirement comes from. There is Ethernet data
plane OAM and in some cases Ethernet forwarding rules that both require
bi-directional symmetric paths.  The requirement is to be able to
support native Ethernet loopback and data plane trace functions and
bi-directional symmetry in the data plane is required. 

			5. What is "fate sharing"? I couldn't find this
in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths? 

		Yes it is related.  A shared resource link group
identifies shared resources at some granularity. Fate shared paths have
shared resources at a very high level of granularity.  Disjoint paths
have none or very few shared resources.  For a bidirectional path the
shared fate comes from the fact that both direction have common
resources and if one fails the other is likely to fail.    
		 
		Regards,
		Don 

			Regards,
			 
			Vijay

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Mar 2007 11:05:20 -0000

Hi,

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?

- Is this a protection feature where the switch-over of one
  direction to its backup path must be accompanied by a
  switch-over of the other direction, too?

- Is this a control plane feature where the removal of control
  plane state in one direction must cause the removal of control
  plane state in the other direction?

The use of a single control plane state (bidirectional signaling) obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

The use of an identical path for both directions can provide some elements 
of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue is 
not impacted by bidirectional or associated signaling as the directions can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and seem 
to be beyond this debate.

So I am wondering what relevance fate-sharing has to the discussion of 
asymmetrical bandwidth. Maybe the discussion has reduced to:
- We need asymmetrical bidirectional services
- Does the value of a single signaling exchange outweigh the
   cost of new signaling objects and procedures?

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 06, 2007 10:34 AM
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this.

Regards,
Attila

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on

Hi Vijay

Hi,

Regards,
Don

Regards,

Vijay

---

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Tue, 6 Mar 2007 12:29:39 +0100

Guys,

         let me try to summarize what we have said so far:

1         The basic idea behind the ID is based on some facts (I hope we all agree that are facts :-));

1.1      Ethernet services are (likely) bidirectional with asymmetric bandwidth;

1.2      GMPLS now allows to set-up bi-directional LSP with symmetrical bandwidth;

1.3      If, with the existing protocols, there is the need to set-up a bi-directional service with asymmetric bandwidth requirement (e.g. IpTv) and with upstream and downstream path that follow the same route we have to signal two different LSPs using the RRO of the first one as strict ERO for the second one.  If we also want to bind the two LSPs in order to identify them as part of the same service we can use the ASSOCIATON obj (modified I suppose)

1.4      Likely (I would say very likely) the NMS that requests the LSP(s) set-up knows in advance the bandwidth needed in the two directions.  So we are in a different situation w.r.t. the original RSVP situation.  We have all the information we need to set-up the LSP at the Path processing

Now if all of we are happy with point 1.3 then we have finished.  If someone think that is better to have the possibility to set-up and identify a bidirectional service with a single LSP then the ID have reason to exists at least for discussion :-).

IMHO having the possibility to set-up the LSP at the path processing speed up the service establishment and this is particularly useful in case of LSP rerouting in case of failure.  In fact if the service is made of the two LSP what could happens is the first one can be set-up and the second one fails during signaling this means that first one have to be deleted and two LSP path recomputed and re-signaled.  

Best Regards

Diego  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs (IJ/ETH)
Sent: martedì 6 marzo 2007 11.35
To: Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay,

let me answer this. 

If you need different protection for each direction then you likely will need differently routed LSPs. In this case one better uses separate sessions for the two directions since all the benefits of having a single session (like fate sharing) is gone if the LSPs take different routes. The ID only proposes to relax the symmetrical bandwidth property of the bidirectional LSP establishment given in RFC3471.

Regards,

Attila

	Don,

	Regards,

	Vijay

		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

		Hi Vijay

			Hi,

		Regards,

		Don 

			Regards,

			Vijay

---

From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
Date: Tue, 6 Mar 2007 12:35:00 +0100

Hi Adrian,

Please see inline.
Regards,
Attila 

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 12:05 PM
> To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
> Cc: [email-masked]
> Subject: What is this fate sharing thing? [Was: Questions on 
> draft-takacs-asym-bw-lsp-00.txt]
> 
> Hi,
> 
> There has been a lot of discussion about "fate-sharing" and I 
> am not sure what problem we are trying to solve.
> 
> The use of a single control plane state (bidirectional 
> signaling) obviously makes control plane fate-sharing 
> automatic, but the use of associated signaling does not 
> preclude control plane fate sharing - it just needs 

Control plane fate sharing was mentioned as one benefit when having a
single session. In this case additional message exchanges are not needed
and there are no additional delays which otherwise would be an issue
with restoration.

> 
> The use of an identical path for both directions can provide 
> some elements of data plane fate sharing, but it is important 
> to note that it does not guarantee it. For example, a 
> unidirectional fiber could fail. This issue is not impacted 
> by bidirectional or associated signaling as the directions 
> can be installed on the path by associated signaling, and as 
> a failure might only impact one direction in bidirectional signaling.
> 
Agreed, the data plane aspects are technology specific.

> End-to-end protection features are implemented at a different 
> level and seem to be beyond this debate.
> 
> 

Another point is on application scenarios. As Dimitri pointed out in his
early mails, if a general extension to support asymmetric bandwidth is
going to be specified its complexity might outweigh its benefits.
However, given a focused scenario with single sided control and full
bandwidth knowledge at the ingress, the simple extensions given in the
ID might be appropriate. The question on this would be whether the
proposed extension with this scope is worth the effort.

---

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Tue, 6 Mar 2007 12:45:04 +0100

Hi Adrian,
          Some comments in line

Best Regards

Diego

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: martedì 6 marzo 2007 12.05
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]

Hi,

There has been a lot of discussion about "fate-sharing" and I am not sure 
what problem we are trying to solve.
[dc] As usual you and Vijay, make a point :-) I also think we need to clarify what is fate sharing.

- Is this a data plane feature where a data plane fault in one
  direction must cause data plane interruption in both directions?
[dc] I think here you are talking about the so called ALS (Automatic Laser Shutdown) there should b some ITU-T recc about this.  I sorry I forgot the number.

The use of an identical path for both directions can provide some elements 
of data plane fate sharing, but it is important to note that it does not 
guarantee it. 
[dc] Yes my understanding of the fate sharing is that upstream and downstream LSP must follow the same path. 

For example, a unidirectional fiber could fail. This issue is 
not impacted by bidirectional or associated signaling as the directions can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.
[dc] Here is where ALS should come in the field.  If the fibre is broken in one direction the ALS should shutdown the laser associated to the other direction.  
 
 -------X----->
A              B  
 <------------S
That is X is a failure (LOL), as soon B detects the loss of light due to the ALS is shutdown the laser (S in the picture) towards A

[dc] I've tried to make a summary of the point discussed so far in an another mail

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" 
<[email-masked]>
Cc: <[email-masked]>

Hi Vijay,

let me answer this.

Regards,
Attila

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on

Hi Vijay

Hi,

Regards,
Don

Regards,

Vijay

---

From: "Pandian, Vijay" <[email-masked]>
Date: Tue, 6 Mar 2007 09:35:38 -0500

Hi Diego,
 
Even for point 1.3, it is not clear why the two directions of this LSP needs to be on the same (physical?) path. I may not understand the IpTv application, but isn't it true that the direction where you need a small bandwidth probably is used to send control messages such as "channel change" etc... In that case, doesn't it make sense to use a completely different path with a different QoS for a efficient network resource utilization?
 
Assuming that we end up treating each direction as independent sessions, can we use the  GMPLS-CALL ID to correlate the two connections? I assume the intermediate nodes don't care about such an "ASSOCIATEION".
 
Regards,
 
Vijay

-----Original Message-----
From: Diego Caviglia (GA/ERI) [mailto:[email-masked]]
Sent: Tuesday, March 06, 2007 6:30 AM
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Guys,

Best Regards

Diego  

  _____  

Hi Vijay,

let me answer this. 

Regards,

Attila

  _____  

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Vijay

  _____  

Hi,

Regards,

Don 

Regards,

Vijay

---

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Tue, 6 Mar 2007 15:41:00 +0100

Hi Vijay,

               Please see in line.

Best regards

Diego

From: Pandian, Vijay [mailto:[email-masked]] 
Sent: martedì 6 marzo 2007 15.36
To: Diego Caviglia (GA/ERI); Attila Takacs (IJ/ETH); Don Fedyk
Cc: [email-masked]
Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

Hi Diego,

Even for point 1.3, it is not clear why the two directions of this LSP needs to be on the same (physical?) path.

[dc] I not saying that they must be on or need to be on the same path in order to work.  I'm saying if there is a requirement to have upstream and downstream on the same path then....

 I may not understand the IpTv application, but isn't it true that the direction where you need a small bandwidth probably is used to send control messages such as "channel change" etc... In that case, doesn't it make sense to use a completely different path with a different QoS for a efficient network resource utilization?

[dc] Yes 

Regards,

Vijay

	-----Original Message-----
	From: Diego Caviglia (GA/ERI) [mailto:[email-masked]]
	Sent: Tuesday, March 06, 2007 6:30 AM
	To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
	Cc: [email-masked]
	Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

	Guys,

	1.       1         The basic idea behind the ID is based on some facts (I hope we all agree that are facts :-));

	2.      1.1      Ethernet services are (likely) bidirectional with asymmetric bandwidth;

	3.      1.2      GMPLS now allows to set-up bi-directional LSP with symmetrical bandwidth;

	4.      1.3      If, with the existing protocols, there is the need to set-up a bi-directional service with asymmetric bandwidth requirement (e.g. IpTv) and with upstream and downstream path that follow the same route we have to signal two different LSPs using the RRO of the first one as strict ERO for the second one.  If we also want to bind the two LSPs in order to identify them as part of the same service we can use the ASSOCIATON obj (modified I suppose)

	5.      1.4      Likely (I would say very likely) the NMS that requests the LSP(s) set-up knows in advance the bandwidth needed in the two directions.  So we are in a different situation w.r.t. the original RSVP situation.  We have all the information we need to set-up the LSP at the Path processing

	6.                  Now if all of we are happy with point 1.3 then we have finished.  If someone think that is better to have the possibility to set-up and identify a bidirectional service with a single LSP then the ID have reason to exists at least for discussion :-).

	7.                  IMHO having the possibility to set-up the LSP at the path processing speed up the service establishment and this is particularly useful in case of LSP rerouting in case of failure.  In fact if the service is made of the two LSP what could happens is the first one can be set-up and the second one fails during signaling this means that first one have to be deleted and two LSP path recomputed and re-signaled.  

	8.                  Best Regards

	9.                    

	10.              Diego  

	11.                

	Hi Vijay,

	let me answer this. 

	Regards,

	Attila

		Don,

		Regards,

		Vijay

			-----Original Message-----
			From: Don Fedyk [mailto:[email-masked]]
			Sent: Monday, March 05, 2007 6:41 PM
			To: Pandian, Vijay; [email-masked]
			Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt

			Hi Vijay

				Hi,

			Regards,

			Don 

				Regards,

				Vijay

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 6 Mar 2007 07:51:53 -0800 (PST)

Adrian,

I would define "fate sharing" very simply: it is the situation when both directions go through the same links at any time: after setup, protection switchover, recovery, reroute, etc. In control plane the bidirectional service where opposite directions fate-share we have some nice by-products:
a) CP states for both directions could be always combined together with the summary state reduced in size;
b) the management of both directions can be accomplished using a single exchange of signaling messages, This holds for initial setup, protection switchover, recovery, re-route
c) number of RSVP refreshes also is half as much

My understanding is that we do like the notion of a symmetrical bidirectional LSP in a packet switched network layer.  This is a (I'd say big) reason why we want to migrate from MPLS to GMPLS, and you. Adrian, I believe is still a big advocate of such migration. So, we don't mind an extra complexity (such as UPSTREAM LABEL, UPSTREAM ACCEPTABLE LABEL SET).

I have just one question to the authors of the draft: do we have a strong use case for a bidirectional service requiring the fate sharing (as I defined it above) of both directions and fully symmetrical (recovery requirements, colors, etc) apart from the bandwidth requirements? If the answer is yes, than I say I don't mind a copule of extra signaling objects.

Igor

Adrian Farrel <[email-masked]> wrote: Hi,

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" 
To: "Pandian, Vijay" ; "Don Fedyk" 

Cc: 

Hi Vijay,

let me answer this.

Regards,
Attila

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on

Hi Vijay

Hi,

Regards,
Don

Regards,

Vijay

---------------------------------
Don't get soaked.  Take a quick peak at the forecast 
 with theYahoo! Search weather shortcut.

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 6 Mar 2007 10:55:28 -0500

Hi Adrian

In an Ethernet bridging context I'll try to add what I know. 

> -----Original Message----- From: Adrian Farrel
> [mailto:[email-masked]] Sent: Tuesday, March 06, 2007
> 6:05 AM To: Attila Takacs (IJ/ETH); Pandian, Vijay; Fedyk,
> Don (BL60:1A00) Cc: [email-masked] Subject: What is
> this fate sharing thing? [Was: Questions on
> There has been a lot of discussion about "fate-sharing"
> and I am not sure what problem we are trying to solve.
> 
> - Is this a data plane feature where a data plane fault in
> one direction must cause data plane interruption in both
> directions?
[DF]When we say data plane I suppose it depends on the Physical
layer as well. I'm not much of an expert on physical layers
but I believe we went over much of this in the GMPLS control
of optical. 

For Ethernet bridging, if there is a fault detected in one direction
the OAM signals the fault and at a minimum an alarm is
raised. I don't believe there is an immediate attempt to
interupt data but one result may be to use the indication or
activate protection or restoration mechanisms. 
In Ethernet bridging the Bridge Relay is a bi-drectional functions 
that is attached to two ports. (below the ports there may be 
unidirectional links). 
 
> 
> - Is this a protection feature where the switch-over of
> one direction to its backup path must be accompanied by a
[DF]In Ethernet this is the case. Unidirectional Ethernet would
not support many Ethernet features. 

> 
> - Is this a control plane feature where the removal of
> control plane state in one direction must cause the
> removal of control plane state in the other direction?
[DF]I don't know if I can parse this. "removal of control plane
state in one direction in a bidirectional LSP?" I think you
may be refering to the case where two RSVP-TE sessions
control a single bi-directional path.  The point is the data
plane should not be unidirectionally active since this would
create issues with OAM functions that assume a bidirectional
data plane.  
> additional message exchanges.
[DF]True but in the case of associated case there is also a
concept of a master and slave relationship between the
associated signaling paths for any given action. This
requires new capability as well.
> 
> The use of an identical path for both directions can
> provide some elements of data plane fate sharing, but it
> is important to note that it does not guarantee it. For
> example, a unidirectional fiber could fail.  This issue is
> not impacted by bidirectional or associated signaling as
> the directions can be installed on the path by associated
> signaling, and as a failure might only impact one
> direction in bidirectional signaling.
[DF]The bi-directional aspects are at the L2 Ethernet bridge level.
Unidirectional faults are detected as loss of Connectivity
check messages or the like and declared the ethernet LSP in
fault. What action is taken depends on the choice of
configuration and control plane.

> level and seem to be beyond this debate.

[DF]There could be an association object to implement some
aspects of co-ordination between a primary and a backup LSP.
> 
> 
> So I am wondering what relevance fate-sharing has to the
> discussion of asymmetrical bandwidth. Maybe the discussion
> has reduced to:
> - Does the value of a single signaling exchange
> outweigh the cost of new signaling objects and procedures?
[DF]The fate sharing aspect is related to the Ethernet
bi-directionality.  We need bi-directional Ethernet LSPs 
with (symmetric or asymmetric BW). This requirement is stronger 
than your first point.

Perhaps Fate sharing is not the right or the best term.  My
understanding of Ethernet is a typically a Spanning tree
creates the bi-directional Ethernet paths that have these
properties. You can also configure static Ethernet paths
that have the same properties. 

Regards,
Don 

> Adrian
<snip>

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 6 Mar 2007 12:37:14 -0500

Hi Igor
 
Good points.  Comments in line.

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: Tuesday, March 06, 2007 10:52 AM

	Adrian,
	
	I would define "fate sharing" very simply: it is the situation
when both directions go through the same links at any time: after setup,
protection switchover, recovery, reroute, etc. In control plane the
bidirectional service where opposite directions fate-share we have some
nice by-products: 

In Ethernet Bridging the "fate sharing" object is the to the level of
ports on the bridge relay.  Both direction of the path must pass through
the Bridge relay. There may be link aggregation functions below this. So
I would adjust your definition slightly to include same "link objects".

	 
	a) CP states for both directions could be always combined
together with the summary state reduced in size;
	b) the management of both directions can be accomplished using a
single exchange of signaling messages, This holds for initial setup,
protection switchover, recovery, re-route
	c) number of RSVP refreshes also is half as much
	
	My understanding is that we do like the notion of a symmetrical
bidirectional LSP in a packet switched network layer.  This is a (I'd
say big) reason why we want to migrate from MPLS to GMPLS, and you.
Adrian, I believe is still a big advocate of such migration. So, we
don't mind an extra complexity (such as UPSTREAM LABEL, UPSTREAM
ACCEPTABLE LABEL SET).
	
	I have just one question to the authors of the draft: do we have
a strong use case for a bidirectional service requiring the fate sharing
(as I defined it above) of both directions and fully symmetrical
(recovery requirements, colors, etc) apart from the bandwidth
requirements? If the answer is yes, than I say I don't mind a copule of
extra signaling objects. 

We have a draft for GMPLS control of Ethernet PBB-TE which is an
emerging L2 data plane.  The Ethernet bridge relay function assumes
bi-directionality. Ethernet data plane OAM is built on the
bi-directional relay.   IMHO in that context the answer to your question
is yes.    
 
In fact I think the requirement for asymmetrical BW is just related to
the fact we have a packet technology. (MPLS is no different). 
The need for bi-directional fate sharing is from the requirements of the
Ethernet Bridging Relay and our desire to leverage the Relay
capabilities (this packet layer is different).  
The use case cited for this requirement is the distribution of packet
Video which may well be high BW in one direction and relatively small in
the other but even my Internet connection is asymmetric today and I
don't use it for video. So the use case applies to all kinds of of
packet transport. 
 
Regards,
Don 

	Igor

	Adrian Farrel <[email-masked]> wrote:

		Hi,
		
and I am not sure 
		
		- Is this a data plane feature where a data plane fault
in one
		direction must cause data plane interruption in both
directions?
		
one
		
		- Is this a control plane feature where the removal of
control
		plane state in one direction must cause the removal of
control
		plane state in the other direction?
		
		The use of a single control plane state (bidirectional
signaling) obviously 
		makes control plane fate-sharing automatic, but the use
of associated 
		signaling does not preclude control plane fate sharing -
it just needs 
		additional message exchanges.
		
		The use of an identical path for both directions can
provide some elements 
		of data plane fate sharing, but it is important to note
that it does not 
		guarantee it. For example, a unidirectional fiber could
fail. This issue is 
		not impacted by bidirectional or associated signaling as
the directions can 
		be installed on the path by associated signaling, and as
a failure might 
		only impact one direction in bidirectional signaling.
		
		End-to-end protection features are implemented at a
different level and seem 
		to be beyond this debate.

		So I am wondering what relevance fate-sharing has to the
discussion of 
		asymmetrical bandwidth. Maybe the discussion has reduced
to:
		- We need asymmetrical bidirectional services
		- Does the value of a single signaling exchange outweigh
the
		cost of new signaling objects and procedures?
		
		Adrian
		
		----- Original Message ----- 
		
		Cc: 

		Hi Vijay,
		
		let me answer this.
		
		If you need different protection for each direction then
you likely will
		need differently routed LSPs. In this case one better
uses separate
		sessions for the two directions since all the benefits
of having a
		single session (like fate sharing) is gone if the LSPs
take different
		routes. The ID only proposes to relax the symmetrical
bandwidth property
		of the bidirectional LSP establishment given in RFC3471.
		
		Regards,
		Attila

[mailto:[email-masked]] On

		Don,
		
		The question I had regarding P&R was trying to figure
out if one
		direction required a better P&R (say 1+1) and the
reverse direction
		probably required some basic P&R (say Re-routing).
		
		So the requirement is to use the same "physical link"
for the
		forward and reverse direction. Am I right?
		
		Regards,
		
		Vijay

		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on
		draft-takacs-asym-bw-lsp-00.txt

		Hi Vijay

		From: [email-masked]
		[mailto:[email-masked]] On Behalf Of Pandian,
Vijay
		Sent: Monday, March 05, 2007 2:07 PM
		To: [email-masked]
		Subject: Questions on
		draft-takacs-asym-bw-lsp-00.txt

		Hi,
		
		I have some basic questions, primarily trying to
		understand the scope of this ID as well as the
application behind such a
		requirement.

		The postulation was that GMPLS today supports
		bi-directional service with a single RSVP-TE session
creating a
		bidirectional LSP. The most common implementation of
this is Optical
		TDM networks. Since this was the starting point, the ID
postulates
		setting up an asymmetric service with a single
asymmetric LSP. (Like
		many new drafts it sets a requirement and postulates a
an
		implementation.)
		
		So to your question besides bandwidth there is also
		underlying requirement to align with GMPLS single
session procedures and
		support a bi-directional packet data plane as Ethernet
does today. A
		single bidirectional (in this case asymmetric BW
capable) LSP. In other
		words a single RSVP-TE session. Several people have
pointed out this is
		also achievable with two unidirectional RSVP-TE sessions
(one at each
		end). Rather than reopen that debate on this thread I
will acknowledge
		the authors had a single session in mind more as a
requirement of the
		technology. Ethernet data forwarding is bi-directional
symmetric and
		there are efficiencies in a single session of a
bi-directional LSP. On
		the other hand the issue is there is currently no way to
specify the
		asymmetric BW. If you want to discuss the pros and cons
of multiple
		sessions versus single there is already a thread on this
(RE: I-D
		ACTION:draft-takacs-asym-bw-lsp-00.txt)

		With respect to GMPLS, the plan was to allow
		bi-directional Protection or Recovery LSPs controlled by
separate
		RSVP-TE sessions in separate from the single RSVP-TE
session associated
		with the primary bidirectional LSP.
		
		3. If P&R are indeed different, doesn't it make
		sense to route them separately (separate CSPF
calculation at each end)
		and eventually signal them independently as well?

		Hopefully I addressed part of this already. Recovery of
		the bi-directional LSP could be handled by another
RSVP-TE session &
		LSP. The data plane in our case must have a
bi-directional symmetric
		path so you can only do a CSPF at one end and/or force
the paths to
		align.

		That is the way an Ethernet data plane works, and in my
		case this is where the requirement comes from. There is
Ethernet data
		plane OAM and in some cases Ethernet forwarding rules
that both require
		bi-directional symmetric paths. The requirement is to be
able to
		support native Ethernet loopback and data plane trace
functions and
		bi-directional symmetry in the data plane is required.
		
		5. What is "fate sharing"? I couldn't find this
		in other RFCs or IDs. Is it same as link/node/SRLG
disjoint paths?

		Yes it is related. A shared resource link group
		identifies shared resources at some granularity. Fate
shared paths have
		shared resources at a very high level of granularity.
Disjoint paths
		have none or very few shared resources. For a
bidirectional path the
		shared fate comes from the fact that both direction have
common
		resources and if one fails the other is likely to fail.
		
		Regards,
		Don

		Regards,
		
		Vijay

	

	Don't get soaked. Take a quick peak at the forecast
<http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news> 
	with theYahoo! Search weather shortcut.
<http://tools.search.yahoo.com/shortcuts/?fr=oni_on_mail&#news>

---

From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
Date: Tue, 6 Mar 2007 20:48:13 +0100

Hi Igor,
 
I think the point is on flexibility. If bandwidth is available with fine
granularity one can leverage this in many cases. To add a new example:
central office - branch office connectivity, in this scenario it seems
to be likely to have the same recovery...etc requirements but different
bw needs for up/down streams.
 
Regarding "fate sharing", as you specified, it depends on how one
defines "a strong use case"...one may use diversely routed LSPs as well
to provide bidirectional connection for, e.g., the above service, but
with co routed LSPs issues may become simpler (like management, CP
states, OAM,...). 
 
Regards,
Attila

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: Tuesday, March 06, 2007 4:52 PM
	To: Adrian Farrel; Attila Takacs (IJ/ETH); Pandian, Vijay; Don
Fedyk
	Cc: [email-masked]
	Subject: Re: What is this fate sharing thing? [Was: Questions on
draft-takacs-asym-bw-lsp-00.txt]

	Adrian,

	
	
	Igor

		Hi,

		

		

		
		Adrian
		
		----- Original Message ----- 
		
		Cc: 

		Hi Vijay,
		
		let me answer this.

		Regards,
		Attila

		
		Don,

		
		Regards,
		
		Vijay

		-----Original Message-----
		From: Don Fedyk [mailto:[email-masked]]
		Sent: Monday, March 05, 2007 6:41 PM
		To: Pandian, Vijay; [email-masked]
		Subject: RE: Questions on
		draft-takacs-asym-bw-lsp-00.txt

		Hi Vijay

		Hi,

		

		

		

		
		Regards,
		Don

		Regards,
		
		Vijay

---

From: [email-masked]
Date: Tue, 6 Mar 2007 22:44:40 +0100

adrian, all

the point is not whether "We need asymmetrical bidirectional services"
but "Do we have a clear requirement for asymmetrical bidirectional LSPs?" 

when i look at some of the examples that have been cited, it would 
surprise me that we would provision an LSP per micro-flow across the 
network (being Ethernet or whatever packet technology), even more, GMPLS 
is mostly used as an edge-to-edge technology in most cases, GMPLS capable 
devices do not even interact with the sources of traffic some where 
mentioning in their examples

i am also reading that some Ethernet equipment are introducing several 
specific (data plane) constraints, indeed, but the control plane is not 
going to elevate those, in part. these constraints are independent whether 
one has unidirectional LSP, or asym bandwidth LSP provisioning capability 
at control plane level (adrian pointed this out numerous times but this is 
one of the cornerstone of the whole discussion)

hence, the point since so far, is that they are no convincing argument in 
favor of an asymmetric LSP bandwidth provisioning WITHIN a single 
signaling exchange, indeed, most arguments are boiling down to 
hypothetical control plane efficiency that can be ensured by other means 
if we consider the restricting conditions where the proposed approach 
would be workable 

-d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
06/03/2007 12:05
Please respond to "Adrian Farrel"
 
        To:     "Attila Takacs \(IJ/ETH\)" <[email-masked]>, 
"Pandian, Vijay" <[email-masked]>, "Don Fedyk" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        What is this fate sharing thing? [Was: Questions 
on draft-takacs-asym-bw-lsp-00.txt]

Hi,

The use of a single control plane state (bidirectional signaling) 
obviously 
makes control plane fate-sharing automatic, but the use of associated 
signaling does not preclude control plane fate sharing - it just needs 
additional message exchanges.

of data plane fate sharing, but it is important to note that it does not 
guarantee it. For example, a unidirectional fiber could fail. This issue 
is 
not impacted by bidirectional or associated signaling as the directions 
can 
be installed on the path by associated signaling, and as a failure might 
only impact one direction in bidirectional signaling.

End-to-end protection features are implemented at a different level and 
seem 
to be beyond this debate.

Adrian

----- Original Message ----- 
From: "Attila Takacs (IJ/ETH)" <[email-masked]>
To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk" 
<[email-masked]>
Cc: <[email-masked]>

Hi Vijay,

let me answer this.

Regards,
Attila

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on

Hi Vijay

Hi,

Regards,
Don

Regards,

Vijay

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 6 Mar 2007 14:24:06 -0800

Dimitri,

I think you're absolutely right.  Furthermore, this application seems to
be a natural for LSP hierarchy, where there would be a containing
symmetric bi-directional LSP with contained asymmetric uni-directional
LSPs.  The latter would be correlated with the Association object.

This would give you fate sharing and fast recovery via the
re-instantiation of the containing LSP, and reasonable control plane
performance, since the contained LSP signaling is only between the
containing LSP endpoints.

Thanks,

John 

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 1:45 PM
> To: Adrian Farrel
> Cc: Attila Takacs (IJ/ETH); [email-masked]; Don Fedyk; 
> [email-masked]; Pandian, Vijay
> Subject: Re: What is this fate sharing thing? [Was: Questions 
> when i look at some of the examples that have been cited, it 
> would surprise me that we would provision an LSP per 
> micro-flow across the network (being Ethernet or whatever 
> packet technology), even more, GMPLS is mostly used as an 
> edge-to-edge technology in most cases, GMPLS capable devices 
> do not even interact with the sources of traffic some where 
> i am also reading that some Ethernet equipment are 
> introducing several specific (data plane) constraints, 
> indeed, but the control plane is not going to elevate those, 
> in part. these constraints are independent whether one has 
> unidirectional LSP, or asym bandwidth LSP provisioning 
> capability at control plane level (adrian pointed this out 
> numerous times but this is one of the cornerstone of the 
> whole discussion)
> 
> hence, the point since so far, is that they are no convincing 
> argument in favor of an asymmetric LSP bandwidth provisioning 
> WITHIN a single signaling exchange, indeed, most arguments 
> are boiling down to hypothetical control plane efficiency 
> that can be ensured by other means if we consider the 
> restricting conditions where the proposed approach would be workable 
> 
> -d.
> 
> 
>  
> 
> 
> 
> 
> 
> some elements 
> of data plane fate sharing, but it is important to note that 
> it does not guarantee it. For example, a unidirectional fiber 
> could fail. This issue is not impacted by bidirectional or 
> associated signaling as the directions can be installed on 
> the path by associated signaling, and as a failure might only 
> impact one direction in bidirectional signaling.
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 7 Mar 2007 06:34:18 -0800 (PST)

Dimitri.

See in-line.

[email-masked] wrote: adrian, all

IB>> What Neil and Don are saying is that some signifficant Ethernet functionality will be lost if an Ethernet bi-directional service is mapped on non-congruent paths. This exactly coincides with what I hear from our local Ethernet experts. Hence, if we are to support Ethernet layer by GMPLS, we must consider mapping them on single bi-directional LSPs. This is not "hypothetical control plane efficiency" discussion. Bi-directional LSPs are as important in Ethernet as in TDM or optical layers. But I do agree with you that so far there were no convincing examples presented just yet that illustrate the need of bandwidth asymetrical services. 

Igor

-d.

"Adrian Farrel" 
 
        To:     "Attila Takacs \(IJ/ETH\)" , 
"Pandian, Vijay" , "Don Fedyk" 

        cc:     

Hi,

Adrian

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

Cc: 

Hi Vijay,

let me answer this.

Regards,
Attila

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on

Hi Vijay

Hi,

Regards,
Don

Regards,

Vijay

---------------------------------
8:00? 8:25? 8:40?  Find a flick in no time
 with theYahoo! Search movie showtime shortcut.

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 7 Mar 2007 12:43:49 -0500

Hi Dimitri 

Inline [DF]

> but "Do we have a clear requirement for asymmetrical 
[DF]  I agree. 

> mentioning in their examples
[DF] Two points. The GMPLS for Ethernet Provider Backbone Bridges-TE is
hardly a micro flow but you are correct that at high bandwidth levels it
would likely be symmetric BW. 

> introducing several 

[DF] Sorry I'm missing your point here. 
> argument in 

[DF] I don't agree on the efficiency point.  By any measure of
efficiency a single RSVP-TE session that handles both directions and
possibly different bandwidths is better that 2 that do 1/2 the job each.
If bandwidth is the same, in each direction today we don't need an
extension.  Igor gave a nice summary.  

BTW I do believe that there will be an association object to correlate
at the very least primary and back-up bi-directional LSP.  I agree an
association object can manage 2 RSVP-TE uni-directional sessions for a
full bi-directional connection, and while there is some merit to not
extending current BW semantics there are also a set of new correlation
rules that have not been implemented. 

So if we enumerate the GMPLS LSP building block possibilities I see: 

Unidirectional LSP with BW (supported today by existing procedures)
- 1 RSVP-TE session 

Symmetric BW bi-directional LSP (supported today by existing procedures)
- 1 RSVP-TE session can be used by existing GMPLS 

Asymmetric BW bi-directional LSP (not yet defined).
- 2 Unidirectional LSPs with BW + an association object need to be used
plus a set of extensions to path correlation 
OR 
- 1 Symmetric BW bi-directional LSP can be used and no BW objects (many
MPLS TE sessions have no real BW in the control plane)
OR
- 1 Symmetric BW bi-directional LSP a bi-directional BW object. 

Regards,
Don 

<snip>

---

From: [email-masked]
Date: Fri, 9 Mar 2007 00:34:13 +0100

igor 

"Hence, if we are to support Ethernet layer by GMPLS, we must consider 
mapping them on single bi-directional LSPs."

this statement is fundamentally incorrect, the association of control 
plane state to data plane state is independent on the Ethernet 
constraints, one may device control plane techniques that are facilitating 
operations but there are by no means reason to constrain the way nodes are 
performing such association

as i wrote a couple of days ago

"i am also reading that some Ethernet equipment are introducing several 
specific (data plane) constraints, indeed, but the control plane is not 
going to elevate those, in part. these constraints are independent whether 
one has unidirectional LSP, or asym bandwidth LSP provisioning capability 
at control plane level (adrian pointed this out numerous times but this is 
one of the cornerstone of the whole discussion)"

-d.

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
07/03/2007 15:34
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel 
<[email-masked]>
        cc:     "Attila Takacs \(IJ/ETH\)" <[email-masked]>, 
[email-masked], Don Fedyk <[email-masked]>, 
[email-masked], "Pandian, Vijay" <[email-masked]>
        Subject:        Re: What is this fate sharing thing? [Was: 
Questions on draft-takacs-asym-bw-lsp-00.txt]

Dimitri.

See in-line.

[email-masked] wrote:
adrian, all

IB>> What Neil and Don are saying is that some signifficant Ethernet 
functionality will be lost if an Ethernet bi-directional service is mapped 
on non-congruent paths. This exactly coincides with what I hear from our 
local Ethernet experts. Hence, if we are to support Ethernet layer by 
GMPLS, we must consider mapping them on single bi-directional LSPs. This 
is not "hypothetical control plane efficiency" discussion. Bi-directional 
LSPs are as important in Ethernet as in TDM or optical layers. But I do 
agree with you that so far there were no convincing examples presented 
just yet that illustrate the need of bandwidth asymetrical services. 

Igor

-d.

"Adrian Farrel" 

cc: 

Hi,

Adrian

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

Cc: 

Hi Vijay,

let me answer this.

Regards,
Attila

Don,

Regards,

Vijay

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; [email-masked]
Subject: RE: Questions on

Hi Vijay

Hi,

Regards,
Don

Regards,

Vijay