(resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13

[Curtis Villamizar <[e-mail]>]

Lou et al,

Resending.  I'm not sure if the original (sent Tue, 17 Dec 2013) went
through to all recipients. There may have been a problem (due to a
self inflicted DNS issue).

I did not get a response so I suspect Lou didn't get this email.

Curtis


In message <[e-mail]>
Lou Berger writes:
>
> Hello,
>  
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review. The purpose
> of the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
>  
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>  
> Document: draft-ietf-rtgwg-cl-requirement-13.txt
> Reviewer: Lou Berger
> Review Date: 2013-12-11
> IETF LC End Date: 2013-12-09
> Intended Status: Informational
>  
> Summary:
>  
>         I have some minor concerns about this document that I think
> should be resolved before publication.
>  
> Comments:
>  
>     I think the document is greatly improved since the previous last
> call.  I have some comments and reservations on the document that are
> described below.  As discussed on the list, I remain concerned about the
> value of defining requirements in terms of nebulous "Performance
> Objectives", but as this is acceptable to the WG I will not elaborate on
> this concern further.
>  
> Major Issues:
>  
>    No major issues found.
>  
> Minor Issues:
>  
> 1. Terminology & consistency: the document coins the term "Advanced
> Multipath":
>        Advanced Multipath is a formalization of multipath techniques
>  
> Do you see this term as a new noun, like LSP, or as an adjective?  I
> expected the latter, i.e. that it be used like "multipath" is used in
> the above sentence, but it seems to be used as a new noun.  I'm not sure
> coining a new noun really makes sense, but if this the intent then the
> last paragraph of section 2 needs to be revised as "Advanced Multipath"
> will now have a specific definition as opposed to a generic term. Also I
> suggest always capitalizing it (or even using the abbreviation "AM")
> will clarify this distinction.

I see multipath as a noun and therefore advanced multipath as a noun.
Advanced is an adjective, multipath as a noun.  Advanced Multipath is
the set of techniques that form a solution.  An advanced multipath is
a collection of componet links.  The former is capitalized, the latter
is not.  I'll check to see if I got that right in all occurances.  If
you would like I can also add this to the definition making it:

 OLD

   Advanced Multipath
       Advanced Multipath meets the requirements defined in this
       document.  A key capability of advanced multipath is the support
       of non-homogeneous component links.

 NEW

   Advanced Multipath
       Advanced Multipath is a formalization of multipath techniques
       that meets the requirements defined in this document.  A key
       capability of Advanced Multipath is the support of
       non-homogeneous component links.  An "advanced multipath" is a
       collection of component links.  In this document the former is
       capitalized and the latter is not.

If we agree on this I'll just search for "advanced" and make
capitalization consistent with the above statements.

I don't think the phrase "advanced multipath technique" makes it an
adjective any more than a statement such as make-before-break is an
MPLS technique" makes MPLS an adjective in normal use.  The phrase "an
X technique" is simply a shorthand for indicating a "technique
applicable to X".  Even if that makes it an adjective the phrase "MPLS
technique" is common and so that should not be a problem.  The
paragraph in question might be the following.  It seems benign to me.

   The term Advanced Multipath is intended to be used within the context
   of this document and the related documents,
   [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and
   any other related document.  Other advanced multipath techniques may
   in the future arise.  If the capabilities defined in this document
   become commonplace, they would no longer be considered "advanced".
   Use of the term "advanced multipath" outside this document, if
   referring to the term as defined here, should indicate Advanced
   Multipath as defined by this document, citing the current document
   name.  If using another definition of "advanced multipath", documents
   may optionally clarify that they are not using the term "advanced
   multipath" as defined by this document if clarification is deemed
   helpful.

I see no problem with this.  Please be more specific if you think
there are places where advanced multipath is used as an adjective or
where its use is confusing.

> 2. Editorial: server and client layer vs upper and lower layer.
>  
> The document uses server and client layer networks and LSPs and,
> sometimes interchangeably or redundantly, upper and lower layer networks
> and LSPs.  I think this issue can be resolved by avoiding the term
> client/server when referring to network layers and just using the
> lower/upper terminology.  The one exception to this is in the definition
> Client LSP which should simply be defined in the context of a multipath,
> i.e.:
> OLD
> A client LSP is an LSP which has been set up over a server layer.
> NEW
> A client LSP is an LSP which has been set up over Advanced Multipath.

A client LSP can be set up over a server layer MPLS-TP LSP or any
server layer MPLS LSP or over a link layer or over a pseudowire ... or
over an advanced multipath.

> I think this also means that usage of the term "Client" is limited to
> "Client LSP".

I searched for all occurances of the word client.  All occurances are
"client LSP" excexpt the phrase "client of a client LSP" and that is
used only in the following paragraph.

   The ingress and egress of a multipath may be midpoint LSRs with
   respect to a given client LSP.  A midpoint LSR does not participate
   in the signaling of any clients of the client LSP.  Therefore, in
   general, multipath endpoints cannot determine requirements of clients
   of a client LSP through participation in the signaling of the clients
   of the client LSP.

THe point is that "A midpoint LSR does not participate in the
signaling of any clients of the client LSP" and that non-participation
in client (or higher layer) signaling applies to any "client of a
client LSP", not just other LSP running over it.

I then searched for all occurances of the words upper and lower and
higher.  There are no occurances of "upper".

There were a few occurances of "lower latency" and "higher latency".
Other than that, all occurances of lower and higher except one are in
the follwoing text:

 3.2.  Component Links Provided by Lower Layer Networks

   A component link may be supported by a lower layer network.  For
   example, the lower layer may be a circuit switched network or another
   MPLS network (e.g., MPLS-TP)).  The lower layer network may change
   the latency (and/or other performance parameters) seen by the client
   layer.  Currently, there is no protocol for the lower layer network
   to inform the higher layer network of a change in a performance
   parameter.  Communication of the latency performance parameter is a
   very important requirement.  Communication of other performance
   parameters (e.g., delay variation) is desirable.

   FR#8  The solution SHALL specify a protocol means to allow a lower
       layer server network to communicate latency to the higher layer
       client network.

The exception is this sentence:

     FR#22 The solution SHOULD support the use case where an advanced
       multipath itself is a component link for a higher order advanced
       multipath.  For example, an advanced multipath comprised of MPLS-
       TP bi-directional tunnels viewed as logical links could then be
       used as a component link in yet another advanced multipath that
       connects MPLS routers.

The terms lower layer and higher layer go all the way back to the ISO
seven layer model of ancient times (1970s?, 1980s?) and maybe further
back but that is before even my time.

I don't think this is unclear but I could add the following in
definitions:

   Higher Layers
      A client layer is the one immediately above a server layer.  The
      client layer and all layers above that layer are higher layers.

   Lower Layers
      A server layer is the later immediately below a client laer.
      The server layer and all layers below are lower layers.

Do I really need to put this in the definitions section?  If yoy think
it is necessary, I will add it.

> 3. Technical: The document should make it clear that LSPs can provide
> paths from an Advanced Multipath.  I suggest adding something like the
> the following at the end of page 3
>    d. a lower layer LSP.

Case "b." is intended to include LSP but is not specifically limited
to LSP.  Multipath (not Advanced Multipath) includes IGP ECMP,
Ethernet Link Aggregation, and all sorts of things that don't involve
MPLS at all.  For example, a path in Ethernet Link Aggregation Group
(LAG) could be supported by a pseudowires or ODU2e or GFP-F, though
this would be unknown to the LAG, or in the simplest case each path in
the set of LAG members could be supported by a plain Ethernet cable.

> and at the end of the Component Link definition:
>    A component link may be provided via an LSP.

I think this is covered in "3.2.  Component Links Provided by Lower
Layer Networks".

 3.2.  Component Links Provided by Lower Layer Networks

   A component link may be supported by a lower layer network.  For
   example, the lower layer may be a circuit switched network or another
   MPLS network (e.g., MPLS-TP)).

This sort of statement could be made earlier.  For example in the
discussion following the definitions (on page 5) the document covers
one case (where a component link is not an LSP) but it is not until
later that the other case is mentioned.

I could add a paragraph in the discussion following the definitions
that mentions that a component link can also be another LSP.

 OLD:

   A Component Link may be a point-to-point physical link (where a
   "physical link" includes one or more link layer plus a physical
   layer) or a logical link that preserves ordering in the steady state.
   A component link may have transient out of order events, but such
   events must not exceed the network's Performance Objectives.  For
   example, a component link may be comprised of any supportable
   combination of link layers over a physical layer or over logical sub-
   layers, including those providing physical layer emulation.

 NEW:

   A Component Link may be a point-to-point physical link (where a
   "physical link" includes one or more link layer plus a physical
   layer) or a logical link that preserves ordering in the steady state.
   A component link may have transient out of order events, but such
   events must not exceed the network's Performance Objectives.  For
   example, a component link may be comprised of any supportable
   combination of link layers over a physical layer or over logical sub-
   layers, including those providing physical layer emulation, or over
    MPLS server layer LSP.

These are identical except the phrase ", or over MPLS server layer
LSP" added to the end of the last sentence.

> 4. Editorial: Unless I'm mistaken, the requirements in this document
> apply to the Advanced Multipath solution.  In most cases the document
> states requirements in the form of "The solution", but in a few cases it
> just says "advanced multipath".  I think these cases should be changed
> to apply to an "Advanced Multipath solution".  I think this comment
> applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9.

That is not correct.  For example:

   FR#1  An advanced multipath MAY be announced in conjunction with
       detailed parameters about its component links, such as bandwidth
       and latency.  The advanced multipath SHALL behave as a single IGP
       adjacency.

In this requirement the "advanced multipath" is a specific collection
of component links that is announced by way of an MPLS Forwarding
Adjaccency (FA) in the IGP.  The same is true for the other
requirements cited.  In all of these cases an advanced multipath is a
specific collection of component links.  There is a typo in MR#1.

 OLD

   MR#1  Management Plane MUST support polling of the status and
       configuration of an advanced multipath and its individual
       advanced multipath and support notification of status change.

 NEW

   MR#1  Management Plane MUST support polling of the status and
       configuration of an advanced multipath and its individual
       component links and support notification of status change.

In the last line
s/advanced multipath/component links/

> 5. Technical: use of "indicate" in FR10-13, FR14, FR15:
> In these cases it is unclear if the requirements apply to
> (a) a client's ability to indicate a desired service/LSP constraint or
> (b) a selected component link's attribute that will be used by a client
> LSP,
> (c) both, or
> (d) something completely different
> The requirements should be clear to which entity the requirement applies.

This "indication" can be through signaling or the management plane and
both must be supported in later framework and protocol definitions and
we can argue then whether both must be supported or if one or the
other is a "should" in RFC 2119 speak.

There was concern that the word "signal" would exclude providing the
same informantion through the management plane and therefore the word
"indicate" is used.

Rather than spell this out many times we hoped this would be clear.  I
could add clarifying text up front if you think this is necessary.  For
example, I could add the following before FR#1.

   FR#0  In requirements that follow in this document the word
      "indicate" is used where information may be provided by either
      the combination of link state IGP advertisement and MPLS LSP
      signaling or via management plane protocols.  In later documents
      providing framework and protocol definitions both signaling and
      management plane mechanisms MUST be defined.

It would be trivial to make this FR#1 and renumber the rest.

Should I add it and renumber?

> 6. The last paragraph in section 3.3. strikes me as both odd and out of
> place.  There are so many possible decisions that must be considered by
> network operators relative to disruption and optimization.  Why mention
> just "power reduction"?  Is there something special about the
> interactions of multipath and power reduction?  What value / information
> does this paragraph add?

The last paragraph in section 3.3 is:

   Allowing multipath to contain component links with different
   characteristics can improve the overall load balance and can be
   accomplished while still accommodating the more strict requirements
   of a subset of client LSP.

I'm not sure if this is the "odd and out of place" paragraph you refer
to.  It summarizes the purpose of the requirements in this section.  I
think you mean section 3.5 and not 3.3.

The remainder of your paragraph above discusses power reducetion and
this is only mentioned in section 3.5 so I think you mean this
paragraph.

   As with any load balancing change, a change initiated for the purpose
   of power reduction may be minimally disruptive.  Typically the
   disruption is limited to a change in delay characteristics and the
   potential for a very brief period with traffic reordering.  The
   network operator when configuring a network for power reduction
   should weigh the benefit of power reduction against the disadvantage
   of a minimal disruption.

The paragraphs following a set of requirements provide discussion
related to that set of requirements.  I don't see this as out of
place.  The prior two paragraphs discuss delay discontinuity.  This
paragraph is a reminder that "As with any load balancing change, a
change initiated for the purpose of power reduction may be minimally
disruptive."  I don't see this as out of place.

For example, to compensate for a less than perfect load balance a
subset of LSPs may need to be moved and that subset can be chosen from
those which will be least affected (and there are plenty of
requirements that compell the fussy LSP to tell the network abour
their specifial needs).  To power down a component link, *all* LSP on
that component link need to be moved, even the very fussy ones.
Therefore I think mentioning that disruption should be considered is
not out of place in the discussion following these requirements.  We
like to keep the discussion brief so this level of detail was not
included.

> 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS?

At the very least it means something similar to same administrative
domain.  An AS can be subdivided within an organization.  Do you have
a better way to define intra-domain and inter-domain without going
down the rat hole of defining the term "domain"?  No on in the WG had
an issue with this so far but I'm open for a suggestion for better
wording.

> Nits:
>  
> - References should be provided in all cases when referring to
>   "existing ... techniques"

References are not allowed in the abstract.  In section 3.3 is the sentence:

   Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a
   description of existing techniques and a set of references.

Much of that document is dedicated to describing existing techniques
and it contains quite a few references.

I can move this sentence.  Where in the document would you like to see
it moved to?

> Using line numbers from
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt

Using line number is a text editor counts the page headers.  What tool
are you using?  I didn't see anything on tools.ietf.org.

So I'll guess.  Looks like add 10 lines per page.

> Line 112
> s/SHOULD/should

s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/

Also remove stray comma.

> Line 118
> s/MAY/may

s/deployment MAY choose to/deployment may choose to/

OK.  Could go either way but s/MAY chose to/MAY/ would work too.

> Line 149, match intro:
> s/Advanced Multipath meets/Advanced Multipath is a formalization of
> multipath techniques that meet

OK.

> Lines 251-254, beginning with "The" through the end of the paragraph.
> This should be an FR.

Looks like you mean this:

   The transient period between some service disrupting
   event and the convergence of the routing and/or signaling protocols
   MUST occur within a time frame specified by Performance Objective
   values.

OK.  I'll add this as FR#6++.

> That's it,
> Lou

There are a few suggestions for changes to the text based on your
comments and a few questions for you.  Based on your response to this
email I will edit the document.

Thanks for the thorough review.

Curtis

- --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com--


------- End of Forwarded Message