Subject: [mpls-tp] FW: OPINIONS PLEASE: Preparing MPLS-TP Requirementsforlastcall

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

-----Original Message-----
From: Cecil Byles 
Sent: 03 February 2009 16:14
To: 'Ben Niven-Jenkins'
Subject: RE: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-TP
Requirementsforlastcall

Hi Ben

After reading the various e-mail comments on this subject, I would like
to suggest the following text for the definition below, as this would
support the migration of legacy TDM networks and all their associated
OAM capabilities. 

Thus based on the above I believe the following should apply.

> Bidirectional path: A path that supports traffic flow in both 
> directions on the same predetermined route (links and nodes) across 
> its layer network under normal operating conditions.
> Under failure conditions 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>.

The above definition would support the following statement in the
requirements documentation see below

"Transport carriers require control and deterministic usage of network
resources. They need end-to-end control to engineer network paths and to
efficiently utilize network resources. They require capabilities to
support static or dynamic provisioning of deterministic, protected and
secured services and their associated resources."

This view is also supported by Eric Gray's e-mail where he states "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 a special case of
bidirectional"

-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.

Regards

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

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: 03 February 2009 14:59
To: Cecil Byles
Subject: Re: [mpls-tp] OPINIONS PLEASE: Preparing MPLS-TP
Requirementsforlastcall

Cecil,

Free free to make comments.  Ben

On 03/02/2009 10:06, "Cecil Byles" <[email-masked]> wrote:

> 
>  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
>  
> 
>> -----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,
>> 
>> 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
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

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