Subject: Re: [mpls-tp] -03 of requirements draft & actions still toberesolved

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 2 Feb 2009 09:00:39 +0100

Please take into account that if, and AFAIK that is the route, we are going to use GMPLS to signal MPLS-TP LSPs we already have the possibility to set-up bidrectional LSPs.  Meaning that a single signaling (Path/Resv/(Confirm)) can set-up a bidirectional LSP.

Of course I'm not saying that MPLS-TP data plane must support bidirectional LSPs just because GMPLS does nevertheless the fact we have bidirectional LSPs in GMPLS is an indicator that there is a clear requirement to support it in transport network.

Just my two cents.

BR

Diego

__________________________________________

Diego Caviglia

Strategic Product Manager

Broadband Networks, PL Broadband Optical Network 

Ericsson Telecomunicazioni S.p.A. (TEI)

Via A. Negrone 1/A                                 Office:  +39 010 600 3736

16153, Genova, Italy                               Fax: +39 010 600 3577

Block E Level 4                                        Mobile: +39 335 7181762

www.ericsson.com                  diego,[email-masked]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

________________________________

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Niven-Jenkins
> Sent: venerdì 30 gennaio 2009 17.53
> To: Maarten Vissers; 'BUSI ITALO'
> Cc: [email-masked]
> Subject: Re: [mpls-tp] -03 of requirements draft & actions still
> toberesolved
> 
> Maarten,
> 
> Please remember that the work on MPLS-TP is pulled in two directions
> depending on the requirements and strategy of the different participants
> 
> 1) Those who want to drive additional MPLS-TP functionality to match that
> of
> transport networks to date
> 2) Those who want to drive additional MPLS-TP functionality to match that
> of
> packet networks to date.
> 
> Associated uni-directional paths is how MPLS supports bi-directional
> connectivity today ad some participants would like to retain that
> behaviour
> as it is how their network operates today, what their operations are
> familiar with etc.
> 
> Ben
> 
> 
> On 30/01/2009 15:54, "Maarten Vissers" <[email-masked]> wrote:
> 
> > Italo,
> >
> > Thanks for this clarification.
> > In this case I would like to ask the question what the application is of
> > such paths? I.e. when would one want to use such paths, instead of just
> two
> > unidirectional paths or of one co-routed bidirectional path.
> >
> > Regards,
> > Maarten
> >
> > -----Original Message-----
> > From: BUSI ITALO [mailto:[email-masked]]
> > Sent: vrijdag 30 januari 2009 16:28
> > To: Maarten Vissers; Ben Niven-Jenkins
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] -03 of requirements draft & actions still to
> > beresolved
> >
> > Maarten,
> >
> > My understanding is that associated unidirectional paths are two
> > unidirectional paths (treated as unidirectional from OAM, CP and
> protection
> > perspective) that are just associated at the end-points.
> >
> > Italo
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> >> Sent: Friday, January 30, 2009 3:52 PM
> >> To: 'Ben Niven-Jenkins'
> >> Cc: [email-masked]
> >> Subject: Re: [mpls-tp] -03 of requirements draft & actions still to
> >> beresolved
> >>
> >> Ben,
> >>
> >> Can you describe how we should treat "associated unidirectional paths"
> >> from an OAM perspective?
> >>
> >> Should such path be treated as two independent unidirectional paths,
> >> in which case there is no Remote Defect/Error Information to exchange
> >> between the two endpoints? Additionally, any tandem connection
> >> monitoring will only be unidirectional as the other direction of such
> >> associated unidir paths will not pass through the same nodes.
> >>
> >> Or, should such path still support Remote Defect/Error Information
> >> between the two endpoints of this path?
> >>
> >> Note that SNC type protection switching of the 1:1 type will not be
> >> able to work on such associated unidir paths as such protection
> >> requires APS signals to flow over both direction of the path.
> >>
> >> Regards,
> >> Maarten
> >>
> >> _______________________________________________
> >> 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

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 11:51:19 +0100

Ben, 

I am aware of the two directions, and am just trying to understand in which
case those favouring "associated unidirectional paths" want to deploy this
type of path. When I know this, I can judge what the impact is on OAM,
multi-operator connection monitoring, fault localization and protection
switching. Support of this type of paths may have a significant impact on
these things.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: vrijdag 30 januari 2009 17:53
To: Maarten Vissers; 'BUSI ITALO'
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to
beresolved

Maarten,

1) Those who want to drive additional MPLS-TP functionality to match that of
transport networks to date
2) Those who want to drive additional MPLS-TP functionality to match that of
packet networks to date.

Associated uni-directional paths is how MPLS supports bi-directional
connectivity today ad some participants would like to retain that behaviour
as it is how their network operates today, what their operations are
familiar with etc.

Ben

On 30/01/2009 15:54, "Maarten Vissers" <[email-masked]> wrote:

> In this case I would like to ask the question what the application is 
> of such paths? I.e. when would one want to use such paths, instead of 
> just two unidirectional paths or of one co-routed bidirectional path.
> 
> Regards,
> Maarten
>

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 2 Feb 2009 14:23:14 -0600

Italo/Maarten,

	Just to avoid muddying a number of other discussions, I believe 
we're close to convergence on changing "associated uni-directional"
to "bi-directional" (where the distinction is between "bi-directional"
and "co-routed bi-directional" - instead of "associated uni-directional"
and "bi-directional").  This originated from a comment by Neil, and has
been circulated on the list with no substantive objections (that I know
of).

	Hence this discussion is using a specific term that is about to 
become irrelevant, and is therefore likely to generate confusion...

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BUSI ITALO
Sent: Friday, January 30, 2009 11:12 AM
To: Maarten Vissers; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still
toberesolved

Boh (dunno)

I would leave to the people supporting this option to clarify the
application: there were quite a few within MEAD.

I do not see any harm in supporting associated unidirectional transport
paths, as long as we keep a clear definition and distinction wrt
bidirectional transport paths.

Italo

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Friday, January 30, 2009 4:54 PM
> To: BUSI ITALO; 'Ben Niven-Jenkins'
> Cc: [email-masked]
> Subject: RE: [mpls-tp] -03 of requirements draft & actions 
> still to beresolved
> 
> Italo,
> 
> such paths? I.e. when would one want to use such paths, 
> instead of just two
> unidirectional paths (treated as unidirectional from OAM, CP 
> and protection

---

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

Maarten,

If one has equipment that does not support the setup of co-signaled
bidirectional paths one may use two unidirectional paths. However if those
unidirectional paths are supporting a bidirectional client/service it may be
useful to associate them into a bidirectional path in order to manage the
bidirectional client/service more efficiently (e.g. Alarm suppression)

An example would be supporting an Ethernet link using a PW over MPLS (which
doesn't support co-signaled bidirectional paths today).

Ben

On 30/01/2009 15:54, "Maarten Vissers" <[email-masked]> wrote:

> such paths? I.e. when would one want to use such paths, instead of just two
> unidirectional paths (treated as unidirectional from OAM, CP and protection

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:33:56 +0000

Diego,

No-one is disputing the requirement for co-routed bi-directional paths.
It's really about what do we call a bi-directional path that has not been
co-signaled.

Ben

On 02/02/2009 08:00, "Diego Caviglia" <[email-masked]> wrote:

> Please take into account that if, and AFAIK that is the route, we are going to
> use GMPLS to signal MPLS-TP LSPs we already have the possibility to set-up
> bidrectional LSPs.  Meaning that a single signaling (Path/Resv/(Confirm)) can
> set-up a bidirectional LSP.
> 
> Of course I'm not saying that MPLS-TP data plane must support bidirectional
> LSPs just because GMPLS does nevertheless the fact we have bidirectional LSPs
> in GMPLS is an indicator that there is a clear requirement to support it in
> transport network.
> 
> Just my two cents.
> 
> BR
> 
> Diego
>  
> 
> This communication is confidential and intended solely for the addressee(s).
> Any unauthorized review, use, disclosure or distribution is prohibited. If you
> believe this message has been sent to you in error, please notify the sender
> by replying to this transmission and delete the message without disclosing it.
> Thank you.
> 
>  
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:37:30 +0000

Maarten, See my response earlier this evening to your original mail.  Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Feb 2009 11:34:31 +0100

Ben,

Alarm suppression is a unidirectional tool and doesn't depend on
unidirectional or bidirectional server layer connections. So this is not the
right example in my opinion.

Co-routed bidirectionality is important for 
- SNC protection switching
- tandem connection monitoring for case of multi-operator services
- management (including fault localization) because both directions of
transmission use the same equipment along the full length of the connection
- maintaining of equal delays for both directions of transmission. This may
be important where there is a significant imbalance in the length of the
connections.

Non-co-routed bidirectionality will complicate those four items. Can we add
the complications that non-co-routed bidir connection introduce as a note
and state that those complications will not result in additional
requirements for SNC protection, tandem connection monitoring and fault
localization?

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: maandag 2 februari 2009 23:45
To: Maarten Vissers; 'BUSI ITALO'
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to
beresolved

Maarten,

Ben