From adrian@olddog.co.uk Sun May 12 13:14:05 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4694421F8C9B for ; Sun, 12 May 2013 13:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KDXOQ2KtMpX for ; Sun, 12 May 2013 13:14:00 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 3B27B21F8C83 for ; Sun, 12 May 2013 13:14:00 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4CKDwBU027482; Sun, 12 May 2013 21:13:58 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4CKDsje027461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 May 2013 21:13:55 +0100 From: "Adrian Farrel" To: References: In-Reply-To: Date: Sun, 12 May 2013 21:13:54 +0100 Message-ID: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D8_01CE4F55.9D9894C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZQHEifWRr9rkK4Fbzg/QpL8iQkQLAth9GmFYS3wA= Content-Language: en-gb Cc: rtg-dir@ietf.org, 'Danny McPherson' Subject: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 20:14:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D8_01CE4F55.9D9894C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, I am attaching Danny's routing directorate review of your draft. Please = read his note below. As IETF last call has completed, you do not need to heed these comments = in the same way as you might for comments coming during IETF last call. However, the ADs will be sifting through what Danny has written and = potentially adding issues he raises to our Discusses/Comments. In view = of that, you may feel it wise to read what he has written and see = whether you are moved to answer his questions and maybe update the text. Thanks, Adrian > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: 12 May 2013 20:57 > To: BRUNGARD, DEBORAH A > Cc: stbryant@cisco.com; adrian@olddog.co.uk; Dan Li > (huawei.danli@huawei.com) > Subject: Re: Routing Area Directorate Review for = draft-ietf-karp-crypto-key-table >=20 > Review attached, apologies for the latency. Also, I'm sending this > without a full review of the review so if anything seems abrasive it > wasn't meant to be.. >=20 > Thanks, >=20 > -danny ------=_NextPart_000_00D8_01CE4F55.9D9894C0 Content-Type: text/plain; name="rtgdir-review-draft-ietf-karp-crypto-key-table.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rtgdir-review-draft-ietf-karp-crypto-key-table.txt" Hello,=0A= I have been selected as the Routing Directorate reviewer =0A= for this draft.=0A= =0A= The Routing Directorate seeks to review all routing or =0A= routing-related drafts as they pass through IETF last =0A= call and IESG review, and sometimes on special request. =0A= The purpose of the review is to provide assistance to =0A= the Routing ADs. For more information about the Routing =0A= Directorate, please see=0A= =0A= http://www.ietf.org/iesg/directorate/routing.html=0A= =0A= Although these comments are primarily for the use of the =0A= Routing ADs, it would be helpful if you could consider =0A= them along with any other comments that you receive, and =0A= strive to resolve them through discussion or by updating =0A= the draft as appropriate. =0A= =0A= Document: http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-07=0A= Reviewer: Danny McPherson=0A= Review Date: 08 MAY 2013=0A= Intended Status: Standards Track=0A= =0A= There is at least one major issue with this document, as =0A= it is now written.=0A= =0A= Comments/Questions:=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= 1) This document specifically restricts itself to only ever talking about=0A= symmetric keys, and therefore it is not going to work for public key = crypto=0A= approaches like RPKI/BGPSEC. If the objective is "Keying and = Authentication=0A= for routing protocols (not just *routed* protocols) then not = accommodating =0A= BGP would seem to miss the mark. An array of mechanisms to get keys into=0A= routers and store them for a lot of different purposes is precisely one = of =0A= the reasons why folks don't update keys or perform more authentication =0A= functions today.=0A= =0A= 2) As a Standards Track document it feels entirely too generic. It = should=0A= employ some specific example usages to illustrate its efficacy and = refine =0A= its inadequacies, the current "boil the ocean" leaves me wonder what's=0A= actually to be implemented from this ID.=0A= =0A= 3) There is a clear need to discuss proper time synchronization that is=0A= conspicuously missing, and this seems the type of place to tackle it = rather=0A= than avoiding the topic..=0A= =0A= 4) There is _no_ error handling recommendations, and plenty of failure = modes.=0A= =0A= 5) There are lots of instances where you might have multiple sessions = (link=0A= local, IGP, or EGP) between a single peer (e.g., BGP multisession or = diverse=0A= path) that MAY employ different credentials, this model doesn't seem to =0A= accommodate this at all. =0A= =0A= 6) What about use for authentication data of other sorts? E.g., NTP or = SNMP,=0A= or L2TPv3, or other types of PWs, etc..? If we're going to define a = generic=0A= model shouldn't it accommodate those?=0A= =0A= 7) S.2 text suggests multiple times that "many routing protocols restrict=0A= their key names to integers that can be represented in 16 or 32 bits." = Is=0A= this really the case? Are there ANY that restrict their key *names* to = 32 bits=0A= today? This really doesn't afford much in the way of operator usability = and=0A= mnemonic values, etc..=0A= =0A= Specific comments:=0A= =0A= 1) Section 2 starts off by talking about if/when long-lived keys will be=0A= reused... It says ``hopefully'' they won't be... Is there a = recommendaiton=0A= to reference (or provide) here or just well placed aspirations? :-)=0A= =0A= 2) Section 2 talks about ``ProtocolSpecificInfo'' but stays super = vague... not=0A= even an example. I would suggest something be provided to demonstrate = how=0A= this field would be used (or motivate its existence). We don't want it = to=0A= wind up being used to store plain-text passphrases!=0A= =0A= 3) Section 2 opens Pandora's box with the=0A= SendLifetime[Start|End]/AcceptedLifetime[Start|End]. The = inevitability of=0A= peers losing time sync w/o a systemic solution (e.g., NTP/TICTOC/Other) = is =0A= glossed over. Routers would, without persistent sync, eventually stop = being =0A= able to talk to each other. At no point in the draft is there any = discussion =0A= of how protocol errors are handled in routing or routed protocols. So, = if I'm =0A= a sender, and suddenly my receiver can't sync w/ me, then I have no = error =0A= message to use to debug. Having dealt with this before, I can tell you = that =0A= it is _no_fun_! Also, this is clearly not just for adjacent peers, as = BGP =0A= , LSPs, LSAs, etc.. are all preserved multi-hop. Some taxonomy for = routed v.=0A= routing (session v. multi-hop messages) might be useful here. I think = some of=0A= the other KARP work touches on this a bit, perhaps references and = application=0A= are in order?=0A= =0A= 4) Section 3 the key selection protocol seems a little too generic to be=0A= useful... Pre-canning algorithm preference as the first choice seems to = miss=0A= other degrees of freedom that might be very application specific. Also, = I=0A= wonder if (as this protocol might evolve) there would be contention = between=0A= peers in which one would _presume_ a certain algo preference order, but = the=0A= other might implement a different choice? The point is, codifying that = there=0A= is a mandate here seems optimistic and reaching, shouldn't that be done = in the=0A= corresponding protocol specifications?.=0A= =0A= 5) Section 6's operational considerations seems like a very under powered=0A= provision for the need for time synchronization between peers. As=0A= suggested, this text essentially acknowledges that there is a problem, = and=0A= offers a wouldbe solution that (by definition) will fail after prolonged = clock=0A= drift.=0A= =0A= 6) Section 7 should include a treatise on the dependency this protocol = will=0A= have on time sync (such as through NTP or something)...=0A= =0A= NITs:=0A= =3D=3D=3D=3D=3D=0A= =0A= =0A= S.2: =0A= =0A= ---=0A= s/will multiple rows will contain/...?/=0A= =0A= =0A= ---=0A= Under the "Peers" definition what's "unicast keys" mean?=0A= =0A= ---=0A= Also, what do you mean by "name a routing area for a multicast routing=0A= protocol"? Are you suggesting reference the area or level in LS = protocols, or=0A= referring to something in PIM-* et al, or something else? Then = intention and=0A= context here is unclear?=0A= =0A= ---=0A= Recommend replacing "packet" with "message" in *all* such instances?=0A= =0A= ---=0A= As for "Interfaces", the concept of interface groups would likely be = valuable=0A= here, or perpaps the notion of "router" or "context" level values? This=0A= applies to the TCP-AO example where eBGP v. Transit eBGP for internal = would=0A= all be large numers with lots of overlap, but may vary across sets and = perhaps=0A= even across AFI/SAFI.=0A= =0A= ---=0A= In the Protocol section here, it's still unclear to me if we're talking = about=0A= routing or routed protocols, or PWs, or LS updates in LS protocols, etc..=0A= =0A= ---=0A= I'm kinda surprised there's nothing some akin to a KDF or AlgID registry=0A= already. How to those developers no to include their algorithms in this=0A= registry now?=0A= =0A= ---=0A= S.3:=0A= =0A= ---=0A= "Outoing packet" v. "message" again? I think we need to be more precise = here.=0A= =0A= ---=0A= What does "loosely bound" mean?=0A= =0A= ---=0A= The conditions outlined in key matches would likely benefit considerably = from=0A= the notion of interface groups or similar (e.g., internal v. external, = etc..).=0A= =0A= ---=0A= You talk in this section about how exceeding the lifetime on a particular=0A= long-lived key does not have any impact - how do you know this? = SHouldn't=0A= that be left to the protocol and deployment model?=0A= =0A= ---=0A= The last graf of S.3 about TCP-AO and other protocols using their own DB = - did=0A= I miss something about what this should be the case? Is this IF they = don't=0A= want to use this DB, or is there something else here? The current text = isn't=0A= very helpful in groking the context.=0A= =0A= ---=0A= S.4 talks again a lot about "packets", when I think sometime you mean = messages=0A= v. packets, but perhaps sometime not?=0A= =0A= ---=0A= References: Russ, I'm a little surprised you use your home address in = these..=0A= =0A= =0A= =0A= ---=0A= =0A= s/when received in a packet./when received in a message./=0A= =0A= ------=_NextPart_000_00D8_01CE4F55.9D9894C0-- From eric.gray@ericsson.com Tue May 14 09:27:53 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07F621F84A7 for ; Tue, 14 May 2013 09:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57a0YxxQgePk for ; Tue, 14 May 2013 09:27:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81A21F8653 for ; Tue, 14 May 2013 09:24:54 -0700 (PDT) X-AuditID: c6180641-b7f906d000003e3f-79-5192652b6c13 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D0.EE.15935.B2562915; Tue, 14 May 2013 18:24:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 14 May 2013 12:24:11 -0400 From: Eric Gray To: Yaacov Weingarten Thread-Topic: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 Thread-Index: Ac46I/L2HHXp8Uk5T2ussJve4WIn1ABaH/6ABUenjKA= Date: Tue, 14 May 2013 16:24:09 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60AA2DC@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.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.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF60AA2DCeusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPlK5O6qRAg7U32C3O7K212HnmOrPF gjVP2S1uXOxhcWDx2DnrLrvHkiU/mTx+nEzx+HL5M1sASxSXTUpqTmZZapG+XQJXxpE/U1gL zlxnrVh51KCBcXIbaxcjJ4eEgInEguUPoWwxiQv31rN1MXJxCAkcZZR4daefGcJZzijxZuML JpAqNgENiWN31jJ2MXJwiAhoSmxYVwsSZhY4ySjxYLEziC0sEC7R1P2IBcQWEYiQeP3rL1S5 lcTjE/IgYRYBVYmFy6eAhXkFvCU+f7OH2DSJUeLc151sIDWcAoESL7o2gdmMQLd9P7WGCWKV uMStJ/OZIG4WkFiy5zwzhC0q8fLxP6hflCWWPNnPAlGfL7HkzFEwm1dAUOLkzCcsExhFZyEZ NQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR4SZGYOQdk2Bz 3MG44JPlIUZpDhYlcd5ErsZAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxT1j68XFstqzB9 pfu+Gr6YR3t2bjrDxhcV/na3aOohLb8J5fslXtSZ+fJOZ6258nrD+mM1D0T5s6rW3c5MeNdZ OnNK5ZLNl0setsTt65y6ks/z+fezDRw3uv58n77u0eqmA0VzK5RLEy7+q7imVNhw4Um0903+ CWIGR/5lbl1Qsb75/PfWy/tDlFiKMxINtZiLihMBDQIzA4oCAAA= Cc: "rtg-dir@ietf.org" , "rtg-ads@tools-ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 16:28:20 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF60AA2DCeusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaacov, I didn't see this response until I specifically went lookin= g for it. Sorry to have taken so long to get back to you. For the most part, your counter proposal is good enough. S= ee my replies in line below... Thanks for addressing most of my comments. -- Eric From: Yaacov Weingarten [mailto:wyaacov@gmail.com] Sent: Wednesday, April 17, 2013 8:56 AM To: Eric Gray Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tools-ietf.o= rg; rtg-dir@ietf.org Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-pro= tection-05 Importance: High Eric, hi Thank you for your review and very in-depth comments, I will try to address= some of them inline below (indicated by "yw>>" before the comment. Hope this helps, yaacov On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray > wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on speci= al request. The purpose of the review is to provide assistance to the Routing= ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other comments that yo= u receive, and strive to resolve them through discussion or by updating the d= raft. Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05 Reviewer: Eric Gray Review Date: 17 April, 2013 Intended Status: Informational There is at least one major issue with this document, as it is now written. Comments/Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The "disclaimer" at the end of the Introduction misses a case related to th= e cases excluded from the scope of this document - which is itself presumably out o= f scope. yw>> Assume that you are referring to the disclaimer at the end of section = 1.1 (as opposed to the one at the end of section 1) I did not refer to section 1, I referred to the Introduction. Since this w= as the name of section 1, I thought that referring to it by name would be sufficiently una= mbiguous, since all of section 1 is the Introduction... The text currently talks to protection of a path prior to entry to the ring= , or after exit from the ring. The missing case is when the path is part of a protect= ed service that involves one or more alternative paths external to the ring. It is no= t difficult to think of a scenario in which a protection event outside of the ring will= require that data forwarded across the ring will need to enter the ring at a differ= ent point, leave the ring at a different point, or both. While this would seem to impact the protection of the ring itself (possibly= requiring setup of similar protection for the new path traversing the ring), it shoul= d be quite easy to represent such an occurrence as a set of discrete event/operations = that would not be significantly different when compared to initial setup of prot= ection for the previous path in the ring. If for any reason folks feel that this may not be the case under some circu= mstances this document should either address those cases or explicitly state that th= ey will not be addressed by this document. Alternatively, the issue may be addressed by simply removing the 2nd senten= ce of the "disclaimer" paragraph, or the cases explicitly stated should be expres= sed as "examples." yw>> How about if I change the text of the second sentence to read: "Prote= ction triggers on the transport path prior to the ring ingress node or beyond the egress nodes may be protect= ed by some other mechanism."? Fine. ---------------------------------------------------------------------------= ---------------------------------- Bullet 4 of section 1.3 is confusing as written. The meaning of "LI" is cl= ear enough, but "LE" presents some problems. Suppose that PHP is used; in this case, t= here is no label "expected" at the egress point from the ring (although a label may= be present and will be used by the LSR at that point, that label may not alway= s be the same label). Is PHP never permitted? yw>> regarding this, I seem to recall such a discussion regarding MPLS-TP a= nd PHP. However, in any case if there is no such label, why couldn't LE=3D= null? It is just being presented for discussion, not as an actual label. Okay. Even as an item for discussion, the text seems to imply that one wou= ld always find a label. With PHP, the egress LSR can signal that PHP is to e used by using the appr= opriate NULL label. However, this label never actually shows up on the wire, so the egress LSR = does not expect to see it. My concern is that someone reading this may look to see this as an object t= o be managed. I suppose that it could be read as NULL, so that may not be an issue. And any LSR that signals PHP and then expects to see a specific label is a = darwin candidate. So, fine. Also, under what circumstances would the ring egress point SPME exit LSR no= t be the same? Based on subsequent reading, I believe this would be the case= for use of an SPME to provide "Wrapping" protection - it would probably therefo= re be a good idea to either say something to this effect (if that is the case)= or provide a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or pos= sibly just to section 2.3). I would suggest adding a sentence to this bullet, along the lines of: "See section 2.3 for examples of where the SPME egress and ring exit might = not be the same." yw>> How about if I add ", for example as described in Section 2.3" to the = parenthetical phrase? Fine. ---------------------------------------------------------------------------= ---------------------------------- Section 2 appears to ignore 1+1 protection, which would (similar to "Steeri= ng") use pre-established protection paths from an ingress LSR/node to each egres= s LSR/node but would send that traffic both ways at all times. The main differences between this approach and Steering are: o the need to notify the ingress node is eliminated as a consid= eration for protection switching latency o there is (therefore) no reliance on the existence of a failur= e detection method that is able to notify the ingress of a failure in t= he ring o double bandwidth is required This is carried forward in all subsequent sections/subsections. yw>> 1+1 protection is a linear protection methodology, and Section 2 is de= scribing basic Transport Network ring protection as defined in the ITU - w= hich include Steering and Wrapping. 1+1 does not seem to be popular in rin= gs, since historically SDH seemed to shun this alternative. We do reference= 1+1 transmission in section 3.2 and in the conclusions. Your recollection of ring protection schemes is probably far fresher than m= ine. I distinctly recall ring protection methodologies that provide hitless protection by always sen= ding traffic both ways around the ring. In fact, it is hard for me to imagine how one could = get hitless protection without this sort of scheme. Because this requires sending traffic on both the working and protection pa= th, it is 1+1 and it requires double bandwidth. I am not certain that ignoring 1+1 protection in section 2 and lightly glos= sing it over in later sections addresses my comment, but - if it is too late at this point to fix= it - then I imagine we will just have to live with it. ---------------------------------------------------------------------------= ---------------------------------- Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" compariso= n basis in the bullets relating to "considerations" in each subsection. In o= rder to allow this comparison, both sections would need to provide an indication of= the order of protection paths required in a protection domain. Because - in the "Wrapping" case - it is necessary to provide protection SP= ME for each node and link (in a ring the number of links is exactly the same a= s the number of nodes), the number of protection SPME is O(2N). For the "Steering" case, however, it is necessary to provide protection SPM= E for each ingress node to each egress node (except for the last one) - which= is O(N^2). This statement is actually made in the introductory text in sectio= n 2.4. I would suggest either adding a bullet in section 2.2 and including forward references in these bullets to the analysis in section 2.4, or removing the= bullet in section 2.1. yw>> Could you please specify which bullet you are suggesting to delete? Th= anx I hope you worked this out on your own. The target bullet is both obvious = and unambiguous, given the first paragraph of this comment. I don't even have to look back = at the draft to see it in context. Ths two section compare aspects of protection schemes. One apparently incl= udes a statement about the order of the number of required protection paths, while the other= does not. The comment suggests either adding the missing information as a bullet in s= ection 2.2, or removing the corresponding bullet in section 2.1. Are you saying that you cannot determine from my comment which bullet that = is? ... now looking at the latest draft ... I see (based on the -06 version) that you did not figure this out. Look at the bullets in section 2.1. Then look at the bullets in section 2.= 2. What you should see is that the 2nd bullet in section 2.2 has no counterpart in section 2.2. While this is true of other bullets as well, the comment I made shows that = it is relatively easy to determine the (order of the) number of protection paths required to use = steering as the protection scheme. For other bullets, I can see why they were omitted. A = bullet that talks about the order of the number of protection paths required for steering is = simply not there, for no good reason that I can determine. ---------------------------------------------------------------------------= ---------------------------------- Section 2.3 appears to assume that the desired protection scheme will be ba= sed on "Steering" rather than "Wrapping." This assumption is made without any effort/analysis to justify why this assumption is made (at least as far as = I can see). If that is the intention, minimally, section 2.3 should start with a statem= ent that this is the assumption made. Reading further, however, subsequent subsection 2.3.2 describes how the SPM= E concept - as outlined in the introductory text of section 2.3 - may be used= for the "Wrapping" approach. The confusion arises as a result of figure 3 and the text that describes it= in the preceding paragraph, as this figure/text is what most contributes to an imp= ression that an SPME would start at the ingress and end at an egress. I would suggest that this figure and the preceding paragraph would find a b= etter home on section 2.3.1. This would also align subsections of section 2.3 be= tter as there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4. yw>> Will move the paragraph and figure, as you suggest. ---------------------------------------------------------------------------= ---------------------------------- The last paragraph in introductory text in section 2.3 (immediately prior t= o the start of section 2.3.1) appears to ignore the case where the egress LSR wou= ld use labels to "steer" delivery of labeled packets it receives over the SPME= to specific egress ports (of the egress LSR). These labels would most likely not be a part of the label stack received by= the ingress LSR (there is no need for these labels to be known outside of the r= ing) and would have to be pushed onto the stack before pushing on the label for = an SPME to the egress LSR/node. yw>> Do you have a suggestion on how better to include this consideration? For thatI need to re-read the draft. ... now looking at the latest draft ... Okay, the last paragraph actually ignores a few things: 1) If the ingress and egress LSRs on the ring are adjacent nodes on the rin= g, no swapping occurs. 2) in any case where there are more than 3 LSRs involved in the LSP at the = hierarchical layer of the SPME, there will be N-2 label swaps that ultimately result in the L= E label attached to the PDU arriving at the egress LSR. 3) the point I was trying to make - which was that the ingress LSR may have= been given a label stack (which would not be what you refer to as "LI", and would consist = of more than one label where only the top level label would be seen anywhere in the LSP but at= the ingress, where it is pushed on, and the egress LSR). In re-looking at this, it seems to me that you are trying to avoid this lev= el of detail, so it would be sufficient to "qualify" this description by inserting "in the simplest c= ase" before "packets that arrive..." ---------------------------------------------------------------------------= ---------------------------------- I believe the text in the last paragraph of section 2.3.4 is incorrect in s= tating that protected traffic might not share the same protection path in both directio= ns. If both LSR-B and LSR-F detect that LSR-A is not available, then both will = use the protection SPME between LSR-B and LSR-F. If both LSR-A and LSR-E detect that LSR-F is not available, then both will = use the protection SPME between LSR-A and LSR-E. If both LSR-A and LSR-F detect that the link between them is not available,= then both will use the protection SPME between them. All that is required is that both LSRs in each case agree as to the nature = of the failure (node or link) - which may be easily and consistently determined by monitoring the status of the working and protection SPME. While it is possible for the end-point LSRs in each case to have an inconsi= stent view of the nature of the failure, this inconsistency should be short lived= (based on the periodicity of OAM monitoring of SPMEs). Depending on the OAM monitoring periodicity used - and the length of links = in the ring - this inconsistency may exist for a period of time that is less t= han the latency to be expected for "Steering" based protection. Note that this is a major issue with the current text as it impacts on anal= ysis in subsequent section 2.4 and the conclusion/recommendations of this document. yw>> This statement is the result of review comments that we received durin= g an earlier review of the document, and I am wary of removing it from the = document at this late stage in the review process. In any case, there are = other considerations for limiting both types of protection. I am sure that= your analysis is correct although I am not sure that I understand your emp= hatic objection to the text and how it is related to the analysis in sectio= n 2.4. The analysis appears to be missing information. Yet the analysis is presum= ably the basis on which the conclusions of the draft are based. However, if the WG feels that the conclusions of this draft are correct, th= en there may not be much point in addressing this comment. ---------------------------------------------------------------------------= ---------------------------------- The analysis in section 2.4 is incomplete or based on an incorrect assertio= n made in section 2.3.4. If the alternative suggested in section 2.3.4 were used, the number of SPME= that will be required would be O(4N) - which is still O(N) and would be less tha= n O(N^2) for fewer than the 16-node limit assumption made for the analysis. yw>> This is correct and is certainly correct when the comparison is betwee= n O(2N) and O(N^2). Therefore whether the statement (reiterated in parenth= esis here) is correct or not does not really affect the conclusions. This = is based on the simplicity of Steering and the avoidance of wasted resource= s by transmitting the traffic twice over certain links. Fine ---------------------------------------------------------------------------= ---------------------------------- In the 1st sentence of the last paragraph in the introductory text of secti= on 2.4, the sentence mentions the use of additional resources but does not mention = the additional latency. Is there any reason for the omission? yw>> not really I suggest removing the text in this sentence that starts with "even though"= as it might otherwise be necessary to attempt an exhaustive list of detraction= s. yw>> I have no problem with this suggestion ---------------------------------------------------------------------------= ---------------------------------- Also in the last paragraph of the introductory text in section 2.4, I imagi= ne that the case where one or more pairs of SPME may be eliminated because of LSRs that are not ingress-egress pairs is most likely of trivial value in any de= ployment involving a ring topology. Perhaps the last sentence in the last paragraph of this text in section 2.4= could be removed? yw>> Again, I have no problem with this NITs: =3D=3D=3D=3D In the Introduction section, 5th bullet in (or after) the 2nd paragraph - " Impact of signaling and routing information exchanged during protection, in presence of control plane." - the phrase "in presence of control plane" should probably be "in the presence of a control plane." yw>> will fix ---------------------------------------------------------------------------= ---------------------------------- In the 2nd bullet in section 2.1, I believe it is the case that O(2N) =3D O= (N). yw>> while this is true, I think it is significant to mention the 2N ---------------------------------------------------------------------------= ---------------------------------- In the 1st paragraph of section 2.3.1, where it says "there is always an al= ternative path ..." - at the SPME level (as described in this document), there's alwa= ys exactly one alternative path. yw>> This is not 100% true. What is true is that there is exactly on alter= native path within the ring (there may be additional alternatives that go o= utside the ring). This is why I did not originally add the "exactly" in the= first place. Paths outside of the ring are explicitly out-of-scope. However, this is fi= ne. ---------------------------------------------------------------------------= ---------------------------------- In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) =3D= O(N^2). yw>> see above, same applies to next statement. ---------------------------------------------------------------------------= ---------------------------------- In the 1st and 2nd bullets in section 2.4, I believe it is the case that O(= 2N) =3D O(N). ---------------------------------------------------------------------------= ---------------------------------- -- Thanx and BR, yaacov Still looking for new opportunity --_000_48E1A67CB9CA044EADFEAB87D814BFF60AA2DCeusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaacov,=

 <= /p>

    &= nbsp;           I didn't = see this response until I specifically went looking for it.

 <= /p>

    &= nbsp;           Sorry to = have taken so long to get back to you.

 <= /p>

    &= nbsp;           For the m= ost part, your counter proposal is good enough.  See my

replies in line below…<= /i>

 <= /p>

    &= nbsp;           Thanks fo= r addressing most of my comments.

 <= /p>

--

Eric

 <= /p>

From: Yaacov W= eingarten [mailto:wyaacov@gmail.com]
Sent: Wednesday, April 17, 2013 8:56 AM
To: Eric Gray
Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tools= -ietf.org; rtg-dir@ietf.org
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-r= ing-protection-05
Importance: High

 

Eric, hi

 

Thank you for your review and very in-depth comments= , I will try to address some of them inline below (indicated by "yw>= ;>" before the comment.

 

Hope this helps,

yaacov

On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray <eric.gray@ericsson.c= om> wrote:

Hello,

 

I have been selected as the Routing Directorate reviewer for this = draft.

 

The Routing Directorate seeks to review all routing or routing-rel= ated drafts

as they pass through IETF last call and IESG review, and sometimes= on special

request. The purpose of the review is to provide assistance to &nb= sp;the Routing ADs.

 

For more information about the Routing Directorate, please see

http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are primarily for the use of the Routing A= Ds, it would

be helpful if you could consider them along with any other comment= s that you

receive, and strive to resolve them through discussion or by updat= ing the draft.

 

Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05

Reviewer: Eric Gray

Review Date: 17 April, 2013

Intended Status: Informational

 

There is at least one major issue with this document, as it is now= written.

 

Comments/Questions:

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

 

The "disclaimer" at the end of the Introduction misses a= case related to the cases

excluded from the scope of this document – which is itself p= resumably out of scope. 

 

yw>> Assume that you are referring to the disc= laimer at the end of section 1.1 (as opposed to the one at the end of secti= on 1) 

 <= /p>

I did not refer = to section 1, I referred to the Introduction.  Since this was the name= of

section 1, I tho= ught that referring to it by name would be sufficiently unambiguous,

since all of sec= tion 1 is the Introduction…

 

 

The text currently talks to protection of a path prior to entry to= the ring, or after

exit from the ring.  The missing case is when the path is par= t of a protected service

that involves one or more alternative paths external to the ring.&= nbsp; It is not difficult

to think of a scenario in which a protection event outside of the = ring will require

that data forwarded across the ring will need to enter the ring at= a different point,

leave the ring at a different point, or both.

 

While this would seem to impact the protection of the ring itself = (possibly requiring

setup of similar protection for the new path traversing the ring),= it should be quite

easy to represent such an occurrence as a set of discrete event/op= erations that

would not be significantly different when compared to initial setu= p of protection for

the previous path in the ring.

 

If for any reason folks feel that this may not be the case under s= ome circumstances

this document should either address those cases or explicitly stat= e that they will not

be addressed by this document.

 

Alternatively, the issue may be addressed by simply removing the 2= nd sentence of

the "disclaimer" paragraph, or the cases explicitly stat= ed should be expressed as

"examples."

 

yw>> How about if I change the text of the sec= ond sentence to read:  "Protection triggers on the transport path=
   prior to the ring ingress node or beyond the egress nodes may = be protected by some other mechanism."?

 <= /p>

Fine.=

 

------------------------------------------------------------------= -------------------------------------------

 

Bullet 4 of section 1.3 is confusing as written.  The meaning= of "LI" is clear enough,

but "LE" presents some problems.  Suppose that PHP = is used; in this case, there is

no label "expected" at the egress point from the ring (a= lthough a label may be

present and will be used by the LSR at that point, that label may = not always be the

same label).

 

Is PHP never permitted?

 

yw>> regarding this, I seem to recall such a d= iscussion regarding MPLS-TP and PHP.  However, in any case if the= re is no such label, why couldn't LE=3Dnull? It is just being presented for= discussion, not as an actual label. 

 <= /p>

Okay.  Even= as an item for discussion, the text seems to imply that one would always f= ind a label.

With PHP, the eg= ress LSR can signal that PHP is to e used by using the appropriate NULL lab= el.

However, this la= bel never actually shows up on the wire, so the egress LSR does not expect = to

see it.

 

My concern is th= at someone reading this may look to see this as an object to be managed.&nb= sp; I

suppose that it = could be read as NULL, so that may not be an issue.

 

And any LSR that= signals PHP and then expects to see a specific label is a darwin candidate= .

 

So, fine.

 

 

Also, under what circumstances would the ring egress point SPME ex= it LSR not

be the same?  Based on subsequent reading, I believe this wou= ld be the case for

use of an SPME to provide "Wrapping" protection – = it would probably therefore

be a good idea to either say something to this effect (if that is = the case) or provide

a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for exampl= e, or possibly

just to section 2.3).

 

I would suggest adding a sentence to this bullet, along the lines = of:

 

"See section 2.3 for examples of where the SPME egress and ri= ng exit might not

be the same."

 

yw>> How about if I add ", for examp= le as described in Section 2.3" to the parenthetical phrase?=

 <= /p>

Fine.=

 

------------------------------------------------------------------= -------------------------------------------

 

Section 2 appears to ignore 1+1 protection, which would (simil= ar to "Steering")

use pre-established protection paths from an ingress LSR/node to e= ach egress

LSR/node but would send that traffic both ways at all times. 

 

The main differences between this approach and Steering are:<= /o:p>

 

o           = ;  the need to notify the ingress node is eliminated as a consideratio= n for

           =      protection switching latency

o           = ;  there is (therefore) no reliance on the existence of a failure dete= ction

           =      method that is able to notify the ingress of a fai= lure in the ring

o           = ;  double bandwidth is required

 

This is carried forward in all subsequent sections/subsections.

 

yw>> 1+1 protection is a linear protection= methodology, and Section 2 is describing basic Transport Network ring prot= ection as defined in  the ITU - which include Steering and Wrapping.&n= bsp; 1+1 does not seem to be popular in rings, since historically SDH seemed to shun this alternative. We do reference 1+1 transmis= sion in section 3.2 and in the conclusions.

 <= /p>

Your recollectio= n of ring protection schemes is probably far fresher than mine.  I dis= tinctly recall

ring protection = methodologies that provide hitless protection by always sending traffic bot= h

ways around the = ring.  In fact, it is hard for me to imagine how one could get hitless= protection

without this sor= t of scheme.

 

Because this req= uires sending traffic on both the working and protection path, it is 1+= 1 and it

requires double = bandwidth.

 

I am not certain= that ignoring 1+1 protection in section 2 and lightly glossing it over= in later

sections address= es my comment, but – if it is too late at this point to fix it –= ; then I imagine

we will just hav= e to live with it.

 

------------------------------------------------------------------= -------------------------------------------

 

Sections 2.1 and 2.2 do not exactly provide an "apples-to-app= les" comparison

basis in the bullets relating to "considerations" in eac= h subsection.  In order to

allow this comparison, both sections would need to provide an indi= cation of the

order of protection paths required in a protection domain.

 

Because – in the "Wrapping" case – it is nec= essary to provide protection SPME

for each node and link (in a ring the number of links is exactly t= he same as the

number of nodes), the number of protection SPME is O(2N).

 

For the "Steering" case, however, it is necessary to pro= vide protection SPME

for each ingress node to each egress node (except for the last one= ) – which is

O(N^2).  This statement is actually made in the introductory = text in section 2.4.

 

I would suggest either adding a bullet in section 2.2 and includin= g forward

references in these bullets to the analysis in section 2.4, or rem= oving the bullet

in section 2.1.

 

yw>> Could you please specify which bullet you= are suggesting to delete? Thanx 

 <= /p>

I hope you worke= d this out on your own.  The target bullet is both obvious and unambig= uous,

given the first = paragraph of this comment.  I don't even have to look back at the draf= t to see

it in context.

 

Ths two section = compare aspects of protection schemes.  One apparently includes a stat= ement

about the order = of the number of required protection paths, while the other does not.<= /o:p>

 

The comment sugg= ests either adding the missing information as a bullet in section 2.2, or

removing the cor= responding bullet in section 2.1.

 

Are you saying t= hat you cannot determine from my comment which bullet that is?

 

… now look= ing at the latest draft …

 

I see (based on = the -06 version) that you did not figure this out.

 

Look at the bull= ets in section 2.1.  Then look at the bullets in section 2.2.  Wh= at you should see

is that the 2nd bullet in section 2.2 has no counterpart in section 2.2.

 

While this is tr= ue of other bullets as well, the comment I made shows that it is relatively= easy

to determine the= (order of the) number of protection paths required to use steering as the<= o:p>

protection schem= e.  For other bullets, I can see why they were omitted.  A bullet= that talks

about the order = of the number of protection paths required for steering is simply not there= ,

for no good reas= on that I can determine.

 

------------------------------------------------------------------= -------------------------------------------

 

Section 2.3 appears to assume that the desired protection scheme w= ill be based

on "Steering" rather than "Wrapping."  Th= is assumption is made without any

effort/analysis to justify why this assumption is made (at least a= s far as I can see).

 

If that is the intention, minimally, section 2.3 should start with= a statement that

this is the assumption made.

 

Reading further, however, subsequent subsection 2.3.2 describes ho= w the SPME

concept – as outlined in the introductory text of section 2.= 3 – may be used for the

"Wrapping" approach.

 

The confusion arises as a result of figure 3 and the text that des= cribes it in the

preceding paragraph, as this figure/text is what most contributes = to an impression

that an SPME would start at the ingress and end at an egress.=

 

I would suggest that this figure and the preceding paragraph would= find a better

home on section 2.3.1.  This would also align subsections of = section 2.3 better as

there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4.<= /o:p>

 

yw>> Will move the paragraph and figure, as yo= u suggest. 

 

------------------------------------------------------------------= -------------------------------------------

 

The last paragraph in introductory text in section 2.3 (immediatel= y prior to the

start of section 2.3.1) appears to ignore the case where the egres= s LSR would

use labels to "steer" delivery of labeled packets it rec= eives over the SPME to

specific egress ports (of the egress LSR). 

 

These labels would most likely not be a part of the label stack re= ceived by the

ingress LSR (there is no need for these labels to be known outside= of the ring)

and would have to be pushed onto the stack before pushing on the l= abel for an

SPME to the egress LSR/node.

 

yw>> Do you have a suggestion on how better to= include this consideration? 

 <= /p>

For thatI need t= o re-read the draft.

 

… now look= ing at the latest draft …

 

Okay, the last p= aragraph actually ignores a few things:

1) If the ingres= s and egress LSRs on the ring are adjacent nodes on the ring, no swapping o= ccurs.

2) in any case w= here there are more than 3 LSRs involved in the LSP at the hierarchical lay= er of

  &nbs= p; the SPME, there will be N-2 label swaps that ultimately result in the LE= label attached to the

  &nbs= p; PDU arriving at the egress LSR.

3) the point I w= as trying to make – which was that the ingress LSR may have been give= n a label

  &nbs= p; stack (which would not be what you refer to as "LI", and would= consist of more than one label

  &nbs= p; where only the top level label would be seen anywhere in the LSP bu= t at the ingress, where it

  &nbs= p;  is pushed on, and the egress LSR).<= /b>

 

In re-looking at= this, it seems to me that you are trying to avoid this level of detail, so= it would

be sufficient to= "qualify" this description by inserting "in the simplest ca= se" before "packets that

arrive…&qu= ot;

 

------------------------------------------------------------------= -------------------------------------------

 

I believe the text in the last paragraph of section 2.3.4 is incor= rect in stating that

protected traffic might not share the same protection path in both= directions.

 

If both LSR-B and LSR-F detect that LSR-A is not available, then b= oth will use the

protection SPME between LSR-B and LSR-F.

 

If both LSR-A and LSR-E detect that LSR-F is not available, then b= oth will use the

protection SPME between LSR-A and LSR-E.

 

If both LSR-A and LSR-F detect that the link between them is not a= vailable, then

both will use the protection SPME between them.

 

All that is required is that both LSRs in each case agree as to th= e nature of the

failure (node or link) – which may be easily and consistentl= y determined by

monitoring the status of the working and protection SPME.

 

While it is possible for the end-point LSRs in each case to have a= n inconsistent

view of the nature of the failure, this inconsistency should be sh= ort lived (based

on the periodicity of OAM monitoring of SPMEs).

 

Depending on the OAM monitoring periodicity used – and the l= ength of links in

the ring – this inconsistency may exist for a period of time= that is less than the

latency to be expected for "Steering" based protection.<= o:p>

 

Note that this is a major issue with the current text as = it impacts on analysis in

subsequent section 2.4 and the conclusion/recommendations= of this document.

 

yw>> This statement is the result of review co= mments that we received during an earlier review of the document, and I am = wary of removing it from the document at this late stage in the review proc= ess.  In any case, there are other considerations for limiting both types of protection.  I am sure that your analysis = is correct although I am not sure that I understand your emphatic objection= to the text and how it is related to the analysis in section 2.4.

 <= /p>

The analysis app= ears to be missing information.  Yet the analysis is presumably the ba= sis on

which the conclu= sions of the draft are based.

 

However, if the = WG feels that the conclusions of this draft are correct, then there may not=

be much point in= addressing this comment.

 

------------------------------------------------------------------= -------------------------------------------

 

The analysis in section 2.4 is incomplete or based on an incorrect= assertion made

in section 2.3.4.

 

If the alternative suggested in section 2.3.4 were used, the numbe= r of SPME that

will be required would be O(4N) – which is still O(N) and wo= uld be less than O(N^2)

for fewer than the 16-node limit assumption made for the analysis.

 

yw>> This is correct and is certainly correct = when the comparison is between O(2N) and O(N^2).  Therefore wheth= er the statement (reiterated in parenthesis here) is correct or not do= es not really affect the conclusions.  This is based on the simplicity of Steering and the avoidance of wasted resources by transm= itting the traffic twice over certain links.

 <= /p>

Fine<= /span>

 

------------------------------------------------------------------= -------------------------------------------

 

In the 1st sentence of the last paragraph in the introd= uctory text of section 2.4,

the sentence mentions the use of additional resources but does not= mention the

additional latency.

 

Is there any reason for the omission?

 

yw>> not really 

 

 

I suggest removing the text in this sentence that starts with &quo= t;even though" as

it might otherwise be necessary to attempt an exhaustive list of d= etractions.

 

yw>> I have no problem with this suggestion&nb= sp;

 

------------------------------------------------------------------= -------------------------------------------

 

Also in the last paragraph of the introductory text in section 2.4= , I imagine that

the case where one or more pairs of SPME may be eliminated because= of LSRs

that are not ingress-egress pairs is most likely of trivial value = in any deployment

involving a ring topology. 

 

Perhaps the last sentence in the last paragraph of this text in se= ction 2.4 could be

removed?

 

yw>> Again, I have no problem with this <= o:p>

 

 

NITs:

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

 

In the Introduction section, 5th bullet in (or after) t= he 2nd paragraph –

 

   " Impact of signaling and routing information ex= changed during

      protection, in presence of control = plane."

 

- the phrase "in presence of control plane" should proba= bly be "in the

presence of a control plane."

 

yw>> will fix 

 

------------------------------------------------------------------= -------------------------------------------

 

In the 2nd bullet in section 2.1, I believe it is the c= ase that O(2N) =3D O(N).

 

yw>> while this is true, I think it is signifi= cant to mention the 2N 

 

------------------------------------------------------------------= -------------------------------------------

 

In the 1st paragraph of section 2.3.1, where it says &q= uot;there is always an alternative

path …" – at the SPME level (as described in this= document), there's always exactly

one  alternative path.

yw>> This is not 100% true.  What is true=  is that there is exactly on alternative path within the ring (there m= ay be additional alternatives that go outside the ring). This is why I did = not originally add the "exactly" in the first place. 

 <= /p>

Paths outside of= the ring are explicitly out-of-scope.  However, this is fine.

------------------------------------------------------------------= -------------------------------------------

 

In the 1st bullet in section 2.4, I believe it is the c= ase that O(2N^2) =3D O(N^2).

 

yw>> see above, same applies to next statement= . 

 

------------------------------------------------------------------= -------------------------------------------

 

In the 1st and 2nd bullets in section 2.4, I= believe it is the case that O(2N) =3D O(N).

------------------------------------------------------------------= -------------------------------------------

 

 

 

 




--

Thanx and BR,

yaacov

 

Still looking for new opportunity<= /p>

--_000_48E1A67CB9CA044EADFEAB87D814BFF60AA2DCeusaamb107ericsso_-- From wyaacov@gmail.com Tue May 21 00:15:42 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371E521F96B5 for ; Tue, 21 May 2013 00:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-zXwTYEFmcH for ; Tue, 21 May 2013 00:15:39 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0532521F9625 for ; Tue, 21 May 2013 00:15:38 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so168314vbh.40 for ; Tue, 21 May 2013 00:15:38 -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=Z4qsBTlJNEvG2IghvjLCR71GY/DtFM10PRkQ603pcZE=; b=x1V16b71gvFSPUwbL44ML+Jn/mwGEOU1mCIeu6XJOp4Xu/lRLvDL+93jREUa0rjGoZ XJyBvr5G8rjlwNlW1CvlFliBkWQBGspveS66gd0F3tfpulVyg9P6SySF9gXKqauauVcx o8s9lbsCtkAM5CWP5urmNJWIcbVT21JqQ3SJ8C21Qh3VFjGm0WQJOYPUPnU1FcYyTMMN Hrefti8TaK73Vu07bBJGxR1Z65k+ahF6URoYITr1KMHyymdlH3FDoxz6Wa31NyAsdpIh j8qMH3BHjpNaBMszMow9II7jeWFIkXd8GvbGjqHHulDNZ/5sYZ8q3icmGNuWA2afU2HC hTZA== MIME-Version: 1.0 X-Received: by 10.52.183.170 with SMTP id en10mr355998vdc.5.1369120538384; Tue, 21 May 2013 00:15:38 -0700 (PDT) Received: by 10.52.171.39 with HTTP; Tue, 21 May 2013 00:15:38 -0700 (PDT) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF60AA2DC@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF60AA2DC@eusaamb107.ericsson.se> Date: Tue, 21 May 2013 10:15:38 +0300 Message-ID: From: Yaacov Weingarten To: Eric Gray Content-Type: multipart/alternative; boundary=bcaec548a1b358617e04dd353778 X-Mailman-Approved-At: Tue, 21 May 2013 05:07:09 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools-ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:15:42 -0000 --bcaec548a1b358617e04dd353778 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Eric, hi I guess I am happy to say that this is out of my hands now as the document has been approved by the IESG. Unless you think that these issues are critical, I do not think that I can address them without approval from the ADs. If you know of a different process, I am willing to be enlightened! Thanx anyway, yaacov On Tue, May 14, 2013 at 7:24 PM, Eric Gray wrote: > Yaacov,**** > > ** ** > > I didn't see this response until I specifically went > looking for it.**** > > ** ** > > Sorry to have taken so long to get back to you.**** > > ** ** > > For the most part, your counter proposal is good enough. > See my**** > > replies *in line below=85***** > > ** ** > > Thanks for addressing most of my comments. **** > > ** ** > > --**** > > Eric**** > > ** ** > > *From:* Yaacov Weingarten [mailto:wyaacov@gmail.com] > *Sent:* Wednesday, April 17, 2013 8:56 AM > *To:* Eric Gray > *Cc:* draft-ietf-mpls-tp-ring-protection@tools.ietf.org; > rtg-ads@tools-ietf.org; rtg-dir@ietf.org > *Subject:* Re: Routing Area Directorate Review of > draft-ietf-mpls-tp-ring-protection-05 > *Importance:* High**** > > ** ** > > Eric, hi**** > > **** > > Thank you for your review and very in-depth comments, I will try to > address some of them inline below (indicated by "yw>>" before the comment= . > **** > > **** > > Hope this helps,**** > > yaacov**** > > On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray wrote= : > **** > > Hello,**** > > **** > > I have been selected as the Routing Directorate reviewer for this draft. = * > *** > > **** > > The Routing Directorate seeks to review all routing or routing-related > drafts **** > > as they pass through IETF last call and IESG review, and sometimes on > special **** > > request. The purpose of the review is to provide assistance to the > Routing ADs. **** > > **** > > For more information about the Routing Directorate, please see **** > > http://www.ietf.org/iesg/directorate/routing.html**** > > **** > > Although these comments are primarily for the use of the Routing ADs, it > would **** > > be helpful if you could consider them along with any other comments that > you **** > > receive, and strive to resolve them through discussion or by updating the > draft. **** > > **** > > Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-0= 5 > **** > > Reviewer: Eric Gray**** > > Review Date: 17 April, 2013**** > > Intended Status: Informational**** > > **** > > There is at least one major issue with this document, as it is now writte= n. > **** > > **** > > Comments/Questions:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > **** > > The "disclaimer" at the end of the Introduction misses a case related to > the cases**** > > excluded from the scope of this document =96 which is itself presumably o= ut > of scope. **** > > **** > > yw>> Assume that you are referring to the disclaimer at the end of sectio= n > 1.1 (as opposed to the one at the end of section 1) **** > > ** ** > > *I did not refer to section 1, I referred to the Introduction. Since > this was the name of* > > *section 1, I thought that referring to it by name would be sufficiently > unambiguous,* > > *since all of section 1 is the Introduction=85* > > **** > > **** > > The text currently talks to protection of a path prior to entry to the > ring, or after **** > > exit from the ring. The missing case is when the path is part of a > protected service**** > > that involves one or more alternative paths external to the ring. It is > not difficult**** > > to think of a scenario in which a protection event outside of the ring > will require**** > > that data forwarded across the ring will need to enter the ring at a > different point,**** > > leave the ring at a different point, or both.**** > > **** > > While this would seem to impact the protection of the ring itself > (possibly requiring**** > > setup of similar protection for the new path traversing the ring), it > should be quite**** > > easy to represent such an occurrence as a set of discrete event/operation= s > that **** > > would not be significantly different when compared to initial setup of > protection for**** > > the previous path in the ring.**** > > **** > > If for any reason folks feel that this may not be the case under some > circumstances**** > > this document should either address those cases or explicitly state that > they will not**** > > be addressed by this document.**** > > **** > > Alternatively, the issue may be addressed by simply removing the 2ndsente= nce of > **** > > the "disclaimer" paragraph, or the cases explicitly stated should be > expressed as**** > > "examples."**** > > **** > > yw>> How about if I change the text of the second sentence to read: > "Protection triggers on the transport path > prior to the ring ingress node or beyond the egress nodes may be > protected by some other mechanism."?**** > > ** ** > > *Fine.* > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > Bullet 4 of section 1.3 is confusing as written. The meaning of "LI" is > clear enough,**** > > but "LE" presents some problems. Suppose that PHP is used; in this case, > there is **** > > no label "expected" at the egress point from the ring (although a label > may be **** > > present and will be used by the LSR at that point, that label may not > always be the**** > > same label).**** > > **** > > Is PHP never permitted?**** > > **** > > yw>> regarding this, I seem to recall such a discussion regarding > MPLS-TP and PHP. However, in any case if there is no such label, why > couldn't LE=3Dnull? It is just being presented for discussion, not as an > actual label. **** > > ** ** > > *Okay. Even as an item for discussion, the text seems to imply that one > would always find a label.* > > *With PHP, the egress LSR can signal that PHP is to e used by using the > appropriate NULL label.* > > *However, this label never actually shows up on the wire, so the egress > LSR does not expect to* > > *see it.* > > * * > > *My concern is that someone reading this may look to see this as an > object to be managed. I* > > *suppose that it could be read as NULL, so that may not be an issue.* > > * * > > *And any LSR that signals PHP and then expects to see a specific label is > a darwin candidate.* > > * * > > *So, fine.* > > **** > > **** > > Also, under what circumstances would the ring egress point SPME exit LSR > not**** > > be the same? Based on subsequent reading, I believe this would be the > case for**** > > use of an SPME to provide "Wrapping" protection =96 it would probably > therefore**** > > be a good idea to either say something to this effect (if that is the > case) or provide**** > > a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or > possibly**** > > just to section 2.3).**** > > **** > > I would suggest adding a sentence to this bullet, along the lines of:**** > > **** > > "See section 2.3 for examples of where the SPME egress and ring exit migh= t > not**** > > be the same."**** > > **** > > yw>> How about if I add ", for example as described in Section 2.3" to > the parenthetical phrase?**** > > ** ** > > *Fine.* > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > Section 2 appears to ignore 1+1 protection, which would (similar to > "Steering")**** > > use pre-established protection paths from an ingress LSR/node to each > egress**** > > LSR/node but would send that traffic both ways at all times. **** > > **** > > The main differences between this approach and Steering are:**** > > **** > > o the need to notify the ingress node is eliminated as a > consideration for **** > > protection switching latency**** > > o there is (therefore) no reliance on the existence of a > failure detection **** > > method that is able to notify the ingress of a failure in > the ring**** > > o double bandwidth *is* required **** > > **** > > This is carried forward in all subsequent sections/subsections.**** > > **** > > yw>> 1+1 protection is a linear protection methodology, and Section 2 is > describing basic Transport Network ring protection as defined in the ITU= - > which include Steering and Wrapping. 1+1 does not seem to be popular in > rings, since historically SDH seemed to shun this alternative. We do > reference 1+1 transmission in section 3.2 and in the conclusions.**** > > ** ** > > *Your recollection of ring protection schemes is probably far fresher > than mine. I distinctly recall* > > *ring protection methodologies that provide hitless protection by always > sending traffic both* > > *ways around the ring. In fact, it is hard for me to imagine how one > could get hitless protection* > > *without this sort of scheme.* > > * * > > *Because this requires sending traffic on both the working and protection > path, it is 1+1 and it* > > *requires double bandwidth.* > > * * > > *I am not certain that ignoring 1+1 protection in section 2 and lightly > glossing it over in later* > > *sections addresses my comment, but =96 if it is too late at this point t= o > fix it =96 then I imagine * > > *we will just have to live with it.* > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" > comparison**** > > basis in the bullets relating to "considerations" in each subsection. In > order to **** > > allow this comparison, both sections would need to provide an indication > of the**** > > order of protection paths required *in a protection domain*. **** > > **** > > Because =96 in the "Wrapping" case =96 it is necessary to provide protect= ion > SPME**** > > for each node and link (in a ring the number of links is exactly the same > as the **** > > number of nodes), the number of protection SPME is O(2N).**** > > **** > > For the "Steering" case, however, it is necessary to provide protection > SPME**** > > for each ingress node to each egress node (except for the last one) =96 > which is**** > > O(N^2). This statement is actually made in the introductory text in > section 2.4.**** > > **** > > I would suggest either adding a bullet in section 2.2 and including forwa= rd > **** > > references in these bullets to the analysis in section 2.4, or removing > the bullet**** > > in section 2.1.**** > > **** > > yw>> Could you please specify which bullet you are suggesting to delete? > Thanx **** > > ** ** > > *I hope you worked this out on your own. The target bullet is both > obvious and unambiguous,* > > *given the first paragraph of this comment. I don't even have to look > back at the draft to see* > > *it in context.* > > * * > > *Ths two section compare aspects of protection schemes. One apparently > includes a statement* > > *about the order of the number of required protection paths, while the > other does not.* > > * * > > *The comment suggests either adding the missing information as a bullet > in section 2.2, or * > > *removing the corresponding bullet in section 2.1.* > > * * > > *Are you saying that you cannot determine from my comment which bullet > that is?* > > * * > > *=85 now looking at the latest draft =85* > > * * > > *I see (based on the -06 version) that you did not figure this out.* > > * * > > *Look at the bullets in section 2.1. Then look at the bullets in section > 2.2. What you should see* > > *is that the 2nd bullet in section 2.2 has no counterpart in section 2.2.= * > > * * > > *While this is true of other bullets as well, the comment I made shows > that it is relatively easy* > > *to determine the (order of the) number of protection paths required to > use steering as the* > > *protection scheme. For other bullets, I can see why they were omitted. > A bullet that talks* > > *about the order of the number of protection paths required for steering > is simply not there,* > > *for no good reason that I can determine.* > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > Section 2.3 appears to assume that the desired protection scheme will be > based**** > > on "Steering" rather than "Wrapping." This assumption is made without an= y > **** > > effort/analysis to justify why this assumption is made (at least as far a= s > I can see). **** > > **** > > If that is the intention, minimally, section 2.3 should start with a > statement that **** > > this is the assumption made.**** > > **** > > Reading further, however, subsequent subsection 2.3.2 describes how the > SPME**** > > concept =96 as outlined in the introductory text of section 2.3 =96 may b= e > used for the**** > > "Wrapping" approach.**** > > **** > > The confusion arises as a result of figure 3 and the text that describes > it in the **** > > preceding paragraph, as this figure/text is what most contributes to an > impression**** > > that an SPME would start at the ingress and end at an egress.**** > > **** > > I would suggest that this figure and the preceding paragraph would find a > better **** > > home on section 2.3.1. This would also align subsections of section 2.3 > better as **** > > there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4.**** > > **** > > yw>> Will move the paragraph and figure, as you suggest. **** > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > The last paragraph in introductory text in section 2.3 (immediately prior > to the**** > > start of section 2.3.1) appears to ignore the case where the egress LSR > would**** > > use labels to "steer" delivery of labeled packets it receives over the > SPME to**** > > specific egress ports (of the egress LSR). **** > > **** > > These labels would most likely not be a part of the label stack received > by the **** > > ingress LSR (there is no need for these labels to be known outside of the > ring)**** > > and would have to be pushed onto the stack before pushing on the label fo= r > an**** > > SPME to the egress LSR/node.**** > > **** > > yw>> Do you have a suggestion on how better to include this consideration= ? > **** > > ** ** > > *For thatI need to re-read the draft.* > > * * > > *=85 now looking at the latest draft =85* > > * * > > *Okay, the last paragraph actually ignores a few things:* > > *1) If the ingress and egress LSRs on the ring are adjacent nodes on the > ring, no swapping occurs.* > > *2) in any case where there are more than 3 LSRs involved in the LSP at > the hierarchical layer of* > > * the SPME, there will be N-2 label swaps that ultimately result in > the LE label attached to the* > > * PDU arriving at the egress LSR.* > > *3) the point I was trying to make =96 which was that the ingress LSR may > have been given a label* > > * stack (which would not be what you refer to as "LI", and would > consist of more than one label * > > * where only the top level label would be seen anywhere in the LSP but > at the ingress, where it * > > * is pushed on, and the egress LSR).* > > * * > > *In re-looking at this, it seems to me that you are trying to avoid this > level of detail, so it would* > > *be sufficient to "qualify" this description by inserting "in the > simplest case" before "packets that* > > *arrive=85"* > > * * > > ** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > I believe the text in the last paragraph of section 2.3.4 is incorrect in > stating that**** > > protected traffic might not share the same protection path in both > directions.**** > > **** > > If both LSR-B and LSR-F detect that LSR-A is not available, then both wil= l > use the**** > > protection SPME between LSR-B and LSR-F.**** > > **** > > If both LSR-A and LSR-E detect that LSR-F is not available, then both wil= l > use the**** > > protection SPME between LSR-A and LSR-E.**** > > **** > > If both LSR-A and LSR-F detect that the link between them is not > available, then**** > > both will use the protection SPME between them.**** > > **** > > All that is required is that both LSRs in each case agree as to the natur= e > of the **** > > failure (node or link) =96 which may be easily and consistently determine= d by > **** > > monitoring the status of the working and protection SPME. **** > > **** > > While it is possible for the end-point LSRs in each case to have an > inconsistent**** > > view of the nature of the failure, this inconsistency should be short > lived (based**** > > on the periodicity of OAM monitoring of SPMEs).**** > > **** > > Depending on the OAM monitoring periodicity used =96 and the length of li= nks > in **** > > the ring =96 this inconsistency may exist for a period of time that is le= ss > than the **** > > latency to be expected for "Steering" based protection.**** > > **** > > *Note that this is a major issue with the current text as it impacts on > analysis in***** > > *subsequent section 2.4 and the conclusion/recommendations of this > document.***** > > **** > > yw>> This statement is the result of review comments that we received > during an earlier review of the document, and I am wary of removing it fr= om > the document at this late stage in the review process. In any case, ther= e > are other considerations for limiting both types of protection. I am sur= e > that your analysis is correct although I am not sure that I understand yo= ur > emphatic objection to the text and how it is related to the analysis in > section 2.4.**** > > ** ** > > *The analysis appears to be missing information. Yet the analysis is > presumably the basis on* > > *which the conclusions of the draft are based.* > > * * > > *However, if the WG feels that the conclusions of this draft are correct, > then there may not* > > *be much point in addressing this comment.* > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > The analysis in section 2.4 is incomplete or based on an incorrect > assertion made**** > > in section 2.3.4.**** > > **** > > If the alternative suggested in section 2.3.4 were used, the number of > SPME that**** > > will be required would be O(4N) =96 which is still O(N) and would be less > than O(N^2)**** > > for fewer than the 16-node limit assumption made for the analysis. **** > > **** > > yw>> This is correct and is certainly correct when the comparison is > between O(2N) and O(N^2). Therefore whether the statement (reiterated in > parenthesis here) is correct or not does not really affect the > conclusions. This is based on the simplicity of Steering and the avoidan= ce > of wasted resources by transmitting the traffic twice over certain links.= * > *** > > ** ** > > *Fine* > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > In the 1st sentence of the last paragraph in the introductory text of > section 2.4,**** > > the sentence mentions the use of additional resources but does not mentio= n > the**** > > additional latency.**** > > **** > > Is there any reason for the omission?**** > > **** > > yw>> not really **** > > **** > > **** > > I suggest removing the text in this sentence that starts with "even > though" as**** > > it might otherwise be necessary to attempt an exhaustive list of > detractions. **** > > **** > > yw>> I have no problem with this suggestion **** > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > Also in the last paragraph of the introductory text in section 2.4, I > imagine that**** > > the case where one or more pairs of SPME may be eliminated because of LSR= s > **** > > that are not ingress-egress pairs is most likely of trivial value in any > deployment**** > > involving a ring topology. **** > > **** > > Perhaps the last sentence in the last paragraph of this text in section > 2.4 could be**** > > removed?**** > > **** > > yw>> Again, I have no problem with this **** > > **** > > **** > > NITs:**** > > =3D=3D=3D=3D**** > > **** > > In the Introduction section, 5th bullet in (or after) the 2nd paragraph = =96 > **** > > **** > > " Impact of signaling and routing information exchanged during**** > > protection, in presence of control plane."**** > > **** > > - the phrase "in presence of control plane" should probably be "in *the* = * > *** > > presence of *a* control plane." **** > > **** > > yw>> will fix **** > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > In the 2nd bullet in section 2.1, I believe it is the case that O(2N) =3D > O(N).**** > > **** > > yw>> while this is true, I think it is significant to mention the 2N **** > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > In the 1st paragraph of section 2.3.1, where it says "there is always an > alternative**** > > path =85" =96 at the SPME level (as described in this document), there's > always *exactly ***** > > *one* alternative path.**** > > yw>> This is not 100% true. What is true is that there is exactly on > alternative path within the ring (there may be additional alternatives th= at > go outside the ring). This is why I did not originally add the "exactly" = in > the first place. **** > > ** ** > > *Paths outside of the ring are explicitly out-of-scope. However, this is > fine.* > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) = =3D > O(N^2). **** > > **** > > yw>> see above, same applies to next statement. **** > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > In the 1st and 2nd bullets in section 2.4, I believe it is the case that > O(2N) =3D O(N). **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > **** > > **** > > **** > > **** > > > > > -- **** > > Thanx and BR,**** > > yaacov**** > > ** ** > > *Still looking for new opportunity***** > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --bcaec548a1b358617e04dd353778 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Eric, hi
=A0
I guess I am happy t= o say that this is out of my hands now as the document has been approved by= the IESG. Unless you think that these issues are critical, I do not think = that I can address them without approval from the ADs.
=A0
If you know of a different process, I am willing to be e= nlightened!
=A0
Thanx anyway,
yaacov


On Tue, Ma= y 14, 2013 at 7:24 PM, Eric Gray <eric.gray@ericsson.com> wrote:

Yaacov,

=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 I didn't see this response until I specific= ally went looking for it.

=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Sorry to have taken so long to get back to you.=

=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 For the most part, your counter proposal is goo= d enough.=A0 See my

replies in line below=85

=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks for addressing most of my comments.

=A0

--

Eric

=A0

From: Yaacov Weing= arten [mailto:wyaaco= v@gmail.com]
Sent: Wednesday, April 17, 2013 8:56 AM
To: Eric Gray
Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tool= s-ietf.org; rtg-d= ir@ietf.org
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-r= ing-protection-05
Importance: High

=A0

Eric, hi

=A0

Thank you for your review and very in-depth comments= , I will try to address some of them inline below (indicated by "yw>= ;>" before the comment.

=A0

Hope this helps,

yaacov

On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray <eric.gray@ericsson.c= om> wrote:

Hello,

=A0

I have been selected as the Routing Directorate revi= ewer for this draft.

=A0

The Routing Directorate seeks to review all routing = or routing-related drafts

as they pass through IETF last call and IESG review,= and sometimes on special

request. The purpose of the review is to provide ass= istance to =A0the Routing ADs.

=A0

For more information about the Routing Directorate, = please see

http://www.ietf.org/iesg/directorate/routing.ht= ml

=A0

Although these comments are primarily for the use of= the Routing ADs, it would

be helpful if you could consider them along with any= other comments that you

receive, and strive to resolve them through discussi= on or by updating the draft.

=A0

Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05=

Reviewer: Eric Gray

Review Date: 17 April, 2013

Intended Status: Informational

=A0

There is at least one major issue with this document= , as it is now written.

=A0

Comments/Questions:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= u>

=A0

The "disclaimer" at the end of the Introdu= ction misses a case related to the cases

excluded from the scope of this document =96 which i= s itself presumably out of scope.=A0

=A0

yw>> Assume that you are referring to the disc= laimer at the end of section 1.1 (as opposed to the one at the end of secti= on 1)=A0

=A0

I= did not refer to section 1, I referred to the Introduction.=A0 Since this = was the name of

section 1, I = thought that referring to it by name would be sufficiently unambiguous,<= /u>

since all of = section 1 is the Introduction=85

=A0

=A0

The text currently talks to protection of a path pri= or to entry to the ring, or after

exit from the ring.=A0 The missing case is when the = path is part of a protected service

that involves one or more alternative paths external= to the ring.=A0 It is not difficult

to think of a scenario in which a protection event o= utside of the ring will require

that data forwarded across the ring will need to ent= er the ring at a different point,

leave the ring at a different point, or both.=

=A0

While this would seem to impact the protection of th= e ring itself (possibly requiring

setup of similar protection for the new path travers= ing the ring), it should be quite

easy to represent such an occurrence as a set of dis= crete event/operations that

would not be significantly different when compared t= o initial setup of protection for

the previous path in the ring.

=A0

If for any reason folks feel that this may not be th= e case under some circumstances

this document should either address those cases or e= xplicitly state that they will not

be addressed by this document.

=A0

Alternatively, the issue may be addressed by simply = removing the 2nd sentence of

the "disclaimer" paragraph, or the cases e= xplicitly stated should be expressed as

"examples."

=A0

yw>> How about if I change the text of the sec= ond sentence to read:=A0 "Protection triggers on the transport path =A0=A0 prior to the ring ingress node or beyond the egress nodes may be pro= tected by some other mechanism."?

=A0

Fine.

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Bullet 4 of section 1.3 is confusing as written.=A0 = The meaning of "LI" is clear enough,

but "LE" presents some problems.=A0 Suppos= e that PHP is used; in this case, there is

no label "expected" at the egress point fr= om the ring (although a label may be

present and will be used by the LSR at that point, t= hat label may not always be the

same label).

=A0

Is PHP never permitted?

=A0

yw>> regarding this, I seem to recall such a d= iscussion regarding MPLS-TP and PHP.=A0 However, in any case=A0if there is = no such label, why couldn't LE=3Dnull? It is just being presented for d= iscussion, not as an actual label.=A0

=A0

Okay.= =A0 Even as an item for discussion, the text seems to imply that one would = always find a label.

With PHP, the= egress LSR can signal that PHP is to e used by using the appropriate NULL = label.

However, this= label never actually shows up on the wire, so the egress LSR does not expe= ct to

see it.

=A0

My concern is= that someone reading this may look to see this as an object to be managed.= =A0 I

suppose that = it could be read as NULL, so that may not be an issue.=

=A0

And any LSR t= hat signals PHP and then expects to see a specific label is a darwin candid= ate.

=A0

So, fine.<= /u>

=A0

=A0

Also, under what circumstances would the ring egress= point SPME exit LSR not

be the same?=A0 Based on subsequent reading, I belie= ve this would be the case for

use of an SPME to provide "Wrapping" prote= ction =96 it would probably therefore

be a good idea to either say something to this effec= t (if that is the case) or provide

a forward reference (to section 2.3.2, 2.3.3 and 2.3= .4, for example, or possibly

just to section 2.3).

=A0

I would suggest adding a sentence to this bullet, al= ong the lines of:

=A0

"See section 2.3 for examples of where the SPME= egress and ring exit might not

be the same."

=A0

yw>> How about if I=A0add ", for example= =A0as described in Section 2.3" to the parenthetical phrase?=

=A0

Fine.

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Section 2 appears to ignore 1+1 protection, which wo= uld (similar to "Steering")

use pre-established protection paths from an ingress= LSR/node to each egress

LSR/node but would send that traffic both ways at al= l times.=A0

=A0

The main differences between this approach and Steer= ing are:

=A0

o=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the need to no= tify the ingress node is eliminated as a consideration for

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 protec= tion switching latency

o=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 there is (ther= efore) no reliance on the existence of a failure detection

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 method= that is able to notify the ingress of a failure in the ring<= /p>

o=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 double bandwid= th is required

=A0

This is carried forward in all subsequent sections/s= ubsections.

=A0

yw>> 1+1 protection is a linear protection met= hodology, and Section 2 is describing basic Transport Network ring protecti= on as defined in =A0the ITU - which include Steering and Wrapping.=A0 1+1 d= oes not seem to be popular in rings, since historically SDH seemed to shun this alternative.=A0We do reference 1+1 transmission in= section 3.2 and in the conclusions.

=A0

Your re= collection of ring protection schemes is probably far fresher than mine.=A0= I distinctly recall

ring protecti= on methodologies that provide hitless protection by always sending traffic = both

ways around t= he ring.=A0 In fact, it is hard for me to imagine how one could get hitless= protection

without this = sort of scheme.

=A0

Because this = requires sending traffic on both the working and protection path, it is 1+1= and it

requires doub= le bandwidth.

=A0

I am not cert= ain that ignoring 1+1 protection in section 2 and lightly glossing it over = in later

sections addr= esses my comment, but =96 if it is too late at this point to fix it =96 the= n I imagine

we will just = have to live with it.

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Sections 2.1 and 2.2 do not exactly provide an "= ;apples-to-apples" comparison

basis in the bullets relating to "consideration= s" in each subsection.=A0 In order to

allow this comparison, both sections would need to p= rovide an indication of the

order of protection paths required in a protection domain.

=A0

Because =96 in the "Wrapping" case =96 it = is necessary to provide protection SPME

for each node and link (in a ring the number of link= s is exactly the same as the

number of nodes), the number of protection SPME is O= (2N).

=A0

For the "Steering" case, however, it is ne= cessary to provide protection SPME

for each ingress node to each egress node (except fo= r the last one) =96 which is

O(N^2).=A0 This statement is actually made in the in= troductory text in section 2.4.

=A0

I would suggest either adding a bullet in section 2.= 2 and including forward

references in these bullets to the analysis in secti= on 2.4, or removing the bullet

in section 2.1.

=A0

yw>> Could you please specify which bullet you= are suggesting to delete? Thanx=A0

=A0

I hope = you worked this out on your own.=A0 The target bullet is both obvious and u= nambiguous,

given the fir= st paragraph of this comment.=A0 I don't even have to look back at the = draft to see

it in context= .

=A0

Ths two secti= on compare aspects of protection schemes.=A0 One apparently includes a stat= ement

about the ord= er of the number of required protection paths, while the other does not.=

=A0

The comment s= uggests either adding the missing information as a bullet in section 2.2, o= r

removing the = corresponding bullet in section 2.1.

=A0

Are you sayin= g that you cannot determine from my comment which bullet that is?=

=A0

=85 now looki= ng at the latest draft =85

=A0

I see (based = on the -06 version) that you did not figure this out.<= /u>

=A0

Look at the b= ullets in section 2.1.=A0 Then look at the bullets in section 2.2.=A0 What = you should see

is that the 2= nd bullet in section 2.2 has no counterpart in section 2.2.

=A0

While this is= true of other bullets as well, the comment I made shows that it is relativ= ely easy

to determine = the (order of the) number of protection paths required to use steering as t= he

protection sc= heme.=A0 For other bullets, I can see why they were omitted.=A0 A bullet th= at talks

about the ord= er of the number of protection paths required for steering is simply not th= ere,

for no good r= eason that I can determine.

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Section 2.3 appears to assume that the desired prote= ction scheme will be based

on "Steering" rather than "Wrapping.&= quot;=A0 This assumption is made without any

effort/analysis to justify why this assumption is ma= de (at least as far as I can see).

=A0

If that is the intention, minimally, section 2.3 sho= uld start with a statement that

this is the assumption made.

=A0

Reading further, however, subsequent subsection 2.3.= 2 describes how the SPME

concept =96 as outlined in the introductory text of = section 2.3 =96 may be used for the

"Wrapping" approach.

=A0

The confusion arises as a result of figure 3 and the= text that describes it in the

preceding paragraph, as this figure/text is what mos= t contributes to an impression

that an SPME would start at the ingress and end at a= n egress.

=A0

I would suggest that this figure and the preceding p= aragraph would find a better

home on section 2.3.1.=A0 This would also align subs= ections of section 2.3 better as

there is a similar figure in section 2.3.2, 2.3.3 an= d 2.3.4.

=A0

yw>> Will move the paragraph and figure, as yo= u suggest.=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

The last paragraph in introductory text in section 2= .3 (immediately prior to the

start of section 2.3.1) appears to ignore the case w= here the egress LSR would

use labels to "steer" delivery of labeled = packets it receives over the SPME to

specific egress ports (of the egress LSR).=A0

=A0

These labels would most likely not be a part of the = label stack received by the

ingress LSR (there is no need for these labels to be= known outside of the ring)

and would have to be pushed onto the stack before pu= shing on the label for an

SPME to the egress LSR/node.

=A0

yw>> Do you have a suggestion on how better to= include this consideration?=A0

=A0

F= or thatI need to re-read the draft.

=A0

=85 now looki= ng at the latest draft =85

=A0

Okay, the las= t paragraph actually ignores a few things:=

1) If the ing= ress and egress LSRs on the ring are adjacent nodes on the ring, no swappin= g occurs.

2) in any cas= e where there are more than 3 LSRs involved in the LSP at the hierarchical = layer of

=A0=A0=A0 the= SPME, there will be N-2 label swaps that ultimately result in the LE label= attached to the

=A0=A0=A0 PDU= arriving at the egress LSR.

3) the point = I was trying to make =96 which was that the ingress LSR may have been given= a label

=A0=A0=A0 sta= ck (which would not be what you refer to as "LI", and would consi= st of more than one label

=A0=A0=A0=A0w= here only the top level label would be seen anywhere in the LSP but at the = ingress, where it

=A0=A0=A0=A0= =A0is pushed on, and the egress LSR).

=A0

In re-looking= at this, it seems to me that you are trying to avoid this level of detail,= so it would

be sufficient= to "qualify" this description by inserting "in the simplest= case" before "packets that

arrive=85&quo= t;

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

I believe the text in the last paragraph of section = 2.3.4 is incorrect in stating that

protected traffic might not share the same protectio= n path in both directions.

=A0

If both LSR-B and LSR-F detect that LSR-A is not ava= ilable, then both will use the

protection SPME between LSR-B and LSR-F.

=A0

If both LSR-A and LSR-E detect that LSR-F is not ava= ilable, then both will use the

protection SPME between LSR-A and LSR-E.

=A0

If both LSR-A and LSR-F detect that the link between= them is not available, then

both will use the protection SPME between them.

=A0

All that is required is that both LSRs in each case = agree as to the nature of the

failure (node or link) =96 which may be easily and c= onsistently determined by

monitoring the status of the working and protection = SPME.

=A0

While it is possible for the end-point LSRs in each = case to have an inconsistent

view of the nature of the failure, this inconsistenc= y should be short lived (based

on the periodicity of OAM monitoring of SPMEs).

=A0

Depending on the OAM monitoring periodicity used =96= and the length of links in

the ring =96 this inconsistency may exist for a peri= od of time that is less than the

latency to be expected for "Steering" base= d protection.

=A0

Note that this is a major issue with the cu= rrent text as it impacts on analysis in

subsequent section 2.4 and the conclusion/r= ecommendations of this document.

=A0

yw>> This statement is the result of review co= mments that we received during an earlier review of the document, and I am = wary of removing it from the document at this late stage in the review proc= ess.=A0 In any case, there are other considerations for limiting both types of protection.=A0 I am sure that your analysis is = correct although I am not sure that I understand your emphatic objection to= the text and how it is related to the analysis in section 2.4.

=A0

The ana= lysis appears to be missing information.=A0 Yet the analysis is presumably = the basis on

which the con= clusions of the draft are based.

=A0

However, if t= he WG feels that the conclusions of this draft are correct, then there may = not

be much point= in addressing this comment.

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

The analysis in section 2.4 is incomplete or based o= n an incorrect assertion made

in section 2.3.4.

=A0

If the alternative suggested in section 2.3.4 were u= sed, the number of SPME that

will be required would be O(4N) =96 which is still O= (N) and would be less than O(N^2)

for fewer than the 16-node limit assumption made for= the analysis.

=A0

yw>> This is correct and is certainly correct = when the comparison is between O(2N) and O(N^2).=A0 Therefore=A0whether the= =A0statement (reiterated in parenthesis here) is correct or not does not re= ally affect the conclusions.=A0 This is based on the simplicity of Steering and the avoidance of wasted resources by transm= itting the traffic twice over certain links.

=A0

Fine=

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st sentence of the last paragraph= in the introductory text of section 2.4,

the sentence mentions the use of additional resource= s but does not mention the

additional latency.

=A0

Is there any reason for the omission?<= /p>

=A0

yw>> not really=A0

=A0

=A0

I suggest removing the text in this sentence that st= arts with "even though" as

it might otherwise be necessary to attempt an exhaus= tive list of detractions.

=A0

yw>> I have no problem with this suggestion=A0=

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Also in the last paragraph of the introductory text = in section 2.4, I imagine that

the case where one or more pairs of SPME may be elim= inated because of LSRs

that are not ingress-egress pairs is most likely of = trivial value in any deployment

involving a ring topology.=A0

=A0

Perhaps the last sentence in the last paragraph of t= his text in section 2.4 could be

removed?

=A0

yw>> Again, I have no problem with this=A0<= /u>

=A0

=A0

NITs:

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

=A0

In the Introduction section, 5th bullet i= n (or after) the 2nd paragraph =96

=A0

=A0=A0 " Impact of signaling and routing inform= ation exchanged during

=A0=A0=A0=A0=A0 protection, in presence of control p= lane."

=A0

- the phrase "in presence of control plane"= ; should probably be "in the

presence of a control plane."

=A0

yw>> will fix=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 2nd bullet in section 2.1, I belie= ve it is the case that O(2N) =3D O(N).

=A0

yw>> while this is true, I think it is signifi= cant to mention the=A02N=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st paragraph of section 2.3.1, wh= ere it says "there is always an alternative

path =85" =96 at the SPME level (as described i= n this document), there's always exactly

one=A0 alternative path.=

yw>> This is not 100% true.=A0 What is true=A0= is that there is exactly on alternative path within the ring (there may be = additional alternatives that go outside the ring). This is why I did not or= iginally add the "exactly" in the first place.=A0

=A0

P= aths outside of the ring are explicitly out-of-scope.=A0 However, this is f= ine.

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st bullet in section 2.4, I belie= ve it is the case that O(2N^2) =3D O(N^2).

=A0

yw>> see above, same applies to next statement= .=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st and 2nd bullets in = section 2.4, I believe it is the case that O(2N) =3D O(N).

----------------------------------------------------= ---------------------------------------------------------

=A0

=A0

=A0

=A0




--

Thanx and BR,

yaacov

=A0

Still looking for new opportunity




--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--bcaec548a1b358617e04dd353778-- From eric.gray@ericsson.com Tue May 21 06:53:44 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989C821F9749 for ; Tue, 21 May 2013 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfYZsvGXVJBn for ; Tue, 21 May 2013 06:53:25 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A92721F9698 for ; Tue, 21 May 2013 06:53:25 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-65-519b7c50993a Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F2.E5.17121.05C7B915; Tue, 21 May 2013 15:53:21 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 21 May 2013 09:53:20 -0400 From: Eric Gray To: Yaacov Weingarten Thread-Topic: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 Thread-Index: Ac46I/L2HHXp8Uk5T2ussJve4WIn1ABaH/6ABUenjKABWl0aAAAFeK3w Date: Tue, 21 May 2013 13:53:19 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60AD9E6@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF60AA2DC@eusaamb107.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.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF60AD9E6eusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiG5gzexAg/lN3BZn9tZa7Dxzndli wZqn7BY3LvawOLB47Jx1l91jyZKfTB4/TqZ4fLn8mS2AJYrLJiU1J7MstUjfLoEr4+jx4oIt p9gq2s6cYG1gfPeetYuRk0NCwERi5qOJTBC2mMSFe+vZuhi5OIQEjjJKPLnbywzhLGeUONO/ nA2kik1AQ+LYnbWMXYwcHCICmhIb1tWChJkFTjJKPFjsDGILC4RLNHU/YgGxRQQiJF7/+ssI YbtJ7Ph0DGwxi4CqRM+UL2AjeQW8JbZPOw61eDaTROeaO2AXcQoESuze1c4OYjMCXff91Bom iGXiEreezIe6WkBiyZ7zzBC2qMTLx/+gPlOWWPJkPwtEfb7EkUWrmSGWCUqcnPmEZQKj6Cwk o2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtjECIy+YxJs ujsY97y0PMQozcGiJM7bqj01UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjdLMdkvvcS5hP nP/7L3mv5vuNAYkv/tfplv5dkCpz5dryq+Urt/zXzny906ts2euuhW8NLMv8j7dOPWIodc7s xPepfqZyHz6Hrfxp8uv2S64JEbe/r/KN+7H4dnTGRGu+o49unhT3SBLYrO/bffG++i+VGqdn Aet/fJ5m3ZdutlHv8tPJAoavXiuxFGckGmoxFxUnAgCM6+WTjAIAAA== Cc: "rtg-dir@ietf.org" , "rtg-ads@tools-ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:53:45 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF60AD9E6eusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This discussion is also addressed to the Ads. If they feel that further changes may be required, you should hear from the= m. If they do not, that is fine with me... From: Yaacov Weingarten [mailto:wyaacov@gmail.com] Sent: Tuesday, May 21, 2013 3:16 AM To: Eric Gray Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tools-ietf.o= rg; rtg-dir@ietf.org Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-pro= tection-05 Importance: High Eric, hi I guess I am happy to say that this is out of my hands now as the document = has been approved by the IESG. Unless you think that these issues are criti= cal, I do not think that I can address them without approval from the ADs. If you know of a different process, I am willing to be enlightened! Thanx anyway, yaacov On Tue, May 14, 2013 at 7:24 PM, Eric Gray > wrote: Yaacov, I didn't see this response until I specifically went lookin= g for it. Sorry to have taken so long to get back to you. For the most part, your counter proposal is good enough. S= ee my replies in line below... Thanks for addressing most of my comments. -- Eric From: Yaacov Weingarten [mailto:wyaacov@gmail.com= ] Sent: Wednesday, April 17, 2013 8:56 AM To: Eric Gray Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tools-ietf.org; rtg-dir@ietf.org Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-pro= tection-05 Importance: High Eric, hi Thank you for your review and very in-depth comments, I will try to address= some of them inline below (indicated by "yw>>" before the comment. Hope this helps, yaacov On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray > wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on speci= al request. The purpose of the review is to provide assistance to the Routing= ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other comments that yo= u receive, and strive to resolve them through discussion or by updating the d= raft. Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05 Reviewer: Eric Gray Review Date: 17 April, 2013 Intended Status: Informational There is at least one major issue with this document, as it is now written. Comments/Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The "disclaimer" at the end of the Introduction misses a case related to th= e cases excluded from the scope of this document - which is itself presumably out o= f scope. yw>> Assume that you are referring to the disclaimer at the end of section = 1.1 (as opposed to the one at the end of section 1) I did not refer to section 1, I referred to the Introduction. Since this w= as the name of section 1, I thought that referring to it by name would be sufficiently una= mbiguous, since all of section 1 is the Introduction... The text currently talks to protection of a path prior to entry to the ring= , or after exit from the ring. The missing case is when the path is part of a protect= ed service that involves one or more alternative paths external to the ring. It is no= t difficult to think of a scenario in which a protection event outside of the ring will= require that data forwarded across the ring will need to enter the ring at a differ= ent point, leave the ring at a different point, or both. While this would seem to impact the protection of the ring itself (possibly= requiring setup of similar protection for the new path traversing the ring), it shoul= d be quite easy to represent such an occurrence as a set of discrete event/operations = that would not be significantly different when compared to initial setup of prot= ection for the previous path in the ring. If for any reason folks feel that this may not be the case under some circu= mstances this document should either address those cases or explicitly state that th= ey will not be addressed by this document. Alternatively, the issue may be addressed by simply removing the 2nd senten= ce of the "disclaimer" paragraph, or the cases explicitly stated should be expres= sed as "examples." yw>> How about if I change the text of the second sentence to read: "Prote= ction triggers on the transport path prior to the ring ingress node or beyond the egress nodes may be protect= ed by some other mechanism."? Fine. ---------------------------------------------------------------------------= ---------------------------------- Bullet 4 of section 1.3 is confusing as written. The meaning of "LI" is cl= ear enough, but "LE" presents some problems. Suppose that PHP is used; in this case, t= here is no label "expected" at the egress point from the ring (although a label may= be present and will be used by the LSR at that point, that label may not alway= s be the same label). Is PHP never permitted? yw>> regarding this, I seem to recall such a discussion regarding MPLS-TP a= nd PHP. However, in any case if there is no such label, why couldn't LE=3D= null? It is just being presented for discussion, not as an actual label. Okay. Even as an item for discussion, the text seems to imply that one wou= ld always find a label. With PHP, the egress LSR can signal that PHP is to e used by using the appr= opriate NULL label. However, this label never actually shows up on the wire, so the egress LSR = does not expect to see it. My concern is that someone reading this may look to see this as an object t= o be managed. I suppose that it could be read as NULL, so that may not be an issue. And any LSR that signals PHP and then expects to see a specific label is a = darwin candidate. So, fine. Also, under what circumstances would the ring egress point SPME exit LSR no= t be the same? Based on subsequent reading, I believe this would be the case= for use of an SPME to provide "Wrapping" protection - it would probably therefo= re be a good idea to either say something to this effect (if that is the case)= or provide a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or pos= sibly just to section 2.3). I would suggest adding a sentence to this bullet, along the lines of: "See section 2.3 for examples of where the SPME egress and ring exit might = not be the same." yw>> How about if I add ", for example as described in Section 2.3" to the = parenthetical phrase? Fine. ---------------------------------------------------------------------------= ---------------------------------- Section 2 appears to ignore 1+1 protection, which would (similar to "Steeri= ng") use pre-established protection paths from an ingress LSR/node to each egres= s LSR/node but would send that traffic both ways at all times. The main differences between this approach and Steering are: o the need to notify the ingress node is eliminated as a consid= eration for protection switching latency o there is (therefore) no reliance on the existence of a failur= e detection method that is able to notify the ingress of a failure in t= he ring o double bandwidth is required This is carried forward in all subsequent sections/subsections. yw>> 1+1 protection is a linear protection methodology, and Section 2 is de= scribing basic Transport Network ring protection as defined in the ITU - w= hich include Steering and Wrapping. 1+1 does not seem to be popular in rin= gs, since historically SDH seemed to shun this alternative. We do reference= 1+1 transmission in section 3.2 and in the conclusions. Your recollection of ring protection schemes is probably far fresher than m= ine. I distinctly recall ring protection methodologies that provide hitless protection by always sen= ding traffic both ways around the ring. In fact, it is hard for me to imagine how one could = get hitless protection without this sort of scheme. Because this requires sending traffic on both the working and protection pa= th, it is 1+1 and it requires double bandwidth. I am not certain that ignoring 1+1 protection in section 2 and lightly glos= sing it over in later sections addresses my comment, but - if it is too late at this point to fix= it - then I imagine we will just have to live with it. ---------------------------------------------------------------------------= ---------------------------------- Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" compariso= n basis in the bullets relating to "considerations" in each subsection. In o= rder to allow this comparison, both sections would need to provide an indication of= the order of protection paths required in a protection domain. Because - in the "Wrapping" case - it is necessary to provide protection SP= ME for each node and link (in a ring the number of links is exactly the same a= s the number of nodes), the number of protection SPME is O(2N). For the "Steering" case, however, it is necessary to provide protection SPM= E for each ingress node to each egress node (except for the last one) - which= is O(N^2). This statement is actually made in the introductory text in sectio= n 2.4. I would suggest either adding a bullet in section 2.2 and including forward references in these bullets to the analysis in section 2.4, or removing the= bullet in section 2.1. yw>> Could you please specify which bullet you are suggesting to delete? Th= anx I hope you worked this out on your own. The target bullet is both obvious = and unambiguous, given the first paragraph of this comment. I don't even have to look back = at the draft to see it in context. Ths two section compare aspects of protection schemes. One apparently incl= udes a statement about the order of the number of required protection paths, while the other= does not. The comment suggests either adding the missing information as a bullet in s= ection 2.2, or removing the corresponding bullet in section 2.1. Are you saying that you cannot determine from my comment which bullet that = is? ... now looking at the latest draft ... I see (based on the -06 version) that you did not figure this out. Look at the bullets in section 2.1. Then look at the bullets in section 2.= 2. What you should see is that the 2nd bullet in section 2.2 has no counterpart in section 2.2. While this is true of other bullets as well, the comment I made shows that = it is relatively easy to determine the (order of the) number of protection paths required to use = steering as the protection scheme. For other bullets, I can see why they were omitted. A = bullet that talks about the order of the number of protection paths required for steering is = simply not there, for no good reason that I can determine. ---------------------------------------------------------------------------= ---------------------------------- Section 2.3 appears to assume that the desired protection scheme will be ba= sed on "Steering" rather than "Wrapping." This assumption is made without any effort/analysis to justify why this assumption is made (at least as far as = I can see). If that is the intention, minimally, section 2.3 should start with a statem= ent that this is the assumption made. Reading further, however, subsequent subsection 2.3.2 describes how the SPM= E concept - as outlined in the introductory text of section 2.3 - may be used= for the "Wrapping" approach. The confusion arises as a result of figure 3 and the text that describes it= in the preceding paragraph, as this figure/text is what most contributes to an imp= ression that an SPME would start at the ingress and end at an egress. I would suggest that this figure and the preceding paragraph would find a b= etter home on section 2.3.1. This would also align subsections of section 2.3 be= tter as there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4. yw>> Will move the paragraph and figure, as you suggest. ---------------------------------------------------------------------------= ---------------------------------- The last paragraph in introductory text in section 2.3 (immediately prior t= o the start of section 2.3.1) appears to ignore the case where the egress LSR wou= ld use labels to "steer" delivery of labeled packets it receives over the SPME= to specific egress ports (of the egress LSR). These labels would most likely not be a part of the label stack received by= the ingress LSR (there is no need for these labels to be known outside of the r= ing) and would have to be pushed onto the stack before pushing on the label for = an SPME to the egress LSR/node. yw>> Do you have a suggestion on how better to include this consideration? For thatI need to re-read the draft. ... now looking at the latest draft ... Okay, the last paragraph actually ignores a few things: 1) If the ingress and egress LSRs on the ring are adjacent nodes on the rin= g, no swapping occurs. 2) in any case where there are more than 3 LSRs involved in the LSP at the = hierarchical layer of the SPME, there will be N-2 label swaps that ultimately result in the L= E label attached to the PDU arriving at the egress LSR. 3) the point I was trying to make - which was that the ingress LSR may have= been given a label stack (which would not be what you refer to as "LI", and would consist = of more than one label where only the top level label would be seen anywhere in the LSP but at= the ingress, where it is pushed on, and the egress LSR). In re-looking at this, it seems to me that you are trying to avoid this lev= el of detail, so it would be sufficient to "qualify" this description by inserting "in the simplest c= ase" before "packets that arrive..." ---------------------------------------------------------------------------= ---------------------------------- I believe the text in the last paragraph of section 2.3.4 is incorrect in s= tating that protected traffic might not share the same protection path in both directio= ns. If both LSR-B and LSR-F detect that LSR-A is not available, then both will = use the protection SPME between LSR-B and LSR-F. If both LSR-A and LSR-E detect that LSR-F is not available, then both will = use the protection SPME between LSR-A and LSR-E. If both LSR-A and LSR-F detect that the link between them is not available,= then both will use the protection SPME between them. All that is required is that both LSRs in each case agree as to the nature = of the failure (node or link) - which may be easily and consistently determined by monitoring the status of the working and protection SPME. While it is possible for the end-point LSRs in each case to have an inconsi= stent view of the nature of the failure, this inconsistency should be short lived= (based on the periodicity of OAM monitoring of SPMEs). Depending on the OAM monitoring periodicity used - and the length of links = in the ring - this inconsistency may exist for a period of time that is less t= han the latency to be expected for "Steering" based protection. Note that this is a major issue with the current text as it impacts on anal= ysis in subsequent section 2.4 and the conclusion/recommendations of this document. yw>> This statement is the result of review comments that we received durin= g an earlier review of the document, and I am wary of removing it from the = document at this late stage in the review process. In any case, there are = other considerations for limiting both types of protection. I am sure that= your analysis is correct although I am not sure that I understand your emp= hatic objection to the text and how it is related to the analysis in sectio= n 2.4. The analysis appears to be missing information. Yet the analysis is presum= ably the basis on which the conclusions of the draft are based. However, if the WG feels that the conclusions of this draft are correct, th= en there may not be much point in addressing this comment. ---------------------------------------------------------------------------= ---------------------------------- The analysis in section 2.4 is incomplete or based on an incorrect assertio= n made in section 2.3.4. If the alternative suggested in section 2.3.4 were used, the number of SPME= that will be required would be O(4N) - which is still O(N) and would be less tha= n O(N^2) for fewer than the 16-node limit assumption made for the analysis. yw>> This is correct and is certainly correct when the comparison is betwee= n O(2N) and O(N^2). Therefore whether the statement (reiterated in parenth= esis here) is correct or not does not really affect the conclusions. This = is based on the simplicity of Steering and the avoidance of wasted resource= s by transmitting the traffic twice over certain links. Fine ---------------------------------------------------------------------------= ---------------------------------- In the 1st sentence of the last paragraph in the introductory text of secti= on 2.4, the sentence mentions the use of additional resources but does not mention = the additional latency. Is there any reason for the omission? yw>> not really I suggest removing the text in this sentence that starts with "even though"= as it might otherwise be necessary to attempt an exhaustive list of detraction= s. yw>> I have no problem with this suggestion ---------------------------------------------------------------------------= ---------------------------------- Also in the last paragraph of the introductory text in section 2.4, I imagi= ne that the case where one or more pairs of SPME may be eliminated because of LSRs that are not ingress-egress pairs is most likely of trivial value in any de= ployment involving a ring topology. Perhaps the last sentence in the last paragraph of this text in section 2.4= could be removed? yw>> Again, I have no problem with this NITs: =3D=3D=3D=3D In the Introduction section, 5th bullet in (or after) the 2nd paragraph - " Impact of signaling and routing information exchanged during protection, in presence of control plane." - the phrase "in presence of control plane" should probably be "in the presence of a control plane." yw>> will fix ---------------------------------------------------------------------------= ---------------------------------- In the 2nd bullet in section 2.1, I believe it is the case that O(2N) =3D O= (N). yw>> while this is true, I think it is significant to mention the 2N ---------------------------------------------------------------------------= ---------------------------------- In the 1st paragraph of section 2.3.1, where it says "there is always an al= ternative path ..." - at the SPME level (as described in this document), there's alwa= ys exactly one alternative path. yw>> This is not 100% true. What is true is that there is exactly on alter= native path within the ring (there may be additional alternatives that go o= utside the ring). This is why I did not originally add the "exactly" in the= first place. Paths outside of the ring are explicitly out-of-scope. However, this is fi= ne. ---------------------------------------------------------------------------= ---------------------------------- In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) =3D= O(N^2). yw>> see above, same applies to next statement. ---------------------------------------------------------------------------= ---------------------------------- In the 1st and 2nd bullets in section 2.4, I believe it is the case that O(= 2N) =3D O(N). ---------------------------------------------------------------------------= ---------------------------------- -- Thanx and BR, yaacov Still looking for new opportunity -- Thanx and BR, yaacov Still looking for new opportunity --_000_48E1A67CB9CA044EADFEAB87D814BFF60AD9E6eusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This discussion is also a= ddressed to the Ads.

 <= /p>

If they feel that further= changes may be required, you should hear from them.

 <= /p>

If they do not, that is f= ine with me…

 <= /p>

From: Yaacov W= eingarten [mailto:wyaacov@gmail.com]
Sent: Tuesday, May 21, 2013 3:16 AM
To: Eric Gray
Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tools= -ietf.org; rtg-dir@ietf.org
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-r= ing-protection-05
Importance: High

 

Eric, hi

 

I guess I am happy to say that this is out of my han= ds now as the document has been approved by the IESG. Unless you think that= these issues are critical, I do not think that I can address them without = approval from the ADs.

 

If you know of a different process, I am willing to = be enlightened!

 

Thanx anyway,

yaacov

 

On Tue, May 14, 2013 at 7:24 PM, Eric Gray <eric.gray@ericsson.c= om> wrote:

Yaacov,

 

      &nb= sp;         I didn't see this respo= nse until I specifically went looking for it.

 

      &nb= sp;         Sorry to have taken so = long to get back to you.

 

      &nb= sp;         For the most part, your= counter proposal is good enough.  See my

replies in line below…<= /i>

 

      &nb= sp;         Thanks for addressing m= ost of my comments.

 

--

Eric

 

From: Yaacov Weingarten [mai= lto:wyaacov@gmail.co= m]
Sent: Wednesday, April 17, 2013 8:56 AM
To: Eric Gray
Cc: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; rtg-ads@tools-ietf.org; rtg-dir@ietf.org
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-r= ing-protection-05
Importance: High

 

Eric, hi

 

Thank you for your review and very in-depth comments, I will try t= o address some of them inline below (indicated by "yw>>" be= fore the comment.

 

Hope this helps,

yaacov

On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray <eric.gray@ericsson.com> wro= te:

Hello,

 

I have been selected as the Routing Directorate reviewer for this = draft.

 

The Routing Directorate seeks to review all routing or routing-rel= ated drafts

as they pass through IETF last call and IESG review, and sometimes= on special

request. The purpose of the review is to provide assistance to &nb= sp;the Routing ADs.

 

For more information about the Routing Directorate, please see

http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are primarily for the use of the Routing A= Ds, it would

be helpful if you could consider them along with any other comment= s that you

receive, and strive to resolve them through discussion or by updat= ing the draft.

 

Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05

Reviewer: Eric Gray

Review Date: 17 April, 2013

Intended Status: Informational

 

There is at least one major issue with this document, as it is now= written.

 

Comments/Questions:

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

 

The "disclaimer" at the end of the Introduction misses a= case related to the cases

excluded from the scope of this document – which is itself p= resumably out of scope. 

 

yw>> Assume that you are referring to the disclaimer at the = end of section 1.1 (as opposed to the one at the end of section 1) 

 

I did not refer to section 1, = I referred to the Introduction.  Since this was the name of=

section 1, I thought that refe= rring to it by name would be sufficiently unambiguous,

since all of section 1 is the = Introduction…

 

 

The text currently talks to protection of a path prior to entry to= the ring, or after

exit from the ring.  The missing case is when the path is par= t of a protected service

that involves one or more alternative paths external to the ring.&= nbsp; It is not difficult

to think of a scenario in which a protection event outside of the = ring will require

that data forwarded across the ring will need to enter the ring at= a different point,

leave the ring at a different point, or both.

 

While this would seem to impact the protection of the ring itself = (possibly requiring

setup of similar protection for the new path traversing the ring),= it should be quite

easy to represent such an occurrence as a set of discrete event/op= erations that

would not be significantly different when compared to initial setu= p of protection for

the previous path in the ring.

 

If for any reason folks feel that this may not be the case under s= ome circumstances

this document should either address those cases or explicitly stat= e that they will not

be addressed by this document.

 

Alternatively, the issue may be addressed by simply removing the 2= nd sentence of

the "disclaimer" paragraph, or the cases explicitly stat= ed should be expressed as

"examples."

 

yw>> How about if I change the text of the second sentence t= o read:  "Protection triggers on the transport path
   prior to the ring ingress node or beyond the egress nodes may = be protected by some other mechanism."?

 

Fine.<= /o:p>

 

------------------------------------------------------------------= -------------------------------------------

 

Bullet 4 of section 1.3 is confusing as written.  The meaning= of "LI" is clear enough,

but "LE" presents some problems.  Suppose that PHP = is used; in this case, there is

no label "expected" at the egress point from the ring (a= lthough a label may be

present and will be used by the LSR at that point, that label may = not always be the

same label).

 

Is PHP never permitted?

 

yw>> regarding this, I seem to recall such a discussion rega= rding MPLS-TP and PHP.  However, in any case if there is no such = label, why couldn't LE=3Dnull? It is just being presented for discussion, not as an actual label. 

 

Okay.  Even as an item fo= r discussion, the text seems to imply that one would always find a label.

With PHP, the egress LSR can s= ignal that PHP is to e used by using the appropriate NULL label.

However, this label never actu= ally shows up on the wire, so the egress LSR does not expect to

see it.

 <= /p>

My concern is that someone rea= ding this may look to see this as an object to be managed.  I

suppose that it could be read = as NULL, so that may not be an issue.

 <= /p>

And any LSR that signals PHP a= nd then expects to see a specific label is a darwin candidate.

 <= /p>

So, fine.

 

 

Also, under what circumstances would the ring egress point SPME ex= it LSR not

be the same?  Based on subsequent reading, I believe this wou= ld be the case for

use of an SPME to provide "Wrapping" protection – = it would probably therefore

be a good idea to either say something to this effect (if that is = the case) or provide

a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for exampl= e, or possibly

just to section 2.3).

 

I would suggest adding a sentence to this bullet, along the lines = of:

 

"See section 2.3 for examples of where the SPME egress and ri= ng exit might not

be the same."

 

yw>> How about if I add ", for example as des= cribed in Section 2.3" to the parenthetical phrase?

 

Fine.<= /o:p>

 

------------------------------------------------------------------= -------------------------------------------

 

Section 2 appears to ignore 1+1 protection, which would (simil= ar to "Steering")

use pre-established protection paths from an ingress LSR/node to e= ach egress

LSR/node but would send that traffic both ways at all times. 

 

The main differences between this approach and Steering are:<= /o:p>

 

o           = ;  the need to notify the ingress node is eliminated as a consideratio= n for

           =      protection switching latency

o           = ;  there is (therefore) no reliance on the existence of a failure dete= ction

           =      method that is able to notify the ingress of a fai= lure in the ring

o           = ;  double bandwidth is required

 

This is carried forward in all subsequent sections/subsections.

 

yw>> 1+1 protection is a linear protection methodology, = and Section 2 is describing basic Transport Network ring protection as defi= ned in  the ITU - which include Steering and Wrapping.  1+1 does not seem to be popular in rings, since historically SDH seeme= d to shun this alternative. We do reference 1+1 transmission in se= ction 3.2 and in the conclusions.

 

Your recollection of ring prot= ection schemes is probably far fresher than mine.  I distinctly recall

ring protection methodologies = that provide hitless protection by always sending traffic both

ways around the ring.  In= fact, it is hard for me to imagine how one could get hitless protection

without this sort of scheme.

 <= /p>

Because this requires sending = traffic on both the working and protection path, it is 1+1 and it

requires double bandwidth.

 <= /p>

I am not certain that ignoring= 1+1 protection in section 2 and lightly glossing it over in later

sections addresses my comment,= but – if it is too late at this point to fix it – then I imagine

we will just have to live with= it.

 

------------------------------------------------------------------= -------------------------------------------

 

Sections 2.1 and 2.2 do not exactly provide an "apples-to-app= les" comparison

basis in the bullets relating to "considerations" in eac= h subsection.  In order to

allow this comparison, both sections would need to provide an indi= cation of the

order of protection paths required in a protection domain.

 

Because – in the "Wrapping" case – it is nec= essary to provide protection SPME

for each node and link (in a ring the number of links is exactly t= he same as the

number of nodes), the number of protection SPME is O(2N).

 

For the "Steering" case, however, it is necessary to pro= vide protection SPME

for each ingress node to each egress node (except for the last one= ) – which is

O(N^2).  This statement is actually made in the introductory = text in section 2.4.

 

I would suggest either adding a bullet in section 2.2 and includin= g forward

references in these bullets to the analysis in section 2.4, or rem= oving the bullet

in section 2.1.

 

yw>> Could you please specify which bullet you are suggestin= g to delete? Thanx 

 

I hope you worked this out on = your own.  The target bullet is both obvious and unambiguous,

given the first paragraph of t= his comment.  I don't even have to look back at the draft to see

it in context.<= /b>

 <= /p>

Ths two section compare aspect= s of protection schemes.  One apparently includes a statement

about the order of the number = of required protection paths, while the other does not.<= o:p>

 <= /p>

The comment suggests either ad= ding the missing information as a bullet in section 2.2, or

removing the corresponding bul= let in section 2.1.

 <= /p>

Are you saying that you cannot= determine from my comment which bullet that is?

 <= /p>

… now looking at the lat= est draft …

 <= /p>

I see (based on the -06 versio= n) that you did not figure this out.

 <= /p>

Look at the bullets in section= 2.1.  Then look at the bullets in section 2.2.  What you should see

is that the 2nd bul= let in section 2.2 has no counterpart in section 2.2.

 <= /p>

While this is true of other bu= llets as well, the comment I made shows that it is relatively easy

to determine the (order of the= ) number of protection paths required to use steering as the=

protection scheme.  For o= ther bullets, I can see why they were omitted.  A bullet that talks

about the order of the number = of protection paths required for steering is simply not there,

for no good reason that I can = determine.

 

------------------------------------------------------------------= -------------------------------------------

 

Section 2.3 appears to assume that the desired protection scheme w= ill be based

on "Steering" rather than "Wrapping."  Th= is assumption is made without any

effort/analysis to justify why this assumption is made (at least a= s far as I can see).

 

If that is the intention, minimally, section 2.3 should start with= a statement that

this is the assumption made.

 

Reading further, however, subsequent subsection 2.3.2 describes ho= w the SPME

concept – as outlined in the introductory text of section 2.= 3 – may be used for the

"Wrapping" approach.

 

The confusion arises as a result of figure 3 and the text that des= cribes it in the

preceding paragraph, as this figure/text is what most contributes = to an impression

that an SPME would start at the ingress and end at an egress.=

 

I would suggest that this figure and the preceding paragraph would= find a better

home on section 2.3.1.  This would also align subsections of = section 2.3 better as

there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4.<= /o:p>

 

yw>> Will move the paragraph and figure, as you suggest.&nbs= p;

 

------------------------------------------------------------------= -------------------------------------------

 

The last paragraph in introductory text in section 2.3 (immediatel= y prior to the

start of section 2.3.1) appears to ignore the case where the egres= s LSR would

use labels to "steer" delivery of labeled packets it rec= eives over the SPME to

specific egress ports (of the egress LSR). 

 

These labels would most likely not be a part of the label stack re= ceived by the

ingress LSR (there is no need for these labels to be known outside= of the ring)

and would have to be pushed onto the stack before pushing on the l= abel for an

SPME to the egress LSR/node.

 

yw>> Do you have a suggestion on how better to include this = consideration? 

 

For thatI need to re-read the = draft.

 <= /p>

… now looking at the lat= est draft …

 <= /p>

Okay, the last paragraph actua= lly ignores a few things:

1) If the ingress and egress L= SRs on the ring are adjacent nodes on the ring, no swapping occurs.

2) in any case where there are= more than 3 LSRs involved in the LSP at the hierarchical layer of

    the SPME, t= here will be N-2 label swaps that ultimately result in the LE label attache= d to the

    PDU arrivin= g at the egress LSR.

3) the point I was trying to m= ake – which was that the ingress LSR may have been given a label

    stack (whic= h would not be what you refer to as "LI", and would consist of mo= re than one label

    where = only the top level label would be seen anywhere in the LSP but at the ingre= ss, where it

     = is pushed on, and the egress LSR).

 <= /p>

In re-looking at this, it seem= s to me that you are trying to avoid this level of detail, so it would

be sufficient to "qualify= " this description by inserting "in the simplest case" befor= e "packets that

arrive…"=

 <= /p>

------------------------------------------------------------------= -------------------------------------------

 

I believe the text in the last paragraph of section 2.3.4 is incor= rect in stating that

protected traffic might not share the same protection path in both= directions.

 

If both LSR-B and LSR-F detect that LSR-A is not available, then b= oth will use the

protection SPME between LSR-B and LSR-F.

 

If both LSR-A and LSR-E detect that LSR-F is not available, then b= oth will use the

protection SPME between LSR-A and LSR-E.

 

If both LSR-A and LSR-F detect that the link between them is not a= vailable, then

both will use the protection SPME between them.

 

All that is required is that both LSRs in each case agree as to th= e nature of the

failure (node or link) – which may be easily and consistentl= y determined by

monitoring the status of the working and protection SPME.

 

While it is possible for the end-point LSRs in each case to have a= n inconsistent

view of the nature of the failure, this inconsistency should be sh= ort lived (based

on the periodicity of OAM monitoring of SPMEs).

 

Depending on the OAM monitoring periodicity used – and the l= ength of links in

the ring – this inconsistency may exist for a period of time= that is less than the

latency to be expected for "Steering" based protection.<= o:p>

 

Note that this is a major issue with the current text as = it impacts on analysis in

subsequent section 2.4 and the conclusion/recommendations= of this document.

 

yw>> This statement is the result of review comments that we= received during an earlier review of the document, and I am wary of removi= ng it from the document at this late stage in the review process.  In any case, there are other considerations f= or limiting both types of protection.  I am sure that your analysis is= correct although I am not sure that I understand your emphatic objection t= o the text and how it is related to the analysis in section 2.4.

 

The analysis appears to be mis= sing information.  Yet the analysis is presumably the basis on

which the conclusions of the d= raft are based.

 <= /p>

However, if the WG feels that = the conclusions of this draft are correct, then there may not

be much point in addressing th= is comment.

 

------------------------------------------------------------------= -------------------------------------------

 

The analysis in section 2.4 is incomplete or based on an incorrect= assertion made

in section 2.3.4.

 

If the alternative suggested in section 2.3.4 were used, the numbe= r of SPME that

will be required would be O(4N) – which is still O(N) and wo= uld be less than O(N^2)

for fewer than the 16-node limit assumption made for the analysis.

 

yw>> This is correct and is certainly correct when the compa= rison is between O(2N) and O(N^2).  Therefore whether the st= atement (reiterated in parenthesis here) is correct or not does not really affect the conclusions.  This is based on the simplic= ity of Steering and the avoidance of wasted resources by transmitting the t= raffic twice over certain links.

 

Fine

 

------------------------------------------------------------------= -------------------------------------------

 

In the 1st sentence of the last paragraph in the introd= uctory text of section 2.4,

the sentence mentions the use of additional resources but does not= mention the

additional latency.

 

Is there any reason for the omission?

 

yw>> not really 

 

 

I suggest removing the text in this sentence that starts with &quo= t;even though" as

it might otherwise be necessary to attempt an exhaustive list of d= etractions.

 

yw>> I have no problem with this suggestion =

 

------------------------------------------------------------------= -------------------------------------------

 

Also in the last paragraph of the introductory text in section 2.4= , I imagine that

the case where one or more pairs of SPME may be eliminated because= of LSRs

that are not ingress-egress pairs is most likely of trivial value = in any deployment

involving a ring topology. 

 

Perhaps the last sentence in the last paragraph of this text in se= ction 2.4 could be

removed?

 

yw>> Again, I have no problem with this 

 

 

NITs:

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

 

In the Introduction section, 5th bullet in (or after) t= he 2nd paragraph –

 

   " Impact of signaling and routing information ex= changed during

      protection, in presence of control = plane."

 

- the phrase "in presence of control plane" should proba= bly be "in the

presence of a control plane."

 

yw>> will fix 

 

------------------------------------------------------------------= -------------------------------------------

 

In the 2nd bullet in section 2.1, I believe it is the c= ase that O(2N) =3D O(N).

 

yw>> while this is true, I think it is significant to mentio= n the 2N 

 

------------------------------------------------------------------= -------------------------------------------

 

In the 1st paragraph of section 2.3.1, where it says &q= uot;there is always an alternative

path …" – at the SPME level (as described in this= document), there's always exactly

one  alternative path.

yw>> This is not 100% true.  What is true is that = there is exactly on alternative path within the ring (there may be addition= al alternatives that go outside the ring). This is why I did not originally add the "exactly" in the first place. =

 

Paths outside of the ring are = explicitly out-of-scope.  However, this is fine.

------------------------------------------------------------------= -------------------------------------------

 

In the 1st bullet in section 2.4, I believe it is the c= ase that O(2N^2) =3D O(N^2).

 

yw>> see above, same applies to next statement. 

 

------------------------------------------------------------------= -------------------------------------------

 

In the 1st and 2nd bullets in section 2.4, I= believe it is the case that O(2N) =3D O(N).

------------------------------------------------------------------= -------------------------------------------

 

 

 

 




--

Thanx and BR,

yaacov

 

Still looking for new opportunity




--

Thanx and BR,

yaacov

 

Still looking for new opportunity<= /p>

--_000_48E1A67CB9CA044EADFEAB87D814BFF60AD9E6eusaamb107ericsso_-- From hartmans@painless-security.com Tue May 21 05:28:08 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437ED21F96FB for ; Tue, 21 May 2013 05:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd1buwGdNnvn for ; Tue, 21 May 2013 05:27:55 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 594D221F96B6 for ; Tue, 21 May 2013 05:27:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 251D52060A; Tue, 21 May 2013 08:24:57 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtRYK-wtxtda; Tue, 21 May 2013 08:24:56 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 08:24:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6E9BE440B; Tue, 21 May 2013 08:27:51 -0400 (EDT) From: Sam Hartman To: References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> Date: Tue, 21 May 2013 08:27:51 -0400 In-Reply-To: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> (Adrian Farrel's message of "Sun, 12 May 2013 21:13:54 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 May 2013 07:34:11 -0700 Cc: rtg-dir@ietf.org, 'Danny McPherson' , draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 12:28:08 -0000 Danny, it sounds like you care a lot more about the time sync issue than people who have discussed in in the WG. Would you be willing to write some text discussing NTP and providing a way forward on your concern here? I will need to discuss several issues you raise with the WG. In addition, I'll want to address many of the specific comments you raise. However there are a couple points raised that I can respond to now. So I'll do that and get that discussion started. With regard to the generic comments. i don't believe expanding the scope to cover SIDR, or public-keys would be within the scope of KARP or of the tharter item leading to this document. I think it would be a fairly bad idea. I think the WG has consensus on the current scope and so I believe item 1 would not be appropriate here. Similarly, I think expanding the scope as suggested by 6 after IETF last call is inappropriate. With regard ti item 7: yes most routing protocols use small integers to identify keys over the wire. The only protocols contemplated that use names come from outside the IETF; you'll need to talk to Russ and Tim about how that works. However, the administrative key name--the name that the operator uses--is not restricted and can be whatever the operator likes. From danny@tcb.net Tue May 21 08:37:26 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF821F854D for ; Tue, 21 May 2013 08:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm1aLTFea0mF for ; Tue, 21 May 2013 08:37:21 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDEB21F8693 for ; Tue, 21 May 2013 08:37:21 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id B75AD300039 for ; Tue, 21 May 2013 15:37:20 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id 8A027300021; Tue, 21 May 2013 09:37:19 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 09:37:19 -0600 From: Danny McPherson To: Sam Hartman In-Reply-To: References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> Message-ID: <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue May 21 09:37:20 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 519b94b042077801820872 X-DSPAM-Factors: 27, within+#+#+of, 0.40000, not+#+#+#+you, 0.40000, current+#+and, 0.40000, works+#+#+have, 0.40000, that+#+#+#+regard, 0.40000, points+#+that, 0.40000, names+come, 0.40000, key+#+#+#+Not, 0.40000, WG+#+addition, 0.40000, not+#+#+dependencies, 0.40000, dump+#+#+#+debug, 0.40000, to+#+#+#+to, 0.40000, to+#+#+#+to, 0.40000, here+The, 0.40000, lot+#+about, 0.40000, raise+Understood, 0.40000, Subject*FW+#+Area, 0.40000, g+if, 0.40000, 2013+#+#+06, 0.40000, something+#+the, 0.40000, and+#+#+#+the, 0.40000, has+#+on, 0.40000, completely+#+#+and, 0.40000, have+#+#+#+the, 0.40000, synchronization+#+#+implementations, 0.40000, or+#+#+missing, 0.40000, that+are, 0.40000 Cc: adrian@olddog.co.uk, rtg-dir@ietf.org, draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:37:26 -0000 On 2013-05-21 06:27, Sam Hartman wrote: > Danny, it sounds like you care a lot more about the time sync issue > than > people who have discussed in in the WG. Would you be willing to write > some text discussing NTP and providing a way forward on your concern > here? The reason I care a lot more is that there's less point in investing in deployment of these capabilities if we're going to be overly loose on timing issues, expiry, etc. I think if I wrote text it would simply state that there needs to be reasonable synchronization and that implementations should not assume some considerable skew (e.g., greater than a few minutes). It's arguably not as bad for p2p sessions but for system wide functions (e.g., LSA, LSP, etc..) it could be more problematic in practice. Highlighting and not marginalizing these dependencies is key. IF you want me to write something up I can, but it's simply could to be a lot more prescriptive than what's there today, with an exclamation point in the deployment considerations section. > I will need to discuss several issues you raise with the WG. > In addition, I'll want to address many of the specific comments you > raise. Understood. > However there are a couple points raised that I can respond to now. > So > I'll do that and get that discussion started. > > With regard to the generic comments. > i don't believe expanding the scope to cover SIDR, or public-keys > would > be within the scope of KARP or of the tharter item leading to this > document. I think it would be a fairly bad idea. As an operator I now have multiple mechanisms to manage that are completely different architectures and terminology, etc. If we want folks to use this there needs to be incentives, more complexity upon completion is not an incentive. Can you explain why it's a bad idea? > I think the WG has consensus on the current scope and so I believe > item > 1 would not be appropriate here. > > Similarly, I think expanding the scope as suggested by 6 after IETF > last > call is inappropriate. Duly noted, however, my concern remains. > With regard ti item 7: yes most routing protocols use small integers > to > identify keys over the wire. > The only protocols contemplated that use names come from outside the > IETF; you'll need to talk to Russ and Tim about how that works. Do you have a reference or pointer to support this? And the point about names was in my router/switch configurations today - that's how they're referenced (your "admin key name" point below). Not binding to this in some manner means it's going to have to be done outside of the specification - or am I missing something? > However, the administrative key name--the name that the operator > uses--is not restricted and can be whatever the operator likes. Right, and that needs to be tied to DB in some manner, no? Or do you see that as purely an implementation issue? E.g., if an operator wanted to dump the db to debug something, they'd need to tie it back to the admin names, no? Thanks Sam, -danny From danny@tcb.net Tue May 21 08:47:21 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09D921F9773 for ; Tue, 21 May 2013 08:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qavI0yFEvZGQ for ; Tue, 21 May 2013 08:47:16 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B921F979D for ; Tue, 21 May 2013 08:47:16 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 9651C300039 for ; Tue, 21 May 2013 15:47:16 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id 40683300015; Tue, 21 May 2013 09:47:16 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 09:47:16 -0600 From: Danny McPherson To: Sam Hartman In-Reply-To: References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue May 21 09:47:16 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 519b970442071533316713 X-DSPAM-Factors: 27, support+automated, 0.40000, yet+and, 0.40000, to+#+#+#+or, 0.40000, that+#+danny, 0.40000, we+missing, 0.40000, Subject*FW+#+Area, 0.40000, example+then, 0.40000, that+are, 0.40000, 09+#+#+Hartman, 0.40000, to+validate, 0.40000, validation+#+#+#+the, 0.40000, e+#+I'm, 0.40000, yet+#+#+impact, 0.40000, example+#+systems, 0.40000, On+#+#+#+09, 0.40000, 39+#+#+#+OK, 0.40000, to+#+#+#+is, 0.40000, upon+#+the, 0.40000, 39+#+Hartman, 0.40000, can+cause, 0.40000, having+large, 0.40000, working+#+#+#+assuming, 0.40000, only+#+they, 0.40000, Subject*Re+FW, 0.40000, this+#+#+validation, 0.40000, message+#+#+#+across, 0.40000, what+#+#+missing, 0.40000 Cc: adrian@olddog.co.uk, rtg-dir@ietf.org, draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:47:21 -0000 On 2013-05-21 09:39, Sam Hartman wrote: > OK. Then let's take a step back. > why is having large skew bad? > The working group has been assuming hours or days of permitted skew > is > OK. > > what are we missing? If we're going to support automated rollover, for example, then systems need to know when to begin/stop using a key to either sign with or for validation. If they're out of synch this can cause validation failure (e.g., I'm signing with something that you think is expired or hasn't become valid yet) and perhaps impact message validation non-deterministically across the network. The only way they know what a remote system is going to validate based upon is the assumption they have the right key(s) that are valid within that timeframe. -danny From hartmans@painless-security.com Tue May 21 08:39:33 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DE521F8A54 for ; Tue, 21 May 2013 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IovpU+t-TMeP for ; Tue, 21 May 2013 08:39:28 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 01E5E21F8693 for ; Tue, 21 May 2013 08:39:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4F46B20608; Tue, 21 May 2013 11:36:30 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXaPkbueNQyV; Tue, 21 May 2013 11:36:30 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 11:36:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5019C440B; Tue, 21 May 2013 11:39:26 -0400 (EDT) From: Sam Hartman To: Danny McPherson References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> Date: Tue, 21 May 2013 11:39:26 -0400 In-Reply-To: <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> (Danny McPherson's message of "Tue, 21 May 2013 09:37:19 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 May 2013 09:05:03 -0700 Cc: adrian@olddog.co.uk, rtg-dir@ietf.org, draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:39:33 -0000 OK. Then let's take a step back. why is having large skew bad? The working group has been assuming hours or days of permitted skew is OK. what are we missing? From hartmans@painless-security.com Tue May 21 08:46:29 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EEC21F9763 for ; Tue, 21 May 2013 08:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF91l2psyXN0 for ; Tue, 21 May 2013 08:46:24 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E766121F9669 for ; Tue, 21 May 2013 08:46:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9B2932060D; Tue, 21 May 2013 11:43:26 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4hllYB4QukG; Tue, 21 May 2013 11:43:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 11:43:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 15C98440B; Tue, 21 May 2013 11:46:22 -0400 (EDT) From: Sam Hartman To: Danny McPherson References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> Date: Tue, 21 May 2013 11:46:22 -0400 In-Reply-To: <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> (Danny McPherson's message of "Tue, 21 May 2013 09:37:19 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 May 2013 09:05:03 -0700 Cc: adrian@olddog.co.uk, rtg-dir@ietf.org, draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:46:29 -0000 Hi. I think I better understand our confusion regarding key names. The draft is wrong:-) There's supposed to be an administrative key name field that is how the operator refers to the key. The local and peer key names are used to construct the wire formats. As an example the base OSPF spec has an integer format for that wire key name. however, the conceptual database in the draft seems to be missing the administrative key name. You're completely right that without that, operators are going to have significant trouble. I'm not sure how that fell through the cracks, but I'll confirm with the WG and fix. Thanks for the catch! From acee.lindem@ericsson.com Tue May 21 09:05:39 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0396521F9265 for ; Tue, 21 May 2013 09:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46s2OVp0xH76 for ; Tue, 21 May 2013 09:05:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16621F8E8F for ; Tue, 21 May 2013 09:05:32 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-09-519b9b4b39f1 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 75.6E.06724.B4B9B915; Tue, 21 May 2013 18:05:31 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 21 May 2013 12:05:30 -0400 From: Acee Lindem To: Danny McPherson Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVjp9XeuZ+klNEUSCtv5VT/HQ3pkQEJ4A Date: Tue, 21 May 2013 16:05:30 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714BB7C@eusaamb101.ericsson.se> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> 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.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <6EFA09000186A144A7C436E4EF8C5467@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonUNd79uxAg9YGc4sfPTeYLV5+fsxs sfPvFBaLmZ4WC9Y8ZXdg9Viy5CeTx4rNKxk9Zn9rZfRoOjaV3ePL5c9sAaxRXDYpqTmZZalF +nYJXBmdzTcYCw5yV8yecoW1gXE2ZxcjB4eEgInEtdVcXYycQKaYxIV769m6GLk4hASOMkrM +3OPEcJZzigx/c8HFpAqNgEdieeP/jGD2CICyhKn/95iBSliFvjLKHHr7kR2kISwQKLE4ZV/ mEA2iAgkSez7GgtRbySxoe0AWC+LgKrEsXMrmEBsXgFvidnb+pkhlh1mkrg8pYkVJMEpYC7x 8OBCRhCbEei876fWgDUwC4hL3HoynwnibAGJJXvOM0PYohIvH/9jhbCVJZY82c8CUa8jsWD3 JzYI21pizfqPjBC2tsSyha+ZIY4QlDg58wnLBEbxWUhWzELSPgtJ+ywk7bOQtC9gZF3FyFFa nFqWm25kuIkRGI/HJNgcdzAu+GR5iFGag0VJnLdbe2qgkEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBsaKC/M+bdvjK7Qzo0y0ljFc7vWZjY3WK+QPb5ghEn7843f/nYf/reY4pHJvcdZ3mdOZ r2KNDZ9++TrBccvqG5t3L70jIDj7j0Okf+PN3t0mB6o89+vsvX74+0r3zyLW3GH6dX9kGOae Kb4QXsQ3Y87mPgcuT59QVmeVqXL1No3upqYFxfb/PvYosRRnJBpqMRcVJwIARcwdcJUCAAA= Cc: Sam Hartman , "" , "" , "" Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:05:39 -0000 Hi Danny,=20 On May 21, 2013, at 11:47 AM, Danny McPherson wrote: > On 2013-05-21 09:39, Sam Hartman wrote: >> OK. Then let's take a step back. >> why is having large skew bad? >> The working group has been assuming hours or days of permitted skew is >> OK. >>=20 >> what are we missing? >=20 > If we're going to support automated rollover, for example, then systems n= eed to know when to begin/stop using a key to either sign with or for valid= ation. If they're out of synch this can cause validation failure (e.g., I'= m signing with something that you think is expired or hasn't become valid y= et) and perhaps impact message validation non-deterministically across the = network. The only way they know what a remote system is going to validate = based upon is the assumption they have the right key(s) that are valid with= in that timeframe. For rollover to be successful, an implementation needs to send or sign with= the most recent key (e.g. latest SendLifetimeStart) and accept all current= keys (i.e., the current time falls between AcceptLifetimeStart and AcceptL= ifetimeEnd). This is what I recommend today with my implementation of OSPF = authentication and key-chains.=20 Although I've never been in the acknowledgements section, I've reviewed thi= s document several times and am responsible for getting the terminology ali= gned with industry standard key-chains.=20 Thanks, Acee >=20 > -danny >=20 From acee.lindem@ericsson.com Tue May 21 09:14:44 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B1521F95D7 for ; Tue, 21 May 2013 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rg94cWlLx2p for ; Tue, 21 May 2013 09:14:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AACF221F94F5 for ; Tue, 21 May 2013 09:14:31 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-4a-519b9d678d42 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C6.BF.17121.76D9B915; Tue, 21 May 2013 18:14:31 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 21 May 2013 12:14:30 -0400 From: Acee Lindem To: Sam Hartman Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) Thread-Index: AQHOVj5FnkpTM+tx2EGis6siFIAf9Q== Date: Tue, 21 May 2013 16:14:29 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714BBC8@eusaamb101.ericsson.se> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> 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.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLrHWzd97uxAg+/LJS1+9Nxgtnj5+TGz xc6/U1gsZnpaLFjzlN2B1WPJkp9MHis2r2T0mP2tldGj6dhUdo8vlz+zBbBGcdmkpOZklqUW 6dslcGV8f3WJseAqR8X054cYGxg/sHUxcnJICJhI/Lk8C8oWk7hwbz2YLSRwlFGi5VdKFyMX kL2cUeL7+RXMIAk2AR2J54/+gdkiAgYS814dYwMpYhb4wChxeOtPJpCEsECuRM+LP2wQRXkS jT/vs0DYehIL+6cA2RwcLAKqEgtmyYOEeQW8Je7cec8IsWwmk8TEBffYQRKcApoSHY8ugc1h BLru+6k1YPOZBcQlbj2ZzwRxtYDEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuEbS3x 5N8FqDnaEssWvmaGOEJQ4uTMJywTGMVnIVkxC0n7LCTts5C0z0LSvoCRdRUjR2lxalluupHB JkZgPB6TYNPdwbjnpeUhRmkOFiVx3lbtqYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGE0l Ljxlt7HZ6u3AJ3eeYdos9xs7a9aGOShoVXYr6ewyXv7lOu+SnrS17edjnOYLvOs6f/tyQ8C7 pTy9D+zVFofkfE5a6ufxydU3dP7PX06aZjP1+n6IbhcxrDy8/qKu+X4O5Y/pfw/VnzDL2/o3 hOd8yfLHf46FxmpcnN62XNukbcdcN4GGv0osxRmJhlrMRcWJADrL/P+VAgAA Cc: "" , "" , "" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:14:44 -0000 Sam,=20 I think is very confusing to have a LocalKeyName, PeerKeyName, and AdminKey= Name. Hell, LocalKeyName and PeerKeyName are already confusing. Could we re= place the key used for wire formats with a single SecurityAssociationID? If= there is any justice in the universe, the local system and peer system wil= l agree.=20 Thanks, Acee=20 On May 21, 2013, at 11:46 AM, Sam Hartman wrote: >=20 > Hi. > I think I better understand our confusion regarding key names. >=20 > The draft is wrong:-) >=20 > There's supposed to be an administrative key name field that is how the > operator refers to the key. The local and peer key names are used to > construct the wire formats. As an example the base OSPF spec has an > integer format for that wire key name. >=20 > however, the conceptual database in the draft seems to be missing the > administrative key name. You're completely right that without that, > operators are going to have significant trouble. >=20 > I'm not sure how that fell through the cracks, but I'll confirm with the > WG and fix. Thanks for the catch! From manav.bhatia@alcatel-lucent.com Tue May 21 09:39:56 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8EA21F9399 for ; Tue, 21 May 2013 09:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHJCl1xdICCf for ; Tue, 21 May 2013 09:39:49 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3893F21F9003 for ; Tue, 21 May 2013 09:39:49 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4LGdkDQ012860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 11:39:48 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4LGdjSE011355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 12:39:45 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 21 May 2013 12:39:45 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 22 May 2013 00:39:42 +0800 From: "Bhatia, Manav (Manav)" To: Danny McPherson , Sam Hartman Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVjkbB2PuMgunukmqOQ/ut1/P/pkP1eMA Date: Tue, 21 May 2013 16:39:42 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> In-Reply-To: <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "adrian@olddog.co.uk" , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:39:56 -0000 Is it not given that NTP will always be running in any decent sized deploym= ent to sync the clocks? How else would admins make sense of the logs/traps = coming from different routers if the time stamps are not synced? Given this= , why would the clock for accepting keys ever drift beyond a few secs/mins? Cheers, Manav > -----Original Message----- > From: rtg-dir-bounces@ietf.org=20 > [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Danny McPherson > Sent: Tuesday, May 21, 2013 9:07 PM > To: Sam Hartman > Cc: adrian@olddog.co.uk; rtg-dir@ietf.org;=20 > draft-ietf-karp-crypto-key-table.all@tools.ietf.org > Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review=20 > for draft-ietf-karp-crypto-key-table >=20 > On 2013-05-21 06:27, Sam Hartman wrote: > > Danny, it sounds like you care a lot more about the time sync issue=20 > > than people who have discussed in in the WG. Would you be=20 > willing to=20 > > write some text discussing NTP and providing a way forward on your=20 > > concern here? >=20 > The reason I care a lot more is that there's less point in=20 > investing in deployment of these capabilities if we're going=20 > to be overly loose on timing issues, expiry, etc. I think if=20 > I wrote text it would simply state that there needs to be=20 > reasonable synchronization and that implementations should=20 > not assume some considerable skew (e.g., greater than a few=20 > minutes). It's arguably not as bad for p2p sessions but for=20 > system wide functions (e.g., LSA, LSP, etc..) it could be=20 > more problematic in practice. Highlighting and not=20 > marginalizing these dependencies is key. IF you want me to=20 > write something up I can, but it's simply could to be a lot=20 > more prescriptive than what's there today, with an=20 > exclamation point in the deployment considerations section. >=20 > > I will need to discuss several issues you raise with the WG. > > In addition, I'll want to address many of the specific comments you=20 > > raise. >=20 > Understood. >=20 > > However there are a couple points raised that I can respond=20 > to now. =20 > > So > > I'll do that and get that discussion started. > > > > With regard to the generic comments. > > i don't believe expanding the scope to cover SIDR, or public-keys=20 > > would be within the scope of KARP or of the tharter item leading to=20 > > this document. I think it would be a fairly bad idea. >=20 > As an operator I now have multiple mechanisms to manage that=20 > are completely different architectures and terminology, etc. =20 > If we want folks to use this there needs to be incentives,=20 > more complexity upon completion is not an incentive. Can you=20 > explain why it's a bad idea? >=20 > > I think the WG has consensus on the current scope and so I believe=20 > > item > > 1 would not be appropriate here. > > > > Similarly, I think expanding the scope as suggested by 6 after IETF=20 > > last call is inappropriate. >=20 > Duly noted, however, my concern remains. >=20 > > With regard ti item 7: yes most routing protocols use small=20 > integers=20 > > to identify keys over the wire. > > The only protocols contemplated that use names come from=20 > outside the=20 > > IETF; you'll need to talk to Russ and Tim about how that works. >=20 > Do you have a reference or pointer to support this? And the=20 > point about names was in my router/switch configurations=20 > today - that's how they're referenced (your "admin key name"=20 > point below). Not binding to this in some manner means it's=20 > going to have to be done outside of the specification - or am=20 > I missing something? >=20 > > However, the administrative key name--the name that the operator=20 > > uses--is not restricted and can be whatever the operator likes. >=20 > Right, and that needs to be tied to DB in some manner, no? =20 > Or do you see that as purely an implementation issue? E.g.,=20 > if an operator wanted to dump the db to debug something,=20 > they'd need to tie it back to the admin names, no? >=20 > Thanks Sam, >=20 > -danny >=20 > = From danny@tcb.net Tue May 21 10:26:43 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DCB21F9861 for ; Tue, 21 May 2013 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWo-u-ynhDCt for ; Tue, 21 May 2013 10:26:38 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6591A21F93E9 for ; Tue, 21 May 2013 10:26:04 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id CF0C8300039 for ; Tue, 21 May 2013 17:25:54 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id EDFA6300015; Tue, 21 May 2013 11:25:53 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 11:25:53 -0600 From: Danny McPherson To: Acee Lindem In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4714BB7C@eusaamb101.ericsson.se> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <94A203EA12AECE4BA92D42DBFFE0AE4714BB7C@eusaamb101.ericsson.se> Message-ID: <2f8152019c54c12a2fc126c35dd53e73@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue May 21 11:25:54 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 519bae2242072093153311 X-DSPAM-Factors: 27, On+#+#+#+10, 0.40000, key+#+#+#+pun, 0.40000, aligned+with, 0.40000, AcceptLifetimeEnd+then, 0.40000, key+#+#+latest, 0.40000, industry+#+#+chains, 0.40000, no+pun, 0.40000, Subject*FW+#+Area, 0.40000, SendLifetimeStart+and, 0.40000, send+or, 0.40000, Ack!+no, 0.40000, and+#+#+is, 0.40000, most+recent, 0.40000, problem+#+we're, 0.40000, Although+#+#+been, 0.40000, document+#+times, 0.40000, recent+#+#+#+latest, 0.40000, networks+#+I've, 0.40000, time+#+between, 0.40000, 10+#+#+#+wrote, 0.40000, with+#+#+#+key, 0.40000, successful+#+implementation, 0.40000, times+and, 0.40000, I+#+#+#+idea, 0.40000, then+they, 0.40000, implementation+#+#+#+or, 0.40000, e+#+#+#+and, 0.40000 Cc: Sam Hartman , draft-ietf-karp-crypto-key-table.all@tools.ietf.org, rtg-dir@ietf.org, adrian@olddog.co.uk Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:26:43 -0000 On 2013-05-21 10:05, Acee Lindem wrote: > For rollover to be successful, an implementation needs to send or > sign with the most recent key (e.g. latest SendLifetimeStart) and > accept all current keys (i.e., the current time falls between > AcceptLifetimeStart and AcceptLifetimeEnd). This is what I recommend > today with my implementation of OSPF authentication and key-chains. So this is precisely my point. If you and I have a different idea of when AcceptLifetimeEnd is and it's so different that you're signing messages with a key that I believe has exceeded AcceptLifetimeEnd then that's a problem. If we're going to use time-based expiry then they ought to be reasonable precise in today's networks. > Although I've never been in the acknowledgements section, I've > reviewed this document several times and am responsible for getting > the terminology aligned with industry standard key-chains. Ack! (no pun there :-) -danny From danny@tcb.net Tue May 21 10:27:37 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99921F93C4 for ; Tue, 21 May 2013 10:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7U3fodCkVn7 for ; Tue, 21 May 2013 10:27:32 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id ACFE421F8CE9 for ; Tue, 21 May 2013 10:27:31 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 74D4D300039 for ; Tue, 21 May 2013 17:27:31 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id E3A10300015; Tue, 21 May 2013 11:27:30 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 11:27:30 -0600 From: Danny McPherson To: "Bhatia, Manav (Manav)" In-Reply-To: <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: " <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk>" <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue May 21 11:27:31 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 519bae8342078158812936 X-DSPAM-Factors: 27, Subject*FW+#+Area, 0.01000, Subject*Area+#+Review, 0.01000, Subject*FW+Routing, 0.01000, Subject*FW+#+#+#+Review, 0.01000, Subject*Directorate+#+for, 0.01000, Subject*Routing+Area, 0.01000, Subject*Area+#+#+for, 0.01000, Cc*adrian+olddog.co.uk, 0.01000, On+#+05, 0.01000, Subject*Routing+#+#+Review, 0.01000, Subject*Routing+#+Directorate, 0.01000, Subject*Directorate+Review, 0.01000, Cc*draft-ietf-karp-crypto-key-table.all+tools.ietf.org, 0.01000, 2013+05, 0.01000, 2013+#+21, 0.01000, From*Danny+#+danny, 0.01000, Subject*Area+Directorate, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Subject*Review+for, 0.01000, From*Danny+McPherson, 0.01000, Cc*rtg-dir+ietf.org, 0.01000, On+2013, 0.01000, Subject*FW+#+#+Directorate, 0.01000, On+#+#+21, 0.01000, From*McPherson+danny, 0.01000, From*Danny McPherson , 0.01000, 05+21, 0.01000 Cc: Sam Hartman , draft-ietf-karp-crypto-key-table.all@tools.ietf.org, rtg-dir@ietf.org, adrian@olddog.co.uk Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:27:37 -0000 On 2013-05-21 10:39, Bhatia, Manav (Manav) wrote: > Is it not given that NTP will always be running in any decent sized > deployment to sync the clocks? How else would admins make sense of > the > logs/traps coming from different routers if the time stamps are not > synced? Given this, why would the clock for accepting keys ever drift > beyond a few secs/mins? Indeed my point... -danny From manav.bhatia@alcatel-lucent.com Tue May 21 10:32:39 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7921F9794 for ; Tue, 21 May 2013 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRvd8lnelQnS for ; Tue, 21 May 2013 10:32:32 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 64C8821F925A for ; Tue, 21 May 2013 10:32:32 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4LHWS0e003283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 12:32:28 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r4LHWRjJ006162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 13:32:27 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 21 May 2013 13:32:27 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 22 May 2013 01:32:24 +0800 From: "Bhatia, Manav (Manav)" To: Danny McPherson Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVjkbB2PuMgunukmqOQ/ut1/P/pkP1eMA//+IfwCAAIZMIA== Date: Tue, 21 May 2013 17:32:23 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: " <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk>" <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Sam Hartman , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "rtg-dir@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:32:39 -0000 In that case associating a life time with the keys should work as long as t= he protocols provide a reasonable window for the key transition. Will it help if text is added which basically says that NTP or some timing = protocol should be running that keeps all clocks pretty much synchronized s= o that all routers have a consistent view of the time. Cheers, Manav > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net]=20 > Sent: Tuesday, May 21, 2013 10:58 PM > To: Bhatia, Manav (Manav) > Cc: Sam Hartman; adrian@olddog.co.uk; rtg-dir@ietf.org;=20 > draft-ietf-karp-crypto-key-table.all@tools.ietf.org > Subject: RE: [RTG-DIR] FW: Routing Area Directorate Review=20 > for draft-ietf-karp-crypto-key-table >=20 > On 2013-05-21 10:39, Bhatia, Manav (Manav) wrote: > > Is it not given that NTP will always be running in any decent sized=20 > > deployment to sync the clocks? How else would admins make=20 > sense of the=20 > > logs/traps coming from different routers if the time stamps are not=20 > > synced? Given this, why would the clock for accepting keys=20 > ever drift=20 > > beyond a few secs/mins? >=20 > Indeed my point... >=20 > -danny >=20 >=20 > = From acee.lindem@ericsson.com Tue May 21 10:43:48 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC5521F9892 for ; Tue, 21 May 2013 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYpUQesNMj7f for ; Tue, 21 May 2013 10:43:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76621F9859 for ; Tue, 21 May 2013 10:43:38 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-61-519bb2492d2b Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.D4.06724.942BB915; Tue, 21 May 2013 19:43:38 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 21 May 2013 13:43:37 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVkh4XeuZ+klNEUSCtv5VT/HQ3pkQKMuAgAADIYA= Date: Tue, 21 May 2013 17:43:37 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> References: " <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk>" <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <278C2A3660CA2D43853C830D16E805CF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHW9dr0+xAg0UHBC1+9Nxgtnj5+TGz xc6/U1gsZnpazLl3j9ViwZqn7A5sHq3P9rJ6LFnyk8ljxeaVjB6zv7UyejQdm8ru8eXyZ7YA tigum5TUnMyy1CJ9uwSujL1n7rMXfOKqmHC3n7WB8QNHFyMnh4SAiUTPq31sELaYxIV764Fs Lg4hgaOMEo9fvGaEcJYzSuz+/o4VpIpNQEfi+aN/zCC2iICtxPPNu1hAipgFZjFJ/LjZClYk LJAocXjlH6YuRg6goiSJfV9jIUwrif8zOEFMFgFVia3HVEGKeQW8JW427WCFWHWOWeL67oMs IAlOgWiJhmtHmUBsRqDjvp9aA2YzC4hL3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJZY82c8C Ua8jsWD3JzYI21ri2I/rrBC2tsSyha+ZIY4QlDg58wnLBEbxWUhWzELSPgtJ+ywk7bOQtC9g ZF3FyFFanFqWm25kuIkRGKHHJNgcdzAu+GR5iFGag0VJnLdbe2qgkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBkbx9lnrKvbqX85Tfm3+9XjAV4mm+JlxTGpPAo8YzBQQj8wUmNQxIVLFW9H0 5+lHLneEGCVjsjLFl53tqjlxvfK0bKsxz5sGXv51TCXMBv3vGRMW75jiP8nt+rODFwpf57Av +eU703fDU2P245dfiO44XlPezb2l9ovSfOW7t5fte+dgc3JP5CwlluKMREMt5qLiRAAZrHEF ngIAAA== Cc: Sam Hartman , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:43:49 -0000 In my examples, I normally use a 30 day transition period.=20 Thanks, Acee=20 On May 21, 2013, at 1:32 PM, Bhatia, Manav (Manav) wrote: > In that case associating a life time with the keys should work as long as= the protocols provide a reasonable window for the key transition. >=20 > Will it help if text is added which basically says that NTP or some timin= g protocol should be running that keeps all clocks pretty much synchronized= so that all routers have a consistent view of the time. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Danny McPherson [mailto:danny@tcb.net]=20 >> Sent: Tuesday, May 21, 2013 10:58 PM >> To: Bhatia, Manav (Manav) >> Cc: Sam Hartman; adrian@olddog.co.uk; rtg-dir@ietf.org;=20 >> draft-ietf-karp-crypto-key-table.all@tools.ietf.org >> Subject: RE: [RTG-DIR] FW: Routing Area Directorate Review=20 >> for draft-ietf-karp-crypto-key-table >>=20 >> On 2013-05-21 10:39, Bhatia, Manav (Manav) wrote: >>> Is it not given that NTP will always be running in any decent sized=20 >>> deployment to sync the clocks? How else would admins make=20 >> sense of the=20 >>> logs/traps coming from different routers if the time stamps are not=20 >>> synced? Given this, why would the clock for accepting keys=20 >> ever drift=20 >>> beyond a few secs/mins? >>=20 >> Indeed my point... >>=20 >> -danny >>=20 >>=20 From manav.bhatia@alcatel-lucent.com Tue May 21 11:21:57 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F6221F967D for ; Tue, 21 May 2013 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYmzvq9VCUBZ for ; Tue, 21 May 2013 11:21:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CA70421F9601 for ; Tue, 21 May 2013 11:21:49 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r4LILe8L013109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 13:21:41 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4LILeCT032763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:21:40 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 21 May 2013 14:21:40 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Wed, 22 May 2013 02:21:37 +0800 From: "Bhatia, Manav (Manav)" To: Sam Hartman , Acee Lindem Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVk4hB2PuMgunukmqOQ/ut1/P/pkP8oUg Date: Tue, 21 May 2013 18:21:36 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "adrian@olddog.co.uk" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:21:57 -0000 I also expect the transition period to be shorter. 30 days seems like etern= ity .. In any decent sized network the routers are synced using NTP. Given this, w= hy does the transition period need to be this large? Cheers, Manav > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com]=20 > Sent: Tuesday, May 21, 2013 11:38 PM > To: Acee Lindem > Cc: Bhatia, Manav (Manav); Danny McPherson;=20 > draft-ietf-karp-crypto-key-table.all@tools.ietf.org;=20 > rtg-dir@ietf.org; adrian@olddog.co.uk > Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review=20 > for draft-ietf-karp-crypto-key-table >=20 > >>>>> "Acee" =3D=3D Acee Lindem writes: >=20 > Acee> In my examples, I normally use a 30 day transition period. > Acee> Thanks, Acee >=20 >=20 > Accee, my point exactly. Danny has asserted a couple of=20 > times that the transition period should be short, but I don't=20 > understand why that's true. >=20 > --Sam > = From acee.lindem@ericsson.com Tue May 21 11:33:34 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FD511E80DC for ; Tue, 21 May 2013 11:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE61-2gq6vII for ; Tue, 21 May 2013 11:33:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BED4611E80A6 for ; Tue, 21 May 2013 11:33:27 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-3f-519bbdf6cd16 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 14.E8.17121.6FDBB915; Tue, 21 May 2013 20:33:27 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 21 May 2013 14:33:25 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVk4hXeuZ+klNEUSCtv5VT/HQ3pkQNoAAgAADTAA= Date: Tue, 21 May 2013 18:33:25 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714BFBA@eusaamb101.ericsson.se> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonVvf73tmBBvun8Fn86LnBbPHy82Nm i51/p7BYzPS0mHPvHqvFgjVP2R3YPFqf7WX1WLLkJ5PHis0rGT1mf2tl9Gg6NpXd48vlz2wB bFFcNimpOZllqUX6dglcGe9mXWEqOMBTcfXwHuYGxqlcXYycHBICJhK3Dy9mgrDFJC7cW8/W xcjFISRwlFFi/ezlLBDOckaJjq5udpAqNgEdieeP/jGD2CICthLPN+8CK2IWmMEk8fJBD1hC WCBR4vDKP0BjOYCKkiT2fY2FqLeSWNOxjA3EZhFQlZjT+oUZpIRXwFvi5/Y0iF2/WCTOrd3K CFLDKRAt8abxKdhIRqDrvp9aA3Yps4C4xK0n86GuFpBYsuc8M4QtKvHy8T9WCFtZYsmT/SwQ 9ToSC3Z/YoOwrSXerX0CNUdbYtnC12C9vAKCEidnPmGZwCg+C8mKWUjaZyFpn4WkfRaS9gWM rKsYOUqLU8ty040MNjECY/SYBJvuDsY9Ly0PMUpzsCiJ87ZqTw0UEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwDiPXzrj1FVXCcnQHQaPdm93vXi7vfxeytIv9vmCxRPPNDn+aFJSEDDvXq+r IfBmVVpg6cOsM76JqyZeFUrkPv5MieHQTo3rqqfmdKbZtF5/XsPGddhWS/hztt+Zj/nvW7O3 u2oUz19sFRfU//T6G4nNj1P3d708vzt2oppb/uf1n8Wk/1vbeSmxFGckGmoxFxUnAgA6yPvy nwIAAA== Cc: Sam Hartman , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:33:34 -0000 I'm not forcing any period. I'm just making the point that there is no sens= e to try and synchronize all your keys between 12:00 AM and 12:01 AM on Jan= uary 1st. You should use an interval that satisfies your network administra= tion model for the domain to which the key is scoped. Given that there is a= major concern that network providers do not change keys periodically, a li= beral transition window is preferable to not changing the keys at all.=20 Thanks, Acee=20 On May 21, 2013, at 2:21 PM, Bhatia, Manav (Manav) wrote: > I also expect the transition period to be shorter. 30 days seems like ete= rnity .. >=20 > In any decent sized network the routers are synced using NTP. Given this,= why does the transition period need to be this large? >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans@painless-security.com]=20 >> Sent: Tuesday, May 21, 2013 11:38 PM >> To: Acee Lindem >> Cc: Bhatia, Manav (Manav); Danny McPherson;=20 >> draft-ietf-karp-crypto-key-table.all@tools.ietf.org;=20 >> rtg-dir@ietf.org; adrian@olddog.co.uk >> Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review=20 >> for draft-ietf-karp-crypto-key-table >>=20 >>>>>>> "Acee" =3D=3D Acee Lindem writes: >>=20 >> Acee> In my examples, I normally use a 30 day transition period. >> Acee> Thanks, Acee >>=20 >>=20 >> Accee, my point exactly. Danny has asserted a couple of=20 >> times that the transition period should be short, but I don't=20 >> understand why that's true. >>=20 >> --Sam From housley@vigilsec.com Tue May 21 11:51:26 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7487921F968B for ; Tue, 21 May 2013 11:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgyDrUbfXda5 for ; Tue, 21 May 2013 11:51:20 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3660721F9540 for ; Tue, 21 May 2013 11:51:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8AFC8F2407B; Tue, 21 May 2013 14:51:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id CHuSkdzH5p89; Tue, 21 May 2013 14:50:59 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E4CF1F24072; Tue, 21 May 2013 14:51:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 21 May 2013 14:51:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> To: Sam Hartman X-Mailer: Apple Mail (2.1085) Cc: adrian@olddog.co.uk, draft-ietf-karp-crypto-key-table.all@tools.ietf.org, rtg-dir@ietf.org, Danny McPherson Subject: Re: [RTG-DIR] Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:51:26 -0000 I see no reason not to add a key name that is intended fro human recognition. Suggestion: AdminKeyName The AdminKeyName field contains a string identifying the key by humans. The same string can be used on the local system and peer systems, but this is not required. Protocols do not make use of this string; protocols use the LocalKeyName and the PeerKeyName. Russ On May 21, 2013, at 11:46 AM, Sam Hartman wrote: > > Hi. > I think I better understand our confusion regarding key names. > > The draft is wrong:-) > > There's supposed to be an administrative key name field that is how the > operator refers to the key. The local and peer key names are used to > construct the wire formats. As an example the base OSPF spec has an > integer format for that wire key name. > > however, the conceptual database in the draft seems to be missing the > administrative key name. You're completely right that without that, > operators are going to have significant trouble. > > I'm not sure how that fell through the cracks, but I'll confirm with the > WG and fix. Thanks for the catch! From manav.bhatia@alcatel-lucent.com Tue May 21 11:51:52 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281521F96D9 for ; Tue, 21 May 2013 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6g264Nt6lOo for ; Tue, 21 May 2013 11:51:45 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AD1C821F96CB for ; Tue, 21 May 2013 11:51:45 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4LIpg0Z013767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2013 13:51:42 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4LIpgbe015147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:51:42 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 21 May 2013 14:51:42 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Wed, 22 May 2013 02:51:38 +0800 From: "Bhatia, Manav (Manav)" To: Sam Hartman Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table Thread-Index: AQHOVlBLB2PuMgunukmqOQ/ut1/P/pkP9DpA Date: Tue, 21 May 2013 18:51:38 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C302A392@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-dir@ietf.org" , Acee Lindem , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "adrian@olddog.co.uk" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:51:52 -0000 > It doesn't. > Why does it need to be short? >=20 Once instance of when you might want to change the key is when the person w= ho had access to the keys leaves the organization (based on what we heard f= rom the operators in KARP when doing karp design guide). By giving a transi= tion period of 30 days, you leave your network vulnerable for that long. You change the key on all routers using your favorite provisioning tool. No= w since all routers are in sync, you can actually give a transition period = in O(hours) or the amount of time that it takes you to reconfigure all your= routers in your network. Once that's over, all your routers have moved ove= r to the new Key. BTW, discussing the length of the transition period in the context of this = draft looks like a daft digression! :) I think it would be useful to add some text about assuming that the clocks = on all routers will be pretty much in sync - specifically since you are rec= ommending key life times in the draft.=20 Cheers, Manav From housley@vigilsec.com Tue May 21 11:56:28 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05121F96E0 for ; Tue, 21 May 2013 11:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG82K6cAw4MV for ; Tue, 21 May 2013 11:56:21 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BFF4421F9603 for ; Tue, 21 May 2013 11:56:21 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id AB385F2407D; Tue, 21 May 2013 14:56:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id MBSgcd054Sft; Tue, 21 May 2013 14:56:00 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DABE4F24072; Tue, 21 May 2013 14:56:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4714BBC8@eusaamb101.ericsson.se> Date: Tue, 21 May 2013 14:56:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <94A203EA12AECE4BA92D42DBFFE0AE4714BBC8@eusaamb101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1085) Cc: Sam Hartman , "" , "" , "" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:56:28 -0000 Acee: If the parties can agree to use the same identifier, that is fine, they = can populate the field with the same value. However, the complexity really is needed. If I tell you that I'm going = to call the key 48, and you already have a key with that identifier, = then one of us needs to rearrange things or we have to find an = identifier without a collision. Since some of the routing protocols = have a 16-bit identifier, this seems like a significant coordination = activity. Russ On May 21, 2013, at 12:14 PM, Acee Lindem wrote: > Sam,=20 > I think is very confusing to have a LocalKeyName, PeerKeyName, and = AdminKeyName. Hell, LocalKeyName and PeerKeyName are already confusing. = Could we replace the key used for wire formats with a single = SecurityAssociationID? If there is any justice in the universe, the = local system and peer system will agree.=20 > Thanks, > Acee=20 >=20 > On May 21, 2013, at 11:46 AM, Sam Hartman wrote: >=20 >>=20 >> Hi. >> I think I better understand our confusion regarding key names. >>=20 >> The draft is wrong:-) >>=20 >> There's supposed to be an administrative key name field that is how = the >> operator refers to the key. The local and peer key names are used to >> construct the wire formats. As an example the base OSPF spec has an >> integer format for that wire key name. >>=20 >> however, the conceptual database in the draft seems to be missing the >> administrative key name. You're completely right that without that, >> operators are going to have significant trouble. >>=20 >> I'm not sure how that fell through the cracks, but I'll confirm with = the >> WG and fix. Thanks for the catch! >=20 From danny@tcb.net Tue May 21 12:44:10 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D911E811A for ; Tue, 21 May 2013 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvpgClu0JLUf for ; Tue, 21 May 2013 12:44:05 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 36C0311E811B for ; Tue, 21 May 2013 12:44:05 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id DCB0C300056 for ; Tue, 21 May 2013 19:44:04 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.friendswithtools.org (Postfix) with ESMTP id CFF00300021; Tue, 21 May 2013 13:44:02 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 13:44:02 -0600 From: Danny McPherson To: Sam Hartman In-Reply-To: References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> Message-ID: <50b675ac00305c285d1ec9bb1ac3e1a6@tcb.net> X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue May 21 13:44:04 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 519bce8442071113538903 X-DSPAM-Factors: 27, Subject*FW+#+Area, 0.01000, Subject*Area+#+Review, 0.01000, Subject*FW+Routing, 0.01000, Subject*FW+#+#+#+Review, 0.01000, Subject*Directorate+#+for, 0.01000, Subject*Routing+Area, 0.01000, Subject*Area+#+#+for, 0.01000, Cc*adrian+olddog.co.uk, 0.01000, On+#+05, 0.01000, Subject*Routing+#+#+Review, 0.01000, Subject*Routing+#+Directorate, 0.01000, Subject*Directorate+Review, 0.01000, Cc*draft-ietf-karp-crypto-key-table.all+tools.ietf.org, 0.01000, 2013+05, 0.01000, 2013+#+21, 0.01000, going+to, 0.01000, From*Danny+#+danny, 0.01000, Subject*Area+Directorate, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Subject*Review+for, 0.01000, From*Danny+McPherson, 0.01000, Cc*rtg-dir+ietf.org, 0.01000, On+2013, 0.01000, Subject*FW+#+#+Directorate, 0.01000, On+#+#+21, 0.01000, From*McPherson+danny, 0.01000, From*Danny McPherson , 0.01000 Cc: adrian@olddog.co.uk, rtg-dir@ietf.org, Acee Lindem , "Bhatia, Manav \(Manav\)" , draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:44:10 -0000 On 2013-05-21 12:23, Sam Hartman wrote: > > It doesn't. > Why does it need to be short? I agree with Manav's example (we're doing some of this ourselves currently). Say for example we have a critical server that distributes an important file and needs availability of t per an SLA unless in a change management/maintenance window. Assume that server is reachable because LSPs are validated and processed. I don't want that key to rollover at some period in a 30 day window that I don't have staff on hand to deal with any issues that may result. The same applies for BGP where I may want to have a peer for a critical transit link to have their operations folks on the phone during key rollovers so that if problems occur we can address them - say I have 10 or 20 or 50 of these to do in one night. If we were going to use such a capability we need it to be precise. -danny From hartmans@painless-security.com Tue May 21 11:08:08 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C7021F8793 for ; Tue, 21 May 2013 11:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxJfLxN30YSC for ; Tue, 21 May 2013 11:08:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5D23621F8746 for ; Tue, 21 May 2013 11:08:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3BAC120556; Tue, 21 May 2013 14:05:05 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McsN6uso53Me; Tue, 21 May 2013 14:05:04 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 14:05:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1CC63440B; Tue, 21 May 2013 14:08:01 -0400 (EDT) From: Sam Hartman To: Acee Lindem References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> Date: Tue, 21 May 2013 14:08:01 -0400 In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> (Acee Lindem's message of "Tue, 21 May 2013 17:43:37 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 May 2013 13:09:00 -0700 Cc: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:08:08 -0000 >>>>> "Acee" == Acee Lindem writes: Acee> In my examples, I normally use a 30 day transition period. Acee> Thanks, Acee Accee, my point exactly. Danny has asserted a couple of times that the transition period should be short, but I don't understand why that's true. --Sam From hartmans@painless-security.com Tue May 21 11:23:38 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD221F9684 for ; Tue, 21 May 2013 11:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqNULMHwsv3A for ; Tue, 21 May 2013 11:23:32 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6EB21F967D for ; Tue, 21 May 2013 11:23:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6A9B320608; Tue, 21 May 2013 14:20:34 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMtckfGl9NwN; Tue, 21 May 2013 14:20:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 14:20:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7B45C440B; Tue, 21 May 2013 14:23:30 -0400 (EDT) From: Sam Hartman To: "Bhatia\, Manav \(Manav\)" References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Tue, 21 May 2013 14:23:30 -0400 In-Reply-To: <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> (Manav Bhatia's message of "Tue, 21 May 2013 18:21:36 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 May 2013 13:09:01 -0700 Cc: "rtg-dir@ietf.org" , Acee Lindem , "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" , "adrian@olddog.co.uk" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:23:38 -0000 >>>>> "Bhatia," == Bhatia, Manav (Manav) writes: Bhatia,> I also expect the transition period to be shorter. 30 days Bhatia,> seems like eternity .. In any decent sized network the Bhatia,> routers are synced using NTP. Given this, why does the Bhatia,> transition period need to be this large? It doesn't. Why does it need to be short? From hartmans@painless-security.com Tue May 21 11:47:26 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36BB11E80D2 for ; Tue, 21 May 2013 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sfw-fQwJOhv for ; Tue, 21 May 2013 11:47:21 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9A75B11E80A5 for ; Tue, 21 May 2013 11:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 281DA2060D; Tue, 21 May 2013 14:44:23 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfFtf1r-Upam; Tue, 21 May 2013 14:44:22 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 21 May 2013 14:44:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4532B440B; Tue, 21 May 2013 14:47:19 -0400 (EDT) From: Sam Hartman To: Acee Lindem References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <94A203EA12AECE4BA92D42DBFFE0AE4714BBC8@eusaamb101.ericsson.se> Date: Tue, 21 May 2013 14:47:19 -0400 In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4714BBC8@eusaamb101.ericsson.se> (Acee Lindem's message of "Tue, 21 May 2013 16:14:29 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 May 2013 13:09:01 -0700 Cc: "" , "" , "" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:47:27 -0000 >>>>> "Acee" == Acee Lindem writes: Acee> Sam, I think is very confusing to have a LocalKeyName, Acee> PeerKeyName, and AdminKeyName. Hell, LocalKeyName and Acee> PeerKeyName are already confusing. Could we replace the key Acee> used for wire formats with a single SecurityAssociationID? If Acee> there is any justice in the universe, the local system and Acee> peer system will agree. Thanks, Acee As an individual I don't support this change. here are some reasons; 1) we want the key table to be able to represent all the things that the protocols can represent. 2) Coordinating things like this between organizations ends up being tricky. Since there's no technical requirement to require such coordination I'd prefer not to add one here. as a matter of process, I think proposing this change after IETF last call has concluded is too late. The reason i think introducing the admin key name may still be appropriate is that we had told the WG at multiple points we would do that and I believe the WG had consensus to do so. obviously, determining that is up to the KARP chairs. From jmh@joelhalpern.com Tue May 21 17:58:43 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466EA21F93F6 for ; Tue, 21 May 2013 17:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpc-8IEfC6sm for ; Tue, 21 May 2013 17:58:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7653321F871D for ; Tue, 21 May 2013 17:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 609E11C0840; Tue, 21 May 2013 17:58:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-236.clppva.east.verizon.net [70.106.134.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 05A1D1C0138; Tue, 21 May 2013 17:58:35 -0700 (PDT) Message-ID: <519C1838.1020509@joelhalpern.com> Date: Tue, 21 May 2013 20:58:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Danny McPherson References: <00d701ce4f4d$3bc9cc80$b35d6580$@olddog.co.uk> <5ef29b4ea5cf9b8d9f56867fda33c63c@tcb.net> <20211F91F544D247976D84C5D778A4C3029F33@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C302A04D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <94A203EA12AECE4BA92D42DBFFE0AE4714BE26@eusaamb101.ericsson.se> <20211F91F544D247976D84C5D778A4C302A30F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <50b675ac00305c285d1ec9bb1ac3e1a6@tcb.net> In-Reply-To: <50b675ac00305c285d1ec9bb1ac3e1a6@tcb.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "Bhatia, Manav \(Manav\)" , rtg-dir@ietf.org, Acee Lindem , draft-ietf-karp-crypto-key-table.all@tools.ietf.org, adrian@olddog.co.uk Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 00:58:43 -0000 Let me try to rephrase the discussion of time, and make a point about context. In reverse order. In terms of context, this document defines the time windows. As this corresponds to current practice, it would be very strange not to have the fields needed to support the current practice. And this document is NOT the deployment guide. This document can not require or expect NTP. that is not its job. Now, in terms of behavior, when you want to change keys, there are many approaches. But an obvious approach that copes with the problems is: 1) Select time T1 that you expect to have the keys configured 2) Select times t2 and t3 for the systems to start using the new key. Make it enough later than t1 that clock skew is a non-issue. Pick a time that suits your maintenance practices 3) Select a time t4, enough after t2 and t3 that clock skew is a non issue, to stop accepting oldkey. 4) Now configure to start accepting newkey at T1, start generating newkey on each system at t2 and T3, and to stop accepting oldkey at T4. If you pick times that match your operational practices and comfort, you have a nice safe transition. If those times ar 1 minute appart because you have NTP and trust it, 5 minutes apart because you are confident of behavior, or days apart because that is the way you work is entirely your business. And again, none of that belongs in this document. Yours, Joel PS: SIDR (origin or path) is out of scope for the working group. On 5/21/2013 3:44 PM, Danny McPherson wrote: > On 2013-05-21 12:23, Sam Hartman wrote: >> >> It doesn't. >> Why does it need to be short? > > I agree with Manav's example (we're doing some of this ourselves > currently). > > Say for example we have a critical server that distributes an important > file and needs availability of t per an SLA unless in a change > management/maintenance window. Assume that server is reachable because > LSPs are validated and processed. I don't want that key to rollover at > some period in a 30 day window that I don't have staff on hand to deal > with any issues that may result. The same applies for BGP where I may > want to have a peer for a critical transit link to have their operations > folks on the phone during key rollovers so that if problems occur we can > address them - say I have 10 or 20 or 50 of these to do in one night. > > If we were going to use such a capability we need it to be precise. > > -danny > > > > From acee.lindem@ericsson.com Fri May 24 14:15:02 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7421F8EEC for ; Fri, 24 May 2013 14:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwhaQKa9e54m for ; Fri, 24 May 2013 14:14:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E880621F8B45 for ; Fri, 24 May 2013 14:14:55 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-63-519fd84ec212 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2A.80.17121.E48DF915; Fri, 24 May 2013 23:14:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Fri, 24 May 2013 17:14:54 -0400 From: Acee Lindem To: Russ Housley Thread-Topic: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) Thread-Index: AQHOVlTqrwXT0RflZ02oRsJrvBfQl5kUqIKA Date: Fri, 24 May 2013 21:14:53 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714FDE2@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLonXNfvxvxAg+Yuc4sfPTeYLV5+fsxs sfPvFBaLmZ4Wr17cZLdYsOYpuwObx5IlP5k8Vmxeyegx+1sro0fTsansHl8uf2bzWHXnC2sA WxSXTUpqTmZZapG+XQJXxu4169kK7glVdP3bydLA+IOvi5GTQ0LAROLxmd+MELaYxIV769m6 GLk4hASOMkoseLqMHcJZzihx99E8sCo2AR2J54/+MYPYIgLqEn/nXwArYhZYwCRx+NIsJpCE sECuxMG1V9ggivIkDq9pg2owknh2ZzVYDYuAqsTa/atYQWxeAW+J2WuugsU5BRwkTs4/wAJi MwKd9P3UGrA4s4C4xK0n85kgThWQWLLnPDOELSrx8vE/sDmiAnoSbcfOsEPElSWWPNnPAtGr I7Fg9yc2CNta4ubLh6wQtrbEsoWvmSFuEJQ4OfMJywRG8VlI1s1C0j4LSfssJO2zkLQvYGRd xchRWpxalptuZLCJERilxyTYdHcw7nlpeYhRmoNFSZy3VXtqoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbG+pd/O8qnTeXoDQ5UVNTuWVi9IMbzxtm304PZ3khKLd77sJ8t99mZx1dPW+9K OODbt/eGmH/AgWsLIu8ekO3sST8u2HR07/XKtyr30hWD/3BwpCo7eUbe4YszeiYZGaOh5TrD RvFe/P6PJ5qSbrnKfFxbvPXT+/ssa6q5QoU0c5TUeNr3PfRQYinOSDTUYi4qTgQAleugyqAC AAA= Cc: Sam Hartman , "" , "" , "" , Danny McPherson Subject: Re: [RTG-DIR] FW: Routing Area Directorate Review for draft-ietf-karp-crypto-key-table (key names) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:15:02 -0000 Hi Russ, Sorry for the delayed response - I had a high priority day job preemption. I must say that I disagree with you here. Once you add the AdminKeyName to the crypto table, that is the unique identifier for table entries and there is not reason to worry about conflicts for other fields. Also, if you are using the same key, there is no reason not to use the same Security Association ID (SA ID). If the keys are asymmetric, then they are separate keys and SA IDs. I'd be interested in Danny's and other routing directorate member's view on this. Thanks, Acee=20 On 5/21/13 11:56 AM, "Russ Housley" wrote: >Acee: > >If the parties can agree to use the same identifier, that is fine, they >can populate the field with the same value. > >However, the complexity really is needed. If I tell you that I'm going >to call the key 48, and you already have a key with that identifier, then >one of us needs to rearrange things or we have to find an identifier >without a collision. Since some of the routing protocols have a 16-bit >identifier, this seems like a significant coordination activity. > >Russ > > > >On May 21, 2013, at 12:14 PM, Acee Lindem wrote: > >> Sam,=20 >> I think is very confusing to have a LocalKeyName, PeerKeyName, and >>AdminKeyName. Hell, LocalKeyName and PeerKeyName are already confusing. >>Could we replace the key used for wire formats with a single >>SecurityAssociationID? If there is any justice in the universe, the >>local system and peer system will agree. >> Thanks, >> Acee=20 >>=20 >> On May 21, 2013, at 11:46 AM, Sam Hartman wrote: >>=20 >>>=20 >>> Hi. >>> I think I better understand our confusion regarding key names. >>>=20 >>> The draft is wrong:-) >>>=20 >>> There's supposed to be an administrative key name field that is how the >>> operator refers to the key. The local and peer key names are used to >>> construct the wire formats. As an example the base OSPF spec has an >>> integer format for that wire key name. >>>=20 >>> however, the conceptual database in the draft seems to be missing the >>> administrative key name. You're completely right that without that, >>> operators are going to have significant trouble. >>>=20 >>> I'm not sure how that fell through the cracks, but I'll confirm with >>>the >>> WG and fix. Thanks for the catch! >>=20 >