Hi Adrian,
Some comments in line
Best Regards
Diego
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
Sent: martedì 6 marzo 2007 12.05
To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
Cc: ccamp@ops.ietf.org
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 J 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.
- 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.
[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
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?
[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)" <Attila.Takacs@ericsson.com>
To: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>; "Don Fedyk"
<dwfedyk@nortel.com>
Cc: <ccamp@ops.ietf.org>
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.
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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Pandian, Vijay
Sent: Tuesday, March 06, 2007 1:36 AM
To: Don Fedyk
Cc: ccamp@ops.ietf.org
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:dwfedyk@nortel.com]
Sent: Monday, March 05, 2007 6:41 PM
To: Pandian, Vijay; ccamp@ops.ietf.org
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
Hi Vijay
________________________________
From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Pandian, Vijay
Sent: Monday, March 05, 2007 2:07 PM
To: ccamp@ops.ietf.org
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