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

[Yaacov Weingarten <[e-mail]>]

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]> 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-analysishelps.
>
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*