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

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:mpls-bounces@ietf.org] On Behalf Of Bocci, Matthew
> (Nokia - GB)
> Sent: Monday, February 22, 2016 6:42 AM
> To: draft-ryoo-mpls-tp-aps-updates@tools.ietf.org; mpls-
> chairs@tools.ietf.org
> Cc: mpls@ietf.org
> 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
> 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
> 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
> <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 s/two
> MB> end nodes converged / two end nodes converge
> 
> 
>  Best regards
> 
> Matthew
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls