draft-psarkar-rtgwg-rlfa-node-protection-04.txt   draft-psarkar-rtgwg-rlfa-node-protection-05.txt 
Routing Area Working Group P. Sarkar, Ed. Routing Area Working Group P. Sarkar, Ed.
Internet-Draft H. Gredler Internet-Draft H. Gredler
Intended status: Standards Track S. Hegde Intended status: Standards Track S. Hegde
Expires: October 10, 2014 H. Raghuveer Expires: December 26, 2014 C. Bowers
C. Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
S. Litkowski S. Litkowski
Orange Orange
April 08, 2014 H. Raghuveer
June 24, 2014
Remote-LFA Node Protection and Manageability Remote-LFA Node Protection and Manageability
draft-psarkar-rtgwg-rlfa-node-protection-04 draft-psarkar-rtgwg-rlfa-node-protection-05
Abstract Abstract
The loop-free alternates computed following the current Remote-LFA The loop-free alternates computed following the current Remote-LFA
[I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link- [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
protection. The resulting Remote-LFA nexthops (also called PQ- protection. The resulting Remote-LFA nexthops (also called PQ-
nodes), may not gaurantee node-protection for all destinations being nodes), may not gaurantee node-protection for all destinations being
protected by it. protected by it.
This document describes procedures for determining if a given PQ-node This document describes procedures for determining if a given PQ-node
skipping to change at page 2, line 7 skipping to change at page 2, line 10
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 October 10, 2014. This Internet-Draft will expire on December 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 3 2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 3
2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Few Additional Definitions . . . . . . . . . . . . . . . 5 2.2. Few Additional Definitions . . . . . . . . . . . . . . . 5
2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 5 2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 6
2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6 2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 6
2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 8 2.2.4. Link-Protecting PQ Space . . . . . . . . . . . . . . 8
2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 8 2.2.5. Candidate Node-Protecting PQ Space . . . . . . . . . 8
2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 8 2.3. Computing Node-protecting R-LFA Path . . . . . . . . . . 8
2.3.1. Computing Candidate Node-protecting PQ-Nodes for 2.3.1. Computing Candidate Node-protecting PQ-Nodes for
Primary nexthops . . . . . . . . . . . . . . . . . . 8 Primary nexthops . . . . . . . . . . . . . . . . . . 8
2.3.2. Computing node-protecting paths from PQ-nodes to 2.3.2. Computing node-protecting paths from PQ-nodes to
destinations . . . . . . . . . . . . . . . . . . . . 10 destinations . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Limiting extra computational overhead . . . . . . . . 12 2.3.3. Limiting extra computational overhead . . . . . . . . 12
3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . 13 3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . 13
3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 14 3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 14
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides
loop-free alternates that gaurantees only link-protection. The loop-free alternates that gaurantees only link-protection. The
resulting Remote-LFA alternate nexthops (also referred to as the PQ- resulting Remote-LFA alternate nexthops (also referred to as the PQ-
nodes) may not provide node-protection for all destinations covered nodes) may not provide node-protection for all destinations covered
by the same, in case of failure of the primary nexthop node. Neither by the same, in case of failure of the primary nexthop node. Neither
does the specification provide a means to determine the same. does the specification provide a means to determine the same.
skipping to change at page 3, line 26 skipping to change at page 3, line 28
all possible Remote-LFA) alternate nexthops, collect the complete set all possible Remote-LFA) alternate nexthops, collect the complete set
of path characteristics for each alternate path, run a alternate- of path characteristics for each alternate path, run a alternate-
selection policy (configured by the operator), and find the best selection policy (configured by the operator), and find the best
alternate path. This will require the Remote-LFA implementation to alternate path. This will require the Remote-LFA implementation to
gather all the required path characteristics along each link on the gather all the required path characteristics along each link on the
entire Remote-LFA alternate path. entire Remote-LFA alternate path.
With current LFA [RFC5286] and Remote-LFA implementations, the With current LFA [RFC5286] and Remote-LFA implementations, the
forward SPF (and reverse SPF) is run on the computing router and its forward SPF (and reverse SPF) is run on the computing router and its
immediate 1-hop routers as the roots. While that enables computation immediate 1-hop routers as the roots. While that enables computation
of path attributes (e.g. SRLG, Admin-groups) for first alternate path of path attributes (e.g. SRLG, Admin-groups) for first alternate
segment from the computing router to the PQ-node, there is no means path segment from the computing router to the PQ-node, there is no
for the computing router to gather any path attributes for the path means for the computing router to gather any path attributes for the
segment from the PQ-node to destination. Consecutively any policy- path segment from the PQ-node to destination. Consecutively any
based selection of alternate paths will consider only the path policy-based selection of alternate paths will consider only the path
attributes from the computing router up until the PQ-node. attributes from the computing router up until the PQ-node.
This document describes a procedure for determining node-protection This document describes a procedure for determining node-protection
with Remote-LFA. The same procedure are also extended for collection with Remote-LFA. The same procedure are also extended for collection
of complete set of path attributes, enabling more accurate policy- of complete set of path attributes, enabling more accurate policy-
based selection for alternate paths obtained with Remote-LFA. based selection for alternate paths obtained with Remote-LFA.
2. Node Protection with Remote-LFA 2. Node Protection with Remote-LFA
Node-protection is required to provide protection of traffic on a
given forwarding node, against the failure of the first-hop node on
the primary forwarding path. Such protection becomes more critical
in the absence of mechanisms like non-stop-routing in the network.
Certain operators refrains from deploying non-stop-routing in their
network, due to the significant additional performance complexities
it comes along with. In such cases node-protection is a must to
gaurantee un-interrupted flow of traffic, even in the case of an
entire forwarding node going down.
The follwoing sections discusses the node-protection problem in the
context of Remote-LFA and proposes a solution for solving the same.
2.1. The Problem 2.1. The Problem
To better illustrate the problem and the solution proposed in this To better illustrate the problem and the solution proposed in this
document the following topology diagram from the Remote-LFA document the following topology diagram from the Remote-LFA
[I-D.ietf-rtgwg-remote-lfa] draft is being re-used with slight [I-D.ietf-rtgwg-remote-lfa] draft is being re-used with slight
modification. modification.
D1 D1
/ /
S-x-E S-x-E
skipping to change at page 5, line 28 skipping to change at page 5, line 31
possible primary and R-LFA alternate paths via PQ-node R3, for each possible primary and R-LFA alternate paths via PQ-node R3, for each
destination reachable through the S-E link in the above topology. destination reachable through the S-E link in the above topology.
The R-LFA alternate paths via PQ-node R2 remains same as in Table 1. The R-LFA alternate paths via PQ-node R2 remains same as in Table 1.
+-------------+--------------+---------+------------------------+ +-------------+--------------+---------+------------------------+
| Destination | Primary Path | PQ-node | Remote-LFA Backup Path | | Destination | Primary Path | PQ-node | Remote-LFA Backup Path |
+-------------+--------------+---------+------------------------+ +-------------+--------------+---------+------------------------+
| R3 | S->E->R3 | R3 | S=>N=>E=>R3 | | R3 | S->E->R3 | R3 | S=>N=>E=>R3 |
| E | S->E | R3 | S=>N=>E=>R3->E | | E | S->E | R3 | S=>N=>E=>R3->E |
| D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 | | D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 |
| D2 | S->E->D1 | R3 | S=>N=>E=>R3->D2 | | D2 | S->E->R3->D2 | R3 | S=>N=>E=>R3->D2 |
+-------------+--------------+---------+------------------------+ +-------------+--------------+---------+------------------------+
Table 2: Remote-LFA backup paths via PQ-node R3 Table 2: Remote-LFA backup paths via PQ-node R3
Again a closer look at Table 2 shows that, unlike Table 1, where the Again a closer look at Table 2 shows that, unlike Table 1, where the
single PQ-node R2 provided node-protection, for destinations R3 and single PQ-node R2 provided node-protection, for destinations R3 and
D1, if we choose R3 as the R-LFA nexthop, it does not provide node- D1, if we choose R3 as the R-LFA nexthop, it does not provide node-
protection for R3 and D1 anymore. If S chooses R3 as the R-LFA protection for R3 and D1 anymore. If S chooses R3 as the R-LFA
nexthop, in the event of the node-failure on primary nexthop E, the nexthop, in the event of the node-failure on primary nexthop E, the
alternate path from S to R-LFA nexthop R3 also becomes unavailable. alternate path from S to R-LFA nexthop R3 also becomes unavailable.
skipping to change at page 6, line 31 skipping to change at page 6, line 37
Y : The node being evaluated for link-protecting Y : The node being evaluated for link-protecting
extended P-Space. extended P-Space.
Figure 3: Link-Protecting Ext-P-Space Condition Figure 3: Link-Protecting Ext-P-Space Condition
2.2.2. Node-Protecting Extended P-Space 2.2.2. Node-Protecting Extended P-Space
The node-protecting extended P-space for a primary nexthop node E The node-protecting extended P-space for a primary nexthop node E
being protected, is the set of routers that are reachable from one or being protected, is the set of routers that are reachable from one or
more direct neighbors of S, except primary node E, without traversing more direct neighbors of S, except primary node E, without traversing
the node E. This MUST exclude any direct neighbors for which there is the node E. This MUST exclude any direct neighbors for which there
atleast one ECMP path from the direct neighbor traversing the node E is atleast one ECMP path from the direct neighbor traversing the node
being protected. E being protected.
A node Y is in node-protecting extended P-space w.r.t to the node E A node Y is in node-protecting extended P-space w.r.t to the node E
being protected, if and only if, there exists atleast one direct being protected, if and only if, there exists atleast one direct
neighbor of S, Ni, other than primary nexthop E, that satisfies the neighbor of S, Ni, other than primary nexthop E, that satisfies the
following condition. following condition.
D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y) D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y)
Where, Where,
D_opt(A,B) : Distance on most optimum path from A to B. D_opt(A,B) : Distance on most optimum path from A to B.
skipping to change at page 7, line 21 skipping to change at page 7, line 21
Ni : A direct neighbor of S other than primary Ni : A direct neighbor of S other than primary
nexthop E. nexthop E.
Y : The node being evaluated for node-protecting Y : The node being evaluated for node-protecting
extended P-Space. extended P-Space.
Figure 4: Node-Protecting Ext-P-Space Condition Figure 4: Node-Protecting Ext-P-Space Condition
It must be noted that a node Y satisfying the condition in Figure 4 It must be noted that a node Y satisfying the condition in Figure 4
above only guarantees that the R-LFA alternate path segment from S above only guarantees that the R-LFA alternate path segment from S
via direct neighbor Ni to the node Y is not affected in the event of via direct neighbor Ni to the node Y is not affected in the event of
a node failure of E. It does not yet guarantee that the path segment a node failure of E. It does not yet guarantee that the path segment
from node Y to the destination is also unaffected by the same failure from node Y to the destination is also unaffected by the same failure
event. event.
2.2.3. Q-Space 2.2.3. Q-Space
The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft already defines The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] draft already defines
this. The Q-space for a link S-E being protected is the set of this. The Q-space for a link S-E being protected is the set of
routers that can reach primary node E, without traversing the S-E routers that can reach primary node E, without traversing the S-E
link on any of the shortest path from the node Y to primary nexthop link on any of the shortest path from the node Y to primary nexthop
E. This MUST exclude any destination for which there is atleast one E. This MUST exclude any destination for which there is atleast one
skipping to change at page 8, line 21 skipping to change at page 8, line 21
2.2.5. Candidate Node-Protecting PQ Space 2.2.5. Candidate Node-Protecting PQ Space
A node Y is in candidate node-protecting PQ space w.r.t to the node A node Y is in candidate node-protecting PQ space w.r.t to the node
(E) being protected, if and only if, Y is present in both node- (E) being protected, if and only if, Y is present in both node-
protecting extended P-space and the Q-space for the link being protecting extended P-space and the Q-space for the link being
protected. protected.
Again it must be noted that a node Y being in candidate node- Again it must be noted that a node Y being in candidate node-
protecting PQ-space does not guarantee that the R-LFA alternate path protecting PQ-space does not guarantee that the R-LFA alternate path
via the same, in entirety, is unaffected in the event of a node via the same, in entirety, is unaffected in the event of a node
failure of primary nexthop node E. It only guarantees that the path failure of primary nexthop node E. It only guarantees that the path
segment from S to PQ-node Y is unaffected by the same failure event. segment from S to PQ-node Y is unaffected by the same failure event.
The PQ-nodes in the candidate node-protecting PQ space may provide The PQ-nodes in the candidate node-protecting PQ space may provide
node protection for only a subset of destinations that are reachable node protection for only a subset of destinations that are reachable
through the corresponding primary link. through the corresponding primary link.
2.3. Computing Node-protecting R-LFA Path 2.3. Computing Node-protecting R-LFA Path
The R-LFA alternate path through a given PQ-node to a given The R-LFA alternate path through a given PQ-node to a given
destination comprises of two path segments as follows. destination comprises of two path segments as follows.
skipping to change at page 11, line 43 skipping to change at page 11, line 43
| D1 | E | 3 | 2 | 1 | No | | D1 | E | 3 | 2 | 1 | No |
| | | (R2,D1) | (R2,E) | (E,D1) | | | | | (R2,D1) | (R2,E) | (E,D1) | |
| D2 | E | 2 | 2 | 1 | Yes | | D2 | E | 2 | 2 | 1 | Yes |
| | | (R2,D2) | (R2,E) | (E,D2) | | | | | (R2,D2) | (R2,E) | (E,D2) | |
+-------------+------------+---------+--------+---------+-----------+ +-------------+------------+---------+--------+---------+-----------+
Table 5: Node-protection evaluation for R-LFA path segment between Table 5: Node-protection evaluation for R-LFA path segment between
PQ-node and destination PQ-node and destination
As seen in the above example above, R2 does not meet the node- As seen in the above example above, R2 does not meet the node-
protecting inequality for destination E, and F. And so, once again, protecting inequality for destination E, and F. And so, once again,
while R2 is a node-protecting Remote-LFA nexthop for R3 and G, it is while R2 is a node-protecting Remote-LFA nexthop for R3 and G, it is
not so for E and F. not so for E and F.
In SPF implementations that also produce a list of links and nodes In SPF implementations that also produce a list of links and nodes
traversed on the shortest path(s) from a given root to others, to traversed on the shortest path(s) from a given root to others, to
determine whether a PQ-node provides node-protection for a given determine whether a PQ-node provides node-protection for a given
destination or not, the list of nodes computed from forward SPF run destination or not, the list of nodes computed from forward SPF run
on the PQ-node, for the given destination, should be inspected. In on the PQ-node, for the given destination, should be inspected. In
case the list contains the primary nexthop node, the PQ-node does not case the list contains the primary nexthop node, the PQ-node does not
provide node-protection. Else, the PQ-node guarantees node- provide node-protection. Else, the PQ-node guarantees node-
skipping to change at page 13, line 12 skipping to change at page 13, line 12
document proposes that implementations MUST choose a subset from the document proposes that implementations MUST choose a subset from the
entire set of PQ-nodes computed in the network, with a finite limit entire set of PQ-nodes computed in the network, with a finite limit
on the number of PQ-nodes in the subset. Implementations MUST choose on the number of PQ-nodes in the subset. Implementations MUST choose
a default value for this limit and may provide user with a a default value for this limit and may provide user with a
configuration knob to override the default limit. Implementations configuration knob to override the default limit. Implementations
MUST also evaluate some default preference criteria while considering MUST also evaluate some default preference criteria while considering
a PQ-node in this subset. Finally, implementations MAY also allow a PQ-node in this subset. Finally, implementations MAY also allow
user to override the default preference criteria, by providing a user to override the default preference criteria, by providing a
policy configuration for the same. policy configuration for the same.
A suggested default criteria for PQ-node selection will be to put a This document proposes that implementations SHOULD use a default
score on each PQ-node, proportional to the number of primary preference criteria for PQ-node selection which will put a score on
interfaces and remote destination routers being protected by it, and each PQ-node, proportional to the number of primary interfaces for
then pick PQ-nodes based on this score. A more appropriate which it provides coverage, its distance from the computing router,
heuristsics can be devised, based on in-depth study of coverage and its router-id (or system-id in case of IS-IS). PQ-nodes that
provided by R-LFA, in the networks where they are mostly deployed. cover more primary interfaces SHOULD be preferred over PQ-nodes that
The same can then be used for PQ-node selection. cover fewer primary interfaces. When two or more PQ-nodes cover the
same number of primary interfaces, PQ-nodes which are closer (based
on metric) to the computing router SHOULD be preferred over PQ-nodes
farther away from it. For PQ-nodes that cover the same number of
primary interfaces and are the same distance from the the computing
router, the PQ-node with smaller router-id (or system-id in case of
IS-IS) SHOULD be preferred.
Once a subset of PQ-nodes is found, computing router shall run a Once a subset of PQ-nodes is found, computing router shall run a
forward SPF on each of the PQ-nodes in the subset to continue with forward SPF on each of the PQ-nodes in the subset to continue with
procedures proposed in section Section 2.3.2. procedures proposed in section Section 2.3.2.
3. Manageabilty of Remote-LFA Alternate Paths 3. Manageabilty of Remote-LFA Alternate Paths
3.1. The Problem 3.1. The Problem
With the regular Remote-LFA [I-D.ietf-rtgwg-remote-lfa] functionality With the regular Remote-LFA [I-D.ietf-rtgwg-remote-lfa] functionality
skipping to change at page 14, line 15 skipping to change at page 14, line 18
3.2. The Solution 3.2. The Solution
The additional forward SPF computation proposed in section The additional forward SPF computation proposed in section
Section 2.3.2 document shall also collect links, nodes and path Section 2.3.2 document shall also collect links, nodes and path
characteristics along the second path segment. This shall enable characteristics along the second path segment. This shall enable
collection of complete path characteristics for a given Remote-LFA collection of complete path characteristics for a given Remote-LFA
alternate path to a given destination. The complete alternate path alternate path to a given destination. The complete alternate path
characteristics shall then facilitate more accurate alternate path characteristics shall then facilitate more accurate alternate path
selection while running the alternate selection policy. selection while running the alternate selection policy.
Like specified in Section 2.3.3 to limit the computational overhead
of the approach proposed, forward SPF computations MUST be run on a
selected subset from the entire set of PQ-nodes computed in the
network, with a finite limit on the number of PQ-nodes in the subset.
The detailed suggestion on how to select this subset is specified in
the same section. While this limits the number of possible alternate
paths provided to the alternate-selection policy, this is needed keep
the computational complexity within affordable limits. However if
the alternate-selection policy is very restrictive this may leave few
destinations in the entire toplogy without protection. Yet this
limitation provides a necessary tradeoff between extensive coverage
and immense computational overhead.
4. Acknowledgements 4. Acknowledgements
Many thanks to Bruno Decraene for his useful comments. Many thanks to Bruno Decraene for providing his useful comments. We
would also like to thank Uma Chunduri for reviewing this document and
providing valuable feedback.
5. IANA Considerations 5. IANA Considerations
N/A. - No protocol changes are proposed in this document. N/A. - No protocol changes are proposed in this document.
6. Security Considerations 6. Security Considerations
This document does not introduce any change in any of the protocol This document does not introduce any change in any of the protocol
specifications. It simply proposes to run an extra SPF rooted on specifications. It simply proposes to run an extra SPF rooted on
each PQ-node discovered in the whole network. each PQ-node discovered in the whole network.
skipping to change at page 15, line 30 skipping to change at page 16, line 4
Email: hannes@juniper.net Email: hannes@juniper.net
Shraddha Hegde Shraddha Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
Electra, Exora Business Park Electra, Exora Business Park
Bangalore, KA 560103 Bangalore, KA 560103
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
Harish Raghuveer
Juniper Networks, Inc.
Electra, Exora Business Park
Bangalore, KA 560103
India
Email: hraghuveer@juniper.net
Chris Bowers Chris Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: cbowers@juniper.net Email: cbowers@juniper.net
Stephane Litkowski Stephane Litkowski
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Harish Raghuveer
Email: harish.r.prabhu@gmail.com
 End of changes. 20 change blocks. 
38 lines changed or deleted 66 lines changed or added

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