[mpls] 회신: MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

Mattew,

Thank you for your review and comments.

This work of updating RFC 7271 was triggered by
comments raised by people working on three independent 
implementations of RFC 7271.

I am not sure about the IETF and/or MPLS WG process of exposing 
the names of the companies that implement this RFC as it might 
be sensitive to some of those companies. 
But, as far as I know, there are more than ten equipment vendors who
implemented or are implementing RFC 7271 
(or ITU-T Recommentation G.8131, which is in line with 
and has the same technical contents as RFC 7271).

A few weeks ago, a South Korean government owned national backbone 
network started being operated with protection provided by RFC 7271.
Also, we anticipate that major Korean network operators will
use this technology when their packet transport networks are  
expanded or upgraded as they want to run their networks with 
implementations complying with Internation Standards.

Regarding your comment on Section 4.1,
the authors' intention is not to define any new state, like INIT. 
However, we understand that your comment is triggered by the facts
that implementation of the last two bullets (SD and EXER)
may require some internal states.
we consider this is an internal implementation decision 
and outside of the scope of this document. 

For your nits on Section 4.2,
we will incorporate them in revision.  

Again, I appreciate your time and effort to review the draft.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Bocci, Matthew (Nokia - GB) [matthew.bocci@nokia.com] 대신 mpls [mpls-bounces@ietf.org]
보낸 날짜: 2016년 2월 22일 월요일 오후 8:41
받는 사람: draft-ryoo-mpls-tp-aps-updates@tools.ietf.org; mpls-chairs@tools.ietf.org
참조: mpls@ietf.org
제목: [mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

Authors

I have been selected as an MPLS Review team reviewer for
draft-ryoo-mpls-tp-aps-updates-02.txt.

In general, I think the draft is technically sound and it is useful to
provide clarification to sections of RFC7271 if it is the case that this
is actually causing confusion to implementers. However, I would encourage
the working group to think about how widely implemented and deployed
RFC7271 is before progressing this work, since spending working group time
on something that is not being widely implemented does not seem useful.

Minor Comments/Nits
‹‹‹‹‹‹‹‹‹‹‹‹‹‹
4.1
<https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.1>
.  Initialization Behavior

   This section defines initialization behavior that is not described in
   [RFC7271 <https://tools.ietf.org/html/rfc7271>].

MB> It is a little unclear if this is adding a new INIT state to the state
machine that you can transit to from one or more other states, or if this
is just stating initial conditions before APS becomes operational. Please
can you clarify?

4.2
<https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.2>
.  State Transition Modification

   In addition to the initialization behavior described in Section 4.1
<https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.1>
,
   four cells of remote state transition table need to be changed to
   make two end nodes converged after initialization.

MB> s/four cells of remote state/ four cells of the remote state
MB> s/two end nodes converged / two end nodes converge

 Best regards

Matthew

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls