Requirements for Advanced Multipath in MPLS Networks
Note: This ballot was opened for revision 15 and is now closed.
(Stewart Bryant) Yes
(Adrian Farrel) (was Discuss) Yes
Comment (2014-02-06 for -15)
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.
(Jari Arkko) No Objection
(Richard Barnes) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
Comment (2014-02-06 for -15)
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
Spencer Dawkins No Objection
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
(Barry Leiba) No Objection
Comment (2014-02-05 for -15)
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.