Subject: [mpls] Comments on draft-cheng-mpls-tp-shared-ring-protection-00

From: Gregory Mirsky <[email-masked]>
Date: Thu, 8 Nov 2012 21:32:09 +0000

Dear Authors, et al.,
below are my comments to your document I've mentioned at MPLS WG meeting earlier:
*       SPME given new Ring Tunnel name
      * Implicitly jumps between single ring and interconnected rings scenario
      * Implicitly considers p2p bidirectional corouted LSP even though more generic p2p scenario stated
      * Only Link OAM being considered, what makes steering more challenging
      * No mention that Link or Node protection in wrapping has to be pre-determined
      * Coordination protocol - TBD
      * Hard to identify advantages of this approach when comparing with solutions described in draft-weingarten-mpls-tp-ring-protection-06 protection of p2p bi-directional LSP.

   Regards,
        Greg

---

From: Yaacov Weingarten <[email-masked]>
Date: Fri, 9 Nov 2012 08:43:53 +0200

Greg, hi

I am not sure that I agree with all of your comments (see below), although
I would love to agree with your conclusion;)

BR,
yaacov
On Nov 8, 2012 11:32 PM, "Gregory Mirsky" <[email-masked]>
wrote:
> SPME given new Ring Tunnel name
yw>> I disagree that this Ring Tunnel is a new name for an SPME! SPME is a
standard p2p or p2mp bi-directional LSP (or tunnel), whereas this RT is a
new construct that (I think) needs to be defined first in MPLS (or a
reference should be given as to where it is defined).  The RT is defined by
its destination - so this makes it a mp2p tunnel where traffic may enter
the tunnel at any LSR in the ring and exit at the endpoint.

> Implicitly jumps between single ring and interconnected rings scenario
> Implicitly considers p2p bidirectional corouted LSP even though more
generic p2p scenario stated
yw>> I agree that using the RT construct they hae destroyed any pretense of
co-routed bi-directionality of the traffic, since obviously for a co-routed
LSP that enters the ring at LSR-A and LSR-D -the traffic in the A-D
direction will be transmitted through a RT that is destined for LSR-D
whereas the D-A traffic will be in some other RT that is destined for LSR-A.
> Only Link OAM being considered, what makes steering more challenging
yw>> It should also be noted that this is a physical Link OAM not a MPLS
logical link OAM.  I also think that the mechanism that is being suggested
for passing the switching information up to the MPLS level should be
expanded upon and possibly defined in MPLS (or referenced if already
defined).
> No mention that Link or Node protection in wrapping has to be
pre-determined
> Coordination protocol - TBD
> Hard to identify advantages of this approach when comparing with
solutions described in draft-weingarten-mpls-tp-ring-protection-06
protection of p2p bi-directional LSP.
>
> Regards,
>         Greg
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 9 Nov 2012 14:32:31 +0000

Hi Yaakov,
many thanks for your detailed comments. I think that if a Ring Tunnel presents mp2p construct then it unlikely can be part of solution for a MPLS-TP networks as it's operation is based on merging traffic flows. Would you agree?

    Regards,
        Greg

________________________________
From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Thursday, November 08, 2012 10:44 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-cheng-mpls-tp-shared-ring-protection-00

Greg, hi

I am not sure that I agree with all of your comments (see below), although I would love to agree with your conclusion;)

BR,
yaacov
> SPME given new Ring Tunnel name
yw>> I disagree that this Ring Tunnel is a new name for an SPME! SPME is a standard p2p or p2mp bi-directional LSP (or tunnel), whereas this RT is a new construct that (I think) needs to be defined first in MPLS (or a reference should be given as to where it is defined).  The RT is defined by its destination - so this makes it a mp2p tunnel where traffic may enter the tunnel at any LSR in the ring and exit at the endpoint.

> Implicitly considers p2p bidirectional corouted LSP even though more generic p2p scenario stated
yw>> I agree that using the RT construct they hae destroyed any pretense of co-routed bi-directionality of the traffic, since obviously for a co-routed LSP that enters the ring at LSR-A and LSR-D -the traffic in the A-D direction will be transmitted through a RT that is destined for LSR-D whereas the D-A traffic will be in some other RT that is destined for LSR-A.
> Only Link OAM being considered, what makes steering more challenging
yw>> It should also be noted that this is a physical Link OAM not a MPLS logical link OAM.  I also think that the mechanism that is being suggested for passing the switching information up to the MPLS level should be expanded upon and possibly defined in MPLS (or referenced if already defined).
> No mention that Link or Node protection in wrapping has to be pre-determined
> Hard to identify advantages of this approach when comparing with solutions described in draft-weingarten-mpls-tp-ring-protection-06 protection of p2p bi-directional LSP.
>
> Regards,
>         Greg
>
>
>
> [email-masked]<mailto:[email-masked]>

---

From: weiqiang cheng <[email-masked]>
Date: Tue, 13 Nov 2012 16:53:46 +0800

Hi Greg and Yaakov,

Thanks a lot for your comments. Here is clarification for your
concerns on the Ring Tunnel:
Ring Tunnel is a implementation mechanism within the local ring to
minimize recovery elements, OAM sessions, Labels used, and management
transactions as described in RFC5654. There is no change to the LSPs
entering the ring, and they are still P2P or P2MP. In another words,
it is working only in the ring for P2P and P2MP path. So it is OK for
MPLS-TP.

B.R.
Weiqiang Cheng

2012/11/9 Gregory Mirsky <[email-masked]>:
> Hi Yaakov,
> many thanks for your detailed comments. I think that if a Ring Tunnel
> presents mp2p construct then it unlikely can be part of solution for a
> MPLS-TP networks as it's operation is based on merging traffic flows. Would
> you agree?
>
>     Regards,
>         Greg
>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [mpls] Comments on
> draft-cheng-mpls-tp-shared-ring-protection-00
>
> Greg, hi
>
> I am not sure that I agree with all of your comments (see below), although I
> would love to agree with your conclusion;)
>
> BR,
> yaacov
> its destination - so this makes it a mp2p tunnel where traffic may enter the
> tunnel at any LSR in the ring and exit at the endpoint.
>
>> Hard to identify advantages of this approach when comparing with solutions
>> described in draft-weingarten-mpls-tp-ring-protection-06 protection of p2p
>> bi-directional LSP.
>>
>> Regards,
>>         Greg
>>
>>
>>