< draft-ietf-rtgwg-cl-requirement-12.txt   draft-ietf-rtgwg-cl-requirement-13.txt >
RTGWG C. Villamizar, Ed. RTGWG C. Villamizar, Ed.
Internet-Draft OCCNC, LLC Internet-Draft OCCNC, LLC
Intended status: Informational D. McDysan, Ed. Intended status: Informational D. McDysan, Ed.
Expires: April 12, 2014 Verizon Expires: May 17, 2014 Verizon
S. Ning S. Ning
Tata Communications Tata Communications
A. Malis A. Malis
Verizon Consultant
L. Yong L. Yong
Huawei USA Huawei USA
October 9, 2013 November 13, 2013
Requirements for Advanced Multipath in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-12 draft-ietf-rtgwg-cl-requirement-13
Abstract Abstract
This document provides a set of requirements for Advanced Multipath This document provides a set of requirements for Advanced Multipath
in MPLS Networks. in MPLS Networks.
Advanced Multipath is a formalization of multipath techniques Advanced Multipath is a formalization of multipath techniques
currently in use in IP and MPLS networks and a set of extensions to currently in use in IP and MPLS networks and a set of extensions to
existing multipath techniques. existing multipath techniques.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2014. This Internet-Draft will expire on May 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability and Transient Response . . . . . . 6 3.1. Availability, Stability and Transient Response . . . . . 6
3.2. Component Links Provided by Lower Layer Networks . . . . . 7 3.2. Component Links Provided by Lower Layer Networks 7
3.3. Component Links with Different Characteristics . . . . . . 8 3.3. Component Links with Different Characteristics . . . . . 7
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9 3.4. Considerations for Bidirectional Client LSP . . . . . . . 8
3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 10 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 9
4. General Requirements for Protocol Solutions . . . . . . . . . 11 4. General Requirements for Protocol Solutions . . . . . . . . . 11
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13 5. Management Requirements . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
There is often a need to provide large aggregates of bandwidth that There is often a need to provide large aggregates of bandwidth that
are best provided using parallel links between routers or carrying are best provided using parallel links between routers or carrying
traffic over multiple MPLS LSP. In core networks there is often no traffic over multiple MPLS LSP. In core networks there is often no
alternative since the aggregate capacities of core networks today far alternative since the aggregate capacities of core networks today far
exceed the capacity of a single physical link or single packet exceed the capacity of a single physical link or single packet
processing element. processing element.
skipping to change at page 6, line 41 skipping to change at page 6, line 20
3.1. Availability, Stability and Transient Response 3.1. Availability, Stability and Transient Response
Limiting the period of unavailability in response to failures or Limiting the period of unavailability in response to failures or
transient events is extremely important as well as maintaining transient events is extremely important as well as maintaining
stability. The transient period between some service disrupting stability. The transient period between some service disrupting
event and the convergence of the routing and/or signaling protocols event and the convergence of the routing and/or signaling protocols
MUST occur within a time frame specified by Performance Objective MUST occur within a time frame specified by Performance Objective
values. values.
FR#1 An advanced multipath MAY be announced in conjunction with FR#1 An advanced multipath MAY be announced in conjunction with
detailed parameters about its component links, such as detailed parameters about its component links, such as bandwidth
bandwidth and latency. The advanced multipath SHALL behave as and latency. The advanced multipath SHALL behave as a single IGP
a single IGP adjacency. adjacency.
FR#2 The solution SHALL provide a means to summarize some routing FR#2 The solution SHALL provide a means to summarize some routing
advertisements regarding the characteristics of an advanced advertisements regarding the characteristics of an advanced
multipath such that the updated protocol mechanisms maintain multipath such that the updated protocol mechanisms maintain
convergence times within the timeframe needed to meet or not convergence times within the timeframe needed to meet or not
significantly exceed existing Performance Objective for significantly exceed existing Performance Objective for
convergence on the same network or convergence on a network convergence on the same network or convergence on a network with
with a similar topology. a similar topology.
FR#3 The solution SHALL ensure that restoration operations happen FR#3 The solution SHALL ensure that restoration operations happen
within the timeframe needed to meet existing Performance within the timeframe needed to meet existing Performance
Objective for restoration time on the same network or Objective for restoration time on the same network or restoration
restoration time on a network with a similar topology. time on a network with a similar topology.
FR#4 The solution shall provide a mechanism to select a set of paths FR#4 The solution shall provide a mechanism to select a set of paths
for an LSP across a network in such a way that flows within the for an LSP across a network in such a way that flows within the
LSP are distributed across the set of paths while meeting all LSP are distributed across the set of paths while meeting all of
of the other requirements stated above. The solution SHOULD the other requirements stated above. The solution SHOULD work in
work in a manner similar to existing multipath techniques a manner similar to existing multipath techniques except as
except as necessary to accommodate advanced multipath necessary to accommodate advanced multipath requirements.
requirements.
FR#5 If extensions to existing protocols are specified and/or new FR#5 If extensions to existing protocols are specified and/or new
protocols are defined, then the solution SHOULD provide a means protocols are defined, then the solution SHOULD provide a means
for a network operator to migrate an existing deployment in a for a network operator to migrate an existing deployment in a
minimally disruptive manner. minimally disruptive manner.
FR#6 Any load balancing solutions MUST NOT oscillate. Some change FR#6 Any load balancing solutions MUST NOT oscillate. Some change
in path MAY occur. The solution MUST ensure that path in path MAY occur. The solution MUST ensure that path stability
stability and traffic reordering continue to meet Performance and traffic reordering continue to meet Performance Objective on
Objective on the same network or on a network with a similar the same network or on a network with a similar topology. Since
topology. Since oscillation may cause reordering, there MUST oscillation may cause reordering, there MUST be means to control
be means to control the frequency of changing the component the frequency of changing the component link over which a flow is
link over which a flow is placed. placed.
FR#7 Management and diagnostic protocols MUST be able to operate FR#7 Management and diagnostic protocols MUST be able to operate
over advanced multipaths. over advanced multipaths.
Existing scaling techniques used in MPLS networks apply to MPLS Existing scaling techniques used in MPLS networks apply to MPLS
networks which support Advanced Multipaths. Scalability and networks which support Advanced Multipaths. Scalability and
stability are covered in more detail in stability are covered in more detail in
[I-D.ietf-rtgwg-cl-framework]. [I-D.ietf-rtgwg-cl-framework].
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 A component link may be supported by a lower layer network. For
example, the lower layer may be a circuit switched network or another example, the lower layer may be a circuit switched network or another
MPLS network (e.g., MPLS-TP)). The lower layer network may change MPLS network (e.g., MPLS-TP)). The lower layer network may change
the latency (and/or other performance parameters) seen by the client the latency (and/or other performance parameters) seen by the client
layer. Currently, there is no protocol for the lower layer network layer. Currently, there is no protocol for the lower layer network
to inform the higher layer network of a change in a performance to inform the higher layer network of a change in a performance
parameter. Communication of the latency performance parameter is a parameter. Communication of the latency performance parameter is a
very important requirement. Communication of other performance very important requirement. Communication of other performance
parameters (e.g., delay variation) is desirable. parameters (e.g., delay variation) is desirable.
FR#8 The solution SHALL specify a protocol means to allow a lower FR#8 The solution SHALL specify a protocol means to allow a lower
layer server network to communicate latency to the higher layer layer server network to communicate latency to the higher layer
client network. client network.
FR#9 The precision of latency reporting SHOULD be configurable. A FR#9 The precision of latency reporting SHOULD be configurable. A
reasonable default SHOULD be provided. Implementations SHOULD reasonable default SHOULD be provided. Implementations SHOULD
support precision of at least 10% of the one way latencies for support precision of at least 10% of the one way latencies for
latency of 1 msec or more. latency of 1 msec or more.
The intent is to measure the predominant latency in uncongested The intent is to measure the predominant latency in uncongested
service provider networks, where geographic delay dominates and is on service provider networks, where geographic delay dominates and is on
the order of milliseconds or more. The argument for including the order of milliseconds or more. The argument for including
queuing delay is that it reflects the delay experienced by queuing delay is that it reflects the delay experienced by
applications. The argument against including queuing delay is that applications. The argument against including queuing delay is that
it if used in routing decisions it can result in routing instability. it if used in routing decisions it can result in routing instability.
This tradeoff is discussed in detail in This tradeoff is discussed in detail in
[I-D.ietf-rtgwg-cl-framework]. [I-D.ietf-rtgwg-cl-framework].
skipping to change at page 8, line 35 skipping to change at page 8, line 10
As one means to provide high availability, network operators deploy a As one means to provide high availability, network operators deploy a
topology in the MPLS network using lower layer networks that have a topology in the MPLS network using lower layer networks that have a
certain degree of diversity at the lower layer(s). Many techniques certain degree of diversity at the lower layer(s). Many techniques
have been developed to balance the distribution of flows across have been developed to balance the distribution of flows across
component links that connect the same pair of nodes. When the path component links that connect the same pair of nodes. When the path
for a flow can be chosen from a set of candidate nodes connected via for a flow can be chosen from a set of candidate nodes connected via
advanced multipaths, other techniques have been developed. Refer to advanced multipaths, other techniques have been developed. Refer to
the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of
existing techniques and a set of references. existing techniques and a set of references.
FR#10 The solution SHALL provide a means to indicate that a client FR#10 The solution SHALL provide a means to indicate that a client
LSP will traverse a component link with the minimum latency LSP will traverse a component link with the minimum latency
value. This will provide a means by which minimum latency value. This will provide a means by which minimum latency
Performance Objectives of flows within the client LSP can be Performance Objectives of flows within the client LSP can be
supported. supported.
FR#11 The solution SHALL provide a means to indicate that a client FR#11 The solution SHALL provide a means to indicate that a client
LSP will traverse a component link with a maximum acceptable LSP will traverse a component link with a maximum acceptable
latency value as specified by protocol. This will provide a latency value as specified by protocol. This will provide a
means by which bounded latency Performance Objectives of flows means by which bounded latency Performance Objectives of flows
within the client LSP can be supported. within the client LSP can be supported.
FR#12 The solution SHALL provide a means to indicate that a client FR#12 The solution SHALL provide a means to indicate that a client
LSP will traverse a component link with a maximum acceptable LSP will traverse a component link with a maximum acceptable
delay variation value as specified by protocol. delay variation value as specified by protocol.
The above set of requirements apply to component links with different The above set of requirements apply to component links with different
characteristics regardless as to whether those component links are characteristics regardless as to whether those component links are
provided by parallel physical links between nodes or provided by sets provided by parallel physical links between nodes or provided by sets
of paths across a network provided by server layer LSP. of paths across a network provided by server layer LSP.
Allowing multipath to contain component links with different Allowing multipath to contain component links with different
characteristics can improve the overall load balance and can be characteristics can improve the overall load balance and can be
accomplished while still accommodating the more strict requirements accomplished while still accommodating the more strict requirements
of a subset of client LSP. of a subset of client LSP.
skipping to change at page 9, line 26 skipping to change at page 8, line 50
client LSP where time synchronization protocols such as PTP or NTP client LSP where time synchronization protocols such as PTP or NTP
are carried, or in any other case where symmetric delay is highly are carried, or in any other case where symmetric delay is highly
desirable. There may be other uses of this capability. desirable. There may be other uses of this capability.
Other client LSP may only require that the LSP path serve the same Other client LSP may only require that the LSP path serve the same
set of nodes in both directions. This is necessary if protocols are set of nodes in both directions. This is necessary if protocols are
carried which make use of the reverse direction of the LSP as a back carried which make use of the reverse direction of the LSP as a back
channel in cases such OAM protocols using TTL to monitor or diagnose channel in cases such OAM protocols using TTL to monitor or diagnose
the underlying path. There may be other uses of this capability. the underlying path. There may be other uses of this capability.
FR#13 The solution MUST support an optional means for client LSP FR#13 The solution MUST support an optional means for client LSP
signaling to bind a client LSP to a particular component link signaling to bind a client LSP to a particular component link
within an advanced multipath. If this option is not within an advanced multipath. If this option is not exercised,
exercised, then a client LSP that is bound to an advanced then a client LSP that is bound to an advanced multipath may be
multipath may be bound to any component link matching all bound to any component link matching all other signaled
other signaled requirements, and different directions of a requirements, and different directions of a bidirectional client
bidirectional client LSP can be bound to different component LSP can be bound to different component links.
links.
FR#14 The solution MUST support a means to indicate that both FR#14 The solution MUST support a means to indicate that both
directions of co-routed bidirectional client LSP MUST be bound directions of co-routed bidirectional client LSP MUST be bound to
to the same set of nodes. the same set of nodes.
A client LSP which is bound to a specific component link SHOULD NOT A client LSP which is bound to a specific component link SHOULD NOT
exceed the capacity of a single component link. exceed the capacity of a single component link.
For some large bidirectional client LSP it may not be necessary (or For some large bidirectional client LSP it may not be necessary (or
possible due to the client LSP capacity) to bind the LSP to a common possible due to the client LSP capacity) to bind the LSP to a common
set of component links but may be necessary or desirable to constrain set of component links but may be necessary or desirable to constrain
the path taken by the LSP to the same set of nodes in both the path taken by the LSP to the same set of nodes in both
directions. Without and entirely new and highly dynamic protocol, it directions. Without and entirely new and highly dynamic protocol, it
is not feasible to constrain such an bidirectional client LSP to take is not feasible to constrain such an bidirectional client LSP to take
skipping to change at page 10, line 14 skipping to change at page 9, line 35
3.5. Multipath Load Balancing Dynamics 3.5. Multipath Load Balancing Dynamics
Multipath load balancing attempts to keep traffic levels on all Multipath load balancing attempts to keep traffic levels on all
component links below congestion levels if possible and preferably component links below congestion levels if possible and preferably
well balanced. Load balancing is minimally disruptive (see well balanced. Load balancing is minimally disruptive (see
discussion below this section's list of requirements). The discussion below this section's list of requirements). The
sensitivity to these minimal disruptions of traffic flows within sensitivity to these minimal disruptions of traffic flows within
specific client LSP needs to be considered. specific client LSP needs to be considered.
FR#15 The solution SHALL provide a means that indicates whether any FR#15 The solution SHALL provide a means that indicates whether any
of the flows within an client LSP MUST NOT be split across of the flows within an client LSP MUST NOT be split across
multiple component links. multiple component links.
FR#16 The solution SHALL provide a means local to a node that FR#16 The solution SHALL provide a means local to a node that
automatically distributes flows across the component links in automatically distributes flows across the component links in the
the advanced multipath such that Performance Objectives are advanced multipath such that Performance Objectives are met as
met as described in prior requirements in Section 3.3. described in prior requirements in Section 3.3.
FR#17 The solution SHALL measure traffic flows or groups of traffic FR#17 The solution SHALL measure traffic flows or groups of traffic
flows and dynamically select the component link on which to flows and dynamically select the component link on which to place
place this traffic in order to balance the load so that no this traffic in order to balance the load so that no component
component link in the advanced multipath between a pair of link in the advanced multipath between a pair of nodes is
nodes is overloaded. overloaded.
FR#18 When a traffic flow is moved from one component link to FR#18 When a traffic flow is moved from one component link to another
another in the same advanced multipath between a set of nodes, in the same advanced multipath between a set of nodes, it MUST be
it MUST be done so in a minimally disruptive manner. done so in a minimally disruptive manner.
FR#19 Load balancing MAY be used during sustained low traffic FR#19 Load balancing MAY be used during sustained low traffic periods
periods to reduce the number of active component links for the to reduce the number of active component links for the purpose of
purpose of power reduction. power reduction.
FR#20 The solution SHALL provide a means to identify client LSPs FR#20 The solution SHALL provide a means to identify client LSPs
containing traffic flows whose rearrangement frequency needs containing traffic flows whose rearrangement frequency needs to
to be bounded by a specific value and MUST provide a means to be bounded by a specific value and MUST provide a means to bound
bound the rearrangement frequency for traffic flows within the rearrangement frequency for traffic flows within these client
these client LSP. LSP.
FR#21 The solution SHALL provide a means to distribute traffic flows FR#21 The solution SHALL provide a means to distribute traffic flows
from a single client LSP across multiple component links to from a single client LSP across multiple component links to
handle at least the case where the traffic carried in an handle at least the case where the traffic carried in an client
client LSP exceeds that of any component link in the advanced LSP exceeds that of any component link in the advanced multipath.
multipath.
FR#22 The solution SHOULD support the use case where an advanced FR#22 The solution SHOULD support the use case where an advanced
multipath itself is a component link for a higher order multipath itself is a component link for a higher order advanced
advanced multipath. For example, an advanced multipath multipath. For example, an advanced multipath comprised of MPLS-
comprised of MPLS-TP bi-directional tunnels viewed as logical TP bi-directional tunnels viewed as logical links could then be
links could then be used as a component link in yet another used as a component link in yet another advanced multipath that
advanced multipath that connects MPLS routers. connects MPLS routers.
FR#23 If the total demand offered by traffic flows exceeds the FR#23 If the total demand offered by traffic flows exceeds the
capacity of the advanced multipath, the solution SHOULD define capacity of the advanced multipath, the solution SHOULD define a
a means to cause some client LSP to move to an alternate set means to cause some client LSP to move to an alternate set of
of paths that are not congested. These "preempted LSP" may paths that are not congested. These "preempted LSP" may not be
not be restored if there is no uncongested path in the restored if there is no uncongested path in the network.
network.
A minimally disruptive change implies that as little disruption as is A minimally disruptive change implies that as little disruption as is
practical occurs. Such a change can be achieved with zero packet practical occurs. Such a change can be achieved with zero packet
loss. A delay discontinuity may occur, which is considered to be a loss. A delay discontinuity may occur, which is considered to be a
minimally disruptive event for most services if this type of event is minimally disruptive event for most services if this type of event is
sufficiently rare. A delay discontinuity is an example of a sufficiently rare. A delay discontinuity is an example of a
minimally disruptive behavior corresponding to current techniques. minimally disruptive behavior corresponding to current techniques.
A delay discontinuity is an isolated event which may greatly exceed A delay discontinuity is an isolated event which may greatly exceed
the normal delay variation (jitter). A delay discontinuity has the the normal delay variation (jitter). A delay discontinuity has the
skipping to change at page 11, line 47 skipping to change at page 11, line 21
network operator when configuring a network for power reduction network operator when configuring a network for power reduction
should weigh the benefit of power reduction against the disadvantage should weigh the benefit of power reduction against the disadvantage
of a minimal disruption. of a minimal disruption.
4. General Requirements for Protocol Solutions 4. General Requirements for Protocol Solutions
This section defines requirements for protocol specification used to This section defines requirements for protocol specification used to
meet the functional requirements specified in Section 3. meet the functional requirements specified in Section 3.
GR#1 The solution SHOULD extend existing protocols wherever GR#1 The solution SHOULD extend existing protocols wherever
possible, developing a new protocol only where doing so adds a possible, developing a new protocol only where doing so adds a
significant set of capabilities. significant set of capabilities.
GR#2 A solution SHOULD extend LDP capabilities to meet functional GR#2 A solution SHOULD extend LDP capabilities to meet functional
requirements (without using TE methods as decided in requirements (without using TE methods as decided in [RFC3468]).
[RFC3468]).
GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported
on an advanced multipath. Function requirements SHOULD, where on an advanced multipath. Function requirements SHOULD, where
possible, be accommodated in a manner that supports LDP possible, be accommodated in a manner that supports LDP signaled
signaled LSP, RSVP signaled LSP, and LSP set up using LSP, RSVP signaled LSP, and LSP set up using management plane
management plane mechanisms. mechanisms.
GR#4 When the nodes connected via an advanced multipath are in the GR#4 When the nodes connected via an advanced multipath are in the
same MPLS network topology, the solution MAY define extensions same MPLS network topology, the solution MAY define extensions to
to the IGP. the IGP.
GR#5 When the nodes are connected via an advanced multipath are in GR#5 When the nodes are connected via an advanced multipath are in
different MPLS network topologies, the solution SHALL NOT rely different MPLS network topologies, the solution SHALL NOT rely on
on extensions to the IGP. extensions to the IGP.
GR#6 The solution SHOULD support advanced multipath IGP GR#6 The solution SHOULD support advanced multipath IGP
advertisement that results in convergence time better than that advertisement that results in convergence time better than that
of advertising the individual component links. The solution of advertising the individual component links. The solution
SHALL be designed so that it represents the range of SHALL be designed so that it represents the range of capabilities
capabilities of the individual component links such that of the individual component links such that functional
functional requirements are met, and also minimizes the requirements are met, and also minimizes the frequency of
frequency of advertisement updates which may cause IGP advertisement updates which may cause IGP convergence to occur.
convergence to occur.
Examples of advertisement update triggering events to be Examples of advertisement update triggering events to be
considered include: client LSP establishment/release, changes considered include: client LSP establishment/release, changes in
in component link characteristics (e.g., latency, up/down component link characteristics (e.g., latency, up/down state),
state), and/or bandwidth utilization. and/or bandwidth utilization.
GR#7 When a worst case failure scenario occurs, the number of GR#7 When a worst case failure scenario occurs, the number of RSVP-
RSVP-TE client LSPs to be resignaled will cause a period of TE client LSPs to be resignaled will cause a period of
unavailability as perceived by users. The resignaling time of unavailability as perceived by users. The resignaling time of
the solution MUST support protocol mechanisms meeting existing the solution MUST support protocol mechanisms meeting existing
provider Performance Objective for the duration of provider Performance Objective for the duration of unavailability
unavailability without significantly relaxing those existing without significantly relaxing those existing Performance
Performance Objectives for the same network or for networks Objectives for the same network or for networks with similar
with similar topology. For example, the processing load due to topology. For example, the processing load due to IGP
IGP readvertisement MUST NOT increase significantly and the readvertisement MUST NOT increase significantly and the
resignaling time of the solution MUST NOT increase resignaling time of the solution MUST NOT increase significantly
significantly as compared with current methods. as compared with current methods.
5. Management Requirements 5. Management Requirements
MR#1 Management Plane MUST support polling of the status and MR#1 Management Plane MUST support polling of the status and
configuration of an advanced multipath and its individual configuration of an advanced multipath and its individual
advanced multipath and support notification of status change. advanced multipath and support notification of status change.
MR#2 Management Plane MUST be able to activate or de-activate any MR#2 Management Plane MUST be able to activate or de-activate any
component link in an advanced multipath in order to facilitate component link in an advanced multipath in order to facilitate
operation maintenance tasks. The routers at each end of an operation maintenance tasks. The routers at each end of an
advanced multipath MUST redistribute traffic to move traffic advanced multipath MUST redistribute traffic to move traffic from
from a de-activated link to other component links based on the a de-activated link to other component links based on the traffic
traffic flow TE criteria. flow TE criteria.
MR#3 Management Plane MUST be able to configure a client LSP over an MR#3 Management Plane MUST be able to configure a client LSP over an
advanced multipath and be able to select a component link for advanced multipath and be able to select a component link for the
the client LSP. client LSP.
MR#4 Management Plane MUST be able to trace which component link a MR#4 Management Plane MUST be able to trace which component link a
client LSP is assigned to and monitor individual component link client LSP is assigned to and monitor individual component link
and advanced multipath performance. and advanced multipath performance.
MR#5 Management Plane MUST be able to verify connectivity over each MR#5 Management Plane MUST be able to verify connectivity over each
individual component link within an advanced multipath. individual component link within an advanced multipath.
MR#6 Component link fault notification MUST be sent to the MR#6 Component link fault notification MUST be sent to the
management plane. management plane.
MR#7 Advanced multipath fault notification MUST be sent to the MR#7 Advanced multipath fault notification MUST be sent to the
management plane and MUST be distributed via link state message management plane and MUST be distributed via link state message
in the IGP. in the IGP.
MR#8 Management Plane SHOULD provide the means for an operator to MR#8 Management Plane SHOULD provide the means for an operator to
initiate an optimization process. initiate an optimization process.
MR#9 An operator initiated optimization MUST be performed in a MR#9 An operator initiated optimization MUST be performed in a
minimally disruptive manner as described in Section 3.5. minimally disruptive manner as described in Section 3.5.
6. Acknowledgements 6. Acknowledgements
Frederic Jounay of France Telecom and Yuji Kamite of NTT Frederic Jounay of France Telecom and Yuji Kamite of NTT
Communications Corporation co-authored a version of this document. Communications Corporation co-authored a version of this document.
A rewrite of this document occurred after the IETF77 meeting. A rewrite of this document occurred after the IETF77 meeting.
Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John
Scuder and Alex Zinin, the current WG chair Alia Atlas, and others Scuder and Alex Zinin, the current WG chair Alia Atlas, and others
provided valuable guidance prior to and at the IETF77 RTGWG meeting. provided valuable guidance prior to and at the IETF77 RTGWG meeting.
skipping to change at page 14, line 18 skipping to change at page 13, line 34
Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG
mailing list after IETF82 that identified a new requirement. mailing list after IETF82 that identified a new requirement.
Iftekhar Hussain made numerous valuable comments on the RTGWG mailing Iftekhar Hussain made numerous valuable comments on the RTGWG mailing
list that resulted in improvements to document clarity. list that resulted in improvements to document clarity.
In the interest of full disclosure of affiliation and in the interest In the interest of full disclosure of affiliation and in the interest
of acknowledging sponsorship, past affiliations of authors are noted. of acknowledging sponsorship, past affiliations of authors are noted.
Much of the work done by Ning So occurred while Ning was at Verizon. Much of the work done by Ning So occurred while Ning was at Verizon.
Much of the work done by Curtis Villamizar occurred while at Much of the work done by Curtis Villamizar occurred while at
Infinera. Infinera. Much of the work done by Andy Malis occurred while Andy
was at Verizon.
Tom Yu and Francis Dupont provided the SecDir and GenArt reviews Tom Yu and Francis Dupont provided the SecDir and GenArt reviews
respectively. Both reviews provided useful comments. The current respectively. Both reviews provided useful comments. The current
wording of the security section is based on suggested wording from wording of the security section is based on suggested wording from
Tom Yu. Lou Berger provided the RtgDir review which resulted in the Tom Yu. Lou Berger provided the RtgDir review which resulted in the
document being renamed and substantial clarification of terminology document being renamed and substantial clarification of terminology
and document wording, particularly in the Abstract, Introduction, and and document wording, particularly in the Abstract, Introduction, and
Definitions sections. Definitions sections.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 16, line 26 skipping to change at page 15, line 40
USA USA
Email: dave.mcdysan@verizon.com Email: dave.mcdysan@verizon.com
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com Email: ning.so@tatacommunications.com
Andrew Malis Andrew Malis
Verizon Consultant
60 Sylvan Road
Waltham, MA 02451
USA
Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com
Email: agmalis@gmail.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75025 Plano, TX 75025
USA USA
Phone: +1 469-277-5837 Phone: +1 469-277-5837
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
 End of changes. 50 change blocks. 
180 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/