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

From: Stewart Bryant <[email-masked]>
Date: Thu, 3 Mar 2016 14:43:14 +0000

I was also selected as an MPLS Review team reviewer.

The document is well written and should be adopted by the WG.

As part of the WG process there needs to be independent confirmation
that if put into an arbitrary state, the state machine unconditionally
migrates to the correct state, and hence that the state machine is
unconditionally correct. That way we can be sure that no further
changes will be needed to address "all problematic changes@

- Stewart

Stewart

On 22/02/2016 11:41, Bocci, Matthew (Nokia - GB) wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Fri, 4 Mar 2016 10:38:11 +0800

Authors,

We have enough mpls-rt reviews in now. Could you please check if there
is anything that you want to change in the draft, before starting the
working group document adoption poll.

/Loa

---

From: "Ryoo, Jeong-dong " <[email-masked]>
Date: Fri, 4 Mar 2016 04:55:20 +0000

Loa,

I just uploaded a revision (-03), which reflects the editorial comments from Matthew.

We don't have any more to change before the poll.

Best regards,

Jeong-dong

________________________________
보낸 사람 : "Loa Andersson" <[email-masked]>
보낸 날짜 : 2016-03-04 11:38:35 ( +09:00 )
받는 사람 : Stewart Bryant <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
참조 : [email-masked] <[email-masked]>
제목 : Re: [mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

Authors,

/Loa

>> RFC7271 is before progressing this work, since spending working group

>> time

>> [RFC7271 ].

>> MB> It is a little unclear if this is adding a new INIT state to the

>> state

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 31 Mar 2016 13:07:55 +0200

Authors,

I have been selected as an MPLS Review Team reviewer for

draft-saad-mpls-static-yang-02

Before adopting this draft as a WG draft I suggest to
resolve/discuss

the following comments:

In general I think this draft should be split into two separate
documents.

One for describing the MPLS base YANG module, and

one for describing the MPLS Static LSP module.

The latter augments the former, and the authors expect that there
will

be more documents that augment the first.

(they even provide examples in the Abstract and section 2 of this
draft)

The text in Section 1. Introduction needs more words than just "

AAA".

I think that the remainder of the draft looks technically sound.

Minor nits:

2.

s/proposes/provides/

4.

s/memo/document/

====

Best regards, Huub.