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

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Mon, 22 Feb 2016 11:41:36 +0000

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

---

From: 류정동 <[email-masked]>
Date: Wed, 24 Feb 2016 15:02:29 +0000

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) [[email-masked]] 대신 mpls [[email-masked]]
보낸 날짜: 2016년 2월 22일 월요일 오후 8:41
받는 사람: [email-masked]; [email-masked]
참조: [email-masked]
제목: [mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

Authors

Minor Comments/Nits
‹‹‹‹‹‹‹‹‹‹‹‹‹‹
4.1

4.2

 Best regards

Matthew

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Thu, 25 Feb 2016 11:41:32 +0800

Working Group, Jeong-dong,

IETF encourage implementers of, and operators that deploy, solutions
specified in IETF RFCs and IDs to share this information. Normally we
request this information just prior to the publication request, but no
harm in receiving it earlier. We except this information to come from
the vendors implementing the  specification or the operators deploying
it.

Since this was brought up in the MPLS-RT review, we think it is
appropriate do do an early implementation poll.

    If you have or plan an implementation of RFC 7271 and the updates
    specified in draft-ryoo-mpls-tp-aps-updates could you please share
    this on the mpls wg mailing list ([email-masked]).

    If you have or plan deployment of RFC 7271 and the updates specified
    in draft-ryoo-mpls-tp-aps-updates could you please share this on the
    mpls wg mailing list ([email-masked]).

    If you have special reasons this information may be sent to the mpls
    working group chairs directly.

/Loa
mpls wg co-chair

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 25 Feb 2016 10:42:18 +0000

I too have finished my review of this draft.  Like Matthew, I find the document is sound; I didn't go through all the states, but the document presents its case well.  I'm conflicted on the question of further progression of the draft -- on the one hand, it is wasteful to put more time into fixing something which may  not have much deployment, but on the other, it is worse to leave a protocol out there that's known not to work in some cases.

My two cents - this draft should be progressed to fix the state machine cases, and then that should be it for TP.  Any new features should be strongly weighed against market adoption.  And no, "lack of behavior $FOO" is not a bug fix.

eric

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Bocci, Matthew
> (Nokia - GB)
> Sent: Monday, February 22, 2016 6:42 AM
> To: [email-masked]; mpls-
> [email-masked]
> Cc: [email-masked]
> Subject: [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
> <<<<<<<<<<<<<<
> MB> It is a little unclear if this is adding a new INIT state to the
> MB> 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
> MB> s/four cells of remote state/ four cells of the remote state s/two
> MB> end nodes converged / two end nodes converge
> 
> 
>  Best regards
> 
> Matthew
> 
>

---

From: GENG Liang <[email-masked]>
Date: Thu, 25 Feb 2016 15:24:58 +0000

Dear all,

In China Mobile, we currently do not have devices with implementation of RFC7271 in existing network. 

However, we do plan to make deployment given that vendor could provide reliable implementation with proven inter-operation capability with the existing devices.

Best wishes,
Liang

________________________________________
发件人: mpls <[email-masked]> 代表 Loa Andersson <[email-masked]>
发送时间: 2016年2月25日 3:41
收件人: 류정동; Bocci, Matthew (Nokia - GB); [email-masked]; [email-masked]
抄送: [email-masked]
主题: [mpls] Early implementation poll -- Re:  회신: MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

/Loa
mpls wg co-chair