Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-TP Requirements forlastcall

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 22:13:55 +0000

Huub,

On 30/01/2009 11:33, "Huub van Helvoort" <[email-masked]> wrote:

> All,
> 
> I agree with the comments of Annamaria and Italo.
> 
> A bidirectional path is intuitively a co-routed path, i.e. passing the
> same links and nodes in the network and shares fate.

I think this may depend on one's background. To me bidirectional just
conveys the meaning that it supports traffic flow in both directions.

It is the term itself or the definition that is objectionable?  How about
the following compromise?

Bidirectional path: A path that supports traffic flow in both directions.
The forward and backward directions may or may not follow the same route
(links and nodes) across its layer network. A bidirectional path may be
constructed from a pair of unidirectional paths (one for each direction)
which are associated with one another at the path's ingress/egress points.

Ben

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

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 03 Feb 2009 09:55:44 +0100

Hi Ben,

> conveys the meaning that it supports traffic flow in both directions.

Indeed, my background is transport networks and there a bidirectional
path always follows the same path (links and nodes) in the network.
Both  directions are provisioned at the same time.

This has the advantage that the termination points are associated
and remote information can be returned. Provisioning of MIPs in
intermediate nodes is also possible as these require association
for tools that require a response.

Setting up a unidirectional path is exceptional.

> It is the term itself or the definition that s objectionable?  How about

I think it should be made more clear that two flavors of
bidirectional path exist:
-1- bidirectional path with only ingress/egress ports associated
     this is provisioned and managed as two unidirectional paths that
     are associated after establishing.
-2- bidirectional path fully associated, including sections and
     intermediate nodes.
     This is provisioned and managed as a single entity.

In the scope of MPLS-TP applied in a transport network I propose
to use bidirectional in the sense of -2- and use the term
*associated bidirectional* for case -1- to indicate that is is a
special case of bidirectional.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Rolf Winter" <[email-masked]>
Date: Tue, 3 Feb 2009 09:57:32 +0100

Ben,

I am in favor of that new definition. From the discussion it appears that people sometimes want to refer only and explicitly to the co-routed case. Maybe you can slightly update the definition to the following to capture that requirement:

Bidirectional path: A path that supports traffic flow in both directions The forward and backward directions may or may not follow the same route (links and nodes) across its layer network. <ADD> The former case is referred to as co-routed </ADD>. A bidirectional path may be constructed from a pair of unidirectional paths (one for each direction) which are associated with one another at the path's ingress/egress points.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ben Niven-Jenkins
> Sent: Montag, 2. Februar 2009 23:14
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-TP Requirements
> forlastcall
> 
> Huub,
>

---

From: "Cecil Byles" <[email-masked]>
Date: Tue, 3 Feb 2009 11:06:27 +0100

Hi,

Can I reply with a comment on the definition for bidirectional path as I
am only a recipient of this forum ?

Cecil Byles   

Senior Architect 
Services Development-Transmission Architecture 
Information Systems & Technology 
Interoute Communications Limited
Walbrook Building, 195 Marsh Wall, London E14 9SG, UK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rolf Winter
Sent: 03 February 2009 08:58
To: Ben Niven-Jenkins; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-TP
Requirementsforlastcall

Ben,

I am in favor of that new definition. From the discussion it appears
that people sometimes want to refer only and explicitly to the co-routed
case. Maybe you can slightly update the definition to the following to
capture that requirement:

Bidirectional path: A path that supports traffic flow in both directions
The forward and backward directions may or may not follow the same route
(links and nodes) across its layer network. <ADD> The former case is
referred to as co-routed </ADD>. A bidirectional path may be constructed
from a pair of unidirectional paths (one for each direction) which are
associated with one another at the path's ingress/egress points.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014 

> It is the term itself or the definition that is objectionable?  How 
> about the following compromise?
> 
> The forward and backward directions may or may not follow the same 
> route (links and nodes) across its layer network. A bidirectional path

> may be constructed from a pair of unidirectional paths (one for each
> direction)

---

From: "Rolf Winter" <[email-masked]>
Date: Tue, 3 Feb 2009 12:07:39 +0100

The IETF is not making such a distinction (RFC 3935).

> Behalf Of Cecil Byles
> Sent: Dienstag, 3. Februar 2009 11:06
> To: Rolf Winter; Ben Niven-Jenkins; [email-masked]; mpls-
> [email-masked]
> Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-
> TPRequirementsforlastcall
> 
> 
>  Hi,
> 
> route
> Requirements

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 3 Feb 2009 06:58:24 -0600

And thus we come full circle to what we had decided at the design
team meeting in Ipswich.

Since I have been delaying internal review and submission of our 
draft pending resolution of this issue, I think I will just have
to assume that we're going with what we had decided earlier.  If
we change our collective minds (again), then we will have change
the draft again.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Huub van Helvoort
Sent: Tuesday, February 03, 2009 3:56 AM
To: [email-masked]
Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-TP
Requirementsforlastcall

Hi Ben,

route

Cheers, Huub.

---

From: <[email-masked]>
Date: Tue, 3 Feb 2009 13:12:20 -0000

Colleagues,

I don't really want to prolong this discussion, but if we want to be
precise here (if only to be sure that at some future date someone can't
point out that our definition was incomplete) we ought to make it clear
that routing congruency at layer N does not ensure routing congruency in
all layers down to the duct.

This is not just a point of academic interest.  It can practically
affect network performance (especially absolute delay variation between
the 2 directions), the frequency and nature of 'break' failures, and
what we might infer from an incoming OAM failure indications at layer
N....let me try and explain:

FREQ OF FAILURES AT LAYER N:
---------------------------
Let us assume then when we break a section layer that both directions on
that section fail....a reasonable assumption.  Let us also assume
congruent routing from layer N to the duct and that X bidirectional link
connections at layer N map to Y1 bidirectional sections at the physical
layer (Y1>=X).  However, if there is not congruent routing to the duct
then the X bidirectional link connections at layer N will map to Y2
different sections at the physical layer, where Y2>Y1.

This means that the case of non-congruent routing to the duct layer N
will experience Y2/Y1 more failures over some period than the congruent
routing case. 

And to take a concrete example, if we assume
-	that in the congruent routing case the X bidirectional link
connections at layer N map to exactly X bidirectional sections
-	whilst in the non-congruent routing case each X bidirectional
link connection at layer N maps to a different section there will be 2X
sections.

Thus in this case we can say that by not providing routing congruency to
the duct the probability of failures in layer N has increased 2-fold
from section layer cuts.

Aside=> In the classic definition of unavailability if any direction
fails (for >=10s) then both directions are assumed to be unavailable

OAM FAILURE INDICATIONS:
-----------------------
If the predominant type of failure is section layer cuts where both
directions fail, then in the case of single-ended monitoring at layer N
and with congruent routing to the duct:
-	if we see an incoming BDI indication (ie incoming direction has
not failed at layer N) we can assume with a high degree of confidence
the outgoing direction has failed *at layer N* and not a lower layer
network, because.....
-	....if a section layer had failed this would give rise to an
incoming failure indication at layer N, and we can also assume the
outgoing direction at layer N has also failed.

With non-congruent routing to the duct we cannot assume any of this. 

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rolf Winter
> To: Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]
> I am in favor of that new definition. From the discussion it 
> appears that people sometimes want to refer only and 
> explicitly to the co-routed case. Maybe you can slightly 
> update the definition to the following to capture that requirement:
> 
> Bidirectional path: A path that supports traffic flow in both 
> directions The forward and backward directions may or may not 
> follow the same route (links and nodes) across its layer 
> network. <ADD> The former case is referred to as co-routed 
> </ADD>. A bidirectional path may be constructed from a pair 
> of unidirectional paths (one for each direction) which are 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
>  
>

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 3 Feb 2009 07:37:57 -0600

Neil,

	I think we mostly understand this.  We had exactly this
discussion
(in gruesome detail) at the design team meeting in Ipswich.  One thing I
wondered at the time was - beyond establishing that caveats may apply -
what exactly are we (as the people trying to define a Transport Profile
for MPLS) supposed to do about the possibility that route congruency may
not exist for other technologies applicable to other network layers?

	I think the obvious caveat is that - if you want route
congruency 
at a specific network layer - you may want to ensure that you have it at

lower layer networks as well.

	However important this may be for a network operator to realize,

for the purposes of defining requirements for MPLS-TP, this seems to be
a 
big "SO WHAT?"

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, February 03, 2009 8:12 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing
MPLS-TPRequirementsforlastcall

Colleagues,

OAM FAILURE INDICATIONS:
-----------------------

regards, Neil

> > directions.

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Tue, 3 Feb 2009 10:12:40 -0600

Huub,

I have a question for clarification. Is your -2- equivalent to the
co-routed one or not?

Regards,
Kam

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Huub van Helvoort
directions.
route

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 04 Feb 2009 14:23:13 +0100

Hello Kam,

> I have a question for clarification. Is your -2- equivalent to the

Yes it is equivalent, so adding "co-routed" doe not provide extra
information (just like in "black T-Ford" black does not add).

For case -1- "associated" adds extra information (just as in
"blue T-Ford").

Cheers, Huub.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 21:04:30 +0000

Eric,

Following the debate I have decided the same thing and will keep the
existing definitions as per -03 which are as follows:

Associated unidirectional path: A path that supports traffic flow in both
directions but which is constructed from a pair of unidirectional paths (one
for each direction) which are associated with one another at the path's
ingress/egress points. The forward and backward directions may or may not
follow the same route (links and nodes) across the network.

Bidirectional path: A path where the forward and backward directions follow
the same route (links and nodes) across the network.

Unidirectional path: A path that supports traffic flow in only one
direction.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 21:06:00 +0000

One correction. I have used the term associated bidirectional path not
associated unidirectional path.  Ben