From nobody Wed Apr 2 03:32:30 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6862F1A01B1 for ; Wed, 2 Apr 2014 03:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugbWF9ulB49V for ; Wed, 2 Apr 2014 03:32:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id A3E961A01AA for ; Wed, 2 Apr 2014 03:32:07 -0700 (PDT) Received: from mail243-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 10:32:03 +0000 Received: from mail243-tx2 (localhost [127.0.0.1]) by mail243-tx2-R.bigfish.com (Postfix) with ESMTP id 901161700645; Wed, 2 Apr 2014 10:32:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic85fh148cI168aJzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail243-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(377454003)(52604005)(76576001)(77096001)(76786001)(74316001)(54316002)(65816001)(74366001)(94946001)(74706001)(66066001)(33646001)(59766001)(74876001)(92566001)(80022001)(50986001)(63696002)(47976001)(19609705001)(16236675002)(76482001)(99286001)(20776003)(86362001)(69226001)(47736001)(19300405004)(49866001)(54356001)(53806001)(93136001)(2656002)(87266001)(85852003)(77982001)(95666003)(87936001)(81816001)(4396001)(15975445006)(81686001)(31966008)(56776001)(76796001)(94316002)(81542001)(15202345003)(79102001)(93516002)(51856001)(19580395003)(74502001)(97186001)(83322001)(90146001)(83072002)(81342001)(47446002)(19580405001)(56816005)(98676001)(99396002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB520; H:BN1PR05MB520.namprd05.prod.outlook.com; FPR:EED2FE05.ABFA9912.B1F3118B.4AFA9A4D.207D3; MLV:sfv; PTR:InfoNoRecords; LANG:en; Received: from mail243-tx2 (localhost.localdomain [127.0.0.1]) by mail243-tx2 (MessageSwitch) id 1396434721257807_21698; Wed, 2 Apr 2014 10:32:01 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.237]) by mail243-tx2.bigfish.com (Postfix) with ESMTP id 3947314800A0; Wed, 2 Apr 2014 10:32:01 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 10:32:01 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 2 Apr 2014 10:32:00 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 2 Apr 2014 10:31:59 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.240]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.187]) with mapi id 15.00.0898.005; Wed, 2 Apr 2014 10:31:59 +0000 From: Pushpasis Sarkar To: Uma Chunduri , "rtgwg@ietf.org" Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thread-Topic: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thread-Index: AQHPSrgG3PkuL/+RM0WZdllDTnHOMZr+DFeg Date: Wed, 2 Apr 2014 10:31:58 +0000 Message-ID: References: <1B502206DFA0C544B7A60469152008633F23168E@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F23168E@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.18] x-forefront-prvs: 0169092318 Content-Type: multipart/alternative; boundary="_000_a3d1b5e1b4c24bcaa7c9b9efe7084f26BN1PR05MB520namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/QR7fWt3fO5lORtCw3CT75WzcFOM X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 10:32:28 -0000 --_000_a3d1b5e1b4c24bcaa7c9b9efe7084f26BN1PR05MB520namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Uma, First off, sorry for the late response. Second, thanks a lot for taking you= r time to review this draft so closely. Please find some comments and resol= ution inline. Hoping I am able to address all your comments. Thanks -Pushpasis From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, March 28, 2014 11:21 PM To: rtgwg@ietf.org Subject: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Dear Authors, These are some specific comments - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Abstract - "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." Why we need this for NP only? ... [Pushpasis] This is not needed for NP. But the proposed solution for NP(i.e= . FSPF rooted on the PQ-node) is also necessary when we need to support LFA= -manageability, even when NP is not required. That is why we originally cho= se the title of this draft as "Remote-LFA Node Protection and Manageability= " 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 a= lternate policy ? This is not what is represented in I-D.ietf-rtgwg-lfa-man= ageability (it's prune then run alternate selection policy) [Pushpasis] As far as I understand the draft talks about what all character= istics to collect and evaluate while evaluating a alternate-selecting polic= y. Obviously for that we need to collect all those characteristics before d= oing the actual policy run. Much like how all the route-parameters of a ro= ute are learnt and collected before running a route-policy on it. Policy ca= nnot be expected to give the correct selection if appropriate characteristi= cs of the route(or alternate path) is provided to the policy. Right? In som= e implementation the policy engine may take the responsibility of collectin= g all path characteristics itself. But atleast the path characteristics nee= d to be evaluated before policy evaluation. Now looking at the path characteristics of RLFA path they are basically all= the characteristics in the LFA manageability for the each link and node on= the alternate path from PLR to PQ-node as well as from PQ-node to destinat= ion. We will be able to typically walk the links and node from PLR to PQ-no= de since we would already run a Djikstra(FSPF) rooted at 1-hop neighbor on = the path from PLR to PQ-node(standard RFC5286 implementation). However we w= ill not walk the nodes and links from PQ-node to destination, unless we run= a Djikstra(FSPF) rooted at PQ-node. 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? [Pushpasis] Yes. Typo. Will correct it while uploading next version. 4. Section 2.1 - Table 2 D2 | S->E->D1 | R3 | S=3D>N=3D>E=3D>R3->D2 The above should be S->E-R3-D2 [Pushpasis] No the shortest path from N (assuming link-protection like base= RLFA draft does) is still N->E->R3->D2. After adding the link between N an= d E, there are two PQ-nodes R2 and R3. This particular row is w.r.t R3 as t= he PQ-node. The shortest path from S to R3 that does not take S-E link is S= ->N->E->R3 (still traverses primary nexthop E). We are trying to point the issue with the assumption (i.e protect against S= -E link failure, not node-failure of E) taken by the PQ-node solution logic= in the base RLFA draft here. 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 [Pushpasis] Typo again :) Thanks for pointing out. Will correct it while up= loading next version. 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) [Pushpasis] Sure. Will change it. 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" [Pushpasis] Y is a candidate being evaluated for being in the node-protecti= ng Ext-P space. . Will correct it while uploading next version. 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- node." for all direct neighbor =3D=3D> should be replaced to indicate all eligi= ble neighbors where back is provisioned. [Pushpasis] This in my opinion is very implementation specific. So I will p= refer to keep the eligibility part outside this draft. But I agree that in case a neighbor has been configured as 'ine= ligible' for providing backup by user configuration, it should be skipped over. 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- node." Y is not PQ-node here. "PQ-node" should be replaced with node protecting= extended-p space node. [Pushpasis] Well in reality a node-protecting PQ-node will also be a link-p= rotecting PQ-node. But I will still modify the text in next version to remo= ve the linkage. 10. Section 2.3.1 In the similar grounds as above Table 3 & table 4 first column should not be "PQ-node (y)" [Pushpasis] Ok. Will correct it in next version. 11. Section 2.3.1 Though this section is trying to justify how and why the PQ nodes selec= ted 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. [Pushpasis] Sure. Will correct it in next version. 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 [Pushpasis] Typo again :). Will correct it in next version. 13. Section 2.3.2 "After 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 cog= nizant of this while loosely using PQ nodes term. [Pushpasis] Will correct it in next version. Also it's not "After running the forward SPF..", it should be "While ru= nning the forward SPF.." [Pushpasis] This is too implementation specific. Depends on wether you run = Djikstra first and then compute backup path from its results, or do everyth= ing along with the main djikstra. So I will replace it like this ... "On ru= nning the forward SPF on a candidate node-protecting PQ-node ... " 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. [Pushpasis] RemoteLFA like all other LFA mechanism is entirely a local deci= sion on the PLR. PQ-nodes chosen by two PLRs will never be same. So it shou= ld not matter. 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 poin= ts 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." [Pushpasis] This is a just a suggestion, and not a MUST. Individual impleme= ntations are free to use their own heuristics. 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 c= learly spelled out. And also this whole thing doesn't belong here and should be in http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-03 And I already see the same in Section 5.2.4.2 of the same. [Pushpasis] This is added to the LFA-manageability draft only after it was = proposed in this draft earlier. We have kept it short and simple in here. A= nd decided any further developments in this will be added in LFA-manageabil= ity draft. So all future heuristics that are being worked on will be added = in the LFA-manageability draft. -- Uma C. --_000_a3d1b5e1b4c24bcaa7c9b9efe7084f26BN1PR05MB520namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Uma,

 

First off, sorry for t= he late response. Second, thanks a lot for taking your time to review this = draft so closely. Please find some comments and resolution inline. Hoping I= am able to address all your comments.

 

Thanks

-Pushpasis<= /span>

 

From: Uma Chunduri [mailto:uma.chunduri@erics= son.com]
Sent: Friday, March 28, 2014 11:21 PM
To: rtgwg@ietf.org
Subject: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03

 

Dear Authors,

 

These are some specific comments –<= /p>

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

1. Abstract -

   "The

   document also shows how the same proced= ure 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 po= licy for eliminating paths not

   fitting constraints."

  

   Why we need this for NP only?=

   ...

[Pushpasis] This is not n= eeded for NP. But the proposed solution for NP(i.e. FSPF rooted on the PQ-n= ode) is also necessary when we need to support LFA-manageability, even when NP is not required. That is why we originally chose the title of= this draft as “Remote-LFA Nod= e Protection and Manageability“

 

2. Introduction

 

   "  Also, the LFA Manageabilit= y [I-D.ietf-rtgwg-lfa-manageability]

   document, requires a computing router t= o find all possible (including

   all possible Remote-LFA) alternate next= hops, collect the complete set

   of path characteristics for each altern= ate path, run a alternate-

   selection policy (configured by the ope= rator), and find the best

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

   gather all the required path characteri= stics along each link on the

   entire Remote-LFA alternate path."=

 

Why do we need to collect path characteristics of al= l 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)

[Push= pasis] As far as I understand the draft talks about what all characteristic= s to collect and evaluate while evaluating a alternate-selecting policy. Ob= viously for that we need to collect all those characteristics before doing the actual policy run. Much like ho= w all the route-parameters of  a route are learnt and collected before= running a route-policy on it. Policy cannot be expected to give the correc= t selection if appropriate characteristics of the route(or alternate path) is provided to the policy. Right? In some = implementation the policy engine may take the responsibility of collecting = all path characteristics itself. But atleast the path characteristics need = to be evaluated before policy evaluation.

Now l= ooking at the path characteristics of RLFA path they are basically all the = characteristics in the LFA manageability for the each link and node on the = alternate path from PLR to PQ-node as well as from PQ-node to destination. We will be able to typically walk the= links and node from PLR to PQ-node since we would already run a Djikstra(F= SPF) rooted at 1-hop neighbor on the path from PLR to PQ-node(standard RFC5= 286 implementation). However we will not walk the nodes and links from PQ-node to destination, unless we r= un a Djikstra(FSPF) rooted at PQ-node.

 

 

3. Section 2.1

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

   link-protection for all the destination= s, it does not provide node-

   protection for destinations E and F.&qu= ot;

 

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

[Push= pasis] Yes. Typo. Will correct it whil= e uploading next version.

 

4. Section 2.1 - Table 2

    D2     &= nbsp;    | S->E->D1     | R3 =      | S=3D>N=3D>E=3D>R3->D2

 

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

[Pushpasis] No the sho= rtest path from N (assuming link-protection like base RLFA draft does) is s= till N->E->R3->D2. After adding the link between N and E, there ar= e two PQ-nodes R2 and R3. This particular row is w.r.t R3 as the PQ-node. The shortest path from S to R3 that does not t= ake S-E link is S->N->E->R3 (still traverses primary nexthop E).

 

We are trying to point= the issue with the assumption (i.e protect against S-E link failure, not n= ode-failure of E) taken by the PQ-node solution logic in the base RLFA draf= t here.

 

5. Section 2.1

    "Again a closer look at Tabl= e 2 shows that, unlike Table 1, where the

   single PQ-node R2 provided node-protect= ion, 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<= /o:p>

[Pushpasis] Typo again= J Thanks for pointing out. Will correct it while uplo= ading next version.

 

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 dr= aft, per agreement earlier) to

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

 

[Pushpasis] Sure. Will= change it.

 

7.Section 2.2.2

  "It must be noted that a node Y satisfyi= ng the condition in Figure 4

   above only guarantees that the R-LFA al= ternate 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 destinati= on is also unaffected by the

   same failure event."

 

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

[Pushpasis] Y is a can= didate being evaluated for being in the node-protecting Ext-P space. . Will= correct it while uploading next version.

 

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

 

   "Implementations should run the in= equality in Section 2.2.2 Figure 4

   for all direct neighbor, other than pri= mary nexthop node E, to

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

   node."

   for all direct neighbor =3D=3D> shou= ld be replaced to indicate all eligible neighbors where back is provisioned= .

[Pushpasis] This in my= opinion is very implementation specific. So I will prefer to keep the elig= ibility part outside

this draft. But I agre= e that in case a neighbor has been configured as ‘ineligible’ f= or providing backup by

user configuration, it= should be skipped over.

 

9. Section 2.3.1

 

   " Implementations should run the i= nequality in Section 2.2.2 Figure 4

   for all direct neighbor, other than pri= mary nexthop node E, to

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

   node."

 

   Y is not PQ-node here. "PQ-node&qu= ot; should be replaced with node protecting extended-p space node.

[Pushpasis] Well in re= ality a node-protecting PQ-node will also be a link-protecting PQ-node. But= I will still modify the text in next version to remove the linkage.

 

10. Section 2.3.1

     In the similar grounds as a= bove

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

[Pushpasis] Ok. Will c= orrect it in next version.

 

11. Section 2.3.1

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

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

 

    For e.g.

  

    "So S may re-use the li= st 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 nexth= op node E does not exist on

   the list of nodes traversed on any of t= he 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 candi= date NP extended-P space.

[Pushpasis] Sure. Will= correct it in next version.

 

12. Section 2.3.1

  

    "

   As seen in the above Table 4 while R2 i= s 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 pa= th from R2 to E and F."

 

   There are no nodes G and F anywhere in = the diagrams

[Pushpasis] Typo again= J. Will correct it in next version.=

 

13. Section 2.3.2

 

    "After

   running the forward SPF on a PQ-node (f= rom the node-protecting PQ-

   space) the computing router shall run t= he inequality in Figure 6

   below.  PQ-nodes that does not qua= lify the condition for a given

   destination, does not gaurantee node-pr= otection for the path segment

   from the PQ-node to the given destinati= on."

 

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

   of this while loosely using PQ nod= es term.

[Pushpasis] Will corre= ct it in next version.

 

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

 

[Pushpasis] This is to= o implementation specific. Depends on wether you run Djikstra first and the= n compute backup path from its results, or do everything along with the mai= n djikstra. So I will replace it like this … “On running the forward SPF on a candidate node-= protecting PQ-node … “=

 

 

14. Section 2.3.3

 

    " Implementations MUST choos= e

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

   configuration knob to override the defa= ult limit.  Implementations

   MUST also evaluate some default prefere= nce 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.

[Pushpasis] RemoteLFA = like all other LFA mechanism is entirely a local decision on the PLR. PQ-no= des chosen by two PLRs will never be same. So it should not matter.

 

   But if "some default" prefere= nce is used you won't fulfill the objective of same PQ node. If this is rea= lly a goal then this document must

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

 

   The below paragraph indicates a suggest= ed default criteria and also points out further study is required to confir= m this is indeed the "default".

    I think this need to be worked ou= t.

 

   "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 route= rs 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 wher= e they are mostly deployed.

   The same can then be used for PQ-node s= election."

 

[Pushpasis] This is a = just a suggestion, and not a MUST. Individual implementations are free to u= se their own heuristics.

 

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 characte= ristics you are seeking must be clearly spelled out.

 

   And also this whole thing doesn't belon= g here and should be in

   http://tools.ietf.org/html/draft= -ietf-rtgwg-lfa-manageability-03

 

   And I already see the same in Section 5= .2.4.2 of the same.

 

[Pushpasis] This is ad= ded to the LFA-manageability draft only after it was proposed in this draft= earlier. We have kept it short and simple in here. And decided any further= developments in this will be added in LFA-manageability draft. So all future heuristics that are being worked= on will be added in the LFA-manageability draft.

 

 

--

Uma C.

 

--_000_a3d1b5e1b4c24bcaa7c9b9efe7084f26BN1PR05MB520namprd05pro_-- From nobody Tue Apr 8 02:00:14 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A011A01BF; Tue, 8 Apr 2014 02:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e2vY-V8IWuT; Tue, 8 Apr 2014 02:00:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 252361A01BB; Tue, 8 Apr 2014 02:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-psarkar-rtgwg-rlfa-node-protection-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408090001.26884.26232.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 02:00:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/NNGVS__qVcbbImj4NX5u25xi0W0 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:00:13 -0000 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 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-psarkar-rtgwg-rlfa-node-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-psarkar-rtgwg-rlfa-node-protection-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 8 07:37:01 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80541A0407 for ; Tue, 8 Apr 2014 07:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-xJFxjaO8uv for ; Tue, 8 Apr 2014 07:36:55 -0700 (PDT) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id E90AF1A03FD for ; Tue, 8 Apr 2014 07:36:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,818,1389762000"; d="scan'208";a="34997577" Received: from unknown (HELO wv1-cas-02.vsnl.co.in) ([64.86.157.138]) by mx3-2.tatacommunications.com with ESMTP; 08 Apr 2014 10:36:54 -0400 Received: from USWV1VCAS01.vsnl.co.in (64.86.157.177) by wv1-cas-02.vsnl.co.in (64.86.157.138) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 8 Apr 2014 10:36:53 -0400 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas01.vsnl.co.in ([fe80::6521:bbe2:f2e4:7b9b%11]) with mapi id 14.03.0158.001; Tue, 8 Apr 2014 10:36:54 -0400 From: Arun Arumuganainar To: "rtgwg@ietf.org" Subject: Requesting Comments about the Draft : draft-arumuganainar-rtgwg-dps-requirements-00.txt Thread-Topic: Requesting Comments about the Draft : draft-arumuganainar-rtgwg-dps-requirements-00.txt Thread-Index: Ac9TN+sLi2nu02ehQQKZvkxKmKk3hw== Date: Tue, 8 Apr 2014 14:36:53 +0000 Message-ID: <8E0F17CF07213C4882E85670E17849E1A03BED2B@uswv1vdag02.vsnl.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.86.157.8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/wg8x7Q5XovFg0WvRv90KPJyEFTk X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:37:00 -0000 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 frame= work for DPS - I have also included existing implementation and Gap analysis 2) DPS Use cases :- (draft-arumuganainar-rtgwg-dps-use-cases-00)=20 - Document all the use cases for DPS - Majority of the use cases taken from existing implementation. I have als= o 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 o= riginal 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 imp= lementation, 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 a= s 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 tun= e the DPS behaviour to adapt to dynamic network conditions. I have document= ed this requirement in a separate draft. This draft proposes to do the sign= alling at the TCP layer . It would be great if you can review this draft as= well (draft-arumuganainar-rtgwg-dps-l4-ppn-00 ) . It would be great if you can review this for me and let me know if there ar= e any feedback or comments. Thanks and Regards Arun Arun Arumuganainar CCIE#16918 ( R&S and SP ) =20 Technical Design Authority=20 Advanced Solution Delivery Tata Communications Limited Direct +44 207 029 9513=A0=A0=A0|=A0=A0Fax +44 207 519 4609=A0=A0=A0|=A0=A0= Mobile +44 7771 831 052=A0=A0=A0|=A0=A0IP 709513 arun.arumuganainar@tatacommunications.com _____________________________________________ From: Arun Arumuganainar=20 Sent: 15 October 2013 19:46 To: 'rtgwg@ietf.org' Subject: Requesting Comments about the Draft : draft-aumuganainar-rtgwg-dps= -00 Hello all, I have posted a following draft - Dynamic Path selection ( Based on Applica= tion ). http://www.ietf.org/internet-drafts/draft-aumuganainar-rtgwg-dps-00= .txt In the draft I have proposed a network design architecture for routing pack= ets via different paths available in the network based on application port = number. Primarily, this is targeted for Enterprise customers who have built= up redundancy at their WAN edge but are suffering from a congested primary= link whilst the secondary is idle. The objective of this architecture is as follows 1) Offload bulky application on to the secondary link =20 2) Achieve the above without introducing asymmetric routing in the netwo= rk It would be great if you can review this draft and respond back with any co= mments. Thanks very much. Thanks and Regards Arun Arun Arumuganainar CCIE#16918 ( R&S and SP ) =20 Technical Design Authority=20 Advanced Solution Delivery Tata Communications Limited Direct +44 207 029 9513=A0=A0=A0|=A0=A0Fax +44 207 519 4609=A0=A0=A0|=A0=A0= Mobile +44 7771 831 052=A0=A0=A0|=A0=A0IP 709513 arun.arumuganainar@tatacommunications.com From nobody Tue Apr 8 16:21:17 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F9C1A02F3 for ; Tue, 8 Apr 2014 16:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9Skqv8e2lut for ; Tue, 8 Apr 2014 16:21:13 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 033601A0761 for ; Tue, 8 Apr 2014 16:21:12 -0700 (PDT) X-AuditID: c6180641-b7f638e000005a82-ea-53448181475b Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AE.49.23170.18184435; Wed, 9 Apr 2014 01:08:49 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 19:21:12 -0400 From: Uma Chunduri To: Pushpasis Sarkar , "rtgwg@ietf.org" Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thread-Topic: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thread-Index: Ac9KrcDA735FKnU5Tr2dhjVMzaaMzAD0oy8AATc/e9A= Date: Tue, 8 Apr 2014 23:21:11 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F25F3EF@eusaamb105.ericsson.se> References: <1B502206DFA0C544B7A60469152008633F23168E@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F25F3EFeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPiG5jo0uwwdyjyhZX9nxmsrjw5jez xde9D1kdmD2WLPnJ5HG96Sq7R8uzk2wBzFFcNimpOZllqUX6dglcGR+un2cr6OhirJjbs4Kp gfFARRcjJ4eEgInEltPH2SBsMYkL99YD2VwcQgJHGSUuvd4F5SxjlPj/aRMLSBWbgJ7Ex6k/ 2UFsEQFfiY0dV8C6mQXsJRa3rmAEsYUFXCTafu5khKhxlfh4/DgThG0lcWLpS1YQm0VARWJ3 90KwObxAc26vbmSCWDaTUWJJ+yWwBk6BMInDL/rBbEag876fWsMEsUxc4taT+UwQZwtILNlz nhnCFpV4+fgfK4StKLGvfzo7RH2+xOJb66CWCUqcnPmEZQKj6Cwko2YhKZuFpAwiridxY+oU NghbW2LZwtfMELauxIx/h1iQxRcwsq9i5CgtTi3LTTcy3MQIjLdjEmyOOxgXfLI8xCjNwaIk zvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZ4y9y+0+st+eUiO+SP2oVf1k13qp7e 6z0/qjTA6IBaPVfM3qa9y9YnnIxQDLs6w9JD5NxZvWLXp+YKpaVvTj1NefSJ5Y3JYZNLvcHi pg/ut93r2P1IZEdjg5dYzS0eoYfWBxTm2su6C9SmZT1lbjA1vlXx43aoLU9K2o7fQRZfIk22 Jc5sVmIpzkg01GIuKk4EAPuFvW2FAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/l6Yem2IAAOd1shLIvdKNk5XOm08 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 23:21:16 -0000 --_000_1B502206DFA0C544B7A60469152008633F25F3EFeusaamb105erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thought to reply for this earlier but missed it. Most of the things are fi= ne but I have few comments as described below - -- Uma C. From: Pushpasis Sarkar [mailto:psarkar@juniper.net] Sent: Wednesday, April 02, 2014 3:32 AM To: Uma Chunduri; rtgwg@ietf.org Cc: LITKOWSKI Stephane DTF/DERX Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Hi Uma, First off, sorry for the late response. [Uma]: :), I think I matched your response! ... 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 a= lternate policy ? This is not what is represented in I-D.ietf-rtgwg-lfa-man= ageability (it's prune then run alternate selection policy) [Pushpasis] As far as I understand the draft talks about what all character= istics to collect and evaluate while evaluating a alternate-selecting polic= y. Obviously for that we need to collect all those characteristics before d= oing the actual policy run. Much like how all the route-parameters of a ro= ute are learnt and collected before running a route-policy on it. Policy ca= nnot be expected to give the correct selection if appropriate characteristi= cs of the route(or alternate path) is provided to the policy. Right? In som= e implementation the policy engine may take the responsibility of collectin= g all path characteristics itself. But atleast the path characteristics nee= d to be evaluated before policy evaluation. [Uma]: The main issue I observed in the above paragraph is - you are aski= ng to collect all possible path characteristics (which can be as many as 50= 0+ FSPFs depending on the topology) then run the alternate policy.. " all possible Remote-LFA) alternate nexthops, collect the complete set of path characteristics for each alternate path, run a alternate- selection policy" I think you need to clarify here that after heuristics (default or whatever= ) the pruned version of candidate NP PQs are considered as input for the po= licy for the best alternate path. You can see; it's quite possible, after the heuristics and the operator po= licy you may not get any NP PQ at the end (so be it). ... 4. Section 2.1 - Table 2 D2 | S->E->D1 | R3 | S=3D>N=3D>E=3D>R3->D2 The above should be S->E-R3-D2 [Pushpasis] No the shortest path from N (assuming link-protection like base= RLFA draft does) is still N->E->R3->D2. After adding the link between N an= d E, there are two PQ-nodes R2 and R3. This particular row is w.r.t R3 as t= he PQ-node. The shortest path from S to R3 that does not take S-E link is S= ->N->E->R3 (still traverses primary nexthop E). We are trying to point the issue with the assumption (i.e protect against S= -E link failure, not node-failure of E) taken by the PQ-node solution logic= in the base RLFA draft here. [Uma]: D2 | S->E->D1 =3D=3D> be S->E->R3->D2 (:)) 14. Section 2.3.3 [Pushpasis] RemoteLFA like all other LFA mechanism is entirely a local deci= sion on the PLR. PQ-nodes chosen by two PLRs will never be same. So it shou= ld not matter. [Uma]:. Of course, it will not be same. I was not talking about PQ-nodes f= or 2 PLRs I was rather talking about, same and predictable PQ node from = the SAME PLR for different vendors (for manageability purposes, that's wha= t you got to aim for at minimum). Please read through my original comment a= gain! --_000_1B502206DFA0C544B7A60469152008633F25F3EFeusaamb105erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thought to reply for t= his  earlier but missed it. Most of the things are fine but I have few= comments as described below -

 

--

Uma C.

 

From: Pushpasi= s Sarkar [mailto:psarkar@juniper.net]
Sent: Wednesday, April 02, 2014 3:32 AM
To: Uma Chunduri; rtgwg@ietf.org
Cc: LITKOWSKI Stephane DTF/DERX
Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03=

 

Hi Uma,

 

First off, sorry for t= he late response.

[Uma]: J, I think I matched your response!

 

   ...

 

2. Introduction

 

   "  Also, the LFA Manageabilit= y [I-D.ietf-rtgwg-lfa-manageability]

   document, requires a computing router t= o find all possible (including

   all possible Remote-LFA) alternate next= hops, collect the complete set

   of path characteristics for each altern= ate path, run a alternate-

   selection policy (configured by the ope= rator), and find the best

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

   gather all the required path characteri= stics along each link on the

   entire Remote-LFA alternate path."=

 

Why do we need to collect path characteristics of al= l 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)

[Push= pasis] As far as I understand the draft talks about what all characteristic= s to collect and evaluate while evaluating a alternate-selecting policy. Ob= viously for that we need to collect all those characteristics before doing the actual policy run. Much like ho= w all the route-parameters of  a route are learnt and collected before= running a route-policy on it. Policy cannot be expected to give the correc= t selection if appropriate characteristics of the route(or alternate path) is provided to the policy. Right? In some = implementation the policy engine may take the responsibility of collecting = all path characteristics itself. But atleast the path characteristics need = to be evaluated before policy evaluation.

 

[Uma]: The main issue =  I observed in the above paragraph is  - you are asking to collec= t all possible path characteristics (which can be as many as 500+ FSPFs depending on the topology) then run the alter= nate policy..

 

“   all possible Remote-LFA) alterna= te nexthops, collect the complete set

   of path characteristics for each altern= ate path, run a alternate-

   selection policy”

 

I think you need to cl= arify here that after heuristics (default or whatever) the pruned version o= f candidate NP PQs are considered as input for the policy for the best alternate path.

You can see; it’= s quite possible, after the heuristics and the  operator policy you ma= y not  get any NP PQ at the end (so be it).

 

…

 

4. Section 2.1 - Table 2

    D2     &= nbsp;    | S->E->D1     | R3 =      | S=3D>N=3D>E=3D>R3->D2

 

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

[Pushpasis] No the sho= rtest path from N (assuming link-protection like base RLFA draft does) is s= till N->E->R3->D2. After adding the link between N and E, there ar= e two PQ-nodes R2 and R3. This particular row is w.r.t R3 as the PQ-node. The shortest path from S to R3 that does not t= ake S-E link is S->N->E->R3 (still traverses primary nexthop E).

We are trying to point= the issue with the assumption (i.e protect against S-E link failure, not n= ode-failure of E) taken by the PQ-node solution logic in the base RLFA draf= t here.

 

[Uma]:   &nb= sp; D2          | S->E->= D1     =E8 be S->E->R3->D2 (J)

 

14. Section 2.3.3

 

[Pushpasis] RemoteLFA = like all other LFA mechanism is entirely a local decision on the PLR. PQ-no= des chosen by two PLRs will never be same. So it should not matter.

 

[Uma]:.  Of cours= e, it will not be same. I was not talking about PQ-nodes for 2 PLRs

   &nbs= p;         I was rather talking abo= ut, same and predictable PQ node from the SAME PLR for different vendors &n= bsp;(for manageability purposes, that’s what you got to aim for at minimum). Please read through my o= riginal comment again!

   &nbs= p;  

 

 

 

--_000_1B502206DFA0C544B7A60469152008633F25F3EFeusaamb105erics_-- From nobody Wed Apr 9 04:40:30 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAAB1A00E6 for ; Wed, 9 Apr 2014 04:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idIdAuyDiH9S for ; Wed, 9 Apr 2014 04:40:23 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1861A011D for ; Wed, 9 Apr 2014 04:40:22 -0700 (PDT) Received: from mail55-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE022.bigfish.com (10.3.207.144) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Apr 2014 11:40:01 +0000 Received: from mail55-am1 (localhost [127.0.0.1]) by mail55-am1-R.bigfish.com (Postfix) with ESMTP id 20B783800F6; Wed, 9 Apr 2014 11:40:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic89bhc85fh168aJzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail55-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(377454003)(189002)(199002)(57704003)(80022001)(19580395003)(19580405001)(83322001)(95416001)(33646001)(49866001)(15975445006)(66066001)(99396002)(16236675002)(90146001)(93136001)(19300405004)(83072002)(92566001)(77096001)(47736002)(19609705001)(77982001)(95666003)(54316003)(65816002)(79102001)(59766002)(94316002)(54356002)(63696004)(56816006)(47446003)(81686001)(15202345003)(80976001)(85852003)(46102001)(93516002)(81342001)(20776003)(69226001)(74366001)(87936001)(4396001)(76796001)(74876001)(81816001)(86362001)(31966008)(74662001)(74706001)(74502001)(76576001)(76786001)(81542001)(97336001)(98676001)(74316001)(76482001)(2656002)(97186001)(94946001)(53806002)(50986002)(56776002)(47976003)(85306002)(87266001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB517; H:BN1PR05MB520.namprd05.prod.outlook.com; FPR:CEB0FE1D.AFCA95A2.F1D1304B.8EFDDA41.205C5; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1 (MessageSwitch) id 1397043598397245_1233; Wed, 9 Apr 2014 11:39:58 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.244]) by mail55-am1.bigfish.com (Postfix) with ESMTP id 52E8460067; Wed, 9 Apr 2014 11:39:58 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Apr 2014 11:39:58 +0000 Received: from BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 9 Apr 2014 11:40:17 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 9 Apr 2014 11:40:10 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.240]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.69]) with mapi id 15.00.0898.005; Wed, 9 Apr 2014 11:40:10 +0000 From: Pushpasis Sarkar To: Uma Chunduri , "rtgwg@ietf.org" Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thread-Topic: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thread-Index: AQHPSrgG3PkuL/+RM0WZdllDTnHOMZr+DFeggApgrYCAAMHZIA== Date: Wed, 9 Apr 2014 11:40:09 +0000 Message-ID: <12347b6b6eb2435190960aa432299e72@BN1PR05MB520.namprd05.prod.outlook.com> References: <1B502206DFA0C544B7A60469152008633F23168E@eusaamb105.ericsson.se> <1B502206DFA0C544B7A60469152008633F25F3EF@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F25F3EF@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.18] x-forefront-prvs: 01762B0D64 Content-Type: multipart/alternative; boundary="_000_12347b6b6eb2435190960aa432299e72BN1PR05MB520namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/pLqtZ-PNbSCf78ylz1qHVzJo398 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:40:27 -0000 --_000_12347b6b6eb2435190960aa432299e72BN1PR05MB520namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Uma, Please find comments and responses inline. Thanks -Pushpasis From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Wednesday, April 09, 2014 4:51 AM To: Pushpasis Sarkar; rtgwg@ietf.org Cc: LITKOWSKI Stephane DTF/DERX Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Thought to reply for this earlier but missed it. Most of the things are fi= ne but I have few comments as described below - -- Uma C. From: Pushpasis Sarkar [mailto:psarkar@juniper.net] Sent: Wednesday, April 02, 2014 3:32 AM To: Uma Chunduri; rtgwg@ietf.org Cc: LITKOWSKI Stephane DTF/DERX Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03 Hi Uma, First off, sorry for the late response. [Uma]: :), I think I matched your response! ... 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 a= lternate policy ? This is not what is represented in I-D.ietf-rtgwg-lfa-man= ageability (it's prune then run alternate selection policy) [Pushpasis] As far as I understand the draft talks about what all character= istics to collect and evaluate while evaluating a alternate-selecting polic= y. Obviously for that we need to collect all those characteristics before d= oing the actual policy run. Much like how all the route-parameters of a ro= ute are learnt and collected before running a route-policy on it. Policy ca= nnot be expected to give the correct selection if appropriate characteristi= cs of the route(or alternate path) is provided to the policy. Right? In som= e implementation the policy engine may take the responsibility of collectin= g all path characteristics itself. But atleast the path characteristics nee= d to be evaluated before policy evaluation. [Uma]: The main issue I observed in the above paragraph is - you are aski= ng to collect all possible path characteristics (which can be as many as 50= 0+ FSPFs depending on the topology) then run the alternate policy.. [Pushpasis] No, this paragraph is not asking to do so, it just clarifying w= hat is required if we need to support LFA-manageability for RLFA. Ideally w= e should be running FSPF on all possible PQ-nodes and evaluate all possible= RLFA alternate paths. In section 2.3.2 of this draft we mentioned that whi= le finding all possible RLFA paths will be ideal it will not be feasible an= d hence we recommend to limit the search with upto 16 PQ-nodes. " all possible Remote-LFA) alternate nexthops, collect the complete set of path characteristics for each alternate path, run a alternate- selection policy" I think you need to clarify here that after heuristics (default or whatever= ) the pruned version of candidate NP PQs are considered as input for the po= licy for the best alternate path. You can see; it's quite possible, after the heuristics and the operator po= licy you may not get any NP PQ at the end (so be it). [Pushpasis] Yes its quite possible. And that applies to the LFA-manageabili= ty draft as well. With the operator's choice of alternate policy certain de= stinations may end up with ZERO protection though there were feasible alter= nate paths. Point is whenever any policy is being used, while it provides a= powerful tool to achieve a lot, the same can be misused or used without ad= equate awareness of its consequences leading to undesired behavior. IMO, a = draft should be listing out what all could be achieved with this solution a= nd not listing out extensively what all cannot be achieved. But if the grou= p members still insist I will add some text in next version. ... 4. Section 2.1 - Table 2 D2 | S->E->D1 | R3 | S=3D>N=3D>E=3D>R3->D2 The above should be S->E-R3-D2 [Pushpasis] No the shortest path from N (assuming link-protection like base= RLFA draft does) is still N->E->R3->D2. After adding the link between N an= d E, there are two PQ-nodes R2 and R3. This particular row is w.r.t R3 as t= he PQ-node. The shortest path from S to R3 that does not take S-E link is S= ->N->E->R3 (still traverses primary nexthop E). We are trying to point the issue with the assumption (i.e protect against S= -E link failure, not node-failure of E) taken by the PQ-node solution logic= in the base RLFA draft here. [Uma]: D2 | S->E->D1 =3D=3D> be S->E->R3->D2 (:)) [Pushpasis] Ack. One more typo :( I should have waited some more time for y= our response. 14. Section 2.3.3 [Pushpasis] RemoteLFA like all other LFA mechanism is entirely a local deci= sion on the PLR. PQ-nodes chosen by two PLRs will never be same. So it shou= ld not matter. [Uma]:. Of course, it will not be same. I was not talking about PQ-nodes f= or 2 PLRs I was rather talking about, same and predictable PQ node from = the SAME PLR for different vendors (for manageability purposes, that's wha= t you got to aim for at minimum). Please read through my original comment a= gain! [Pushpasis] Uma do you foresee one single node running multiple vendor impl= ementations? If not this is not a concern in my opinion. If you are replaci= ng PLR from one vendor implementation to another it will either use the sam= e heuristics or the operator is fine with the new different heuristics. Aga= in the point is we don't want any vendor implementation to not implement a = better heuristics if they have found one because this draft has made it man= datory. --_000_12347b6b6eb2435190960aa432299e72BN1PR05MB520namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Uma,

 

Please find comments a= nd responses inline.

 

Thanks

-Pushpasis<= /span>

 

From: Uma Chunduri [mailto:uma.chunduri@erics= son.com]
Sent: Wednesday, April 09, 2014 4:51 AM
To: Pushpasis Sarkar; rtgwg@ietf.org
Cc: LITKOWSKI Stephane DTF/DERX
Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03=

 

Thought to reply for t= his  earlier but missed it. Most of the things are fine but I have few= comments as described below -

 

--

Uma C.

 

From: Pushpasi= s Sarkar [mailto:psarkar@juniper.net= ]
Sent: Wednesday, April 02, 2014 3:32 AM
To: Uma Chunduri; rtgwg@ietf.org
Cc: LITKOWSKI Stephane DTF/DERX
Subject: RE: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03=

 

Hi Uma,

 

First off, sorry for t= he late response.

[Uma]: J, I think I matched your response!

 

   ...

 

2. Introduction

 

   "  Also, the LFA Manageabilit= y [I-D.ietf-rtgwg-lfa-manageability]

   document, requires a computing router t= o find all possible (including

   all possible Remote-LFA) alternate next= hops, collect the complete set

   of path characteristics for each altern= ate path, run a alternate-

   selection policy (configured by the ope= rator), and find the best

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

   gather all the required path characteri= stics along each link on the

   entire Remote-LFA alternate path."=

 

Why do we need to collect path characteristics of al= l 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)

[Push= pasis] As far as I understand the draft talks about what all characteristic= s to collect and evaluate while evaluating a alternate-selecting policy. Ob= viously for that we need to collect all those characteristics before doing the actual policy run. Much like ho= w all the route-parameters of  a route are learnt and collected before= running a route-policy on it. Policy cannot be expected to give the correc= t selection if appropriate characteristics of the route(or alternate path) is provided to the policy. Right? In some = implementation the policy engine may take the responsibility of collecting = all path characteristics itself. But atleast the path characteristics need = to be evaluated before policy evaluation.

 

[Uma]: The main issue =  I observed in the above paragraph is  - you are asking to collec= t all possible path characteristics (which can be as many as 500+ FSPFs= depending on the topology) then run the alternate policy..

[Pushpasis] No, thi= s paragraph is not asking to do so, it just clarifying what is required if = we need to support LFA-manageability for RLFA. Ideally we should be running= FSPF on all possible PQ-nodes and evaluate all possible RLFA alternate paths. In section 2.3.2 of this draft we menti= oned that while finding all possible RLFA paths will be ideal it will not b= e feasible and hence we recommend to limit the search with upto 16 PQ-nodes= .

 

“   all possible Remote-LFA) alterna= te nexthops, collect the complete set

   of path characteristics for each altern= ate path, run a alternate-

   selection policy”

 

I think you need to cl= arify here that after heuristics (default or whatever) the pruned version o= f candidate NP PQs are considered as input for the policy for the best alte= rnate path.

You can see; it’= s quite possible, after the heuristics and the  operator policy you ma= y not  get any NP PQ at the end (so be it).

[Pushpasis] Yes its= quite possible. And that applies to the LFA-manageability draft as well. W= ith the operator’s choice of alternate policy certain destinations ma= y end up with ZERO protection though there were feasible alternate paths. Point is whenever any policy is being used,= while it provides a powerful tool to achieve a lot, the same can be misuse= d or used without adequate awareness of its consequences leading to undesir= ed behavior. IMO, a draft should be listing out what all could be achieved with this solution and not listi= ng out extensively what all cannot be achieved. But if the group members st= ill insist I will add some text in next version.

 

…

 

4. Section 2.1 - Table 2

    D2     &= nbsp;    | S->E->D1     | R3 =      | S=3D>N=3D>E=3D>R3->D2

 

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

[Pushpasis] No the sho= rtest path from N (assuming link-protection like base RLFA draft does) is s= till N->E->R3->D2. After adding the link between N and E, there ar= e two PQ-nodes R2 and R3. This particular row is w.r.t R3 as the PQ-node. The shortest path from S to R3 that does not t= ake S-E link is S->N->E->R3 (still traverses primary nexthop E).

We are trying to point= the issue with the assumption (i.e protect against S-E link failure, not n= ode-failure of E) taken by the PQ-node solution logic in the base RLFA draf= t here.

 

[Uma]:   &nb= sp; D2          | S->E->= D1     è<= span style=3D"color:#984807"> be S->E->R3->D2 (J)

[Pushpasis] Ack. On= e more typo L<= /b> I should have waited some more time fo= r your response.

 

14. Section 2.3.3

 

[Pushpasis] RemoteLFA = like all other LFA mechanism is entirely a local decision on the PLR. PQ-no= des chosen by two PLRs will never be same. So it should not matter.

 

[Uma]:.  Of cours= e, it will not be same. I was not talking about PQ-nodes for 2 PLRs

   &nbs= p;         I was rather talking abo= ut, same and predictable PQ node from the SAME PLR for different vendors &n= bsp;(for manageability purposes, that’s what you got to aim for at mi= nimum). Please read through my original comment again!

[Pushpasis] Uma do = you foresee one single node running multiple vendor implementations? If not= this is not a concern in my opinion. If you are replacing PLR from one ven= dor implementation to another it will either use the same heuristics or the operator is fine with the new differ= ent heuristics. Again the point is we don’t want any vendor implement= ation to not implement a better heuristics if they have found one because t= his draft has made it mandatory.

 

   &nbs= p;  

 

 

 

--_000_12347b6b6eb2435190960aa432299e72BN1PR05MB520namprd05pro_-- From nobody Wed Apr 9 08:29:15 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72D1A02DA for ; Wed, 9 Apr 2014 08:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWQSgF2JG9Kk for ; Wed, 9 Apr 2014 08:29:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 368581A02AA for ; Wed, 9 Apr 2014 08:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3385; q=dns/txt; s=iport; t=1397057351; x=1398266951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NE3cnVARgGOxcM1vPYrHGW5AhxAUFheJoRHFM+peOmI=; b=aCcal02TliBbOe1yLrvR0S7aM/l2kA2yciC67swBILHrUAFrwSzo0bDN 7za3MzwE1wsw5QPQKqmNBo79bzhpTtIE3pS8kbhgAVWv9ES1+19/D1pHM QP4fE5GUQrDPSuXGvOfAZpHSk3lnnq3jT8i9+PnUmWbtdOBIKUsZs9G3A M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAJJmRVOtJV2Y/2dsb2JhbABZgkJEO1fEDIEgFnSCJgEBBB1cEAIBCAQ7BzIUEQIEDgWHfA3MQxMEjmgEB4Q4BJhekkKDMIIr X-IronPort-AV: E=Sophos;i="4.97,826,1389744000"; d="scan'208,217";a="316224202" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 09 Apr 2014 15:29:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s39FT9jX025399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Apr 2014 15:29:09 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.227]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 9 Apr 2014 10:29:09 -0500 From: "Alvaro Retana (aretana)" To: "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Topic: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Index: AQHPP0MEPVYrj3DVB0qc+EV5ws0qppsJoycA Date: Wed, 9 Apr 2014 15:29:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CF6ADE3F53F19aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/uCLaVPu_wy24qMA-A39pHhpKSeQ Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:29:15 -0000 --_000_CF6ADE3F53F19aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors: Hi! Since the start of the WG Adoption Call for this draft, an IPR Disclosure w= as submitted: https://datatracker.ietf.org/ipr/2334/ Please respond to this message indicating whether or not you are aware of a= ny relevant IPR beyond what has been disclosed to far. Please keep in mind= that we expect individual replies from each author. Thanks! Alvaro. On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_CF6ADE3F53F19aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <897E30732DE9C84BA92A6C95179B2B63@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Authors:

Hi!

Please respond to this message indicating whether or not you are aware= of any relevant IPR beyond what has been disclosed t= o far.  Please keep in mind that we expect individual replies from eac= h author.

Thanks!

Alvaro.

On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WG Adoption Call for this draft, I want to for= mally ask the authors (no additional contributors are listed in the latest = version) to please respond to this message indicating whether or not you ar= e aware of any relevant IPR.  The draft will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

Thanks!

Alvaro.

 --_000_CF6ADE3F53F19aretanaciscocom_-- From nobody Wed Apr 9 08:44:09 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFEB1A0392 for ; Wed, 9 Apr 2014 08:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkewdjD0xfUa for ; Wed, 9 Apr 2014 08:44:05 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id BA3AD1A0395 for ; Wed, 9 Apr 2014 08:44:04 -0700 (PDT) Received: from mail222-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Apr 2014 15:43:43 +0000 Received: from mail222-va3 (localhost [127.0.0.1]) by mail222-va3-R.bigfish.com (Postfix) with ESMTP id 08E564402FA; Wed, 9 Apr 2014 15:43:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371Ic85fh103dK1519Mzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail222-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(24454002)(41574002)(377454003)(479174003)(189002)(199002)(54014002)(31966008)(86362001)(74662001)(74502001)(74706001)(87936001)(76796001)(74366001)(74876001)(4396001)(81816001)(76576001)(76482001)(74316001)(2656002)(98676001)(56776002)(50986002)(47976003)(85306002)(87266001)(94946001)(97186001)(53806002)(76786001)(97336001)(81542001)(90146001)(16236675002)(19300405004)(93516002)(92566001)(83072002)(93136001)(80022001)(83322001)(19580395003)(19580405001)(66066001)(99396002)(95416001)(33646001)(49866001)(15975445006)(20776003)(81342001)(81686001)(85852003)(46102001)(15202345003)(80976001)(69226001)(95666003)(77982001)(47736002)(19609705001)(77096001)(47446003)(59766002)(63696004)(94316002)(54356002)(54316003)(65816002)(79102001)(56816006)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB517; H:BN1PR05MB520.namprd05.prod.outlook.com; FPR:3F9D44CA.80D0E5E5.F5EDCDB3.A4D99AA8.201F8; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en ; Received: from mail222-va3 (localhost.localdomain [127.0.0.1]) by mail222-va3 (MessageSwitch) id 1397058220423191_25691; Wed, 9 Apr 2014 15:43:40 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.250]) by mail222-va3.bigfish.com (Postfix) with ESMTP id 63F86AC00B0; Wed, 9 Apr 2014 15:43:40 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Apr 2014 15:43:40 +0000 Received: from BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 9 Apr 2014 15:44:00 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 9 Apr 2014 15:43:57 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.240]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.69]) with mapi id 15.00.0898.005; Wed, 9 Apr 2014 15:43:57 +0000 From: Pushpasis Sarkar To: "Alvaro Retana (aretana)" , "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" Subject: RE: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Topic: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Index: AQHPP0MEPVYrj3DVB0qc+EV5ws0qppsJoycA///zE7A= Date: Wed, 9 Apr 2014 15:43:56 +0000 Message-ID: <8394f3d75b394b3f808bd7a85d53b8d8@BN1PR05MB520.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-forefront-prvs: 01762B0D64 Content-Type: multipart/alternative; boundary="_000_8394f3d75b394b3f808bd7a85d53b8d8BN1PR05MB520namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/OMJVsBT8d1TuAt2J1RzEmT2SGCc Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:44:07 -0000 --_000_8394f3d75b394b3f808bd7a85d53b8d8BN1PR05MB520namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alvaro, I am not aware of any other IPR other than the one mentioned below. Thanks -Pushpasis From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Wednesday, April 09, 2014 8:59 PM To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Authors: Hi! Since the start of the WG Adoption Call for this draft, an IPR Disclosure w= as submitted: https://datatracker.ietf.org/ipr/2334/ Please respond to this message indicating whether or not you are aware of a= ny relevant IPR beyond what has been disclosed to far. Please keep in mind= that we expect individual replies from each author. Thanks! Alvaro. On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_8394f3d75b394b3f808bd7a85d53b8d8BN1PR05MB520namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

 <= /p>

I am not aware of any oth= er IPR other than the one mentioned below.

 <= /p>

Thanks<= /p>

-Pushpasis

 <= /p>

From: Alvaro= Retana (aretana) [mailto:aretana@cisco.com]
Sent: Wednesday, April 09, 2014 8:59 PM
To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-pro= tection

 

Authors:<= /p>

 

Hi!

 

Since the start of the WG A= doption Call for this draft, an IPR Disclosure was submitted: https://datatracker.ietf.org/ipr= /2334/

 

Please respond to this mess= age indicating whether or not you are aware of any relevant IPR beyond what has been disclosed to far.  Please keep in mind tha= t we expect individual replies from each author.

 

Thanks!

 

Alvaro.

 

On 3/14/14 1:05 AM, "A= lvaro Retana (aretana)" <areta= na@cisco.com> wrote:

 

Hi!

 

In parallel to the WG Adopt= ion Call for this draft, I want to formally ask the authors (no additi= onal contributors are listed in the latest version) to please respond to this message indicating whether or not you are aware of any rel= evant IPR.  The draft will not progress (pending the results of the WG= Adoption Call) until we have received a response from each author.

 

Thanks!

 

Alvaro.

 

--_000_8394f3d75b394b3f808bd7a85d53b8d8BN1PR05MB520namprd05pro_-- From nobody Thu Apr 10 06:22:37 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0211A0274 for ; Thu, 10 Apr 2014 06:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFzkEwtAqDya for ; Thu, 10 Apr 2014 06:22:32 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 047B41A0136 for ; Thu, 10 Apr 2014 06:22:31 -0700 (PDT) Received: from mail92-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 13:22:07 +0000 Received: from mail92-ch1 (localhost [127.0.0.1]) by mail92-ch1-R.bigfish.com (Postfix) with ESMTP id 20E4B1A0611; Thu, 10 Apr 2014 13:22:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: VPS-15(zzbb2dI98dI9371I103dKe238szz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL8275bh8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: pass (mail92-ch1: domain of juniper.net designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=hannes@juniper.net; helo=CH1PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail92-ch1 (localhost.localdomain [127.0.0.1]) by mail92-ch1 (MessageSwitch) id 1397136124772504_19797; Thu, 10 Apr 2014 13:22:04 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail92-ch1.bigfish.com (Postfix) with ESMTP id B87432A004A; Thu, 10 Apr 2014 13:22:04 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 13:22:02 +0000 Received: from juniper.net (193.110.55.16) by pod51010.outlook.com (10.255.150.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 10 Apr 2014 13:22:24 +0000 Date: Thu, 10 Apr 2014 15:22:19 +0200 From: Hannes Gredler To: "Alvaro Retana (aretana)" Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Message-ID: <20140410132219.GB9633@juniper.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.16] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/ndQeEqheedz8KdzQlQq1hnlejwo Cc: "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:22:36 -0000 hi alvaro, i am not aware about any IPR that has not been disclosed in https://datatracker.ietf.org/ipr/2334/ /hannes On Wed, Apr 09, 2014 at 03:29:08PM +0000, Alvaro Retana (aretana) wrote: | Authors: | Hi! | Since the start of the WG Adoption Call for this draft, an IPR Disclosure | was submitted: https://datatracker.ietf.org/ipr/2334/ | Please respond to this message indicating whether or not you are aware of | any relevant IPR beyond what has been disclosed to far. Please keep in | mind that we expect individual replies from each author. | Thanks! | Alvaro. | On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" wrote: | | Hi! | In parallel to the WG Adoption Call for this draft, I want to formally | ask the authors (no additional contributors are listed in the latest | version) to please respond to this message indicating whether or not you | are aware of any relevant IPR. The draft will not progress (pending the | results of the WG Adoption Call) until we have received a response from | each author. | Thanks! | Alvaro. | _______________________________________________ | rtgwg mailing list | rtgwg@ietf.org | https://www.ietf.org/mailman/listinfo/rtgwg From nobody Thu Apr 10 06:49:21 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695C11A01D2 for ; Thu, 10 Apr 2014 06:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8sUyAW_bSNW for ; Thu, 10 Apr 2014 06:49:08 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id EAC981A0183 for ; Thu, 10 Apr 2014 06:49:07 -0700 (PDT) Received: from mail67-co9-R.bigfish.com (10.236.132.247) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 13:48:43 +0000 Received: from mail67-co9 (localhost [127.0.0.1]) by mail67-co9-R.bigfish.com (Postfix) with ESMTP id 81BB41E00A6; Thu, 10 Apr 2014 13:48:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371Ic85fh103dK1519Mzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzc2hz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail67-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(24454002)(199002)(54014002)(479174003)(377454003)(41574002)(92566001)(76576001)(15975445006)(85852003)(19609705001)(77982001)(87936001)(46102001)(83072002)(86362001)(15202345003)(74502001)(80022001)(66066001)(74316001)(99396002)(33646001)(76482001)(79102001)(20776003)(19300405004)(81342001)(83322001)(81542001)(16236675002)(31966008)(80976001)(74662001)(19580395003)(4396001)(2656002)(19580405001)(54356999)(50986999)(76176999)(77096999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB515; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:3C9D44CA.8CD0E5E5.F9EDFDB3.A4D99AA8.2021E; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:; Received: from mail67-co9 (localhost.localdomain [127.0.0.1]) by mail67-co9 (MessageSwitch) id 1397137721231999_19419; Thu, 10 Apr 2014 13:48:41 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.247]) by mail67-co9.bigfish.com (Postfix) with ESMTP id 345CD120054; Thu, 10 Apr 2014 13:48:41 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 13:48:35 +0000 Received: from BLUPR05MB515.namprd05.prod.outlook.com (10.141.29.146) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 10 Apr 2014 13:48:54 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB515.namprd05.prod.outlook.com (10.141.29.146) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 10 Apr 2014 13:48:52 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0913.002; Thu, 10 Apr 2014 13:48:52 +0000 From: Chris Bowers To: Pushpasis Sarkar , "Alvaro Retana (aretana)" , "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" Subject: RE: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Topic: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Index: AQHPP0MEPVYrj3DVB0qc+EV5ws0qppsJoycA///zE7CAAXINQA== Date: Thu, 10 Apr 2014 13:48:51 +0000 Message-ID: <8e8f9008635a405ba238bcfd420703a4@BLUPR05MB292.namprd05.prod.outlook.com> References: <8394f3d75b394b3f808bd7a85d53b8d8@BN1PR05MB520.namprd05.prod.outlook.com> In-Reply-To: <8394f3d75b394b3f808bd7a85d53b8d8@BN1PR05MB520.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.10] x-forefront-prvs: 0177904E6B Content-Type: multipart/alternative; boundary="_000_8e8f9008635a405ba238bcfd420703a4BLUPR05MB292namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/ZxXhuM_ca7KtCBNfz2HtZanwqW4 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:49:15 -0000 --_000_8e8f9008635a405ba238bcfd420703a4BLUPR05MB292namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any other IPR other than the one mentioned below. Chris From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Pushpasis Sarkar Sent: Wednesday, April 09, 2014 10:44 AM To: Alvaro Retana (aretana); draft-psarkar-rtgwg-rlfa-node-protection@tools= .ietf.org Cc: rtgwg@ietf.org Subject: RE: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Hi Alvaro, I am not aware of any other IPR other than the one mentioned below. Thanks -Pushpasis From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Wednesday, April 09, 2014 8:59 PM To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Authors: Hi! Since the start of the WG Adoption Call for this draft, an IPR Disclosure w= as submitted: https://datatracker.ietf.org/ipr/2334/ Please respond to this message indicating whether or not you are aware of a= ny relevant IPR beyond what has been disclosed to far. Please keep in mind= that we expect individual replies from each author. Thanks! Alvaro. On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_8e8f9008635a405ba238bcfd420703a4BLUPR05MB292namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any oth= er IPR other than the one mentioned below.

 <= /p>

Chris

 <= /p>

From: rtgwg = [mailto:rtgwg-bounces@ietf.org] On Behalf Of Pushpasis Sarkar
Sent: Wednesday, April 09, 2014 10:44 AM
To: Alvaro Retana (aretana); draft-psarkar-rtgwg-rlfa-node-protectio= n@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: RE: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-pro= tection

 

Hi Alvaro,

 <= /p>

I am not aware of any oth= er IPR other than the one mentioned below.

 <= /p>

Thanks<= /p>

-Pushpasis

 <= /p>

From: Alvaro= Retana (aretana) [mailto:aretana@cisc= o.com]
Sent: Wednesday, April 09, 2014 8:59 PM
To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-pro= tection

 

Authors:<= /p>

 

Hi!

 

Since the start of the WG A= doption Call for this draft, an IPR Disclosure was submitted: https://datatracker.ietf.org/ipr= /2334/

 

Please respond to this mess= age indicating whether or not you are aware of any relevant IPR beyond what has been disclosed to far.  Please keep in mind tha= t we expect individual replies from each author.

 

Thanks!

 

Alvaro.

 

On 3/14/14 1:05 AM, "A= lvaro Retana (aretana)" <areta= na@cisco.com> wrote:

 

Hi!

 

In parallel to the WG Adopt= ion Call for this draft, I want to formally ask the authors (no additi= onal contributors are listed in the latest version) to please respond to this message indicating whether or not you are aware of any rel= evant IPR.  The draft will not progress (pending the results of the WG= Adoption Call) until we have received a response from each author.

 

Thanks!

 

Alvaro.

 

--_000_8e8f9008635a405ba238bcfd420703a4BLUPR05MB292namprd05pro_-- From nobody Thu Apr 10 06:50:51 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461451A021C for ; Thu, 10 Apr 2014 06:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2DCUMwPXC3i for ; Thu, 10 Apr 2014 06:50:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id E9C261A01C1 for ; Thu, 10 Apr 2014 06:50:43 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 3FF09190A02; Thu, 10 Apr 2014 15:50:42 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 21D23384049; Thu, 10 Apr 2014 15:50:39 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 10 Apr 2014 15:50:38 +0200 From: To: "Alvaro Retana (aretana)" , "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" Date: Thu, 10 Apr 2014 15:50:37 +0200 Subject: RE: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Topic: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Index: AQHPP0MEPVYrj3DVB0qc+EV5ws0qppsJoycAgAFl9SA= Message-ID: <11049_1397137839_5346A1AF_11049_8118_1_EEE55384044474429A926C625D0FCC810C3CD84812@PUEXCB2F.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810C3CD84812PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.9.220919 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/uIZllSS1er0nQwB_mxXgAZ-XolI Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:50:48 -0000 --_000_EEE55384044474429A926C625D0FCC810C3CD84812PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Not aware of any IPR De : Alvaro Retana (aretana) [mailto:aretana@cisco.com] Envoy=E9 : mercredi 9 avril 2014 17:29 =C0 : draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org Cc : rtgwg@ietf.org Objet : Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Authors: Hi! Since the start of the WG Adoption Call for this draft, an IPR Disclosure w= as submitted: https://datatracker.ietf.org/ipr/2334/ Please respond to this message indicating whether or not you are aware of a= ny relevant IPR beyond what has been disclosed to far. Please keep in mind= that we expect individual replies from each author. Thanks! Alvaro. On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810C3CD84812PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Not aware o= f any IPR

 

 

De : Alvaro Retana (aretana) [mailto:aretana= @cisco.com]
Envoy=E9 : mercredi 9 avril 2014 17:29
= =C0 : draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org
<= b>Cc : rtgwg@ietf.org
Objet : Re: IPR Claims relate= d to draft-psarkar-rtgwg-rlfa-node-protection

 

Authors:

&= nbsp;

Hi!

 

<= /div>

Since the start of the WG Adoption Call= for this draft, an IPR Disclosure was submitted: https://datatracker.ietf.org/ipr/2334/

 

Please respond to this messag= e indicating whether or not you are aware of any relevant IPR beyond= what has been disclosed to far.  Please keep in mind that we expect i= ndividual replies from each author.

 

Thanks!

=  

Alvaro.

 

On 3/14/14 1:05 AM, &quo= t;Alvaro Retana (aretana)" <ar= etana@cisco.com> wrote:

 

<= div>

Hi!

 

In parallel to the WG Adoption Call for this draft,&n= bsp;I want to formally ask the authors (no additional contributors are list= ed in the latest version) to please respond to this message indicating whet= her or not you are aware of any relevant IPR.  The draft will not prog= ress (pending the results of the WG Adoption Call) until we have received a= response from each author.

 

Thanks!

&= nbsp;

Alvaro.

 

________________________=
___________________________________________________________________________=
______________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810C3CD84812PUEXCB2Fnante_-- From nobody Thu Apr 10 07:48:09 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172F81A0277 for ; Thu, 10 Apr 2014 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q631rzKQokoV for ; Thu, 10 Apr 2014 07:48:02 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 841271A0145 for ; Thu, 10 Apr 2014 07:48:02 -0700 (PDT) Received: from mail36-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 14:47:37 +0000 Received: from mail36-ch1 (localhost [127.0.0.1]) by mail36-ch1-R.bigfish.com (Postfix) with ESMTP id A86034200B6; Thu, 10 Apr 2014 14:47:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371Ic85fh103dK1519Mzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail36-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shraddha@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(41574002)(24454002)(54014002)(377454003)(479174003)(66066001)(19300405004)(80022001)(86362001)(79102001)(46102001)(20776003)(19580395003)(31966008)(16236675002)(74502001)(80976001)(74662001)(92566001)(83322001)(4396001)(77982001)(33646001)(19580405001)(15975445006)(18717965001)(81342001)(85852003)(99396002)(83072002)(81542001)(87936001)(19609705001)(76576001)(15202345003)(2656002)(76482001)(74316001)(54356999)(50986999)(76176999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB125; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:3C9944CA.8CD0E5E5.F5EDFDB3.A4D99A88.20209; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail36-ch1 (localhost.localdomain [127.0.0.1]) by mail36-ch1 (MessageSwitch) id 1397141256152401_23649; Thu, 10 Apr 2014 14:47:36 +0000 (UTC) Received: from CH1EHSMHS042.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail36-ch1.bigfish.com (Postfix) with ESMTP id 162271800D3; Thu, 10 Apr 2014 14:47:36 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS042.bigfish.com (10.43.69.251) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 14:47:35 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 10 Apr 2014 14:47:57 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 10 Apr 2014 14:47:55 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.55]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.55]) with mapi id 15.00.0918.000; Thu, 10 Apr 2014 14:47:55 +0000 From: Shraddha Hegde To: "Alvaro Retana (aretana)" , "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" Subject: RE: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Topic: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Thread-Index: AQHPP0MEPVYrj3DVB0qc+EV5ws0qppsJoycAgAFyoyA= Date: Thu, 10 Apr 2014 14:47:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.18] x-forefront-prvs: 0177904E6B Content-Type: multipart/alternative; boundary="_000_fa185404b6c04420a6f163e902b3ad95BY2PR05MB127namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/K1Crq65I4QswnCG_YIzWlLbDiYc Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:48:07 -0000 --_000_fa185404b6c04420a6f163e902b3ad95BY2PR05MB127namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alvaro, I am not aware of any other IPR other than the one mentioned below. Rgds Shraddha From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana (are= tana) Sent: Wednesday, April 09, 2014 8:59 PM To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection Authors: Hi! Since the start of the WG Adoption Call for this draft, an IPR Disclosure w= as submitted: https://datatracker.ietf.org/ipr/2334/ Please respond to this message indicating whether or not you are aware of a= ny relevant IPR beyond what has been disclosed to far. Please keep in mind= that we expect individual replies from each author. Thanks! Alvaro. On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_fa185404b6c04420a6f163e902b3ad95BY2PR05MB127namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

 <= /p>

I am not aware of any oth= er IPR other than the one mentioned below.

 <= /p>

Rgds

Shraddha

 <= /p>

From: rtgwg [m= ailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: Wednesday, April 09, 2014 8:59 PM
To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-pro= tection

 

Authors:<= /p>

 

Hi!

 

Since the start of the WG A= doption Call for this draft, an IPR Disclosure was submitted: https://datatracker.ietf.org/ipr= /2334/

 

Please respond to this mess= age indicating whether or not you are aware of any relevant IPR beyond what has been disclosed to far.  Please keep in mind tha= t we expect individual replies from each author.

 

Thanks!

 

Alvaro.

 

On 3/14/14 1:05 AM, "A= lvaro Retana (aretana)" <areta= na@cisco.com> wrote:

 

Hi!

 

In parallel to the WG Adopt= ion Call for this draft, I want to formally ask the authors (no additi= onal contributors are listed in the latest version) to please respond to this message indicating whether or not you are aware of any rel= evant IPR.  The draft will not progress (pending the results of the WG= Adoption Call) until we have received a response from each author.

 

Thanks!

 

Alvaro.

 

--_000_fa185404b6c04420a6f163e902b3ad95BY2PR05MB127namprd05pro_-- From nobody Fri Apr 11 06:35:52 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACABC1A0696 for ; Fri, 11 Apr 2014 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73eXs7dAUp2v for ; Fri, 11 Apr 2014 06:35:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1871D1A026C for ; Fri, 11 Apr 2014 06:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3431; q=dns/txt; s=iport; t=1397223344; x=1398432944; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KExRzyUusRxWC/jpCMEFZ+RyCVjKlbFiZWAV5kJV5Rc=; b=ApJFli/eUU3eIRQ72bL3UOtY/y1ppA+e/MgnH3uVWMYp084p1PVtnBHs +wxuQQptMtvjt7RrNJgkJf0AqRXBKSPtT7+LWDjw2bmOf95cbklS8hQeg D/94+XToy+aEWZ/jvZDsOsdAdyw7mupY44emtO3HeC18ZJ2uKf8476fft s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAC/uR1OtJV2Z/2dsb2JhbABZgkJEO1etf41ZiHSBGxZ0giYBAQR5EAIBCAQ7BzIUEQIEDgWHfA3MIheOaAQHhDgEmGCBNZENgzGCKw X-IronPort-AV: E=Sophos;i="4.97,842,1389744000"; d="scan'208,217";a="316995728" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 11 Apr 2014 13:35:43 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3BDZh1N022000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 13:35:43 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.162]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 08:35:43 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-rtgwg-mofrr@tools.ietf.org" Subject: Re: IPR Claims related to draft-ietf-rtgwg-mofrr Thread-Topic: IPR Claims related to draft-ietf-rtgwg-mofrr Thread-Index: AQHPPz9L2w2bbTUN3EO+tBGO/aSUWpsMqB+A Date: Fri, 11 Apr 2014 13:35:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CF6D67055456Baretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/2C5PzS7yggmOXS31WAF9TqWZoYA Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:35:48 -0000 --_000_CF6D67055456Baretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors/Contributors: So far I have only heard back from Jeff Tantsura (as a contributor), who po= inted at an additional piece of IPR: https://datatracker.ietf.org/ipr/2332= / We must hear from all of you (yes, all 8 of you) if this draft is to progre= ss. Thanks! Alvaro. On 3/14/14 12:38 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WGLC for this draft, I want to formally ask the authors = (and contributors) to please respond to this message indicating whether or = not you are aware of any relevant IPR beyond what has already been disclose= d. The draft will not progress (pending the results of the WGLC) until we = have received a response from each author/contributor. http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -ietf-rtgwg-mofrr Thanks! Alvaro. --_000_CF6D67055456Baretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7D2B3C88FDFD964CA37B0085BC9EF8B8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Authors/Contributors:

So far I have only heard back from Jeff Tantsura (as a contributor), w= ho pointed at an additional piece of IPR:  https://datatracker.ietf.org/ipr/2332/

We must hear from all of you (yes, all 8 of you) if this draft is to p= rogress.

Thanks!

Alvaro.

On 3/14/14 12:38 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WGLC for this draft, I want to formally ask th= e authors (and contributors) to please respond to this message indicating w= hether or not you are aware of any relevant IPR beyond what has already bee= n disclosed.  The draft will not progress (pending the results of the WGLC) until we have received a response from e= ach author/contributor.


Thanks!

Alvaro.

 --_000_CF6D67055456Baretanaciscocom_-- From nobody Fri Apr 11 06:41:33 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA9B1A069B for ; Fri, 11 Apr 2014 06:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI04httKU1bZ for ; Fri, 11 Apr 2014 06:41:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 149421A0696 for ; Fri, 11 Apr 2014 06:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2856; q=dns/txt; s=iport; t=1397223689; x=1398433289; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tBgFYWT4jT70K4oNNiZpmvC/uxrvh0z8v2RgqvkJsw0=; b=mCnr3T0NA59Kro+1OlbLfS+fOOFK/tpGGIH2VwV7D7blaFfcLqBWmMyv nidmm62RQH1ldpqccISC1f7QlI0KNtdHUYzTYviPwsRy2CSMifxzU6xFp 02+SZtVYpe8eQJs0j3fKVtzZTdiw6MQYhxOqefsCkRkDmgzcA/gnOJi/i E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFALbwR1OtJV2c/2dsb2JhbABZgkJEgRLETIEbFnSCJgEBBB1cEAIBCAQ7BzIUEQIEDgWHfMw8F45sB4Q4BJhgkkKDMYIr X-IronPort-AV: E=Sophos;i="4.97,842,1389744000"; d="scan'208,217";a="317083225" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 11 Apr 2014 13:41:28 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3BDfSRf013278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 13:41:28 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.162]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 08:41:28 -0500 From: "Alvaro Retana (aretana)" To: "draft-litkowski-rtgwg-uloop-delay@tools.ietf.org" Subject: Re: IPR Claims related to draft-litkowski-rtgwg-uloop-delay Thread-Topic: IPR Claims related to draft-litkowski-rtgwg-uloop-delay Thread-Index: AQHPP0X9V3A0Fgoy10aYf53lUa6ja5sMqa6A Date: Fri, 11 Apr 2014 13:41:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CF6D68EA5457Baretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/nQ7xmuvNcfsnVzQkF-Lc4sHC9-A Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:41:31 -0000 --_000_CF6D68EA5457Baretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors: So far I have only heard back from one of you (Stephane). We must hear fro= m all of you (yes, all 4 of you) if this draft is to progress. Thanks! Alvaro. On 3/14/14 1:26 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_CF6D68EA5457Baretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <984362DAB8A06D41828CA3198BACC4FF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Authors:

So far I have only heard back from one of you (Stephane).  We mus= t hear from all of you (yes, all 4 of you) if this draft is to progress.

Thanks!

Alvaro.


On 3/14/14 1:26 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WG Adoption Call for this draft, I want to for= mally ask the authors (no additional contributors are listed in the latest = version) to please respond to this message indicating whether or not you ar= e aware of any relevant IPR.  The draft will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

Thanks!

Alvaro.

 --_000_CF6D68EA5457Baretanaciscocom_-- From nobody Fri Apr 11 07:09:25 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BDE1A01D2 for ; Fri, 11 Apr 2014 07:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkQYAbVLqb8t for ; Fri, 11 Apr 2014 07:09:18 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 734961A019E for ; Fri, 11 Apr 2014 07:09:17 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id pv20so3482914lab.23 for ; Fri, 11 Apr 2014 07:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZZ7joul5+WxeOHsRR8n2aN/rg7Af8pjPB9GvtAxgDpw=; b=LFl3QzZpLM9DKdpi81CFTkQFBqV2SEZ47wypnZZ9pZ9eJiO4u9NHa7AYp6gtVbT6/6 B+ls+nXJOih7ug9KuXGOoXgV80ePLYaarYsVQm3VRdnMH5JDoht/fBNzOZ7A/0c/BP4A zEyaUrJgOl2sdD8V2+xckQPMfrsZM5Gk58x7rNfRD13TWNlfWPJOz9AD81qXHPtq+cAJ mWbEYbOV6FerQSwkUdXGutOEcF6w4bc6zmLi2/Y98L7qCMyqABZ6Z/Gn9FDIxqb0KA/V a9lDvviCjJ/ZQO3NSaNX3K4JKZ2c7s0x0dUWsF4641rkMFAuuOiX9++aKquyrBfxn0HC D9WQ== MIME-Version: 1.0 X-Received: by 10.152.170.137 with SMTP id am9mr17036698lac.15.1397225354963; Fri, 11 Apr 2014 07:09:14 -0700 (PDT) Received: by 10.112.33.39 with HTTP; Fri, 11 Apr 2014 07:09:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 19:39:14 +0530 Message-ID: Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-node-protection From: Harish R Prabhu To: Shraddha Hegde Content-Type: multipart/alternative; boundary=089e01177201f430c904f6c4e023 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/AuuGCygFIENx7afYarCA3CSN_E0 Cc: "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:09:22 -0000 --089e01177201f430c904f6c4e023 Content-Type: text/plain; charset=ISO-8859-1 Hi Alvaro, I am not aware of any other IPR claims than the one already mentioned. Best regards, Harish Raghuveer On Thu, Apr 10, 2014 at 8:17 PM, Shraddha Hegde wrote: > Hi Alvaro, > > > > I am not aware of any other IPR other than the one mentioned below. > > > > Rgds > > Shraddha > > > > *From:* rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Alvaro > Retana (aretana) > > *Sent:* Wednesday, April 09, 2014 8:59 PM > *To:* draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org > *Cc:* rtgwg@ietf.org > *Subject:* Re: IPR Claims related to > draft-psarkar-rtgwg-rlfa-node-protection > > > > Authors: > > > > Hi! > > > > Since the start of the WG Adoption Call for this draft, an IPR Disclosure > was submitted: https://datatracker.ietf.org/ipr/2334/ > > > > Please respond to this message indicating whether or not you are aware of > any relevant IPR *beyond* what has been disclosed to far. Please keep in > mind that we expect individual replies from each author. > > > > Thanks! > > > > Alvaro. > > > > On 3/14/14 1:05 AM, "Alvaro Retana (aretana)" wrote: > > > > Hi! > > > > In parallel to the WG Adoption Call for this draft, I want to formally ask > the authors (no additional contributors are listed in the latest version) > to please respond to this message indicating whether or not you are aware > of any relevant IPR. The draft will not progress (pending the results of > the WG Adoption Call) until we have received a response from each author. > > > > Thanks! > > > > Alvaro. > > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > -- Harish R Prabhu Bangalore, India. --089e01177201f430c904f6c4e023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

I am not aware of any other IPR cla= ims than the one already mentioned.

Best regards,
Harish Ra= ghuveer


On Thu, Apr 10, 2014 at 8:17 PM, Shraddha Hegde <shraddha@juniper.net> wrote:

Hi Alvaro,<= /span>

=A0<= /p>

I am not aware of any oth= er IPR other than the one mentioned below.

=A0<= /p>

Rgds<= /span>

Shraddha

=A0<= /p>

From: rtgwg [m= ailto:rtgwg-bou= nces@ietf.org] On Behalf Of Alvaro Retana (aretana)


Sent: Wednesday, April 09, 2014 8:59 PM
To: draft-psarkar-rtgwg-rlfa-node-protection@tools= .ietf.org
Cc: rtgwg@ietf.o= rg
Subject: Re: IPR Claims related to draft-psarkar-rtgwg-rlfa-no= de-protection

=A0

Authors:

=A0

Hi!

=A0

Since the start of the WG Adoption Call= for this draft, an IPR Disclosure was submitted:=A0https://datatracker.ietf.org/i= pr/2334/

=A0

Please respond to this message indicati= ng whether or not you are aware of any relevant IPR beyond what has been disclosed to far. =A0Please keep in mind that w= e expect individual replies from each author.

=A0

Thanks!

=A0

Alvaro.

=A0

On 3/14/14 1:05 AM, "Alvaro Retana= (aretana)" <aretana@cisco.com> wrote:

=A0

Hi!

=A0

In parallel to the WG Adoption Call for= this draft,=A0I want to formally ask the authors (no additional contributo= rs are listed in the latest version) to please respond to this message indicating whether or not you are aware of any rel= evant IPR. =A0The draft will not progress (pending the results of the WG Ad= option Call) until we have received a response from each author.<= /u>

=A0

Thanks!

=A0

Alvaro.

=A0


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg




--
Harish R Prabhu
= Bangalore, India.
--089e01177201f430c904f6c4e023-- From nobody Fri Apr 11 07:11:15 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E207A1A0698 for ; Fri, 11 Apr 2014 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXafZQfMgfTB for ; Fri, 11 Apr 2014 07:11:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id C3BAE1A019E for ; Fri, 11 Apr 2014 07:11:06 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 0CB392ACCB4; Fri, 11 Apr 2014 16:11:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E3A7D18004F; Fri, 11 Apr 2014 16:11:03 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 11 Apr 2014 16:11:03 +0200 From: To: "Alvaro Retana (aretana)" , "draft-litkowski-rtgwg-uloop-delay@tools.ietf.org" Subject: RE: IPR Claims related to draft-litkowski-rtgwg-uloop-delay Thread-Topic: IPR Claims related to draft-litkowski-rtgwg-uloop-delay Thread-Index: AQHPP0X9V3A0Fgoy10aYf53lUa6ja5sMqa6A///3dhA= Date: Fri, 11 Apr 2014 14:11:03 +0000 Message-ID: <8333_1397225463_5347F7F7_8333_3783_1_53C29892C857584299CBF5D05346208A07130DAF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A07130DAFPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.11.83019 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/DSb_EzmD8Os-HJ2ntZyB4K98nqo Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:11:12 -0000 --_000_53C29892C857584299CBF5D05346208A07130DAFPEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alvaro, I am not aware of any other IPR claims than the one already mentioned. Best regards, Bruno From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana (are= tana) Sent: Friday, April 11, 2014 3:41 PM To: draft-litkowski-rtgwg-uloop-delay@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IPR Claims related to draft-litkowski-rtgwg-uloop-delay Authors: So far I have only heard back from one of you (Stephane). We must hear fro= m all of you (yes, all 4 of you) if this draft is to progress. Thanks! Alvaro. On 3/14/14 1:26 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version) t= o please respond to this message indicating whether or not you are aware of= any relevant IPR. The draft will not progress (pending the results of the= WG Adoption Call) until we have received a response from each author. Thanks! Alvaro. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A07130DAFPEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Alvaro,

=  

= I am not aware of any other IPR c= laims than the one already mentioned.

=  

= Best regards,

= Bruno

=  

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Beh= alf Of Alvaro Retana (aretana)
Sent: Friday, April 11, 2014= 3:41 PM
To: draft-litkowski-rtgwg-ul= oop-delay@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IPR Claims rela= ted to draft-litkowski-rtgwg-uloop-delay

 

Authors:

 

So far I have only heard back from one of you (Steph= ane).  We must hear from all of you (yes, all 4 of you) if this draft is to progress.

 

Thanks!

 

Alvaro.

 

 

On 3/14/14 1:26 AM, "Alvaro Retana (aretana)&qu= ot; <aretana@cisco.com> wrot= e:

 

Hi!

 

In parallel to the WG Adoption Call for this draft,&= nbsp;I want to formally ask the authors (no additional contributors are listed in the latest version) to please respond to this message indica= ting whether or not you are aware of any relevant IPR.  The draft will= not progress (pending the results of the WG Adoption Call) until we have r= eceived a response from each author.

 

Thanks!

 

Alvaro.

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A07130DAFPEXCVZYM11corpo_-- From nobody Mon Apr 14 05:59:29 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1C1A02CE for ; Mon, 14 Apr 2014 05:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQZefg_8Tb_t for ; Mon, 14 Apr 2014 05:59:24 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id C08B91A01CE for ; Mon, 14 Apr 2014 05:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1242; q=dns/txt; s=iport; t=1397480362; x=1398689962; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=A4Lu0Zn5A1vtb+HAQyTRQmKqBI6Fmw7nJ1dp7IL0QnU=; b=cgbdDMnmAUck1K26h3fhnAUz+9PNs5DrUPEdl6BuvaHGv767USoUjDEo duIAwXrAoB/3dXgYL1oJaO+vHH4mlqzV7kAbsGXVhU3jR3ZSsAJRZLhhK HLuXR82yWTjY1rCq6ExmQgSLyweMcd+o+JXz2UR2ADBCLE7EwW7nWjVTx k=; X-IronPort-AV: E=Sophos;i="4.97,857,1389744000"; d="scan'208";a="13183598" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 14 Apr 2014 12:59:22 +0000 Received: from ams-iwijnand-8716.cisco.com (ams-iwijnand-8716.cisco.com [10.55.191.151]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3ECxISV010306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 12:59:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: IPR Claims related to draft-ietf-rtgwg-mofrr From: IJsbrand Wijnands In-Reply-To: Date: Mon, 14 Apr 2014 14:59:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <285AE4C7-7D26-46D1-998B-B1B04D2721C4@cisco.com> References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/AjkOzZSwPnznJZmulAG4QbMgXLw Cc: "draft-ietf-rtgwg-mofrr@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 12:59:28 -0000 Hi Alvaro, No IPR know beyond what is already disclosed. Thx, Ice. On 11 Apr 2014, at 15:35, "Alvaro Retana (aretana)" = wrote: > Authors/Contributors: >=20 > So far I have only heard back from Jeff Tantsura (as a contributor), = who pointed at an additional piece of IPR: = https://datatracker.ietf.org/ipr/2332/ >=20 > We must hear from all of you (yes, all 8 of you) if this draft is to = progress. >=20 > Thanks! >=20 > Alvaro. >=20 > On 3/14/14 12:38 AM, "Alvaro Retana (aretana)" = wrote: >=20 > Hi! >=20 > In parallel to the WGLC for this draft, I want to formally ask the = authors (and contributors) to please respond to this message indicating = whether or not you are aware of any relevant IPR beyond what has already = been disclosed. The draft will not progress (pending the results of the = WGLC) until we have received a response from each author/contributor. >=20 > = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-rtgwg-mofrr >=20 > Thanks! >=20 > Alvaro. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Wed Apr 23 14:09:08 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685801A067C; Wed, 23 Apr 2014 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8-22cMJpzio; Wed, 23 Apr 2014 14:09:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 368891A0667; Wed, 23 Apr 2014 14:09:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: psarkar@juniper.net, hannes@juniper.net, shraddha@juniper.net, hraghuveer@juniper.net, cbowers@juniper.net, stephane.litkowski@orange.com Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-psarkar-rtgwg-rlfa-node-protection-04 X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423210902.16000.97424.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 14:09:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/taYSE1m46D_9tteRnkTvryPWL4E Cc: adrian@olddog.co.uk, ipr-announce@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 21:09:03 -0000 Dear psarkar@juniper.net, Hannes Gredler, Shraddha Hegde, Harish Raghuveer, cbowers@juniper.net, 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-04-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2346/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-psarkar-rtgwg-rlfa-node- protection-04.""); The IETF Secretariat From nobody Wed Apr 30 13:42:56 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12D21A0953 for ; Wed, 30 Apr 2014 13:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss0mKfFIlmk8 for ; Wed, 30 Apr 2014 13:42:45 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE291A08BE for ; Wed, 30 Apr 2014 13:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4751; q=dns/txt; s=iport; t=1398890563; x=1400100163; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YYALlk1U8Q9WeQgR34EqUNZXH1rh1bvyjHxwRzAxSEA=; b=ZGRsUcXOFzub9Y38x40clt4LdpT8Bx1RIHoLdIEG6SzBQRNonT4QR9pc eZGXQyoeU4JMWaGYK1tWRnR3pEEewOfKPVollDExBj+LqiLb1jgLxrojS 0JlmuI2H7Hom2aBGpiCN5J7ILs4qxDD+7yKBeYFv8zc8g+O1r8k+Rra5s U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAOVfYVOtJV2a/2dsb2JhbABZgkJET1etKI4kiQCBIRZ0giYBAQR5EAIBCAQ7BzIUEQIEDgWIQQ3JaheOTQQHhDkEmSeBPJEvgzGCKw X-IronPort-AV: E=Sophos; i="4.97,960,1389744000"; d="scan'208,217"; a="40090807" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 30 Apr 2014 20:42:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3UKgOkU016277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 20:42:24 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.162]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 15:42:23 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-rtgwg-mofrr@tools.ietf.org" Subject: Re: IPR Claims related to draft-ietf-rtgwg-mofrr Thread-Topic: IPR Claims related to draft-ietf-rtgwg-mofrr Thread-Index: AQHPPz9L2w2bbTUN3EO+tBGO/aSUWpsMqB+AgB5TggA= Date: Wed, 30 Apr 2014 20:42:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CF86D79B56798aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/Nmv5a9DyXw3RdKZgtkEjw4nTLvs Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:42:49 -0000 --_000_CF86D79B56798aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors/Contributors: We've made some progress and now we have received replies from the followin= g people: Ice, Bruno, Wim and Jeff (as a contributor). Again, we do need to hear from everyone before proceeding.. Thanks! Alvaro. On 4/11/14 9:35 AM, "Alvaro Retana (aretana)" > wrote: Authors/Contributors: So far I have only heard back from Jeff Tantsura (as a contributor), who po= inted at an additional piece of IPR: https://datatracker.ietf.org/ipr/2332= / We must hear from all of you (yes, all 8 of you) if this draft is to progre= ss. Thanks! Alvaro. On 3/14/14 12:38 AM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WGLC for this draft, I want to formally ask the authors = (and contributors) to please respond to this message indicating whether or = not you are aware of any relevant IPR beyond what has already been disclose= d. The draft will not progress (pending the results of the WGLC) until we = have received a response from each author/contributor. http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -ietf-rtgwg-mofrr Thanks! Alvaro. --_000_CF86D79B56798aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <131DA124285BB34280306A73078981D7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Authors/Contributors:

We've made some progress and now we have received replies from the fol= lowing people:  Ice, Bruno, Wim and Jeff (as a contributor).

Again, we do need to hear from everyone before proceeding..

Thanks!

Alvaro.

On 4/11/14 9:35 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Authors/Contributors:

So far I have only heard back from Jeff Tantsura (as a contributor), w= ho pointed at an additional piece of IPR:  https://datatracker.ietf.org/ipr/2332/

We must hear from all of you (yes, all 8 of you) if this draft is to p= rogress.

Thanks!

Alvaro.

On 3/14/14 12:38 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WGLC for this draft, I want to formally ask th= e authors (and contributors) to please respond to this message indicating w= hether or not you are aware of any relevant IPR beyond what has already bee= n disclosed.  The draft will not progress (pending the results of the WGLC) until we have received a response from e= ach author/contributor.


Thanks!

Alvaro.

 --_000_CF86D79B56798aretanaciscocom_--