Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

[Rui Costa <[e-mail]>]

Thanks for your time, Yaacov.

G.841, which describes SDH's protection mechanisms, reused in G.8131.1 and G.8132.1 (and G.8031, and 2007's G.8131/G.8132), was published for the 1st time in 1995 (http://www.itu.int/rec/T-REC-G.841/en).

Hope (and am sure) you'll quickly find what you look for.

Regards,
Rui

From: Yaacov Weingarten [mailto:[e-mail]]
Sent: segunda-feira, 29 de Outubro de 2012 09:03
To: Rui Costa
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext D'Alessandro Alessandro Gerardo; [e-mail]; [e-mail]; MPLS-TP ad hoc team; [e-mail]
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Rui, hi

Thank you for your comments to this WGLC, I will try to answer some of your comments that deal directly with my aspect of the draft in question and leave your other comments for those that are more qualified.  See inline below.

Hope this helps,
yaacov weingarten

Still looking for new opportunity.
On Wed, Oct 3, 2012 at 6:09 PM, Rui Costa <[e-mail]<mailto:[e-mail]>> wrote:
Hello,

1. RFC1958 states "If a previous design, in the Internet context or elsewhere, has successfully solved the same problem [...]".
yw>>  Not sure what you are driving at - the question whether protection schemes that were designed for the physical layer, where rings are prevalent, is applicable to the logical layer of MPLS may need to be examined further.  However, this document merely states that it is possible to address the protection by applying an existing design to the domain.

2. This draft looks quite different from G.841's sections about rings (or G.8132.1 draft), IMHO. If there's a problem with the liaison accessibility, perhaps the expired comparison http://tools.ietf.org/html/draft-yang-mpls-tp-ring-protection-analysis helps.
yw>>  This is very true and it was not a goal of the authors to adhere to either G.841 nor G.8132.1 (except in the description of the Wrapping and Steering mechanisms).  I find the comparison presented in the referenced draft as very helpful and I notice that there are several instances in which this comparison has come to different conclusions from those listed in the LS from ITU-T SG15 (in particular in the categories of Simplicity, Resource use, and Configuration), but I am not sure why this is relevant to the draft in question.

3. Could the authors explain, remembering the RFC1958 quote above ("Internet context or ELSEWHERE"), what's the benefit of this draft versus existing G.841 (Jul/1995)/G.8132.1 draft/draft-helvoort-mpls-tp-ring-protection-switching?
yw>>  As mentioned above, this is merely an applicability statement that says that many of the issues in ring protection can be addressed by use of the existing Linear Protection mechanism.  In addition, it is very unclear how the two mechanisms that you mention (one is a physical layer mechanism, the other is a draft that was discussed [under a different name and author] in WG) really can be applied to MPLS without introducing new constructs to MPLS whose definition and technology would need to precede the work on these mechanisms.  In particular (just one example that needs to be examined more closely), there is a claim that running OAM on a segment LSP can notify all other LSPs that traverse a particular LSR  that they must reroute their traffic without a real MPLS description of how this is done.  While this is very understandable in an Ethernet environment that works at the  MAC address level, it is unclear how this is applied to MPLS label, without causing layer violations.

4. What is the benefit of RFC6378 (Feb2012) versus existing G.841(Jul/1995)/G.8131.1 draft (again, remembering RFC1958...)? What new brings PSC versus APS?
yw>> I believe that this was a WGLC on a different document

5. Why did we approve RFC6670, essentially saying "1 standard's better than 2", but create 2 completely new protection standards, alternate to options architecturally similar to those we have in the field for almost 20years?
yw>> Again I believe that this was a WGLC on a different document.  But it is interesting that you have a mechanism in the field for almost 20 years for a technology that is only 13 years old!!  I do believe that new technologies call for a reexamination of tools that we have in the field rather than the other way around.

6. Why isn't the intersection of the authors of this draft, RFCs 6378 and 6670, the empty set?
yw>> Again this was a WGLC on a different document.

Regards,
Rui

Thanx and BR,
yaacov

Still looking for new opportunity