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

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 (mpls@ietf.org)

    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 (mpls@ietf.org)

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

/Loa
mpls wg co-chair

On 2016-02-24 23:02, 류정동 wrote:
> 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
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>