From nobody Tue Jul 1 14:01:03 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E181A0A85 for ; Tue, 1 Jul 2014 14:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2kGSEVY2nEw for ; Tue, 1 Jul 2014 14:00:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2111A0A84 for ; Tue, 1 Jul 2014 14:00:59 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-ee-53b2cd3e6b97 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BA.B4.25146.E3DC2B35; Tue, 1 Jul 2014 17:01:18 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 17:00:41 -0400 From: Acee Lindem To: OSPF List , Peter Psenak Thread-Topic: Comments draft-ietf-ospf-segment-routing-extensions-00.txt Thread-Index: AQHPlW+EvcsTnOwDzEu9lMZ/o5iqQA== Date: Tue, 1 Jul 2014 21:00:40 +0000 Message-ID: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPlK7d2U3BBqf+W1u03LvHbrFjdzub A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRfuASY8FPkYrH2zYwNzDuFOhi5OCQEDCR aFrO3cXICWSKSVy4t56ti5GLQ0jgKKPE2m2P2EASQgLLGCWm74kGsdkEdCSeP/rHDGKLCNhL XHp4kgnEFhZwkehuaGUBmSki4Clx9U0eRImexNWvE1lBbBYBFYlFU9eBlfMCta54vw5sDCPQ 3u+n1oDFmQXEJW49mc8EcY+AxJI955khbFGJl4//sULYShJzXl9jhqg3kHh/bj6UbS3xZ85E dghbW2LZwtfMELsEJU7OfMIygVFkFpIVs5C0z0LSPgtJ+ywk7QsYWVcxcpQWp5blphsZbmIE RsIxCTbHHYwLPlkeYhTgYFTi4X2wb1OwEGtiWXFl7iFGaQ4WJXFezep5wUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoY1QKPsbpva1S48/i5DEudaCAjx7utpeKvTzh0My/4+6X3yX+RQKFd rDpueyLFTjzy0Qw4EW+wXptJXG3Z87MsK30XbnV/xj438ZPVHsaNm45vsF73t11hcdvXuQcP zDXfbJSpHfRsz4XMbbNjZ1w97XgysPjNqSz+W0U9E49br7b+utv1Z0zldyWW4oxEQy3mouJE AK7Wna9lAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/f2uFb5piCK9_T7RO9N3pUUXrDXU Subject: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 21:01:01 -0000 Hi Peter,=20 I=92ve reviewed the OSPF Segment Routing WG draft and have some comments.=20 1. Can you describe the usage of algorithm in the Segment Routing do= main? An SR capable router advertises the algorithms it supports and an alg= orithm is associated with a Prefix-SID. However, the usage of this informat= ion is not described anywhere and it is guaranteed that there will be many= different interpretations.=20 2. The usage of the advertised Weight references the =93Segment Rout= ing Architecture=94. However, there is no description of weight usage there= . 3. Section 3.2 - the range advertisement seems a bit unnatural. Why = is it assumed that all the advertised ranges have the same size? It would s= eem more intuitive that individual ranges are defined by the tuple. =20 4. Section 4.2 - Can you please make the P-flag the NP-Flag since th= e set value indicates not to perform the PHP operation? If you want to keep= it the P-Flag, the set value should mean to perform the PHP. 5. Section 4.2 and 5.2 - The Segment Routing architecture defines ad= jacency SIDs as having local significance. Yet the L-Flag allows this to be= encoded as global. Similarly, it would seem that a prefix SID would norma= lly have global significance and local significance would be an exception (= e.g., possibly a loopback address accessible only from the advertising OSPF= router).=20 6. Section 4.2 - I really don=92t like having his sub-TLV redefine t= he subsuming top-level TLV as a range of prefixes of the same length rather= than a single prefix. Although this is my first serious reading of the dra= ft, this encoding seems really unwieldy and, in practice, I=92d expect the = range size always advertised as 1. We can discuss this more in Toronto.=20 7. Section 4.2 - Shouldn=92t the reference for the mapping server be= the =93Segment Routing Architecture=94 rather than the =93Segment Routing = Use Cases=94? In general, the usage of a mapping server and the scope of as= signment needs to be described better somewhere (not in the OSPF encoding d= ocument).=20 8. Section 6 - It would seem that an entity calculating a multi-area= SR path would need access to the topology for all the areas and the SID wo= uld need to be globally assigned? Right? So rules are primarily for the pop= ulation of the forwarding plane. Right?=20 9. Section 6.2 - In standard OSPF, inter-area summary propagation on= ly applies to inter-area routes learned over the backbone. Is this any diff= erent?=20 Thanks, Acee=20 =20 From nobody Wed Jul 2 04:35:21 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CABB1B28F3 for ; Wed, 2 Jul 2014 04:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bKzNvYtkfSv for ; Wed, 2 Jul 2014 04:35:06 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBE11A003B for ; Wed, 2 Jul 2014 04:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4391; q=dns/txt; s=iport; t=1404300905; x=1405510505; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+yU85ax87sHQ9pI8n/rxt9igphtiI8klLDiFV/FwWm0=; b=CDw6sHvm5SY6lLd0mkwFuD3DsPbztYp6qqhMXfV1HK05FribyNirvShp yKS9wUL0uk9TRhh7i3ovrtGfoiTTZoYuKZyEa1mWCqA/G//OFolwvJlit J1td011Jel7yNpX1bz9dD1HKoasVhZSsluDdR8eZY3016agfwFTtdlQcc M=; X-IronPort-AV: E=Sophos;i="5.01,587,1400025600"; d="scan'208";a="98196768" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Jul 2014 11:35:03 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s62BZ2wc004547; Wed, 2 Jul 2014 11:35:03 GMT Message-ID: <53B3EE66.90608@cisco.com> Date: Wed, 02 Jul 2014 13:35:02 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem , OSPF List , Stefano Previdi References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> In-Reply-To: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/QJFs6SMgp-HpK6X41dvA3iFEwGY Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Jul 2014 11:35:12 -0000 Hi Acee, please see inline: On 7/1/14 23:00 , Acee Lindem wrote: > Hi Peter, > > I’ve reviewed the OSPF Segment Routing WG draft and have some comments. > > 1. Can you describe the usage of algorithm in the Segment Routing domain? An SR capable router advertises the algorithms it supports and an algorithm is associated with a Prefix-SID. However, the usage of this information is not described anywhere and it is guaranteed that there will be many different interpretations. filsfils-spring-segment-routing-use-cases will be updated to include the usage of algorithm. > > 2. The usage of the advertised Weight references the “Segment Routing Architecture”. However, there is no description of weight usage there. weight is used for influencing load-balancing across multiple adj-sid's to the same node. filsfils-spring-segment-routing-use-cases will be updated to include the usage of weight. > > 3. Section 3.2 - the range advertisement seems a bit unnatural. Why is it assumed that all the advertised ranges have the same size? It would seem more intuitive that individual ranges are defined by the tuple. there is a typo in the text: "SID/Label Sub-TLV MAY appear multiple times" will be changed to "SID/Label Range TLV MAY appear multiple times", which I believe will address your comment. > > 4. Section 4.2 - Can you please make the P-flag the NP-Flag since the set value indicates not to perform the PHP operation? If you want to keep it the P-Flag, the set value should mean to perform the PHP. sure, will rename to NP-flag > > 5. Section 4.2 and 5.2 - The Segment Routing architecture defines adjacency SIDs as having local significance. Yet the L-Flag allows this to be encoded as global. Similarly, it would seem that a prefix SID would normally have global significance and local significance would be an exception (e.g., possibly a loopback address accessible only from the advertising OSPF router). the architectre draft will be corrected to reflect that both prefix-sid and adj-sid can be global or local. > > 6. Section 4.2 - I really don’t like having his sub-TLV redefine the subsuming top-level TLV as a range of prefixes of the same length rather than a single prefix. Although this is my first serious reading of the draft, this encoding seems really unwieldy and, in practice, I’d expect the range size always advertised as 1. We can discuss this more in Toronto. an example where the range would be more then 1 is a mapping server case. This helps you to advertise SIDs for loopback addresses of all routers in a non-SR capable part of the network, assuming they are allocated from the contiguous address space. Instead of advertising hundreds of mappings for each /32 address, you can compact it to a single advertisement. What you need in such case is component prefix/length plus the number of components - OSPF Extended Prefix TLV gives you the component info and Prefix SID Sub-TLV "Range Size' gives you the number of components. We could have defined a separate top level TLV in OSPF Extended Prefix LSA for the advertisement of range of components, but it looks to me that would be an overkill. Current encoding of Prefix SID Sub-TLV gives us all the flexibility we need. In addition it matches what ISIS has done. > > 7. Section 4.2 - Shouldn’t the reference for the mapping server be the “Segment Routing Architecture” rather than the “Segment Routing Use Cases”? In general, the usage of a mapping server and the scope of assignment needs to be described better somewhere (not in the OSPF encoding document). will fix the reference > > 8. Section 6 - It would seem that an entity calculating a multi-area SR path would need access to the topology for all the areas and the SID would need to be globally assigned? Right? correct. > So rules are primarily for the population of the forwarding plane. Right? for advertisement/propagation of SIDs and for forwarding plane programming. > > 9. Section 6.2 - In standard OSPF, inter-area summary propagation only applies to inter-area routes learned over the backbone. Is this any different? no, the mechanism is the same as for type-3s. thanks, Peter > > Thanks, > Acee > > > > . > From nobody Wed Jul 2 05:46:51 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6091A0087 for ; Wed, 2 Jul 2014 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfSqf6aRCGJe for ; Wed, 2 Jul 2014 05:46:47 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11661A005F for ; Wed, 2 Jul 2014 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2368; q=dns/txt; s=iport; t=1404305206; x=1405514806; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=5N1AGnK10cGVzgVIfXPC3b9sFphcBlwd7PE0ZBjok1c=; b=MhzwOnjDLewi9hBGMMYgWIIrQ+QdXOdXwQTswVMEx8EygtVmuEWo9zWD anLoe7xprfZlFrOgTteki+4NnYvM1tpMdIUmK58fFqviob11XKTu+B2dl GJ2yeu88pLyvedLCnbrhnKFrSzsWt8113YnrYedxa53AsUw6uo+0opTVo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0GAJz+s1OtJssW/2dsb2JhbABag1+DSKhDDwEBAQUBbplmAYEidYQDAQEBBCMVPwENBBwDAQIDAgUWCwICCQMCAQIBOwIIBgEMBgIBAQWIOQ2qQJswF4EshESJOQaCcYFMAQSabYFIhUWMfIIBgUQ7Lw X-IronPort-AV: E=Sophos;i="5.01,587,1400025600"; d="scan'208";a="102342213" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 Jul 2014 12:46:44 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s62CkhZQ007996; Wed, 2 Jul 2014 12:46:43 GMT Message-ID: <53B3FF33.1000109@cisco.com> Date: Wed, 02 Jul 2014 14:46:43 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: OSPF List , Acee Lindem References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> In-Reply-To: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/BKYyAJHKaP0N9fSGcU63dUt-Ry8 Subject: [OSPF] Fwd: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Jul 2014 12:46:49 -0000 Acee, WG, I have updated the OSPFv3 SR extension draft. Given that OSPFv2 SR extension draft has been accepted as a WG item, it would make a lot of sense to make the OSPFv3 SR draft WG document as well. thanks, Peter -------- Original Message -------- Subject: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Date: Wed, 2 Jul 2014 04:47:17 -0700 From: To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , Wim Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt has been successfully submitted by Peter Psenak and posted to the IETF repository. Name: draft-psenak-ospf-segment-routing-ospfv3-extension Revision: 02 Title: OSPFv3 Extensions for Segment Routing Document date: 2014-07-02 Group: Individual Submission Pages: 29 URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv3-extension/ Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-ospfv3-extension-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-psenak-ospf-segment-routing-ospfv3-extension-02 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary OSPFv3 extensions that need to be introduced for Segment Routing. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat . From nobody Wed Jul 2 07:02:29 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3811A014F for ; Wed, 2 Jul 2014 07:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSEFW1MCbmoB for ; Wed, 2 Jul 2014 07:02:23 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AC81A0162 for ; Wed, 2 Jul 2014 07:02:21 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-6d-53b3bc94f5db Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 61.FB.25146.49CB3B35; Wed, 2 Jul 2014 10:02:29 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 10:02:12 -0400 From: Ing-Wher Chen To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-chen-ospf-transition-to-ospfv3-01.txt Thread-Index: AQHPlflAtYCupoVFyEOZS5WlGKgqQ5uMz1bw Date: Wed, 2 Jul 2014 14:02:12 +0000 Message-ID: References: <20140702132630.1320.28041.idtracker@ietfa.amsl.com> In-Reply-To: <20140702132630.1320.28041.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.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXSPn+7UPZuDDZ7vFLBouXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGdu+tjAVXBCpuDDvC2sDY49IFyMnh4SAicSjliYWCFtM4sK9 9WwgtpDAUUaJnolJXYxcQPYyRom1k3+AJdgEDCQ2fNzCBGKLCChLbNnbDxYXFgiXePmnA2gQ B1A8QmL3rQSIEiOJb28/sYLYLAIqEs+7doKV8wp4S+z8/oIRYpeDxMm+eWBxTgFHidmHFoHF GYHu+X5qDdgqZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBC2osS+/unsICcwC2hKrN+lD9Gq KDGl+yE7xFpBiZMzn7BMYBSdhWTqLISOWUg6ZiHpWMDIsoqRo7Q4tSw33chwEyMw5I9JsDnu YFzwyfIQowAHoxIP74N9m4KFWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cCosuGIys/La95kJx4MWugmXX/yh/m1oq4dJ5kcF9+77Fs8Y/N/BRNTEalUqYML rf2u/zzcuCvaeVr37jdlk66844n4J52Snh7/gkP2gBCLgcKvj39bTGI/3bTzdvy6asH7aU/M G9euqJe5uv7evy8KT/Zmrk10Wbbj6N2vf5Lzmm2ucD5fvTWQTYmlOCPRUIu5qDgRAG1mHcRa AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/mNjJVVv3hQSZ8XYkYPlT3NoelfQ Subject: [OSPF] FW: New Version Notification for draft-chen-ospf-transition-to-ospfv3-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Jul 2014 14:02:25 -0000 SGVsbG8sDQoNCkFjZWUsIFJhbiwgYW5kIEkgaGF2ZSB1cGRhdGVkIHRoZSBmb2xsb3dpbmcgZHJh ZnQgdG8gYWRkcmVzcyB0aGUgZmVlZGJhY2sgYXQgdGhlIGxhc3QgbWVldGluZyBhbmQgb24gdGhl IG1haWxpbmcgbGlzdC4gIEluIHBhcnRpY3VsYXIsIGEgbmV3IHNlY3Rpb24gb24gSVB2NCB1c2Ug Y2FzZSBoYXMgYmVlbiBhZGRlZCwgYW5kIHRoZSBlZGl0cyB0aGF0IEthcnN0ZW4gc3VnZ2VzdGVk IGJhY2sgb24gRmViLiAxNywgMjAxNCBoYXZlIGFsc28gYmVlbiBpbmNvcnBvcmF0ZWQuDQoNClRo YW5rcywNCkhlbGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDAyLCAyMDE0IDk6MjcgQU0NClRvOiBSLiBBdGtpbnNvbjsgSW5n LVdoZXIgQ2hlbjsgSW5nLVdoZXIgQ2hlbjsgQWNlZSBMaW5kZW07IEFjZWUgTGluZGVtDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNoZW4tb3NwZi10cmFuc2l0 aW9uLXRvLW9zcGZ2My0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2hl bi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBJLiBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZToJCWRyYWZ0LWNoZW4tb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2Mw0KUmV2aXNpb246 CTAxDQpUaXRsZToJCU9TUEZ2MyBvdmVyIElQdjQgZm9yIElQdjYgVHJhbnNpdGlvbg0KRG9jdW1l bnQgZGF0ZToJMjAxNC0wNy0wMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJOQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWNoZW4tb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My0wMS50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW9zcGYtdHJh bnNpdGlvbi10by1vc3BmdjMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtY2hlbi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLTAxDQpEaWZmOiAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY2hlbi1vc3BmLXRy YW5zaXRpb24tdG8tb3NwZnYzLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgbWVjaGFuaXNtIHRvIHVzZSBJUHY0IHRvIHRyYW5zcG9ydCBPU1BGdjMNCiAgIHBhY2tl dHMsIGluIG9yZGVyIHRvIGZhY2lsaXRhdGUgdHJhbnNpdGlvbiBmcm9tIElQdjQtb25seSB0byBJ UHY2IGFuZA0KICAgZHVhbC1zdGFjayB3aXRoaW4gYSByb3V0aW5nIGRvbWFpbi4gIFVzaW5nIE9T UEZ2MyBvdmVyIElQdjQgd2l0aCB0aGUNCiAgIGV4aXN0aW5nIE9TUEZ2MyBBZGRyZXNzIEZhbWls eSBleHRlbnNpb24gY2FuIHNpbXBsaWZ5IHRyYW5zaXRpb24gZnJvbQ0KICAgYW4gT1NGUHYyIElQ djQtb25seSByb3V0aW5nIGRvbWFpbiB0byBhbiBPU1BGdjMgZHVhbC1zdGFjayByb3V0aW5nDQog ICBkb21haW4uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jul 2 10:17:33 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C551E1A0329 for ; Wed, 2 Jul 2014 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5jUUoy2WSGw for ; Wed, 2 Jul 2014 10:17:23 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088571A01BD for ; Wed, 2 Jul 2014 10:17:22 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-3f-53b3ea4f365a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 39.B7.25146.F4AE3B35; Wed, 2 Jul 2014 13:17:35 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 13:17:20 -0400 From: Acee Lindem To: Peter Psenak Thread-Topic: Comments draft-ietf-ospf-segment-routing-extensions-00.txt Thread-Index: AQHPlhl7vnSiCAgPyEu3PM2rx20nZQ== Date: Wed, 2 Jul 2014 17:17:19 +0000 Message-ID: <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> In-Reply-To: <53B3EE66.90608@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPoK7/q83BBse3mlu03LvHbrFjdzub xfrdj5gcmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsErozmj+kF7XoVsyfOZm9g3KjSxcjJ ISFgItHzrZ0VwhaTuHBvPVsXIxeHkMBRRonlB38wQzjLGCVaP15hAqliE9CReP7oHzOILSKg IjHveg8LiM0sECSx8chORhBbWMBDYu28mUBxDqAaT4mrb/IgTD2Jjw0JIBUsQJ135h9nBwnz CthLHFxmCmIKCcRInDmfBVLBKaAuMevKZjYQmxHosu+n1jBB7BGXuPVkPhPExQISS/acZ4aw RSVePv4H9YmSxJzX15gh6g0k3p+bD2VbS3xffZ4RwtaWWLbwNVicV0BQ4uTMJywTGMVnIVkx C0n7LCTts5C0z0LSvoCRdRUjR2lxalluupHhJkZgXB2TYHPcwbjgk+UhRgEORiUe3gf7NgUL sSaWFVfmHmKU5mBREufVrJ4XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxlqnOO74nGh+2 78sq4NSyLirPWOMnITZL0dadVfbzzpo4t5BNFuvq5T64OyyOfnFPb1N62oSpQbKTI/18LU5z GNQ8lt03iVXud+gDBdvXv5aq6wv2/Qp6ueWhypN+T8H+bwed7K7Ivr6i0Wn7y9Ba7HuN29+D QbEC+5K40w7Nv26/8168zG0lluKMREMt5qLiRACLWF7KjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/9yuMLj4Yupu2SDP1ocRWOnSBCx4 Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Jul 2014 17:17:25 -0000 Hi Peter,=20 It seems there are two distinct deployment scenarios - one where SR routers= are given a range and policy and allocate their own SIDs and another where= a mapping server does it for the routing domain.=20 See inline for #6.=20 On Jul 2, 2014, at 7:35 AM, Peter Psenak wrote: > Hi Acee, >=20 > please see inline: >=20 > On 7/1/14 23:00 , Acee Lindem wrote: >> Hi Peter, >>=20 >> I=92ve reviewed the OSPF Segment Routing WG draft and have some comments= . >>=20 >> 1. Can you describe the usage of algorithm in the Segment Routing= domain? An SR capable router advertises the algorithms it supports and an = algorithm is associated with a Prefix-SID. However, the usage of this infor= mation is not described anywhere and it is guaranteed that there will be m= any different interpretations. >=20 > filsfils-spring-segment-routing-use-cases will be updated to include the = usage of algorithm. >=20 >>=20 >> 2. The usage of the advertised Weight references the =93Segment R= outing Architecture=94. However, there is no description of weight usage th= ere. >=20 > weight is used for influencing load-balancing across multiple adj-sid's t= o the same node. >=20 > filsfils-spring-segment-routing-use-cases will be updated to include the = usage of weight. >=20 >>=20 >> 3. Section 3.2 - the range advertisement seems a bit unnatural. W= hy is it assumed that all the advertised ranges have the same size? It woul= d seem more intuitive that individual ranges are defined by the tuple. >=20 > there is a typo in the text: > "SID/Label Sub-TLV MAY appear multiple times" will be changed to "SID/Lab= el Range TLV MAY appear multiple times", which I believe will address your = comment. >=20 >>=20 >> 4. Section 4.2 - Can you please make the P-flag the NP-Flag since= the set value indicates not to perform the PHP operation? If you want to k= eep it the P-Flag, the set value should mean to perform the PHP. >=20 > sure, will rename to NP-flag >=20 >>=20 >> 5. Section 4.2 and 5.2 - The Segment Routing architecture defines= adjacency SIDs as having local significance. Yet the L-Flag allows this to= be encoded as global. Similarly, it would seem that a prefix SID would no= rmally have global significance and local significance would be an exceptio= n (e.g., possibly a loopback address accessible only from the advertising O= SPF router). >=20 > the architectre draft will be corrected to reflect that both prefix-sid a= nd adj-sid can be global or local. >=20 >>=20 >> 6. Section 4.2 - I really don=92t like having his sub-TLV redefin= e the subsuming top-level TLV as a range of prefixes of the same length rat= her than a single prefix. Although this is my first serious reading of the = draft, this encoding seems really unwieldy and, in practice, I=92d expect t= he range size always advertised as 1. We can discuss this more in Toronto. >=20 > an example where the range would be more then 1 is a mapping server case.= This helps you to advertise SIDs for loopback addresses of all routers in = a non-SR capable part of the network, assuming they are allocated from the = contiguous address space. Instead of advertising hundreds of mappings for e= ach /32 address, you can compact it to a single advertisement. I=92ve seen loopbacks allocated sequentially in a few networks but many mor= e where there weren=92t.=20 >=20 > What you need in such case is component prefix/length plus the number of = components - OSPF Extended Prefix TLV gives you the component info and Pref= ix SID Sub-TLV "Range Size' gives you the number of components. I understood it but I don=92t like the sub-TLV extending the specification = of the higher level TLV. I especially don=92t like it since the top-level T= LV is a generic mechanism to advertise attributes. When additional attribu= tes are defined, it begs the of whether or not they apply solely to the pre= fix or to the range.=20 >=20 > We could have defined a separate top level TLV in OSPF Extended Prefix LS= A for the advertisement of range of components, but it looks to me that wou= ld be an overkill. I would have preferred that. When the SID attributes are embedded (OSPFv3 a= nd ISIS), I think the semantics are even more unnatural since reachability = MAY be advertised for the prefix while SID mapping is being advertised for = the range.=20 > Current encoding of Prefix SID Sub-TLV gives us all the flexibility we ne= ed. In addition it matches what ISIS has done. I haven=92t seen any discussion of the draft on the ISIS list other than th= e revision updates.=20 Thanks, Acee=20 >=20 >=20 >>=20 >> 7. Section 4.2 - Shouldn=92t the reference for the mapping server= be the =93Segment Routing Architecture=94 rather than the =93Segment Routi= ng Use Cases=94? In general, the usage of a mapping server and the scope of= assignment needs to be described better somewhere (not in the OSPF encodin= g document). >=20 > will fix the reference >=20 >>=20 >> 8. Section 6 - It would seem that an entity calculating a multi-a= rea SR path would need access to the topology for all the areas and the SID= would need to be globally assigned? Right? >=20 > correct. >=20 >> So rules are primarily for the population of the forwarding plane. Right= ? >=20 > for advertisement/propagation of SIDs and for forwarding plane programmin= g. >=20 >>=20 >> 9. Section 6.2 - In standard OSPF, inter-area summary propagation= only applies to inter-area routes learned over the backbone. Is this any d= ifferent? >=20 > no, the mechanism is the same as for type-3s. >=20 > thanks, > Peter >=20 >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >> . >>=20 >=20 From nobody Wed Jul 2 10:48:41 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B77F1B29C2 for ; Wed, 2 Jul 2014 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kBTvWDc5uWa for ; Wed, 2 Jul 2014 10:48:37 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7419E1B287E for ; Wed, 2 Jul 2014 10:48:37 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-83-53b3f40fa474 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.89.05330.F04F3B35; Wed, 2 Jul 2014 13:59:11 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 13:48:36 -0400 From: Acee Lindem To: Peter Psenak Thread-Topic: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Thread-Index: AQHPlfOv+tbyxFw4u0GQ0Nbv0ar8sZuNUtYA Date: Wed, 2 Jul 2014 17:48:35 +0000 Message-ID: References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> In-Reply-To: <53B3FF33.1000109@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <0520419468A2D04D9CB4DF385FCD10A2@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPny7/l83BBvdXyFm03LvHbrFjdzub A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWx5sUS9oKVohXnXmg3MP4W7GLk5JAQMJHY vWsqI4QtJnHh3nq2LkYuDiGBo4wSKzffZIFwljFKTPk/jwmkik1AR+L5o3/MILaIgIrEvOs9 LCA2s4CsxLNtTWBxYYFUiYM97exdjBxANWkS0+56QpQbSUzd+4EdxGYBar3wugmshFfAXuL1 v0CQsJBAvMSkeROYQcKcApoS07ZZgoQZgU77fmoNE8QicYlbT+YzQZwsILFkz3lmCFtU4uXj f6wQtpLEx9/z2SHqdSQW7P7EBjKSWcBa4vI7qHu1JZYtfA3WyisgKHFy5hOWCYzis5BsmIWk exZC9ywk3bOQdC9gZF3FyFFanFqWm25ksIkRGEvHJNh0dzDueWl5iFGAg1GJh/fBvk3BQqyJ ZcWVuYcYpTlYlMR5Z9XOCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaMUhtaraUsr9UdSs lJB5G86kZF0pOhXNeWzaXMXYlAfLzbd1JR450pTOo1zqU/Zs2VTxJt0ZbnMsVi79bfY4m1/K a+mq2J2y67dcFV1338/09CtLYeWgrzV/+S4EcHQUP521UDefV+HCNMY5J39MyIz2lejkVF9p tFu5YMn9fD/2u7w/XL1+KbEUZyQaajEXFScCAKNitLyGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/4-DVCGrBd3q_gJeasS6ZkLIwOs8 Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Jul 2014 17:48:39 -0000 Hi Peter,=20 I will review this version and start the adoption poll.=20 Others - please read and comment.=20 Thanks,=20 Acee On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: > Acee, WG, >=20 > I have updated the OSPFv3 SR extension draft. >=20 > Given that OSPFv2 SR extension draft has been accepted as a WG item, it w= ould make a lot of sense to make the OSPFv3 SR draft WG document as well. >=20 > thanks, > Peter >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-psenak-ospf-segment-routing-o= spfv3-extension-02.txt > Date: Wed, 2 Jul 2014 04:47:17 -0700 > From: > To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , Wim= Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler >=20 >=20 > A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extension-= 02.txt > has been successfully submitted by Peter Psenak and posted to the > IETF repository. >=20 > Name: draft-psenak-ospf-segment-routing-ospfv3-extension > Revision: 02 > Title: OSPFv3 Extensions for Segment Routing > Document date: 2014-07-02 > Group: Individual Submission > Pages: 29 > URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routin= g-ospfv3-extension-02.txt > Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routin= g-ospfv3-extension/ > Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-os= pfv3-extension-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-psenak-ospf-segment-routin= g-ospfv3-extension-02 >=20 > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS and OSPF). >=20 > This draft describes the necessary OSPFv3 extensions that need to be > introduced for Segment Routing. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > . >=20 >=20 >=20 From nobody Thu Jul 3 01:09:38 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FAE1A02F1 for ; Thu, 3 Jul 2014 01:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL5HCJq1SUh2 for ; Thu, 3 Jul 2014 01:09:34 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471F21A00E1 for ; Thu, 3 Jul 2014 01:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4784; q=dns/txt; s=iport; t=1404374974; x=1405584574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OIAaK8J46Si7K9i/iYdmRzHudCkd5v4Xj92l0fBiqPk=; b=bJzOfMbs3KzUR+LrfxB8iLmqWDlA6gdD7RthzOUeM1WR1y36lCDUQdEG xQGP/TLRte75+7DtkSBesIpb9G13PW60OmbO04EPGD+rQUKL6W0jVUme4 63Qj3h0XAlZ1n6113OMjPVOBazH3yPX/LDJbyWMckcil7DS7MXQGIS1WB o=; X-IronPort-AV: E=Sophos;i="5.01,593,1400025600"; d="scan'208";a="103604041" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Jul 2014 08:09:33 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6389WwP000518; Thu, 3 Jul 2014 08:09:32 GMT Message-ID: <53B50FBC.60803@cisco.com> Date: Thu, 03 Jul 2014 10:09:32 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> In-Reply-To: <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/6SH_xdQY9TTrUqSirw_V-5aOLcI Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 08:09:36 -0000 Hi Acee, please see inline: On 7/2/14 19:17 , Acee Lindem wrote: > Hi Peter, > It seems there are two distinct deployment scenarios - one where SR routers are given a range and policy and allocate their own SIDs and another where a mapping server does it for the routing domain. yes, that is correct. The latter is used mainly during migration from LDP to SR. >>> 6. Section 4.2 - I really don’t like having his sub-TLV redefine the subsuming top-level TLV as a range of prefixes of the same length rather than a single prefix. Although this is my first serious reading of the draft, this encoding seems really unwieldy and, in practice, I’d expect the range size always advertised as 1. We can discuss this more in Toronto. >> >> an example where the range would be more then 1 is a mapping server case. This helps you to advertise SIDs for loopback addresses of all routers in a non-SR capable part of the network, assuming they are allocated from the contiguous address space. Instead of advertising hundreds of mappings for each /32 address, you can compact it to a single advertisement. > > I’ve seen loopbacks allocated sequentially in a few networks but many more where there weren’t. still, having a mechanism to compact the advertisements if possible looks appealing. > >> >> What you need in such case is component prefix/length plus the number of components - OSPF Extended Prefix TLV gives you the component info and Prefix SID Sub-TLV "Range Size' gives you the number of components. > > I understood it but I don’t like the sub-TLV extending the specification of the higher level TLV. I especially don’t like it since the top-level TLV is a generic mechanism to advertise attributes. When additional attributes are defined, it begs the of whether or not they apply solely to the prefix or to the range. high level TLV advertise a single prefix/mask. It's the sub-TLV which may extend the applicability to the range if required, so the scope is defined by each sub-TLV. > >> >> We could have defined a separate top level TLV in OSPF Extended Prefix LSA for the advertisement of range of components, but it looks to me that would be an overkill. > > I would have preferred that. When the SID attributes are embedded (OSPFv3 and ISIS), I think the semantics are even more unnatural since reachability MAY be advertised for the prefix while SID mapping is being advertised for the range. I had the same reservations at the beginning :) But there is no problem really. Prefix-SID sub-TLV never advertises any reachability, whether it advertises a single SID or a range of SIDs. For Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of "start" and Prefix-SID sub-TLV always carry its own "size" - just a different interpretation of the data from the higher level TLV. Please note that SID range is quite different from the address range we are used to from summarization. SID range requires three parameters (address/mask and count), compared to two parameter (address/mask) that traditional address range uses. As a result, Extended prefix TLV as such can not cover the SID range, because it only has address/mask. Defining a top-level TLV for a SID range itself does not really fit into Extended Prefix LSA and having a new LSA for it is not an option I would say. So the current encoding looks like a good compromise to me. thanks, Peter > >> Current encoding of Prefix SID Sub-TLV gives us all the flexibility we need. In addition it matches what ISIS has done. > > I haven’t seen any discussion of the draft on the ISIS list other than the revision updates. > > Thanks, > Acee > > > >> >> >>> >>> 7. Section 4.2 - Shouldn’t the reference for the mapping server be the “Segment Routing Architecture” rather than the “Segment Routing Use Cases”? In general, the usage of a mapping server and the scope of assignment needs to be described better somewhere (not in the OSPF encoding document). >> >> will fix the reference >> >>> >>> 8. Section 6 - It would seem that an entity calculating a multi-area SR path would need access to the topology for all the areas and the SID would need to be globally assigned? Right? >> >> correct. >> >>> So rules are primarily for the population of the forwarding plane. Right? >> >> for advertisement/propagation of SIDs and for forwarding plane programming. >> >>> >>> 9. Section 6.2 - In standard OSPF, inter-area summary propagation only applies to inter-area routes learned over the backbone. Is this any different? >> >> no, the mechanism is the same as for type-3s. >> >> thanks, >> Peter >> >>> >>> Thanks, >>> Acee >>> >>> >>> >>> . >>> >> > > . > From nobody Thu Jul 3 03:02:02 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA9F1A04AC for ; Thu, 3 Jul 2014 03:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JW8a_Rr23uL for ; Thu, 3 Jul 2014 03:02:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FDE1A0368 for ; Thu, 3 Jul 2014 03:01:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJO02717; Thu, 03 Jul 2014 10:01:58 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 11:01:58 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 18:01:53 +0800 From: Xuxiaohu To: Peter Psenak , Acee Lindem Thread-Topic: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt Thread-Index: AQHPlem4IpA14m6HCEObXOqvma7kYJuMgQWAgAD5SACAAJ7xwA== Date: Thu, 3 Jul 2014 10:01:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828FF4C@NKGEML512-MBS.china.huawei.com> References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> <53B50FBC.60803@cisco.com> In-Reply-To: <53B50FBC.60803@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/al_ujGn4PAMrbbzYK4Eesaax7Hg Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 10:02:01 -0000 > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Peter Psenak > Sent: Thursday, July 03, 2014 4:10 PM > To: Acee Lindem > Cc: OSPF List > Subject: Re: [OSPF] Comments > draft-ietf-ospf-segment-routing-extensions-00.txt >=20 > Hi Acee, >=20 > please see inline: >=20 > On 7/2/14 19:17 , Acee Lindem wrote: > > Hi Peter, > > It seems there are two distinct deployment scenarios - one where SR rou= ters > are given a range and policy and allocate their own SIDs and another wher= e a > mapping server does it for the routing domain. >=20 > yes, that is correct. The latter is used mainly during migration from LDP= to SR. The mapping server could actually be used to advertise global SIDs for all = the SR-capable nodes as well (see http://tools.ietf.org/html/draft-xu-ospf-= global-label-sid-adv-00). In this way, the potential risk of global SID all= ocation collision can be avoided.=20 Best regards, Xiaohu From nobody Thu Jul 3 03:33:40 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262641B2831 for ; Thu, 3 Jul 2014 03:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EazDD5SLl7w for ; Thu, 3 Jul 2014 03:33:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22F41B2837 for ; Thu, 3 Jul 2014 03:33:20 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 18681264178 for ; Thu, 3 Jul 2014 12:33:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F1F914C056 for ; Thu, 3 Jul 2014 12:33:18 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 3 Jul 2014 12:33:18 +0200 From: To: "ospf@ietf.org" Thread-Topic: draft-decraene-rtgwg-backoff-algo-00.txt Thread-Index: Ac+Wp+MyvMnaa2ToRgGqZeRoKdO52QAAfAMA Date: Thu, 3 Jul 2014 10:33:18 +0000 Message-ID: <31904_1404383599_53B5316F_31904_1971_1_53C29892C857584299CBF5D05346208A07177B63@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/bZTbJ4lQXVyMcfHFYTNe246Lsoc Subject: [OSPF] draft-decraene-rtgwg-backoff-algo-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 10:33:37 -0000 UmVwb3N0aW5nLg0KV2hlbiByZXBseWluZywgcGxlYXNlIGFkZCBydGd3Z0BpZXRmLm9yZyBhbmQg aXNpcy13Z0BpZXRmLm9yZyBpbiBjb3B5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBERUNSQUVORSBCcnVubyBJTVQvT0xOIA0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIw MTQgMTI6MjcgUE0NClRvOiBydGd3Z0BpZXRmLm9yZw0KQ2M6IGlzaXMtd2dAaWV0Zi5vcmcgbGlz dDsgJ29zcGZAaWV0Zi5vcmcnDQpTdWJqZWN0OiBkcmFmdC1kZWNyYWVuZS1ydGd3Zy1iYWNrb2Zm LWFsZ28tMDAudHh0DQoNCkhpIGFsbCwNCg0KUGxlYXNlIGZpbmQgYmVsb3cgYSBwcm9wb3NlZCBz aG9ydCBkcmFmdCB3aGljaDoNCi1hLSBjYWxscyBmb3IgYSBzdGFuZGFyZGl6ZWQgU1BGIGJhY2st b2ZmIGFsZ29yaXRobSwgZm9yIGludGVyb3BlcmFiaWxpdHkgcHVycG9zZQ0KLWItIHByb3Bvc2Vz IGFuIGFsZ29yaXRobQ0KDQpDb21tZW50cyBhcmUgd2VsY29tZWQuDQoNCk5vdGUgdGhhdCB2MDAg Y3VycmVudGx5IHByb3Bvc2VzIHRoZSBhbGdvcml0aG0gd2hpY2ggaXMgdGhlIG1vc3QgZGVwbG95 ZWQuIEkgd291bGQgYmUgZmluZSB3aXRoIGFueSBtb2RpZmljYXRpb24sIGJhc2VkIG9uIFdHIGNv bnNlbnN1cyAoYXNzdW1pbmcgV0cgYWRvcHRpb24pLg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KQnJ1 bm8NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXks IEp1bHkgMDMsIDIwMTQgMTI6MTYgUE0NCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRl Y3JhZW5lLXJ0Z3dnLWJhY2tvZmYtYWxnby0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgQnJ1bm8gRGVjcmFlbmUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZGVjcmFlbmUtcnRnd2ctYmFja29mZi1hbGdvDQpSZXZpc2lv bjoJMDANClRpdGxlOgkJQmFjay1vZmYgU1BGIGFsZ29yaXRobSBmb3IgbGluayBzdGF0ZSBJR1AN CkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDMNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTUNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1kZWNyYWVuZS1ydGd3Zy1iYWNrb2ZmLWFsZ28tMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGVjcmFlbmUt cnRnd2ctYmFja29mZi1hbGdvLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWRlY3JhZW5lLXJ0Z3dnLWJhY2tvZmYtYWxnby0wMA0KDQoNCkFic3RyYWN0 Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3RhbmRhcmQgYWxnb3JpdGhtIHRvIGJhY2st b2ZmIGxpbmstc3RhdGUgSUdQDQogICBTUEYgY29tcHV0YXRpb25zLg0KDQogICBUaGlzIGltcHJv dmVzIGludGVyb3BlcmFiaWxpdHkgYnkgcmVkdWNpbmcgdGhlIHByb2JhYmlsaXR5IGFuZC9vcg0K ICAgZHVyYXRpb24gb2YgdHJhbnNpZW50IGZvcndhcmRpbmcgbG9vcHMgZHVyaW5nIHRoZSBJR1Ag Y29udmVyZ2VuY2UgaW4NCiAgIHRoZSBhcmVhL2xldmVsIHdoZW4gdGhlIG5ldHdvcmsgcmVhY3Rz IHRvIG11bHRpcGxlIGNvbnNlY3V0aXZlDQogICBldmVudHMuDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu Jul 3 08:45:25 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B2E1A0151 for ; Thu, 3 Jul 2014 08:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4CGKDA235RT for ; Thu, 3 Jul 2014 08:45:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EF81A0177 for ; Thu, 3 Jul 2014 08:45:20 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-ec-53b5262a46c5 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DB.82.25146.A2625B35; Thu, 3 Jul 2014 11:45:15 +0200 (CEST) To: undisclosed-recipients:; Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 11:45:13 -0400 From: Acee Lindem CC: OSPF List Thread-Topic: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Thread-Index: AQHPlfOv+tbyxFw4u0GQ0Nbv0ar8sZuNUtYAgAFv3IA= Date: Thu, 3 Jul 2014 15:45:12 +0000 Message-ID: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPiK622tZgg1sn+Sxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxprJl1gKZktVnP20n7WB8bdoFyMnh4SAicTfCRfYIGwxiQv3 1gPZXBxCAkcZJf7PucEMkhARkJGYO/sxK0RiGaPEyfYOFpAEm4COxPNH/8CKmAVkJZ5tawKz hQVSJQ72tLN3MXIANadJTLvrCTHHSqJ5yx0mEJtFQEXi59EP7CA2r4C9xKbWHcwQ86cySvx9 8AXsIk4BB4np96+C7WIEuu77qTVMELvEJW49mc8EcbWAxJI955khbFGJl4//sULYShIff89n h6g3kHh/bj4zyD3MAtYSZ7dEQoS1JZYtfM0McYOgxMmZT1gmMIrPQrJhFpLuWQjds5B0z0LS vYCRdRUjR2lxalluupHhJkZg/ByTYHPcwbjgk+UhRgEORiUe3gSBLcFCrIllxZW5hxilOViU xHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBkKtz3+dXrEzMcHkofj9dayFggcjgx tiJghsWKsCqLo91Jpq2MPXfOtcpEPF//jevbv5bXPcbvAt///PXv/1WJ5WHyRy/WqPz6u3Hx s2zfz0KdH427Dj+368xduk8vbMI1iSkS2a0TbW5VpXBZFtyruPvvXvWrD6srl6mdVnC/euPF qYMxv6OslFiKMxINtZiLihMBZK6yuoACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/lw3AP9lvOaOeyXoglhD70R21FWk Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 15:45:22 -0000 Hi,=20 I=92d like to start a 2 week OSPF WG adoption poll of the subject draft. Th= e encodings are very close to those in the OSPFv2 draft (which is a WG docu= ment) other than the fact that they take advantage of the OSPFv3 LSA extens= ions which simplifies things. However, it makes a lot of sense to advance t= hese drafts separately since the OSPFv2 draft is not dependent on any other= drafts and there are existing implementations.=20 Thanks, Acee On Jul 2, 2014, at 1:48 PM, Acee Lindem wrote: > Hi Peter,=20 > I will review this version and start the adoption poll.=20 >=20 > Others - please read and comment.=20 >=20 > Thanks,=20 > Acee > On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >=20 >> Acee, WG, >>=20 >> I have updated the OSPFv3 SR extension draft. >>=20 >> Given that OSPFv2 SR extension draft has been accepted as a WG item, it = would make a lot of sense to make the OSPFv3 SR draft WG document as well. >>=20 >> thanks, >> Peter >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for draft-psenak-ospf-segment-routing-= ospfv3-extension-02.txt >> Date: Wed, 2 Jul 2014 04:47:17 -0700 >> From: >> To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , Wi= m Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler >>=20 >>=20 >> A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extension= -02.txt >> has been successfully submitted by Peter Psenak and posted to the >> IETF repository. >>=20 >> Name: draft-psenak-ospf-segment-routing-ospfv3-extension >> Revision: 02 >> Title: OSPFv3 Extensions for Segment Routing >> Document date: 2014-07-02 >> Group: Individual Submission >> Pages: 29 >> URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routi= ng-ospfv3-extension-02.txt >> Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routi= ng-ospfv3-extension/ >> Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-o= spfv3-extension-02 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-psenak-ospf-segment-routi= ng-ospfv3-extension-02 >>=20 >> Abstract: >> Segment Routing (SR) allows for a flexible definition of end-to-end >> paths within IGP topologies by encoding paths as sequences of >> topological sub-paths, called "segments". These segments are >> advertised by the link-state routing protocols (IS-IS and OSPF). >>=20 >> This draft describes the necessary OSPFv3 extensions that need to be >> introduced for Segment Routing. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >> . >>=20 >>=20 >>=20 >=20 From nobody Thu Jul 3 09:58:57 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBE71B2B2B for ; Thu, 3 Jul 2014 09:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvTCWApCDXdf for ; Thu, 3 Jul 2014 09:58:52 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25D61B2B06 for ; Thu, 3 Jul 2014 09:58:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s63GwfHP003452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jul 2014 11:58:44 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s63GwfQB025979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 18:58:41 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 3 Jul 2014 18:58:41 +0200 From: "Henderickx, Wim (Wim)" To: Acee Lindem Thread-Topic: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Thread-Index: AQHPluAKk/LSkVSym02OdWqk7Qp/Vw== Date: Thu, 3 Jul 2014 16:58:40 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/kayq2R4KCwzwisaojsMYSkorKkg Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 16:58:55 -0000 Support as co-author On 03/07/14 17:45, "Acee Lindem" wrote: >Hi,=20 > >I=B9d like to start a 2 week OSPF WG adoption poll of the subject draft. >The encodings are very close to those in the OSPFv2 draft (which is a WG >document) other than the fact that they take advantage of the OSPFv3 LSA >extensions which simplifies things. However, it makes a lot of sense to >advance these drafts separately since the OSPFv2 draft is not dependent >on any other drafts and there are existing implementations. > >Thanks, >Acee > >On Jul 2, 2014, at 1:48 PM, Acee Lindem wrote: > >> Hi Peter,=20 >> I will review this version and start the adoption poll. >>=20 >> Others - please read and comment. >>=20 >> Thanks,=20 >> Acee >> On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >>=20 >>> Acee, WG, >>>=20 >>> I have updated the OSPFv3 SR extension draft. >>>=20 >>> Given that OSPFv2 SR extension draft has been accepted as a WG item, >>>it would make a lot of sense to make the OSPFv3 SR draft WG document as >>>well. >>>=20 >>> thanks, >>> Peter >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for >>>draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Date: Wed, 2 Jul 2014 04:47:17 -0700 >>> From: >>> To: Stefano Previdi , Jeff Tantsura >>>, Jeff Tantsura >>>, "Rob Shakir" , Hannes >>>Gredler , "Wim Henderickx" >>>, Clarence Filsfils >>>, Wim Henderickx >>>, Peter Psenak , >>>Stefano Previdi , Clarence Filsfils >>>, Peter Psenak , "Rob Shakir" >>>, Hannes Gredler >>>=20 >>>=20 >>> A new version of I-D, >>>draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> has been successfully submitted by Peter Psenak and posted to the >>> IETF repository. >>>=20 >>> Name: draft-psenak-ospf-segment-routing-ospfv3-extension >>> Revision: 02 >>> Title: OSPFv3 Extensions for Segment Routing >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 29 >>> URL:=20 >>>http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-os >>>pfv3-extension-02.txt >>> Status:=20 >>>https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv >>>3-extension/ >>> Htmlized:=20 >>>http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-ospfv3-exte >>>nsion-02 >>> Diff:=20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-psenak-ospf-segment-routing-osp= fv >>>3-extension-02 >>>=20 >>> Abstract: >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>>=20 >>> This draft describes the necessary OSPFv3 extensions that need to be >>> introduced for Segment Routing. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>>submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>> . >>>=20 >>>=20 >>>=20 >>=20 > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From nobody Thu Jul 3 10:06:40 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA51B2964 for ; Thu, 3 Jul 2014 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EXTNSN=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqYy5xhvi0G0 for ; Thu, 3 Jul 2014 10:06:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8EC1B280E for ; Thu, 3 Jul 2014 10:06:37 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-27-53b5393cf7aa Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CE.67.25146.C3935B35; Thu, 3 Jul 2014 13:06:37 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 13:06:35 -0400 From: Jeff Tantsura To: Acee Lindem Thread-Topic: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Thread-Index: AQHPluAKk/LSkVSym02OdWqk7Qp/V5uOYjqA Date: Thu, 3 Jul 2014 17:06:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="euc-kr" Content-ID: <044EE8C6A5F1D44AA1EDF0234D2DAAFA@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPuK6t5dZgg/6DXBYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49bfiSwFbVoVU45dZ2xg/KPRxcjJISFgIrH27kQ2CFtM4sK9 9UA2F4eQwFFGiZ4HHawQzjJGiTn9x8Cq2AQMJP5/O84CYosIaEl0vv3ODmIzC8hKPNvWxAxi CwvkSJzuPMAKUZMrMbHjBBuEbSQxYVMnmM0ioCLxpX8WWC+vgLnE8dmPwWwhATuJ20vugs3n FLCX2H90FVicEei676fWMEHsEpe49WQ+E8TVAhJL9pxnhrBFJV4+/ge2V1RAT+LdcZgaRYl9 /dOh7tSS+PJjHxuEbS3x+f13KFtRYkr3Q6h7BCVOznzCMoFRYhaSdbOQtM9C0j4LSfssJO0L GFlXMXKUFqeW5aYbGW5iBMbWMQk2xx2MCz5ZHmIU4GBU4uFdoLk1WIg1say4MvcQozQHi5I4 r2b1vGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKut8k6/nSilEJTuVJd088hir22eKV8s FR9HJU94c9Bmjh+n8Z37rZWbTK9kzVj25XuAUOkljaNZOWUZui3XFgfqWdaoZN/O7Wd+bv1p g2705ZWzc30veGv+WPB0ktNM/iV1Cz9c6Zzxh+mh3NSS2TsVDLwSLgtd/tB3KXtp9/rfG/YU P/LyZlZiKc5INNRiLipOBABAQHYFjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/CFHcWbNYkPPivmwsXyoxym6uMzA Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 17:06:38 -0000 SGkgQWNlZSwNCg0KU3VwcG9ydCBhcyBjb2F1dGhvcg0KDQpDaGVlcnMsDQpKZWZmDQoNCg0KLU9u IDAzLzA3LzE0IDE3OjQ1LCAiQWNlZSBMaW5kZW0iIDxhY2VlLmxpbmRlbUBlcmljc3Nvbi5jb20+ IHdyb3RlOg0KPg0KPj5IaSwgDQo+Pg0KPj5JqfZkIGxpa2UgdG8gc3RhcnQgYSAyIHdlZWsgT1NQ RiBXRyBhZG9wdGlvbiBwb2xsIG9mIHRoZSBzdWJqZWN0IGRyYWZ0Lg0KPj5UaGUgZW5jb2Rpbmdz IGFyZSB2ZXJ5IGNsb3NlIHRvIHRob3NlIGluIHRoZSBPU1BGdjIgZHJhZnQgKHdoaWNoIGlzIGEg V0cNCj4+ZG9jdW1lbnQpIG90aGVyIHRoYW4gdGhlIGZhY3QgdGhhdCB0aGV5IHRha2UgYWR2YW50 YWdlIG9mIHRoZSBPU1BGdjMgTFNBDQo+PmV4dGVuc2lvbnMgd2hpY2ggc2ltcGxpZmllcyB0aGlu Z3MuIEhvd2V2ZXIsIGl0IG1ha2VzIGEgbG90IG9mIHNlbnNlIHRvDQo+PmFkdmFuY2UgdGhlc2Ug ZHJhZnRzIHNlcGFyYXRlbHkgc2luY2UgdGhlIE9TUEZ2MiBkcmFmdCBpcyBub3QgZGVwZW5kZW50 DQo+Pm9uIGFueSBvdGhlciBkcmFmdHMgYW5kIHRoZXJlIGFyZSBleGlzdGluZyBpbXBsZW1lbnRh dGlvbnMuDQo+Pg0KPj5UaGFua3MsDQo+PkFjZWUNCj4+DQo+Pk9uIEp1bCAyLCAyMDE0LCBhdCAx OjQ4IFBNLCBBY2VlIExpbmRlbSA8YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+ DQo+Pj4gSGkgUGV0ZXIsIA0KPj4+IEkgd2lsbCByZXZpZXcgdGhpcyB2ZXJzaW9uIGFuZCBzdGFy dCB0aGUgYWRvcHRpb24gcG9sbC4NCj4+PiANCj4+PiBPdGhlcnMgLSBwbGVhc2UgcmVhZCBhbmQg Y29tbWVudC4NCj4+PiANCj4+PiBUaGFua3MsIA0KPj4+IEFjZWUNCj4+PiBPbiBKdWwgMiwgMjAx NCwgYXQgODo0NiBBTSwgUGV0ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4gDQo+Pj4+IEFjZWUsIFdHLA0KPj4+PiANCj4+Pj4gSSBoYXZlIHVwZGF0ZWQgdGhlIE9TUEZ2 MyBTUiBleHRlbnNpb24gZHJhZnQuDQo+Pj4+IA0KPj4+PiBHaXZlbiB0aGF0IE9TUEZ2MiBTUiBl eHRlbnNpb24gZHJhZnQgaGFzIGJlZW4gYWNjZXB0ZWQgYXMgYSBXRyBpdGVtLA0KPj4+Pml0IHdv dWxkIG1ha2UgYSBsb3Qgb2Ygc2Vuc2UgdG8gbWFrZSB0aGUgT1NQRnYzIFNSIGRyYWZ0IFdHIGRv Y3VtZW50IGFzDQo+Pj4+d2VsbC4NCj4+Pj4gDQo+Pj4+IHRoYW5rcywNCj4+Pj4gUGV0ZXINCj4+ Pj4gDQo+Pj4+IA0KPj4+PiAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+Pj4+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+Pj5kcmFmdC1wc2VuYWst b3NwZi1zZWdtZW50LXJvdXRpbmctb3NwZnYzLWV4dGVuc2lvbi0wMi50eHQNCj4+Pj4gRGF0ZTog V2VkLCAyIEp1bCAyMDE0IDA0OjQ3OjE3IC0wNzAwDQo+Pj4+IEZyb206IDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQo+Pj4+IFRvOiBTdGVmYW5vIFByZXZpZGkgPHNwcmV2aWRpQGNpc2NvLmNv bT4sIEplZmYgVGFudHN1cmENCj4+Pj48amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb20+LCBKZWZm IFRhbnRzdXJhDQo+Pj4+PGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPiwgIlJvYiBTaGFraXIi IDxyb2Iuc2hha2lyQGJ0LmNvbT4sIEhhbm5lcw0KPj4+PkdyZWRsZXIgPGhhbm5lc0BqdW5pcGVy Lm5ldD4sICJXaW0gSGVuZGVyaWNreCINCj4+Pj48d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNl bnQuY29tPiwgQ2xhcmVuY2UgRmlsc2ZpbHMNCj4+Pj48Y2ZpbHNmaWxAY2lzY28uY29tPiwgV2lt IEhlbmRlcmlja3gNCj4+Pj48d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPiwgUGV0 ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT4sDQo+Pj4+U3RlZmFubyBQcmV2aWRpIDxzcHJl dmlkaUBjaXNjby5jb20+LCBDbGFyZW5jZSBGaWxzZmlscw0KPj4+PjxjZmlsc2ZpbEBjaXNjby5j b20+LCBQZXRlciBQc2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPiwgIlJvYiBTaGFraXIiDQo+Pj4+ PHJvYi5zaGFraXJAYnQuY29tPiwgSGFubmVzIEdyZWRsZXIgPGhhbm5lc0BqdW5pcGVyLm5ldD4N Cj4+Pj4gDQo+Pj4+IA0KPj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCj4+Pj5kcmFmdC1wc2Vu YWstb3NwZi1zZWdtZW50LXJvdXRpbmctb3NwZnYzLWV4dGVuc2lvbi0wMi50eHQNCj4+Pj4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQZXRlciBQc2VuYWsgYW5kIHBvc3RlZCB0 byB0aGUNCj4+Pj4gSUVURiByZXBvc2l0b3J5Lg0KPj4+PiANCj4+Pj4gTmFtZToJCWRyYWZ0LXBz ZW5hay1vc3BmLXNlZ21lbnQtcm91dGluZy1vc3BmdjMtZXh0ZW5zaW9uDQo+Pj4+IFJldmlzaW9u OgkwMg0KPj4+PiBUaXRsZToJCU9TUEZ2MyBFeHRlbnNpb25zIGZvciBTZWdtZW50IFJvdXRpbmcN Cj4+Pj4gRG9jdW1lbnQgZGF0ZToJMjAxNC0wNy0wMg0KPj4+PiBHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KPj4+PiBQYWdlczoJCTI5DQo+Pj4+IFVSTDogDQo+Pj4+aHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcHNlbmFrLW9zcGYtc2VnbWVudC1yb3V0aW5n LW8NCj4+Pj5zDQo+Pj4+cGZ2My1leHRlbnNpb24tMDIudHh0DQo+Pj4+IFN0YXR1czogDQo+Pj4+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHNlbmFrLW9zcGYtc2VnbWVu dC1yb3V0aW5nLW9zcGYNCj4+Pj52DQo+Pj4+My1leHRlbnNpb24vDQo+Pj4+IEh0bWxpemVkOiAN Cj4+Pj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wc2VuYWstb3NwZi1zZWdtZW50 LXJvdXRpbmctb3NwZnYzLWV4dA0KPj4+PmUNCj4+Pj5uc2lvbi0wMg0KPj4+PiBEaWZmOiANCj4+ Pj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wc2VuYWstb3NwZi1zZWdt ZW50LXJvdXRpbmctb3NwZg0KPj4+PnYNCj4+Pj4zLWV4dGVuc2lvbi0wMg0KPj4+PiANCj4+Pj4g QWJzdHJhY3Q6DQo+Pj4+ICBTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgZm9yIGEgZmxleGli bGUgZGVmaW5pdGlvbiBvZiBlbmQtdG8tZW5kDQo+Pj4+ICBwYXRocyB3aXRoaW4gSUdQIHRvcG9s b2dpZXMgYnkgZW5jb2RpbmcgcGF0aHMgYXMgc2VxdWVuY2VzIG9mDQo+Pj4+ICB0b3BvbG9naWNh bCBzdWItcGF0aHMsIGNhbGxlZCAic2VnbWVudHMiLiAgVGhlc2Ugc2VnbWVudHMgYXJlDQo+Pj4+ ICBhZHZlcnRpc2VkIGJ5IHRoZSBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2xzIChJUy1JUyBh bmQgT1NQRikuDQo+Pj4+IA0KPj4+PiAgVGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIG5lY2Vzc2Fy eSBPU1BGdjMgZXh0ZW5zaW9ucyB0aGF0IG5lZWQgdG8gYmUNCj4+Pj4gIGludHJvZHVjZWQgZm9y IFNlZ21lbnQgUm91dGluZy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPj4+PnN1Ym1pc3Npb24NCj4+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4gDQo+Pj4+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4+IA0KPj4+PiAuDQo+Pj4+IA0KPj4+PiANCj4+Pj4g DQo+Pj4gDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5PU1BGIG1haWxpbmcgbGlzdA0KPj5PU1BGQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+T1NQRiBtYWlsaW5nIGxpc3QNCj5PU1BGQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQoNCg== From nobody Thu Jul 3 10:35:21 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11B81A016F for ; Thu, 3 Jul 2014 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzuzO3u4gzDJ for ; Thu, 3 Jul 2014 10:35:18 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3361A0021 for ; Thu, 3 Jul 2014 10:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3520; q=dns/txt; s=iport; t=1404408918; x=1405618518; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QyBtY3/HCa2+Jx96TzycMwxlgjbpCrPff3PYlm0bSPE=; b=bcEaXT+GoXKr2Uef0W/xISrIx54lnSujxj+rf1w90gJ/gUL1Ap5sRgDl 7KVQrh3aPkr8DbC98o98GoxLWOeBzpoYR2y0kevlqapmvBy3QJKZxt1qS utEvSLkmar6ahYVxngTyRK7AUHeGmoVpN33Xy5s48vUT0pf03ECpiZoqJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAC2TtVOtJssW/2dsb2JhbABag1+/N4c/AYEidYQDAQEBBAEBAS8BBTYJAQEMBAsRAwECAQkWDwkDAgECARUoCAYNAQUCAQEFiDkNyToXjyIHBoQ9AQSadoFIhUeMfIIBgUQ7Lw X-IronPort-AV: E=Sophos;i="5.01,596,1400025600"; d="scan'208";a="103243245" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Jul 2014 17:35:16 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s63HZGEc022505; Thu, 3 Jul 2014 17:35:16 GMT Message-ID: <53B59453.9040100@cisco.com> Date: Thu, 03 Jul 2014 19:35:15 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> In-Reply-To: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/UIz88eyRs9ZKN-l7YhwxCbFf0FQ Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 17:35:21 -0000 Hi Acee, support as coauthor. thanks, Peter On 7/3/14 17:45 , Acee Lindem wrote: > Hi, > > I’d like to start a 2 week OSPF WG adoption poll of the subject draft. The encodings are very close to those in the OSPFv2 draft (which is a WG document) other than the fact that they take advantage of the OSPFv3 LSA extensions which simplifies things. However, it makes a lot of sense to advance these drafts separately since the OSPFv2 draft is not dependent on any other drafts and there are existing implementations. > > Thanks, > Acee > > On Jul 2, 2014, at 1:48 PM, Acee Lindem wrote: > >> Hi Peter, >> I will review this version and start the adoption poll. >> >> Others - please read and comment. >> >> Thanks, >> Acee >> On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >> >>> Acee, WG, >>> >>> I have updated the OSPFv3 SR extension draft. >>> >>> Given that OSPFv2 SR extension draft has been accepted as a WG item, it would make a lot of sense to make the OSPFv3 SR draft WG document as well. >>> >>> thanks, >>> Peter >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Date: Wed, 2 Jul 2014 04:47:17 -0700 >>> From: >>> To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , Wim Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler >>> >>> >>> A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> has been successfully submitted by Peter Psenak and posted to the >>> IETF repository. >>> >>> Name: draft-psenak-ospf-segment-routing-ospfv3-extension >>> Revision: 02 >>> Title: OSPFv3 Extensions for Segment Routing >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 29 >>> URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv3-extension/ >>> Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-ospfv3-extension-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-psenak-ospf-segment-routing-ospfv3-extension-02 >>> >>> Abstract: >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>> >>> This draft describes the necessary OSPFv3 extensions that need to be >>> introduced for Segment Routing. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> . >>> >>> >>> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Fri Jul 4 02:57:30 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CA41B2CB2 for ; Fri, 4 Jul 2014 02:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJIrhRdwn4f2 for ; Fri, 4 Jul 2014 02:57:26 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF09D1B2CB1 for ; Fri, 4 Jul 2014 02:57:25 -0700 (PDT) Received: from [92.40.249.195] (helo=[172.20.10.4]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X30F8-0005sZ-A9; Fri, 04 Jul 2014 10:57:22 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Rob Shakir In-Reply-To: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> Date: Fri, 4 Jul 2014 10:57:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> To: Acee Lindem X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/daC5Ng09RzQwwUPIwg1XPivMYeQ Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2014 09:57:28 -0000 Hi Acee, Support as a co-author. Kind regards, r. On 3 Jul 2014, at 16:45, Acee Lindem wrote: > Hi,=20 >=20 > I=92d like to start a 2 week OSPF WG adoption poll of the subject = draft. The encodings are very close to those in the OSPFv2 draft (which = is a WG document) other than the fact that they take advantage of the = OSPFv3 LSA extensions which simplifies things. However, it makes a lot = of sense to advance these drafts separately since the OSPFv2 draft is = not dependent on any other drafts and there are existing = implementations.=20 >=20 > Thanks, > Acee >=20 > On Jul 2, 2014, at 1:48 PM, Acee Lindem = wrote: >=20 >> Hi Peter,=20 >> I will review this version and start the adoption poll.=20 >>=20 >> Others - please read and comment.=20 >>=20 >> Thanks,=20 >> Acee >> On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >>=20 >>> Acee, WG, >>>=20 >>> I have updated the OSPFv3 SR extension draft. >>>=20 >>> Given that OSPFv2 SR extension draft has been accepted as a WG item, = it would make a lot of sense to make the OSPFv3 SR draft WG document as = well. >>>=20 >>> thanks, >>> Peter >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for = draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Date: Wed, 2 Jul 2014 04:47:17 -0700 >>> From: >>> To: Stefano Previdi , Jeff Tantsura = , Jeff Tantsura = , "Rob Shakir" , Hannes = Gredler , "Wim Henderickx" = , Clarence Filsfils = , Wim Henderickx = , Peter Psenak , = Stefano Previdi , Clarence Filsfils = , Peter Psenak , "Rob Shakir" = , Hannes Gredler >>>=20 >>>=20 >>> A new version of I-D, = draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> has been successfully submitted by Peter Psenak and posted to the >>> IETF repository. >>>=20 >>> Name: = draft-psenak-ospf-segment-routing-ospfv3-extension >>> Revision: 02 >>> Title: OSPFv3 Extensions for Segment Routing >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 29 >>> URL: = http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-ospf= v3-extension-02.txt >>> Status: = https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv3-= extension/ >>> Htmlized: = http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-ospfv3-extens= ion-02 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-psenak-ospf-segment-routing-ospfv= 3-extension-02 >>>=20 >>> Abstract: >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>>=20 >>> This draft describes the necessary OSPFv3 extensions that need to be >>> introduced for Segment Routing. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>> . >>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Fri Jul 4 05:14:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B41B2D84 for ; Fri, 4 Jul 2014 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDBg8pq3gWHm for ; Fri, 4 Jul 2014 05:14:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E596A1B2D66 for ; Fri, 4 Jul 2014 05:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3661; q=dns/txt; s=iport; t=1404476076; x=1405685676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ToEzDVMlZBxWwQEVKMCuMRMcZBFUpRVocbbZeM0ru74=; b=T48uOsJRzcXkIwjYaCEo1KSO5haWT4zwlWxIp+JFD/l+0BvuPjdMUPPH Y403i1YGDpGwpEIl5jIc84zK7KyfGvtG2T+gNRSKEsCnTw6vBU9ndapEr FyyJbdSUb7ddJgrN9jyD4ysaQXXotFv8uxyhP/X+B4x0+IHFJhGBbvJd3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAKSZtlOtJA2K/2dsb2JhbABagw5SWr5qhz8BgQ0WdYQDAQEBAwEBAQFrCQIFBwQCAQgRAwECAS4nCx0IAgQOBQmIMQgNyhwXjm8zBwaDJ4EWBZp2gUiSRIIBgUJsgUQ X-IronPort-AV: E=Sophos;i="5.01,600,1400025600"; d="scan'208";a="58327425" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 04 Jul 2014 12:14:36 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s64CEaR5021232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 12:14:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 07:14:36 -0500 From: "Stefano Previdi (sprevidi)" To: Acee Lindem Thread-Topic: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Thread-Index: AQHPletk1H/nN8GkzEGFWrcyHQ5wyg== Date: Fri, 4 Jul 2014 12:14:35 +0000 Message-ID: <67E1ADA0-87FF-42F5-97CE-27BC0DC0D464@cisco.com> References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> In-Reply-To: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6E9709D38086A742AE26A401882BDF30@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0AbOefK4JWmNKBEwq68Mcq94hLc Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2014 12:14:40 -0000 support as co-author. s. On Jul 3, 2014, at 5:45 PM, Acee Lindem wrote: > Hi,=20 >=20 > I=92d like to start a 2 week OSPF WG adoption poll of the subject draft. = The encodings are very close to those in the OSPFv2 draft (which is a WG do= cument) other than the fact that they take advantage of the OSPFv3 LSA exte= nsions which simplifies things. However, it makes a lot of sense to advance= these drafts separately since the OSPFv2 draft is not dependent on any oth= er drafts and there are existing implementations.=20 >=20 > Thanks, > Acee >=20 > On Jul 2, 2014, at 1:48 PM, Acee Lindem wrote: >=20 >> Hi Peter,=20 >> I will review this version and start the adoption poll.=20 >>=20 >> Others - please read and comment.=20 >>=20 >> Thanks,=20 >> Acee >> On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >>=20 >>> Acee, WG, >>>=20 >>> I have updated the OSPFv3 SR extension draft. >>>=20 >>> Given that OSPFv2 SR extension draft has been accepted as a WG item, it= would make a lot of sense to make the OSPFv3 SR draft WG document as well. >>>=20 >>> thanks, >>> Peter >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-psenak-ospf-segment-routing= -ospfv3-extension-02.txt >>> Date: Wed, 2 Jul 2014 04:47:17 -0700 >>> From: >>> To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , W= im Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler >>>=20 >>>=20 >>> A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extensio= n-02.txt >>> has been successfully submitted by Peter Psenak and posted to the >>> IETF repository. >>>=20 >>> Name: draft-psenak-ospf-segment-routing-ospfv3-extension >>> Revision: 02 >>> Title: OSPFv3 Extensions for Segment Routing >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 29 >>> URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-rout= ing-ospfv3-extension-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-rout= ing-ospfv3-extension/ >>> Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-= ospfv3-extension-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-psenak-ospf-segment-rout= ing-ospfv3-extension-02 >>>=20 >>> Abstract: >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>>=20 >>> This draft describes the necessary OSPFv3 extensions that need to be >>> introduced for Segment Routing. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>> . >>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Sat Jul 5 01:08:27 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F571A039A for ; Sat, 5 Jul 2014 01:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5RZZxPfElOj for ; Sat, 5 Jul 2014 01:08:23 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1E81A0397 for ; Sat, 5 Jul 2014 01:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3529; q=dns/txt; s=iport; t=1404547704; x=1405757304; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ApHOnlHsfAGU4FZVNB7ad4rT+0QonQ6cQwP1qsc2UBw=; b=HTduGGZEnRBjf3U33IkaBXxhpf0WskoddS9sTDBWGrbHFc5EGK+tw0x1 nJkxbsgFivVO1gUL5eSvImf6/9gIGP8zEUd5WYHvbc+lzY8BmbDhWhV4X f29wH2iipJ3TMMcVjMpKrPIM1JxXSiH/KT9Tkuc2ay6AKCln3XvDa6zr5 I=; X-IronPort-AV: E=Sophos;i="5.01,606,1400025600"; d="scan'208";a="42461787" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 05 Jul 2014 08:08:21 +0000 Received: from [10.70.230.55] (tky-vpn-client-230-55.cisco.com [10.70.230.55]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6588Jdf004427; Sat, 5 Jul 2014 08:08:19 GMT Message-ID: <53B7B275.2080804@cisco.com> Date: Sat, 05 Jul 2014 17:08:21 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: acee.lindem@ericsson.com, undisclosed-recipients:; References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> In-Reply-To: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/GQQqbR8yovqVOBAqpVLsIjNgps4 Cc: ospf@ietf.org Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jul 2014 08:08:25 -0000 I read the draft. Support. Regards, -Shishio (2014/07/04 0:45), Acee Lindem wrote: > Hi, > > I$B!G(Bd like to start a 2 week OSPF WG adoption poll of the subject draft. The encodings are very close to those in the OSPFv2 draft (which is a WG document) other than the fact that they take advantage of the OSPFv3 LSA extensions which simplifies things. However, it makes a lot of sense to advance these drafts separately since the OSPFv2 draft is not dependent on any other drafts and there are existing implementations. > > Thanks, > Acee > > On Jul 2, 2014, at 1:48 PM, Acee Lindem wrote: > >> Hi Peter, >> I will review this version and start the adoption poll. >> >> Others - please read and comment. >> >> Thanks, >> Acee >> On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >> >>> Acee, WG, >>> >>> I have updated the OSPFv3 SR extension draft. >>> >>> Given that OSPFv2 SR extension draft has been accepted as a WG item, it would make a lot of sense to make the OSPFv3 SR draft WG document as well. >>> >>> thanks, >>> Peter >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Date: Wed, 2 Jul 2014 04:47:17 -0700 >>> From: >>> To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , Wim Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler >>> >>> >>> A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> has been successfully submitted by Peter Psenak and posted to the >>> IETF repository. >>> >>> Name: draft-psenak-ospf-segment-routing-ospfv3-extension >>> Revision: 02 >>> Title: OSPFv3 Extensions for Segment Routing >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 29 >>> URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv3-extension/ >>> Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-ospfv3-extension-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-psenak-ospf-segment-routing-ospfv3-extension-02 >>> >>> Abstract: >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>> >>> This draft describes the necessary OSPFv3 extensions that need to be >>> introduced for Segment Routing. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> . >>> >>> >>> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Sat Jul 5 13:49:02 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8A1B2858 for ; Sat, 5 Jul 2014 13:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUu1Ie_6NdmX for ; Sat, 5 Jul 2014 13:48:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9624F1B284E for ; Sat, 5 Jul 2014 13:48:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AB0CD1801AE; Sat, 5 Jul 2014 13:48:39 -0700 (PDT) To: acee.lindem@ericsson.com, akr@cisco.com, sina@cisco.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140705204839.AB0CD1801AE@rfc-editor.org> Date: Sat, 5 Jul 2014 13:48:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/jpfP8_cZBap-0Fhx06GyArteaUM Cc: ospf@ietf.org, jyoung@gsu.edu, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC6549 (4041) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jul 2014 20:49:00 -0000 The following errata report has been submitted for RFC6549, "OSPFv2 Multi-Instance Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6549&eid=4041 -------------------------------------- Type: Editorial Reported by: Jim Young Section: 8 Original Text ------------- 8. IANA Considerations The size of the AuType field is reduced from 16 octets to 8 octets. This changes the OSPF Authentication Codes registry in that the values 256-65535 are no longer defined and are therefore deprecated. There is no backward compatibility issue since this range of values was previously defined as "Reserved and should not be assigned". Corrected Text -------------- 8. IANA Considerations The size of the AuType field is reduced from 16 bits to 8 bits. This changes the OSPF Authentication Codes registry in that the values 256-65535 are no longer defined and are therefore deprecated. There is no backward compatibility issue since this range of values was previously defined as "Reserved and should not be assigned". Notes ----- Earlier in RFC6549 Section 2. OSPFv2 Instance Packet Encoding, Paragraph 2 states "All fields are as defined in [OSPFV2] except that the Instance ID field is new, and the AuType field is reduced to 8 bits from 16 bits without any change in meaning. The Instance ID field is defined as follows:". The proposed corrected text makes section 8 consistent with section 2. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6549 (draft-ietf-ospf-multi-instance-09) -------------------------------------- Title : OSPFv2 Multi-Instance Extensions Publication Date : March 2012 Author(s) : A. Lindem, A. Roy, S. Mirtorabi Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Jul 6 05:41:40 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051CB1A0120 for ; Sun, 6 Jul 2014 05:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvj1hOwFvFIp for ; Sun, 6 Jul 2014 05:41:35 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31C81A011C for ; Sun, 6 Jul 2014 05:41:34 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:52186 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X3ll6-0003le-Oo; Sun, 06 Jul 2014 12:41:33 +0000 From: "Russ White" To: "'OSPF List'" Date: Sun, 6 Jul 2014 08:41:26 -0400 Message-ID: <02df01cf9917$9b05a650$d110f2f0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+ZFv4nWa+hKUOQQ8u/arcrmksngA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2mXVkvWjfpXcc0dnUefzVYCdIf8 Cc: 'Alia Atlas' Subject: [OSPF] draft-atlas-ospf-mrt-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jul 2014 12:41:37 -0000 Just one question/comment on this draft -- In section 6.1, MRT-Ineligible Links TLV for OSPFv2, the draft says there should be a new TLV in the router capabilities LSA that advertises links not to be included in the MRT calculation (excluded links). I'm not certain why an option isn't used in the LSA header for this, instead. Two things that seem strange to me: - The exclusion of a link is a link property, not a router property, so I'm not certain why this would be advertised as a property of the OSPF router. This seems to muddy the line between router and properties and link properties in a way that sets the stage for make the router capabilities just another area into which to stuff various bits of information we can't find a home for elsewhere. - If you modify a specific link state, then you must advertise two TLVs, or rather two LSAs, rather than one. Thus these two pieces of information must be connected in a local database, but advertised separately, with all the coordination/etc. that implies. It seems like it might be better to move this bit of information into the TLV where the actual link state is advertised in some way. :-) Russ From nobody Mon Jul 7 07:06:21 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE4B1A0104 for ; Mon, 7 Jul 2014 07:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0rTQGXwRQ-T for ; Mon, 7 Jul 2014 07:06:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F09A1A00FF for ; Mon, 7 Jul 2014 07:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3892; q=dns/txt; s=iport; t=1404741978; x=1405951578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=os/Gwssnm1dor4DOHui6DlPtUM86chW/Oj4VPwfnV2g=; b=Zr9AQyhM0Fb6lvaeMOPh1B6pzn/qmP+iF2SE9ecVQMbrDOe2uYw9LSO8 XVLeGfwpM8vnqxkPhxujrVhA6MyoKOwiPZeDNbZ2uuAf9HmcZK1KI/enF PGRnX+5bM25uTOM63rL8Egu/FCEs+kx2EH+gYipo09QA+/Ri5UpjAH4Xv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMKADGoulOtJA2G/2dsb2JhbABagw5SUwe+dYdFAYEVFnWEAwEBAQQBAQE3NAkCDAQCAQgRAwEBAQEKFAkHJwsUCQgCBA4FCAGIOQgFyWkXjnExBwaDJ4EWBZw+kkSCAYFCgjA X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="338172620" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2014 14:06:17 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s67E6H85013818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 14:06:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 09:06:16 -0500 From: "Les Ginsberg (ginsberg)" To: Acee Lindem Thread-Topic: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt Thread-Index: AQHPlh3gUKs8gPBNOUuqeHTSee4S3puO0yIAgAXZzZA= Date: Mon, 7 Jul 2014 14:06:16 +0000 Message-ID: References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> In-Reply-To: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.103.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/m5hi0wbN9mXt6jy352naG0ZxIl4 Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 14:06:20 -0000 Support. Les > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > Sent: Thursday, July 03, 2014 8:45 AM > Cc: OSPF List > Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf- > segment-routing-ospfv3-extension-02.txt >=20 > Hi, >=20 > I'd like to start a 2 week OSPF WG adoption poll of the subject draft. Th= e > encodings are very close to those in the OSPFv2 draft (which is a WG > document) other than the fact that they take advantage of the OSPFv3 LSA > extensions which simplifies things. However, it makes a lot of sense to > advance these drafts separately since the OSPFv2 draft is not dependent o= n > any other drafts and there are existing implementations. >=20 > Thanks, > Acee >=20 > On Jul 2, 2014, at 1:48 PM, Acee Lindem > wrote: >=20 > > Hi Peter, > > I will review this version and start the adoption poll. > > > > Others - please read and comment. > > > > Thanks, > > Acee > > On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: > > > >> Acee, WG, > >> > >> I have updated the OSPFv3 SR extension draft. > >> > >> Given that OSPFv2 SR extension draft has been accepted as a WG item, i= t > would make a lot of sense to make the OSPFv3 SR draft WG document as > well. > >> > >> thanks, > >> Peter > >> > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for draft-psenak-ospf-segment- > routing-ospfv3-extension-02.txt > >> Date: Wed, 2 Jul 2014 04:47:17 -0700 > >> From: > >> To: Stefano Previdi , Jeff Tantsura > , Jeff Tantsura , > "Rob Shakir" , Hannes Gredler , > "Wim Henderickx" , Clarence Filsfils > , Wim Henderickx lucent.com>, Peter Psenak , Stefano Previdi > , Clarence Filsfils , Peter Psena= k > , "Rob Shakir" , Hannes Gredler > > >> > >> > >> A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3- > extension-02.txt > >> has been successfully submitted by Peter Psenak and posted to the > >> IETF repository. > >> > >> Name: draft-psenak-ospf-segment-routing-ospfv3- > extension > >> Revision: 02 > >> Title: OSPFv3 Extensions for Segment Routing > >> Document date: 2014-07-02 > >> Group: Individual Submission > >> Pages: 29 > >> URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment- > routing-ospfv3-extension-02.txt > >> Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment- > routing-ospfv3-extension/ > >> Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing= - > ospfv3-extension-02 > >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-psenak-ospf-segment- > routing-ospfv3-extension-02 > >> > >> Abstract: > >> Segment Routing (SR) allows for a flexible definition of end-to-end > >> paths within IGP topologies by encoding paths as sequences of > >> topological sub-paths, called "segments". These segments are > >> advertised by the link-state routing protocols (IS-IS and OSPF). > >> > >> This draft describes the necessary OSPFv3 extensions that need to be > >> introduced for Segment Routing. > >> > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> . > >> > >> > >> > > >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Mon Jul 7 07:49:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBB11A01E1 for ; Mon, 7 Jul 2014 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWKhqBXQxC43 for ; Mon, 7 Jul 2014 07:49:31 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA37E1A0208 for ; Mon, 7 Jul 2014 07:49:29 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-1b-53ba5ee0a278 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E5.F8.25146.0EE5AB35; Mon, 7 Jul 2014 10:48:32 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 10:49:22 -0400 From: Acee Lindem To: RFC Errata System , "akr@cisco.com" , "sina@cisco.com" , "akatlas@gmail.com" , "adrian@olddog.co.uk" Thread-Topic: [Editorial Errata Reported] RFC6549 (4041) Thread-Index: AQHPmJKNxjoWdpTHVkqOX+Lcw1uGsZuUgdsA Date: Mon, 7 Jul 2014 14:49:21 +0000 Message-ID: References: <20140705204839.AB0CD1801AE@rfc-editor.org> In-Reply-To: <20140705204839.AB0CD1801AE@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <34E078399E6E004C9C44B248BC1C1BDE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyuXRPgu6DuF3BBpduS1j86LnBbPHp4SVm i8MHZ7FZtPYeZLZouXeP3aJp/1c2izcf+1gc2D2m/N7I6rFz1l12j73XJ7F5LFnyk8ljxeaV jB4NbcdYA9iiuGxSUnMyy1KL9O0SuDJe/l7KUvBGvOL57YVMDYzbhLsYOTkkBEwkWrovskPY YhIX7q1n62Lk4hASOMoosXLtZChnGaPEnns32UCq2AR0JJ4/+scMkhAROM8o8eHADBaQBLOA m8SiJfdYQWxhAXOJQ/+6mEBsEQELiaN3/gPZHEC2kUTPCxYQk0VARWLHGReQCl4BU4muR18Z QWwhoM41i+aBreIE6tzZcpgZxGYEOu77qTVMEJvEJW49mc8EcbSAxJI955khbFGJl4//gV0g KqAn0dz1hhEiriTx8fd8doheHYkFuz+xQdjWEq/+3oWKa0ssW/iaGeIeQYmTM5+wTGCUmIVk 3Swk7bOQtM9C0j4LSfsCRtZVjBylxalluelGhpsYgXF8TILNcQfjgk+WhxgFOBiVeHgTwnYG C7EmlhVX5h5ilOZgURLn1ayeFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0cDrQEzJ7B9H O1fYSso5vN408e45i+DVgSdOL1y4e3bel5wad5dcM8WPdvqR1eohFd75i45X3Xm65oLk0x6/ L4V6qp8PtSm3eyTPtmdy5GpdPEPjrsDFq90XbvDV7bpgu3hZ16QNMx2UObOmrLydVC+9k332 5V39G25bc85QS38nY37ZVWvDdiWW4oxEQy3mouJEAIC8dTfEAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/DlvBJ4de1FtjPvNwVT-CPu2oIkI Cc: "ospf@ietf.org" , "jyoung@gsu.edu" Subject: Re: [OSPF] [Editorial Errata Reported] RFC6549 (4041) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 14:49:34 -0000 Hi Alia,=20 I agree with this errata. Note that the AuType field size is correctly depicted in section 2 of RFC 6549. Thanks, Acee=20 -----Original Message----- From: RFC Errata System Date: Saturday, July 5, 2014 at 1:48 PM To: Ericsson , Abhay Roy , Sina Mirtorabi , Alia Atlas , Adrian Farrel , Abhay Roy , Ericsson Cc: "jyoung@gsu.edu" , OSPF - OSPF WG List , "rfc-editor@rfc-editor.org" Subject: [Editorial Errata Reported] RFC6549 (4041) >The following errata report has been submitted for RFC6549, >"OSPFv2 Multi-Instance Extensions". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D6549&eid=3D4041 > >-------------------------------------- >Type: Editorial >Reported by: Jim Young > >Section: 8 > >Original Text >------------- >8. IANA Considerations > >The size of the AuType field is reduced from 16 octets to 8 octets. >This changes the OSPF Authentication Codes registry in that the >values 256-65535 are no longer defined and are therefore deprecated. >There is no backward compatibility issue since this range of values >was previously defined as "Reserved and should not be assigned". > > >Corrected Text >-------------- >8. IANA Considerations > >The size of the AuType field is reduced from 16 bits to 8 bits. >This changes the OSPF Authentication Codes registry in that the >values 256-65535 are no longer defined and are therefore deprecated. >There is no backward compatibility issue since this range of values >was previously defined as "Reserved and should not be assigned". > > >Notes >----- >Earlier in RFC6549 Section 2. OSPFv2 Instance Packet Encoding, Paragraph >2 states "All fields are as defined in [OSPFV2] except that the Instance >ID field is new, and the AuType field is reduced to 8 bits from 16 bits >without any change in meaning. The Instance ID field is defined as >follows:". The proposed corrected text makes section 8 consistent with >section 2. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC6549 (draft-ietf-ospf-multi-instance-09) >-------------------------------------- >Title : OSPFv2 Multi-Instance Extensions >Publication Date : March 2012 >Author(s) : A. Lindem, A. Roy, S. Mirtorabi >Category : PROPOSED STANDARD >Source : Open Shortest Path First IGP >Area : Routing >Stream : IETF >Verifying Party : IESG From nobody Mon Jul 7 14:06:29 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF31B290B; Mon, 7 Jul 2014 14:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHKck0Y6s4P3; Mon, 7 Jul 2014 14:06:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC211B28CC; Mon, 7 Jul 2014 14:06:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D5B1918001B; Mon, 7 Jul 2014 14:05:57 -0700 (PDT) To: jyoung@gsu.edu, acee.lindem@ericsson.com, akr@cisco.com, sina@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140707210557.D5B1918001B@rfc-editor.org> Date: Mon, 7 Jul 2014 14:05:57 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OkGsZr8iaBfSBw7RIwLfn6Rog6o Cc: ospf@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Errata Verified] RFC6549 (4041) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 21:06:24 -0000 The following errata report has been verified for RFC6549, "OSPFv2 Multi-Instance Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6549&eid=4041 -------------------------------------- Status: Verified Type: Editorial Reported by: Jim Young Date Reported: 2014-07-05 Verified by: Alia Atlas (IESG) Section: 8 Original Text ------------- 8. IANA Considerations The size of the AuType field is reduced from 16 octets to 8 octets. This changes the OSPF Authentication Codes registry in that the values 256-65535 are no longer defined and are therefore deprecated. There is no backward compatibility issue since this range of values was previously defined as "Reserved and should not be assigned". Corrected Text -------------- 8. IANA Considerations The size of the AuType field is reduced from 16 bits to 8 bits. This changes the OSPF Authentication Codes registry in that the values 256-65535 are no longer defined and are therefore deprecated. There is no backward compatibility issue since this range of values was previously defined as "Reserved and should not be assigned". Notes ----- Earlier in RFC6549 Section 2. OSPFv2 Instance Packet Encoding, Paragraph 2 states "All fields are as defined in [OSPFV2] except that the Instance ID field is new, and the AuType field is reduced to 8 bits from 16 bits without any change in meaning. The Instance ID field is defined as follows:". The proposed corrected text makes section 8 consistent with section 2. -------------------------------------- RFC6549 (draft-ietf-ospf-multi-instance-09) -------------------------------------- Title : OSPFv2 Multi-Instance Extensions Publication Date : March 2012 Author(s) : A. Lindem, A. Roy, S. Mirtorabi Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jul 8 03:52:26 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D531B27E7 for ; Tue, 8 Jul 2014 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PknK_2UdKeH7 for ; Tue, 8 Jul 2014 03:52:23 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150AE1A0205 for ; Tue, 8 Jul 2014 03:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3512; q=dns/txt; s=iport; t=1404816744; x=1406026344; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hcdPOyBekO5r5D9Ip/SYInMNPZyTu5OyrMlHhEYshsY=; b=OAO36dpVWUjUkKUJEkhzH1aG/o/OrFh3K288suopw3zu9jyWHZbupWHB g+ctmE5790o3VVvm/p5BEWtKAeFRNrAstGfrdi+ZNN+dWKHjYZGDp+uk3 yykkSSqVYidsOUNO6vfvW2xtz8CC7ux0wMWpEfWOsxf7MNtg+5zVQglxn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAADMu1OtJssW/2dsb2JhbABZg2C/TYdEAYEsdYN7CAEBAQQBAQEvAQU2CQEBDAQLEQMBAgEJFg8JAwIBAgEVKAgGBgcBBQIBAQWFbYJMDckUF48iBwaDAIE9AQSadoFIiyKHIoIBgUQ7Lw X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208";a="102435478" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2014 10:52:23 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s68AqKdN001626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 10:52:21 GMT Message-ID: <53BBCD64.5090103@cisco.com> Date: Tue, 08 Jul 2014 12:52:20 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Acee Lindem , undisclosed-recipients:; References: <20140702114717.7506.67351.idtracker@ietfa.amsl.com> <53B3FF33.1000109@cisco.com> <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> In-Reply-To: <87E367DF-B25B-4C0E-AB92-AAA175443DF4@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/IRpddPB5xgHsBRPf5sa05oDCZHM Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 10:52:25 -0000 Support to accept as WG work. Anton On 07/03/2014 05:45 PM, Acee Lindem wrote: > Hi, > > I’d like to start a 2 week OSPF WG adoption poll of the subject draft. The encodings are very close to those in the OSPFv2 draft (which is a WG document) other than the fact that they take advantage of the OSPFv3 LSA extensions which simplifies things. However, it makes a lot of sense to advance these drafts separately since the OSPFv2 draft is not dependent on any other drafts and there are existing implementations. > > Thanks, > Acee > > On Jul 2, 2014, at 1:48 PM, Acee Lindem wrote: > >> Hi Peter, >> I will review this version and start the adoption poll. >> >> Others - please read and comment. >> >> Thanks, >> Acee >> On Jul 2, 2014, at 8:46 AM, Peter Psenak wrote: >> >>> Acee, WG, >>> >>> I have updated the OSPFv3 SR extension draft. >>> >>> Given that OSPFv2 SR extension draft has been accepted as a WG item, it would make a lot of sense to make the OSPFv3 SR draft WG document as well. >>> >>> thanks, >>> Peter >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Date: Wed, 2 Jul 2014 04:47:17 -0700 >>> From: >>> To: Stefano Previdi , Jeff Tantsura , Jeff Tantsura , "Rob Shakir" , Hannes Gredler , "Wim Henderickx" , Clarence Filsfils , Wim Henderickx , Peter Psenak , Stefano Previdi , Clarence Filsfils , Peter Psenak , "Rob Shakir" , Hannes Gredler >>> >>> >>> A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> has been successfully submitted by Peter Psenak and posted to the >>> IETF repository. >>> >>> Name: draft-psenak-ospf-segment-routing-ospfv3-extension >>> Revision: 02 >>> Title: OSPFv3 Extensions for Segment Routing >>> Document date: 2014-07-02 >>> Group: Individual Submission >>> Pages: 29 >>> URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-ospfv3-extension/ >>> Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-ospfv3-extension-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-psenak-ospf-segment-routing-ospfv3-extension-02 >>> >>> Abstract: >>> Segment Routing (SR) allows for a flexible definition of end-to-end >>> paths within IGP topologies by encoding paths as sequences of >>> topological sub-paths, called "segments". These segments are >>> advertised by the link-state routing protocols (IS-IS and OSPF). >>> >>> This draft describes the necessary OSPFv3 extensions that need to be >>> introduced for Segment Routing. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> . >>> >>> >>> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Jul 8 04:11:34 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B031B27E5 for ; Tue, 8 Jul 2014 04:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEkJpEyqCxg1 for ; Tue, 8 Jul 2014 04:11:25 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6651B27F7 for ; Tue, 8 Jul 2014 04:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2618; q=dns/txt; s=iport; t=1404817877; x=1406027477; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ZyCBr0N5tPwZkNZ06ZaU6Z9H55lclNVfVkyU8ONlH/Q=; b=SSqqn9NYEA1Mm2GKr0iWrcn70QlfQf/oWKImnyQ2SsEVDRzvqYl139jM 5wXW5ezMcG70iG23IbLwaukLgpoc8Pntpv2bJ7cZL0Em4xvnp6Ebi7I62 vEHBU/K8pUQI0GuQATM52m7rRO+a+da601PPWmd/Rh2MsQRSq8I7xBAMC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwHAJXRu1OtJssW/2dsb2JhbABZg2BTvnqHRAGBK3WEAwEBAQQBAQE1NgkBDQQLEQQBAQEJFggHCQMCAQIBFR8IAQgGAQwGAgEBBYg5CAXJEBePKQaEPQEEllyEGoFIkkSCAYFEOy8 X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208";a="106549376" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 08 Jul 2014 11:11:09 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s68BB94P001635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 11:11:09 GMT Message-ID: <53BBD1CD.9070406@cisco.com> Date: Tue, 08 Jul 2014 13:11:09 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ing-Wher Chen , "ospf@ietf.org" References: <20140702132630.1320.28041.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/enFUocwmPjAemTKpQak-IcIEaAg Subject: Re: [OSPF] FW: New Version Notification for draft-chen-ospf-transition-to-ospfv3-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 11:11:32 -0000 Hi Helen, I believe encapsulation choice is per-link decision, i.e. there shouldn't be any problems in running IPv4 AF OSPFv3 over IPv4 on one link of a router and IPv4 AF OSPFv3 over IPv6 on another link as long as all routers connected to each link use the same encapsulation. Likewise, if IPv4 AF VL packets themselves are IPv4-encapsulated it shouldn't matter if physical links are using IPv6 or IPv4 encapsulation. The draft's text could be more clear on this aspect. Anton On 07/02/2014 04:02 PM, Ing-Wher Chen wrote: > Hello, > > Acee, Ran, and I have updated the following draft to address the feedback at the last meeting and on the mailing list. In particular, a new section on IPv4 use case has been added, and the edits that Karsten suggested back on Feb. 17, 2014 have also been incorporated. > > Thanks, > Helen > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 02, 2014 9:27 AM > To: R. Atkinson; Ing-Wher Chen; Ing-Wher Chen; Acee Lindem; Acee Lindem > Subject: New Version Notification for draft-chen-ospf-transition-to-ospfv3-01.txt > > > A new version of I-D, draft-chen-ospf-transition-to-ospfv3-01.txt > has been successfully submitted by I. Chen and posted to the IETF repository. > > Name: draft-chen-ospf-transition-to-ospfv3 > Revision: 01 > Title: OSPFv3 over IPv4 for IPv6 Transition > Document date: 2014-07-02 > Group: Individual Submission > Pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-chen-ospf-transition-to-ospfv3-01.txt > Status: https://datatracker.ietf.org/doc/draft-chen-ospf-transition-to-ospfv3/ > Htmlized: http://tools.ietf.org/html/draft-chen-ospf-transition-to-ospfv3-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-chen-ospf-transition-to-ospfv3-01 > > Abstract: > This document defines a mechanism to use IPv4 to transport OSPFv3 > packets, in order to facilitate transition from IPv4-only to IPv6 and > dual-stack within a routing domain. Using OSPFv3 over IPv4 with the > existing OSPFv3 Address Family extension can simplify transition from > an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing > domain. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Jul 8 11:08:22 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3481A0390 for ; Tue, 8 Jul 2014 11:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL8XIwyvdhr2 for ; Tue, 8 Jul 2014 11:08:18 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675D91A0165 for ; Tue, 8 Jul 2014 11:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7361; q=dns/txt; s=iport; t=1404842897; x=1406052497; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Tn6/Q5/ah15WNTkdpyRdKexUMp4C60sgs9YIWrDaRY0=; b=C2wCO/dJWzSeHZLLRM4w0C84wrToEWIXlFIg0lXCSc7YX/3oBX/f0Soy YZ87IYb7+7OOYy/mwSS1R2u+Eqsuauoqp0K1BY8DavooiiYZtIEq9gH3u rxidQ996aJ5QgeQZxZzCQYYdzHiMY9Ho6aAGrafURIYAjbaRHCU40O8GR o=; X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="102628362" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2014 18:08:15 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s68I8Ckf028615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 18:08:15 GMT Message-ID: <53BC338C.9090808@cisco.com> Date: Tue, 08 Jul 2014 20:08:12 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Peter Psenak , Acee Lindem References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> <53B50FBC.60803@cisco.com> In-Reply-To: <53B50FBC.60803@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/r6Q4w-ucHW-cch1eYiui6wJ05PE Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 18:08:20 -0000 Hi Peter, in current text ranges are not required to be processed and I think this kills their potential usage: If multiple Prefix-SIDs are advertised for the same prefix, the receiving router MUST use the first encoded SID and MAY use the subsequent ones. (and similar text for inter-area LSA origination). Subsequent prefixes may be used or may be ignored. And if they are ignored then it is originator's fault, receiver has all rights to ignore them. If the mapping server wants to ensure every router installs prefix attributes then it has no choice but to break the range and advertise each prefix individually. So IMO ranges processing must be required on every step, otherwise they will never be used. > high level TLV advertise a single prefix/mask. It's the sub-TLV which > may extend the applicability to the range if required, so the scope is > defined by each sub-TLV. That what makes ranges counter intuitive. Intuitive hierarchy is object on the top and then subordinate items describing properties of the object: Object --- | |- attribute1 |- attribute2 But the current scheme does not define object at the top of the hierarchy, real object is defined together with property: Anchor --- | |- range-of-objects-and-attribute1 |- range-of-objects-and-attribute2 There are three problems with this representation: 1. Anchor (i.e. top level TLV) is not enough to determine which objects (i.e. prefixes) are affected and which are not 2. Set of objects (i.e. the range) may be different in each sub-TLV thus raising concerns of ambiguity 3. Text requires that anchor is advertised only once but there is no requirement that ranges advertised for different anchors cannot overlap It would have been more logical to define range in the "OSPF Extended Prefix TLV" header itself, not in each sub-TLV. This specifies the object (i.e. the range) in the topmost TLV and resolves problems mentioned above. Anton On 07/03/2014 10:09 AM, Peter Psenak wrote: > Hi Acee, > > please see inline: > > On 7/2/14 19:17 , Acee Lindem wrote: >> Hi Peter, >> It seems there are two distinct deployment scenarios - one where SR >> routers are given a range and policy and allocate their own SIDs and >> another where a mapping server does it for the routing domain. > > yes, that is correct. The latter is used mainly during migration from > LDP to SR. > > > >>>> 6. Section 4.2 - I really don’t like having his sub-TLV >>>> redefine the subsuming top-level TLV as a range of prefixes of the >>>> same length rather than a single prefix. Although this is my first >>>> serious reading of the draft, this encoding seems really unwieldy >>>> and, in practice, I’d expect the range size always advertised as 1. >>>> We can discuss this more in Toronto. >>> >>> an example where the range would be more then 1 is a mapping server >>> case. This helps you to advertise SIDs for loopback addresses of all >>> routers in a non-SR capable part of the network, assuming they are >>> allocated from the contiguous address space. Instead of advertising >>> hundreds of mappings for each /32 address, you can compact it to a >>> single advertisement. >> >> I’ve seen loopbacks allocated sequentially in a few networks but many >> more where there weren’t. > > still, having a mechanism to compact the advertisements if possible > looks appealing. > >> >>> >>> What you need in such case is component prefix/length plus the number >>> of components - OSPF Extended Prefix TLV gives you the component info >>> and Prefix SID Sub-TLV "Range Size' gives you the number of components. >> >> I understood it but I don’t like the sub-TLV extending the >> specification of the higher level TLV. I especially don’t like it >> since the top-level TLV is a generic mechanism to advertise >> attributes. When additional attributes are defined, it begs the of >> whether or not they apply solely to the prefix or to the range. > > high level TLV advertise a single prefix/mask. It's the sub-TLV which > may extend the applicability to the range if required, so the scope is > defined by each sub-TLV. > >> >>> >>> We could have defined a separate top level TLV in OSPF Extended >>> Prefix LSA for the advertisement of range of components, but it looks >>> to me that would be an overkill. >> >> I would have preferred that. When the SID attributes are embedded >> (OSPFv3 and ISIS), I think the semantics are even more unnatural since >> reachability MAY be advertised for the prefix while SID mapping is >> being advertised for the range. > > I had the same reservations at the beginning :) > But there is no problem really. Prefix-SID sub-TLV never advertises any > reachability, whether it advertises a single SID or a range of SIDs. For > Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of > "start" and Prefix-SID sub-TLV always carry its own "size" - just a > different interpretation of the data from the higher level TLV. > > Please note that SID range is quite different from the address range we > are used to from summarization. SID range requires three parameters > (address/mask and count), compared to two parameter (address/mask) that > traditional address range uses. As a result, Extended prefix TLV as such > can not cover the SID range, because it only has address/mask. Defining > a top-level TLV for a SID range itself does not really fit into Extended > Prefix LSA and having a new LSA for it is not an option I would say. So > the current encoding looks like a good compromise to me. > > thanks, > Peter > >> >>> Current encoding of Prefix SID Sub-TLV gives us all the flexibility >>> we need. In addition it matches what ISIS has done. >> >> I haven’t seen any discussion of the draft on the ISIS list other than >> the revision updates. >> >> Thanks, >> Acee >> >> >> >>> >>> >>>> >>>> 7. Section 4.2 - Shouldn’t the reference for the mapping >>>> server be the “Segment Routing Architecture” rather than the >>>> “Segment Routing Use Cases”? In general, the usage of a mapping >>>> server and the scope of assignment needs to be described better >>>> somewhere (not in the OSPF encoding document). >>> >>> will fix the reference >>> >>>> >>>> 8. Section 6 - It would seem that an entity calculating a >>>> multi-area SR path would need access to the topology for all the >>>> areas and the SID would need to be globally assigned? Right? >>> >>> correct. >>> >>>> So rules are primarily for the population of the forwarding plane. >>>> Right? >>> >>> for advertisement/propagation of SIDs and for forwarding plane >>> programming. >>> >>>> >>>> 9. Section 6.2 - In standard OSPF, inter-area summary >>>> propagation only applies to inter-area routes learned over the >>>> backbone. Is this any different? >>> >>> no, the mechanism is the same as for type-3s. >>> >>> thanks, >>> Peter >>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>> . >>>> >>> >> >> . >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Tue Jul 8 13:04:55 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213581A0025 for ; Tue, 8 Jul 2014 13:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGXSv_SqVaUS for ; Tue, 8 Jul 2014 13:04:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C40D1A0009 for ; Tue, 8 Jul 2014 13:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9441; q=dns/txt; s=iport; t=1404849891; x=1406059491; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SPYiHozQPXO0hAFxzdV6G6n1nWGJlcdC563M1NNZuWg=; b=V59AZiMtpq+SNXZkT4rHJSafmpra2MNUyyQofLF8yV3M0ltscXUZJO7E eGCndL71Y4ZY41TNJ/ZhLCnbJimFTzj8jXz2tsIo1NqkGxP4dCR9ND+li NLBs+G6WbcRnCJikIs0GpMHbER6uPGpd7zDD/3zD0lGCCKPr3Q8xWMKmX I=; X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="102673261" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2014 20:04:50 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s68K4ntx020765; Tue, 8 Jul 2014 20:04:49 GMT Message-ID: <53BC4EE3.30909@cisco.com> Date: Tue, 08 Jul 2014 22:04:51 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Anton Smirnov , Acee Lindem References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> <53B50FBC.60803@cisco.com> <53BC338C.9090808@cisco.com> In-Reply-To: <53BC338C.9090808@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/WsHXJ2weyRQ1g9DV6BdiBeVvEW4 Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 20:04:54 -0000 Anton, please see inline: On 7/8/14 20:08 , Anton Smirnov wrote: > Hi Peter, > in current text ranges are not required to be processed and I think > this kills their potential usage: > > If multiple Prefix-SIDs are advertised for the same prefix, the > receiving router MUST use the first encoded SID and MAY use the > subsequent ones. I do not see any connection between ranges and the above text. Above text says that if there are multiple prefix SIDs advertised, for a single prefix, every implementation MUST process at least the first one. Typically only a single SID will be advertised for each prefix regardless of the range being 1 or more. > > (and similar text for inter-area LSA origination). > Subsequent prefixes may be used or may be ignored. And if they are there are no subsequent prefixes. Each prefix is advertised in a separate top level TLV and will have it's own prefix-SID sub-TLV, only belonging to that prefix. > ignored then it is originator's fault, receiver has all rights to ignore > them. If the mapping server wants to ensure every router installs prefix > attributes then it has no choice but to break the range and advertise > each prefix individually. > So IMO ranges processing must be required on every step, otherwise > they will never be used. > please see above. > > > > > high level TLV advertise a single prefix/mask. It's the sub-TLV which > > may extend the applicability to the range if required, so the scope is > > defined by each sub-TLV. the way to look at it is that the top-level TLV always advertises a single prefix in a form of prefix/length. Nested sub-TLVs have their own data, which are interpreted based on the sub-TLV specification, they do not change what is in the top-level TLV. The fact that some sub-TLV has a count variable and use the prefix/mask as starting point makes no impact on the top-level data. > > That what makes ranges counter intuitive. Intuitive hierarchy is > object on the top and then subordinate items describing properties of > the object: > > Object --- > | > |- attribute1 > |- attribute2 > > > But the current scheme does not define object at the top of the > hierarchy, real object is defined together with property: > > Anchor --- > | > |- range-of-objects-and-attribute1 > |- range-of-objects-and-attribute2 > > There are three problems with this representation: > 1. Anchor (i.e. top level TLV) is not enough to determine which objects > (i.e. prefixes) are affected and which are not actually it is enough. We are not changing or replacing the top-level data. We are just using it differently - for prefix-SID sub-TLV the prefix/length in the top-level TLV is used as a 'start' object. > 2. Set of objects (i.e. the range) may be different in each sub-TLV thus > raising concerns of ambiguity this does not introduce any more ambiguity then any other encoding which includes prefix/mask/count variables. > 3. Text requires that anchor is advertised only once but there is no > requirement that ranges advertised for different anchors cannot overlap actually there is no reason why they can not overlap. We have overlaps today with prefix/mask semantics as well and we deal with them. > > It would have been more logical to define range in the "OSPF Extended > Prefix TLV" header itself, not in each sub-TLV. This specifies the > object (i.e. the range) in the topmost TLV and resolves problems > mentioned above. we wanted to preserve the prefix/length semantics well known from current OSPF. Making size mandatory would be a significant deviation from the current OSPF spec. Prefix-SID 'count' semantics is something specific to the SID and is more of an exception and IMHO should not force us to to deviate from representation we are used to work with. thanks, Peter > > Anton > > > On 07/03/2014 10:09 AM, Peter Psenak wrote: >> Hi Acee, >> >> please see inline: >> >> On 7/2/14 19:17 , Acee Lindem wrote: >>> Hi Peter, >>> It seems there are two distinct deployment scenarios - one where SR >>> routers are given a range and policy and allocate their own SIDs and >>> another where a mapping server does it for the routing domain. >> >> yes, that is correct. The latter is used mainly during migration from >> LDP to SR. >> >> >> >>>>> 6. Section 4.2 - I really don’t like having his sub-TLV >>>>> redefine the subsuming top-level TLV as a range of prefixes of the >>>>> same length rather than a single prefix. Although this is my first >>>>> serious reading of the draft, this encoding seems really unwieldy >>>>> and, in practice, I’d expect the range size always advertised as 1. >>>>> We can discuss this more in Toronto. >>>> >>>> an example where the range would be more then 1 is a mapping server >>>> case. This helps you to advertise SIDs for loopback addresses of all >>>> routers in a non-SR capable part of the network, assuming they are >>>> allocated from the contiguous address space. Instead of advertising >>>> hundreds of mappings for each /32 address, you can compact it to a >>>> single advertisement. >>> >>> I’ve seen loopbacks allocated sequentially in a few networks but many >>> more where there weren’t. >> >> still, having a mechanism to compact the advertisements if possible >> looks appealing. >> >>> >>>> >>>> What you need in such case is component prefix/length plus the number >>>> of components - OSPF Extended Prefix TLV gives you the component info >>>> and Prefix SID Sub-TLV "Range Size' gives you the number of components. >>> >>> I understood it but I don’t like the sub-TLV extending the >>> specification of the higher level TLV. I especially don’t like it >>> since the top-level TLV is a generic mechanism to advertise >>> attributes. When additional attributes are defined, it begs the of >>> whether or not they apply solely to the prefix or to the range. >> >> high level TLV advertise a single prefix/mask. It's the sub-TLV which >> may extend the applicability to the range if required, so the scope is >> defined by each sub-TLV. >> >>> >>>> >>>> We could have defined a separate top level TLV in OSPF Extended >>>> Prefix LSA for the advertisement of range of components, but it looks >>>> to me that would be an overkill. >>> >>> I would have preferred that. When the SID attributes are embedded >>> (OSPFv3 and ISIS), I think the semantics are even more unnatural since >>> reachability MAY be advertised for the prefix while SID mapping is >>> being advertised for the range. >> >> I had the same reservations at the beginning :) >> But there is no problem really. Prefix-SID sub-TLV never advertises any >> reachability, whether it advertises a single SID or a range of SIDs. For >> Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of >> "start" and Prefix-SID sub-TLV always carry its own "size" - just a >> different interpretation of the data from the higher level TLV. >> >> Please note that SID range is quite different from the address range we >> are used to from summarization. SID range requires three parameters >> (address/mask and count), compared to two parameter (address/mask) that >> traditional address range uses. As a result, Extended prefix TLV as such >> can not cover the SID range, because it only has address/mask. Defining >> a top-level TLV for a SID range itself does not really fit into Extended >> Prefix LSA and having a new LSA for it is not an option I would say. So >> the current encoding looks like a good compromise to me. >> >> thanks, >> Peter >> >>> >>>> Current encoding of Prefix SID Sub-TLV gives us all the flexibility >>>> we need. In addition it matches what ISIS has done. >>> >>> I haven’t seen any discussion of the draft on the ISIS list other than >>> the revision updates. >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> >>>> >>>>> >>>>> 7. Section 4.2 - Shouldn’t the reference for the mapping >>>>> server be the “Segment Routing Architecture” rather than the >>>>> “Segment Routing Use Cases”? In general, the usage of a mapping >>>>> server and the scope of assignment needs to be described better >>>>> somewhere (not in the OSPF encoding document). >>>> >>>> will fix the reference >>>> >>>>> >>>>> 8. Section 6 - It would seem that an entity calculating a >>>>> multi-area SR path would need access to the topology for all the >>>>> areas and the SID would need to be globally assigned? Right? >>>> >>>> correct. >>>> >>>>> So rules are primarily for the population of the forwarding plane. >>>>> Right? >>>> >>>> for advertisement/propagation of SIDs and for forwarding plane >>>> programming. >>>> >>>>> >>>>> 9. Section 6.2 - In standard OSPF, inter-area summary >>>>> propagation only applies to inter-area routes learned over the >>>>> backbone. Is this any different? >>>> >>>> no, the mechanism is the same as for type-3s. >>>> >>>> thanks, >>>> Peter >>>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>> . >>>>> >>>> >>> >>> . >>> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > . > From nobody Tue Jul 8 14:23:05 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E301A00DF for ; Tue, 8 Jul 2014 14:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDF96Q2Xoeut for ; Tue, 8 Jul 2014 14:23:01 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 073521A0071 for ; Tue, 8 Jul 2014 14:23:00 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:46443] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 1C/45-20336-4316CB35; Tue, 08 Jul 2014 21:23:00 +0000 From: Acee Lindem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 8 Jul 2014 17:22:59 -0400 To: OSPF List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ULlBrr2-2KArNKFYnvBWiEk7bSo Subject: [OSPF] IETF 90 OSPF WG Agenda X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 21:23:02 -0000 As you can see, we have a full agenda for IETF 90 in Toronto. In the = interest of time, I will be finding someone to take minutes in advance.=20= https://datatracker.ietf.org/meeting/90/agenda/ospf/ Thanks, Acee=20= From nobody Wed Jul 9 00:35:14 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FAF1A0393 for ; Wed, 9 Jul 2014 00:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4xVICi8K5ea for ; Wed, 9 Jul 2014 00:35:11 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BC01A037F for ; Wed, 9 Jul 2014 00:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10657; q=dns/txt; s=iport; t=1404891313; x=1406100913; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uzXNpPB1qXNtQvSgmoj1cMeTDhWQxfSF3K1eqDOE4g8=; b=Cm27IAI/WfTxrcy5HhVtxEmYQSpqKS3FnJTQyffS6yMm9ChvWlwg2LL8 DvDaDmMwYSvRpneGkDQE9sOARZrn5aEOYL3rHTUgWS5A6kFQwDRvhM4uc hEJbaBifLolN1giuQ/qMKabLUndtBucKbOvL5ml5DOE+n0yXKsZ8h2XP6 I=; X-IronPort-AV: E=Sophos;i="5.01,630,1400025600"; d="scan'208";a="102982380" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 09 Jul 2014 07:35:10 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s697Z72s023274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Jul 2014 07:35:07 GMT Message-ID: <53BCF0AB.4080207@cisco.com> Date: Wed, 09 Jul 2014 09:35:07 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Peter Psenak , Acee Lindem References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> <53B50FBC.60803@cisco.com> <53BC338C.9090808@cisco.com> <53BC4EE3.30909@cisco.com> In-Reply-To: <53BC4EE3.30909@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0U47qCVJcfagBt5eSTFh2-imEx0 Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 09 Jul 2014 07:35:13 -0000 Hi Peter, I don't understand your answers. Let me give an example of encoding: Extended Prefix TLV 192.0.2.1/32 Prefix SID Sub-TLV Range 2 SID/Label Binding sub-TLV Range 4 Extended Prefix TLV 192.0.2.4/32 Prefix SID Sub-TLV Range 1 SID/Label Binding sub-TLV Range 1 This is valid encoding per current text and it expands into: 192.0.2.1 - 1 SID 1 Binding 192.0.2.2 - 1 SID 1 Binding 192.0.2.3 - 1 Binding 192.0.2.4 - 1 SID 2 Bindings Obviously this encoding is very difficult to work with because ranges are different for attributes, because prefix 192.0.2.4/32 is served by two ranges. It is more logical to define range as part of top-level TLV: Extended Prefix TLV Prefix/mask; Range Prefix SID Sub-TLV SID SID/Label Binding sub-TLV Binding Anton On 07/08/2014 10:04 PM, Peter Psenak wrote: > Anton, > > please see inline: > > On 7/8/14 20:08 , Anton Smirnov wrote: >> Hi Peter, >> in current text ranges are not required to be processed and I think >> this kills their potential usage: >> >> If multiple Prefix-SIDs are advertised for the same prefix, the >> receiving router MUST use the first encoded SID and MAY use the >> subsequent ones. > > I do not see any connection between ranges and the above text. Above > text says that if there are multiple prefix SIDs advertised, for a > single prefix, every implementation MUST process at least the first one. > Typically only a single SID will be advertised for each prefix > regardless of the range being 1 or more. > >> >> (and similar text for inter-area LSA origination). >> Subsequent prefixes may be used or may be ignored. And if they are > > there are no subsequent prefixes. Each prefix is advertised in a > separate top level TLV and will have it's own prefix-SID sub-TLV, only > belonging to that prefix. > >> ignored then it is originator's fault, receiver has all rights to ignore >> them. If the mapping server wants to ensure every router installs prefix >> attributes then it has no choice but to break the range and advertise >> each prefix individually. >> So IMO ranges processing must be required on every step, otherwise >> they will never be used. >> > > please see above. > >> >> >> >> > high level TLV advertise a single prefix/mask. It's the sub-TLV which >> > may extend the applicability to the range if required, so the scope is >> > defined by each sub-TLV. > > the way to look at it is that the top-level TLV always advertises a > single prefix in a form of prefix/length. Nested sub-TLVs have their own > data, which are interpreted based on the sub-TLV specification, they do > not change what is in the top-level TLV. The fact that some sub-TLV has > a count variable and use the prefix/mask as starting point makes no > impact on the top-level data. > >> >> That what makes ranges counter intuitive. Intuitive hierarchy is >> object on the top and then subordinate items describing properties of >> the object: >> >> Object --- >> | >> |- attribute1 >> |- attribute2 >> >> >> But the current scheme does not define object at the top of the >> hierarchy, real object is defined together with property: >> >> Anchor --- >> | >> |- range-of-objects-and-attribute1 >> |- range-of-objects-and-attribute2 >> >> There are three problems with this representation: >> 1. Anchor (i.e. top level TLV) is not enough to determine which objects >> (i.e. prefixes) are affected and which are not > > actually it is enough. We are not changing or replacing the top-level > data. We are just using it differently - for prefix-SID sub-TLV the > prefix/length in the top-level TLV is used as a 'start' object. > >> 2. Set of objects (i.e. the range) may be different in each sub-TLV thus >> raising concerns of ambiguity > > this does not introduce any more ambiguity then any other encoding which > includes prefix/mask/count variables. > >> 3. Text requires that anchor is advertised only once but there is no >> requirement that ranges advertised for different anchors cannot overlap > > actually there is no reason why they can not overlap. We have overlaps > today with prefix/mask semantics as well and we deal with them. > >> >> It would have been more logical to define range in the "OSPF Extended >> Prefix TLV" header itself, not in each sub-TLV. This specifies the >> object (i.e. the range) in the topmost TLV and resolves problems >> mentioned above. > > we wanted to preserve the prefix/length semantics well known from > current OSPF. Making size mandatory would be a significant deviation > from the current OSPF spec. > > Prefix-SID 'count' semantics is something specific to the SID and is > more of an exception and IMHO should not force us to to deviate from > representation we are used to work with. > > thanks, > Peter > > > >> >> Anton >> >> >> On 07/03/2014 10:09 AM, Peter Psenak wrote: >>> Hi Acee, >>> >>> please see inline: >>> >>> On 7/2/14 19:17 , Acee Lindem wrote: >>>> Hi Peter, >>>> It seems there are two distinct deployment scenarios - one where SR >>>> routers are given a range and policy and allocate their own SIDs and >>>> another where a mapping server does it for the routing domain. >>> >>> yes, that is correct. The latter is used mainly during migration from >>> LDP to SR. >>> >>> >>> >>>>>> 6. Section 4.2 - I really don’t like having his sub-TLV >>>>>> redefine the subsuming top-level TLV as a range of prefixes of the >>>>>> same length rather than a single prefix. Although this is my first >>>>>> serious reading of the draft, this encoding seems really unwieldy >>>>>> and, in practice, I’d expect the range size always advertised as 1. >>>>>> We can discuss this more in Toronto. >>>>> >>>>> an example where the range would be more then 1 is a mapping server >>>>> case. This helps you to advertise SIDs for loopback addresses of all >>>>> routers in a non-SR capable part of the network, assuming they are >>>>> allocated from the contiguous address space. Instead of advertising >>>>> hundreds of mappings for each /32 address, you can compact it to a >>>>> single advertisement. >>>> >>>> I’ve seen loopbacks allocated sequentially in a few networks but many >>>> more where there weren’t. >>> >>> still, having a mechanism to compact the advertisements if possible >>> looks appealing. >>> >>>> >>>>> >>>>> What you need in such case is component prefix/length plus the number >>>>> of components - OSPF Extended Prefix TLV gives you the component info >>>>> and Prefix SID Sub-TLV "Range Size' gives you the number of >>>>> components. >>>> >>>> I understood it but I don’t like the sub-TLV extending the >>>> specification of the higher level TLV. I especially don’t like it >>>> since the top-level TLV is a generic mechanism to advertise >>>> attributes. When additional attributes are defined, it begs the of >>>> whether or not they apply solely to the prefix or to the range. >>> >>> high level TLV advertise a single prefix/mask. It's the sub-TLV which >>> may extend the applicability to the range if required, so the scope is >>> defined by each sub-TLV. >>> >>>> >>>>> >>>>> We could have defined a separate top level TLV in OSPF Extended >>>>> Prefix LSA for the advertisement of range of components, but it looks >>>>> to me that would be an overkill. >>>> >>>> I would have preferred that. When the SID attributes are embedded >>>> (OSPFv3 and ISIS), I think the semantics are even more unnatural since >>>> reachability MAY be advertised for the prefix while SID mapping is >>>> being advertised for the range. >>> >>> I had the same reservations at the beginning :) >>> But there is no problem really. Prefix-SID sub-TLV never advertises any >>> reachability, whether it advertises a single SID or a range of SIDs. For >>> Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of >>> "start" and Prefix-SID sub-TLV always carry its own "size" - just a >>> different interpretation of the data from the higher level TLV. >>> >>> Please note that SID range is quite different from the address range we >>> are used to from summarization. SID range requires three parameters >>> (address/mask and count), compared to two parameter (address/mask) that >>> traditional address range uses. As a result, Extended prefix TLV as such >>> can not cover the SID range, because it only has address/mask. Defining >>> a top-level TLV for a SID range itself does not really fit into Extended >>> Prefix LSA and having a new LSA for it is not an option I would say. So >>> the current encoding looks like a good compromise to me. >>> >>> thanks, >>> Peter >>> >>>> >>>>> Current encoding of Prefix SID Sub-TLV gives us all the flexibility >>>>> we need. In addition it matches what ISIS has done. >>>> >>>> I haven’t seen any discussion of the draft on the ISIS list other than >>>> the revision updates. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> 7. Section 4.2 - Shouldn’t the reference for the mapping >>>>>> server be the “Segment Routing Architecture” rather than the >>>>>> “Segment Routing Use Cases”? In general, the usage of a mapping >>>>>> server and the scope of assignment needs to be described better >>>>>> somewhere (not in the OSPF encoding document). >>>>> >>>>> will fix the reference >>>>> >>>>>> >>>>>> 8. Section 6 - It would seem that an entity calculating a >>>>>> multi-area SR path would need access to the topology for all the >>>>>> areas and the SID would need to be globally assigned? Right? >>>>> >>>>> correct. >>>>> >>>>>> So rules are primarily for the population of the forwarding plane. >>>>>> Right? >>>>> >>>>> for advertisement/propagation of SIDs and for forwarding plane >>>>> programming. >>>>> >>>>>> >>>>>> 9. Section 6.2 - In standard OSPF, inter-area summary >>>>>> propagation only applies to inter-area routes learned over the >>>>>> backbone. Is this any different? >>>>> >>>>> no, the mechanism is the same as for type-3s. >>>>> >>>>> thanks, >>>>> Peter >>>>> >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> >>>>>> >>>>>> . >>>>>> >>>>> >>>> >>>> . >>>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> . >> > From nobody Wed Jul 9 01:21:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41021A039B for ; Wed, 9 Jul 2014 01:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRe2M91DMXli for ; Wed, 9 Jul 2014 01:21:36 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1CE1A0398 for ; Wed, 9 Jul 2014 01:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12004; q=dns/txt; s=iport; t=1404894104; x=1406103704; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sMCt9Fq+8rKdZNe2vNjI+mR3QFWkxJtK8rrPX++nLss=; b=Fy4R0KjY71gtfdshEkUyfP9JnoQUzvf4ZD5kv6wYX8evuv5Z2+JsrEdE nMKkowAMd7vrj2dSb5Je33MDA3IjTyR1oTE4XsWL1HSZx50ZOq50i7Et5 Xrg/oBWYX4WnRA/T84yz4IGsQTpv1BRCwjEuBH+RzHYAJOzYL5db/k7Hq w=; X-IronPort-AV: E=Sophos;i="5.01,630,1400025600"; d="scan'208";a="102960889" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 09 Jul 2014 08:21:41 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s698LWdn031272; Wed, 9 Jul 2014 08:21:32 GMT Message-ID: <53BCFB8E.30808@cisco.com> Date: Wed, 09 Jul 2014 10:21:34 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Anton Smirnov , Acee Lindem References: <948E8138-3BB5-4292-9CF6-4131F6AEED8D@ericsson.com> <53B3EE66.90608@cisco.com> <677E5EF6-C3F0-41DB-A7DA-7C43E07E3B07@ericsson.com> <53B50FBC.60803@cisco.com> <53BC338C.9090808@cisco.com> <53BC4EE3.30909@cisco.com> <53BCF0AB.4080207@cisco.com> In-Reply-To: <53BCF0AB.4080207@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/CGxZDY7PV_bPG3CGAqMQwyvQdhI Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 09 Jul 2014 08:21:39 -0000 Hi Anton, please see inline: On 7/9/14 09:35 , Anton Smirnov wrote: > Hi Peter, > I don't understand your answers. Let me give an example of encoding: > > Extended Prefix TLV > 192.0.2.1/32 > Prefix SID Sub-TLV > Range 2 > SID/Label Binding sub-TLV > Range 4 > > > Extended Prefix TLV > 192.0.2.4/32 > Prefix SID Sub-TLV > Range 1 > SID/Label Binding sub-TLV > Range 1 > > This is valid encoding per current text and it expands into: > > 192.0.2.1 - 1 SID 1 Binding > 192.0.2.2 - 1 SID 1 Binding > 192.0.2.3 - 1 Binding > 192.0.2.4 - 1 SID 2 Bindings > > Obviously this encoding is very difficult to work with because ranges > are different for attributes, because prefix 192.0.2.4/32 is served by > two ranges. the fact you have two SIDs or two Bindings for a single prefix is not a result of the current encoding. Moving the 'range' to top level TLV is not going to address it - you can have a top level TLV with 192.0.2.1/32/4 and 192.0.2.4/32/1 resulting in the exactly the same situation. > > > It is more logical to define range as part of top-level TLV: > > Extended Prefix TLV > Prefix/mask; Range as I mentioned in the previous email, we want to preserve the prefix representation by prefix/length in top-level TLV as that is sufficient for almost all attributes. If people do not like the range in the Prefix SID and SID/Label Binding sub-TLVs, then I prefer to define a new top level TLV that would be used to advertise attributes for a prefix block, which would be represented by prefix/length/count. I'm afraid it will not be used for anything except the Prefix SID & SID/Label Binding sub-TLV though - history shows we never needed such prefix block in the past. thanks, Peter > Prefix SID Sub-TLV > SID > SID/Label Binding sub-TLV > Binding > > Anton > > > On 07/08/2014 10:04 PM, Peter Psenak wrote: >> Anton, >> >> please see inline: >> >> On 7/8/14 20:08 , Anton Smirnov wrote: >>> Hi Peter, >>> in current text ranges are not required to be processed and I think >>> this kills their potential usage: >>> >>> If multiple Prefix-SIDs are advertised for the same prefix, the >>> receiving router MUST use the first encoded SID and MAY use the >>> subsequent ones. >> >> I do not see any connection between ranges and the above text. Above >> text says that if there are multiple prefix SIDs advertised, for a >> single prefix, every implementation MUST process at least the first one. >> Typically only a single SID will be advertised for each prefix >> regardless of the range being 1 or more. >> >>> >>> (and similar text for inter-area LSA origination). >>> Subsequent prefixes may be used or may be ignored. And if they are >> >> there are no subsequent prefixes. Each prefix is advertised in a >> separate top level TLV and will have it's own prefix-SID sub-TLV, only >> belonging to that prefix. >> >>> ignored then it is originator's fault, receiver has all rights to ignore >>> them. If the mapping server wants to ensure every router installs prefix >>> attributes then it has no choice but to break the range and advertise >>> each prefix individually. >>> So IMO ranges processing must be required on every step, otherwise >>> they will never be used. >>> >> >> please see above. >> >>> >>> >>> >>> > high level TLV advertise a single prefix/mask. It's the sub-TLV which >>> > may extend the applicability to the range if required, so the >>> scope is >>> > defined by each sub-TLV. >> >> the way to look at it is that the top-level TLV always advertises a >> single prefix in a form of prefix/length. Nested sub-TLVs have their own >> data, which are interpreted based on the sub-TLV specification, they do >> not change what is in the top-level TLV. The fact that some sub-TLV has >> a count variable and use the prefix/mask as starting point makes no >> impact on the top-level data. >> >>> >>> That what makes ranges counter intuitive. Intuitive hierarchy is >>> object on the top and then subordinate items describing properties of >>> the object: >>> >>> Object --- >>> | >>> |- attribute1 >>> |- attribute2 >>> >>> >>> But the current scheme does not define object at the top of the >>> hierarchy, real object is defined together with property: >>> >>> Anchor --- >>> | >>> |- range-of-objects-and-attribute1 >>> |- range-of-objects-and-attribute2 >>> >>> There are three problems with this representation: >>> 1. Anchor (i.e. top level TLV) is not enough to determine which objects >>> (i.e. prefixes) are affected and which are not >> >> actually it is enough. We are not changing or replacing the top-level >> data. We are just using it differently - for prefix-SID sub-TLV the >> prefix/length in the top-level TLV is used as a 'start' object. >> >>> 2. Set of objects (i.e. the range) may be different in each sub-TLV thus >>> raising concerns of ambiguity >> >> this does not introduce any more ambiguity then any other encoding which >> includes prefix/mask/count variables. >> >>> 3. Text requires that anchor is advertised only once but there is no >>> requirement that ranges advertised for different anchors cannot overlap >> >> actually there is no reason why they can not overlap. We have overlaps >> today with prefix/mask semantics as well and we deal with them. >> >>> >>> It would have been more logical to define range in the "OSPF Extended >>> Prefix TLV" header itself, not in each sub-TLV. This specifies the >>> object (i.e. the range) in the topmost TLV and resolves problems >>> mentioned above. >> >> we wanted to preserve the prefix/length semantics well known from >> current OSPF. Making size mandatory would be a significant deviation >> from the current OSPF spec. >> >> Prefix-SID 'count' semantics is something specific to the SID and is >> more of an exception and IMHO should not force us to to deviate from >> representation we are used to work with. >> >> thanks, >> Peter >> >> >> >>> >>> Anton >>> >>> >>> On 07/03/2014 10:09 AM, Peter Psenak wrote: >>>> Hi Acee, >>>> >>>> please see inline: >>>> >>>> On 7/2/14 19:17 , Acee Lindem wrote: >>>>> Hi Peter, >>>>> It seems there are two distinct deployment scenarios - one where SR >>>>> routers are given a range and policy and allocate their own SIDs and >>>>> another where a mapping server does it for the routing domain. >>>> >>>> yes, that is correct. The latter is used mainly during migration from >>>> LDP to SR. >>>> >>>> >>>> >>>>>>> 6. Section 4.2 - I really don’t like having his sub-TLV >>>>>>> redefine the subsuming top-level TLV as a range of prefixes of the >>>>>>> same length rather than a single prefix. Although this is my first >>>>>>> serious reading of the draft, this encoding seems really unwieldy >>>>>>> and, in practice, I’d expect the range size always advertised as 1. >>>>>>> We can discuss this more in Toronto. >>>>>> >>>>>> an example where the range would be more then 1 is a mapping server >>>>>> case. This helps you to advertise SIDs for loopback addresses of all >>>>>> routers in a non-SR capable part of the network, assuming they are >>>>>> allocated from the contiguous address space. Instead of advertising >>>>>> hundreds of mappings for each /32 address, you can compact it to a >>>>>> single advertisement. >>>>> >>>>> I’ve seen loopbacks allocated sequentially in a few networks but many >>>>> more where there weren’t. >>>> >>>> still, having a mechanism to compact the advertisements if possible >>>> looks appealing. >>>> >>>>> >>>>>> >>>>>> What you need in such case is component prefix/length plus the number >>>>>> of components - OSPF Extended Prefix TLV gives you the component info >>>>>> and Prefix SID Sub-TLV "Range Size' gives you the number of >>>>>> components. >>>>> >>>>> I understood it but I don’t like the sub-TLV extending the >>>>> specification of the higher level TLV. I especially don’t like it >>>>> since the top-level TLV is a generic mechanism to advertise >>>>> attributes. When additional attributes are defined, it begs the of >>>>> whether or not they apply solely to the prefix or to the range. >>>> >>>> high level TLV advertise a single prefix/mask. It's the sub-TLV which >>>> may extend the applicability to the range if required, so the scope is >>>> defined by each sub-TLV. >>>> >>>>> >>>>>> >>>>>> We could have defined a separate top level TLV in OSPF Extended >>>>>> Prefix LSA for the advertisement of range of components, but it looks >>>>>> to me that would be an overkill. >>>>> >>>>> I would have preferred that. When the SID attributes are embedded >>>>> (OSPFv3 and ISIS), I think the semantics are even more unnatural since >>>>> reachability MAY be advertised for the prefix while SID mapping is >>>>> being advertised for the range. >>>> >>>> I had the same reservations at the beginning :) >>>> But there is no problem really. Prefix-SID sub-TLV never advertises any >>>> reachability, whether it advertises a single SID or a range of SIDs. >>>> For >>>> Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of >>>> "start" and Prefix-SID sub-TLV always carry its own "size" - just a >>>> different interpretation of the data from the higher level TLV. >>>> >>>> Please note that SID range is quite different from the address range we >>>> are used to from summarization. SID range requires three parameters >>>> (address/mask and count), compared to two parameter (address/mask) that >>>> traditional address range uses. As a result, Extended prefix TLV as >>>> such >>>> can not cover the SID range, because it only has address/mask. Defining >>>> a top-level TLV for a SID range itself does not really fit into >>>> Extended >>>> Prefix LSA and having a new LSA for it is not an option I would say. So >>>> the current encoding looks like a good compromise to me. >>>> >>>> thanks, >>>> Peter >>>> >>>>> >>>>>> Current encoding of Prefix SID Sub-TLV gives us all the flexibility >>>>>> we need. In addition it matches what ISIS has done. >>>>> >>>>> I haven’t seen any discussion of the draft on the ISIS list other than >>>>> the revision updates. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> 7. Section 4.2 - Shouldn’t the reference for the mapping >>>>>>> server be the “Segment Routing Architecture” rather than the >>>>>>> “Segment Routing Use Cases”? In general, the usage of a mapping >>>>>>> server and the scope of assignment needs to be described better >>>>>>> somewhere (not in the OSPF encoding document). >>>>>> >>>>>> will fix the reference >>>>>> >>>>>>> >>>>>>> 8. Section 6 - It would seem that an entity calculating a >>>>>>> multi-area SR path would need access to the topology for all the >>>>>>> areas and the SID would need to be globally assigned? Right? >>>>>> >>>>>> correct. >>>>>> >>>>>>> So rules are primarily for the population of the forwarding plane. >>>>>>> Right? >>>>>> >>>>>> for advertisement/propagation of SIDs and for forwarding plane >>>>>> programming. >>>>>> >>>>>>> >>>>>>> 9. Section 6.2 - In standard OSPF, inter-area summary >>>>>>> propagation only applies to inter-area routes learned over the >>>>>>> backbone. Is this any different? >>>>>> >>>>>> no, the mechanism is the same as for type-3s. >>>>>> >>>>>> thanks, >>>>>> Peter >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> . >>>>> >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> . >>> >> > . > From nobody Wed Jul 9 02:50:21 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F561A03D0 for ; Wed, 9 Jul 2014 02:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOTu1_Z9ClG9 for ; Wed, 9 Jul 2014 02:50:17 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B391A03CD for ; Wed, 9 Jul 2014 02:50:16 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-a6-53bcbbad6570 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DC.89.25146.DABBCB35; Wed, 9 Jul 2014 05:49:02 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 05:50:15 -0400 From: Acee Lindem To: Peter Psenak , Anton Smirnov Thread-Topic: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt Thread-Index: AQHPm1suriU3Kd577EqxpPjMGdPJdQ== Date: Wed, 9 Jul 2014 09:50:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPgu663XuCDZZ+5bBo2cZq0XLvHrvF jt3tbA7MHlN+b2T1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxvL9a5kKtvUyVtx/8YqpgfFJJ2MX IyeHhICJxPW3u9ghbDGJC/fWs3UxcnEICRxllLjR/YMJwlnGKDH11BoWkCo2AR2J54/+MYPY IgIeEs9X7gTrZhaQlXi2rQksLiwQIPH2/iIgmwOoJlDixqxkiHI9iVltR1lBbBYBFYk3l0CW cXLwCphKPG19CHYQI9AR30+tYYIYKS5x68l8JojjBCSW7DnPDGGLSrx8/A9sjijQzOauN1DP KEl8/D0f6hwtiS8/9rFB2NYSkx7/YoGwFSWmdD9kh9grKHFy5hOWCYxis5Csm4WkfRaS9llI 2mchaV/AyLqKkaO0OLUsN93IcBMjMJKOSbA57mBc8MnyEKMAB6MSD6/Cwd3BQqyJZcWVuYcY pTlYlMR5NavnBQsJpCeWpGanphakFsUXleakFh9iZOLglGpglDyw6tPUE6p8oYJ7GgoulfCm nFj4neseW20k/+sV/DMvHnqjHfZm4v5HzK5ZK/lTXCduWeIhV35wXmZYgEj40wMG/3894RJL 6M74kcs+a/PS8+4znhq+/rlq0tvQ2jRTM9X8JQ0Vkw5eOtZQ+6l3xbZ5q2Q6W+Vir8oYP36/ 7UJ2gU3tzT6ldiWW4oxEQy3mouJEAIy8ceKFAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/NlkVZewIuw6baUqXkXREyFXEDJA Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 09 Jul 2014 09:50:19 -0000 SGkgUGV0ZXIsIEFudG9uLCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBl dGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgOSwg MjAxNCBhdCAxOjIxIEFNDQpUbzogQW50b24gU21pcm5vdiA8YXNtaXJub3ZAY2lzY28uY29tPiwg RXJpY3Nzb24gPGFjZWUubGluZGVtQGVyaWNzc29uLmNvbT4NCkNjOiBPU1BGIC0gT1NQRiBXRyBM aXN0IDxvc3BmQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPU1BGXSBDb21tZW50cw0KZHJhZnQt aWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zLTAwLnR4dA0KDQo+SGkgQW50b24s DQo+DQo+cGxlYXNlIHNlZSBpbmxpbmU6DQo+DQo+DQo+T24gNy85LzE0IDA5OjM1ICwgQW50b24g U21pcm5vdiB3cm90ZToNCj4+ICAgICBIaSBQZXRlciwNCj4+ICAgICBJIGRvbid0IHVuZGVyc3Rh bmQgeW91ciBhbnN3ZXJzLiBMZXQgbWUgZ2l2ZSBhbiBleGFtcGxlIG9mIGVuY29kaW5nOg0KPj4N Cj4+IEV4dGVuZGVkIFByZWZpeCBUTFYNCj4+ICAgMTkyLjAuMi4xLzMyDQo+PiAgICAgIFByZWZp eCBTSUQgU3ViLVRMVg0KPj4gICAgICAgUmFuZ2UgMg0KPj4gICAgICBTSUQvTGFiZWwgQmluZGlu ZyBzdWItVExWDQo+PiAgICAgICBSYW5nZSA0DQo+Pg0KPj4NCj4+IEV4dGVuZGVkIFByZWZpeCBU TFYNCj4+ICAgMTkyLjAuMi40LzMyDQo+PiAgICAgIFByZWZpeCBTSUQgU3ViLVRMVg0KPj4gICAg ICAgUmFuZ2UgMQ0KPj4gICAgICBTSUQvTGFiZWwgQmluZGluZyBzdWItVExWDQo+PiAgICAgICBS YW5nZSAxDQo+Pg0KPj4gVGhpcyBpcyB2YWxpZCBlbmNvZGluZyBwZXIgY3VycmVudCB0ZXh0IGFu ZCBpdCBleHBhbmRzIGludG86DQo+Pg0KPj4gMTkyLjAuMi4xIC0gMSBTSUQgMSBCaW5kaW5nDQo+ PiAxOTIuMC4yLjIgLSAxIFNJRCAxIEJpbmRpbmcNCj4+IDE5Mi4wLjIuMyAtIDEgQmluZGluZw0K Pj4gMTkyLjAuMi40IC0gMSBTSUQgMiBCaW5kaW5ncw0KPj4NCj4+IE9idmlvdXNseSB0aGlzIGVu Y29kaW5nIGlzIHZlcnkgZGlmZmljdWx0IHRvIHdvcmsgd2l0aCBiZWNhdXNlIHJhbmdlcw0KPj4g YXJlIGRpZmZlcmVudCBmb3IgYXR0cmlidXRlcywgYmVjYXVzZSBwcmVmaXggMTkyLjAuMi40LzMy IGlzIHNlcnZlZCBieQ0KPj4gdHdvIHJhbmdlcy4NCj4NCj50aGUgZmFjdCB5b3UgaGF2ZSB0d28g U0lEcyBvciB0d28gQmluZGluZ3MgZm9yIGEgc2luZ2xlIHByZWZpeCBpcyBub3QgYQ0KPnJlc3Vs dCBvZiB0aGUgY3VycmVudCBlbmNvZGluZy4gTW92aW5nIHRoZSAncmFuZ2UnIHRvIHRvcCBsZXZl bCBUTFYgaXMNCj5ub3QgZ29pbmcgdG8gYWRkcmVzcyBpdCAtIHlvdSBjYW4gaGF2ZSBhIHRvcCBs ZXZlbCBUTFYgd2l0aA0KPjE5Mi4wLjIuMS8zMi80IGFuZCAxOTIuMC4yLjQvMzIvMSByZXN1bHRp bmcgaW4gdGhlIGV4YWN0bHkgdGhlIHNhbWUNCj5zaXR1YXRpb24uDQo+DQo+Pg0KPj4NCj4+IEl0 IGlzIG1vcmUgbG9naWNhbCB0byBkZWZpbmUgcmFuZ2UgYXMgcGFydCBvZiB0b3AtbGV2ZWwgVExW Og0KPj4NCj4+IEV4dGVuZGVkIFByZWZpeCBUTFYNCj4+ICAgUHJlZml4L21hc2s7IFJhbmdlDQo+ DQo+YXMgSSBtZW50aW9uZWQgaW4gdGhlIHByZXZpb3VzIGVtYWlsLCB3ZSB3YW50IHRvIHByZXNl cnZlIHRoZSBwcmVmaXgNCj5yZXByZXNlbnRhdGlvbiBieSBwcmVmaXgvbGVuZ3RoIGluIHRvcC1s ZXZlbCBUTFYgYXMgdGhhdCBpcyBzdWZmaWNpZW50DQo+Zm9yIGFsbW9zdCBhbGwgYXR0cmlidXRl cy4gSWYgcGVvcGxlIGRvIG5vdCBsaWtlIHRoZSByYW5nZSBpbiB0aGUgUHJlZml4DQo+U0lEIGFu ZCBTSUQvTGFiZWwgQmluZGluZyBzdWItVExWcywgdGhlbiBJIHByZWZlciB0byBkZWZpbmUgYSBu ZXcgdG9wDQo+bGV2ZWwgVExWIHRoYXQgd291bGQgYmUgdXNlZCB0byBhZHZlcnRpc2UgYXR0cmli dXRlcyBmb3IgYSBwcmVmaXggYmxvY2ssDQo+d2hpY2ggd291bGQgYmUgcmVwcmVzZW50ZWQgYnkg cHJlZml4L2xlbmd0aC9jb3VudC4gSSdtIGFmcmFpZCBpdCB3aWxsDQo+bm90IGJlIHVzZWQgZm9y IGFueXRoaW5nIGV4Y2VwdCB0aGUgUHJlZml4IFNJRCAmIFNJRC9MYWJlbCBCaW5kaW5nDQo+c3Vi LVRMViB0aG91Z2ggLSBoaXN0b3J5IHNob3dzIHdlIG5ldmVyIG5lZWRlZCBzdWNoIHByZWZpeCBi bG9jayBpbiB0aGUNCj5wYXN0Lg0KDQpJcyB0aGlzIHRoZSBvbmx5IGRvd25zaWRlIG9mIGEgc2Vw YXJhdGUgcmFuZ2UgdG9wLWxldmVsIFRMVj8gSWYgc28sIHRoZW4NCml0IHNlZW1zIHRoaXMgd291 bGQgcHJvdmlkZSBhIGNsZWFuZXIgZW5jb2RpbmcuSSBkb26p9nQgbGlrZSBhbGxvd2luZyByYW5n ZQ0KYXR0cmlidXRlcyBhbmQgc2luZ2xlIHByZWZpeCBhdHRyaWJ1dGVzIHRvIGJlIG1peGVkLiBF dmVuIHdpdGggdGhlIGN1cnJlbnQNCmVuY29kaW5nLCB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSB0byBo YW5kbGUgdGhlIGFtYmlndWl0eSBvZiBvdmVybGFwcGluZw0KcmFuZ2VzIHNvIEkgZG9uqfZ0IHNl ZSBhIHNlcGFyYXRlIHRvcC1sZXZlbCBUTFYgYW5kIGFkZGluZyBtb3JlIGNvbXBsZXhpdHkuDQoN ClRoYW5rcywNCkFjZWUgDQoNCg0KPg0KPnRoYW5rcywNCj5QZXRlcg0KPg0KPj4gICAgICBQcmVm aXggU0lEIFN1Yi1UTFYNCj4+ICAgICAgIFNJRA0KPj4gICAgICBTSUQvTGFiZWwgQmluZGluZyBz dWItVExWDQo+PiAgICAgICBCaW5kaW5nDQo+Pg0KPj4gQW50b24NCj4+DQo+Pg0KPj4gT24gMDcv MDgvMjAxNCAxMDowNCBQTSwgUGV0ZXIgUHNlbmFrIHdyb3RlOg0KPj4+IEFudG9uLA0KPj4+DQo+ Pj4gcGxlYXNlIHNlZSBpbmxpbmU6DQo+Pj4NCj4+PiBPbiA3LzgvMTQgMjA6MDggLCBBbnRvbiBT bWlybm92IHdyb3RlOg0KPj4+PiAgICAgSGkgUGV0ZXIsDQo+Pj4+ICAgICBpbiBjdXJyZW50IHRl eHQgcmFuZ2VzIGFyZSBub3QgcmVxdWlyZWQgdG8gYmUgcHJvY2Vzc2VkIGFuZCBJDQo+Pj4+dGhp bmsNCj4+Pj4gdGhpcyBraWxscyB0aGVpciBwb3RlbnRpYWwgdXNhZ2U6DQo+Pj4+DQo+Pj4+ICAg ICBJZiBtdWx0aXBsZSBQcmVmaXgtU0lEcyBhcmUgYWR2ZXJ0aXNlZCBmb3IgdGhlIHNhbWUgcHJl Zml4LCB0aGUNCj4+Pj4gICAgIHJlY2VpdmluZyByb3V0ZXIgTVVTVCB1c2UgdGhlIGZpcnN0IGVu Y29kZWQgU0lEIGFuZCBNQVkgdXNlIHRoZQ0KPj4+PiAgICAgc3Vic2VxdWVudCBvbmVzLg0KPj4+ DQo+Pj4gSSBkbyBub3Qgc2VlIGFueSBjb25uZWN0aW9uIGJldHdlZW4gcmFuZ2VzIGFuZCB0aGUg YWJvdmUgdGV4dC4gQWJvdmUNCj4+PiB0ZXh0IHNheXMgdGhhdCBpZiB0aGVyZSBhcmUgbXVsdGlw bGUgcHJlZml4IFNJRHMgYWR2ZXJ0aXNlZCwgZm9yIGENCj4+PiBzaW5nbGUgcHJlZml4LCBldmVy eSBpbXBsZW1lbnRhdGlvbiBNVVNUIHByb2Nlc3MgYXQgbGVhc3QgdGhlIGZpcnN0DQo+Pj5vbmUu DQo+Pj4gVHlwaWNhbGx5IG9ubHkgYSBzaW5nbGUgU0lEIHdpbGwgYmUgYWR2ZXJ0aXNlZCBmb3Ig ZWFjaCBwcmVmaXgNCj4+PiByZWdhcmRsZXNzIG9mIHRoZSByYW5nZSBiZWluZyAxIG9yIG1vcmUu DQo+Pj4NCj4+Pj4NCj4+Pj4gKGFuZCBzaW1pbGFyIHRleHQgZm9yIGludGVyLWFyZWEgTFNBIG9y aWdpbmF0aW9uKS4NCj4+Pj4gICAgIFN1YnNlcXVlbnQgcHJlZml4ZXMgbWF5IGJlIHVzZWQgb3Ig bWF5IGJlIGlnbm9yZWQuIEFuZCBpZiB0aGV5IGFyZQ0KPj4+DQo+Pj4gdGhlcmUgYXJlIG5vIHN1 YnNlcXVlbnQgcHJlZml4ZXMuIEVhY2ggcHJlZml4IGlzIGFkdmVydGlzZWQgaW4gYQ0KPj4+IHNl cGFyYXRlIHRvcCBsZXZlbCBUTFYgYW5kIHdpbGwgaGF2ZSBpdCdzIG93biBwcmVmaXgtU0lEIHN1 Yi1UTFYsIG9ubHkNCj4+PiBiZWxvbmdpbmcgdG8gdGhhdCBwcmVmaXguDQo+Pj4NCj4+Pj4gaWdu b3JlZCB0aGVuIGl0IGlzIG9yaWdpbmF0b3IncyBmYXVsdCwgcmVjZWl2ZXIgaGFzIGFsbCByaWdo dHMgdG8NCj4+Pj5pZ25vcmUNCj4+Pj4gdGhlbS4gSWYgdGhlIG1hcHBpbmcgc2VydmVyIHdhbnRz IHRvIGVuc3VyZSBldmVyeSByb3V0ZXIgaW5zdGFsbHMNCj4+Pj5wcmVmaXgNCj4+Pj4gYXR0cmli dXRlcyB0aGVuIGl0IGhhcyBubyBjaG9pY2UgYnV0IHRvIGJyZWFrIHRoZSByYW5nZSBhbmQgYWR2 ZXJ0aXNlDQo+Pj4+IGVhY2ggcHJlZml4IGluZGl2aWR1YWxseS4NCj4+Pj4gICAgIFNvIElNTyBy YW5nZXMgcHJvY2Vzc2luZyBtdXN0IGJlIHJlcXVpcmVkIG9uIGV2ZXJ5IHN0ZXAsIG90aGVyd2lz ZQ0KPj4+PiB0aGV5IHdpbGwgbmV2ZXIgYmUgdXNlZC4NCj4+Pj4NCj4+Pg0KPj4+IHBsZWFzZSBz ZWUgYWJvdmUuDQo+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gID4gaGlnaCBsZXZlbCBUTFYg YWR2ZXJ0aXNlIGEgc2luZ2xlIHByZWZpeC9tYXNrLiBJdCdzIHRoZSBzdWItVExWDQo+Pj4+d2hp Y2gNCj4+Pj4gID4gbWF5IGV4dGVuZCB0aGUgYXBwbGljYWJpbGl0eSB0byB0aGUgcmFuZ2UgaWYg cmVxdWlyZWQsIHNvIHRoZQ0KPj4+PiBzY29wZSBpcw0KPj4+PiAgPiBkZWZpbmVkIGJ5IGVhY2gg c3ViLVRMVi4NCj4+Pg0KPj4+IHRoZSB3YXkgdG8gbG9vayBhdCBpdCBpcyB0aGF0IHRoZSB0b3At bGV2ZWwgVExWIGFsd2F5cyBhZHZlcnRpc2VzIGENCj4+PiBzaW5nbGUgcHJlZml4IGluIGEgZm9y bSBvZiBwcmVmaXgvbGVuZ3RoLiBOZXN0ZWQgc3ViLVRMVnMgaGF2ZSB0aGVpcg0KPj4+b3duDQo+ Pj4gZGF0YSwgd2hpY2ggYXJlIGludGVycHJldGVkIGJhc2VkIG9uIHRoZSBzdWItVExWIHNwZWNp ZmljYXRpb24sIHRoZXkgZG8NCj4+PiBub3QgY2hhbmdlIHdoYXQgaXMgaW4gdGhlIHRvcC1sZXZl bCBUTFYuIFRoZSBmYWN0IHRoYXQgc29tZSBzdWItVExWIGhhcw0KPj4+IGEgY291bnQgdmFyaWFi bGUgYW5kIHVzZSB0aGUgcHJlZml4L21hc2sgYXMgc3RhcnRpbmcgcG9pbnQgbWFrZXMgbm8NCj4+ PiBpbXBhY3Qgb24gdGhlIHRvcC1sZXZlbCBkYXRhLg0KPj4+DQo+Pj4+DQo+Pj4+ICAgICBUaGF0 IHdoYXQgbWFrZXMgcmFuZ2VzIGNvdW50ZXIgaW50dWl0aXZlLiBJbnR1aXRpdmUgaGllcmFyY2h5 IGlzDQo+Pj4+IG9iamVjdCBvbiB0aGUgdG9wIGFuZCB0aGVuIHN1Ym9yZGluYXRlIGl0ZW1zIGRl c2NyaWJpbmcgcHJvcGVydGllcyBvZg0KPj4+PiB0aGUgb2JqZWN0Og0KPj4+Pg0KPj4+PiBPYmpl Y3QgLS0tDQo+Pj4+ICAgICAgICAgICB8DQo+Pj4+ICAgICAgICAgICB8LSBhdHRyaWJ1dGUxDQo+ Pj4+ICAgICAgICAgICB8LSBhdHRyaWJ1dGUyDQo+Pj4+DQo+Pj4+DQo+Pj4+IEJ1dCB0aGUgY3Vy cmVudCBzY2hlbWUgZG9lcyBub3QgZGVmaW5lIG9iamVjdCBhdCB0aGUgdG9wIG9mIHRoZQ0KPj4+ PiBoaWVyYXJjaHksIHJlYWwgb2JqZWN0IGlzIGRlZmluZWQgdG9nZXRoZXIgd2l0aCBwcm9wZXJ0 eToNCj4+Pj4NCj4+Pj4gQW5jaG9yIC0tLQ0KPj4+PiAgICAgICAgICAgfA0KPj4+PiAgICAgICAg ICAgfC0gcmFuZ2Utb2Ytb2JqZWN0cy1hbmQtYXR0cmlidXRlMQ0KPj4+PiAgICAgICAgICAgfC0g cmFuZ2Utb2Ytb2JqZWN0cy1hbmQtYXR0cmlidXRlMg0KPj4+Pg0KPj4+PiBUaGVyZSBhcmUgdGhy ZWUgcHJvYmxlbXMgd2l0aCB0aGlzIHJlcHJlc2VudGF0aW9uOg0KPj4+PiAxLiBBbmNob3IgKGku ZS4gdG9wIGxldmVsIFRMVikgaXMgbm90IGVub3VnaCB0byBkZXRlcm1pbmUgd2hpY2gNCj4+Pj5v YmplY3RzDQo+Pj4+IChpLmUuIHByZWZpeGVzKSBhcmUgYWZmZWN0ZWQgYW5kIHdoaWNoIGFyZSBu b3QNCj4+Pg0KPj4+IGFjdHVhbGx5IGl0IGlzIGVub3VnaC4gV2UgYXJlIG5vdCBjaGFuZ2luZyBv ciByZXBsYWNpbmcgdGhlIHRvcC1sZXZlbA0KPj4+IGRhdGEuIFdlIGFyZSBqdXN0IHVzaW5nIGl0 IGRpZmZlcmVudGx5IC0gZm9yIHByZWZpeC1TSUQgc3ViLVRMViB0aGUNCj4+PiBwcmVmaXgvbGVu Z3RoIGluIHRoZSB0b3AtbGV2ZWwgVExWIGlzIHVzZWQgYXMgYSAnc3RhcnQnIG9iamVjdC4NCj4+ Pg0KPj4+PiAyLiBTZXQgb2Ygb2JqZWN0cyAoaS5lLiB0aGUgcmFuZ2UpIG1heSBiZSBkaWZmZXJl bnQgaW4gZWFjaCBzdWItVExWDQo+Pj4+dGh1cw0KPj4+PiByYWlzaW5nIGNvbmNlcm5zIG9mIGFt YmlndWl0eQ0KPj4+DQo+Pj4gdGhpcyBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG1vcmUgYW1iaWd1 aXR5IHRoZW4gYW55IG90aGVyIGVuY29kaW5nDQo+Pj53aGljaA0KPj4+IGluY2x1ZGVzIHByZWZp eC9tYXNrL2NvdW50IHZhcmlhYmxlcy4NCj4+Pg0KPj4+PiAzLiBUZXh0IHJlcXVpcmVzIHRoYXQg YW5jaG9yIGlzIGFkdmVydGlzZWQgb25seSBvbmNlIGJ1dCB0aGVyZSBpcyBubw0KPj4+PiByZXF1 aXJlbWVudCB0aGF0IHJhbmdlcyBhZHZlcnRpc2VkIGZvciBkaWZmZXJlbnQgYW5jaG9ycyBjYW5u b3QNCj4+Pj5vdmVybGFwDQo+Pj4NCj4+PiBhY3R1YWxseSB0aGVyZSBpcyBubyByZWFzb24gd2h5 IHRoZXkgY2FuIG5vdCBvdmVybGFwLiBXZSBoYXZlIG92ZXJsYXBzDQo+Pj4gdG9kYXkgd2l0aCBw cmVmaXgvbWFzayBzZW1hbnRpY3MgYXMgd2VsbCBhbmQgd2UgZGVhbCB3aXRoIHRoZW0uDQo+Pj4N Cj4+Pj4NCj4+Pj4gSXQgd291bGQgaGF2ZSBiZWVuIG1vcmUgbG9naWNhbCB0byBkZWZpbmUgcmFu Z2UgaW4gdGhlICJPU1BGIEV4dGVuZGVkDQo+Pj4+IFByZWZpeCBUTFYiIGhlYWRlciBpdHNlbGYs IG5vdCBpbiBlYWNoIHN1Yi1UTFYuIFRoaXMgc3BlY2lmaWVzIHRoZQ0KPj4+PiBvYmplY3QgKGku ZS4gdGhlIHJhbmdlKSBpbiB0aGUgdG9wbW9zdCBUTFYgYW5kIHJlc29sdmVzIHByb2JsZW1zDQo+ Pj4+IG1lbnRpb25lZCBhYm92ZS4NCj4+Pg0KPj4+IHdlIHdhbnRlZCB0byBwcmVzZXJ2ZSB0aGUg cHJlZml4L2xlbmd0aCBzZW1hbnRpY3Mgd2VsbCBrbm93biBmcm9tDQo+Pj4gY3VycmVudCBPU1BG LiBNYWtpbmcgc2l6ZSBtYW5kYXRvcnkgd291bGQgYmUgYSBzaWduaWZpY2FudCBkZXZpYXRpb24N Cj4+PiBmcm9tIHRoZSBjdXJyZW50IE9TUEYgc3BlYy4NCj4+Pg0KPj4+IFByZWZpeC1TSUQgJ2Nv dW50JyBzZW1hbnRpY3MgaXMgc29tZXRoaW5nIHNwZWNpZmljIHRvIHRoZSBTSUQgYW5kIGlzDQo+ Pj4gbW9yZSBvZiBhbiBleGNlcHRpb24gYW5kIElNSE8gc2hvdWxkIG5vdCBmb3JjZSB1cyB0byB0 byBkZXZpYXRlIGZyb20NCj4+PiByZXByZXNlbnRhdGlvbiB3ZSBhcmUgdXNlZCB0byB3b3JrIHdp dGguDQo+Pj4NCj4+PiB0aGFua3MsDQo+Pj4gUGV0ZXINCj4+Pg0KPj4+DQo+Pj4NCj4+Pj4NCj4+ Pj4gQW50b24NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMDcvMDMvMjAxNCAxMDowOSBBTSwgUGV0ZXIg UHNlbmFrIHdyb3RlOg0KPj4+Pj4gSGkgQWNlZSwNCj4+Pj4+DQo+Pj4+PiBwbGVhc2Ugc2VlIGlu bGluZToNCj4+Pj4+DQo+Pj4+PiBPbiA3LzIvMTQgMTk6MTcgLCBBY2VlIExpbmRlbSB3cm90ZToN Cj4+Pj4+PiBIaSBQZXRlciwNCj4+Pj4+PiBJdCBzZWVtcyB0aGVyZSBhcmUgdHdvIGRpc3RpbmN0 IGRlcGxveW1lbnQgc2NlbmFyaW9zIC0gb25lIHdoZXJlIFNSDQo+Pj4+Pj4gcm91dGVycyBhcmUg Z2l2ZW4gYSByYW5nZSBhbmQgcG9saWN5IGFuZCBhbGxvY2F0ZSB0aGVpciBvd24gU0lEcyBhbmQN Cj4+Pj4+PiBhbm90aGVyIHdoZXJlIGEgbWFwcGluZyBzZXJ2ZXIgZG9lcyBpdCBmb3IgdGhlIHJv dXRpbmcgZG9tYWluLg0KPj4+Pj4NCj4+Pj4+IHllcywgdGhhdCBpcyBjb3JyZWN0LiBUaGUgbGF0 dGVyIGlzIHVzZWQgbWFpbmx5IGR1cmluZyBtaWdyYXRpb24gZnJvbQ0KPj4+Pj4gTERQIHRvIFNS Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICA2LiBTZWN0aW9uIDQuMiAt IEkgcmVhbGx5IGRvbqn2dCBsaWtlIGhhdmluZyBoaXMgc3ViLVRMVg0KPj4+Pj4+Pj4gcmVkZWZp bmUgdGhlIHN1YnN1bWluZyB0b3AtbGV2ZWwgVExWIGFzIGEgcmFuZ2Ugb2YgcHJlZml4ZXMgb2Yg dGhlDQo+Pj4+Pj4+PiBzYW1lIGxlbmd0aCByYXRoZXIgdGhhbiBhIHNpbmdsZSBwcmVmaXguIEFs dGhvdWdoIHRoaXMgaXMgbXkgZmlyc3QNCj4+Pj4+Pj4+IHNlcmlvdXMgcmVhZGluZyBvZiB0aGUg ZHJhZnQsIHRoaXMgZW5jb2Rpbmcgc2VlbXMgcmVhbGx5IHVud2llbGR5DQo+Pj4+Pj4+PiBhbmQs IGluIHByYWN0aWNlLCBJqfZkIGV4cGVjdCB0aGUgcmFuZ2Ugc2l6ZSBhbHdheXMgYWR2ZXJ0aXNl ZCBhcw0KPj4+Pj4+Pj4xLg0KPj4+Pj4+Pj4gV2UgY2FuIGRpc2N1c3MgdGhpcyBtb3JlIGluIFRv cm9udG8uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IGFuIGV4YW1wbGUgd2hlcmUgdGhlIHJhbmdlIHdvdWxk IGJlIG1vcmUgdGhlbiAxIGlzIGEgbWFwcGluZyBzZXJ2ZXINCj4+Pj4+Pj4gY2FzZS4gVGhpcyBo ZWxwcyB5b3UgdG8gYWR2ZXJ0aXNlIFNJRHMgZm9yIGxvb3BiYWNrIGFkZHJlc3NlcyBvZg0KPj4+ Pj4+PmFsbA0KPj4+Pj4+PiByb3V0ZXJzIGluIGEgbm9uLVNSIGNhcGFibGUgcGFydCBvZiB0aGUg bmV0d29yaywgYXNzdW1pbmcgdGhleSBhcmUNCj4+Pj4+Pj4gYWxsb2NhdGVkIGZyb20gdGhlIGNv bnRpZ3VvdXMgYWRkcmVzcyBzcGFjZS4gSW5zdGVhZCBvZiBhZHZlcnRpc2luZw0KPj4+Pj4+PiBo dW5kcmVkcyBvZiBtYXBwaW5ncyBmb3IgZWFjaCAvMzIgYWRkcmVzcywgeW91IGNhbiBjb21wYWN0 IGl0IHRvIGENCj4+Pj4+Pj4gc2luZ2xlIGFkdmVydGlzZW1lbnQuDQo+Pj4+Pj4NCj4+Pj4+PiBJ qfZ2ZSBzZWVuIGxvb3BiYWNrcyBhbGxvY2F0ZWQgc2VxdWVudGlhbGx5IGluIGEgZmV3IG5ldHdv cmtzIGJ1dA0KPj4+Pj4+bWFueQ0KPj4+Pj4+IG1vcmUgd2hlcmUgdGhlcmUgd2VyZW6p9nQuDQo+ Pj4+Pg0KPj4+Pj4gc3RpbGwsIGhhdmluZyBhIG1lY2hhbmlzbSB0byBjb21wYWN0IHRoZSBhZHZl cnRpc2VtZW50cyBpZiBwb3NzaWJsZQ0KPj4+Pj4gbG9va3MgYXBwZWFsaW5nLg0KPj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXaGF0IHlvdSBuZWVkIGluIHN1Y2ggY2FzZSBpcyBjb21w b25lbnQgcHJlZml4L2xlbmd0aCBwbHVzIHRoZQ0KPj4+Pj4+Pm51bWJlcg0KPj4+Pj4+PiBvZiBj b21wb25lbnRzIC0gT1NQRiBFeHRlbmRlZCBQcmVmaXggVExWIGdpdmVzIHlvdSB0aGUgY29tcG9u ZW50DQo+Pj4+Pj4+aW5mbw0KPj4+Pj4+PiBhbmQgUHJlZml4IFNJRCBTdWItVExWICJSYW5nZSBT aXplJyBnaXZlcyB5b3UgdGhlIG51bWJlciBvZg0KPj4+Pj4+PiBjb21wb25lbnRzLg0KPj4+Pj4+ DQo+Pj4+Pj4gSSB1bmRlcnN0b29kIGl0IGJ1dCBJIGRvbqn2dCBsaWtlIHRoZSBzdWItVExWIGV4 dGVuZGluZyB0aGUNCj4+Pj4+PiBzcGVjaWZpY2F0aW9uIG9mIHRoZSBoaWdoZXIgbGV2ZWwgVExW LiBJIGVzcGVjaWFsbHkgZG9uqfZ0IGxpa2UgaXQNCj4+Pj4+PiBzaW5jZSB0aGUgdG9wLWxldmVs IFRMViBpcyBhIGdlbmVyaWMgbWVjaGFuaXNtIHRvIGFkdmVydGlzZQ0KPj4+Pj4+IGF0dHJpYnV0 ZXMuICBXaGVuIGFkZGl0aW9uYWwgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCwgaXQgYmVncyB0aGUg b2YNCj4+Pj4+PiB3aGV0aGVyIG9yIG5vdCB0aGV5IGFwcGx5IHNvbGVseSB0byB0aGUgcHJlZml4 IG9yIHRvIHRoZSByYW5nZS4NCj4+Pj4+DQo+Pj4+PiBoaWdoIGxldmVsIFRMViBhZHZlcnRpc2Ug YSBzaW5nbGUgcHJlZml4L21hc2suIEl0J3MgdGhlIHN1Yi1UTFYgd2hpY2gNCj4+Pj4+IG1heSBl eHRlbmQgdGhlIGFwcGxpY2FiaWxpdHkgdG8gdGhlIHJhbmdlIGlmIHJlcXVpcmVkLCBzbyB0aGUg c2NvcGUNCj4+Pj4+aXMNCj4+Pj4+IGRlZmluZWQgYnkgZWFjaCBzdWItVExWLg0KPj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXZSBjb3VsZCBoYXZlIGRlZmluZWQgYSBzZXBhcmF0ZSB0 b3AgbGV2ZWwgVExWIGluIE9TUEYgRXh0ZW5kZWQNCj4+Pj4+Pj4gUHJlZml4IExTQSBmb3IgdGhl IGFkdmVydGlzZW1lbnQgb2YgcmFuZ2Ugb2YgY29tcG9uZW50cywgYnV0IGl0DQo+Pj4+Pj4+bG9v a3MNCj4+Pj4+Pj4gdG8gbWUgdGhhdCB3b3VsZCBiZSBhbiBvdmVya2lsbC4NCj4+Pj4+Pg0KPj4+ Pj4+IEkgd291bGQgaGF2ZSBwcmVmZXJyZWQgdGhhdC4gV2hlbiB0aGUgU0lEIGF0dHJpYnV0ZXMg YXJlIGVtYmVkZGVkDQo+Pj4+Pj4gKE9TUEZ2MyBhbmQgSVNJUyksIEkgdGhpbmsgdGhlIHNlbWFu dGljcyBhcmUgZXZlbiBtb3JlIHVubmF0dXJhbA0KPj4+Pj4+c2luY2UNCj4+Pj4+PiByZWFjaGFi aWxpdHkgTUFZIGJlIGFkdmVydGlzZWQgZm9yIHRoZSBwcmVmaXggd2hpbGUgU0lEIG1hcHBpbmcg aXMNCj4+Pj4+PiBiZWluZyBhZHZlcnRpc2VkIGZvciB0aGUgcmFuZ2UuDQo+Pj4+Pg0KPj4+Pj4g SSBoYWQgdGhlIHNhbWUgcmVzZXJ2YXRpb25zIGF0IHRoZSBiZWdpbm5pbmcgOikNCj4+Pj4+IEJ1 dCB0aGVyZSBpcyBubyBwcm9ibGVtIHJlYWxseS4gUHJlZml4LVNJRCBzdWItVExWIG5ldmVyIGFk dmVydGlzZXMNCj4+Pj4+YW55DQo+Pj4+PiByZWFjaGFiaWxpdHksIHdoZXRoZXIgaXQgYWR2ZXJ0 aXNlcyBhIHNpbmdsZSBTSUQgb3IgYSByYW5nZSBvZiBTSURzLg0KPj4+Pj4gRm9yDQo+Pj4+PiBQ cmVmaXgtU0lEIHN1Yi1UTFYsIHByZWZpeCBmcm9tIHRoZSBoaWdoZXIgbGV2ZWwgVExWIGhhcyBh IG1lYW5pbmcgb2YNCj4+Pj4+ICJzdGFydCIgYW5kIFByZWZpeC1TSUQgc3ViLVRMViBhbHdheXMg Y2FycnkgaXRzIG93biAic2l6ZSIgLSBqdXN0IGENCj4+Pj4+IGRpZmZlcmVudCBpbnRlcnByZXRh dGlvbiBvZiB0aGUgZGF0YSBmcm9tIHRoZSBoaWdoZXIgbGV2ZWwgVExWLg0KPj4+Pj4NCj4+Pj4+ IFBsZWFzZSBub3RlIHRoYXQgU0lEIHJhbmdlIGlzIHF1aXRlIGRpZmZlcmVudCBmcm9tIHRoZSBh ZGRyZXNzIHJhbmdlDQo+Pj4+PndlDQo+Pj4+PiBhcmUgdXNlZCB0byBmcm9tIHN1bW1hcml6YXRp b24uIFNJRCByYW5nZSByZXF1aXJlcyB0aHJlZSBwYXJhbWV0ZXJzDQo+Pj4+PiAoYWRkcmVzcy9t YXNrIGFuZCBjb3VudCksIGNvbXBhcmVkIHRvIHR3byBwYXJhbWV0ZXIgKGFkZHJlc3MvbWFzaykN Cj4+Pj4+dGhhdA0KPj4+Pj4gdHJhZGl0aW9uYWwgYWRkcmVzcyByYW5nZSB1c2VzLiBBcyBhIHJl c3VsdCwgRXh0ZW5kZWQgcHJlZml4IFRMViBhcw0KPj4+Pj4gc3VjaA0KPj4+Pj4gY2FuIG5vdCBj b3ZlciB0aGUgU0lEIHJhbmdlLCBiZWNhdXNlIGl0IG9ubHkgaGFzIGFkZHJlc3MvbWFzay4NCj4+ Pj4+RGVmaW5pbmcNCj4+Pj4+IGEgdG9wLWxldmVsIFRMViBmb3IgYSBTSUQgcmFuZ2UgaXRzZWxm IGRvZXMgbm90IHJlYWxseSBmaXQgaW50bw0KPj4+Pj4gRXh0ZW5kZWQNCj4+Pj4+IFByZWZpeCBM U0EgYW5kIGhhdmluZyBhIG5ldyBMU0EgZm9yIGl0IGlzIG5vdCBhbiBvcHRpb24gSSB3b3VsZCBz YXkuDQo+Pj4+PlNvDQo+Pj4+PiB0aGUgY3VycmVudCBlbmNvZGluZyBsb29rcyBsaWtlIGEgZ29v ZCBjb21wcm9taXNlIHRvIG1lLg0KPj4+Pj4NCj4+Pj4+IHRoYW5rcywNCj4+Pj4+IFBldGVyDQo+ Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+IEN1cnJlbnQgZW5jb2Rpbmcgb2YgUHJlZml4IFNJRCBTdWIt VExWIGdpdmVzIHVzIGFsbCB0aGUgZmxleGliaWxpdHkNCj4+Pj4+Pj4gd2UgbmVlZC4gSW4gYWRk aXRpb24gaXQgbWF0Y2hlcyB3aGF0IElTSVMgaGFzIGRvbmUuDQo+Pj4+Pj4NCj4+Pj4+PiBJIGhh dmVuqfZ0IHNlZW4gYW55IGRpc2N1c3Npb24gb2YgdGhlIGRyYWZ0IG9uIHRoZSBJU0lTIGxpc3Qg b3RoZXINCj4+Pj4+PnRoYW4NCj4+Pj4+PiB0aGUgcmV2aXNpb24gdXBkYXRlcy4NCj4+Pj4+Pg0K Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiBBY2VlDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICA3LiBTZWN0aW9uIDQuMiAt IFNob3VsZG6p9nQgdGhlIHJlZmVyZW5jZSBmb3IgdGhlIG1hcHBpbmcNCj4+Pj4+Pj4+IHNlcnZl ciBiZSB0aGUgqfhTZWdtZW50IFJvdXRpbmcgQXJjaGl0ZWN0dXJlqfcgcmF0aGVyIHRoYW4gdGhl DQo+Pj4+Pj4+PiCp+FNlZ21lbnQgUm91dGluZyBVc2UgQ2FzZXOp9z8gSW4gZ2VuZXJhbCwgdGhl IHVzYWdlIG9mIGEgbWFwcGluZw0KPj4+Pj4+Pj4gc2VydmVyIGFuZCB0aGUgc2NvcGUgb2YgYXNz aWdubWVudCBuZWVkcyB0byBiZSBkZXNjcmliZWQgYmV0dGVyDQo+Pj4+Pj4+PiBzb21ld2hlcmUg KG5vdCBpbiB0aGUgT1NQRiBlbmNvZGluZyBkb2N1bWVudCkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IHdp bGwgZml4IHRoZSByZWZlcmVuY2UNCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAg IDguIFNlY3Rpb24gNiAtIEl0IHdvdWxkIHNlZW0gdGhhdCBhbiBlbnRpdHkgY2FsY3VsYXRpbmcg YQ0KPj4+Pj4+Pj4gbXVsdGktYXJlYSBTUiBwYXRoIHdvdWxkIG5lZWQgYWNjZXNzIHRvIHRoZSB0 b3BvbG9neSBmb3IgYWxsIHRoZQ0KPj4+Pj4+Pj4gYXJlYXMgYW5kIHRoZSBTSUQgd291bGQgbmVl ZCB0byBiZSBnbG9iYWxseSBhc3NpZ25lZD8gUmlnaHQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IGNvcnJl Y3QuDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBTbyBydWxlcyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgcG9w dWxhdGlvbiBvZiB0aGUgZm9yd2FyZGluZyBwbGFuZS4NCj4+Pj4+Pj4+IFJpZ2h0Pw0KPj4+Pj4+ Pg0KPj4+Pj4+PiBmb3IgYWR2ZXJ0aXNlbWVudC9wcm9wYWdhdGlvbiBvZiBTSURzIGFuZCBmb3Ig Zm9yd2FyZGluZyBwbGFuZQ0KPj4+Pj4+PiBwcm9ncmFtbWluZy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiAgICAgICAgIDkuIFNlY3Rpb24gNi4yIC0gSW4gc3RhbmRhcmQgT1NQRiwgaW50 ZXItYXJlYSBzdW1tYXJ5DQo+Pj4+Pj4+PiBwcm9wYWdhdGlvbiBvbmx5IGFwcGxpZXMgdG8gaW50 ZXItYXJlYSByb3V0ZXMgbGVhcm5lZCBvdmVyIHRoZQ0KPj4+Pj4+Pj4gYmFja2JvbmUuIElzIHRo aXMgYW55IGRpZmZlcmVudD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gbm8sIHRoZSBtZWNoYW5pc20gaXMg dGhlIHNhbWUgYXMgZm9yIHR5cGUtM3MuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IHRoYW5rcywNCj4+Pj4+ Pj4gUGV0ZXINCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+PiBB Y2VlDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAuDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gLg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IE9TUEYgbWFpbGlu ZyBsaXN0DQo+Pj4+PiBPU1BGQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29zcGYNCj4+Pj4gLg0KPj4+Pg0KPj4+DQo+PiAuDQo+Pg0KPg0KDQoN Cg== From nobody Wed Jul 9 03:22:44 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653881A03BE for ; Wed, 9 Jul 2014 03:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a97VNwxfUnEY for ; Wed, 9 Jul 2014 03:22:39 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121191A000D for ; Wed, 9 Jul 2014 03:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12135; q=dns/txt; s=iport; t=1404901367; x=1406110967; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q0XGHct02JogaaYlKoMm3CMlcOrcFUicMjfiHsJCtT8=; b=RAWxn0hqqEBCnscf1tQSrmod/Iaf2dmx1RuRxoqSEY6yClq+D0ZTeL6I SHFWyJQSxM4iQYwaPZHuz9pr6FvpxIC3Kft60Xcr7tA+N4mE/iQn2BzyX GB2qep50WF5iXWh3iTNiAn08uXTki4yx586Uzme15+JRcZB69aJI7GzTN 8=; X-IronPort-AV: E=Sophos;i="5.01,630,1400025600"; d="scan'208";a="107722384" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Jul 2014 10:22:45 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s69AMalS028490; Wed, 9 Jul 2014 10:22:37 GMT Message-ID: <53BD17ED.3090108@cisco.com> Date: Wed, 09 Jul 2014 12:22:37 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem , Anton Smirnov References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OHFqtAJhf4ao_D_ua23ZQ-9GJNE Cc: OSPF List Subject: Re: [OSPF] Comments draft-ietf-ospf-segment-routing-extensions-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 09 Jul 2014 10:22:42 -0000 Hi Acee, On 7/9/14 11:50 , Acee Lindem wrote: >> as I mentioned in the previous email, we want to preserve the prefix >> representation by prefix/length in top-level TLV as that is sufficient >> for almost all attributes. If people do not like the range in the Prefix >> SID and SID/Label Binding sub-TLVs, then I prefer to define a new top >> level TLV that would be used to advertise attributes for a prefix block, >> which would be represented by prefix/length/count. I'm afraid it will >> not be used for anything except the Prefix SID & SID/Label Binding >> sub-TLV though - history shows we never needed such prefix block in the >> past. > > Is this the only downside of a separate range top-level TLV? If so, then > it seems this would provide a cleaner encoding.I don©öt like allowing range > attributes and single prefix attributes to be mixed. Even with the current > encoding, we are going to have to handle the ambiguity of overlapping > ranges so I don©öt see a separate top-level TLV and adding more complexity. ok, let's discuss during IETF. thanks, Peter > > Thanks, > Acee > > >> >> thanks, >> Peter >> >>> Prefix SID Sub-TLV >>> SID >>> SID/Label Binding sub-TLV >>> Binding >>> >>> Anton >>> >>> >>> On 07/08/2014 10:04 PM, Peter Psenak wrote: >>>> Anton, >>>> >>>> please see inline: >>>> >>>> On 7/8/14 20:08 , Anton Smirnov wrote: >>>>> Hi Peter, >>>>> in current text ranges are not required to be processed and I >>>>> think >>>>> this kills their potential usage: >>>>> >>>>> If multiple Prefix-SIDs are advertised for the same prefix, the >>>>> receiving router MUST use the first encoded SID and MAY use the >>>>> subsequent ones. >>>> >>>> I do not see any connection between ranges and the above text. Above >>>> text says that if there are multiple prefix SIDs advertised, for a >>>> single prefix, every implementation MUST process at least the first >>>> one. >>>> Typically only a single SID will be advertised for each prefix >>>> regardless of the range being 1 or more. >>>> >>>>> >>>>> (and similar text for inter-area LSA origination). >>>>> Subsequent prefixes may be used or may be ignored. And if they are >>>> >>>> there are no subsequent prefixes. Each prefix is advertised in a >>>> separate top level TLV and will have it's own prefix-SID sub-TLV, only >>>> belonging to that prefix. >>>> >>>>> ignored then it is originator's fault, receiver has all rights to >>>>> ignore >>>>> them. If the mapping server wants to ensure every router installs >>>>> prefix >>>>> attributes then it has no choice but to break the range and advertise >>>>> each prefix individually. >>>>> So IMO ranges processing must be required on every step, otherwise >>>>> they will never be used. >>>>> >>>> >>>> please see above. >>>> >>>>> >>>>> >>>>> >>>>> > high level TLV advertise a single prefix/mask. It's the sub-TLV >>>>> which >>>>> > may extend the applicability to the range if required, so the >>>>> scope is >>>>> > defined by each sub-TLV. >>>> >>>> the way to look at it is that the top-level TLV always advertises a >>>> single prefix in a form of prefix/length. Nested sub-TLVs have their >>>> own >>>> data, which are interpreted based on the sub-TLV specification, they do >>>> not change what is in the top-level TLV. The fact that some sub-TLV has >>>> a count variable and use the prefix/mask as starting point makes no >>>> impact on the top-level data. >>>> >>>>> >>>>> That what makes ranges counter intuitive. Intuitive hierarchy is >>>>> object on the top and then subordinate items describing properties of >>>>> the object: >>>>> >>>>> Object --- >>>>> | >>>>> |- attribute1 >>>>> |- attribute2 >>>>> >>>>> >>>>> But the current scheme does not define object at the top of the >>>>> hierarchy, real object is defined together with property: >>>>> >>>>> Anchor --- >>>>> | >>>>> |- range-of-objects-and-attribute1 >>>>> |- range-of-objects-and-attribute2 >>>>> >>>>> There are three problems with this representation: >>>>> 1. Anchor (i.e. top level TLV) is not enough to determine which >>>>> objects >>>>> (i.e. prefixes) are affected and which are not >>>> >>>> actually it is enough. We are not changing or replacing the top-level >>>> data. We are just using it differently - for prefix-SID sub-TLV the >>>> prefix/length in the top-level TLV is used as a 'start' object. >>>> >>>>> 2. Set of objects (i.e. the range) may be different in each sub-TLV >>>>> thus >>>>> raising concerns of ambiguity >>>> >>>> this does not introduce any more ambiguity then any other encoding >>>> which >>>> includes prefix/mask/count variables. >>>> >>>>> 3. Text requires that anchor is advertised only once but there is no >>>>> requirement that ranges advertised for different anchors cannot >>>>> overlap >>>> >>>> actually there is no reason why they can not overlap. We have overlaps >>>> today with prefix/mask semantics as well and we deal with them. >>>> >>>>> >>>>> It would have been more logical to define range in the "OSPF Extended >>>>> Prefix TLV" header itself, not in each sub-TLV. This specifies the >>>>> object (i.e. the range) in the topmost TLV and resolves problems >>>>> mentioned above. >>>> >>>> we wanted to preserve the prefix/length semantics well known from >>>> current OSPF. Making size mandatory would be a significant deviation >>>> from the current OSPF spec. >>>> >>>> Prefix-SID 'count' semantics is something specific to the SID and is >>>> more of an exception and IMHO should not force us to to deviate from >>>> representation we are used to work with. >>>> >>>> thanks, >>>> Peter >>>> >>>> >>>> >>>>> >>>>> Anton >>>>> >>>>> >>>>> On 07/03/2014 10:09 AM, Peter Psenak wrote: >>>>>> Hi Acee, >>>>>> >>>>>> please see inline: >>>>>> >>>>>> On 7/2/14 19:17 , Acee Lindem wrote: >>>>>>> Hi Peter, >>>>>>> It seems there are two distinct deployment scenarios - one where SR >>>>>>> routers are given a range and policy and allocate their own SIDs and >>>>>>> another where a mapping server does it for the routing domain. >>>>>> >>>>>> yes, that is correct. The latter is used mainly during migration from >>>>>> LDP to SR. >>>>>> >>>>>> >>>>>> >>>>>>>>> 6. Section 4.2 - I really don©öt like having his sub-TLV >>>>>>>>> redefine the subsuming top-level TLV as a range of prefixes of the >>>>>>>>> same length rather than a single prefix. Although this is my first >>>>>>>>> serious reading of the draft, this encoding seems really unwieldy >>>>>>>>> and, in practice, I©öd expect the range size always advertised as >>>>>>>>> 1. >>>>>>>>> We can discuss this more in Toronto. >>>>>>>> >>>>>>>> an example where the range would be more then 1 is a mapping server >>>>>>>> case. This helps you to advertise SIDs for loopback addresses of >>>>>>>> all >>>>>>>> routers in a non-SR capable part of the network, assuming they are >>>>>>>> allocated from the contiguous address space. Instead of advertising >>>>>>>> hundreds of mappings for each /32 address, you can compact it to a >>>>>>>> single advertisement. >>>>>>> >>>>>>> I©öve seen loopbacks allocated sequentially in a few networks but >>>>>>> many >>>>>>> more where there weren©öt. >>>>>> >>>>>> still, having a mechanism to compact the advertisements if possible >>>>>> looks appealing. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> What you need in such case is component prefix/length plus the >>>>>>>> number >>>>>>>> of components - OSPF Extended Prefix TLV gives you the component >>>>>>>> info >>>>>>>> and Prefix SID Sub-TLV "Range Size' gives you the number of >>>>>>>> components. >>>>>>> >>>>>>> I understood it but I don©öt like the sub-TLV extending the >>>>>>> specification of the higher level TLV. I especially don©öt like it >>>>>>> since the top-level TLV is a generic mechanism to advertise >>>>>>> attributes. When additional attributes are defined, it begs the of >>>>>>> whether or not they apply solely to the prefix or to the range. >>>>>> >>>>>> high level TLV advertise a single prefix/mask. It's the sub-TLV which >>>>>> may extend the applicability to the range if required, so the scope >>>>>> is >>>>>> defined by each sub-TLV. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> We could have defined a separate top level TLV in OSPF Extended >>>>>>>> Prefix LSA for the advertisement of range of components, but it >>>>>>>> looks >>>>>>>> to me that would be an overkill. >>>>>>> >>>>>>> I would have preferred that. When the SID attributes are embedded >>>>>>> (OSPFv3 and ISIS), I think the semantics are even more unnatural >>>>>>> since >>>>>>> reachability MAY be advertised for the prefix while SID mapping is >>>>>>> being advertised for the range. >>>>>> >>>>>> I had the same reservations at the beginning :) >>>>>> But there is no problem really. Prefix-SID sub-TLV never advertises >>>>>> any >>>>>> reachability, whether it advertises a single SID or a range of SIDs. >>>>>> For >>>>>> Prefix-SID sub-TLV, prefix from the higher level TLV has a meaning of >>>>>> "start" and Prefix-SID sub-TLV always carry its own "size" - just a >>>>>> different interpretation of the data from the higher level TLV. >>>>>> >>>>>> Please note that SID range is quite different from the address range >>>>>> we >>>>>> are used to from summarization. SID range requires three parameters >>>>>> (address/mask and count), compared to two parameter (address/mask) >>>>>> that >>>>>> traditional address range uses. As a result, Extended prefix TLV as >>>>>> such >>>>>> can not cover the SID range, because it only has address/mask. >>>>>> Defining >>>>>> a top-level TLV for a SID range itself does not really fit into >>>>>> Extended >>>>>> Prefix LSA and having a new LSA for it is not an option I would say. >>>>>> So >>>>>> the current encoding looks like a good compromise to me. >>>>>> >>>>>> thanks, >>>>>> Peter >>>>>> >>>>>>> >>>>>>>> Current encoding of Prefix SID Sub-TLV gives us all the flexibility >>>>>>>> we need. In addition it matches what ISIS has done. >>>>>>> >>>>>>> I haven©öt seen any discussion of the draft on the ISIS list other >>>>>>> than >>>>>>> the revision updates. >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 7. Section 4.2 - Shouldn©öt the reference for the mapping >>>>>>>>> server be the ©øSegment Routing Architecture©÷ rather than the >>>>>>>>> ©øSegment Routing Use Cases©÷? In general, the usage of a mapping >>>>>>>>> server and the scope of assignment needs to be described better >>>>>>>>> somewhere (not in the OSPF encoding document). >>>>>>>> >>>>>>>> will fix the reference >>>>>>>> >>>>>>>>> >>>>>>>>> 8. Section 6 - It would seem that an entity calculating a >>>>>>>>> multi-area SR path would need access to the topology for all the >>>>>>>>> areas and the SID would need to be globally assigned? Right? >>>>>>>> >>>>>>>> correct. >>>>>>>> >>>>>>>>> So rules are primarily for the population of the forwarding plane. >>>>>>>>> Right? >>>>>>>> >>>>>>>> for advertisement/propagation of SIDs and for forwarding plane >>>>>>>> programming. >>>>>>>> >>>>>>>>> >>>>>>>>> 9. Section 6.2 - In standard OSPF, inter-area summary >>>>>>>>> propagation only applies to inter-area routes learned over the >>>>>>>>> backbone. Is this any different? >>>>>>>> >>>>>>>> no, the mechanism is the same as for type-3s. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Peter >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Acee >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> . >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> . >>>>> >>>> >>> . >>> >> > > From nobody Sun Jul 13 04:18:22 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BAA1B2A67 for ; Sun, 13 Jul 2014 04:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOyztgzkPNSo for ; Sun, 13 Jul 2014 04:18:19 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2508E1B2A5C for ; Sun, 13 Jul 2014 04:18:19 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:33956] helo=[10.0.1.6]) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 0C/16-17895-AFA62C35; Sun, 13 Jul 2014 11:18:18 +0000 From: Acee Lindem Content-Type: multipart/alternative; boundary="Apple-Mail=_3D0B468C-BC89-4D74-83A7-5F79BBD67944" Date: Sun, 13 Jul 2014 07:18:17 -0400 Message-Id: To: Anton Smirnov Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/7YAAsNbzDWcDNjuQhw0k5B-AwvY Cc: OSPF List , Ing-Wher Chen Subject: Re: [OSPF] FW: New Version Notification for draft-chen-ospf-transition-to-ospfv3-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jul 2014 11:18:21 -0000 --Apple-Mail=_3D0B468C-BC89-4D74-83A7-5F79BBD67944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Anton,=20 On Jul 8, 2014, at 7:11 AM, Anton Smirnov wrote: > Hi Helen, > I believe encapsulation choice is per-link decision, i.e. there = shouldn't be any problems in running IPv4 AF OSPFv3 over IPv4 on one = link of a router and IPv4 AF OSPFv3 over IPv6 on another link as long as = all routers connected to each link use the same encapsulation. Yes - this should be possible for OSPF interfaces and could be useful if = one wants to use standard IPv6 encapsulation in all cases except a = particular interface that doesn=92t support IPv6 (as described in = section 3).=20 > Likewise, if IPv4 AF VL packets themselves are IPv4-encapsulated it = shouldn't matter if physical links are using IPv6 or IPv4 encapsulation. = The draft's text could be more clear on this aspect. Since the virtual link endpoint is determined dynamical and a virtual = link is only considered up when there is reachability in the transit = area, OSPF for an address family differing from the encapsulation cannot = work without mechanisms outside the protocol., Hence, this isn=92t = something that will included in the scope of this draft.=20 Thanks, Acee=20 >=20 > Anton >=20 >=20 > On 07/02/2014 04:02 PM, Ing-Wher Chen wrote: >> Hello, >>=20 >> Acee, Ran, and I have updated the following draft to address the = feedback at the last meeting and on the mailing list. In particular, a = new section on IPv4 use case has been added, and the edits that Karsten = suggested back on Feb. 17, 2014 have also been incorporated. >>=20 >> Thanks, >> Helen >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, July 02, 2014 9:27 AM >> To: R. Atkinson; Ing-Wher Chen; Ing-Wher Chen; Acee Lindem; Acee = Lindem >> Subject: New Version Notification for = draft-chen-ospf-transition-to-ospfv3-01.txt >>=20 >>=20 >> A new version of I-D, draft-chen-ospf-transition-to-ospfv3-01.txt >> has been successfully submitted by I. Chen and posted to the IETF = repository. >>=20 >> Name: draft-chen-ospf-transition-to-ospfv3 >> Revision: 01 >> Title: OSPFv3 over IPv4 for IPv6 Transition >> Document date: 2014-07-02 >> Group: Individual Submission >> Pages: 9 >> URL: = http://www.ietf.org/internet-drafts/draft-chen-ospf-transition-to-ospfv3-0= 1.txt >> Status: = https://datatracker.ietf.org/doc/draft-chen-ospf-transition-to-ospfv3/ >> Htmlized: = http://tools.ietf.org/html/draft-chen-ospf-transition-to-ospfv3-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-ospf-transition-to-ospfv3-01= >>=20 >> Abstract: >> This document defines a mechanism to use IPv4 to transport OSPFv3 >> packets, in order to facilitate transition from IPv4-only to IPv6 and >> dual-stack within a routing domain. Using OSPFv3 over IPv4 with the >> existing OSPFv3 Address Family extension can simplify transition from >> an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing >> domain. >>=20 >>=20 >>=20 >>=20 >> Pl --Apple-Mail=_3D0B468C-BC89-4D74-83A7-5F79BBD67944 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Anton, 
On Jul 8, 2014, at 7:11 AM, Anton Smirnov <asmirnov@cisco.com> = wrote:

Hi Helen,
I believe = encapsulation choice is per-link decision, i.e. there shouldn't be any = problems in running IPv4 AF OSPFv3 over IPv4 on one link of a router and = IPv4 AF OSPFv3 over IPv6 on another link as long as all routers = connected to each link use the same = encapsulation.

Yes - this should be possible for = OSPF interfaces and could be useful if one wants to use standard IPv6 = encapsulation in all cases except a particular interface that doesn=92t = support IPv6 (as described in section 3). 

Likewise, if IPv4 AF VL packets themselves are = IPv4-encapsulated it shouldn't matter if physical links are using IPv6 = or IPv4 encapsulation. The draft's text could be more clear on this = aspect.

Since the virtual link endpoint is = determined dynamical and a virtual link is only considered up when there = is reachability in the transit area, OSPF for an address family = differing from the encapsulation cannot work without mechanisms outside = the protocol., Hence, this isn=92t something that will included in the = scope of this = draft. 

Thanks,
Acee 




Anton


On 07/02/2014 04:02 PM, Ing-Wher Chen = wrote:
Hello,

Acee, Ran, and I have = updated the following draft to address the feedback at the last meeting = and on the mailing list.  In particular, a new section on IPv4 use = case has been added, and the edits that Karsten suggested back on Feb. = 17, 2014 have also been = incorporated.

Thanks,
Helen

-----Original = Message-----
From: internet-drafts@ietf.org = ;[mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 9:27 AM
To: R. Atkinson; = Ing-Wher Chen; Ing-Wher Chen; Acee Lindem; Acee Lindem
Subject: New = Version Notification for = draft-chen-ospf-transition-to-ospfv3-01.txt


A new version of = I-D, draft-chen-ospf-transition-to-ospfv3-01.txt
has been = successfully submitted by I. Chen and posted to the IETF = repository.

Name: = draft-chen-ospf-transition-to-ospfv3
Revision: = 01
Title: OSPFv3 over IPv4 for IPv6 Transition
Document = date: = 2014-07-02
Group: Individual = Submission
Pages: 9
URL: =            http://www.ietf.org/internet-drafts/draft-chen-ospf-transit= ion-to-ospfv3-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-chen-ospf-transition-to-ospfv= 3/
Htmlized:       http://tools.ietf.org/html/draft-chen-ospf-transition-to-ospfv3-01Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-ospf-transition-to= -ospfv3-01

Abstract:
This document defines a mechanism to = use IPv4 to transport OSPFv3
packets, in order to facilitate = transition from IPv4-only to IPv6 and
dual-stack within a routing = domain.  Using OSPFv3 over IPv4 with the
existing OSPFv3 Address = Family extension can simplify transition from
an OSFPv2 IPv4-only = routing domain to an OSPFv3 dual-stack = routing
domain.




Pl
= --Apple-Mail=_3D0B468C-BC89-4D74-83A7-5F79BBD67944-- From nobody Mon Jul 14 12:37:00 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA691A0AB6 for ; Mon, 14 Jul 2014 12:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TnFzkxgZpJo for ; Mon, 14 Jul 2014 12:36:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6831A009C for ; Mon, 14 Jul 2014 12:36:47 -0700 (PDT) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) with Microsoft SMTP Server (TLS) id 15.0.980.8; Mon, 14 Jul 2014 19:36:44 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0985.008; Mon, 14 Jul 2014 19:36:44 +0000 From: Chris Bowers To: Russ White , 'OSPF List' Thread-Topic: [OSPF] draft-atlas-ospf-mrt-02 Thread-Index: Ac+ZFv4nWa+hKUOQQ8u/arcrmksngAGgrqQQ Date: Mon, 14 Jul 2014 19:36:44 +0000 Message-ID: References: <02df01cf9917$9b05a650$d110f2f0$@riw.us> In-Reply-To: <02df01cf9917$9b05a650$d110f2f0$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(199002)(13464003)(189002)(81542001)(106356001)(76482001)(46102001)(99396002)(99286002)(74316001)(33646001)(92566001)(87936001)(19580395003)(95666004)(20776003)(76176999)(54356999)(83322001)(2656002)(74502001)(4396001)(66066001)(31966008)(101416001)(19580405001)(77982001)(74662001)(76576001)(64706001)(85852003)(15975445006)(86362001)(85306003)(83072002)(107046002)(81342001)(105586002)(80022001)(79102001)(21056001)(50986999)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB120; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/MLy2u9nGTHDBwVjvFyD339On2Wk Cc: Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 19:36:50 -0000 (The response to this question ended up off of the list, so I'm posting it = to continue the discussion on the list.)=20 Russ, I see your point in link information being carried in Node related LSA. =20 The link information is carried in Router LSA and it's not extendible to ca= rry any other information. Since RI-LSA is modeled as an extension to Router LSA, my idea was to tag t= he additional link information With new TLV in RI-LSA. Another approach could have been to define a new LSA type and originate a n= ew LSA for each link which is in-eligible to participate in MRT. A separate= LSA for each link to advertise ineligibility looks suboptimal considering = the amount of state machine/data structure that needs to be maintained for = a separate LSA. >> It seems like it might be better to move this bit of information into th= e TLV where the actual link state is advertised in some way. Link related information is advertised in OSPF-TE opaque LSAs as well. MRT = could run on non-TE enabled networks as well, so it may not be appropriate = to use TE LSAs. Let me know if you think we could stuff-in in existing LSAs or we should go= with new LSA altogether. Rgds, Shraddha -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Russ White Sent: Sunday, July 06, 2014 7:41 AM To: 'OSPF List' Cc: Alia Atlas Subject: [OSPF] draft-atlas-ospf-mrt-02 Just one question/comment on this draft -- In section 6.1, MRT-Ineligible L= inks TLV for OSPFv2, the draft says there should be a new TLV in the router= capabilities LSA that advertises links not to be included in the MRT calcu= lation (excluded links). I'm not certain why an option isn't used in the LS= A header for this, instead. Two things that seem strange to me: - The exclusion of a link is a link property, not a router property, so I'm= not certain why this would be advertised as a property of the OSPF router. This seems to muddy the line between router and properties and link propert= ies in a way that sets the stage for make the router capabilities just anot= her area into which to stuff various bits of information we can't find a ho= me for elsewhere. - If you modify a specific link state, then you must advertise two TLVs, or= rather two LSAs, rather than one. Thus these two pieces of information mus= t be connected in a local database, but advertised separately, with all the= coordination/etc. that implies. It seems like it might be better to move this bit of information into the T= LV where the actual link state is advertised in some way. :-) Russ _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From nobody Mon Jul 14 12:47:55 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484521A00B8 for ; Mon, 14 Jul 2014 12:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk64K1s1MVjN for ; Mon, 14 Jul 2014 12:47:51 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id 363FA1A00A3 for ; Mon, 14 Jul 2014 12:47:51 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:34054] helo=[10.0.1.6]) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 60/55-14952-5E334C35; Mon, 14 Jul 2014 19:47:50 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Acee Lindem In-Reply-To: Date: Mon, 14 Jul 2014 15:47:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E91754D-31E0-47D5-B516-0D89E33B502E@lindem.com> References: <02df01cf9917$9b05a650$d110f2f0$@riw.us> To: Chris Bowers X-Mailer: Apple Mail (2.1878.6) X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Qq5fu2C9Cia3-i0Sjbn__n-Od9E Cc: OSPF List , Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2014 19:47:53 -0000 Hi Chris, Shraddha, =20 On Jul 14, 2014, at 3:36 PM, Chris Bowers wrote: > (The response to this question ended up off of the list, so I'm = posting it to continue the discussion on the list.)=20 >=20 > Russ, >=20 > I see your point in link information being carried in Node related = LSA. >=20 > The link information is carried in Router LSA and it's not extendible = to carry any other information. > Since RI-LSA is modeled as an extension to Router LSA, my idea was to = tag the additional link information With new TLV in RI-LSA. >=20 > Another approach could have been to define a new LSA type and = originate a new LSA for each link which is in-eligible to participate in = MRT. A separate LSA for each link to advertise ineligibility looks = suboptimal considering the amount of state machine/data structure that = needs to be maintained for a separate LSA. >=20 >>> It seems like it might be better to move this bit of information = into the TLV where the actual link state is advertised in some way. >=20 > Link related information is advertised in OSPF-TE opaque LSAs as well. = MRT could run on non-TE enabled networks as well, so it may not be = appropriate to use TE LSAs. >=20 > Let me know if you think we could stuff-in in existing LSAs or we = should go with new LSA altogether. Do NOT use the OSPF RI LSA for link information. Rather than define a = new LSA, use the OSPFv2 Extended-Link opaque LSA defined in = https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension= s/ Thanks, Acee >=20 > Rgds, > Shraddha >=20 > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Russ White > Sent: Sunday, July 06, 2014 7:41 AM > To: 'OSPF List' > Cc: Alia Atlas > Subject: [OSPF] draft-atlas-ospf-mrt-02 >=20 >=20 > Just one question/comment on this draft -- In section 6.1, = MRT-Ineligible Links TLV for OSPFv2, the draft says there should be a = new TLV in the router capabilities LSA that advertises links not to be = included in the MRT calculation (excluded links). I'm not certain why an = option isn't used in the LSA header for this, instead. Two things that = seem strange to me: >=20 > - The exclusion of a link is a link property, not a router property, = so I'm not certain why this would be advertised as a property of the = OSPF router. > This seems to muddy the line between router and properties and link = properties in a way that sets the stage for make the router capabilities = just another area into which to stuff various bits of information we = can't find a home for elsewhere. >=20 > - If you modify a specific link state, then you must advertise two = TLVs, or rather two LSAs, rather than one. Thus these two pieces of = information must be connected in a local database, but advertised = separately, with all the coordination/etc. that implies. >=20 > It seems like it might be better to move this bit of information into = the TLV where the actual link state is advertised in some way. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Wed Jul 16 21:57:59 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6861A0645 for ; Wed, 16 Jul 2014 21:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf33858EHohn for ; Wed, 16 Jul 2014 21:57:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB6A1A063F for ; Wed, 16 Jul 2014 21:57:56 -0700 (PDT) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB205.namprd05.prod.outlook.com (10.242.41.148) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 17 Jul 2014 04:57:53 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.82]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.82]) with mapi id 15.00.0985.008; Thu, 17 Jul 2014 04:57:53 +0000 From: Shraddha Hegde To: Acee Lindem , Chris Bowers Thread-Topic: [OSPF] draft-atlas-ospf-mrt-02 Thread-Index: Ac+ZFv4nWa+hKUOQQ8u/arcrmksngAGgrqQQAACxQIAAd5kVcA== Date: Thu, 17 Jul 2014 04:57:52 +0000 Message-ID: <360fb35f4f674e549557421894497dc6@BY2PR05MB127.namprd05.prod.outlook.com> References: <02df01cf9917$9b05a650$d110f2f0$@riw.us> <0E91754D-31E0-47D5-B516-0D89E33B502E@lindem.com> In-Reply-To: <0E91754D-31E0-47D5-B516-0D89E33B502E@lindem.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(24454002)(377454003)(164054003)(13464003)(199002)(189002)(2656002)(86362001)(19580395003)(74662001)(20776003)(31966008)(74502001)(76576001)(99286002)(76482001)(74316001)(81542001)(46102001)(33646002)(106356001)(83072002)(4396001)(66066001)(77096002)(83322001)(15975445006)(87936001)(54356999)(85306003)(80022001)(19580405001)(21056001)(101416001)(79102001)(107046002)(1941001)(77982001)(76176999)(81342001)(95666004)(50986999)(64706001)(85852003)(105586002)(92566001)(99396002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB205; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OcODN4ga1BuUGnrOsGhECqAOGZ0 Cc: OSPF List , Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2014 04:57:58 -0000 Hi Acee, Defining a new MRT sub TLV to be carried in the OSPFv2 Extended link TLV = as defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions= / "Router-Link TLVs"as defined in=20 https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend looks to be a good option. We will work on the draft to update. Rgds Shraddha -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Tuesday, July 15, 2014 1:18 AM To: Chris Bowers Cc: OSPF List; Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 Hi Chris, Shraddha, =20 On Jul 14, 2014, at 3:36 PM, Chris Bowers wrote: > (The response to this question ended up off of the list, so I'm posting i= t to continue the discussion on the list.)=20 >=20 > Russ, >=20 > I see your point in link information being carried in Node related LSA. >=20 > The link information is carried in Router LSA and it's not extendible to = carry any other information. > Since RI-LSA is modeled as an extension to Router LSA, my idea was to tag= the additional link information With new TLV in RI-LSA. >=20 > Another approach could have been to define a new LSA type and originate a= new LSA for each link which is in-eligible to participate in MRT. A separa= te LSA for each link to advertise ineligibility looks suboptimal considerin= g the amount of state machine/data structure that needs to be maintained fo= r a separate LSA. >=20 >>> It seems like it might be better to move this bit of information into t= he TLV where the actual link state is advertised in some way. >=20 > Link related information is advertised in OSPF-TE opaque LSAs as well. MR= T could run on non-TE enabled networks as well, so it may not be appropriat= e to use TE LSAs. >=20 > Let me know if you think we could stuff-in in existing LSAs or we should = go with new LSA altogether. Do NOT use the OSPF RI LSA for link information. Rather than define a new L= SA, use the OSPFv2 Extended-Link opaque LSA defined in https://datatracker.= ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ Thanks, Acee >=20 > Rgds, > Shraddha >=20 > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Russ White > Sent: Sunday, July 06, 2014 7:41 AM > To: 'OSPF List' > Cc: Alia Atlas > Subject: [OSPF] draft-atlas-ospf-mrt-02 >=20 >=20 > Just one question/comment on this draft -- In section 6.1, MRT-Ineligible= Links TLV for OSPFv2, the draft says there should be a new TLV in the rout= er capabilities LSA that advertises links not to be included in the MRT cal= culation (excluded links). I'm not certain why an option isn't used in the = LSA header for this, instead. Two things that seem strange to me: >=20 > - The exclusion of a link is a link property, not a router property, so I= 'm not certain why this would be advertised as a property of the OSPF route= r. > This seems to muddy the line between router and properties and link prope= rties in a way that sets the stage for make the router capabilities just an= other area into which to stuff various bits of information we can't find a = home for elsewhere. >=20 > - If you modify a specific link state, then you must advertise two TLVs, = or rather two LSAs, rather than one. Thus these two pieces of information m= ust be connected in a local database, but advertised separately, with all t= he coordination/etc. that implies. >=20 > It seems like it might be better to move this bit of information into the= TLV where the actual link state is advertised in some way. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > 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 acee@cisco.com Thu Jul 17 17:09:17 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26901A010C for ; Thu, 17 Jul 2014 17:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 845_GHqAJ_0M for ; Thu, 17 Jul 2014 17:09:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C203D1A00DF for ; Thu, 17 Jul 2014 17:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=983; q=dns/txt; s=iport; t=1405642156; x=1406851756; h=from:to:subject:date:message-id:mime-version; bh=GObBWH0vmfDjbk/tIWGDHBCnotURugsASdMrMpB1BA4=; b=Z1t5h8GTEisb2EELdj5r0wILX4LOTaKhd3YzR7BKpzu2smugXPrsSlj3 1ZcuXRDX0uGZxX7Jl1wgklMW429vBkid+KeI8oUWdH3wwYsum9NAtV1BT iEvE6LxZrO1vZejnPO2wBnJsCCjiOoy61UVNHQToKDRi5hW9masxAzP3s w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAHlkyFOtJA2M/2dsb2JhbABZgkdHgSkEjR6/OhZ2hAqBCwELAQI5ORQTBBOIQp5wpmIXlBgFmx+ULINEbIFF X-IronPort-AV: E=Sophos;i="5.01,681,1400025600"; d="scan'208,217";a="340858892" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jul 2014 00:09:15 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6I09FQU024928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Jul 2014 00:09:15 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 19:09:15 -0500 From: "Acee Lindem (acee)" To: "ospf@ietf.org" Thread-Topic: OSPF WG Chair E-mail Thread-Index: AQHPohyCx99/Q/JUQUuTiVr4qtxJ3A== Date: Fri, 18 Jul 2014 00:09:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.103] Content-Type: multipart/alternative; boundary="_000_CFEDDDE775aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/YtkT0C14xvLzuKsLZImYaKASFJ0 Subject: [OSPF] OSPF WG Chair E-mail X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jul 2014 00:18:01 -0000 --_000_CFEDDDE775aceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that I=92ve changed employers and my E-mail address Is now acee@cisco= .com. Thanks, Acee --_000_CFEDDDE775aceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Note that I=92ve changed employers and my  E-mail address Is now = acee@cisco.com. 
Thanks,
Acee 
--_000_CFEDDDE775aceeciscocom_-- From nobody Fri Jul 18 09:01:41 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EA91B2993 for ; Fri, 18 Jul 2014 09:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZEVcJa7bgec for ; Fri, 18 Jul 2014 09:01:30 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A431B27B0 for ; Fri, 18 Jul 2014 09:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1310; q=dns/txt; s=iport; t=1405699290; x=1406908890; h=from:to:subject:date:message-id:mime-version; bh=EOjVrqh+0q9rcU9WIhh7oybvge1uOEe8hRQXC3V3jlI=; b=TzFWKrpRKm588cFIXSm17k9YIkovIPWySCWZKoEQScdKfkNVm09i6IX8 4rPb4MIC60yEKJS0TJzvy448u6jzo6AXDwKGjqOdRvdGArgzufM9RKrZ9 mkoRlAPUhiU9dp/sU9whw7mEpS62xJ6EtWYLx90Y0/oCSvLv0fBa1s/O7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJtDyVOtJA2N/2dsb2JhbABZgkdHgS3NPBZ2g3oQbh0BCwEhUycEE4hCnRameheUGAWbJZQvg0RsgUU X-IronPort-AV: E=Sophos; i="5.01,685,1400025600"; d="scan'208,217"; a="61987313" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 18 Jul 2014 16:01:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6IG1T7j008638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Jul 2014 16:01:29 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 11:01:29 -0500 From: "Acee Lindem (acee)" To: "ospf@ietf.org" Thread-Topic: ospf-wireless-design@ietf.org Thread-Index: AQHPoqGJoIydOssaTUOSwazWuh3rZQ== Date: Fri, 18 Jul 2014 16:01:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.103] Content-Type: multipart/alternative; boundary="_000_CFEEBD19116aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/mSpGWRHn1TK9lZZseRII3o6C51U Subject: [OSPF] ospf-wireless-design@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jul 2014 16:01:35 -0000 --_000_CFEEBD19116aceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable When my Cisco E-mail ID was reactivated I noticed a large number of subscri= ption requests for the subject IETF mailing list. Note that this list was u= sed during the 2004-2006 OSPF MANET work and is no longer active. I=92ve di= scarded all these requests. Thanks, Acee --_000_CFEEBD19116aceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
When my Cisco E-mail ID was reactivated I noticed a large number of su= bscription requests for the subject IETF mailing list. Note that this list = was used during the 2004-2006 OSPF MANET work and is no longer active. I=92= ve discarded all these requests. 

Thanks,
Acee

--_000_CFEEBD19116aceeciscocom_-- From nobody Mon Jul 21 08:28:47 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29E1A0252 for ; Mon, 21 Jul 2014 08:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zMkqf3BCBOq for ; Mon, 21 Jul 2014 08:28:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF7B1A01C6 for ; Mon, 21 Jul 2014 08:28:42 -0700 (PDT) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB197.namprd05.prod.outlook.com (10.255.191.21) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 15:28:39 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 15:28:39 +0000 From: Chris Bowers To: Russ White , Acee Lindem , OSPF List Thread-Topic: [OSPF] draft-atlas-ospf-mrt-02 Thread-Index: Ac+ZFv4nWa+hKUOQQ8u/arcrmksngAGgrqQQAACxQIAAd5kVcADfQAdw Date: Mon, 21 Jul 2014 15:28:39 +0000 Message-ID: <973fa216fa30459c842bf30ad589ee30@BLUPR05MB292.namprd05.prod.outlook.com> References: <02df01cf9917$9b05a650$d110f2f0$@riw.us> <0E91754D-31E0-47D5-B516-0D89E33B502E@lindem.com> <360fb35f4f674e549557421894497dc6@BY2PR05MB127.namprd05.prod.outlook.com> In-Reply-To: <360fb35f4f674e549557421894497dc6@BY2PR05MB127.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(13464003)(189002)(199002)(24454002)(51704005)(377454003)(107046002)(85306003)(20776003)(33646002)(15975445006)(74502001)(74662001)(105586002)(106356001)(15202345003)(99286002)(95666004)(19580395003)(83322001)(19580405001)(4396001)(93886003)(81542001)(92566001)(50986999)(46102001)(76176999)(54356999)(77982001)(81342001)(87936001)(76482001)(2656002)(83072002)(99396002)(80022001)(31966008)(66066001)(101416001)(79102001)(86362001)(85852003)(74316001)(21056001)(76576001)(64706001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB197; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/aQ7xDb24ClNzKX0Lkuu2liYvWeo Cc: Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2014 15:28:44 -0000 Acee and Russ, =20 We have posted an updated version of the draft following your suggestions w= ith respect to advertising MRT-ineligible links. http://www.ietf.org/internet-drafts/draft-atlas-ospf-mrt-03.txt Thanks, Chris -----Original Message----- From: Shraddha Hegde=20 Sent: Thursday, July 17, 2014 12:58 AM To: Acee Lindem; Chris Bowers Cc: OSPF List; Alia Atlas Subject: RE: [OSPF] draft-atlas-ospf-mrt-02 Hi Acee, Defining a new MRT sub TLV to be carried in the OSPFv2 Extended link TLV = as defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-rout= ing-extensions/ "Router-Link TLVs"as defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend looks to be a good option. We will work on the draft to update. Rgds Shraddha -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Tuesday, July 15, 2014 1:18 AM To: Chris Bowers Cc: OSPF List; Alia Atlas Subject: Re: [OSPF] draft-atlas-ospf-mrt-02 Hi Chris, Shraddha, =20 On Jul 14, 2014, at 3:36 PM, Chris Bowers wrote: > (The response to this question ended up off of the list, so I'm=20 > posting it to continue the discussion on the list.) >=20 > Russ, >=20 > I see your point in link information being carried in Node related LSA. >=20 > The link information is carried in Router LSA and it's not extendible to = carry any other information. > Since RI-LSA is modeled as an extension to Router LSA, my idea was to tag= the additional link information With new TLV in RI-LSA. >=20 > Another approach could have been to define a new LSA type and originate a= new LSA for each link which is in-eligible to participate in MRT. A separa= te LSA for each link to advertise ineligibility looks suboptimal considerin= g the amount of state machine/data structure that needs to be maintained fo= r a separate LSA. >=20 >>> It seems like it might be better to move this bit of information into t= he TLV where the actual link state is advertised in some way. >=20 > Link related information is advertised in OSPF-TE opaque LSAs as well. MR= T could run on non-TE enabled networks as well, so it may not be appropriat= e to use TE LSAs. >=20 > Let me know if you think we could stuff-in in existing LSAs or we should = go with new LSA altogether. Do NOT use the OSPF RI LSA for link information. Rather than define a new L= SA, use the OSPFv2 Extended-Link opaque LSA defined in https://datatracker.= ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ Thanks, Acee >=20 > Rgds, > Shraddha >=20 > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Russ White > Sent: Sunday, July 06, 2014 7:41 AM > To: 'OSPF List' > Cc: Alia Atlas > Subject: [OSPF] draft-atlas-ospf-mrt-02 >=20 >=20 > Just one question/comment on this draft -- In section 6.1, MRT-Ineligible= Links TLV for OSPFv2, the draft says there should be a new TLV in the rout= er capabilities LSA that advertises links not to be included in the MRT cal= culation (excluded links). I'm not certain why an option isn't used in the = LSA header for this, instead. Two things that seem strange to me: >=20 > - The exclusion of a link is a link property, not a router property, so I= 'm not certain why this would be advertised as a property of the OSPF route= r. > This seems to muddy the line between router and properties and link prope= rties in a way that sets the stage for make the router capabilities just an= other area into which to stuff various bits of information we can't find a = home for elsewhere. >=20 > - If you modify a specific link state, then you must advertise two TLVs, = or rather two LSAs, rather than one. Thus these two pieces of information m= ust be connected in a local database, but advertised separately, with all t= he coordination/etc. that implies. >=20 > It seems like it might be better to move this bit of information into the= TLV where the actual link state is advertised in some way. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > 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 nobody Mon Jul 21 12:25:10 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8C1A01EB for ; Mon, 21 Jul 2014 12:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtCEeMnSrI9r for ; Mon, 21 Jul 2014 12:25:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FAC61A036F for ; Mon, 21 Jul 2014 12:25:02 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB662.namprd05.prod.outlook.com (10.141.221.14) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 19:24:59 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.129]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.129]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 19:24:59 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "ospf@ietf.org" Thread-Topic: Follow-up discussion on draft-zzhang-ospf-two-part-metric Thread-Index: Ac+lGUvqIiqLTqfBSei7UevvhvhHhQ== Date: Mon, 21 Jul 2014 19:24:58 +0000 Message-ID: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(41574002)(189002)(199002)(110136001)(81342001)(81542001)(95666004)(107046002)(229853001)(76482001)(21056001)(76576001)(31966008)(66066001)(77982001)(64706001)(74502001)(80022001)(79102001)(105586002)(74662001)(20776003)(77096002)(106356001)(86362001)(54356999)(46102001)(50986999)(99396002)(2656002)(33646002)(87936001)(4396001)(83072002)(85852003)(92566001)(2351001)(83322001)(101416001)(85306003)(74316001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB662; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ksthVACloJHTbSIPxhW5q5oTjUI Cc: "vibhor.julka@l-3Com.com" , "Dave.Dubois@gdc4s.com" , "tom.mcmillan@l-3com.com" Subject: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2014 19:25:08 -0000 Hi, In today's OSPF session there were mainly two questions/comments during my = presentation: 1. Acee: more discussion on mailing list about whether this is a general pr= oblem/solution that the WG should be taking on 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding I want to repeat and add some comments/answers here as a starting point for= more discussions on the mailing list. For #1: - The described problem is real for some large scale and mission critical n= etworks - The problem and solution are not only applicable to the above mentioned e= xample network, but also general to any broadcast network that have differe= nt costs between different pair of routers. As long as the router-to-router= costs can be presented as a to-network and a from-network part, then the s= imple solution applies - The two-part-metric concept is a natural extension of the SPF graph theor= y - we're just changing the previously zero from-network cost to none-zero. For #2, there are pros and cons with each approach. - The stub-link based approach does not depend on the in-progress LSA Exten= sibility work. This has larger impact on implementation - the feature can b= e supported w/o big changes to support extended LSA format. - The LSA Extensibility work is only applicable for OSPFv3. That means OSPF= v2 would need a different approach for the problem. Acee also mentioned tha= t it would be good to have consistent approaches between OSPFv2 and OSPFv3. - As a result at this time we would prefer the stub-link approach. The authors would like to hear more of your opinions/suggestions. Hopefully= we can reach consensus on the applicability of the problem & solution so t= hat it can become a WG item, and choose the best encoding approach. Thanks! Jeffrey From nobody Mon Jul 21 13:59:52 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA81A0552 for ; Mon, 21 Jul 2014 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3p4MhMcZmxK for ; Mon, 21 Jul 2014 13:59:48 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127421A0385 for ; Mon, 21 Jul 2014 13:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2550; q=dns/txt; s=iport; t=1405976388; x=1407185988; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4aBed/wgSbFO3utJbN1Andt2odu03syWpCNz3C53ZjE=; b=Uj59xdnv4kkk0cW6fJtGyHyMbLIc6ntEqYyVCF82XRSTqWH9aEKYmebA hhkVCfyh0tOqHFII5zuwhKaAhWFKu64mbO+bwVmfeQasZ4B3vccps3KcN pmGN/pqQYeMOYWJhvJyaU/Si/Qx21loo9EFUf1lOF5ov65oB4DyVLcpWx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAD1+zVOtJssW/2dsb2JhbABZg2BXxnQKh0UBgTV2hAMBAQEDAQEBATU2CxALGAklDwIWMAYBDAEFAgEBF4gfCA2/EhMEj0sHhEYBBJslhxWNGoNgIS8 X-IronPort-AV: E=Sophos;i="5.01,704,1400025600"; d="scan'208";a="119419627" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Jul 2014 20:59:46 +0000 Received: from [10.61.101.73] (dhcp-10-61-101-73.cisco.com [10.61.101.73]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6LKxhKJ026847; Mon, 21 Jul 2014 20:59:44 GMT Message-ID: <53CD7F3F.308@cisco.com> Date: Mon, 21 Jul 2014 16:59:43 -0400 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" , "ospf@ietf.org" References: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> In-Reply-To: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/F83oB39F2VGJ3YpfFLWeb_VCYzY Cc: "vibhor.julka@l-3Com.com" , "Dave.Dubois@gdc4s.com" , "tom.mcmillan@l-3com.com" Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2014 20:59:50 -0000 Hi Jeffrey, please see inline: On 7/21/14 15:24 , Jeffrey (Zhaohui) Zhang wrote: > Hi, > > In today's OSPF session there were mainly two questions/comments during my presentation: > > 1. Acee: more discussion on mailing list about whether this is a general problem/solution that the WG should be taking on > 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding my comment was not specific to OSPFv3. I propose to use following extensions to encode metric from DR to attached router: 1. OSPFv2: Extended Link LSA 2. OSPFv3: E-Router LSAs > > I want to repeat and add some comments/answers here as a starting point for more discussions on the mailing list. > > For #1: > > - The described problem is real for some large scale and mission critical networks > - The problem and solution are not only applicable to the above mentioned example network, but also general to any broadcast network that have different costs between different pair of routers. As long as the router-to-router costs can be presented as a to-network and a from-network part, then the simple solution applies > - The two-part-metric concept is a natural extension of the SPF graph theory - we're just changing the previously zero from-network cost to none-zero. > > For #2, there are pros and cons with each approach. > > - The stub-link based approach does not depend on the in-progress LSA Extensibility work. This has larger impact on implementation - the feature can be supported w/o big changes to support extended LSA format. though the stub-link approach is simpler to implement, it's a bit of a "hack", as you are using a standard encoding for a stub link to advertise a metric for a neighbor on a broadcast link. > - The LSA Extensibility work is only applicable for OSPFv3. That means OSPFv2 would need a different approach for the problem. Acee also mentioned that it would be good to have consistent approaches between OSPFv2 and OSPFv3. what I proposed is consistent - uses new extended LSAs in both OSPFv2 and OSPFv3. thanks, Peter > - As a result at this time we would prefer the stub-link approach. > > The authors would like to hear more of your opinions/suggestions. Hopefully we can reach consensus on the applicability of the problem & solution so that it can become a WG item, and choose the best encoding approach. > > Thanks! > Jeffrey > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Jul 22 08:14:20 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F571B2958 for ; Tue, 22 Jul 2014 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYjCXYawVmQ5 for ; Tue, 22 Jul 2014 08:14:13 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE3A1B2960 for ; Tue, 22 Jul 2014 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1309; q=dns/txt; s=iport; t=1406042045; x=1407251645; h=from:to:subject:date:message-id:mime-version; bh=1MhyZJyFw7GBqTKdAi+ii75tcvIB5TBLL9VuL4EQw2w=; b=Ic4HTda1wKTkeLt7cxL1E2C94uzsp/PYsLdZqUs0STyJr4InHI0MLHIA RPkjjdKDv+WM8dQJPnkD4LM0iFw+qciLhN6iDScTnEnqv2a9ANoBD2fdN HHEf+dGc7U6BMNYW4MPy/gQEmpfJPbUGcXGZ8LDdQ9dpNl+UjTGaa+Fut s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAE5/zlOtJV2S/2dsb2JhbABYgkdHgS3PZxZ2g3oQgQsBCwF0JwQBiFS/cReUGAWbJpQvg0SCMQ X-IronPort-AV: E=Sophos; i="5.01,710,1400025600"; d="scan'208,217"; a="63032990" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2014 15:13:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6MFDkhQ023084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jul 2014 15:13:46 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 10:13:46 -0500 From: "Acee Lindem (acee)" To: "ospf@ietf.org" , "Peter Psenak (ppsenak)" Thread-Topic: OSPFv3 Extensions for Segment Routing Thread-Index: AQHPpb+IufeA+UmSJEWl3ZDAaHyRig== Date: Tue, 22 Jul 2014 15:13:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.161] Content-Type: multipart/alternative; boundary="_000_CFF3F7EBAB6aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/j81wl9vNJdMTeOYeeyG6uJlRA_4 Subject: [OSPF] OSPFv3 Extensions for Segment Routing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 15:14:15 -0000 --_000_CFF3F7EBAB6aceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Peter, As we discussed in yesterday=92s WG meeting, the poll indicated support of = making OSPFv3 Segment Routing a WG draft. Please republish draft-psenak-ospf-segment-routing-ospfv3-extension-02 as = draft-ietf-ospf-segment-routing-ospfv3-extension-00. Thanks, Acee --_000_CFF3F7EBAB6aceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Peter,
As we discussed in yesterday=92s WG meeting, the poll indicated suppor= t of making OSPFv3 Segment Routing a WG draft. 
Please republish  draft-psenak-ospf-segment-routing-ospfv3-extens= ion-02 as draft-ietf-ospf-segment-routing-ospfv3-extension-00. 
Thanks,
Acee 
--_000_CFF3F7EBAB6aceeciscocom_-- From nobody Tue Jul 22 09:00:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A91B27B0 for ; Tue, 22 Jul 2014 09:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0LxIgkytpp4 for ; Tue, 22 Jul 2014 09:00:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54491A00A8 for ; Tue, 22 Jul 2014 09:00:27 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 16:00:24 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.129]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.129]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 16:00:24 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Peter Psenak , "ospf@ietf.org" Thread-Topic: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric Thread-Index: Ac+lGUvqIiqLTqfBSei7UevvhvhHhQADWYKAACE38CA= Date: Tue, 22 Jul 2014 16:00:23 +0000 Message-ID: <75f0e1a87ea4418697308c5b4c28f94e@BY2PR05MB079.namprd05.prod.outlook.com> References: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> <53CD7F3F.308@cisco.com> In-Reply-To: <53CD7F3F.308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(51704005)(52604005)(199002)(24454002)(41574002)(189002)(377454003)(479174003)(52314003)(79102001)(74662001)(76576001)(74502001)(4396001)(101416001)(74316001)(76176999)(99396002)(19580395003)(77982001)(19580405001)(50986999)(54356999)(83322001)(15975445006)(105586002)(107046002)(85306003)(99286002)(83072002)(92566001)(77096002)(66066001)(64706001)(20776003)(80022001)(46102001)(33646002)(86362001)(81542001)(87936001)(2656002)(21056001)(106356001)(31966008)(81342001)(76482001)(95666004)(85852003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB078; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2L-Zhpczp1zpqnG7ZZSZ_RA_-v4 Cc: "vibhor.julka@l-3Com.com" , "Dave.Dubois@gdc4s.com" , "tom.mcmillan@l-3com.com" Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 16:00:41 -0000 Hi Peter, Thanks for clarifying. Yes Extended Link LSA for OSPFv2 could be used. If we go the path of using = E-Router LSA for OSPFv3, then yet another option is to go back to the MT-ba= sed encoding. That approach for OSPFv2 was documented in -00 but would not = work for OSPFv3 until OSPFv3 MT is specified. With the progress of OSPFv3 L= SA Extendibility work, do you have plans to resume the OSPFv3 MT work soon?= If yes, using MT-based encoding would be even more consistent between OSPF= v2 and OSPFv3. Anyway, the encoding mechanism can be further discussed, especially if this= becomes a WG item. Thanks. Jeffrey > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Monday, July 21, 2014 5:00 PM > To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org > Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; tom.mcmillan@l- > 3com.com > Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part- > metric >=20 > Hi Jeffrey, >=20 > please see inline: >=20 >=20 > On 7/21/14 15:24 , Jeffrey (Zhaohui) Zhang wrote: > > Hi, > > > > In today's OSPF session there were mainly two questions/comments > during my presentation: > > > > 1. Acee: more discussion on mailing list about whether this is a > general problem/solution that the WG should be taking on > > 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding >=20 > my comment was not specific to OSPFv3. > I propose to use following extensions to encode metric from DR to > attached router: >=20 > 1. OSPFv2: Extended Link LSA > 2. OSPFv3: E-Router LSAs >=20 > > > > I want to repeat and add some comments/answers here as a starting > point for more discussions on the mailing list. > > > > For #1: > > > > - The described problem is real for some large scale and mission > critical networks > > - The problem and solution are not only applicable to the above > mentioned example network, but also general to any broadcast network > that have different costs between different pair of routers. As long as > the router-to-router costs can be presented as a to-network and a from- > network part, then the simple solution applies > > - The two-part-metric concept is a natural extension of the SPF graph > theory - we're just changing the previously zero from-network cost to > none-zero. > > > > For #2, there are pros and cons with each approach. > > > > - The stub-link based approach does not depend on the in-progress LSA > Extensibility work. This has larger impact on implementation - the > feature can be supported w/o big changes to support extended LSA format. >=20 > though the stub-link approach is simpler to implement, it's a bit of a > "hack", as you are using a standard encoding for a stub link to > advertise a metric for a neighbor on a broadcast link. >=20 > > - The LSA Extensibility work is only applicable for OSPFv3. That means > OSPFv2 would need a different approach for the problem. Acee also > mentioned that it would be good to have consistent approaches between > OSPFv2 and OSPFv3. >=20 > what I proposed is consistent - uses new extended LSAs in both OSPFv2 > and OSPFv3. >=20 > thanks, > Peter >=20 > > - As a result at this time we would prefer the stub-link approach. > > > > The authors would like to hear more of your opinions/suggestions. > Hopefully we can reach consensus on the applicability of the problem & > solution so that it can become a WG item, and choose the best encoding > approach. > > > > Thanks! > > Jeffrey > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > From nobody Tue Jul 22 09:03:43 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866B1A0302 for ; Tue, 22 Jul 2014 09:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ojb9vNlcz_K for ; Tue, 22 Jul 2014 09:03:37 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60781B27AD for ; Tue, 22 Jul 2014 09:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3914; q=dns/txt; s=iport; t=1406045014; x=1407254614; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8dEQrYOcGeiW6ZibhqgvMG3Py6R6hFLO9nD9yNf5fJo=; b=MB0A+bcz43ghSFb3wDo2TlF9KwhoyDfKn761UNWMQDqnjDckXyn0/X8O 0XzLZYXv60Bg1SaJM1IhYABnHdY4s5kO8lYqtrS7HLiFODOcqjzjPj7uf 14QFa1fx6BOefucQJI/YIuitDgo/Gj0ZzzlF2THuW1bZnqhnl0k6Ytq6x w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMEAFKKzlOtJssW/2dsb2JhbABYg2BXxw0Kh0UBgSd2hAMBAQEDAQEBATU2CgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBgEMAQUCAQEXiB8IDb9xF49LBwaEQAEEmyaBTYVIjRqDYCEv X-IronPort-AV: E=Sophos;i="5.01,710,1400025600"; d="scan'208";a="115261531" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 22 Jul 2014 16:03:32 +0000 Received: from [10.61.109.221] (dhcp-10-61-109-221.cisco.com [10.61.109.221]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6MG3Ujn012592; Tue, 22 Jul 2014 16:03:31 GMT Message-ID: <53CE8B52.7070007@cisco.com> Date: Tue, 22 Jul 2014 12:03:30 -0400 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" , "ospf@ietf.org" References: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> <53CD7F3F.308@cisco.com> <75f0e1a87ea4418697308c5b4c28f94e@BY2PR05MB079.namprd05.prod.outlook.com> In-Reply-To: <75f0e1a87ea4418697308c5b4c28f94e@BY2PR05MB079.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OW7kKDi63vgpDhLxOYMV3XxJapE Cc: "vibhor.julka@l-3Com.com" , "Dave.Dubois@gdc4s.com" , "tom.mcmillan@l-3com.com" Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2014 16:03:39 -0000 Jeffrey, On 7/22/14 12:00 , Jeffrey (Zhaohui) Zhang wrote: > Hi Peter, > > Thanks for clarifying. > > Yes Extended Link LSA for OSPFv2 could be used. If we go the path of using E-Router LSA for OSPFv3, then yet another option is to go back to the MT-based encoding. That approach for OSPFv2 was documented in -00 but would not work for OSPFv3 until OSPFv3 MT is specified. With the progress of OSPFv3 LSA Extendibility work, do you have plans to resume the OSPFv3 MT work soon? If yes, using MT-based encoding would be even more consistent between OSPFv2 and OSPFv3. I do not believe there are any plans to introduce MT to OSPfv3 at this point. thanks, Peter > > Anyway, the encoding mechanism can be further discussed, especially if this becomes a WG item. > > Thanks. > > Jeffrey > >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Monday, July 21, 2014 5:00 PM >> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org >> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; tom.mcmillan@l- >> 3com.com >> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part- >> metric >> >> Hi Jeffrey, >> >> please see inline: >> >> >> On 7/21/14 15:24 , Jeffrey (Zhaohui) Zhang wrote: >>> Hi, >>> >>> In today's OSPF session there were mainly two questions/comments >> during my presentation: >>> >>> 1. Acee: more discussion on mailing list about whether this is a >> general problem/solution that the WG should be taking on >>> 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding >> >> my comment was not specific to OSPFv3. >> I propose to use following extensions to encode metric from DR to >> attached router: >> >> 1. OSPFv2: Extended Link LSA >> 2. OSPFv3: E-Router LSAs >> >>> >>> I want to repeat and add some comments/answers here as a starting >> point for more discussions on the mailing list. >>> >>> For #1: >>> >>> - The described problem is real for some large scale and mission >> critical networks >>> - The problem and solution are not only applicable to the above >> mentioned example network, but also general to any broadcast network >> that have different costs between different pair of routers. As long as >> the router-to-router costs can be presented as a to-network and a from- >> network part, then the simple solution applies >>> - The two-part-metric concept is a natural extension of the SPF graph >> theory - we're just changing the previously zero from-network cost to >> none-zero. >>> >>> For #2, there are pros and cons with each approach. >>> >>> - The stub-link based approach does not depend on the in-progress LSA >> Extensibility work. This has larger impact on implementation - the >> feature can be supported w/o big changes to support extended LSA format. >> >> though the stub-link approach is simpler to implement, it's a bit of a >> "hack", as you are using a standard encoding for a stub link to >> advertise a metric for a neighbor on a broadcast link. >> >>> - The LSA Extensibility work is only applicable for OSPFv3. That means >> OSPFv2 would need a different approach for the problem. Acee also >> mentioned that it would be good to have consistent approaches between >> OSPFv2 and OSPFv3. >> >> what I proposed is consistent - uses new extended LSAs in both OSPFv2 >> and OSPFv3. >> >> thanks, >> Peter >> >>> - As a result at this time we would prefer the stub-link approach. >>> >>> The authors would like to hear more of your opinions/suggestions. >> Hopefully we can reach consensus on the applicability of the problem & >> solution so that it can become a WG item, and choose the best encoding >> approach. >>> >>> Thanks! >>> Jeffrey >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> > > . > From nobody Tue Jul 22 17:53:37 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C41A02E1 for ; Tue, 22 Jul 2014 17:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ50TTPcMFO1 for ; Tue, 22 Jul 2014 17:53:34 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6973F1A0109 for ; Tue, 22 Jul 2014 17:53:32 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-dc-53ceb228296e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E7.BF.25146.922BEC35; Tue, 22 Jul 2014 20:49:13 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 20:53:25 -0400 From: Ing-Wher Chen To: "ospf@ietf.org" Thread-Topic: WG adoption---draft-chen-ospf-transition-to-ospfv3? Thread-Index: Ac+mD1WqrJdjlPOzRKKgH+V1PVvBIw== Date: Wed, 23 Jul 2014 00:53:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyuXRPgq7mpnPBBlcfCFi03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ7dF9gKfrBWtH9bwdbA+IGli5GTQ0LAROLwgp1sELaYxIV7 64FsLg4hgaOMEhdWfGeHcJYzSszddRCsik3AQGLDxy1MILaIgLLElr39YHFhARuJzZsOsUPE HSXen1sFZetJnPv/gxnEZhFQldj9cBNQLwcHr4C3RMN8OZAwI9Di76fWgI1kFhCXuPVkPhPE QQISS/acZ4awRSVePv7HCmErSUxaeo4Vol5HYsHuT2wQtrbEsoWvwep5BQQlTs58wjKBUXgW krGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRoabGIGBfEyCzXEH44JPlocYBTgYlXh4FczOBQux JpYVV+YeYpTmYFES59WsnhcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXH6D9HkI+0MxyMN XBryj/lXC8Q8FedWm3PYm6vIdUrrB+lsgQfha3+Uz2dQm8n/3i8hx//ESfsHGYfkHq0TvjGN 9VI3X36MwiLLTW5umiw/5vzjSv9fvOnIjG3FefO3vfd0YWebczW5nffvFWH2x037TQSa7x+f PU3s9qyZep5/PndmKhVPaFZiKc5INNRiLipOBAC97+ksRQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/LybTyHPTYdeAey_OaQ0u4Ig6ALs Subject: [OSPF] WG adoption---draft-chen-ospf-transition-to-ospfv3? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 23 Jul 2014 00:53:35 -0000 Hello, I'd like to ask if the working group would adopt and help improve and refin= e the following draft: This document describes a mechanism to transport OSPfv3 over IPv4. The mechanism allows devices to migrate to OSPFv3 first, which would help with transition to IPv6 later. The latest -01 version addresses an earlier question by including an IPv4-only use case in which deployed devices cannot communicate in IPv6 but would benefit from using the mechanism proposed in this draft to transition to OSPFv3 for now. Until all devices can communicate using I= Pv6, consolidating to OSPFv3 can still reduce operational complexity and cost. Thanks, Helen =20 From nobody Thu Jul 24 07:39:32 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897EA1A030C for ; Thu, 24 Jul 2014 07:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FEw56FSWBwx for ; Thu, 24 Jul 2014 07:39:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6959F1A000E for ; Thu, 24 Jul 2014 07:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1334; q=dns/txt; s=iport; t=1406212768; x=1407422368; h=from:to:subject:date:message-id:mime-version; bh=Y0kvJaJ8SRzVB9oELBqieC2RpN9aoxnuJayFMLQ2SR8=; b=HKq/Pt7O/wbopd8ZZ30mCiPbOrEu+LLmTUoRBASh9RCWhu92Yr9jK6Se h9MQqjbwGnZOqepfT3Bq1hNhK/Yzk/J/MlP7T46PocTYDFln0nyyJYSw9 IUtq3UdYXnW+WfeQrbv9O5CcHafokB4gHom5f6KQWijPimPXlNLryCuIw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUHAFca0VOtJA2M/2dsb2JhbABZgkdHUlgDyTOIUxZ3g3oQgQsBCwF0JwQciDkNmVqnDReUGAWbM5RCg0iCMQ X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208,217";a="339441449" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jul 2014 14:39:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEd43N032144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 14:39:04 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:39:04 -0500 From: "Acee Lindem (acee)" To: "ospf@ietf.org" Thread-Topic: IETF 90 OSPF WG Meeting MInutes Thread-Index: AQHPp00Dp7M/fymNJkmt8fPz2KKYyw== Date: Thu, 24 Jul 2014 14:39:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.151.216] Content-Type: multipart/alternative; boundary="_000_CFF692C7E72aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/a4E2az_qHXedxiASQh12rtBleh4 Subject: [OSPF] IETF 90 OSPF WG Meeting MInutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2014 14:39:30 -0000 --_000_CFF692C7E72aceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have uploaded the OSPF WG meeting minutes from Monday=92s meeting. Please= unicast any additions or correction to me. Many thanks to Les Ginsberg for= taking them. Here is a URL for your convenience: http://www.ietf.org/proceedings/90/minu= tes/minutes-90-ospf Thanks, Acee --_000_CFF692C7E72aceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I have uploaded the OSPF WG meeting minutes from Monday=92s meeting. P= lease unicast any additions or correction to me. Many thanks to Les Ginsber= g for taking them.  

Here is a URL for your convenience: http://www.ietf.org/proceedin= gs/90/minutes/minutes-90-ospf

Thanks,
Acee 
--_000_CFF692C7E72aceeciscocom_-- From nobody Wed Jul 30 16:39:09 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688891A05C0 for ; Wed, 30 Jul 2014 16:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdQZ3NMrJV1p for ; Wed, 30 Jul 2014 16:39:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9675C1A0451 for ; Wed, 30 Jul 2014 16:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1295; q=dns/txt; s=iport; t=1406763548; x=1407973148; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wLaczMbA52hJA7ry8R5X45uoEWGTA6Kr9OU+JY6dIVo=; b=OBH4AzrYBlsbUjsStiax8bRZvH7rcUn4joEh9bYfSf2e4Zt6BLAwPr8D EKW393ZGZCVq67gWRG0743fGRZkZjbirpzrwZvYsrBH1mDKX1/mE5m2Dj Y8lXRZu7GpDLv9tr/CS5kpHd9aXoTIJWnT7sGqeUaMwK3R+Y6GIqlh9kR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAG2B2VOtJV2R/2dsb2JhbABZgw5SVwTKZR8KiFgWd4QEAQEBAwEBAWsdAQhtCycEARKIQg3APxMElB0FikWRH5RTg0lsgUU X-IronPort-AV: E=Sophos;i="5.01,768,1400025600"; d="scan'208";a="344023468" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2014 23:39:07 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6UNd5dI022016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 23:39:05 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 18:39:05 -0500 From: "Acee Lindem (acee)" To: Ing-Wher Chen , "ospf@ietf.org" Thread-Topic: [OSPF] WG adoption---draft-chen-ospf-transition-to-ospfv3? Thread-Index: AQHPrE9z6AFuPERZukKyfPqG23hyBQ== Date: Wed, 30 Jul 2014 23:39:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2enctG5vTiLpsgNl43s6MzkagdY Subject: Re: [OSPF] WG adoption---draft-chen-ospf-transition-to-ospfv3? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 30 Jul 2014 23:39:08 -0000 Hi Helen, As an author, I would certainly support this work. I think it is clearly in the OSPF WG=B9s best interest to facilitate migration to a single version. When that happens will be dependent on numerous factors including requirements, deployments, and how well we facilitate it. Thanks, Acee On 7/22/14, 8:53 PM, "Ing-Wher Chen" wrote: >Hello, > >I'd like to ask if the working group would adopt and help improve and >refine >the following draft: > > > >This document describes a mechanism to transport OSPfv3 over IPv4. >The mechanism allows devices to migrate to OSPFv3 first, which would help >with transition to IPv6 later. > >The latest -01 version addresses an earlier question by including >an IPv4-only use case in which deployed devices cannot communicate >in IPv6 but would benefit from using the mechanism proposed in this draft >to transition to OSPFv3 for now. Until all devices can communicate using >IPv6, >consolidating to OSPFv3 can still reduce operational complexity and cost. > >Thanks, >Helen >=20 > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From nobody Thu Jul 31 14:54:28 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3BF1A0183 for ; Thu, 31 Jul 2014 14:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO-zykzJTyXL for ; Thu, 31 Jul 2014 14:54:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDD31A0181 for ; Thu, 31 Jul 2014 14:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2607; q=dns/txt; s=iport; t=1406843663; x=1408053263; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pAdohC0hBTJadyhwH8QQZPNlTpwCrwES6eSB71Quv+M=; b=JkrPKFxfbYS1BUq+spAegQ22Uk+zR3jyZ6JDU/bAQyAe2QnZRgQvIWY/ dTaLNSm9iX23W1eFlTrioeNBqYm67os8tV5QtlIzIeMXewLl5/UV3XvJe VAdZb9Ymz3kCCrDjmni9WhE0fsQT+rJ6NEzRL2MfvvzYLqZcYs3W4L9EJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFANy52lOtJA2K/2dsb2JhbABbgw1SVwTNF4dLAYEMFneEBAEBBDo9EgIBCDYQMiUCBBMJiDkNynsXj1OESwWbdIFSkwSDSWwBgUQ X-IronPort-AV: E=Sophos;i="5.01,774,1400025600"; d="scan'208";a="65597853" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 31 Jul 2014 21:54:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6VLsMM7032538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Jul 2014 21:54:22 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 16:54:22 -0500 From: "Acee Lindem (acee)" To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-acee-ospf-rfc4970bis-00.txt Thread-Index: AQHPrNPV9OX1dLnbUUmno3nmSb/zbZu6yxOA Date: Thu, 31 Jul 2014 21:54:21 +0000 Message-ID: References: <20140731152625.15673.25197.idtracker@ietfa.amsl.com> In-Reply-To: <20140731152625.15673.25197.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/h5KKJn_mQnB44LEQ6L9SyD4K_Fg Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc4970bis-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 21:54:25 -0000 Hi,=20 Note that I have authored an RFC 4970 BIS draft which better reflects the requirements. Here is an excerpt describing the changes: This document includes the following changes from RFC 4970 [RFC4970]: 1. The main change is that an OSPF router will be able to advertise multiple instances of the OSPF Router Information LSA. This change permeates through much of the document 2. Additionally, Section 2.5 includes a new TLV for functional capabilities. This is constast to the existing TLV which is used to advertise capabilities for informational purposes only. 3. Finally, references have been updated for drafts that have become RFCs and RFCs that have been obsoleted since the publication of RFC 4970. Thanks, Acee On 7/31/14, 11:26 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-acee-ospf-rfc4970bis-00.txt >has been successfully submitted by Acee Lindem and posted to the >IETF repository. > >Name: draft-acee-ospf-rfc4970bis >Revision: 00 >Title: Extensions to OSPF for Advertising Optional Router Capabilities >Document date: 2014-07-31 >Group: Individual Submission >Pages: 17 >URL: =20 >http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc4970bis-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-acee-ospf-rfc4970bis/ >Htmlized: http://tools.ietf.org/html/draft-acee-ospf-rfc4970bis-00 > > >Abstract: > It is useful for routers in an OSPFv2 or OSPFv3 routing domain to > know the capabilities of their neighbors and other routers in the > routing domain. This document proposes extensions to OSPFv2 and > OSPFv3 for advertising optional router capabilities. A new Router > Information (RI) Link State Advertisement (LSA) is proposed for this > purpose. In OSPFv2, the RI LSA will be implemented with a new opaque > LSA type ID. In OSPFv3, the RI LSA will be implemented with a new > LSA type function code. In both protocols, the RI LSA can be > advertised at any of the defined flooding scopes (link, area, or > autonomous system (AS)). This document obsoletes RFC 4970 by > providing a revised specification including support for advertisement > of multiple instances of the RI LSA and a TLV for functional > capabilities. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat >