Subject: RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]

From: <[email-masked]>
Date: Tue, 6 Mar 2007 17:13:04 -0000

Igor,
 
I can think of one good case.  In CO mode layer networks the 2 key OAM
messages are CV (Connectivity Verification) and BDI (Backward Defect
Indication).  These OAM messages should be present on the trails in each
direction.  The key purpose of BDI is to allow a single end to see the
failure state of its outgoing direction, eg case of unidirectional
connection failure.  For this be of use in a link in a layer N network
for a unidirectional failure of a trail in a layer N-1 network serving
that link, one needs congruent bidirectional trail routings in both
those layer networks.....and clearly this is a recursive requirement
between any layers.
 
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin
Sent: 06 March 2007 15:52
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,

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,

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)" 
To: "Pandian, Vijay" ; "Don Fedyk" 

Cc: 
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: [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

  _____  

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

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 07:05:44 -0000

John....tend to agree with these points.  The only truly recursive
topological construct is p2p.....one can almost consider this as THE
topological atomic building block of hierarchy (ie a client/server layer
network relationship).  This becomes quite evident when we consider the
fact that a link connection in layer network N is provided by a trail in
layer network N-1...a relationship which is clearly recursive across a
stack of nested layer networks.

Now a p2mp construct (like a p2p construct) is also a connection (Note -
A trail is specific p2p relationship, so in a p2mp connection a trail
exists between the root and each leaf).  However mp2p and mp2mp
constructs are not connections.

As previously noted, one can only recursively construct topology with a
p2p connection. So if we want to create p2mp connections (and we will)
these should only exist at the very top of a network stack in the
context of a some service instance, ie we cannot use p2mp connections
(and certainly not mp2p and mp2mp constructs) for recursive topology
creation.

Why is this important? 

Well, its all about deterministic resource assignment and
management....and this plays through to a whole raft of practical
considerations (eg OAM/fault management, performance/SLAs, etc) that
should be important to operators and their customers (which can be other
operators).  The key point about a connection is that it must only have
a single source and no internal routing once created....this is
essentially a definition of a connection, and it comes from information
theory considerations of resource determinism.  Connections do not
(obviously) exist in the cl-ps mode. In the co-cs mode connections can
be created using time (eg SDH/PDH), freq (eg WDM) and space (eg per
fibre) dimension resource partitions.  In the co-ps mode connections can
only be practically created by resource partitioning of the time
dimension.  Note that the key difference between the co-cs and co-ps
mode in the time dimension is one of regular or irregular (respectively)
partitioning of resource.  What this essentially means is that labelling
and resource assignment are coupled/fixed processes and always
deterministic in the co-cs mode but not in the co-ps mode.  This has
many immediate practical consequences too, eg one can't create mp2p
constructs in the co-cs mode but one can in the co-ps mode.

Aside=> A practical consideration (but not axiomatic to its definition)
is that once created a connection is only consciously moved by (i) a
customer request (most obvious for SVC case), (ii) from failures (eg
prot-sw) or (iii) by premeditated planned works.  Counter example:  If
we add nodes/links to a cl-ps mode network than traffic can move at will
under the routing rules of the IGP, but this is not true (or should not
be true) in co-ps and co-cs mode networks....nothing intrinsically wrong
with that, its purely a function of the connection object and how this
must be defined wrt BOTH labelling and resource assignment
considerations.  And a key point to grasp in all this is that the 3
network modes are quite different and it is folly to try and treat them
all identically alike.

Now, the above was what I was hinting at in my last mail to Igor wrt to
the point about the binding of CV OAM messages (forward
defect-detection) and BDI OAM messages (backward defect-detection
indication) for fault management.  It's quite an important point, and
its why in a client/server relationship for creating topology we require
congruent bidirectional routings of the symmetric atomic p2p connection
building block.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: 06 March 2007 22:24
> To: [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: RE: What is this fate sharing thing? [Was: Questions 
> on draft-takacs-asym-bw-lsp-00.txt]
> 
> 
> 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 
> > on draft-takacs-asym-bw-lsp-00.txt]
> > 
> > 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,
> > 
> > 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 
> > 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:
> > From: "Attila Takacs (IJ/ETH)" <[email-masked]>
> > To: "Pandian, Vijay" <[email-masked]>; "Don Fedyk"
> > <[email-masked]>
> > Cc: <[email-masked]>
> > So the requirement is to use the same "physical link" for 
> the forward 
> > and reverse direction. Am I right?
> > 
> > Regards,
> > 
> > Vijay
> > 
> > 
> > 
> > So to your question besides bandwidth there is also underlying 
> > requirement to align with GMPLS single session procedures and
> > RSVP-TE sessions in separate from the single RSVP-TE session 
> > associated with the primary bidirectional LSP.
> > 
> > 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

---

From: <[email-masked]>
Date: Fri, 9 Mar 2007 06:51:49 -0000

Dimitri,
 
> [email-masked]
> Sent: 08 March 2007 23:34
> 
> 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,
NH=> You are correct, but for a different reason that you seem to talk
about below.  GMPLS is a suite of control-plane protocols...a server
layer control-plane does not support/create client layer network
topology, it is the server layer *data-plane* that does that job.

I attempted to explain a few days ago why a p2p bidirectionally
congruent server layer *data-plane* construct is THE atomic building
block for client topology creation (any client)...and I tried to show an
example here from fault management (eg OAM, prot-sw) considerations why
this is important.  As a thought experiment try constructing a client
layer topology from anything other than p2p server layer building
blocks.

The way native cl-ps mode Ethernet works however makes this
(bidirectionally congruent server requirement) rather obvious/important
anyway IMO....which is the point Igor is making above, so he is actually
correct in this respect.  And this has nothing to do with whether one
uses a GMPLS control-plane in the server layer network or not, it is
only relevant to the server layer data-plane.

regards, Neil

> 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]>
> 07/03/2007 15:34
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
> Adrian Farrel 
> <[email-masked]>
>         cc:     "Attila Takacs \(IJ/ETH\)" 
> [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
> 
> 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 
> 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)
> 
> 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 
> 
> 
> 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: 
> Subject: What is this fate sharing thing? [Was: Questions 
> - 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 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?
> 
> it does not 
> level and 
> discussion of 
> 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
> 
> 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).
> 
> understand the scope of this ID as well as the application 
> behind such a requirement.
> 
> 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.)
> 
> 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
> 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.
> 
> sense to route them separately (separate CSPF calculation at 
> each end) and eventually signal them independently as well?
> 
> 
> 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.
> 
> 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.
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
>  8:00? 8:25? 8:40? Find a flick in no time
> with theYahoo! Search movie showtime shortcut.
> 
> 
>