Arun Arumuganainar | 8 Apr 16:36 2014

Requesting Comments about the Draft : draft-arumuganainar-rtgwg-dps-requirements-00.txt

Hi all ,

Thanks very much for listening to my presentation during the London meeting and providing feedback on the draft.

Based on the feedback received , I have re-written the draft as two drafts.

1) DPS-Requirements Draft :- (draft-arumuganainar-rtgwg-dps-requirements-00.txt )

	- This talks about problem statement , full requirements and general framework for DPS
	- I have also included existing implementation and Gap analysis

2) DPS Use cases :- (draft-arumuganainar-rtgwg-dps-use-cases-00) 

	- Document all the use cases for DPS
	- Majority of the use cases taken from existing implementation. I have also included one use case that
currently on our roadmap
	- As discussed draft can be amended if readers can come up with additional uses case.

Since requirements and Use cases draft essentially covers everything , my original
draft(draft-aumuganainar-rtgwg-dps-00 ) do not hold any relevance. Hence I have allowed my original
draft to expire.

In addition to this  I have also posted one more draft.  In the current implementation, signalling happens at
control plane and hence DPS behaviour do not changes when there are changes in network condition . For
example DPS behaviour when there is acute congestion on the primary link will be same as when there is no
congestion. This is because BGP is used for signalling . And BGP is a control plane protocol. It do not have
any information about what is happening in the forwarding plane.

 If we can move the signalling to forwarding plane then probably we can tune the DPS behaviour to adapt to
dynamic network conditions. I have documented this requirement in a separate draft. This draft proposes
(Continue reading)

internet-drafts | 8 Apr 11:00 2014

I-D Action: draft-psarkar-rtgwg-rlfa-node-protection-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Remote-LFA Node Protection and Manageability
        Authors         : Pushpasis Sarkar
                          Hannes Gredler
                          Shraddha Hegde
                          Harish Raghuveer
                          Chris Bowers
                          Stephane Litkowski
	Filename        : draft-psarkar-rtgwg-rlfa-node-protection-04.txt
	Pages           : 16
	Date            : 2014-04-08

   The loop-free alternates computed following the current Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
   protection.  The resulting Remote-LFA nexthops (also called PQ-
   nodes), may not gaurantee node-protection for all destinations being
   protected by it.

   This document describes procedures for determining if a given PQ-node
   provides node-protection for a specific destination or not.  The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints.

(Continue reading)

Uma Chunduri | 28 Mar 18:50 2014

Comments on draft-psarkar-rtgwg-rlfa-node-protection-03

Dear Authors,


These are some specific comments –





1. Abstract -


   document also shows how the same procedure can be utilised for

   collection of complete characteristics for alternate paths.

   Knowledge about the characteristics of all alternate path is

   precursory to apply operator defined policy for eliminating paths not

   fitting constraints."


   Why we need this for NP only?



2. Introduction


   "  Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability]

   document, requires a computing router to find all possible (including

   all possible Remote-LFA) alternate nexthops, collect the complete set

   of path characteristics for each alternate path, run a alternate-

   selection policy (configured by the operator), and find the best

   alternate path.  This will require the Remote-LFA implementation to

   gather all the required path characteristics along each link on the

   entire Remote-LFA alternate path."


Why do we need to collect path characteristics of all alternatives before alternate policy ? This is not what is represented in I-D.ietf-rtgwg-lfa-manageability (it's prune then run alternate

selection policy)


3. Section 2.1

   " A closer look at Table 1 shows that, while the PQ-node R2 provides

   link-protection for all the destinations, it does not provide node-

   protection for destinations E and F."


   There is no node F in the diagram. You mean to say D1 here?


4. Section 2.1 - Table 2

    D2          | S->E->D1     | R3      | S=>N=>E=>R3->D2


    The above should be S->E-R3-D2


5. Section 2.1

    "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

   G, if we choose R3 as the R-LFA nexthop, it does not provide node-

   protection for R3 and D1 anymore."


   There is no node G in the diagram


6. Section 2.2.1


    D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E,Y)


   Need to be changed (even in the main draft, per agreement earlier) to

     D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)


7.Section 2.2.2

  "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

   via direct neighbor Ni to the PQ-node Y is not affected in the event

   of a node failure of E. It does not yet guarantee that the path

   segment from PQ-node Y to the destination is also unaffected by the

   same failure event."


   I don't think Y is yet a PQ node as description says. Probably it needs to be corrected as "potential PQ-node"


8. Section 2.3.1 (even title itself is incorrect, this is all about NP ext-P space)


   "Implementations should run the inequality in Section 2.2.2 Figure 4

   for all direct neighbor, other than primary nexthop node E, to

   determine whether a PQ-node Y is also a candidate node-protecting PQ-


   for all direct neighbor ==> should be replaced to indicate all eligible neighbors where back is provisioned.


9. Section 2.3.1


   " Implementations should run the inequality in Section 2.2.2 Figure 4

   for all direct neighbor, other than primary nexthop node E, to

   determine whether a PQ-node Y is also a candidate node-protecting PQ-



   Y is not PQ-node here. "PQ-node" should be replaced with node protecting extended-p space node.


10. Section 2.3.1

     In the similar grounds as above

     Table 3 & table 4 first column should not be "PQ-node (y)"


11. Section 2.3.1

    Though this section is trying to justify how and why the PQ nodes selected are link protecting and node protecting.

    But the way it's written is incorrect  with references to section 2.2.2


    For e.g.


    "So S may re-use the list of

   links and nodes collected from the same SPF computations, to decide

   whether a PQ-node Y is a candidate node-protecting PQ-node or not.  A

   PQ-node Y shall be considered as a node-protecting, if and only if,

   there is atleast one direct neighbor of S, other than the primary

   nexthop E, for which, the primary nexthop node E does not exist on

   the list of nodes traversed on any of the shortest path(s) from the

   direct neighbor to the PQ-node."


   Here the usage of PQ node is incorrect as it is referring to section 2.2.2.

   The more correct term here is the candidate NP extended-P space.


12. Section 2.3.1



   As seen in the above Table 4 while R2 is candidate node-protecting

   Remote-LFA nexthop for R3 and G, it is not so for E and F, since the

   primary nexthop E is in the shortest path from R2 to E and F."


   There are no nodes G and F anywhere in the diagrams


13. Section 2.3.2



   running the forward SPF on a PQ-node (from the node-protecting PQ-

   space) the computing router shall run the inequality in Figure 6

   below.  PQ-nodes that does not qualify the condition for a given

   destination, does not gaurantee node-protection for the path segment

   from the PQ-node to the given destination."


   Here the PQ nodes are candidate NP PQ nodes - this section should be cognizant

   of this while loosely using PQ nodes term.



    Also it's not "After running the forward SPF..", it should be "While running the forward SPF.."



14. Section 2.3.3


    " Implementations MUST choose

   a default value for this limit and may provide user with a

   configuration knob to override the default limit.  Implementations

   MUST also evaluate some default preference criteria while considering

   a PQ-node in this subset."


   Here the point is for interoperability and deterministically getting the same PQ node from all vendors one default criteria should be used.


   But if "some default" preference is used you won't fulfill the objective of same PQ node. If this is really a goal then this document must

   define indeed a default heuristic and this must be implemented by all.


   The below paragraph indicates a suggested default criteria and also points out further study is required to confirm this is indeed the "default".

    I think this need to be worked out.


   "A suggested default criteria for PQ-node selection will be to put a

   score on each PQ-node, proportional to the number of primary

   interfaces and remote destination routers being protected by it, and

   then pick PQ-nodes based on this score.  A more appropriate

   heuristsics can be devised, based on in-depth study of coverage

   provided by R-LFA, in the networks where they are mostly deployed.

   The same can then be used for PQ-node selection."



15. Section 3


    "For such

   policy-based alternate selection to run, all the relevant path

   characteristics for each the alternate paths (one through each of the

   PQ-nodes), needs to be collected."


   This is very vague - what path characteristics you are seeking must be clearly spelled out.


   And also this whole thing doesn't belong here and should be in


   And I already see the same in Section of the same.




Uma C.


rtgwg mailing list
rtgwg <at>
IETF Secretariat | 25 Mar 20:52 2014

IPR Disclosure: Juniper's Statement of IPR related to draft-psarkar-rtgwg-rlfa-node-protection-01

Dear psarkar <at>, Hannes Gredler, Shraddha Hegde, Harish Raghuveer, cbowers <at>,
Stephane Litkowski:

 An IPR disclosure that pertains to your Internet-Draft entitled "Remote-LFA
Node Protection and Manageability" (draft-psarkar-rtgwg-rlfa-node-protection)
was submitted to the IETF Secretariat on 2014-02-24 and has been posted on the
"IETF Page of Intellectual Property Rights Disclosures"
( The title of the IPR disclosure is
"Juniper's Statement of IPR related to draft-psarkar-rtgwg-rlfa-node-

The IETF Secretariat
Jeff Tantsura | 25 Mar 18:59 2014

What makes for a quality RFC presentation

For your information, the link below is to a presentation Adrian gave to
the MPLS working group on producing drafts that are going to RFC.
Some of the thoughts are specific to MPLS.  But most of them are widely

Jeff Tantsura | 19 Mar 00:40 2014

volunteers to take on draft-ietf-rtgwg-ipfrr-ip-mib work


Following our discussion in London - I'm looking for volunteers to take on
draft-ietf-rtgwg-ipfrr-ip-mib work.


Curtis Villamizar | 15 Mar 01:51 2014



In the presentation about Advanced Multipath Framework, I mentioned
that I would be submitting a draft on routing and load balancing
stability.  That draft just got submitted.

  Stability of Interior Routing and Load Balancing Techniques

Its in the usual places such as

Comments are welcome and would be appreciated.

Alvaro Retana (aretana | 14 Mar 06:01 2014

WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection


During the meeting in London the authors asked for the WG to adopt this draft.

This message officially starts the call for adoption for draft-psarkar-rtgwg-rlfa-node-protection.  Please indicate your position about adopting it by end-of-day on March 28, 2014.


rtgwg mailing list
rtgwg <at>
Alvaro Retana (aretana | 14 Mar 05:35 2014

WGLC for draft-ietf-rtgwg-mofrr


This message starts the Working Group Last Call for draft-ietf-rtgwg-mofrr.  This call will close by EOD (pick your favorite time zone) on March 28, 2014.

Please provide specific feedback as to why you support (or not) the advancement of this draft.  Please avoid "+1"-type responses.


rtgwg mailing list
rtgwg <at>
Adrian Farrel | 12 Mar 23:28 2014

Alia removed as co-chair


A with a final thanks to Alia for her stewardship as co-chair of the RTGWG, I
have removed her as co-chair leaving the WG in the capable hands of Alvaro and

Of course, Alia remains with you as your responsible AD.

Jeff Tantsura | 10 Mar 18:30 2014

IETF 89 RTGWG WG Meeting Minutes


IETF 89 RTGWG WG meeting minutes have been uploaded to
Thanks to Acee Linden for taking the minutes.