Skip to main content

Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-16

Yes

(Stewart Bryant)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)
(Stephen Farrell)

Note: This ballot was opened for revision 15 and is now closed.

Adrian Farrel Former IESG member
(was Discuss) Yes
Yes (2014-02-06 for -15) Unknown
Updated after discussion with the Editor.

---

I am not going to insist that section 3.2 is removed, but this section seems to me to be out of place in this document. I would be pleased to see it go, but am not exercised by its presence. The reasoning for removing it is that there is nothing here that describes the behaviour of AMGs per se. Instead the text is about how information about links is reported from one layer to another.

---

It would be nice if the concise "Abstract Multipath" definition in the Abstract were copied to the Intro.

---

Andy Malis may want to change his coordinates.
Stewart Bryant Former IESG member
Yes
Yes (for -15) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2014-02-05 for -15) Unknown
Non-blocking comments: please consider them, and chat with me if you like... but no response is required.

-- Section 3.5 --

   FR#22 Load balancing MAY be used during sustained low traffic periods
       to reduce the number of active component links for the purpose of
       power reduction.

I'm very suspicious of "MAY" in requirements -- what does it mean here?  The fact that load balancing is entirely optional doesn't seem like a "requirement".

The same is true of GR#4 in Section 4.
Benoît Claise Former IESG member
No Objection
No Objection (2014-02-06 for -15) Unknown
As I mentioned to Stewart privately, I clicked too fast on "no objection" 2 days ago.

I found this draft not easy to read. I had to re-read a few paragraphs/sentences multiple times

-

   Other
   services will continue to require only that reordering not occur
   within a microflow as is current practice.


The definition speaks of flow, not microflow

-

OLD:
   The intent is to first provide a set
   of functional requirements that are as independent as possible of
   protocol specifications in Section 3.  

NEW:

  The intent is to first provide a set
   of functional requirements, in Section 3, that are as independent as possible of
   protocol specifications

- 
Section 1.1
   The implementation SHOULD in most or all
   cases allow any new functionality to be individually enabled or
   disabled through configuration. 

Isn't a requirement? Shouldn't it have his own REQ number?

- 
   A service provider or other
   deployment MAY enable or disable any feature in their network,
   subject to implementation limitations on sets of features which can
   be disabled.

Not sure what this sentence means. What is the requirement, if any?

- What is the meaning of MAY in requirements, like in FR 22

-
 Composite Link
       The term Composite Link had been a registered trademark of Avici
       Systems, but was abandoned in 2007.  The term composite link is
       now defined by the ITU-T in [ITU-T.G.800].  The ITU-T definition
       includes multipath as defined here, plus inverse multiplexing
       which is explicitly excluded from the definition of multipath.

What don't you define what it is (I can only guess), then add a note about the ITU-T relationship



-
   Client Layer
       A client layer is the one immediately above a server layer.

   Server Layer
       A server layer is the latey immediately below a client layer.

A is left to B, and B is right to A ... still doesn't tell me what A and B are.

-
Inverse Multiplexing
       Inverse multiplexing either transmits whole packets and
       resequences the packets at the receiving end or subdivides
       packets and reassembles the packets at the receiving end.
       Inverse multiplexing requires that all packets be handled by a
       common egress packet processing element and is therefore not
       useful for very high bandwidth applications.

I still don't know what Inverse Multiplexing is

- 
Flow identification.
How does it relate to the flow definition in RFC 7011?

- 
   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

You should really be consistent regarding capitalized terms from the terminology section, throughout the document.
Here, Component Link versus component link

-

   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.

Isn't it obvious?

-
FR#26 If the total demand offered by traffic flows exceeds the
       capacity of the AMG, 

offered or required?

- 
   A delay discontinuity is an isolated event which may greatly exceed
   the normal delay variation (jitter).  A delay discontinuity has the
   following effect.  When a flow is moved from a current link to a
   target link with lower latency, reordering can occur.  When a flow is
   moved from a current link to a target link with a higher latency, a
   time gap can occur.  Some flows (e.g., timing distribution, PW
   circuit emulation) are quite sensitive to these effects.  A delay
   discontinuity can also cause a jitter buffer underrun or overrun
   affecting user experience in real time voice services (causing an
   audible click).  These sensitivities may be specified in a
   Performance Objective.

There is some information on this one in RFC 5481
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -15) Unknown