From asmirnov@cisco.com Fri May 3 06:02:18 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B98521F8411 for ; Fri, 3 May 2013 06:02:18 -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 3DSgdE66L3in for ; Fri, 3 May 2013 06:02:13 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8C021F845E for ; Fri, 3 May 2013 06:02:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r43D2Bc7020300 for ; Fri, 3 May 2013 15:02:11 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r43D1tc6018163 for ; Fri, 3 May 2013 15:02:06 +0200 (CEST) Message-ID: <5183B543.6000802@cisco.com> Date: Fri, 03 May 2013 15:01:55 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:02:18 -0000 Hi all, I saw this draft was published a few days ago and I wanted to discuss the approach taken by authors. In brief, this draft deeply changes OSPFv3 by totally reworking LSA encodings but stops short of calling it a new version of OSPF protocol. Per draft routers supporting new LSA encodings do not mix with RFC 5340 OSPFv3 routers and do not talk to them. So from deployment point of view section of the draft describing backward compatibility can be reduced to simply "Totally not backward compatible". I think no one will object that OSPFv3 rigid LSA format became big obstacle in introducing new features and even simply catching up with ISIS. I personally fully agree that OSPFv3 has to be deeply reworked. But in my opinion this draft is presenting OSPFv4 without calling it so - and carries into the new version of the protocol some outdated features of OSPFv2. Isn't it a time to admit that OSPFv3 is failure of epic proportions? And to admit that stance 'to introduce minimum changes into the protocol' taken when developing OSPFv3 architecture was deeply flawed, sacrificed long-term benefits of introducing new protocol version to short-term benefits of quick standardization and will continue causing difficulties unless addressed (with LSA encodings being the most obvious but not the only one)? -- Anton From prvs=6835934e65=acee.lindem@ericsson.com Fri May 3 09:14:20 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233F521F8B65 for ; Fri, 3 May 2013 09:14:18 -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 Ulvk9kku-nCE for ; Fri, 3 May 2013 09:14:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4A821F962D for ; Fri, 3 May 2013 08:14:55 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-8c-5183d46e2f85 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5F.C1.26377.E64D3815; Fri, 3 May 2013 17:14:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Fri, 3 May 2013 11:14:54 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] draft-acee-ospfv3-lsa-extend-00 Thread-Index: AQHOR/50spTN+784ukmlvZM1IxEyWpjz1PuA Date: Fri, 3 May 2013 15:14:53 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4713954C@eusaamb101.ericsson.se> References: <5183B543.6000802@cisco.com> In-Reply-To: <5183B543.6000802@cisco.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: <51151E07B492FD42AA525D3BBC1CE0B3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgm7eleZAg8W7zC1atrFatNy7x+7A 5DHl90ZWjyVLfjIFMEVx2yQllpQFZ6bn6dslcGe8u9vPWvBItKJtxR2WBsZzgl2MnBwSAiYS 91r3sEPYYhIX7q1n62Lk4hASOMoo8WzmbUYIZxmjxL6WXhaQKjYBHYnnj/4xg9giAmoSm+9+ YgWxmQWUJR53rWYDsYUFjCXuP1jDBlFjIvGu8SE7hG0k8XHqbzCbRUBFYs6T3WA2r4C3xPMz 3YwgtpCAhsS1k6fB4pwCmhL3p+5hArEZga77fmoNE8QucYlbT+YzQVwtILFkz3lmCFtU4uXj f6wQtrLEkif7WSDqdSQW7P7EBmFbSyydPoUZwtaWWLbwNTPEDYISJ2c+YZnAKD4LyYpZSNpn IWmfhaR9FpL2BYysqxg5SotTy3LTjQw2MQLj6pgEm+4Oxj0vLQ8xSnOwKInzRnE1BgoJpCeW pGanphakFsUXleakFh9iZOLgBBFcUg2MO8s0PuesKXpmkfw/e2ehbeo/fw3u5f2r16Td29jf br8m/rDU6gDldcbPLeqlWRPfBllKSLieOPdir+jle8K2zplH9FcuKfoUkazZpnLfOPDY5Dtv NZtF75UtOBsu+ubl5h7Ju1ycs+NFYi9Uv7/0seSDwNetjnx3llddPDP51Q/xbPm10fMWKrEU ZyQaajEXFScCAOwv4vN+AgAA Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 16:14:20 -0000 Hi Anton,=20 Thanks for introducing the draft - I had meant to do it but am chronically = pressed for time. Here is the link:=20 https://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend/ You are correct that the draft does require a deployment upgrade. A mixed d= eployment will require separate OSPFv3 routing domains and multiple OSPFv3 = instances at least at the boundaries. The alternative was to require both t= he existing LSAs and the Extended-LSAs to be originated in mixed deployment= s. This adds quite a lot of complexity and will not be scalable in many net= works. It is definitely possible but is the is the sort of backward compati= bility mechanism people who don't write or maintain routing software propos= e.=20 As far as calling it OSPFv4, I don't think we need to do this since only th= e encoding of the LSAs change. We were careful not to change the LSA semant= ics in the interest of rapid acceptance, implementation, and, hopefully, de= ployment. I believe the OSPFv3 moniker should be reserved for a version of = the protocol with far more changes (including deprecation of virtual links = ;^).=20 Thanks, Acee=20 On May 3, 2013, at 9:01 AM, Anton Smirnov wrote: > Hi all, > I saw this draft was published a few days ago and I wanted to discuss t= he approach taken by authors. In brief, this draft deeply changes OSPFv3 by= totally reworking LSA encodings but stops short of calling it a new versio= n of OSPF protocol. Per draft routers supporting new LSA encodings do not m= ix with RFC 5340 OSPFv3 routers and do not talk to them. So from deployment= point of view section of the draft describing backward compatibility can b= e reduced to simply "Totally not backward compatible". >=20 > I think no one will object that OSPFv3 rigid LSA format became big obst= acle in introducing new features and even simply catching up with ISIS. > I personally fully agree that OSPFv3 has to be deeply reworked. > But in my opinion this draft is presenting OSPFv4 without calling it so= - and carries into the new version of the protocol some outdated features = of OSPFv2. > Isn't it a time to admit that OSPFv3 is failure of epic proportions? An= d to admit that stance 'to introduce minimum changes into the protocol' tak= en when developing OSPFv3 architecture was deeply flawed, sacrificed long-t= erm benefits of introducing new protocol version to short-term benefits of = quick standardization and will continue causing difficulties unless address= ed (with LSA encodings being the most obvious but not the only one)? >=20 > --=20 > Anton >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From fred@cisco.com Fri May 3 10:10:46 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E999B21F99DC for ; Fri, 3 May 2013 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108 X-Spam-Level: X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, 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 DRCDscPd3owo for ; Fri, 3 May 2013 10:10:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1D25E21F9896 for ; Fri, 3 May 2013 08:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4837; q=dns/txt; s=iport; t=1367596711; x=1368806311; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3XgXnlaq1T3aUCX/yIyv6zNvc4+jIedBTKxPF19UL4I=; b=gasJQ9mZKA3aJlBhA/VLbe6HLyKkHpzxy1qsxjHgk6OAHkNaJ4AUlPqN lmrE5jRecgvoenm9iNWsjvX+OWcUkQArWQeGZdhPpRkLnWCKLBmciFvsz YSnNtyFR9ktUaUo5VJ2AmXIFVwVZn7fz50nNBpK4otshUwphcZiANw9Y4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcGAKvdg1GtJXHB/2dsb2JhbABQgwc3RL5ueRZtB4IhAQQ6UQEaEBRCFxAEG4gEBwWiCJ89jwCDKmEDmFKKboUegw1yAYE0 X-IronPort-AV: E=Sophos;i="4.87,605,1363132800"; d="scan'208";a="206140649" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 03 May 2013 15:58:16 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r43FwG93006561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 May 2013 15:58:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 3 May 2013 10:58:15 -0500 From: "Fred Baker (fred)" To: "ospf@ietf.org" Thread-Topic: Extensible LSAs Thread-Index: AQHOSBcF6qrBfLZt6Uegrm5XE7rqsA== Date: Fri, 3 May 2013 15:58:15 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B842575@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Extensible LSAs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:10:47 -0000 As I started at the past IETF meeting, there has been some additional work = on extensible LSAs, egress routing, and building access control into routin= g (which in my mind is primarily useful in data centers). Interested in you= r remarks. http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred Baker, 1-May-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing diff: http://tinyurl.com/ct9wn6g "Using OSPFv3 with Role-Based Access Control", Fred Baker, 2-May-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing diff: http://tinyurl.com/ctcshzb "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2-May-13 To diff from the previous drafts, if you want one, you want to do this foll= owing. This is what the tiny url gets you. http://tools.ietf.org/rfcdiff? url1=3Dhttp://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-00= .txt &url2=3Dhttp://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-0= 2.txt http://tools.ietf.org/rfcdiff? url1=3Dhttp://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-rout= ing-00.txt &url2=3Dhttp://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-rou= ting-02.txt I'll save you one question, though. I get asked frequently why these didn't= follow MT-OSPF or MI-OSPF, and commented on this in the meeting in Orlando= . The reason is that neither is fundamentally a topology or instance questi= on. MT-OSPF OSPF presumes that some non-null set of links in a topology are= either absent from some of the topologies or that metrics differ, so that = routes in one topology differ from those in another. This is about qualific= ation of routes - a scalable access list or policy route, if you will. One = could integrate it with MT-OSPF within a network, but the most immediate us= e cases aren't helped by it. Consider egress routing in a multihomed network, the use case presented by = homenet. We have a network with two or more upstreams, each of which alloca= tes a PA prefix to the network. In homenet's case and probably for small ne= tworks, The technique described in draft-ietf-ospf-ospfv3-autoconfig-02.txt= is used to allocate a /64 prefix from each PA prefix to each LAN in the do= main. Links derive their metrics from bandwidth, and might in effect use ho= p count. So the different "topologies" are identical. What differs between = them is that there are multiple default routes, and due to BCP 38 implement= ation upstream, we want to direct traffic using a given ISP's PA prefix to = that ISP. So we want to attach a source prefix to each default (AS-external= , most likely, or at least an intra-as-prefix) route. Internal routes, in t= hat case, will likely accept "any" source including external sources, which= is to say that they are advertised without a source prefix. The concept of source/destination routing is extensible to intra-area or in= ter-area routing as well as egress routing. The use cases are most likely s= omething about security - there is some domain within the network that only= certain other parts of the network are permitted to reach. That is, of cou= rse, more hypothetical at this point. As to the use of the flow label, in a multi-tenant data center, that is a *= lot* of topologies. I think it has scaling issues. As to Multi-Instance, su= ppose I put a set of VMs on a LAN that are part of one tenant and another s= et of VMs in a different tenant. Yes, I probably put them into different su= bnets. But how do instances actually help me there? They don't, really. What the SDN folks are doing right now is segregating the network using ove= rlays - GRE tunnels, VLANs, or some such thing. That mostly has the effect = of making it difficult for the network to do anything, or to optimize the a= pplication in any way from a network perspective. I'd like to keep the appl= ication stuff at the application layer and enable the network to support th= e application. So to my way of thinking, the applications should think in t= erms of communicating with each other as instances - names, addresses given= by some controller, or whatever - and are given those by the controller th= at created them using whatever protocol it uses. Part of what they are give= n, one of half a dozen parameters they are already given, is a tenant numbe= r for access control to put into the flow label. The controller can similar= ly configure the OSPF instance on their favorite router to advertise the su= bnet(s) in question with those tenant numbers. Voila, they have communicati= on that is supported in the network architecture, and with this they are gi= ven the communication isolation they're looking for. From asmirnov@cisco.com Fri May 3 10:27:10 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5158D21F902D for ; Fri, 3 May 2013 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 jzjcrzuU5C00 for ; Fri, 3 May 2013 10:27:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D65FF21F972D for ; Fri, 3 May 2013 08:54:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r43FsFHL008729; Fri, 3 May 2013 17:54:15 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r43Frng5020825; Fri, 3 May 2013 17:54:04 +0200 (CEST) Message-ID: <5183DD8D.1010900@cisco.com> Date: Fri, 03 May 2013 17:53:49 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <5183B543.6000802@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4713954C@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4713954C@eusaamb101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:27:10 -0000 Hi Acee, > As far as calling it OSPFv4, I don't think we need to do this since > only the encoding of the LSAs change. Yes I understand the reasoning but that is exactly where I have a problem with this approach. As it is said - “For every problem there is a solution which is simple, fast and wrong.” I believe approach taken while architecturing OSPFv3 was exactly that - simple, fast and wrong. Exactly the reason why we have to talk right now about creating non-backward-compatible change is because OSPFv3 inherited from OSPFv2 rigid LSA structure in the name of simplicity. I just want to make sure we will not repeat the same mistake again - create non-backward-compatible revision of the protocol which missed opportunity to implement anything but only single change. So understand me right - I fully agree with you that OSPFv3 is not extendable, I have no big problem with semantics of proposed extended LSAs, I am even ready to accept non-backward-compatible change (just because I do not see any other exit from dead end we cornered ourselves into). But I have big problem with approach "lets do minimum changes possible". Solution - since it is non-backward-compatible - must first of all be RIGHT and only then, if possible, simple. So what I am advocating is - lets acknowledge protocol needs major non-backward-compatible uplift and see what else can be fit into such protocol upgrade. Yes, it is going to be slow - but then result will be better. Anton On 05/03/2013 05:14 PM, Acee Lindem wrote: > Hi Anton, > Thanks for introducing the draft - I had meant to do it but am chronically pressed for time. Here is the link: > > https://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend/ > > You are correct that the draft does require a deployment upgrade. A mixed deployment will require separate OSPFv3 routing domains and multiple OSPFv3 instances at least at the boundaries. The alternative was to require both the existing LSAs and the Extended-LSAs to be originated in mixed deployments. This adds quite a lot of complexity and will not be scalable in many networks. It is definitely possible but is the is the sort of backward compatibility mechanism people who don't write or maintain routing software propose. > > As far as calling it OSPFv4, I don't think we need to do this since only the encoding of the LSAs change. We were careful not to change the LSA semantics in the interest of rapid acceptance, implementation, and, hopefully, deployment. I believe the OSPFv3 moniker should be reserved for a version of the protocol with far more changes (including deprecation of virtual links ;^). > > Thanks, > Acee > > On May 3, 2013, at 9:01 AM, Anton Smirnov wrote: > >> Hi all, >> I saw this draft was published a few days ago and I wanted to discuss the approach taken by authors. In brief, this draft deeply changes OSPFv3 by totally reworking LSA encodings but stops short of calling it a new version of OSPF protocol. Per draft routers supporting new LSA encodings do not mix with RFC 5340 OSPFv3 routers and do not talk to them. So from deployment point of view section of the draft describing backward compatibility can be reduced to simply "Totally not backward compatible". >> >> I think no one will object that OSPFv3 rigid LSA format became big obstacle in introducing new features and even simply catching up with ISIS. >> I personally fully agree that OSPFv3 has to be deeply reworked. >> But in my opinion this draft is presenting OSPFv4 without calling it so - and carries into the new version of the protocol some outdated features of OSPFv2. >> Isn't it a time to admit that OSPFv3 is failure of epic proportions? And to admit that stance 'to introduce minimum changes into the protocol' taken when developing OSPFv3 architecture was deeply flawed, sacrificed long-term benefits of introducing new protocol version to short-term benefits of quick standardization and will continue causing difficulties unless addressed (with LSA encodings being the most obvious but not the only one)? >> >> -- >> Anton >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > From prvs=8836ed0ccd=acee.lindem@ericsson.com Sat May 4 14:32:05 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1767821F8A11 for ; Sat, 4 May 2013 14:32:05 -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 aOLioimt5LKN for ; Sat, 4 May 2013 14:31:54 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE1A21F863B for ; Sat, 4 May 2013 14:31:54 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-e7-51857e495dcc Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 44.88.26377.94E75815; Sat, 4 May 2013 23:31:53 +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; Sat, 4 May 2013 17:31:52 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] draft-acee-ospfv3-lsa-extend-00 Thread-Index: AQHOR/50spTN+784ukmlvZM1IxEyWpjz1PuAgAAK44CAAXtugA== Date: Sat, 4 May 2013 21:31:52 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4713A900@eusaamb101.ericsson.se> In-Reply-To: <5183DD8D.1010900@cisco.com> 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.135] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPrK5nXWugwZkeFYuWbawWLffusTsw eUz5vZHVY8mSn0wBTFHcNkmJJWXBmel5+nYJ3BmnJ5xhLXinUXFvVi9rA+MMxS5GDg4JAROJ r+99uxg5gUwxiQv31rN1MXJxCAkcZZQ4v/86O4SzjFFi1eR57CBVbAI6Es8f/WMGsUUE1CQ2 3/3ECmIzCyhLPO5azQZiCwsYS9x/sIYNosZE4l3jQ3YI20niyGqIOSwCKhI7/j8Hq+EV8JaY 8fE8WJxTQFNiYvNDJhCbEeii76fWMEHMF5e49WQ+E8SlAhJL9pxnhrBFJV4+/gd2g6iAnkTb sTPsEHFlie9zHrFA9OpJ3Jg6hQ3CtpbY9X42VFxbYtnC18wQNwhKnJz5hGUCo/gsJOtmIWmf haR9FpL2WUjaFzCyrmLkKC1OLctNNzLYxAiMqmMSbLo7GPe8tDzEKM3BoiTOG8XVGCgkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDE0RwSTUwZize8yOf/QYjc75oTuGkQL3uK9kHtnK3zFFKn1n3 uVzX+CCP4RvW5saYF9b3c4/v5nn09Pqds3kTZ8n1Kze+m3s8xjajhff2zxUqTA2p3xxcbk2b smfmwQPbipetV/ZcMGX5lcAHjm8in3zjPVh/oDfRWEk1u+Zpi1dgxqOwzYv3CXY0fDjxQIml OCPRUIu5qDgRAMMW63x9AgAA Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 21:32:05 -0000 Hi Anton,=20 If you look at the drafts Fred recently refreshed, I think you'll have to agree that we have a burning requirement for this extension. Additionally, history has proven that more focused work has a better chance of reaching fruition. As for backward compatibly, it is possible to do something akin to RFC 1793 and the original unpublished version of this draft contained these mechanisms. However, it is not clear that the complexity justifies the mechanisms - we'll leave that for the WG to decide. Acee=20 P.S. To quote a philosopher of the late 20th century, "You can't always get what you want. But if you try sometimes well you might find you get what you need."=20 On 5/3/13 8:53 AM, "Anton Smirnov" wrote: > Hi Acee, > > > As far as calling it OSPFv4, I don't think we need to do this since > > only the encoding of the LSAs change. > >Yes I understand the reasoning but that is exactly where I have a >problem with this approach. >As it is said - =B3For every problem there is a solution which is simple, >fast and wrong.=B2 >I believe approach taken while architecturing OSPFv3 was exactly that - >simple, fast and wrong. Exactly the reason why we have to talk right now >about creating non-backward-compatible change is because OSPFv3 >inherited from OSPFv2 rigid LSA structure in the name of simplicity. > >I just want to make sure we will not repeat the same mistake again - >create non-backward-compatible revision of the protocol which missed >opportunity to implement anything but only single change. > >So understand me right - I fully agree with you that OSPFv3 is not >extendable, I have no big problem with semantics of proposed extended >LSAs, I am even ready to accept non-backward-compatible change (just >because I do not see any other exit from dead end we cornered ourselves >into). >But I have big problem with approach "lets do minimum changes possible". >Solution - since it is non-backward-compatible - must first of all be >RIGHT and only then, if possible, simple. > >So what I am advocating is - lets acknowledge protocol needs major >non-backward-compatible uplift and see what else can be fit into such >protocol upgrade. Yes, it is going to be slow - but then result will be >better. > >Anton > > >On 05/03/2013 05:14 PM, Acee Lindem wrote: >> Hi Anton, >> Thanks for introducing the draft - I had meant to do it but am >>chronically pressed for time. Here is the link: >> >> https://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend/ >> >> You are correct that the draft does require a deployment upgrade. A >>mixed deployment will require separate OSPFv3 routing domains and >>multiple OSPFv3 instances at least at the boundaries. The alternative >>was to require both the existing LSAs and the Extended-LSAs to be >>originated in mixed deployments. This adds quite a lot of complexity and >>will not be scalable in many networks. It is definitely possible but is >>the is the sort of backward compatibility mechanism people who don't >>write or maintain routing software propose. >> >> As far as calling it OSPFv4, I don't think we need to do this since >>only the encoding of the LSAs change. We were careful not to change the >>LSA semantics in the interest of rapid acceptance, implementation, and, >>hopefully, deployment. I believe the OSPFv3 moniker should be reserved >>for a version of the protocol with far more changes (including >>deprecation of virtual links ;^). >> >> Thanks, >> Acee >> >> On May 3, 2013, at 9:01 AM, Anton Smirnov wrote: >> >>> Hi all, >>> I saw this draft was published a few days ago and I wanted to >>>discuss the approach taken by authors. In brief, this draft deeply >>>changes OSPFv3 by totally reworking LSA encodings but stops short of >>>calling it a new version of OSPF protocol. Per draft routers supporting >>>new LSA encodings do not mix with RFC 5340 OSPFv3 routers and do not >>>talk to them. So from deployment point of view section of the draft >>>describing backward compatibility can be reduced to simply "Totally not >>>backward compatible". >>> >>> I think no one will object that OSPFv3 rigid LSA format became big >>>obstacle in introducing new features and even simply catching up with >>>ISIS. >>> I personally fully agree that OSPFv3 has to be deeply reworked. >>> But in my opinion this draft is presenting OSPFv4 without calling >>>it so - and carries into the new version of the protocol some outdated >>>features of OSPFv2. >>> Isn't it a time to admit that OSPFv3 is failure of epic >>>proportions? And to admit that stance 'to introduce minimum changes >>>into the protocol' taken when developing OSPFv3 architecture was deeply >>>flawed, sacrificed long-term benefits of introducing new protocol >>>version to short-term benefits of quick standardization and will >>>continue causing difficulties unless addressed (with LSA encodings >>>being the most obvious but not the only one)? >>> >>> -- >>> Anton >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> From prvs=8836ed0ccd=acee.lindem@ericsson.com Sat May 4 14:51:53 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCC421F8A81 for ; Sat, 4 May 2013 14:51:47 -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.001, BAYES_00=-2.599, HTML_MESSAGE=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 r1Ej+8VCKRcw for ; Sat, 4 May 2013 14:51:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2067921F853A for ; Sat, 4 May 2013 14:51:41 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-53-518582ec5091 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A5.A8.26377.CE285815; Sat, 4 May 2013 23:51:40 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sat, 4 May 2013 17:51:40 -0400 From: Acee Lindem To: "ospf@ietf.org" Thread-Topic: [OSPF] Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt Thread-Index: AQHOM8EYrvgWOlU3J0mk3Q9C3wXCypj1iU+A Date: Sat, 4 May 2013 21:51:40 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4713A9C0@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4711038C@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/mixed; boundary="_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyuXRPlO6bptZAgz97TCxa7t1jd2D0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8azrnuMBUsVKxacmsbSwLhItouRk0NCwERi3qvJTBC2mMSF e+vZuhi5OIQEjjJK9D89CeUsY5T4tPwRC0gVm4COxPNH/5hBbBEBZYkte/vZQGxhgRKJ+Rs2 QcVLJd4fOc8IYRtJfNh1CqyGRUBFYtqixWA1vALeEhP2/GQHsTkFfCRmP7kENp8R6Irvp9aA XcQsIC5x68l8qOtEJB5ePM0GYYtKvHz8jxXEFhXQk2g7doYdIq4s8X0OyJ0cQL2ZEp2fKyBW CUqcnPmEZQKjyCwkU2chVM1CUgVRki/x+MQmZghbR2LB7k9sELa2xLKFr5lh7DMHHjNB2NYS 3+9vYcFUoytx5PwxdghbUaJtezPQHC4gewWjxKLGf+wwzTfXX2SDKZrS/ZB9ASPfKkaO0uLU stx0I4NNjMCYPibBpruDcc9Ly0OM0hwsSuK8UVyNgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 QQSXVAPjDL807+gg6671onPNuDzmy9zQWL6LpdJnSmt/uM397M2Cz7fprd9excye2qR9fn9v ovmq+ULPBJ1aU4ymPb+XGiAU9SagvO8851ND04xDTgGZW+f83Ta/jFUjMYs1Ibf8m2ak1/O1 7edPaR8Wmyjf1rJKYNfcxW6H0yXPuHRwXos8EbL/1z8lluKMREMt5qLiRADuoylMvAIAAA== Subject: [OSPF] FW: Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 21:51:53 -0000 --_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_ Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_" --_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The working group last call has ended on the subject document. It will go t= o the ADs for review once the shepherding document it complete. From: Ericsson > Date: Sunday, April 7, 2013 11:52 AM To: OSPF List > Subject: [OSPF] Use of OSPF-MDR in Single-Hop Broadcast Networks - draft-ie= tf-ospf-manet-single-hop-mdr-01.txt All, I'd like to start a 2 week WG last call on the subject document. The last c= all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen= t and send any comments to the list prior to that time. Here is a URL for y= our convenience: https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The working group last call has ended on the subject document. It will= go to the ADs for review once the shepherding document it complete. <= /div>

From: Ericsson <acee.lindem@ericsson.com>
Date: Sunday, April 7, 2013 11:52 A= M
To: OSPF List <ospf@ietf.org>
Subject: [OSPF] Use of OSPF-MDR in = Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-mdr-01.txt= 

All,=20

I'd like to start a 2 week WG last call on the subject document. The last c=
all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen=
t and send any comments to the list prior to that time. Here is a URL for y=
our convenience:=20

https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-m=
dr/

Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_-- --_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Sat, 04 May 2013 21:51:40 GMT"; modification-date="Sat, 04 May 2013 21:51:40 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9TUEYgbWFp bGluZyBsaXN0DQpPU1BGQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29zcGYNCg== --_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9C0eusaamb101ericsso_-- From prvs=1836719a47=acee.lindem@ericsson.com Sat May 4 14:53:21 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B1D21F9697 for ; Sat, 4 May 2013 14:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 6WsinWpcsSXH for ; Sat, 4 May 2013 14:53:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7CD21F8A81 for ; Sat, 4 May 2013 14:53:12 -0700 (PDT) X-AuditID: c6180641-b7f906d000003e3f-cb-5185834707b5 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F3.D8.15935.74385815; Sat, 4 May 2013 23:53:12 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Sat, 4 May 2013 17:53:11 -0400 From: Acee Lindem To: "ospf@ietf.org" Thread-Topic: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 Thread-Index: AQHOM8Gc6vHOR6/qzkik1EPe4A1EDpj1ibmA Date: Sat, 4 May 2013 21:53:10 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4713A9D3@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE471103A7@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/mixed; boundary="_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyuXSPn65Hc2ugwdcNbBYt9+6xWyzf94vJ gcljyu+NrB5LlvxkCmCK4rZJSiwpC85Mz9O3S+DOaPq4kLHguULF/vMzWRsYT8t0MXJySAiY SNxc0MsEYYtJXLi3nq2LkYtDSOAoo8SR1pnsEM4yRolTPZ/AqtgEdCSeP/rHDGKLCChLbNnb D9TBwcEsICOx7UoSSFhYoF7i7pMNrCC9IgINjBL3+3ezQdQbSbRuPsMCYrMIqEjMPrYebA6v gLfE+571YPM5BXwk1r7qYwSxGYEu+n5qDVicWUBc4taT+VCXikg8vHiaDcIWlXj5+B8riC0q oCfRduwMO0RcWeL7nEcsEL2ZEts63jJB7BKUODnzCcsERtFZSMbOQlI2C0kZRDxf4sjXNcwQ to7Egt2f2CBsbYllC18zw9hnDjyGmmMtsfP3LSZMNboSR84fY4ewFSXatjdDzVnBKLFtgj9M 76cHZ+FqpnQ/ZF/AyLeKkaO0OLUsN93IcBMjMAEck2Bz3MG44JPlIUZpDhYlcd5ErsZAIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJwggkuqgfHgyXuv+x+o7T/avsmiZO3aGRVMvsdPxzzzrLLz 6JS0XRsVeP40//QXz+7pTbwq4xO0YUrC6bCb070W+sVPWBi7stRD5FrCkee+CnfVVNfJLPVQ kZLreXV7O9Phxyo+ZcEmc/7Hr2tg+a7jXveDr++R4XOuu5pBVXk7n3LeY/3DYvNp/Z5HfxqU WIozEg21mIuKEwEy+Wla0wIAAA== Subject: [OSPF] FW: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 21:53:21 -0000 --_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_ Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_" --_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WG last call for the subject document has completed. It will go to the = ADs for review once the shepherding writeup is complete. Yi Yang has consen= ted to be the document shepherd. Thanks, Acee From: Ericsson > Date: Sunday, April 7, 2013 11:56 AM To: OSPF List > Subject: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Net= works - draft-ietf-ospf-manet-single-hop-or-01 All, I'd like to start a 2 week WG last call on the subject document. The last c= all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen= t and send any comments to the list prior to that time. Here is a URL for y= our convenience: Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <2F48D589994E004CA05E9B2A5DC30927@ericsson.com> Content-Transfer-Encoding: quoted-printable
The WG last call for the subject document has completed. It will go to= the ADs for review once the shepherding writeup is complete. Yi Yang has c= onsented to be the document shepherd. 
Thanks,
Acee 

From: Ericsson <acee.lindem@ericsson.com>
Date: Sunday, April 7, 2013 11:56 A= M
To: OSPF List <ospf@ietf.org>
Subject: [OSPF] Use of the OSPF-MAN= ET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-singl= e-hop-or-01

All,=20

I'd like to start a 2 week WG last call on the subject document. The last c=
all will end at 12:00 AM PDT on April 29th, 2012. Please review the documen=
t and send any comments to the list prior to that time. Here is a URL for y=
our convenience:=20



Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_-- --_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Sat, 04 May 2013 21:53:10 GMT"; modification-date="Sat, 04 May 2013 21:53:10 GMT" Content-ID: <68416481CD00BA4DBFE91C3F6D3FC596@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9TUEYgbWFp bGluZyBsaXN0DQpPU1BGQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29zcGYNCg== --_004_94A203EA12AECE4BA92D42DBFFE0AE4713A9D3eusaamb101ericsso_-- From ppsenak@cisco.com Sun May 5 01:47:58 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100DB21F8693 for ; Sun, 5 May 2013 01:47:58 -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 6fBxZtnLyX7t for ; Sun, 5 May 2013 01:47:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9421F8675 for ; Sun, 5 May 2013 01:47:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r458loLt011722 for ; Sun, 5 May 2013 10:47:50 +0200 (CEST) Received: from Peter-Psenaks-MacBook-Pro.local ([10.61.214.38]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r458liIu010224; Sun, 5 May 2013 10:47:45 +0200 (CEST) Message-ID: <51861CB0.4060700@cisco.com> Date: Sun, 05 May 2013 10:47:44 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Acee Lindem References: <5183B543.6000802@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4713954C@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4713954C@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 08:47:58 -0000 Hi Acee, let me start by saying that I fully support the effort to define extensible LSAs in OSPF. I also don't believe we need a new protocol version for it, nor that we need to address all the legacy in the protocol at this point. One piece I have a problem with is the backward compatibility. I don't think we can afford to introduce an extension to the protocol that is not backward compatible. I know it's easier for us who "write and maintain" the software to do it that way, but we have to look at it from the perspective of the users who have thousands of nodes running the current version of the protocol deployed. Using separate OSPFv3 routing domains during transition has significant impact on the network and brings a lot of complexity to the operational folks. I'm afraid the complexity associated with the backward compatibility would have to be incorporated in the protocol, not pushed to the user. Last, but not least, we have a similar requirements in OSPFv2. I'm in process of writing a draft which requires additional attributes to be flooded for link and prefix in v2. So the question is not if we want to do it for OSPFv2, but rather how do we want to do it for OSPFv2. We can not ask people in the field to migrate from v2 to v3, just because they want to deploy a new functionality that required few extra bytes for link/prefix to be flooded by OSPFv2. We have two possible approaches - define extended LSAs for v2, or take the path of the complementary LSAs, which would be used on top of existing LSAs and used to carry extra data for links/prefixes. I would like to get a sentiment of the OSPF IETF community on this. thanks, Peter On 3.5.2013 17:14, Acee Lindem wrote: > Hi Anton, > Thanks for introducing the draft - I had meant to do it but am chronically pressed for time. Here is the link: > > https://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend/ > > You are correct that the draft does require a deployment upgrade. A mixed deployment will require separate OSPFv3 routing domains and multiple OSPFv3 instances at least at the boundaries. The alternative was to require both the existing LSAs and the Extended-LSAs to be originated in mixed deployments. This adds quite a lot of complexity and will not be scalable in many networks. It is definitely possible but is the is the sort of backward compatibility mechanism people who don't write or maintain routing software propose. > > As far as calling it OSPFv4, I don't think we need to do this since only the encoding of the LSAs change. We were careful not to change the LSA semantics in the interest of rapid acceptance, implementation, and, hopefully, deployment. I believe the OSPFv3 moniker should be reserved for a version of the protocol with far more changes (including deprecation of virtual links ;^). > > Thanks, > Acee > > On May 3, 2013, at 9:01 AM, Anton Smirnov wrote: > >> Hi all, >> I saw this draft was published a few days ago and I wanted to discuss the approach taken by authors. In brief, this draft deeply changes OSPFv3 by totally reworking LSA encodings but stops short of calling it a new version of OSPF protocol. Per draft routers supporting new LSA encodings do not mix with RFC 5340 OSPFv3 routers and do not talk to them. So from deployment point of view section of the draft describing backward compatibility can be reduced to simply "Totally not backward compatible". >> >> I think no one will object that OSPFv3 rigid LSA format became big obstacle in introducing new features and even simply catching up with ISIS. >> I personally fully agree that OSPFv3 has to be deeply reworked. >> But in my opinion this draft is presenting OSPFv4 without calling it so - and carries into the new version of the protocol some outdated features of OSPFv2. >> Isn't it a time to admit that OSPFv3 is failure of epic proportions? And to admit that stance 'to introduce minimum changes into the protocol' taken when developing OSPFv3 architecture was deeply flawed, sacrificed long-term benefits of introducing new protocol version to short-term benefits of quick standardization and will continue causing difficulties unless addressed (with LSA encodings being the most obvious but not the only one)? >> >> -- >> Anton >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > From hannes@juniper.net Mon May 6 09:45:03 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2AB21F8EFD for ; Mon, 6 May 2013 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 0uUhTAcXBPXC for ; Mon, 6 May 2013 09:44:58 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id D67D221F912C for ; Mon, 6 May 2013 09:44:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUYfeBxagWLN9MyV14gcmCW5SxwEniNki@postini.com; Mon, 06 May 2013 09:44:55 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 May 2013 09:43:24 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 6 May 2013 09:43:24 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 May 2013 09:54:06 -0700 Received: from mail82-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 May 2013 16:43:21 +0000 Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id CDA9F8A0849 for ; Mon, 6 May 2013 16:43:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -31 X-BigFish: PS-31(zf7Iz9371I936eI1454Iec9I1432I72dMzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 1367858598786698_15254; Mon, 6 May 2013 16:43:18 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.245]) by mail82-co1.bigfish.com (Postfix) with ESMTP id BA5BB7C00AD; Mon, 6 May 2013 16:43:18 +0000 (UTC) Received: from BL2PRD0512HT002.namprd05.prod.outlook.com (157.56.242.197) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 May 2013 16:43:18 +0000 Received: from agalvin-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.35) with Microsoft SMTP Server (TLS) id 14.16.305.3; Mon, 6 May 2013 16:43:14 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1283) From: Hannes Gredler Date: Mon, 6 May 2013 18:43:08 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <9B23BF6F-9020-41CC-A8F4-56C2F97C2A65@juniper.net> References: <20130506163455.12024.14339.idtracker@ietfa.amsl.com> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%AMAZON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%VERIZON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LEVEL3.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Tom Scholl , Shane Amante , Luay Jalil Subject: [OSPF] Fwd: New Version Notification for draft-gredler-ospf-label-advertisement-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 16:45:03 -0000 Dear OSPF working group, have posted a new version of the OSPF label advertisement draft. the major changes between -00 to -02 are: -support for signaling Bypass (FRR) Labels -support for SPT labels using RFC4761 'VPLS' style label block advertisements. this is mainly to comply to RFC3031 which mandates that label allocation is a strict local procedure, and still not loose the comfort of getting an automatically provided transport mesh (similar to LDP). This provides similar functionality like first mentioned in http://tools.ietf.org/id/draft-tian-mpls-lsp-source-route-01.txt *without* the need of an RFC 3031 architectural violation. The advertised label blocks allow in addition to specify a particular rfc4195 topology-ID and an algorithm (e.g. SPT). we got feedback that having a pluggable algorithm (e.g., but not limited to: MRT) would solve a couple of practical use cases for 'infrastructure LSPs' in the area of make-before break, ordered FIB, etc. the authors are looking for feedback and suggested text changes to improve the draft. - please help us to make it better ;-) as a vehicle to foster open collaboration we are VCing our work in = github. feel free to clone the repository at: = https://github.com/hannesgredler/draft-gredler-ospf-label-advertisement.gi= t send us pull requests with your suggested changes (or diffs using = email); thanks, /hannes Begin forwarded message: > From: > Subject: New Version Notification for = draft-gredler-ospf-label-advertisement-02.txt > Date: May 6, 2013 6:34:55 PM GMT+02:00 > To: Tom Scholl , Hannes Gredler = , Shane Amante , Luay Jalil = >=20 >=20 > A new version of I-D, draft-gredler-ospf-label-advertisement-02.txt > has been successfully submitted by Hannes Gredler and posted to the > IETF repository. >=20 > Filename: draft-gredler-ospf-label-advertisement > Revision: 02 > Title: Advertising MPLS labels in OSPF > Creation date: 2013-05-06 > Group: Individual Submission > Number of pages: 27 > URL: = http://www.ietf.org/internet-drafts/draft-gredler-ospf-label-advertisement= -02.txt > Status: = http://datatracker.ietf.org/doc/draft-gredler-ospf-label-advertisement > Htmlized: = http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-gredler-ospf-label-advertisement-= 02 >=20 > Abstract: > Historically MPLS label distribution was driven by protocols like > LDP, RSVP and LBGP. All of those protocols are session oriented. = In > order to obtain label binding for a given destination FEC from a > given router one needs first to establish an LDP/RSVP/LBGP session > with that router. >=20 > Advertising MPLS labels in IGPs > [I-D.gredler-rtgwg-igp-label-advertisement] describes several use > cases where utilizing the flooding machinery of link-state protocols > for MPLS label distribution allows to obtain the binding without > requiring to establish an LDP/RSVP/LBGP session with that router. >=20 > This document describes the protocol extension to distribute MPLS > label bindings by the OSPFv2 and OSPFv3 protocol. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From asmirnov@cisco.com Tue May 7 01:44:18 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BF221F8FDC for ; Tue, 7 May 2013 01:44:18 -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 L4-o71Jtx3ma for ; Tue, 7 May 2013 01:44:13 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B413D21F8F62 for ; Tue, 7 May 2013 01:44:12 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r478i7pN013634; Tue, 7 May 2013 10:44:07 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r478hfEL018292; Tue, 7 May 2013 10:43:56 +0200 (CEST) Message-ID: <5188BEBD.6040805@cisco.com> Date: Tue, 07 May 2013 10:43:41 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4713A900@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4713A900@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 08:44:18 -0000 Hi Acee, introducing non-backward-compatible revision of protocol is very big deal both for vendors and customers. What I am vigorously objecting is approach of developing non-backward-compatible protocol revision with "minimum of changes" being the primary requirement. This almost guarantees end result to be inefficient. Protocol *extension* must be designed to be backward compatible even if that makes it very complex. That complexity should be addressed by major protocol *revision*. Work on major protocol revision should start from writing requirements document - and this stage alone should probably last couple of years. > Additionally, > history has proven that more focused work has a better chance of > reaching fruition. That's why burning need for new feature should not be mentioned while discussing non-backward-compatible protocol extension. Latter should be developed on its own. Anton On 05/04/2013 11:31 PM, Acee Lindem wrote: > Hi Anton, > If you look at the drafts Fred recently refreshed, I think you'll have to > agree that we have a burning requirement for this extension. Additionally, > history has proven that more focused work has a better chance of reaching > fruition. As for backward compatibly, it is possible to do something akin > to RFC 1793 and the original unpublished version of this draft contained > these mechanisms. However, it is not clear that the complexity justifies > the mechanisms - we'll leave that for the WG to decide. > Acee > P.S. To quote a philosopher of the late 20th century, "You can't always > get what you want. But if you try sometimes well you might find you get > what you need." > From acee.lindem@ericsson.com Thu May 9 11:03:24 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB01521F93A5 for ; Thu, 9 May 2013 11:03:24 -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 O0vLoOPEYN-T for ; Thu, 9 May 2013 11:03:19 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48F21F9378 for ; Thu, 9 May 2013 11:03:18 -0700 (PDT) X-AuditID: c6180641-b7f906d000003e3f-02-518be4e4c5a4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7D.BC.15935.4E4EB815; Thu, 9 May 2013 20:03:16 +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; Thu, 9 May 2013 14:03:15 -0400 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thread-Index: AQHOTNzGePD/nn9nkU6Nq3KyxwKnJpj9aEUA Date: Thu, 9 May 2013 18:03:14 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4713F940@eusaamb101.ericsson.se> References: <20130509174336.13252.85872.idtracker@ietfa.amsl.com> In-Reply-To: <20130509174336.13252.85872.idtracker@ietfa.amsl.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: <39332360BA8AE64DBF6F06EA6AB5BD55@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPt+6TJ92BBg+/SVjs2ido8fNLJ6tF y7177A7MHlN+b2T1aDnyltVjyZKfTAHMUVw2Kak5mWWpRfp2CVwZ3w59Yy24LFEx++EP5gbG buEuRk4OCQETiUffD7ND2GISF+6tZwOxhQSOMkos+RnTxcgFZC9jlPjy4xozSIJNQEfi+aN/ YLaIgKzE0iX7WUFsZoFEiWt/Z4ANEhbwljix7Qk7RI2PxIKV94BqOIBsI4nbNwJBwiwCKhIL OpaDtfIClV9eu4cFpERIwFFi2+9MkDCngJPEwiWvmEBsRqDTvp9awwSxSVzi1pP5TBAnC0gs 2XOeGcIWlXj5+B8rhK0sseTJfhaIeh2JBbs/sUHY1hLnLiyHsrUlli18zQxxgqDEyZlPWCYw is9CsmIWkvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I8NNjMAYOybB5riDccEny0OM0hwsSuK8 iVyNgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYrWT1FFxuvFm10FHPMdffpa/mwXG33qsG nts2BRUp+2YaO++50i65afnv6+4XvixQELU5cHVfVZJRwvvTLBb3Y195HC3+/qFBYLJs1HzX dJX3yhIypgJHbnmyr2W4qTiDV+eW1frZFe3MK/T0xVtq23mEnEz3/X+p/2v+LIto1zSpX0cm LJ+vxFKckWioxVxUnAgA4KaE3X8CAAA= Cc: Srinivasan K K L Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 18:03:24 -0000 There have been a couple errata filed on RFC 6505 (authors copied). As a se= rvice to the=20 OSPF community and in an effort to ensure interoperable OSPFv3 authenticati= on=20 trailer implementations, I have produced a BIS draft. The changes are liste= d in=20 section 1.2: 1.2. Summary of Changes from RFC 6506 This document includes the following changes from RFC 6506 [RFC6506]: 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling (LLS) block checksum calculation is omitted when an OSPFv3 authentication is used. The LLS block is included in the authentication digest calculation and computation of a checksum is unneccessary. Clarification of this issue was raised in an errata. 2. Section 4.5 includes a correction to the key preparation to use the protocol specific key (Ks) rather than the key (K) as the initial key (Ko). This problem was also raised in an errata. 3. Section 4.5 also includes a discussion of the choice of key length to be the hash length (L) rather than the block size (B). The discussion of this choice was included to clarify an issue raised in a rejected errata. 4. Section 4.1 indicates that sequence number checking is dependent on OSPFv3 packet type in order to account for packet prioritization as specified in [RFC4222]. This was an omission from RFC 6506. I would like to quickly move this to an OSPF WG document and begin the revi= ew process. I'm now soliciting feedback on OSPF WG adoption.=20 Thanks, Acee=20 On May 9, 2013, at 1:43 PM, wrote: >=20 > A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt > has been successfully submitted by Manav Bhatia and posted to the > IETF repository. >=20 > Filename: draft-acee-ospf-rfc6506bis > Revision: 01 > Title: Supporting Authentication Trailer for OSPFv3 > Creation date: 2013-05-09 > Group: Individual Submission > Number of pages: 25 > URL: http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6= 506bis-01.txt > Status: http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506b= is > Htmlized: http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospf-rfc65= 06bis-01 >=20 > Abstract: > Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism > for authenticating protocol packets. This behavior is different from > authentication mechanisms present in other routing protocols (OSPFv2, > Intermediate System to Intermediate System (IS-IS), RIP, and Routing > Information Protocol Next Generation (RIPng)). In some environments, > it has been found that IPsec is difficult to configure and maintain > and thus cannot be used. This document defines an alternative > mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does > not only depend upon IPsec for authentication. This document > obsoletes RFC 6506. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From yiya@cisco.com Fri May 17 07:12:42 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0280921F93AB for ; Fri, 17 May 2013 07:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SAVELE=2.3, MIME_BAD_LINEBREAK=0.5, 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 7XEk2R03OQif for ; Fri, 17 May 2013 07:12:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4F21F8B64 for ; Fri, 17 May 2013 07:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10406; q=dns/txt; s=iport; t=1368799954; x=1370009554; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=zjkwqqk7144Svc1U1GUlwbJKjYP33snxAOUBp0Hx9iw=; b=fbXX+h0yqmFPYh6lqF7QdTE5nw12j9sLjUX0wqbrU/2kcwSS4vNGzBqQ Nc48vbv8Hk/cEWVP2TDglLuWoKj/xQN5xHTJAZ0kXcFr2cbox9Ae47MBJ b+nk7Tdc8KcESYiiKTgXsfFLjVSqlgWb9mNvNyE7g63iM6QLw2PssgHTT w=; X-Files: ospf-wg-manet-single-hop-or-writeup.txt : 6287 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAIE5llGtJV2a/2dsb2JhbABRCoMIN8FcehZ0gh8BAQEEHU4HGQEIEQMBAgsZDTAdCAIEARIIAQUGh3gMvUyNUgsGgQsgGIJ0YQOPe5h9gViBOIFqBxcGGA X-IronPort-AV: E=Sophos;i="4.87,692,1363132800"; d="txt'?scan'208";a="211586009" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 17 May 2013 14:12:28 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4HECS6R011754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 14:12:28 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.69]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 17 May 2013 09:12:27 -0500 From: "Yi Yang (yiya)" To: Acee Lindem , "ospf@ietf.org" Thread-Topic: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 Thread-Index: AQHOM8Gc6vHOR6/qzkik1EPe4A1EDpj1ibmAgBQwo4A= Date: Fri, 17 May 2013 14:12:26 +0000 Message-ID: In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4713A9D3@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.95.113] Content-Type: multipart/mixed; boundary="_002_DC74E46E9699A84EB0E1183B90FD16091E8E6F51xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:12:42 -0000 --_002_DC74E46E9699A84EB0E1183B90FD16091E8E6F51xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-ID: <9E24B3DFCFEA494A9E011DA00AD6A300@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Acee, I have completed my shepherd writeup and I believe the document is ready for publication. Please see the attached for the writeup. Yi On 5/4/13 5:53 PM, "Acee Lindem" wrote: >The WG last call for the subject document has completed. It will go to >the ADs for review once the shepherding writeup is complete. Yi Yang has >consented to be the document shepherd. >Thanks, >Acee=20 > > >From: Ericsson >Date: Sunday, April 7, 2013 11:56 AM >To: OSPF List >Subject: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast >Networks - draft-ietf-ospf-manet-single-hop-or-01 > > > >>All,=20 >> >>I'd like to start a 2 week WG last call on the subject document. The >>last call will end at 12:00 AM PDT on April 29th, 2012. Please review >>the document and send any comments to the list prior to that time. Here >>is a URL for your convenience: >> >> >> >>Thanks, >>Acee=20 >> >> --_002_DC74E46E9699A84EB0E1183B90FD16091E8E6F51xmbalnx09ciscoc_ Content-Type: text/plain; name="ospf-wg-manet-single-hop-or-writeup.txt" Content-Description: ospf-wg-manet-single-hop-or-writeup.txt Content-Disposition: attachment; filename="ospf-wg-manet-single-hop-or-writeup.txt"; size=6287; creation-date="Fri, 17 May 2013 14:12:26 GMT"; modification-date="Fri, 17 May 2013 14:12:26 GMT" Content-ID: <1F183C76D1F9B24E955815A4A7E0471D@emea.cisco.com> Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA1JbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyAgSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gDXRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NDSAgICAg RXhwZXJpbWVudGFsLiANICAgICANICAgICBBcyBhbiB1cGRhdGUgb2YgUkZDNTgyMCwgYW4gRXhw ZXJpbWVudGFsIFJGQywgaXQncyBqdXN0aWZpZWQgdG8gDSAgICAgY2F0ZWdvcml6ZSB0aGlzIGRy YWZ0IGFzIEV4cGVyaW1lbnRhbC4gDQ0oMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50 IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50DVdyaXRlLVVwLiBQbGVhc2UgcHJvdmlk ZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNlbnQNZXhhbXBsZXMg Y2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZA1k b2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyBzZWN0aW9uczoNDSAgICAgVGVjaG5pY2FsIFN1bW1hcnkgDQ0gICAgIFRoaXMgZHJhZnQgZGVz Y3JpYmVzIGhvdyB0byBzaW1wbGlmeS9vcHRpbWl6ZSBPU1BGLU1BTkVUIGludGVyZmFjZQ0gICAg IG9wZXJhdGlvbiwgb3JpZ2luYWxseSBzcGVjaWZpZWQgaW4gUkZDNTgyMCwgaW4gc2luZ2xlLWhv cCBicm9hZGNhc3QNICAgICBuZXR3b3Jrcy4NICAgICANICAgICBXb3JraW5nIEdyb3VwIFN1bW1h cnkgDQ0gICAgIFRoZSBpbml0aWFsIGRyYWZ0IHdhcyBwcmVzZW50ZWQgdG8gSUVURiBhYm91dCB0 d28geWVhcnMgYWdvLCBhbmQNICAgICB0aGVyZSB3ZXJlIHNvbWUgY29tbWVudHMvZGlzY3Vzc2lv biBvbiBlbWFpbCBhbGlhcyBhdCB0aGF0IHRpbWUuIA0gICAgIFRoZXJlIGhhdmUgYmVlbiBubyBm dXJ0aGVyIGRpc2N1c3Npb25zIHNpbmNlIHRoZW4uDQ0gICAgIERvY3VtZW50IFF1YWxpdHkgDQ0g ICAgIFRoZSBkb2N1bWVudCBoYXMgZ29uZSB0aHJvdWdoIHNldmVyYWwgV0cgcmV2aWV3IGN5Y2xl cyBhbmQgDSAgICAgcmV2aXNpb25zLiBDb21tZW50cyB3ZXJlIHJlY2VpdmVkIGZyb20gc29tZSBX RyBtZW1iZXJzLiBUbyB0aGUgYmVzdCANICAgICBvZiBteSBrbm93bGVkZ2UsIHRoZXJlIGFyZSBu byBpbXBsZW1lbnRhdGlvbnMuICANDSAgICAgUGVyc29ubmVsICAgICAgDQ0gICAgIFlpIFlhbmcg aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCBTdGV3YXJ0IEJyeWFudCBpcyB0aGUgDSAgICAg cmVzcG9uc2libGUgQUQuIA0NKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhlIHJldmlldyBvZiB0aGlz IGRvY3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ10aGUgRG9jdW1lbnQgU2hlcGhlcmQuICBJ ZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IGlzIG5vdCByZWFkeQ1mb3IgcHVibGljYXRp b24sIHBsZWFzZSBleHBsYWluIHdoeSB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgZm9yd2FyZGVkIHRv DXRoZSBJRVNHLg0NICAgIEkgd2FzIGFza2VkIGJ5IE9TUEYgV0cgY2hhaXIgdG8gcmV2aWV3IHRo ZSBkb2N1bWVudCBhcyB0aGUgRG9jdW1lbnQNICAgIFNoZXBoZXJkLiBJIHJlYWQgdGhyb3VnaCB0 aGUgZG9jdW1lbnQsIHRyYWNrZWQgdGhlIGRpc2N1c3Npb24gb24gDSAgICBlbWFpbCBhbGlhcywg YW5kIGNvbW11bmljYXRlZCB3aXRoIGF1dGhvcnMuIEkgYmVsaWV2ZSB0aGUgZG9jdW1lbnQNICAg IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gDQ0NKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBo ZXJkIGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvcg1icmVhZHRoIG9mIHRoZSBy ZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gDQ0gICAgTm8uIA0NDSg1KSBEbyBwb3J0 aW9ucyBvZiB0aGUgZG9jdW1lbnQgbmVlZCByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3IgZnJv bQ1icm9hZGVyIHBlcnNwZWN0aXZlLCBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxl eGl0eSwgQUFBLCBETlMsDURIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/IElmIHNv LCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXQNdG9vayBwbGFjZS4NDSAgICBOby4NDSg2KSBEZXNj cmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNo ZXBoZXJkDWhhcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJlYSBE aXJlY3RvciBhbmQvb3IgdGhlDUlFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhhbXBsZSwg cGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZQ13aXRoIGNlcnRhaW4gcGFydHMgb2Yg dGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkNaXMgYSBu ZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCBpZiB0aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgaGFz DWRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3 aXNoZXMgdG8gYWR2YW5jZQ10aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZSBjb25jZXJucyBoZXJl Lg0NICAgTm9uZS4gDQ0oNykgSGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQg YWxsIGFwcHJvcHJpYXRlIElQUg1kaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OA1hbmQgQkNQIDc5IGhhdmUgYWxyZWFk eSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5Lg0NICAgWWVzLiAgIA0NKDgpIEhhcyBh biBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50 Pw1JZiBzbywgc3VtbWFyaXplIGFueSBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIHJlZ2FyZGlu ZyB0aGUgSVBSDWRpc2Nsb3N1cmVzLiAgICANDSAgICBOby4gDQ0oOSkgSG93IHNvbGlkIGlzIHRo ZSBjb25zZW5zdXMgb2YgdGhlIGludGVyZXN0ZWQgY29tbXVuaXR5IGJlaGluZCB0aGlzDWRvY3Vt ZW50PyBEb2VzIGl0IHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGlu ZGl2aWR1YWxzLA13aXRoIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIGludGVyZXN0 ZWQgY29tbXVuaXR5IGFzIGEgd2hvbGUNdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8gDQ0g ICBUaGVyZSBpcyBubyBvcHBvc2l0aW9uIHRvIHRoZSBkcmFmdC4gVGhvc2Ugd2hvIHVuZGVyc3Rh bmQNICAgdGhlIE1BTkVUIHVzZSBjYXNlcywgZmVlbCB0aGlzIGlzIGEgdmlhYmxlIGFwcGxpY2F0 aW9uIHRvIG9wdGltaXplDSAgIE1BTkVUIG9wZXJhdGlvbnMgaW4gc2luZ2xlLWhvcCBicm9hZGNh c3QgbmV0d29ya3MuIA0NKDEwKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90 aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSANZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1t YXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlDWVtYWlsIG1lc3NhZ2VzIHRv IHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGENc2VwYXJh dGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxl LikgDSANICAgTm8uIA0NKDExKSBJZGVudGlmeSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQgU2hl cGhlcmQgaGFzIGZvdW5kIGluIHRoaXMNZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9y Zy90b29scy9pZG5pdHMvIGFuZCB0aGUgSW50ZXJuZXQtRHJhZnRzDUNoZWNrbGlzdCkuIEJvaWxl cnBsYXRlIGNoZWNrcyBhcmUgbm90IGVub3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZQ10aG9y b3VnaC4NDSAgIEFsbCBhcHBsaWNhYmxlIGlkbml0cyBlcnJvcnMgYW5kIHdhcm5pbmdzIGhhdmUg YmVlbiByZXNvbHZlZC4NDQ0oMTIpIERlc2NyaWJlIGhvdyB0aGUgZG9jdW1lbnQgbWVldHMgYW55 IHJlcXVpcmVkIGZvcm1hbCByZXZpZXcNY3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0b3Is IG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0NICAgTm90IGFwcGxpY2FibGUuIA0N KDEzKSBIYXZlIGFsbCByZWZlcmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRp ZmllZCBhcw1laXRoZXIgbm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPw0NICAgWWVzLg0NKDE0KSBB cmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCBy ZWFkeSBmb3INYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRl PyBJZiBzdWNoIG5vcm1hdGl2ZQ1yZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSBwbGFuIGZv ciB0aGVpciBjb21wbGV0aW9uPw0NICAgIE5vLiANDSgxNSkgQXJlIHRoZXJlIGRvd253YXJkIG5v cm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVyZW5jZXMgKHNlZSBSRkMgMzk2Nyk/DUlmIHNvLCBsaXN0 IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydCB0aGUgQXJlYSBEaXJlY3RvciBp bg10aGUgTGFzdCBDYWxsIHByb2NlZHVyZS4NDSAgICBOby4NDSgxNikgV2lsbCBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50IGNoYW5nZSB0aGUgc3RhdHVzIG9mIGFueSBleGlzdGluZw1SRkNz PyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQgb24gdGhlIHRpdGxlIHBhZ2UgaGVhZGVyLCBsaXN0ZWQg aW4gdGhlDWFic3RyYWN0LCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRo ZSBSRkNzIGFyZSBub3QgbGlzdGVkDWluIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uLCBl eHBsYWluIHdoeSwgYW5kIHBvaW50IHRvIHRoZSBwYXJ0IG9mDXRoZSBkb2N1bWVudCB3aGVyZSB0 aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9jdW1lbnQgdG8gdGhlIG90aGVyIFJGQ3MNaXMgZGlz Y3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsIGV4cGxh aW4gd2h5DXRoZSBpbnRlcmVzdGVkIGNvbW11bml0eSBjb25zaWRlcnMgaXQgdW5uZWNlc3Nhcnku DQ0gICAgTm8uIA0NKDE3KSBEZXNjcmliZSB0aGUgRG9jdW1lbnQgU2hlcGhlcmQncyByZXZpZXcg b2YgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMNc2VjdGlvbiwgZXNwZWNpYWxseSB3aXRoIHJlZ2Fy ZCB0byBpdHMgY29uc2lzdGVuY3kgd2l0aCB0aGUgYm9keSBvZiB0aGUNZG9jdW1lbnQuIENvbmZp cm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHRoZSBkb2N1bWVudCBtYWtlcw1h cmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSByZXNlcnZhdGlvbnMgaW4gSUFOQSBy ZWdpc3RyaWVzLg1Db25maXJtIHRoYXQgYW55IHJlZmVyZW5jZWQgSUFOQSByZWdpc3RyaWVzIGhh dmUgYmVlbiBjbGVhcmx5DWlkZW50aWZpZWQuIENvbmZpcm0gdGhhdCBuZXdseSBjcmVhdGVkIElB TkEgcmVnaXN0cmllcyBpbmNsdWRlIGENZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgaW5p dGlhbCBjb250ZW50cyBmb3IgdGhlIHJlZ2lzdHJ5LCB0aGF0DWFsbG9jYXRpb25zIHByb2NlZHVy ZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zIGFyZSBkZWZpbmVkLCBhbmQgYQ1yZWFzb25hYmxl IG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnkgaGFzIGJlZW4gc3VnZ2VzdGVkIChzZWUgUkZDIDUy MjYpLg0NICAgIFRoaXMgZG9jdW1lbnQgZG9lc24ndCByZXF1aXJlIGFueSBJQU5BIGFjdGlvbnMu DQ0oMTgpIExpc3QgYW55IG5ldyBJQU5BIHJlZ2lzdHJpZXMgdGhhdCByZXF1aXJlIEV4cGVydCBS ZXZpZXcgZm9yIGZ1dHVyZQ1hbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNl IHRoYXQgdGhlIElFU0cgd291bGQgZmluZA11c2VmdWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5BIEV4 cGVydHMgZm9yIHRoZXNlIG5ldyByZWdpc3RyaWVzLg0NICAgICBOb25lLiAgDQ0NKDE5KSBEZXNj cmliZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZvcm1lZCBieSB0byB2YWxpZGF0 ZQ1zZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwg c3VjaCBhcyBYTUwgY29kZSwNQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4NDSAgICAg Tm90IEFwcGxpY2FibGUuIA0= --_002_DC74E46E9699A84EB0E1183B90FD16091E8E6F51xmbalnx09ciscoc_-- From acee.lindem@ericsson.com Thu May 23 05:06:35 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AD721F9354 for ; Thu, 23 May 2013 05:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, MIME_BAD_LINEBREAK=0.5] 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 ODgDbuMIGBVg for ; Thu, 23 May 2013 05:06:29 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC28221F8F00 for ; Thu, 23 May 2013 05:06:26 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-b2-519e063eee35 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7B.DA.17121.E360E915; Thu, 23 May 2013 14:06:23 +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; Thu, 23 May 2013 08:06:22 -0400 From: Acee Lindem To: Stewart Bryant , Adrian Farrel Thread-Topic: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 Thread-Index: AQHOM8Gc6vHOR6/qzkik1EPe4A1EDpj1ibmAgBQwo4CACX0MgA== Date: Thu, 23 May 2013 12:06:22 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4714E1BF@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/mixed; boundary="_004_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyuXRPoK4927xAg2PnRSx+9Nxgtmi5d4/d omn/VzaLc0/nMFos3/eLyYHVY8rvjaweS5b8ZPJYsXklo0dD2zHWAJYoLpuU1JzMstQifbsE rozbfz+yF5zOrrh+6QlzA+O35C5GTg4JAROJ6ZuOskHYYhIX7q0Hsrk4hASOMkpsX36KFcJZ zigx5+dNFpAqNgEdieeP/jGD2CICPhIrp79lB7GZBRIlTj1pYgKxhQXqJS53XwNrFhFoYJS4 37+bDaLBSaL14yNGEJtFQFXi+8qlQM0cHLwC3hJr17qDhIWAZr48swSsnFPAV+La4/dg5YxA 130/tYYJYpe4xK0n85kgrhaReHjxNNQHohIvH/9jhbCVJb7PecQCUZ8psWtjK1g9r4CgxMmZ T1gmMIrOQjJqFpKyWUjKIOL5Eh9vtbBD2DoSC3Z/YoOwtSWWLXzNDGOfOfAYao61xNw/u7Co 8ZD4fPs7K4RtI3Gz7TzUzGOMEj1fnWF6b+yeD1WjKDGl+yH7Aka+VYwcpcWpZbnpRgabGIEJ 45gEm+4Oxj0vLQ8xSnOwKInztmpPDRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOEXD0+Xw 0SO7jVQXlKfJl4i0O36dcuFqwRs91biCoNzfD78y9S/Z0yB9RLnhumZGTByP8hXxa5dnB/ry 8E93M39zw/t3iYo20//KAq4IFoGrH7PFc16zLRFbHT3r1uH4HXwtj9/cLHH2DVu8N0Fc45nH je5nxQHsjw5sfuFolH4lScFaP+SOEktxRqKhFnNRcSIA22efKOYCAAA= Cc: OSPF List , RFC Editor Subject: Re: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks - draft-ietf-ospf-manet-single-hop-or-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:06:35 -0000 --_004_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_ Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_" --_000_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OSPF WG is requesting publication of "Use of the OSPF-MANET Interface= in Single-Hop Broadcast Networks" (draft-ietf-ospf-manet-single-hop-or-02)= . Yi Yang is acting a document shepherd and the attendant write-up is attac= hed. Thanks, Acee On May 17, 2013, at 10:12 AM, Yi Yang (yiya) wrote: > Hi Acee, > > I have completed my shepherd writeup and I believe the document is ready > for publication. Please see the attached for the writeup. > > Yi > > > > > On 5/4/13 5:53 PM, "Acee Lindem" wrote: > >> The WG last call for the subject document has completed. It will go to >> the ADs for review once the shepherding writeup is complete. Yi Yang has >> consented to be the document shepherd. >> Thanks, >> Acee >> >> >> From: Ericsson >> Date: Sunday, April 7, 2013 11:56 AM >> To: OSPF List >> Subject: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broadcast >> Networks - draft-ietf-ospf-manet-single-hop-or-01 >> >> >> >>> All, >>> >>> I'd like to start a 2 week WG last call on the subject document. The >>> last call will end at 12:00 AM PDT on April 29th, 2012. Please review >>> the document and send any comments to the list prior to that time. Here >>> is a URL for your convenience: >>> >>> >>> >>> Thanks, >>> Acee >>> >>> > > --_000_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <9C0F060D8F0F054B9F9AD2F7D877B70B@ericsson.com> Content-Transfer-Encoding: quoted-printable
The OSPF WG is requesting publication of &nbs= p; "Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks&q= uot; (draft-ietf-ospf-manet-single-hop-or-02). Yi Yang is acting a document= shepherd and the attendant write-up is attached. 
Thanks,
Acee

On May 17, 2013, at 10:12 AM, Yi Yang (yiya) wrote:

> Hi Acee,
>
> I have completed my shepherd writeup and I believe the document is rea= dy
> for publication. Please see the attached for the writeup.
>
> Yi
>
>
>
>
> On 5/4/13 5:53 PM, "Acee Lindem" <acee.lindem@ericsson.co= m> wrote:
>
>> The WG last call for the subject document has completed. It will g= o to
>> the ADs for review once the shepherding writeup is complete. Yi Ya= ng has
>> consented to be the document shepherd.
>> Thanks,
>> Acee
>>
>>
>> From: Ericsson <acee.lindem@ericsson.com>
>> Date: Sunday, April 7, 2013 11:56 AM
>> To: OSPF List <ospf@ietf.org>
>> Subject: [OSPF] Use of the OSPF-MANET Interface in Single-Hop Broa= dcast
>> Networks - draft-ietf-ospf-manet-single-hop-or-01
>>
>>
>>
>>> All,
>>>
>>> I'd like to start a 2 week WG last call on the subject documen= t. The
>>> last call will end at 12:00 AM PDT on April 29th, 2012. Please= review
>>> the document and send any comments to the list prior to that t= ime. Here
>>> is a URL for your convenience:
>>>
>>>
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>
> <ospf-wg-manet-single-hop-or-writeup.txt>

--_000_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_-- --_004_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_ Content-Type: text/plain; name="ospf-wg-manet-single-hop-or-writeup.txt" Content-Description: ospf-wg-manet-single-hop-or-writeup.txt Content-Disposition: attachment; filename="ospf-wg-manet-single-hop-or-writeup.txt"; size=6411; creation-date="Thu, 23 May 2013 12:06:22 GMT"; modification-date="Thu, 23 May 2013 12:06:22 GMT" Content-ID: <3C8D221E3ACC924F9C13E525BF3A0E8B@ericsson.com> Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA1JbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyAgSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gDXRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NDSAgICAg RXhwZXJpbWVudGFsLiANICAgICANICAgICBBcyBhbiB1cGRhdGUgb2YgUkZDNTgyMCwgYW4gRXhw ZXJpbWVudGFsIFJGQywgaXQncyBqdXN0aWZpZWQgdG8gDSAgICAgY2F0ZWdvcml6ZSB0aGlzIGRy YWZ0IGFzIEV4cGVyaW1lbnRhbC4gDQ0oMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50 IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50DVdyaXRlLVVwLiBQbGVhc2UgcHJvdmlk ZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNlbnQNZXhhbXBsZXMg Y2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZA1k b2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyBzZWN0aW9uczoNDSAgICAgVGVjaG5pY2FsIFN1bW1hcnkgDQ0gICAgIFRoaXMgZHJhZnQgZGVz Y3JpYmVzIGhvdyB0byBzaW1wbGlmeS9vcHRpbWl6ZSBPU1BGLU1BTkVUIGludGVyZmFjZQ0gICAg IG9wZXJhdGlvbiwgb3JpZ2luYWxseSBzcGVjaWZpZWQgaW4gUkZDNTgyMCwgaW4gc2luZ2xlLWhv cCBicm9hZGNhc3QNICAgICBuZXR3b3Jrcy4NICAgICANICAgICBXb3JraW5nIEdyb3VwIFN1bW1h cnkgDQ0gICAgIFRoZSBpbml0aWFsIGRyYWZ0IHdhcyBwcmVzZW50ZWQgdG8gSUVURiBhYm91dCB0 d28geWVhcnMgYWdvLCBhbmQNICAgICB0aGVyZSB3ZXJlIHNvbWUgY29tbWVudHMvZGlzY3Vzc2lv biBvbiBlbWFpbCBhbGlhcyBhdCB0aGF0IHRpbWUuIA0gICAgIFRoZXJlIGhhdmUgYmVlbiBubyBm dXJ0aGVyIGRpc2N1c3Npb25zIHNpbmNlIHRoZW4uDQ0gICAgIERvY3VtZW50IFF1YWxpdHkgDQ0g ICAgIFRoZSBkb2N1bWVudCBoYXMgZ29uZSB0aHJvdWdoIHNldmVyYWwgV0cgcmV2aWV3IGN5Y2xl cyBhbmQgDSAgICAgcmV2aXNpb25zLiBDb21tZW50cyB3ZXJlIHJlY2VpdmVkIGZyb20gc29tZSBX RyBtZW1iZXJzLiBUbyB0aGUgYmVzdCANICAgICBvZiBteSBrbm93bGVkZ2UsIHRoZXJlIGFyZSBu byBpbXBsZW1lbnRhdGlvbnMuICANDSAgICAgUGVyc29ubmVsICAgICAgDQ0gICAgIFlpIFlhbmcg aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCBTdGV3YXJ0IEJyeWFudCBpcyB0aGUgDSAgICAg cmVzcG9uc2libGUgQUQuIA0NKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhlIHJldmlldyBvZiB0aGlz IGRvY3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ10aGUgRG9jdW1lbnQgU2hlcGhlcmQuICBJ ZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IGlzIG5vdCByZWFkeQ1mb3IgcHVibGljYXRp b24sIHBsZWFzZSBleHBsYWluIHdoeSB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgZm9yd2FyZGVkIHRv DXRoZSBJRVNHLg0NICAgIEkgd2FzIGFza2VkIGJ5IE9TUEYgV0cgY2hhaXIgdG8gcmV2aWV3IHRo ZSBkb2N1bWVudCBhcyB0aGUgRG9jdW1lbnQNICAgIFNoZXBoZXJkLiBJIHJlYWQgdGhyb3VnaCB0 aGUgZG9jdW1lbnQsIHRyYWNrZWQgdGhlIGRpc2N1c3Npb24gb24gDSAgICBlbWFpbCBhbGlhcywg YW5kIGNvbW11bmljYXRlZCB3aXRoIGF1dGhvcnMuIEkgYmVsaWV2ZSB0aGUgZG9jdW1lbnQNICAg IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gDQ0NKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBo ZXJkIGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvcg1icmVhZHRoIG9mIHRoZSBy ZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gDQ0gICAgTm8uIA0NDSg1KSBEbyBwb3J0 aW9ucyBvZiB0aGUgZG9jdW1lbnQgbmVlZCByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3IgZnJv bQ1icm9hZGVyIHBlcnNwZWN0aXZlLCBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxl eGl0eSwgQUFBLCBETlMsDURIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/IElmIHNv LCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXQNdG9vayBwbGFjZS4NDSAgICBOby4NDSg2KSBEZXNj cmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNo ZXBoZXJkDWhhcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJlYSBE aXJlY3RvciBhbmQvb3IgdGhlDUlFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhhbXBsZSwg cGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZQ13aXRoIGNlcnRhaW4gcGFydHMgb2Yg dGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkNaXMgYSBu ZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCBpZiB0aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgaGFz DWRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3 aXNoZXMgdG8gYWR2YW5jZQ10aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZSBjb25jZXJucyBoZXJl Lg0NICAgTm9uZS4gDQ0oNykgSGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQg YWxsIGFwcHJvcHJpYXRlIElQUg1kaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OA1hbmQgQkNQIDc5IGhhdmUgYWxyZWFk eSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5Lg0NICAgWWVzLiAgIA0NKDgpIEhhcyBh biBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50 Pw1JZiBzbywgc3VtbWFyaXplIGFueSBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIHJlZ2FyZGlu ZyB0aGUgSVBSDWRpc2Nsb3N1cmVzLiAgICANDSAgICBOb25lIG90aGVyIHRoYW4gcHJldmlvdXNs eSBkaXNjbG9zZWQgZm9yIFJGQyA1ODIwLiANDSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2lwci9zZWFyY2gvP29wdGlvbj1yZmNfc2VhcmNoJnJmY19zZWFyY2g9NTgyMA0NKDkpIEhvdyBz b2xpZCBpcyB0aGUgY29uc2Vuc3VzIG9mIHRoZSBpbnRlcmVzdGVkIGNvbW11bml0eSBiZWhpbmQg dGhpcw1kb2N1bWVudD8gRG9lcyBpdCByZXByZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBv ZiBhIGZldyBpbmRpdmlkdWFscywNd2l0aCBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRo ZSBpbnRlcmVzdGVkIGNvbW11bml0eSBhcyBhIHdob2xlDXVuZGVyc3RhbmQgYW5kIGFncmVlIHdp dGggaXQ/IA0NICAgVGhlcmUgaXMgbm8gb3Bwb3NpdGlvbiB0byB0aGUgZHJhZnQuIFRob3NlIHdo byB1bmRlcnN0YW5kDSAgIHRoZSBNQU5FVCB1c2UgY2FzZXMsIGZlZWwgdGhpcyBpcyBhIHZpYWJs ZSBhcHBsaWNhdGlvbiB0byBvcHRpbWl6ZQ0gICBNQU5FVCBvcGVyYXRpb25zIGluIHNpbmdsZS1o b3AgYnJvYWRjYXN0IG5ldHdvcmtzLiANDSgxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFw cGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUgDWRpc2NvbnRlbnQ/IElmIHNvLCBw bGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25mbGljdCBpbiBzZXBhcmF0ZQ1lbWFpbCBt ZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBp biBhDXNlcGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzIHB1YmxpY2x5 IGF2YWlsYWJsZS4pIA0gDSAgIE5vLiANDSgxMSkgSWRlbnRpZnkgYW55IElEIG5pdHMgdGhlIERv Y3VtZW50IFNoZXBoZXJkIGhhcyBmb3VuZCBpbiB0aGlzDWRvY3VtZW50LiAoU2VlIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLyBhbmQgdGhlIEludGVybmV0LURyYWZ0cw1DaGVja2xp c3QpLiBCb2lsZXJwbGF0ZSBjaGVja3MgYXJlIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMg dG8gYmUNdGhvcm91Z2guDQ0gICBBbGwgYXBwbGljYWJsZSBpZG5pdHMgZXJyb3JzIGFuZCB3YXJu aW5ncyBoYXZlIGJlZW4gcmVzb2x2ZWQuDQ0NKDEyKSBEZXNjcmliZSBob3cgdGhlIGRvY3VtZW50 IG1lZXRzIGFueSByZXF1aXJlZCBmb3JtYWwgcmV2aWV3DWNyaXRlcmlhLCBzdWNoIGFzIHRoZSBN SUIgRG9jdG9yLCBtZWRpYSB0eXBlLCBhbmQgVVJJIHR5cGUgcmV2aWV3cy4NDSAgIE5vdCBhcHBs aWNhYmxlLiANDSgxMykgSGF2ZSBhbGwgcmVmZXJlbmNlcyB3aXRoaW4gdGhpcyBkb2N1bWVudCBi ZWVuIGlkZW50aWZpZWQgYXMNZWl0aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8NDSAgIFll cy4NDSgxNCkgQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0 IGFyZSBub3QgcmVhZHkgZm9yDWFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5j bGVhciBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUNcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0 aGUgcGxhbiBmb3IgdGhlaXIgY29tcGxldGlvbj8NDSAgICBOby4gDQ0oMTUpIEFyZSB0aGVyZSBk b3dud2FyZCBub3JtYXRpdmUgcmVmZXJlbmNlcyByZWZlcmVuY2VzIChzZWUgUkZDIDM5NjcpPw1J ZiBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEg RGlyZWN0b3IgaW4NdGhlIExhc3QgQ2FsbCBwcm9jZWR1cmUuDQ0gICAgTm8uDQ0oMTYpIFdpbGwg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkgZXhp c3RpbmcNUkZDcz8gQXJlIHRob3NlIFJGQ3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRl ciwgbGlzdGVkIGluIHRoZQ1hYnN0cmFjdCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0 aW9uPyBJZiB0aGUgUkZDcyBhcmUgbm90IGxpc3RlZA1pbiB0aGUgQWJzdHJhY3QgYW5kIEludHJv ZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUgcGFydCBvZg10aGUgZG9jdW1l bnQgd2hlcmUgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzIGRvY3VtZW50IHRvIHRoZSBvdGhlciBS RkNzDWlzIGRpc2N1c3NlZC4gSWYgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgaW4gdGhlIGRvY3Vt ZW50LCBleHBsYWluIHdoeQ10aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgY29uc2lkZXJzIGl0IHVu bmVjZXNzYXJ5Lg0NICAgIE5vLiANDSgxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50IFNoZXBoZXJk J3MgcmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zDXNlY3Rpb24sIGVzcGVjaWFsbHkg d2l0aCByZWdhcmQgdG8gaXRzIGNvbnNpc3RlbmN5IHdpdGggdGhlIGJvZHkgb2YgdGhlDWRvY3Vt ZW50LiBDb25maXJtIHRoYXQgYWxsIHByb3RvY29sIGV4dGVuc2lvbnMgdGhhdCB0aGUgZG9jdW1l bnQgbWFrZXMNYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcmVzZXJ2YXRpb25z IGluIElBTkEgcmVnaXN0cmllcy4NQ29uZmlybSB0aGF0IGFueSByZWZlcmVuY2VkIElBTkEgcmVn aXN0cmllcyBoYXZlIGJlZW4gY2xlYXJseQ1pZGVudGlmaWVkLiBDb25maXJtIHRoYXQgbmV3bHkg Y3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhDWRldGFpbGVkIHNwZWNpZmljYXRpb24g b2YgdGhlIGluaXRpYWwgY29udGVudHMgZm9yIHRoZSByZWdpc3RyeSwgdGhhdA1hbGxvY2F0aW9u cyBwcm9jZWR1cmVzIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9ucyBhcmUgZGVmaW5lZCwgYW5kIGEN cmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IGhhcyBiZWVuIHN1Z2dlc3RlZCAo c2VlIFJGQyA1MjI2KS4NDSAgICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgcmVxdWlyZSBhbnkgSUFO QSBhY3Rpb25zLg0NKDE4KSBMaXN0IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWly ZSBFeHBlcnQgUmV2aWV3IGZvciBmdXR1cmUNYWxsb2NhdGlvbnMuIFByb3ZpZGUgYW55IHB1Ymxp YyBndWlkYW5jZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQNdXNlZnVsIGluIHNlbGVjdGluZyB0 aGUgSUFOQSBFeHBlcnRzIGZvciB0aGVzZSBuZXcgcmVnaXN0cmllcy4NDSAgICAgTm9uZS4gIA0N DSgxOSkgRGVzY3JpYmUgcmV2aWV3cyBhbmQgYXV0b21hdGVkIGNoZWNrcyBwZXJmb3JtZWQgYnkg dG8gdmFsaWRhdGUNc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWwg bGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsDUJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBl dGMuDQ0gICAgIE5vdCBBcHBsaWNhYmxlLiAN --_004_94A203EA12AECE4BA92D42DBFFE0AE4714E1BFeusaamb101ericsso_-- From iesg-secretary@ietf.org Thu May 23 08:27:07 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F8B21F9608; Thu, 23 May 2013 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZDr+fRvXMI97; Thu, 23 May 2013 08:27:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9BD11E8155; Thu, 23 May 2013 08:27:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523152703.20673.30375.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 08:27:03 -0700 Cc: ospf mailing list , ospf chair , RFC Editor Subject: [OSPF] Document Action: 'OSPF Stub Router Advertisement' to Informational RFC (draft-ietf-ospf-rfc3137bis-04.txt) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:27:07 -0000 The IESG has approved the following document: - 'OSPF Stub Router Advertisement' (draft-ietf-ospf-rfc3137bis-04.txt) as Informational RFC This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc3137bis/ Technical Summary This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This document updates RFC3137 to include applicability to OSPFv3. Working Group Summary There were some noteworthy discussions around including an alternate solution in OSPFv3 which achieves some of the same goals as RFC3137. Authors added a section to capture the use of R-bit as a potential alternative solution. R-bit is part of base OSPFv3 (RFC2740). Document Quality The incremental update to RFC3137 are minimal and the application to OSPFv3 is identical to OSPFv2. Personnel Abhay Roy is the document shepherd and Stewart Bryant is the responsible AD. From iesg-secretary@ietf.org Thu May 23 08:43:33 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD0921F97A1; Thu, 23 May 2013 08:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yrOB0JFg4OMD; Thu, 23 May 2013 08:43:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE71721F97AB; Thu, 23 May 2013 08:43:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523154331.32197.59969.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 08:43:31 -0700 Cc: ospf mailing list , ospf chair , RFC Editor Subject: [OSPF] Protocol Action: 'OSPFv3 Instance ID Registry Update' to Proposed Standard (draft-ietf-ospf-ospfv3-iid-registry-update-04.txt) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:43:33 -0000 The IESG has approved the following document: - 'OSPFv3 Instance ID Registry Update' (draft-ietf-ospf-ospfv3-iid-registry-update-04.txt) as Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-iid-registry-update/ Technical Summary This draft modifies the "OSPFv3 Instand ID Address Family Values" IANA registry to have IDs 192-255 designated for "Private Use" as described in RFC 5226. Working Group Summary The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be "Routing for IPv4-embedded IPv6 Packets" - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt. Document Quality The document is short and to the point. It satisfies its intended purpose. Personnel Acee Lindem is the document shepherd and Stewart Bryant is the responsible AD. From Alan.Davey@metaswitch.com Thu May 30 04:29:25 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50AF21F9421 for ; Thu, 30 May 2013 04:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=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 ZrOTNx+9EjFL for ; Thu, 30 May 2013 04:29:21 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id B755C21F9436 for ; Thu, 30 May 2013 04:28:45 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 12:28:21 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0342.003; Thu, 30 May 2013 12:28:37 +0100 From: Alan Davey To: "draft-acee-ospfv3-lsa-extend@tools.ietf.org" Thread-Topic: [OSPF] draft-acee-ospfv3-lsa-extend-00 Thread-Index: Ac5dKNOXxrjjra7QRqKAriZTB+i9+Q== Date: Thu, 30 May 2013 11:28:37 +0000 Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.124] Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1A925ECENFICSMBX1datco_" MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: [OSPF] draft-acee-ospfv3-lsa-extend-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 11:29:26 -0000 --_000_C2EE31C852049D499842B19FC01C0804C1A925ECENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks I have read draft-acee-ospfv3-lsa-extend-00 and found it interesting. It i= s clearly non-back-compatible with existing implementations of OSPFv3, but = there is not much in the draft about the requirements. Could the authors p= lease give some more details on what is driving the need for the LSA extens= ions? As an aside, the draft does not appear on the WG's Documents page on the IE= TF site. Is this because the draft should have "ospf" in its title, that i= s, "draft-acee-ospf-ospfv3-lsa-extend"? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_C2EE31C852049D499842B19FC01C0804C1A925ECENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks

 

I have read draft-acee-ospfv3-lsa-extend-00 and foun= d it interesting.  It is clearly non-back-compatible with existing imp= lementations of OSPFv3, but there is not much in the draft about the requir= ements.  Could the authors please give some more details on what is driving the need for the LSA extensions?=

 

As an aside, the draft does not appear on the WGR= 17;s Documents page on the IETF site.  Is this because the draft shoul= d have “ospf” in its title, that is, “draft-acee-ospf-osp= fv3-lsa-extend”?

 

Regards

Alan Davey

 

Network = Technologies
Metaswitch Networks

 =

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com<= /a>

 

 

 

 

--_000_C2EE31C852049D499842B19FC01C0804C1A925ECENFICSMBX1datco_-- From lberger@labn.net Fri May 31 09:20:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE30721F859D for ; Fri, 31 May 2013 09:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, 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 qXDjCNL-XytX for ; Fri, 31 May 2013 09:20:18 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 0818F21F84A1 for ; Fri, 31 May 2013 09:20:14 -0700 (PDT) Received: (qmail 32373 invoked by uid 0); 31 May 2013 16:19:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 31 May 2013 16:19:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ydWKTmPaX403tAUpaTZaHJZHf7o275/TjwxIzPtLZ7A=; b=iK0ZqqwQN4u1pM+jqhy1ThySVAMORO0q75tXrAdoO1y1u48u4EkK5TXRBYz9e3SRdJjS5gZvSQLBgPwVSO7A8F6SA4FDvCghwwmVBApaUD2XX/2Ss9y9Sp4i2Z3caWc3; Received: from box313.bluehost.com ([69.89.31.113]:35737 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UiS3V-0006ve-DO; Fri, 31 May 2013 10:19:53 -0600 Message-ID: <51A8CDA9.3050909@labn.net> Date: Fri, 31 May 2013 12:19:53 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: OSPF WG List References: <51A8CB9D.40009@labn.net> In-Reply-To: <51A8CB9D.40009@labn.net> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <51A8CB9D.40009@labn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP WG Chairs Subject: [OSPF] Fwd: [CCAMP] 2nd WG Last Call: g709-framework, g709-info-model, ospf-g709v3, signaling-g709v3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 16:20:24 -0000 Hello, The last call just started in CCAMP may be of interest to some in this WG. Comments and discussion should be directed to the *CCAMP* WG mailing list. Much thanks, Lou CCAMP WG Co-Chair -------- Original Message -------- Subject: [CCAMP] 2nd WG Last Call: g709-framework, g709-info-model, ospf-g709v3, signaling-g709v3 Date: Fri, 31 May 2013 12:11:09 -0400 From: Lou Berger To: CCAMP This mail begins a 2nd two week working group last call on: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-12 (Informational) http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-08 (Informational) http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06 (Standards Track) http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-09 (Standards Track) This working group last call ends on June 16. Comments should be sent to the CCAMP mailing list. Please remember to include the technical basis for any comments. Please note that we're still missing an IPR statement on the 2nd draft. Any forthcoming publication request will be delayed by late IPR statements/disclosures. Thank you, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp