Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

From: Lou Berger <[email-masked]>
Date: Fri, 03 Apr 2009 17:01:08 -0400

So Greg,
	Your proposal is that the intermediate nodes treat the associated
unidirectional LSPs as a bidirectional protected entity?

This is certainly something that is far beyond anything I ever have seen
in the MPLS-TP requirements.  This is, of course, something that *could*
be supported, but the additional mechanisms are substantial. IMO we need
strong operator support for this expansion of function before including
it.  I also think, if there is such support then it should be a
required/MUST function of MPLS-TP given the additional mechanisms
required for it's explicit support.

BTW As I mentioned before, what you are asking for largely comes for
free as if you layer/stack a bidirectional LSP on top of N associated
LSPs.  As long as the N associated LSPs are
signaled/controlled/monitored independently, as apposed to LSP segments,
this is quite feasible and doesn't require explicit support by MPLS-TP
beyond what is already in requirements 32-34.

Lou

On 3/30/2009 7:49 PM, Greg Mirsky wrote:
> Hi Sasha,
> I agree with your suggestion regarding common intermediate nodes of 
> associated bi-directional path. Would following work:
> Only common nodes that are aware of pairing relationship between forward 
> and backward directions of associated bidirectional path can be used as 
> end-points of a protected segment of that transport path.
> 
> Regards,
> Greg
> 
> 2009/3/30 Alexander Vainshtein <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Greg and all,
>     Please note that, generally speaking, the set of common intermediate
>     nodes for two directions of an associated bidirectional path can be
>     empty. And intermediate nodes that are not common to the two
>     directions cannot be aware of the pairing relationship...
>     IMHO and FWIW:
>     - The overall added value of this optional requirement is not high
>     - The restriction (only common intermediate nodes) should be
>     mentioned explicitly.
>     My 2c,
>     Sasha
>     ------------------------------------------------------------------------
>     *From:* [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Greg Mirsky [[email-masked]
>     <mailto:[email-masked]>]
>     *Sent:* Monday, March 30, 2009 9:57 PM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
> 
>     *Subject:* Re: [mpls-tp] Associated bidirectional transport path
>     requirements
> 
>     Hi Liu,
>     please note that in regard to intermediate nodes of associated
>     bi-directional TP-LSP this awareness is only "MAY", optional. I
>     prefer it being explicitly mentioned though since I see associated
>     bi-directional TP-LSP as bi-directional transport entity. Thus its
>     linear 1:1 protection behaves as 1:1 linear protection for a
>     co-routed bidirectional path. If such association is maintaned then
>     it is possible, I think, to apply segment protection to an
>     associated bi-directional path terminating protection segments at
>     head-ends and intersection nodes.
> 
>     Regards,
>     Greg
> 
>     2009/3/29 <[email-masked] <mailto:[email-masked]>>
> 
> 
>         Hi, Ben and Greg:
>         I don't understand why to need be aware of the pairing
>         relationship of the forward and backward directions of that path
>         for intermediate nodes of associated bidirectional transport
>         path? I think it necessary to be aware of the pairing
>         relationship for two-end MEP .
>         do you provide good reason?
>         thank you
>         liu
> 
> 
>         *Greg Mirsky <[email-masked]
>         <mailto:[email-masked]>>*
>         发件人: [email-masked] <mailto:[email-masked]>
> 
>         2009-03-29 23:04
> 
>         	
>         收件人
>         	
>         Ben Niven-Jenkins <[email-masked]
>         <mailto:[email-masked]>>
>         抄送
>         	
>         "[email-masked] <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>         主题
>         	Re: [mpls-tp] Associated bidirectional transport path requirements
> 
> 
>         	
> 
> 
> 
> 
> 
>         Totally agree and support.
> 
>         Regards,
>         Greg
> 
>         On Sat, Mar 28, 2009 at 9:30 PM, Ben Niven-Jenkins
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         Cut & paste error - my fault for trying to do this on the plane
>         when I
>         should have been sleeping :-) 35 should read:
> 
>         35 The intermediate nodes (including MEPs, MIPs and other internal
>         functions as appropriate) of an ASSOCIATED bidirectional
>         transport path at
>         each (sub-)layer MAY be aware of the pairing relationship of the
>         forward and
>         the backward directions of that transport path.
> 
>         Ben
> 
>         On 28/03/2009 18:48, "Alexander Vainshtein"
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>          > Ben,
>          > Looks like 33 and 35 define the same requirement at two
>         different levels: MUST
>          > and MAY.
>          >
>          > Did I miss something?
>          >
>          > Regards,
>          > Sasha
>          > ________________________________________
>          > From: [email-masked]
>         <mailto:[email-masked]> [[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Ben
>          > Niven-Jenkins [[email-masked]
>         <mailto:[email-masked]>]
>          > Sent: Saturday, March 28, 2009 11:54 AM
>          > To: Benjamin Niven-Jenkins; [email-masked]
>         <mailto:[email-masked]>
>          > Subject: Re: [mpls-tp] Associated bidirectional transport
>         path requirements
>          >
>          > OK, following list traffic and private comments, how about change
>          > requirements 32 and insert requirements 33, 34, 35 worded as
>         follows.
>          >
>          > I have kept each as individual requirement to try to avoid
>         ambiguity
>          > introduced by having lots of text in a single requirement.
>          >
>          >
>          > 32 The end points of a co-routed bidirectional transport path
>         MUST be aware
>          > of the pairing relationship of the forward and reverse paths
>         used to support
>          > the bidirectional service.
>          >
>          > 33 The intermediate nodes (including MEPs, MIPs and other
>         internal
>          > functions as appropriate) of a co-routed bidirectional
>         transport path at
>          > each (sub-)layer MUST be aware of the pairing relationship of
>         the forward
>          > and the backward directions of that transport path.
>          >
>          > 34 The end points of an associated bidirectional transport
>         path MUST be
>          > aware of the pairing relationship of the forward and reverse
>         paths used to
>          > support the bidirectional service.
>          >
>          > 35 The intermediate nodes (including MEPs, MIPs and other
>         internal
>          > functions as appropriate) of a co-routed bidirectional
>         transport path at
>          > each (sub-)layer MAY be aware of the pairing relationship of
>         the forward and
>          > the backward directions of that transport path.
>          >
>          > Ben
>          >
>          >
>          > On 25/03/2009 23:32, "Benjamin Niven-Jenkins"
>          > <[email-masked]
>         <mailto:[email-masked]>> wrote:
>          >
>          >> OK, How about this, change requirement 32 from:
>          >>
>          >> 32 The intermediate nodes at each (sub-)layer MUST be aware
>         about
>          >> the pairing relationship of the forward and the backward
>          >> directions belonging to the same co-routed bidirectional
>          >> transport path.
>          >>
>          >> To:
>          >> 32 The intermediate nodes at each (sub-)layer MUST be aware
>         about
>          >> the pairing relationship of the forward and the backward
>          >> directions belonging to the same co-routed bidirectional
>          >> transport path.
>          >>
>          >> A This requirement does not apply to associated bidirectional
>          >> transport paths. Only the ingress and egress nodes at each
>          >> (sub-)layer MUST be aware about the pairing relationship of the
>          >> forward and backward directions belonging to the same associated
>          >> bidirectional transport path.
>          >>
>          >> Quick review appreciated as I am hoping to spin -06 early
>         next week ready to
>          >> liaise to ITU.
>          >>
>          >> Ben
>          >>
>          >>
>          >>
>          >> On 25/03/2009 17:58, "Benjamin Niven-Jenkins"
>          >> <[email-masked]
>         <mailto:[email-masked]>> wrote:
>          >>
>          >>> Folks,
>          >>>
>          >>> Following a chat with Lou I will expand the text around the
>         requirement on
>          >>> associated bidirectional transport paths to try and clear
>         up some of the
>          >>> confusion expressed in the meeting just now.
>          >>>
>          >>> IMO any more than a few clarifying statements belongs in
>         the framework draft
>          >>> not the requirements draft.
>          >>>
>          >>> Ben
>          >>>
>          >>> _______________________________________________
>          >>> mpls-tp mailing list
>          >>> [email-masked] <mailto:[email-masked]>
>          >>> _https://www.ietf.org/mailman/listinfo/mpls-tp_
>          >>
>          >
>          > _______________________________________________
>          > mpls-tp mailing list
>          > [email-masked] <mailto:[email-masked]>
>          > _https://www.ietf.org/mailman/listinfo/mpls-tp_
> 
>         _______________________________________________
>         mpls-tp mailing list_
>         [email-masked] <mailto:[email-masked]>_
>         __https://www.ietf.org/mailman/listinfo/mpls-tp_
>         _______________________________________________
>         mpls-tp mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
>         --------------------------------------------------------
>         ZTE  Information  Security  Notice:  The  information  contained  in  this  mail  is  solely  property  of  the  sender's  organization.  This  mail  communication  is  confidential.  Recipients  named  above  are  obligated  to  maintain  secrecy  and  are  not  permitted  to  disclose  the  contents  of  this  communication  to  others.
>         This  email  and  any  files  transmitted  with  it  are  confidential  and  intended  solely  for  the  use  of  the  individual  or  entity  to  whom  they  are  addressed.  If  you  have  received  this  email  in  error  please  notify  the  originator  of  the  message.  Any  views  expressed  in  this  message  are  those  of  the  individual  sender.
>         This  message  has  been  scanned  for  viruses  and  Spam  by  ZTE  Anti-Spam  system.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 3 Apr 2009 17:17:42 -0400

Lou,
please find my notes in-lined notes tagged [GIM].

Regards,
Greg

2009/4/3 Lou Berger <[email-masked]>

> unidirectional LSPs as a bidirectional protected entity?

[GIM] If associated bi-directional LSP is treated by its end-points as
bidirectional entity then why wouldn't intersecting intermediate nodes treat
segments of the same LSP as bidirectional entities?

> required for it's explicit support.

[GIM] Agree to all your points - support from operators, change of wording
to make it firm requirement rather than optional behavior if such support
exists.

> [snip]

---

From: Lou Berger <[email-masked]>
Date: Fri, 03 Apr 2009 17:27:46 -0400

Greg,
	See below.

On 4/3/2009 5:17 PM, Greg Mirsky wrote:
> 2009/4/3 Lou Berger <[email-masked] <mailto:[email-masked]>>
>
>     So Greg,
> bidirectional entity then why wouldn't intersecting intermediate nodes
> treat segments of the same LSP as bidirectional entities?
>

Because they are composed of two unidirectional LSPs within the network 
and transit nodes would not have any information that would support the 
association, at least if today's mechanisms are used.

Lou

> [GIM] Agree to all your points - support from operators, change of
> wording to make it firm requirement rather than optional behavior if
> such support exists.
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 3 Apr 2009 16:38:54 -0700

Lou,
then linear 1:1 protection of an associated bi-directional path is,
essentially, protection of two independent unidirectional entities for both
segment and path protection? Or it is protection of a bi-directional entity
and then only path protection can be supported and not a segment protection
for an such transport path?

Regards,
Greg

On Fri, Apr 3, 2009 at 2:27 PM, Lou Berger <[email-masked]> wrote:

> Because they are composed of two unidirectional LSPs within the network and
> transit nodes would not have any information that would support the

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Apr 2009 10:14:53 -0400

Greg,
	Certainly each unidirectional LSP can be protected by both end-to-end 
and segment protection.  It'll be up to the definition of the new 
associated bi-directional path (which is really more of a service) to 
determine if there is some meaning to protection of the  bi-directional 
entity...

Lou

On 4/3/2009 7:38 PM, Greg Mirsky wrote:
> essentially, protection of two independent unidirectional entities for
> both segment and path protection? Or it is protection of a
> bi-directional entity and then only path protection can be supported and
> not a segment protection for an such transport path?
>
> Regards,
> Greg
>
> On Fri, Apr 3, 2009 at 2:27 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Greg,
>             See below.
>
>
>         2009/4/3 Lou Berger <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>
>             So Greg,
>     Because they are composed of two unidirectional LSPs within the
>     network and transit nodes would not have any information that would
>     support the association, at least if today's mechanisms are used.
>
>     Lou
>
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 6 Apr 2009 12:56:37 -0400

Lou,
you've said "*which is really more of a service*" and that is my feeling
too. If associated bi-directional entity is not a transport/server but a
service/client, does it belong to MPLS-TP architecture? Or it's too late to
discuss or I'm beating a dead horse?

Regards,
Greg

On Mon, Apr 6, 2009 at 10:14 AM, Lou Berger <[email-masked]> wrote:

> Greg,
>        Certainly each unidirectional LSP can be protected by both
> end-to-end and segment protection.  It'll be up to the definition of the new

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Apr 2009 13:51:02 -0400

Greg,
	Feel free to have the discussion with the requirements folks, but I'm 
really not sure if there is any real support for this...

Lou

On 4/6/2009 12:56 PM, Greg Mirsky wrote:
> Lou,
> you've said "_which is really more of a service_" and that is my feeling
> service/client, does it belong to MPLS-TP architecture? Or it's too late
> to discuss or I'm beating a dead horse?
>
> Regards,
> Greg
>
> On Mon, Apr 6, 2009 at 10:14 AM, Lou Berger <[email-masked]
>     end-to-end and segment protection.  It'll be up to the definition of
>     the new associated bi-directional path (which is really more of a
>     service) to determine if there is some meaning to protection of the
>       bi-directional entity...
>
>     Lou
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             Greg,
>                     See below.
>
>
>                 2009/4/3 Lou Berger <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>
>
>
>                     So Greg,
>                             Your proposal is that the intermediate nodes
>         treat the
>                     associated
>                 bidirectional entity then why wouldn't intersecting
>         intermediate
>                 nodes
>                     This is certainly something that is far beyond
>         anything I
>                 ever have seen
>                     in the MPLS-TP requirements.  This is, of course,
>         something
>                 that *could*
>                     be supported, but the additional mechanisms are
>         substantial.
>                 IMO we need
>                     BTW As I mentioned before, what you are asking for
>         largely
>                 comes for
>                     free as if you layer/stack a bidirectional LSP on
>         top of N
>                 associated
>                     signaled/controlled/monitored independently, as
>         apposed to
>                 LSP segments,
>                     this is quite feasible and doesn't require explicit
>         support
>                 by MPLS-TP