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

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" <loa@pi.nu>
보낸 날짜 : 2016-03-04 11:38:35 ( +09:00 )
받는 사람 : Stewart Bryant <stewart.bryant@gmail.com>, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>, draft-ryoo-mpls-tp-aps-updates@tools.ietf.org <draft-ryoo-mpls-tp-aps-updates@tools.ietf.org>, mpls-chairs@tools.ietf.org <mpls-chairs@tools.ietf.org>
참조 : mpls@ietf.org <mpls@ietf.org>
제목 : Re: [mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

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

On 2016-03-03 22:43, Stewart Bryant wrote:

> 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

>>

>>

>> . Initialization Behavior

>>

>> This section defines initialization behavior that is not described in

>> [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

>>

>>

>> . State Transition Modification

>>

>> In addition to the initialization behavior described in 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