Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Eric,

Many thanks for thorough review of this document and providing constructive comments. We will go through your comments and update the document once other comments from MPLS-RT team come in.

Thanks!

-Nobo

> -----Original Message-----
> From: Osborne, Eric [mailto:[e-mail]]
> Sent: Thursday, December 04, 2014 10:56 AM
> To: [e-mail]; mpls-
> [e-mail]; VIGOUREUX, MARTIN (MARTIN)
> Cc: [e-mail]
> Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-lag-multipath
> 
> I forgot to cc the list so I'm resending my comments on this draft.
> 
> Here is my review:
> 
> - is the document coherent?
> 	Not really...it needs some serious copyediting.  See the wall of text
> below.  None of my copyedit comments should be considered blockers for
> WG adoption.
> 
> - is it useful?
> 	Very much so.  This mechanism will make troubleshooting easier
> and proactive monitoring much better.
> 
> - is it ready for WG adoption?
> 	Yes.  It needs some cleanup but the technology seems sound.  It's
> certainly mature enough to be adopted by the WG.
> 
> 
> Document comments:
> 
> This isn't a line-by-line critique and I'm not a terribly good Real Editor(tm)
> anyways so I've tried to keep these comments general and constructive.
> 
> General: the document needs an infusion of pronouns and definite articles.
> Things like "Result raises a limitation" (sec. 1.2) should be "The result
> raises.." or 'This result raises...'.  I've called out some of the places where
> this needs to happen, but not all of them.
> 
> Section 1.1: s/terminologies/terms/
> 
> Section 1.2: the first paragraph needs a rewrite, it's messy.  Also, the bullet
> points that end in '...is [succeeding|failing]' should be '...have
> [succeeded|failed]'.  And 'With above scenario' needs to be 'With the above
> scenario' or something.
> 
> Sections 3-5: These sections could use a reorg.  Starting with procedures for
> using new TLVs before defining the new TLVs feels awkward.  I suggest
> taking sections [3,4,5] and reordering as [5,3,4].
> 
> Section 3: This section needs a little introduction.  Something like "This
> section describes the handling of the new TLVs by nodes which understand
> them.  There are two cases - nodes which understand the TLVs but which for
> some reason cannot describe LAG members separately, and nodes which
> both understand the new TLVs and are able to describe LAG members
> separately".
> 
> Section 3.2: " The responder LSRs that understands the LAG Interface Info
> TLV and
>    are able to describe outgoing LAG member links separately are to use
>    the follow procedures"
> needs some singular/plural cleanup:
> " A responder LSR that understands the LAG Interface Info TLV and
>    is able to describe outgoing LAG member links separately uses
>    the follow procedures"
> or something like that.
> 
> Section 3.3: "Above procedures..." -> "The procedures above..."
> 
> Section 4.2: Same kind of cleanup as 3.2: "Responder LSRs that
> understands.." -> "Responder LSRs which understand..."
> 
> Section 4.3: "described procedures in this section" -> "the procedures
> described in this section"
> 
> Section 4.3: "following checks" -> "the following checks".  Also, the error
> case is a little confusing.  The first half of the error case is actually a success,
> and I spent some time going back and forth between the first half of the
> success case and the failure case to figure out whether they were different.
> It would benefit from some clarifying text, perhaps something like "An error
> case is any case where the OAM across a LAG fails, either partial or fully.  A
> partial failure is where some LAG member traversals behave as they should
> and some don't, and a full failure is where no LAG member traversals
> behave as they should".
> 
> Sections 5-8: no comments on the TLVs themselves, I don't know OAM well
> enough to find any hidden mines here.  This is for the WG to pore over.
> 
> Section 9: "As result of" -> "as a result of".  Also, "additional processing are
> required" -> "additional processing is required"
> 
> Section 11: "Authors" -> "The authors".
> 
> Appendix A: I get that this section is intended to list out problems that
> aren't solved by the mechanisms in this document.  It's probably worth
> adding text in Section 2 that describes the limitations of the proposed
> mechanism, something like "Most[*] LAGs are built from p2p links, and thus
> router X and router X+1 have the same number of LAG members.  It is
> possible to build LAGs asymmetrically by using Ethernet switches in the
> middle.  Appendix A lists some cases which this document does not
> address; if an operator deploys LAGs in a manner similar to what's shown in
> Appendix A, the mechanisms in this document may not suit them".  I know
> Section 2 has a bullet at the end that hints at this, but I think it should be
> more explicit.
> 
> 
> [*]  I believe this to be true.  I am willing to be wrong.  It has happened
> before.
> 
> 
> 
> 
> 
> 
> eric