From acee.lindem@ericsson.com Mon Nov 4 09:21:32 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4B721E8213 for ; Mon, 4 Nov 2013 09:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CWOONx+90Be for ; Mon, 4 Nov 2013 09:21:23 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7D62511E81B3 for ; Mon, 4 Nov 2013 09:13:30 -0800 (PST) X-AuditID: c6180641-b7f3f8e000000a05-7b-5277d5b688aa Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 64.AE.02565.6B5D7725; Mon, 4 Nov 2013 18:13:26 +0100 (CET) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 4 Nov 2013 12:13:25 -0500 From: Acee Lindem To: OSPF List Thread-Topic: [OSPF] Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt Thread-Index: AQHOstiPFvKkLdrSeEmnp51nfAa89pnxjUYAgCPMTgA= Date: Mon, 4 Nov 2013 17:13:25 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030C3EF7@eusaamb106.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703086BF5@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXSPn+62q+VBBvPO6Fq03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO37LzIVdHFW9G9Yy9LAeJ69i5GTQ0LARKJl8mtmCFtM4sK9 9WxdjFwcQgJHGCUmz5vHApIQEljGKDHlASuIzSagI/H80T+wBhEBWYmlS/aDxYUFoiTe7HjC BBGPlnj79SZUjZXE/h272EBsFgEViba+U2AzeQV8JZr+bwWq5+DgFPCTePC4ACTMCHTD91Nr wMYwC4hL3HoynwniNgGJJXvOQ90pKvHy8T+wtaICehLds5azQsSVJZY82c8C0asjsWD3JzYI 21ri7eReRghbW2LZQoh/eQUEJU7OfMIygVFsFpJ1s5C0z0LSPgtJ+ywk7QsYWVcxcpQWp5bl phsZbmIExskxCTbHHYwLPlkeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A2N22uaZfu883v84/v/2g4Wz3fjvC+fm3a6z2plVND9G93/CXtXzmatchHa8zl37s+PHy1/c gd3qmxQn+S1/1JJ3hmtKZq7pc/bFsx/dYj9/b/eZr4VFf11nPao/8v+Iu8NVN7WnbKVLU9ua OW1OS14RviiXmWmen2GUsXKnzKwFF2oFPM9U+LoosRRnJBpqMRcVJwIAR5G1AGECAAA= Subject: [OSPF] FW: Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:21:33 -0000 Fred will present the use cases for source/destination routing in the Routing Working Group meeting today at 1:00 PM PST in Georgia B. I would encourage everyone to attend to consider the attendant work to support source/destination routing in OSPFv3. Thanks, Acee On 10/12/13 2:32 PM, "Acee Lindem" wrote: >This document hasn't received a lot of discussion on this list. However, >speaking as Routing Area advisor to the Homenet WG, I'd like to see it >accepted as a WG document given that this is a requirement for multi-homed >home networks.=20 >Thanks, >Acee > >On 9/16/13 5:30 AM, "Acee Lindem" wrote: > >>This document includes the encodings necessary for source/destination >>routing. The source/destination routing is required by the Homenet WG in >>support of flexible multi-homed IPv6 deployment. It uses the flexible >>OSPFv3 encodings. Please indicate your support or objections by September >>30th, 2013.=20 >>Thanks, >>Acee=20 >>_______________________________________________ >>OSPF mailing list >>OSPF@ietf.org >>https://www.ietf.org/mailman/listinfo/ospf > From acee.lindem@ericsson.com Mon Nov 4 10:38:19 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551CB21E80B1; Mon, 4 Nov 2013 10:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpDtx6gG6HXY; Mon, 4 Nov 2013 10:38:14 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 333DC21E8063; Mon, 4 Nov 2013 10:38:13 -0800 (PST) X-AuditID: c6180641-b7f3f8e000000a05-bb-5277e993e9ba Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 53.14.02565.399E7725; Mon, 4 Nov 2013 19:38:12 +0100 (CET) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 4 Nov 2013 13:38:08 -0500 From: Acee Lindem To: Adrian Farrel , Stewart Bryant , "ietf-secretariat@ietf.org" Thread-Topic: Publication Request for " Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks" Thread-Index: AQHO2Y0Byej/mdPHDkO2RKpaiOL+EA== Date: Mon, 4 Nov 2013 18:38:08 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030C602D@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: multipart/mixed; boundary="_004_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyuXSPt+6Ul+VBBvufCln86LnBbHF5yjp2 i6W9LSwWLffusVucezqH0YHVY8rvjaweS5b8ZPJYsXklo8eXy5/ZAliiuGxSUnMyy1KL9O0S uDIuTZrDVvAztOLupf1sDYy7groYOTkkBEwkTr94ywRhi0lcuLeeDcQWEjjCKLHumlUXIxeQ vYxR4n37KrAiNgEdieeP/jGDJEQE2hklbn5axwbiMAv0MErMeb2bGaRKWCBN4m7HeVYQW0Qg W+JozxygIg4gW0/i5C0pkDCLgIpE+7u7jCBhXgFfiX/760DCjEBHfD+1BmwXs4C4xK0n86GO E5F4ePE0G4QtKvHy8T+w6aJAE7tnLWeFiCtLLHmynwWiN1Piy/mFYNfwCghKnJz5hGUCo8gs JGNnISmbhaQMIp4v8f/yCVYIW0diwe5PbBC2tsSyha+ZYewzBx4DzeEAsq0l5vYWYirxkPh8 +zvUGBuJm23n2WeBA+sYo8TWPwuYYXqn/IXqVZSY0v2QfQEj3ypGjtLi1LLcdCPDTYzApHBM gs1xB+OCT5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNhXx7Rmx//T P5RkVDdxZmn/F2zyuKj2T41PpV351aJPVwKj5coYVbsiVaP+czW6HNrJY3k/T6qzS2COyfll P2LeaPv/PrXKNYl/ZqZ7W2sr77eFzwu2ia1ZcWBjdZbdojU3KqZJaqmoPdj5OfVj/5Ezx+dY 5a7ccJdpSid/6alvFpm3SlfOmKDEUpyRaKjFXFScCAAda0ei2AIAAA== Cc: OSPF List , "draft-ietf-ospf-manet-single-hop-or@tools.ietf.org" Subject: [OSPF] Publication Request for " Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:38:20 -0000 --_004_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_ Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_" --_000_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please publish draft-ietf-ospf-manet-single-hop-or-02.txt as an Experiment= al protocol. Shepherd writeup attached. Thanks to Yi Yang for being the doc= ument shepherd. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Please publish&nb= sp; dra= ft-ietf-ospf-manet-single-hop-or-02.txt as an Experimental prot= ocol. Shepherd writeup attached. Thanks to Yi Yang for being the document shepherd. 
Thanks, 
Acee

--_000_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_-- --_004_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_ Content-Type: text/plain; name="ospf-wg-manet-single-hop-or-writeup.txt" Content-Description: ospf-wg-manet-single-hop-or-writeup.txt Content-Disposition: attachment; filename="ospf-wg-manet-single-hop-or-writeup.txt"; size=6377; creation-date="Mon, 04 Nov 2013 18:38:08 GMT"; modification-date="Mon, 04 Nov 2013 18:38:08 GMT" Content-ID: <73657BEFD6D9484E8871550E792434E5@ericsson.com> Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLA1JbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyAgSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gDXRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NDSAgICAg RXhwZXJpbWVudGFsLiANICAgICANICAgICBBcyBhbiB1cGRhdGUgb2YgUkZDNTgyMCwgYW4gRXhw ZXJpbWVudGFsIFJGQywgaXQncyBqdXN0aWZpZWQgdG8gDSAgICAgY2F0ZWdvcml6ZSB0aGlzIGRy YWZ0IGFzIEV4cGVyaW1lbnRhbC4gDQ0oMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50 IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50DVdyaXRlLVVwLiBQbGVhc2UgcHJvdmlk ZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNlbnQNZXhhbXBsZXMg Y2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZA1k b2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyBzZWN0aW9uczoNDSAgICAgVGVjaG5pY2FsIFN1bW1hcnkgDQ0gICAgIFRoaXMgZHJhZnQgZGVz Y3JpYmVzIGhvdyB0byBzaW1wbGlmeS9vcHRpbWl6ZSBPU1BGLU1BTkVUIGludGVyZmFjZQ0gICAg IG9wZXJhdGlvbiwgb3JpZ2luYWxseSBzcGVjaWZpZWQgaW4gUkZDNTgyMCwgaW4gc2luZ2xlLWhv cCBicm9hZGNhc3QNICAgICBuZXR3b3Jrcy4NICAgICANICAgICBXb3JraW5nIEdyb3VwIFN1bW1h cnkgDQ0gICAgIFRoZSBpbml0aWFsIGRyYWZ0IHdhcyBwcmVzZW50ZWQgdG8gSUVURiBhYm91dCB0 d28geWVhcnMgYWdvLCBhbmQNICAgICB0aGVyZSB3ZXJlIHNvbWUgY29tbWVudHMvZGlzY3Vzc2lv biBvbiBlbWFpbCBhbGlhcyBhdCB0aGF0IHRpbWUuIA0gICAgIFRoZXJlIGhhdmUgYmVlbiBubyBm dXJ0aGVyIGRpc2N1c3Npb25zIHNpbmNlIHRoZW4uDQ0gICAgIERvY3VtZW50IFF1YWxpdHkgDQ0g ICAgIFRoZSBkb2N1bWVudCBoYXMgZ29uZSB0aHJvdWdoIHNldmVyYWwgV0cgcmV2aWV3IGN5Y2xl cyBhbmQgDSAgICAgcmV2aXNpb25zLiBDb21tZW50cyB3ZXJlIHJlY2VpdmVkIGZyb20gc29tZSBX RyBtZW1iZXJzLiBUbyB0aGUgYmVzdCANICAgICBvZiBteSBrbm93bGVkZ2UsIHRoZXJlIGFyZSBu byBpbXBsZW1lbnRhdGlvbnMuICANDSAgICAgUGVyc29ubmVsICAgICAgDQ0gICAgIFlpIFlhbmcg aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCBTdGV3YXJ0IEJyeWFudCBpcyB0aGUgDSAgICAg cmVzcG9uc2libGUgQUQuIA0NKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhlIHJldmlldyBvZiB0aGlz IGRvY3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ10aGUgRG9jdW1lbnQgU2hlcGhlcmQuICBJ ZiB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IGlzIG5vdCByZWFkeQ1mb3IgcHVibGljYXRp b24sIHBsZWFzZSBleHBsYWluIHdoeSB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgZm9yd2FyZGVkIHRv DXRoZSBJRVNHLg0NICAgIEkgd2FzIGFza2VkIGJ5IE9TUEYgV0cgY2hhaXIgdG8gcmV2aWV3IHRo ZSBkb2N1bWVudCBhcyB0aGUgRG9jdW1lbnQNICAgIFNoZXBoZXJkLiBJIHJlYWQgdGhyb3VnaCB0 aGUgZG9jdW1lbnQsIHRyYWNrZWQgdGhlIGRpc2N1c3Npb24gb24gDSAgICBlbWFpbCBhbGlhcywg YW5kIGNvbW11bmljYXRlZCB3aXRoIGF1dGhvcnMuIEkgYmVsaWV2ZSB0aGUgZG9jdW1lbnQNICAg IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gDQ0NKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBo ZXJkIGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvcg1icmVhZHRoIG9mIHRoZSBy ZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gDQ0gICAgTm8uIA0NDSg1KSBEbyBwb3J0 aW9ucyBvZiB0aGUgZG9jdW1lbnQgbmVlZCByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3IgZnJv bQ1icm9hZGVyIHBlcnNwZWN0aXZlLCBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxl eGl0eSwgQUFBLCBETlMsDURIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/IElmIHNv LCBkZXNjcmliZSB0aGUgcmV2aWV3IHRoYXQNdG9vayBwbGFjZS4NDSAgICBOby4NDSg2KSBEZXNj cmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNo ZXBoZXJkDWhhcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJlYSBE aXJlY3RvciBhbmQvb3IgdGhlDUlFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhhbXBsZSwg cGVyaGFwcyBoZSBvciBzaGUgaXMgdW5jb21mb3J0YWJsZQ13aXRoIGNlcnRhaW4gcGFydHMgb2Yg dGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkNaXMgYSBu ZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCBpZiB0aGUgaW50ZXJlc3RlZCBjb21tdW5pdHkgaGFz DWRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3 aXNoZXMgdG8gYWR2YW5jZQ10aGUgZG9jdW1lbnQsIGRldGFpbCB0aG9zZSBjb25jZXJucyBoZXJl Lg0NICAgTm9uZS4gDQ0oNykgSGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQg YWxsIGFwcHJvcHJpYXRlIElQUg1kaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OA1hbmQgQkNQIDc5IGhhdmUgYWxyZWFk eSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5Lg0NICAgWWVzLiAgIA0NKDgpIEhhcyBh biBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50 Pw1JZiBzbywgc3VtbWFyaXplIGFueSBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIHJlZ2FyZGlu ZyB0aGUgSVBSDWRpc2Nsb3N1cmVzLiAgICANDSAgWWVzIC0gSVBSIGRpc2Nsb3N1cmUgZmlsZWQu IFVwZGF0ZWQgZnJvbSBSRkMgNTgyMC4NDSAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2lwci8yMjAxLw0NDQ0oOSkgSG93IHNvbGlkIGlzIHRoZSBjb25zZW5zdXMgb2YgdGhlIGludGVy ZXN0ZWQgY29tbXVuaXR5IGJlaGluZCB0aGlzDWRvY3VtZW50PyBEb2VzIGl0IHJlcHJlc2VudCB0 aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1YWxzLA13aXRoIG90aGVycyBi ZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIGludGVyZXN0ZWQgY29tbXVuaXR5IGFzIGEgd2hvbGUN dW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8gDQ0gICBUaGVyZSBpcyBubyBvcHBvc2l0aW9u IHRvIHRoZSBkcmFmdC4gVGhvc2Ugd2hvIHVuZGVyc3RhbmQNICAgdGhlIE1BTkVUIHVzZSBjYXNl cywgZmVlbCB0aGlzIGlzIGEgdmlhYmxlIGFwcGxpY2F0aW9uIHRvIG9wdGltaXplDSAgIE1BTkVU IG9wZXJhdGlvbnMgaW4gc2luZ2xlLWhvcCBicm9hZGNhc3QgbmV0d29ya3MuIA0NKDEwKSBIYXMg YW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVt ZSANZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZs aWN0IGluIHNlcGFyYXRlDWVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBSZXNwb25zaWJsZSBBcmVhIERp cmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGENc2VwYXJhdGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1 ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxlLikgDSANICAgTm8uIA0NKDExKSBJZGVu dGlmeSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGluIHRoaXMN ZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy90b29scy9pZG5pdHMvIGFuZCB0aGUg SW50ZXJuZXQtRHJhZnRzDUNoZWNrbGlzdCkuIEJvaWxlcnBsYXRlIGNoZWNrcyBhcmUgbm90IGVu b3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZQ10aG9yb3VnaC4NDSAgIEFsbCBhcHBsaWNhYmxl IGlkbml0cyBlcnJvcnMgYW5kIHdhcm5pbmdzIGhhdmUgYmVlbiByZXNvbHZlZC4NDQ0oMTIpIERl c2NyaWJlIGhvdyB0aGUgZG9jdW1lbnQgbWVldHMgYW55IHJlcXVpcmVkIGZvcm1hbCByZXZpZXcN Y3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlw ZSByZXZpZXdzLg0NICAgTm90IGFwcGxpY2FibGUuIA0NKDEzKSBIYXZlIGFsbCByZWZlcmVuY2Vz IHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBhcw1laXRoZXIgbm9ybWF0aXZl IG9yIGluZm9ybWF0aXZlPw0NICAgWWVzLg0NKDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVy ZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCByZWFkeSBmb3INYWR2YW5jZW1lbnQgb3Ig YXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRlPyBJZiBzdWNoIG5vcm1hdGl2ZQ1yZWZl cmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSBwbGFuIGZvciB0aGVpciBjb21wbGV0aW9uPw0NICAg IE5vLiANDSgxNSkgQXJlIHRoZXJlIGRvd253YXJkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVy ZW5jZXMgKHNlZSBSRkMgMzk2Nyk/DUlmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5j ZXMgdG8gc3VwcG9ydCB0aGUgQXJlYSBEaXJlY3RvciBpbg10aGUgTGFzdCBDYWxsIHByb2NlZHVy ZS4NDSAgICBOby4NDSgxNikgV2lsbCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IGNoYW5n ZSB0aGUgc3RhdHVzIG9mIGFueSBleGlzdGluZw1SRkNzPyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQg b24gdGhlIHRpdGxlIHBhZ2UgaGVhZGVyLCBsaXN0ZWQgaW4gdGhlDWFic3RyYWN0LCBhbmQgZGlz Y3Vzc2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3QgbGlzdGVkDWlu IHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uLCBleHBsYWluIHdoeSwgYW5kIHBvaW50IHRv IHRoZSBwYXJ0IG9mDXRoZSBkb2N1bWVudCB3aGVyZSB0aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMg ZG9jdW1lbnQgdG8gdGhlIG90aGVyIFJGQ3MNaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0 aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsIGV4cGxhaW4gd2h5DXRoZSBpbnRlcmVzdGVkIGNv bW11bml0eSBjb25zaWRlcnMgaXQgdW5uZWNlc3NhcnkuDQ0gICAgTm8uIA0NKDE3KSBEZXNjcmli ZSB0aGUgRG9jdW1lbnQgU2hlcGhlcmQncyByZXZpZXcgb2YgdGhlIElBTkEgY29uc2lkZXJhdGlv bnMNc2VjdGlvbiwgZXNwZWNpYWxseSB3aXRoIHJlZ2FyZCB0byBpdHMgY29uc2lzdGVuY3kgd2l0 aCB0aGUgYm9keSBvZiB0aGUNZG9jdW1lbnQuIENvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0 ZW5zaW9ucyB0aGF0IHRoZSBkb2N1bWVudCBtYWtlcw1hcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBh cHByb3ByaWF0ZSByZXNlcnZhdGlvbnMgaW4gSUFOQSByZWdpc3RyaWVzLg1Db25maXJtIHRoYXQg YW55IHJlZmVyZW5jZWQgSUFOQSByZWdpc3RyaWVzIGhhdmUgYmVlbiBjbGVhcmx5DWlkZW50aWZp ZWQuIENvbmZpcm0gdGhhdCBuZXdseSBjcmVhdGVkIElBTkEgcmVnaXN0cmllcyBpbmNsdWRlIGEN ZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgaW5pdGlhbCBjb250ZW50cyBmb3IgdGhlIHJl Z2lzdHJ5LCB0aGF0DWFsbG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRp b25zIGFyZSBkZWZpbmVkLCBhbmQgYQ1yZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0 cnkgaGFzIGJlZW4gc3VnZ2VzdGVkIChzZWUgUkZDIDUyMjYpLg0NICAgIFRoaXMgZG9jdW1lbnQg ZG9lc24ndCByZXF1aXJlIGFueSBJQU5BIGFjdGlvbnMuDQ0oMTgpIExpc3QgYW55IG5ldyBJQU5B IHJlZ2lzdHJpZXMgdGhhdCByZXF1aXJlIEV4cGVydCBSZXZpZXcgZm9yIGZ1dHVyZQ1hbGxvY2F0 aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElFU0cgd291bGQgZmlu ZA11c2VmdWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5BIEV4cGVydHMgZm9yIHRoZXNlIG5ldyByZWdp c3RyaWVzLg0NICAgICBOb25lLiAgDQ0NKDE5KSBEZXNjcmliZSByZXZpZXdzIGFuZCBhdXRvbWF0 ZWQgY2hlY2tzIHBlcmZvcm1lZCBieSB0byB2YWxpZGF0ZQ1zZWN0aW9ucyBvZiB0aGUgZG9jdW1l bnQgd3JpdHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwgY29kZSwNQk5GIHJ1 bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4NDSAgICAgTm90IEFwcGxpY2FibGUuIA0= --_004_94A203EA12AECE4BA92D42DBFFE0AE47030C602Deusaamb106erics_-- From fred@cisco.com Thu Nov 7 08:46:30 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74321E81D7; Thu, 7 Nov 2013 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.406 X-Spam-Level: X-Spam-Status: No, score=-110.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfIFJp75IRmf; Thu, 7 Nov 2013 08:45:48 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED321E81DA; Thu, 7 Nov 2013 08:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1383842711; x=1385052311; h=from:to:cc:subject:date:message-id:mime-version; bh=0fCRmUo2kyj0YZUSKGrF6CVkYbrAGNuWML0DY2sRDyQ=; b=NfOUmwcP+/OhaC1tiiXG7SAX/bZa2oYIGWvnzHLzSUHqi4oVzm5/hQJN ZksHptKQxuktbOuK02gTPuxSOr1Jiwz0auFmuG2zUCEx09t1RsS17nutl ncrr+pzDlTKdJ6UKALOTbmU1PN1uq0W+RRV1VppbJ8YPz0F9nEisWwPL/ 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKXCe1KtJXG9/2dsb2JhbABagwc4U78OgSUWdIIseRIBgQAnBAENE4dzDbx0jg+BSoMngRADkC6BMIYugS+QW4Mmgio X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="asc'?scan'208";a="282091699" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2013 16:45:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7Gj8uB006053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 16:45:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 10:45:07 -0600 From: "Fred Baker (fred)" To: Routing WG , "ospf@ietf.org" , "isis-wg@ietf.org" Thread-Topic: Tsinghua work on source/destination routing Thread-Index: AQHO29i28SykYfa5/UyGL9QietHsLg== Date: Thu, 7 Nov 2013 16:45:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.25] Content-Type: multipart/signed; boundary="Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , "v6ops@ietf.org WG" Subject: [OSPF] Tsinghua work on source/destination routing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:46:31 -0000 --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd like to draw your attention to a talk that will be given this = morning in homenet. The context is: = http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-case= s http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases "Requirements and Use Cases for Source/Destination Routing", Fred = Baker, 2013-08-13 http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class http://tools.ietf.org/html/draft-xu-homenet-traffic-class "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu = Yang, Jianping Wu, Fred Baker, 2013-10-21 http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, = Shu Yang, Jianping Wu, Dan Wang, 2013-08-22 http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28 http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, = Fred Baker, 2013-10-15 I had breakfast this morning with Shu Yang, who has been writing Quagga = code for several years in the course of his PHd. He first implemented a = source/destination model, reported on in = draft-xu-homenet-twod-ip-routing, which was an MTR scheme. He tells me = he found that very complex. He also listened to my talk in homenet = around draft-baker-fun-routing-class, and has now implemented (if I = understand him correctly) draft-ietf-ospf-ospfv3-lsa-extend and = draft-baker-ipv6-ospf-dst-src-routing. The FIB implementation has a = limitation: the source prefixes must be disjoint. However, given that, = he has two FIB implementations, one of which has separate FIBs for each = source prefix in play including ::/0 (so if there are M prefixes in the = network, M+1 FIBs), and one of which is a single hierarchical M-Trie = that looks up the destination and then the source. He has tested the = code in simulation; the next step is testing in live networks. Examples of use cases are generally around multi-prefix campus networks. = There is a security use case that could be of value; at IETF 87, George = Michaelson of APNIC reported on ULAs seen in his darknet. The short = report is that he sees a fair bit of traffic with a ULA source address = on the backbone. An interesting potential use of source/destination = routing would counter that, and perhaps mitigate the need for ISP BCP 38 = if generally deployed; in a case where a network is using a ULA and a = global prefix (e.g., is not multihomed but has two prefixes, one of = which is intended to only be used within its network), the default route = to the network egress would use the global prefix as a source, and as a = result traffic sent outside the network with a ULA source prefix would = in effect have no route. The network could literally only emit traffic = from its correct prefix. I think this is relevant to the discussion of=20 draft-baker-rtgwg-src-dst-routing-use-cases draft-ietf-ospf-ospfv3-lsa-extend draft-baker-ipv6-ospf-dst-src-routing draft-baker-ipv6-isis-dst-src-routing --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSe8OSbjEdbHIsm0MRAo4JAKD1Gu32KozZNW+5Y1ee5sH14VA5XACg/9jZ h0LqlvvqSnEfhdffbQ568wA= =ofmZ -----END PGP SIGNATURE----- --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2-- From yiya@cisco.com Thu Nov 7 14:36:58 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DE21E808F for ; Thu, 7 Nov 2013 14:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZP7ii4Zvxtu for ; Thu, 7 Nov 2013 14:36:52 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3711E815A for ; Thu, 7 Nov 2013 14:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=234; q=dns/txt; s=iport; t=1383863810; x=1385073410; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=i8c1r8kzK68lE03mqBZHXnj2ETKV4xVPci9E9wW0yQc=; b=L3avSlB/XnXo67BEdrKkRL+FVcHA3FjLMs5GEmoSvQ01v7WVdFgo6uy2 ued+LWYOHA38+CImkHk6HY6dERXExn1lb99wy7WgnR7F/JenUzhVJxBkw kKUFs04zyvyea626V5jF4F8uq97BhAVvXgXrLKwkHi5YZ3ElKhBKJ2M2G U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPEUfFKtJV2Z/2dsb2JhbABagweBC8A1FnSCLDpRAT5CJwSIFJtKoV+UEAOYDJIKgyaCKg X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208";a="282154163" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 07 Nov 2013 22:36:49 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7Man9l012358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Nov 2013 22:36:49 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 16:36:49 -0600 From: "Yi Yang (yiya)" To: OSPF List Thread-Topic: draft-zzhang-ospf-two-part-metric Thread-Index: AQHO3AnYlulKAND70ka+g1IIpxrEhw== Date: Thu, 7 Nov 2013 22:36:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.82.216.244] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] draft-zzhang-ospf-two-part-metric X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:36:58 -0000 As network LSA is used, DR needs to be elected to generate the network LSA. In such a mobile environment, one concern would be that we are going to have frequent DR/BDR elections and network LSA origination consequently.=20 Yi From equinox@spaceboyz.net Thu Nov 7 14:49:58 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572BF11E816F for ; Thu, 7 Nov 2013 14:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ual5AYe90vzL for ; Thu, 7 Nov 2013 14:49:57 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7B211E815B for ; Thu, 7 Nov 2013 14:49:57 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1VeYOe-0001OI-Ui; Thu, 07 Nov 2013 23:49:53 +0100 Date: Thu, 7 Nov 2013 23:49:52 +0100 From: David Lamparter To: OSPF List Message-ID: <20131107224952.GW4891@spaceboyz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Subject: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:49:58 -0000 Hi ospf WG, since most of the stuff being presented in the WG is beyond what I can do for Quagga, I've used the time to type up an overview for E-LSA compatibility scenarios. Quite possibly I've made a lot of mistakes. Anyway here it goes. -David Compatibility mechanic A - 3 states, mixed LSA use ================================================== Assumes "fallback" LSA lookups, where routers may use the combined set of E-LSAs and LSAs for calculation. (E-LSAs should probably supersede equivalent LSAs in that case, just to get determinism.) - 0 (old) 1 (mixed) 2 (new) - - use use E-LSAs advertise advertise - - - - - - - - - - - - - - - - - - - - - - - - - - - LSAs advertise advertise - use use The only invalid combination is 0/1/2. This is detectable by all routers when they see both a Router LSA without a matching E-LSA _and_ a Router E-LSA without a matching LSA. (Except in the multi-area case.) The routers detecting this could exclude themselves from the domain on detecting this, but they can only detect this after getting the entire database. On the adjacency level, 0 - 1 - 1 - 2 cannot be detected as each router only sees a valid combination. If there is distributed knowledge about mode-1 capability, automatically degrading the OSPF domain from mode-2 to mode-1 after seeing a mode-0 router is possible. (If this downgrade capability is enabled and signaled by all routers.) Use of the U bit in this case allows other mode-1 routers to get (and use) the E-LSA versions of LSAs even if they're isolated by mode-0 routers from the originator. The downside is that mixing LSA types opens really nice ways of messing it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously. Also, race conditions may start popping up if LSAs arrive from flooding before E-LSAs. Either way, if a router is identified as E-LSA capable, LSAs originated by it should never be used by mode-1 routers. It may also make sense to specify that mode-1 routers must flood associated LSAs and E-LSAs simultaneously. Compatibility mechanic B - 4 states, no mixed LSA use ===================================================== Assumes strict restriction to using only one type of LSAs on any single particular router. Different routers may be in different modes and therefore be using different LSA types in their calculations. - 0 (old) 1 (degraded) 2 (mixed) 3 (new) - - use use E-LSAs advertise advertise advertise - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - LSAs advertise advertise advertise - use use A valid, working combination is composed of two neighboring of those modes. 0/1/2 doesn't work because mode-2 routers won't see mode-0 routers, similarly 1/2/3 won't work because mode-1 routers won't see mode-3 routers. Folding up modes 1 & 2 into one mode isn't possible without mixing LSA types in calculations. Enforcing valid, working combinations at the adjacency level can't detect misconfigurations like 1 - 2 - 2 - 3. The simplest thing to make this detectable on all "new" routers is probably including a TLV in the Router E-LSA that indicates modes 1 or 2. (Mode 0 is a plain old Router LSA and mode-3 is a Router E-LSA without the TLV.) Combination 0,1,2 can also be detected by mode-2 routers (and mode-2 routers only) when they see a Router LSA without a matching Router E-LSA. Combination 1,2,3 can be detected by mode-1 routers (only) when they see a Router E-LSA without a matching Router LSA. The routers detecting this could exclude themselves from the domain on detecting this, but they can only detect this after getting the entire database. NB: mode-3 routers can _not_ assume misconfiguration on seeing old-style LSAs since they might be originated by mode-2 routers, which is a valid configuration. Any router can detect a 0/1/2/3 mixture/misconfiguration. (Again, except in a multi-area case.) [no suggestions on what to do after detecting the misconfiguration, a red blinking LED and a buzzer seem appropriate to me. Automatic downgrades are certainly possible, but quite a bit more complicated than in case A before.] Note that use of the U bit on E-LSAs is not neccessary in this case. Either the domain consists of routers in modes 0/1 and it doesn't matter if the E-LSAs get distributed or not (because they're not used), or there are no mode-0 routers, meaning all routers distribute E-LSAs anyway. It does affect misconfiguration detection though. Overall, this seems more complex, but then again it provides robustness against accidental or malicious LSA<>E-LSA mismatches. From xuxiaohu@huawei.com Thu Nov 7 14:52:04 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5D621E80BB for ; Thu, 7 Nov 2013 14:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[AWL=2.474, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blvmMJFyubua for ; Thu, 7 Nov 2013 14:51:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8FA021E8169 for ; Thu, 7 Nov 2013 14:51:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ77350; Thu, 07 Nov 2013 22:51:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 22:51:12 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 22:51:55 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 06:51:51 +0800 From: Xuxiaohu To: "ospf@ietf.org" , "isis@ietf.org" Thread-Topic: Inconsistency between OSPF extention and IS-IS extension for segment routing Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODg== Date: Thu, 7 Nov 2013 22:51:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:52:04 -0000 Hi co-authors of the above two drafts, OSPF extension draft proposes to use Extended Prefix Opaque LSA to carry SR= -related attributes. Since the Extended Prefix Opaque LSA does not advertis= e reachability of the prefix, but only its attributes, the prefixes contain= ed within those LSAs for building IP routing table (e.g., Router LSAs) can = be aggregated when crossing area boundaries while the Extended Prefix Opaqu= e LSAs containing prefix SIDs can be intactly propagated across area boudar= ies. The final effect is much similar to the mechanism defined in RFC5283. In contract, IS-IS extension draft proposes to reuse those Extended IP Reac= hability TLVs which are used for building IP routing table to carry SR-rela= ted attributes. Although this choice has the benefit of propagating less LS= As, it loses the capability of aggregating routes when acrossing level boud= aries. Furthermore, it requires the L1/L2 routers much be SR-capable. Although these two drafts are proposing extensions to two different IGPs, I= MHO, it would better to provide similar capabilities if possible, especiall= y advoid destroying the existing capabilities of these two IGPs, e.g., int= er-area/level route aggregation capability. To Peter Psenak, I don't agree with your argrment that the reason that IS-IS extension draft= made that choice is because there is no choice for IS-IS. In fact, you can= use the signalling mechanism for Label Request which has been proposed in = draft-xu-rtgwg-global-label-adv-00. That's to say, you can use separate Ext= ended IP Reachability TLVs other than those for IP reachability advertiseme= nt to carry SR-related attibutes. Since the former TLVs are intened for adv= ertising label bindings other than building IP routing table, the Metric fi= eld of these TLVs is set to a value larger than MAX_PATH_METRIC (i.e., 0xFE= 000000). It's a normal approach for IS-IS. Of course, if SR is just used wi= thin a single level, it's good to use the existing approach proposed in the= IS-IS extension draft. Best regards, Xiaohu= From hannes@juniper.net Thu Nov 7 15:24:40 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5721E808A for ; Thu, 7 Nov 2013 15:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax6ZZwAfxEU0 for ; Thu, 7 Nov 2013 15:24:33 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id C50F811E812F for ; Thu, 7 Nov 2013 15:24:31 -0800 (PST) Received: from mail220-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 23:24:30 +0000 Received: from mail220-tx2 (localhost [127.0.0.1]) by mail220-tx2-R.bigfish.com (Postfix) with ESMTP id 12EBC340372; Thu, 7 Nov 2013 23:24:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h1155h) Received-SPF: pass (mail220-tx2: domain of juniper.net designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=hannes@juniper.net; helo=BY2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail220-tx2 (localhost.localdomain [127.0.0.1]) by mail220-tx2 (MessageSwitch) id 138386666992681_29345; Thu, 7 Nov 2013 23:24:29 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.240]) by mail220-tx2.bigfish.com (Postfix) with ESMTP id 08604740062; Thu, 7 Nov 2013 23:24:29 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 23:24:24 +0000 Received: from hannes-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.84.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 23:24:23 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com> Date: Fri, 8 Nov 2013 00:24:15 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.53] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ospf@ietf.org" , "isis@ietf.org" Subject: Re: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:24:40 -0000 hi xuxiaohu, On Nov 7, 2013, at 11:51 PM, Xuxiaohu wrote: > OSPF extension draft proposes to use Extended Prefix Opaque LSA to = carry SR-related attributes. Since the Extended Prefix Opaque LSA does = not advertise reachability of the prefix, but only its attributes, the = prefixes contained within those LSAs for building IP routing table = (e.g., Router LSAs) can be aggregated when crossing area boundaries = while the Extended Prefix Opaque LSAs containing prefix SIDs can be = intactly propagated across area boudaries. The final effect is much = similar to the mechanism defined in RFC5283. >=20 > In contract, IS-IS extension draft proposes to reuse those Extended IP = Reachability TLVs which are used for building IP routing table to carry = SR-related attributes. Although this choice has the benefit of = propagating less LSAs, it loses the capability of aggregating routes = when a crossing level boudaries. Furthermore, it requires the L1/L2 = routers much be SR-capable. and why is it a problem squeezing a few thousand transport loopbacks across an ABR / L1L2 router ? > Although these two drafts are proposing extensions to two different = IGPs, IMHO, it would better to provide similar capabilities if possible, = especially advoid destroying the existing capabilities of these two = IGPs, e.g., inter-area/level route aggregation capability. most SPs running hierarchical IS-IS have turned on domain wide prefix = leaking. in fact doing aggregation in those environments is prohibitive in = determining the true cost to a particular BGP next hop. - so we do not really loose much. > To Peter Psenak, >=20 > I don't agree with your argrment that the reason that IS-IS extension = draft made that choice is because there is no choice for IS-IS. i second that opinion - the only extensible container for IP prefixes = are the=20 extended IP reach TLVs. > In fact, you can use the signalling mechanism for Label Request which = has been proposed in draft-xu-rtgwg-global-label-adv-00. That's to say, = you can use separate Extended IP Reachability TLVs other than those for = IP reachability advertisement to carry SR-related attibutes. Since the = former TLVs are intened for advertising label bindings other than = building IP routing table, the Metric field of these TLVs is set to a = value larger than MAX_PATH_METRIC (i.e., 0xFE000000). It's a normal = approach for IS-IS. Of course, if SR is just used within a single level, = it's good to use the existing approach proposed in the IS-IS extension = draft. keep in mind that we do not advertise a label per prefix but rather a = global *index*. it is my understanding that the semantics of = draft-xu-rtgwg-global-label-adv-00 are quite different in the sense that absolute label values are being = advertised here. /hannes= From ppsenak@cisco.com Thu Nov 7 15:46:32 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7269A11E8123 for ; Thu, 7 Nov 2013 15:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9D-b0uZqVem for ; Thu, 7 Nov 2013 15:46:28 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7056121E816F for ; Thu, 7 Nov 2013 15:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2615; q=dns/txt; s=iport; t=1383867921; x=1385077521; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gMME11kvhR9qy9uZ4FzEPKZ8efwNsb/AGVXHf19kSUc=; b=g6E8XL61AJC+N+cky0C1SyvDE7HCAl2ofOL6B0jU4vrEzXIHKdMFVRRX jc9CcBotm+5rTNo6NmlptaODtMeCGStNUkEz9Jn8+bqMWFVnQytJEhZ1d yqxHHvW2rZpweY8BJs+UdOJYg4BUqdA9bdQV/WT5+nl/SzrtMS4S/LBxe g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAM4lfFKrRDoG/2dsb2JhbABagwc4v2OBKBZ0giUBAQEDAQEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGHdwUOvS4Ej1kHhDADiUCOTIY9i02BaIFfGw X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="93616406" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 07 Nov 2013 23:45:13 +0000 Received: from [10.21.70.191] ([10.21.70.191]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA7NjBC0027930; Thu, 7 Nov 2013 23:45:12 GMT Message-ID: <527C2606.5060906@cisco.com> Date: Thu, 07 Nov 2013 15:45:10 -0800 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "isis@ietf.org" Subject: Re: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:46:32 -0000 Xiaohu, please see inline: On 11/7/13 14:51 , Xuxiaohu wrote: > Hi co-authors of the above two drafts, > > OSPF extension draft proposes to use Extended Prefix Opaque LSA to carry SR-related attributes. Since the Extended Prefix Opaque LSA does not advertise reachability of the prefix, but only its attributes, the prefixes contained within those LSAs for building IP routing table (e.g., Router LSAs) can be aggregated when crossing area boundaries while the Extended Prefix Opaque LSAs containing prefix SIDs can be intactly propagated across area boudaries. The final effect is much similar to the mechanism defined in RFC5283. > > In contract, IS-IS extension draft proposes to reuse those Extended IP Reachability TLVs which are used for building IP routing table to carry SR-related attributes. Although this choice has the benefit of propagating less LSAs, it loses the capability of aggregating routes when acrossing level boudaries. Furthermore, it requires the L1/L2 routers much be SR-capable. if you aggregate on area/L1L2 boundary, SIDs/labels for individual prefixes that are covered by the aggregate are useless in the area to which you aggregate - there will be no FIB entries for these individual prefixes in such area. So if you aggregate, there is no need to propagate SIDs/labels for aggregated prefixes. thanks, Peter > > Although these two drafts are proposing extensions to two different IGPs, IMHO, it would better to provide similar capabilities if possible, especially advoid destroying the existing capabilities of these two IGPs, e.g., inter-area/level route aggregation capability. > > To Peter Psenak, > > I don't agree with your argrment that the reason that IS-IS extension draft made that choice is because there is no choice for IS-IS. In fact, you can use the signalling mechanism for Label Request which has been proposed in draft-xu-rtgwg-global-label-adv-00. That's to say, you can use separate Extended IP Reachability TLVs other than those for IP reachability advertisement to carry SR-related attibutes. Since the former TLVs are intened for advertising label bindings other than building IP routing table, the Metric field of these TLVs is set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). It's a normal approach for IS-IS. Of course, if SR is just used within a single level, it's good to use the existing approach proposed in the IS-IS extension draft. > > Best regards, > Xiaohu > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From xuxiaohu@huawei.com Thu Nov 7 16:17:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DAF21E8169 for ; Thu, 7 Nov 2013 16:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[AWL=-2.149, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZanDUCHwyym for ; Thu, 7 Nov 2013 16:17:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 089F221E81A7 for ; Thu, 7 Nov 2013 16:17:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ80880; Fri, 08 Nov 2013 00:17:15 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:16:29 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:17:12 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 08:17:08 +0800 From: Xuxiaohu To: Hannes Gredler Thread-Topic: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODv//kP6AgACO0Lw= Date: Fri, 8 Nov 2013 00:17:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227791@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.171] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BG?= =?gb2312?b?IGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJv?= =?gb2312?b?dXRpbmc=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:17:23 -0000 SGkgSGFubmVzLA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IEhhbm5lcyBHcmVkbGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAx M8TqMTHUwjjI1SA3OjI0DQrK1bz+yMs6IFh1eGlhb2h1DQqzrcvNOiBvc3BmQGlldGYub3JnOyBp c2lzQGlldGYub3JnDQrW98ziOiBSZTogW09TUEZdIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BG IGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJvdXRpbmcNCg0KaGkg eHV4aWFvaHUsDQoNCk9uIE5vdiA3LCAyMDEzLCBhdCAxMTo1MSBQTSwgWHV4aWFvaHUgd3JvdGU6 DQo+IE9TUEYgZXh0ZW5zaW9uIGRyYWZ0IHByb3Bvc2VzIHRvIHVzZSBFeHRlbmRlZCBQcmVmaXgg T3BhcXVlIExTQSB0byBjYXJyeSBTUi1yZWxhdGVkIGF0dHJpYnV0ZXMuIFNpbmNlIHRoZSBFeHRl bmRlZCBQcmVmaXggT3BhcXVlIExTQSBkb2VzIG5vdCBhZHZlcnRpc2UgcmVhY2hhYmlsaXR5IG9m IHRoZSBwcmVmaXgsIGJ1dCBvbmx5IGl0cyBhdHRyaWJ1dGVzLCB0aGUgcHJlZml4ZXMgY29udGFp bmVkIHdpdGhpbiB0aG9zZSBMU0FzIGZvciBidWlsZGluZyBJUCByb3V0aW5nIHRhYmxlIChlLmcu LCBSb3V0ZXIgTFNBcykgY2FuIGJlIGFnZ3JlZ2F0ZWQgd2hlbiBjcm9zc2luZyBhcmVhIGJvdW5k YXJpZXMgd2hpbGUgdGhlIEV4dGVuZGVkIFByZWZpeCBPcGFxdWUgTFNBcyBjb250YWluaW5nIHBy ZWZpeCBTSURzIGNhbiBiZSBpbnRhY3RseSBwcm9wYWdhdGVkIGFjcm9zcyBhcmVhIGJvdWRhcmll cy4gVGhlIGZpbmFsIGVmZmVjdCBpcyBtdWNoIHNpbWlsYXIgdG8gdGhlIG1lY2hhbmlzbSBkZWZp bmVkIGluIFJGQzUyODMuDQo+DQo+IEluIGNvbnRyYWN0LCBJUy1JUyBleHRlbnNpb24gZHJhZnQg cHJvcG9zZXMgdG8gcmV1c2UgdGhvc2UgRXh0ZW5kZWQgSVAgUmVhY2hhYmlsaXR5IFRMVnMgd2hp Y2ggYXJlIHVzZWQgZm9yIGJ1aWxkaW5nIElQIHJvdXRpbmcgdGFibGUgdG8gY2FycnkgU1ItcmVs YXRlZCBhdHRyaWJ1dGVzLiBBbHRob3VnaCB0aGlzIGNob2ljZSBoYXMgdGhlIGJlbmVmaXQgb2Yg cHJvcGFnYXRpbmcgbGVzcyBMU0FzLCBpdCBsb3NlcyB0aGUgY2FwYWJpbGl0eSBvZiBhZ2dyZWdh dGluZyByb3V0ZXMgd2hlbiBhIGNyb3NzaW5nIGxldmVsIGJvdWRhcmllcy4gRnVydGhlcm1vcmUs IGl0IHJlcXVpcmVzIHRoZSBMMS9MMiByb3V0ZXJzIG11Y2ggYmUgU1ItY2FwYWJsZS4NCg0KYW5k IHdoeSBpcyBpdCBhIHByb2JsZW0gc3F1ZWV6aW5nIGEgZmV3IHRob3VzYW5kIHRyYW5zcG9ydCBs b29wYmFja3MNCmFjcm9zcyBhbiBBQlIgLyBMMUwyIHJvdXRlciA/DQoNCltYaWFvaHVdIEkgc2hv dWxkIGhhdmUgc2FpZCB0aGF0IGlmIHlvdSB3YW50IHRvIGFnZ3JlZ2F0ZSB0aG9zZSAvMzIgcHJl Zml4ZXMgZm9yIHRyYW5zcG9ydCBsb29wYmFjayBhZGRyZXNzZXMgd2hlbiBjcm9zc2luZyBMMS9M MiByb3V0ZXJzLCB0aG9zZSBMMS9MMiByb3V0ZXJzIE1VU1QgYmUgU1ItY2FwYWJsZS4gT3RoZXJ3 aXNlLCB0aG9zZSBwcmVmaXhlcyBjYW4gbm90IGJlIGFnZ3JlZ2F0ZWQuIFRoZSByZWFzb24gaXMg dGhhdCBpdCByZXF1aXJlcyBMMS9MMiByb3V0ZXJzIHRvIHRyYW5zbGF0ZSBhIFRMViBjb250YWlu aW5nIHByZWZpeCBTSUQgaW50byB0d28gVExWcywgb25lIGlzIHRoZSBUTFYgY29udGFpbmluZyB0 aGUgYWdncmVnYXRlZCByb3V0ZSwgdGhlIG90aGVyIGlzIHRoZSBUTFYgY29udGFpbmluZyB0aGUg cHJlZml4LVNJRC4gSW4gYWRkaXRpb24sIGl0IHNlZW1zIHRoYXQgdGhlcmUgaXMgbm8gbWVudGlv biBhYm91dCB3aGV0aGVyIHRoZSAvMzIgcHJlZml4IGNvbnRhaW5lZCBpbiB0aGUgbGF0dGVyIFRM ViB3aWxsIGJlIHN0aWxsIHVzZWQgZm9yIGJ1aWxkaW5nIElQIHJvdXRpbmcgdGFibGUuIElmIHll cywgdGhlc2UgaG9zdCByb3V0ZXMgYXJlIGFjdHVhbGx5IGxlYWtlZCBhY3Jvc3MgbGV2ZWxzLiBJ ZiBubywgdGhlIE1ldHJpYyBmaWVsZCBTSE9VTEQgYmUgc2V0IHRvIGEgdmFsdWUgbGFyZ2VyIHRo YW4gTUFYX1BBVEhfTUVUUklDIChpLmUuLCAweEZFMDAwMDAwKS4NCg0KPiBBbHRob3VnaCB0aGVz ZSB0d28gZHJhZnRzIGFyZSBwcm9wb3NpbmcgZXh0ZW5zaW9ucyB0byB0d28gZGlmZmVyZW50IElH UHMsIElNSE8sIGl0IHdvdWxkIGJldHRlciB0byBwcm92aWRlIHNpbWlsYXIgY2FwYWJpbGl0aWVz IGlmIHBvc3NpYmxlLCBlc3BlY2lhbGx5IGFkdm9pZCBkZXN0cm95aW5nIHRoZSBleGlzdGluZyBj YXBhYmlsaXRpZXMgb2YgdGhlc2UgdHdvIElHUHMsICBlLmcuLCBpbnRlci1hcmVhL2xldmVsIHJv dXRlIGFnZ3JlZ2F0aW9uIGNhcGFiaWxpdHkuDQoNCm1vc3QgU1BzIHJ1bm5pbmcgaGllcmFyY2hp Y2FsIElTLUlTIGhhdmUgdHVybmVkIG9uIGRvbWFpbiB3aWRlIHByZWZpeCBsZWFraW5nLg0KaW4g ZmFjdCBkb2luZyBhZ2dyZWdhdGlvbiBpbiB0aG9zZSBlbnZpcm9ubWVudHMgaXMgcHJvaGliaXRp dmUgaW4gZGV0ZXJtaW5pbmcNCnRoZSB0cnVlIGNvc3QgdG8gYSBwYXJ0aWN1bGFyIEJHUCBuZXh0 IGhvcC4gLSBzbyB3ZSBkbyBub3QgcmVhbGx5IGxvb3NlDQptdWNoLg0KDQpbWGlhb2h1XSBEaWQg eW91IG1lYW4gdGhhdCBSRkM1MjgzIGlzIHVzZWxlc3MgaW4gbW9zdCBTUCBuZXR3b3Jrcz8NCg0K PiBUbyBQZXRlciBQc2VuYWssDQo+DQo+IEkgZG9uJ3QgYWdyZWUgd2l0aCB5b3VyIGFyZ3JtZW50 IHRoYXQgdGhlIHJlYXNvbiB0aGF0IElTLUlTIGV4dGVuc2lvbiBkcmFmdCBtYWRlIHRoYXQgY2hv aWNlIGlzIGJlY2F1c2UgdGhlcmUgaXMgbm8gY2hvaWNlIGZvciBJUy1JUy4NCg0KaSBzZWNvbmQg dGhhdCBvcGluaW9uIC0gdGhlIG9ubHkgZXh0ZW5zaWJsZSBjb250YWluZXIgZm9yIElQIHByZWZp eGVzIGFyZSB0aGUNCmV4dGVuZGVkIElQIHJlYWNoIFRMVnMuDQoNCj4gSW4gZmFjdCwgeW91IGNh biB1c2UgdGhlIHNpZ25hbGxpbmcgbWVjaGFuaXNtIGZvciBMYWJlbCBSZXF1ZXN0IHdoaWNoIGhh cyBiZWVuIHByb3Bvc2VkIGluIGRyYWZ0LXh1LXJ0Z3dnLWdsb2JhbC1sYWJlbC1hZHYtMDAuIFRo YXQncyB0byBzYXksIHlvdSBjYW4gdXNlIHNlcGFyYXRlIEV4dGVuZGVkIElQIFJlYWNoYWJpbGl0 eSBUTFZzIG90aGVyIHRoYW4gdGhvc2UgZm9yIElQIHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50 IHRvIGNhcnJ5IFNSLXJlbGF0ZWQgYXR0aWJ1dGVzLiBTaW5jZSB0aGUgZm9ybWVyIFRMVnMgYXJl IGludGVuZWQgZm9yIGFkdmVydGlzaW5nIGxhYmVsIGJpbmRpbmdzIG90aGVyIHRoYW4gYnVpbGRp bmcgSVAgcm91dGluZyB0YWJsZSwgdGhlIE1ldHJpYyBmaWVsZCBvZiB0aGVzZSBUTFZzIGlzIHNl dCB0byBhIHZhbHVlIGxhcmdlciB0aGFuIE1BWF9QQVRIX01FVFJJQyAoaS5lLiwgMHhGRTAwMDAw MCkuIEl0J3MgYSBub3JtYWwgYXBwcm9hY2ggZm9yIElTLUlTLiBPZiBjb3Vyc2UsIGlmIFNSIGlz IGp1c3QgdXNlZCB3aXRoaW4gYSBzaW5nbGUgbGV2ZWwsIGl0J3MgZ29vZCB0byB1c2UgdGhlIGV4 aXN0aW5nIGFwcHJvYWNoIHByb3Bvc2VkIGluIHRoZSBJUy1JUyBleHRlbnNpb24gZHJhZnQuDQoN Cg0Ka2VlcCBpbiBtaW5kIHRoYXQgd2UgZG8gbm90IGFkdmVydGlzZSBhIGxhYmVsIHBlciBwcmVm aXggYnV0IHJhdGhlciBhIGdsb2JhbCAqaW5kZXgqLg0KaXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0 aGF0IHRoZSBzZW1hbnRpY3Mgb2YgZHJhZnQteHUtcnRnd2ctZ2xvYmFsLWxhYmVsLWFkdi0wMA0K YXJlIHF1aXRlIGRpZmZlcmVudCBpbiB0aGUgc2Vuc2UgdGhhdCBhYnNvbHV0ZSBsYWJlbCB2YWx1 ZXMgYXJlIGJlaW5nIGFkdmVydGlzZWQgaGVyZS4NCg0KW1hpYW9odV0gVGhhbmsgZm9yIHBvaW50 aW5nIG91dCB0aGlzLiBJbiBmYWN0LCBpZiB0aGUgc2VnbWVudCByb3V0aW5nIHBhcmFkaWdtIGZp bmFsbHkgdXNlcyBnbG9iYWwgaW5kZXhzLCByYXRoZXIgdGhhbiBnbG9iYWwgbGFiZWxzLCB0aGUg bWVjaGFuaXNtIGRlZmluZWQgaW4gdGhlIGFib3ZlIGRyYWZ0IGNhbiBiZSBlYXNpbHkgYWRhcHRl ZCB0byBhZHZlcnRpc2UgZ2xvYmFsIGluZGV4cyBhcyB3ZWxsLg0KDQpCUiwNClhpYW9odQ0KDQov aGFubmVz From xuxiaohu@huawei.com Thu Nov 7 16:23:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCCE21E808F; Thu, 7 Nov 2013 16:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.383 X-Spam-Level: X-Spam-Status: No, score=0.383 tagged_above=-999 required=5 tests=[AWL=-2.066, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji1iTZm6we11; Thu, 7 Nov 2013 16:23:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB221E8195; Thu, 7 Nov 2013 16:23:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ81159; Fri, 08 Nov 2013 00:23:48 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:23:05 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:23:47 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 08:23:40 +0800 From: Xuxiaohu To: Peter Psenak Thread-Topic: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODv//ltYAgACPRrw= Date: Fri, 8 Nov 2013 00:23:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> In-Reply-To: <527C2606.5060906@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.171] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BG?= =?gb2312?b?IGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJv?= =?gb2312?b?dXRpbmc=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:23:54 -0000 DQpIaSBQZXRlciwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K t6K8/sjLOiBQZXRlciBQc2VuYWsgW3Bwc2VuYWtAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTPE 6jEx1MI4yNUgNzo0NQ0KytW8/sjLOiBYdXhpYW9odQ0Ks63LzTogb3NwZkBpZXRmLm9yZzsgaXNp c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtPU1BGXSBJbmNvbnNpc3RlbmN5IGJldHdlZW4gT1NQRiBl eHRlbnRpb24gYW5kIElTLUlTIGV4dGVuc2lvbiBmb3Igc2VnbWVudCByb3V0aW5nDQoNClhpYW9o dSwNCg0KcGxlYXNlIHNlZSBpbmxpbmU6DQoNCk9uIDExLzcvMTMgMTQ6NTEgLCBYdXhpYW9odSB3 cm90ZToNCj4gSGkgY28tYXV0aG9ycyBvZiB0aGUgYWJvdmUgdHdvIGRyYWZ0cywNCj4NCj4gT1NQ RiBleHRlbnNpb24gZHJhZnQgcHJvcG9zZXMgdG8gdXNlIEV4dGVuZGVkIFByZWZpeCBPcGFxdWUg TFNBIHRvIGNhcnJ5IFNSLXJlbGF0ZWQgYXR0cmlidXRlcy4gU2luY2UgdGhlIEV4dGVuZGVkIFBy ZWZpeCBPcGFxdWUgTFNBIGRvZXMgbm90IGFkdmVydGlzZSByZWFjaGFiaWxpdHkgb2YgdGhlIHBy ZWZpeCwgYnV0IG9ubHkgaXRzIGF0dHJpYnV0ZXMsIHRoZSBwcmVmaXhlcyBjb250YWluZWQgd2l0 aGluIHRob3NlIExTQXMgZm9yIGJ1aWxkaW5nIElQIHJvdXRpbmcgdGFibGUgKGUuZy4sIFJvdXRl ciBMU0FzKSBjYW4gYmUgYWdncmVnYXRlZCB3aGVuIGNyb3NzaW5nIGFyZWEgYm91bmRhcmllcyB3 aGlsZSB0aGUgRXh0ZW5kZWQgUHJlZml4IE9wYXF1ZSBMU0FzIGNvbnRhaW5pbmcgcHJlZml4IFNJ RHMgY2FuIGJlIGludGFjdGx5IHByb3BhZ2F0ZWQgYWNyb3NzIGFyZWEgYm91ZGFyaWVzLiBUaGUg ZmluYWwgZWZmZWN0IGlzIG11Y2ggc2ltaWxhciB0byB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4g UkZDNTI4My4NCj4NCj4gSW4gY29udHJhY3QsIElTLUlTIGV4dGVuc2lvbiBkcmFmdCBwcm9wb3Nl cyB0byByZXVzZSB0aG9zZSBFeHRlbmRlZCBJUCBSZWFjaGFiaWxpdHkgVExWcyB3aGljaCBhcmUg dXNlZCBmb3IgYnVpbGRpbmcgSVAgcm91dGluZyB0YWJsZSB0byBjYXJyeSBTUi1yZWxhdGVkIGF0 dHJpYnV0ZXMuIEFsdGhvdWdoIHRoaXMgY2hvaWNlIGhhcyB0aGUgYmVuZWZpdCBvZiBwcm9wYWdh dGluZyBsZXNzIExTQXMsIGl0IGxvc2VzIHRoZSBjYXBhYmlsaXR5IG9mIGFnZ3JlZ2F0aW5nIHJv dXRlcyB3aGVuIGFjcm9zc2luZyBsZXZlbCBib3VkYXJpZXMuIEZ1cnRoZXJtb3JlLCBpdCByZXF1 aXJlcyB0aGUgTDEvTDIgcm91dGVycyBtdWNoIGJlIFNSLWNhcGFibGUuDQoNCmlmIHlvdSBhZ2dy ZWdhdGUgb24gYXJlYS9MMUwyIGJvdW5kYXJ5LCBTSURzL2xhYmVscyBmb3IgaW5kaXZpZHVhbA0K cHJlZml4ZXMgdGhhdCBhcmUgY292ZXJlZCBieSB0aGUgYWdncmVnYXRlIGFyZSB1c2VsZXNzIGlu IHRoZSBhcmVhIHRvDQp3aGljaCB5b3UgYWdncmVnYXRlIC0gdGhlcmUgd2lsbCBiZSBubyBGSUIg ZW50cmllcyBmb3IgdGhlc2UgaW5kaXZpZHVhbA0KcHJlZml4ZXMgaW4gc3VjaCBhcmVhLiBTbyBp ZiB5b3UgYWdncmVnYXRlLCB0aGVyZSBpcyBubyBuZWVkIHRvDQpwcm9wYWdhdGUgU0lEcy9sYWJl bHMgZm9yIGFnZ3JlZ2F0ZWQgcHJlZml4ZXMuDQoNCltYaWFvaHVdICJJbiB0aGUgbXVsdGktYXJl YS9sZXZlbA0KICAgc2NlbmFyaW8gd2hlcmUgcm91dGUgc3VtbWFyeSBiZXR3ZWVuIGFyZWFzL2xl dmVscyBpcyByZXF1aXJlZCwgdGhlIElQDQogICBsb25nZXN0LW1hdGNoIGFsZ29yaXRobSBTSE9V TEQgYmUgdXNlZCBieSBTUi1jYXBhYmxlIHJvdXRlcnMgd2hlbg0KICAgcHJvY2Vzc2luZyBsYWJl bCBiaW5kaW5ncyBhZHZlcnRpc2VkIGJ5IHRoZSBtYXBwaW5nIHNlcnZlciIgRm9yIG1vcmUgZGV0 YWlscywgcGxlYXNlIHJlYWQgdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIG9mIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXJ0Z3dnLWdsb2JhbC1sYWJlbC1hZHYtMDANCg0KQmVz dCByZWdhcmRzLA0KWGlhb2h1DQoNCiINCg0KdGhhbmtzLA0KUGV0ZXINCg0KPg0KPiBBbHRob3Vn aCB0aGVzZSB0d28gZHJhZnRzIGFyZSBwcm9wb3NpbmcgZXh0ZW5zaW9ucyB0byB0d28gZGlmZmVy ZW50IElHUHMsIElNSE8sIGl0IHdvdWxkIGJldHRlciB0byBwcm92aWRlIHNpbWlsYXIgY2FwYWJp bGl0aWVzIGlmIHBvc3NpYmxlLCBlc3BlY2lhbGx5IGFkdm9pZCBkZXN0cm95aW5nIHRoZSBleGlz dGluZyBjYXBhYmlsaXRpZXMgb2YgdGhlc2UgdHdvIElHUHMsICBlLmcuLCBpbnRlci1hcmVhL2xl dmVsIHJvdXRlIGFnZ3JlZ2F0aW9uIGNhcGFiaWxpdHkuDQo+DQo+IFRvIFBldGVyIFBzZW5haywN Cj4NCj4gSSBkb24ndCBhZ3JlZSB3aXRoIHlvdXIgYXJncm1lbnQgdGhhdCB0aGUgcmVhc29uIHRo YXQgSVMtSVMgZXh0ZW5zaW9uIGRyYWZ0IG1hZGUgdGhhdCBjaG9pY2UgaXMgYmVjYXVzZSB0aGVy ZSBpcyBubyBjaG9pY2UgZm9yIElTLUlTLiBJbiBmYWN0LCB5b3UgY2FuIHVzZSB0aGUgc2lnbmFs bGluZyBtZWNoYW5pc20gZm9yIExhYmVsIFJlcXVlc3Qgd2hpY2ggaGFzIGJlZW4gcHJvcG9zZWQg aW4gZHJhZnQteHUtcnRnd2ctZ2xvYmFsLWxhYmVsLWFkdi0wMC4gVGhhdCdzIHRvIHNheSwgeW91 IGNhbiB1c2Ugc2VwYXJhdGUgRXh0ZW5kZWQgSVAgUmVhY2hhYmlsaXR5IFRMVnMgb3RoZXIgdGhh biB0aG9zZSBmb3IgSVAgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgdG8gY2FycnkgU1ItcmVs YXRlZCBhdHRpYnV0ZXMuIFNpbmNlIHRoZSBmb3JtZXIgVExWcyBhcmUgaW50ZW5lZCBmb3IgYWR2 ZXJ0aXNpbmcgbGFiZWwgYmluZGluZ3Mgb3RoZXIgdGhhbiBidWlsZGluZyBJUCByb3V0aW5nIHRh YmxlLCB0aGUgTWV0cmljIGZpZWxkIG9mIHRoZXNlIFRMVnMgaXMgc2V0IHRvIGEgdmFsdWUgbGFy Z2VyIHRoYW4gTUFYX1BBVEhfTUVUUklDIChpLmUuLCAweEZFMDAwMDAwKS4gSXQncyBhIG5vcm1h bCBhcHByb2FjaCBmb3IgSVMtSVMuIE9mIGNvdXJzZSwgaWYgU1IgaXMganVzdCB1c2VkIHdpdGhp biBhIHNpbmdsZSBsZXZlbCwgaXQncyBnb29kIHRvIHVzZSB0aGUgZXhpc3RpbmcgYXBwcm9hY2gg cHJvcG9zZWQgaW4gdGhlIElTLUlTIGV4dGVuc2lvbiBkcmFmdC4NCj4NCj4gQmVzdCByZWdhcmRz LA0KPiBYaWFvaHUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gT1NQRiBtYWlsaW5nIGxpc3QNCj4gT1NQRkBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCj4= From ppsenak@cisco.com Thu Nov 7 16:40:06 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DE921E80BD; Thu, 7 Nov 2013 16:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn88tQN+YOHK; Thu, 7 Nov 2013 16:40:01 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB211E823D; Thu, 7 Nov 2013 16:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1146; q=dns/txt; s=iport; t=1383871194; x=1385080794; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=B1AAWCTBE7C+BR9r67jbVTWAc+cakpZjaPjTttKVYpk=; b=SWUQDfQnM30bpwpCx4iBDkzmqImSdR11WM4vcY1h+Ay7lJpqD/xdveft 5733qU7dqmGusaaq0ba25AKiqE63kdLUMgB6TIhZkBEdSmw0IxTOAefv2 NJ/Z9bMViUNUG1eR9yh3pVWPOHs0v0qIjUSIcUWITfIcYotNdISs5IrN5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAHcyfFKrRDoI/2dsb2JhbABagwc4g0e8HIEoFnSCJQEBAQR4ARAJAhgEBRYNAgkDAgECAToLBg0BBwEBh3wOjwibWAiSU4EljjQHgmeBSQOJDTOOTIEvhQ6LTYFogV8b X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="96846556" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Nov 2013 00:39:15 +0000 Received: from [10.21.114.250] (sjc-vpn2-762.cisco.com [10.21.114.250]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA80dDcj026887; Fri, 8 Nov 2013 00:39:13 GMT Message-ID: <527C32B0.5070101@cisco.com> Date: Thu, 07 Nov 2013 16:39:12 -0800 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: Re: [OSPF] =?gb2312?b?tPC4tDogIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BG?= =?gb2312?b?IGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJv?= =?gb2312?b?dXRpbmc=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:40:06 -0000 Xiaohu, On 11/7/13 16:23 , Xuxiaohu wrote: > > Hi Peter, ] > if you aggregate on area/L1L2 boundary, SIDs/labels for individual > prefixes that are covered by the aggregate are useless in the area to > which you aggregate - there will be no FIB entries for these individual > prefixes in such area. So if you aggregate, there is no need to > propagate SIDs/labels for aggregated prefixes. > > [Xiaohu] "In the multi-area/level > scenario where route summary between areas/levels is required, the IP > longest-match algorithm SHOULD be used by SR-capable routers when > processing label bindings advertised by the mapping server" For more details, please read the Introduction section of http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00 I don't understand. If you summarize, then only the summary prefix will be visible in the backbone (and remote areas) and installed in the FIB on all routers in these areas. Where would you apply 'longest-match algorithm' when you only see the single summary? How would you use the SID/label for prefixes that are covered by the summary? thanks, Peter From zzhang@juniper.net Thu Nov 7 16:48:45 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01B111E81BA for ; Thu, 7 Nov 2013 16:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGomGm66qRaV for ; Thu, 7 Nov 2013 16:48:38 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6511E827F for ; Thu, 7 Nov 2013 16:48:28 -0800 (PST) Received: from mail57-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 00:48:27 +0000 Received: from mail57-co9 (localhost [127.0.0.1]) by mail57-co9-R.bigfish.com (Postfix) with ESMTP id DE14268066E; Fri, 8 Nov 2013 00:48:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail57-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(13464003)(377454003)(51704005)(74316001)(81342001)(56776001)(74366001)(66066001)(47976001)(50986001)(77096001)(81542001)(56816003)(47736001)(74876001)(76796001)(74706001)(74502001)(31966008)(79102001)(65816001)(80022001)(76786001)(76576001)(33646001)(47446002)(74662001)(63696002)(83072001)(81686001)(80976001)(54356001)(81816001)(51856001)(46102001)(87266001)(53806001)(19580395003)(19580405001)(83322001)(85306002)(4396001)(76482001)(59766001)(77982001)(87936001)(69226001)(2656002)(49866001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB080; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail57-co9 (localhost.localdomain [127.0.0.1]) by mail57-co9 (MessageSwitch) id 1383871705843276_32438; Fri, 8 Nov 2013 00:48:25 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.251]) by mail57-co9.bigfish.com (Postfix) with ESMTP id C9C7E1A0055; Fri, 8 Nov 2013 00:48:25 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 00:48:25 +0000 Received: from BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 8 Nov 2013 00:48:25 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB080.namprd05.prod.outlook.com (10.242.38.17) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 8 Nov 2013 00:48:17 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.16]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.16]) with mapi id 15.00.0810.005; Fri, 8 Nov 2013 00:48:17 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Yi Yang (yiya)" , OSPF List Thread-Topic: [OSPF] draft-zzhang-ospf-two-part-metric Thread-Index: AQHO3BfyNQtsFWe0xUOv1deydyoSA5oaf04w Date: Fri, 8 Nov 2013 00:48:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 00246AB517 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [OSPF] draft-zzhang-ospf-two-part-metric X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:48:45 -0000 Yi, As we discussed offline, typically in this kind of networks there are a few= routers are relatively stable (e.g., at fixed-location base stations) and = they can have higher priorities to become DR/BDR. Thanks. Jeffrey > -----Original Message----- > From: Yi Yang (yiya) [mailto:yiya@cisco.com] > Sent: Thursday, November 07, 2013 5:37 PM > To: OSPF List > Subject: [OSPF] draft-zzhang-ospf-two-part-metric >=20 > As network LSA is used, DR needs to be elected to generate the network > LSA. In such a mobile environment, one concern would be that we are > going to have frequent DR/BDR elections and network LSA origination > consequently. >=20 > Yi >=20 From xuxiaohu@huawei.com Thu Nov 7 17:28:56 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD011E81BA; Thu, 7 Nov 2013 17:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.459 X-Spam-Level: X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[AWL=-1.990, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbB+1MYSWe9R; Thu, 7 Nov 2013 17:28:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2D11E81B9; Thu, 7 Nov 2013 17:28:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAA64436; Fri, 08 Nov 2013 01:28:49 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 01:28:48 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 01:28:47 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 09:28:40 +0800 From: Xuxiaohu To: Peter Psenak Thread-Topic: =?gb2312?B?tPC4tDogW09TUEZdIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BGIGV4dGVu?= =?gb2312?Q?tion_and_IS-IS_extension_for_segment_routing?= Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODv//ltYAgACPRrz//3/TAIAAkrMG Date: Fri, 8 Nov 2013 01:28:40 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> In-Reply-To: <527C32B0.5070101@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.96] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogtPC4tDogIEluY29uc2lzdGVuY3kgYmV0d2Vl?= =?gb2312?b?biBPU1BGIGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdt?= =?gb2312?b?ZW50IHJvdXRpbmc=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 01:28:56 -0000 SGkgUGV0ZXIsDQoNClRoZSAnbG9uZ2VzdC1tYXRjaCBhbGdvcml0aG0nIGZvciBMSUIgaW5zdGFs bGF0aW9uIGhhcyBiZWVuIHByb3Bvc2VkIGJ5IFJGQzUyODMuDQoNCkJlc3QgcmVnYXJkcywNClhp YW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6 IFBldGVyIFBzZW5hayBbcHBzZW5ha0BjaXNjby5jb21dDQq3osvNyrG85DogMjAxM8TqMTHUwjjI 1SA4OjM5DQrK1bz+yMs6IFh1eGlhb2h1DQqzrcvNOiBvc3BmQGlldGYub3JnOyBpc2lzLXdnQGll dGYub3JnDQrW98ziOiBSZTogtPC4tDogW09TUEZdIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BG IGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJvdXRpbmcNCg0KWGlh b2h1LA0KDQpPbiAxMS83LzEzIDE2OjIzICwgWHV4aWFvaHUgd3JvdGU6DQo+DQo+IEhpIFBldGVy LA0KXQ0KPiBpZiB5b3UgYWdncmVnYXRlIG9uIGFyZWEvTDFMMiBib3VuZGFyeSwgU0lEcy9sYWJl bHMgZm9yIGluZGl2aWR1YWwNCj4gcHJlZml4ZXMgdGhhdCBhcmUgY292ZXJlZCBieSB0aGUgYWdn cmVnYXRlIGFyZSB1c2VsZXNzIGluIHRoZSBhcmVhIHRvDQo+IHdoaWNoIHlvdSBhZ2dyZWdhdGUg LSB0aGVyZSB3aWxsIGJlIG5vIEZJQiBlbnRyaWVzIGZvciB0aGVzZSBpbmRpdmlkdWFsDQo+IHBy ZWZpeGVzIGluIHN1Y2ggYXJlYS4gU28gaWYgeW91IGFnZ3JlZ2F0ZSwgdGhlcmUgaXMgbm8gbmVl ZCB0bw0KPiBwcm9wYWdhdGUgU0lEcy9sYWJlbHMgZm9yIGFnZ3JlZ2F0ZWQgcHJlZml4ZXMuDQo+ DQo+IFtYaWFvaHVdICJJbiB0aGUgbXVsdGktYXJlYS9sZXZlbA0KPiAgICAgc2NlbmFyaW8gd2hl cmUgcm91dGUgc3VtbWFyeSBiZXR3ZWVuIGFyZWFzL2xldmVscyBpcyByZXF1aXJlZCwgdGhlIElQ DQo+ICAgICBsb25nZXN0LW1hdGNoIGFsZ29yaXRobSBTSE9VTEQgYmUgdXNlZCBieSBTUi1jYXBh YmxlIHJvdXRlcnMgd2hlbg0KPiAgICAgcHJvY2Vzc2luZyBsYWJlbCBiaW5kaW5ncyBhZHZlcnRp c2VkIGJ5IHRoZSBtYXBwaW5nIHNlcnZlciIgRm9yIG1vcmUgZGV0YWlscywgcGxlYXNlIHJlYWQg dGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXh1LXJ0Z3dnLWdsb2JhbC1sYWJlbC1hZHYtMDANCg0KSSBkb24ndCB1bmRlcnN0YW5kLiBJ ZiB5b3Ugc3VtbWFyaXplLCB0aGVuIG9ubHkgdGhlIHN1bW1hcnkgcHJlZml4IHdpbGwNCmJlIHZp c2libGUgaW4gdGhlIGJhY2tib25lIChhbmQgcmVtb3RlIGFyZWFzKSBhbmQgaW5zdGFsbGVkIGlu IHRoZSBGSUINCm9uIGFsbCByb3V0ZXJzIGluIHRoZXNlIGFyZWFzLg0KDQpXaGVyZSB3b3VsZCB5 b3UgYXBwbHkgJ2xvbmdlc3QtbWF0Y2ggYWxnb3JpdGhtJyB3aGVuIHlvdSBvbmx5IHNlZSB0aGUN CnNpbmdsZSBzdW1tYXJ5PyBIb3cgd291bGQgeW91IHVzZSB0aGUgU0lEL2xhYmVsIGZvciBwcmVm aXhlcyB0aGF0IGFyZQ0KY292ZXJlZCBieSB0aGUgc3VtbWFyeT8NCg0KdGhhbmtzLA0KUGV0ZXI= From xuxiaohu@huawei.com Thu Nov 7 17:48:00 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0321E811A; Thu, 7 Nov 2013 17:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=-1.919, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThXJ2W8a5IKI; Thu, 7 Nov 2013 17:47:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D06121E80EC; Thu, 7 Nov 2013 17:47:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAA65383; Fri, 08 Nov 2013 01:47:40 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 01:46:56 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 01:47:39 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 09:47:34 +0800 From: Xuxiaohu To: Hannes Gredler Thread-Topic: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODv//kP6AgACrCX4= Date: Fri, 8 Nov 2013 01:47:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227817@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.96] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BG?= =?gb2312?b?IGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJv?= =?gb2312?b?dXRpbmc=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 01:48:00 -0000 PiBUbyBQZXRlciBQc2VuYWssDQo+DQo+IEkgZG9uJ3QgYWdyZWUgd2l0aCB5b3VyIGFyZ3JtZW50 IHRoYXQgdGhlIHJlYXNvbiB0aGF0IElTLUlTIGV4dGVuc2lvbiBkcmFmdCBtYWRlIHRoYXQgY2hv aWNlIGlzIGJlY2F1c2UgdGhlcmUgaXMgbm8gY2hvaWNlIGZvciBJUy1JUy4NCg0KaSBzZWNvbmQg dGhhdCBvcGluaW9uIC0gdGhlIG9ubHkgZXh0ZW5zaWJsZSBjb250YWluZXIgZm9yIElQIHByZWZp eGVzIGFyZSB0aGUNCmV4dGVuZGVkIElQIHJlYWNoIFRMVnMuDQoNCltYaWFvaHVdIFllcywgeW91 IHNob3VsZCBzdGlsbCB1c2UgdGhlIEV4dGVuZGVkIElQIHJlYWNoYWJpbGl0eSBUTFZzIHRvIGNh cnJ5IFNSLXJlbGF0ZWQgYXR0cmlidXRlcy4gSG93b3ZlciwgeW91IGNhbiB1c2UgInNlcGFyYXRl IiBFeHRlbmRlZCBJUCByZWFjaGFiaWxpdHkgVExWcyBvdGhlciB0aGFuIHRob3NlIEV4dGVuZGVk IElQIHJlYWNoYWJpbGl0eSBUTFZzIGZvciBidWlsZGluZyBJUCByb3V0aW5nIHRhYmxlIHRvIGFk dmVydGlzZSBsYWJlbCBiaW5kaW5ncy4gU2luY2UgdGhlIGZvcm1lciBUTFZzIGFyZSBqdXN0IGlu dGVuZGVkIGZvciBsYWJlbCBkaXN0cmlidXRpb24sIHJhdGhlciB0aGFuIElQIHJlYWNoYWJpbGl0 eSBhZHZlcnRpc2VtZW50LCB0aGUgTWV0cmljIGZpZWxkIG9mIHRoZXNlIFRMVnMgaXMgc2V0IHRv IGEgdmFsdWUgbGFyZ2VyIHRoYW4gTUFYX1BBVEhfTUVUUklDIChpLmUuLCAweEZFMDAwMDAwKS4g SW4gdGhpcyB3YXksIHRoZSBmb3JtZXIgVExWcyBub3cgcGxheSB0aGUgc2ltaWxhciByb2xlIG9m IHRoZSBPU1BGIEV4dGVuZGVkIFByZWZpeCBPcGFxdWUgTFNBcy4gDQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ== From ppsenak@cisco.com Fri Nov 8 11:56:26 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BF21E819E; Fri, 8 Nov 2013 11:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.128 X-Spam-Level: X-Spam-Status: No, score=-5.128 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv6StuzbunP1; Fri, 8 Nov 2013 11:56:22 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F031121E8179; Fri, 8 Nov 2013 11:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1750; q=dns/txt; s=iport; t=1383940582; x=1385150182; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YJqwxZ4JnklB3RHRAEVkGb+KUzJoSg3SsVLx5HtNuyY=; b=L5x+aMqzpT24gxRhiXpKP8DskhNqxdvXyr5jHPUFxl43QA/sZToEECXU uRdhuNsJvZJXRccQaE03u5mm8HxMerIw9+XJEdDZjL6Pw0zCKupqidpaN 0D6VLwUdn+DZuOJe5CBGLFBMGM3LM9u3ME13WRR9vmW9AoiTB+LDyvoYZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAJpBfVKrRDoJ/2dsb2JhbABZgwc4g0e8IoExFnSCJQEBAQQyAUUBEAkCGAQFFg0CCQMCAQIBOgsGDQEFAgEBh3wOjxGbWAiSSIEljkIHgmeBSQOJDzOOTYEvhQ6LToFogV8b X-IronPort-AV: E=Sophos;i="4.93,661,1378857600"; d="scan'208";a="94404526" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 08 Nov 2013 19:56:21 +0000 Received: from [10.21.86.118] ([10.21.86.118]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA8JuKSq013843; Fri, 8 Nov 2013 19:56:20 GMT Message-ID: <527D41E3.1050008@cisco.com> Date: Fri, 08 Nov 2013 11:56:19 -0800 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: Re: [OSPF] =?gb2312?b?tPC4tDogtPC4tDogIEluY29uc2lzdGVuY3kgYmV0d2Vl?= =?gb2312?b?biBPU1BGIGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdt?= =?gb2312?b?ZW50IHJvdXRpbmc=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:56:26 -0000 Xiaohu, there is no LDP in the SR network, so RFC5283 is not applicable. thanks, Peter On 11/7/13 17:28 , Xuxiaohu wrote: > Hi Peter, > > The 'longest-match algorithm' for LIB installation has been proposed by RFC5283. > > Best regards, > Xiaohu > > ________________________________________ > ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] > ·¢ËÍʱ¼ä: 2013Äê11ÔÂ8ÈÕ 8:39 > ÊÕ¼þÈË: Xuxiaohu > ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org > Ö÷Ìâ: Re: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing > > Xiaohu, > > On 11/7/13 16:23 , Xuxiaohu wrote: >> >> Hi Peter, > ] >> if you aggregate on area/L1L2 boundary, SIDs/labels for individual >> prefixes that are covered by the aggregate are useless in the area to >> which you aggregate - there will be no FIB entries for these individual >> prefixes in such area. So if you aggregate, there is no need to >> propagate SIDs/labels for aggregated prefixes. >> >> [Xiaohu] "In the multi-area/level >> scenario where route summary between areas/levels is required, the IP >> longest-match algorithm SHOULD be used by SR-capable routers when >> processing label bindings advertised by the mapping server" For more details, please read the Introduction section of http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00 > > I don't understand. If you summarize, then only the summary prefix will > be visible in the backbone (and remote areas) and installed in the FIB > on all routers in these areas. > > Where would you apply 'longest-match algorithm' when you only see the > single summary? How would you use the SID/label for prefixes that are > covered by the summary? > > thanks, > Peter > From xuxiaohu@huawei.com Fri Nov 8 12:05:06 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC621E81D1; Fri, 8 Nov 2013 12:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.507 X-Spam-Level: X-Spam-Status: No, score=0.507 tagged_above=-999 required=5 tests=[AWL=-1.942, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiV7JTq7A-Oq; Fri, 8 Nov 2013 12:05:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 302DC11E81B4; Fri, 8 Nov 2013 12:04:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR63265; Fri, 08 Nov 2013 20:04:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:04:08 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:04:53 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 04:04:46 +0800 From: Xuxiaohu To: Peter Psenak Thread-Topic: =?gb2312?B?W0lzaXMtd2ddILTwuLQ6ILTwuLQ6IFtPU1BGXSBJbmNvbnNpc3RlbmN5IGJl?= =?gb2312?B?dHdlZW4gT1NQRiBleHRlbnRpb24gYW5kIElTLUlTIGV4dGVuc2lvbiBmb3Ig?= =?gb2312?Q?segment_routing?= Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODv//ltYAgACPRrz//3/TAIAAkrMGgACwmICAAIelwA== Date: Fri, 8 Nov 2013 20:04:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> In-Reply-To: <527D41E3.1050008@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogW0lzaXMtd2ddILTwuLQ6ILTwuLQ6ICBJbmNv?= =?gb2312?b?bnNpc3RlbmN5IGJldHdlZW4gT1NQRiBleHRlbnRpb24gYW5kIElTLUlTIGV4?= =?gb2312?b?dGVuc2lvbiBmb3Igc2VnbWVudCByb3V0aW5n?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:05:06 -0000 SGkgUGV0ZXIsDQoNClN1cmUuIEhvd2V2ZXIsIHdoeSBub3QgYm9ycm93IHRoZSBpZGVhIG9mIGxv bmdlc3QtbWF0Y2hpbmcgYWxnb3JpdGhtIHByb3Bvc2VkIGluIHRoYXQgUkZDIHRvIFNSPw0KDQpC UiwNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IGlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZyBbaXNpcy13Zy1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIFBldGVyIFBzZW5hayBbcHBzZW5ha0BjaXNjby5jb21dDQq3osvNyrG85DogMjAxM8Tq MTHUwjnI1SAzOjU2DQrK1bz+yMs6IFh1eGlhb2h1DQqzrcvNOiBvc3BmQGlldGYub3JnOyBpc2lz LXdnQGlldGYub3JnDQrW98ziOiBSZTogW0lzaXMtd2ddILTwuLQ6ILTwuLQ6IFtPU1BGXSBJbmNv bnNpc3RlbmN5IGJldHdlZW4gT1NQRiBleHRlbnRpb24gYW5kIElTLUlTIGV4dGVuc2lvbiBmb3Ig c2VnbWVudCByb3V0aW5nDQoNClhpYW9odSwNCg0KdGhlcmUgaXMgbm8gTERQIGluIHRoZSBTUiBu ZXR3b3JrLCBzbyBSRkM1MjgzIGlzIG5vdCBhcHBsaWNhYmxlLg0KDQp0aGFua3MsDQpQZXRlcg0K DQpPbiAxMS83LzEzIDE3OjI4ICwgWHV4aWFvaHUgd3JvdGU6DQo+IEhpIFBldGVyLA0KPg0KPiBU aGUgJ2xvbmdlc3QtbWF0Y2ggYWxnb3JpdGhtJyBmb3IgTElCIGluc3RhbGxhdGlvbiBoYXMgYmVl biBwcm9wb3NlZCBieSBSRkM1MjgzLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogUGV0 ZXIgUHNlbmFrIFtwcHNlbmFrQGNpc2NvLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTPE6jEx1MI4yNUg ODozOQ0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOty806IG9zcGZAaWV0Zi5vcmc7IGlzaXMtd2dA aWV0Zi5vcmcNCj4g1vfM4jogUmU6ILTwuLQ6IFtPU1BGXSBJbmNvbnNpc3RlbmN5IGJldHdlZW4g T1NQRiBleHRlbnRpb24gYW5kIElTLUlTIGV4dGVuc2lvbiBmb3Igc2VnbWVudCByb3V0aW5nDQo+ DQo+IFhpYW9odSwNCj4NCj4gT24gMTEvNy8xMyAxNjoyMyAsIFh1eGlhb2h1IHdyb3RlOg0KPj4N Cj4+IEhpIFBldGVyLA0KPiBdDQo+PiBpZiB5b3UgYWdncmVnYXRlIG9uIGFyZWEvTDFMMiBib3Vu ZGFyeSwgU0lEcy9sYWJlbHMgZm9yIGluZGl2aWR1YWwNCj4+IHByZWZpeGVzIHRoYXQgYXJlIGNv dmVyZWQgYnkgdGhlIGFnZ3JlZ2F0ZSBhcmUgdXNlbGVzcyBpbiB0aGUgYXJlYSB0bw0KPj4gd2hp Y2ggeW91IGFnZ3JlZ2F0ZSAtIHRoZXJlIHdpbGwgYmUgbm8gRklCIGVudHJpZXMgZm9yIHRoZXNl IGluZGl2aWR1YWwNCj4+IHByZWZpeGVzIGluIHN1Y2ggYXJlYS4gU28gaWYgeW91IGFnZ3JlZ2F0 ZSwgdGhlcmUgaXMgbm8gbmVlZCB0bw0KPj4gcHJvcGFnYXRlIFNJRHMvbGFiZWxzIGZvciBhZ2dy ZWdhdGVkIHByZWZpeGVzLg0KPj4NCj4+IFtYaWFvaHVdICJJbiB0aGUgbXVsdGktYXJlYS9sZXZl bA0KPj4gICAgICBzY2VuYXJpbyB3aGVyZSByb3V0ZSBzdW1tYXJ5IGJldHdlZW4gYXJlYXMvbGV2 ZWxzIGlzIHJlcXVpcmVkLCB0aGUgSVANCj4+ICAgICAgbG9uZ2VzdC1tYXRjaCBhbGdvcml0aG0g U0hPVUxEIGJlIHVzZWQgYnkgU1ItY2FwYWJsZSByb3V0ZXJzIHdoZW4NCj4+ICAgICAgcHJvY2Vz c2luZyBsYWJlbCBiaW5kaW5ncyBhZHZlcnRpc2VkIGJ5IHRoZSBtYXBwaW5nIHNlcnZlciIgRm9y IG1vcmUgZGV0YWlscywgcGxlYXNlIHJlYWQgdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIG9mIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXJ0Z3dnLWdsb2JhbC1sYWJlbC1hZHYt MDANCj4NCj4gSSBkb24ndCB1bmRlcnN0YW5kLiBJZiB5b3Ugc3VtbWFyaXplLCB0aGVuIG9ubHkg dGhlIHN1bW1hcnkgcHJlZml4IHdpbGwNCj4gYmUgdmlzaWJsZSBpbiB0aGUgYmFja2JvbmUgKGFu ZCByZW1vdGUgYXJlYXMpIGFuZCBpbnN0YWxsZWQgaW4gdGhlIEZJQg0KPiBvbiBhbGwgcm91dGVy cyBpbiB0aGVzZSBhcmVhcy4NCj4NCj4gV2hlcmUgd291bGQgeW91IGFwcGx5ICdsb25nZXN0LW1h dGNoIGFsZ29yaXRobScgd2hlbiB5b3Ugb25seSBzZWUgdGhlDQo+IHNpbmdsZSBzdW1tYXJ5PyBI b3cgd291bGQgeW91IHVzZSB0aGUgU0lEL2xhYmVsIGZvciBwcmVmaXhlcyB0aGF0IGFyZQ0KPiBj b3ZlcmVkIGJ5IHRoZSBzdW1tYXJ5Pw0KPg0KPiB0aGFua3MsDQo+IFBldGVyDQo+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJc2lzLXdnIG1haWxp bmcgbGlzdA0KSXNpcy13Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pc2lzLXdn From ppsenak@cisco.com Fri Nov 8 12:38:04 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DEA21E8099; Fri, 8 Nov 2013 12:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxcvKYZ-4dnq; Fri, 8 Nov 2013 12:37:56 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C807921E80F5; Fri, 8 Nov 2013 12:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3081; q=dns/txt; s=iport; t=1383943047; x=1385152647; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Vu7FVX5o09Pq/lHlbIPJLEi8bKgNdPMLUjC/LiOkkeo=; b=DeMADOGEan+DzxUyIpN05BkzsBCBge+XzswIBAfIKBV/3AgugWG61FNv Ldp/IAWGj4/ibuZDCyyJD9avpeHWn1Zn5CX+V2H2iyxHVBA+8eXw4JQRn Wro1d+qM4rLo+TZldfaB8r09sUEuw4dQVuf1fbYM5SyySDWv5dmhEILug w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAANLfVKrRDoI/2dsb2JhbABZgwc4g0e8IoExFnSCJQEBAQQBAQEvATsKARAJAhgEBRYECQIJAwIBAgEVJQsGDQEFAgEBh3wOjwKbWAiSQIEljkIHgmeBSQOJDzOOTYEvhQ6LToFogV8b X-IronPort-AV: E=Sophos;i="4.93,662,1378857600"; d="scan'208";a="93692713" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 08 Nov 2013 20:37:23 +0000 Received: from [10.21.118.82] ([10.21.118.82]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA8KbMWF008603; Fri, 8 Nov 2013 20:37:22 GMT Message-ID: <527D4B80.6070308@cisco.com> Date: Fri, 08 Nov 2013 12:37:20 -0800 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: Re: [OSPF] =?gb2312?b?W0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0OiAgSW5j?= =?gb2312?b?b25zaXN0ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0ZW50aW9uIGFuZCBJUy1JUyBl?= =?gb2312?b?eHRlbnNpb24gZm9yIHNlZ21lbnQgcm91dGluZw==?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:38:04 -0000 Xiaohu, OSPF SR draft clearly states that newly defined Extended Prefix Opaque LSAs do not contribute to the prefix reachability. What you are asking for is to negate that and install forwarding entries based on what is in the EP-LSA, without prefix being advertised in any regular LSA. Once you start to do that you will end up with all sorts of problems. I would like to keep the current definition in place. thanks, Peter On 11/8/13 12:04 , Xuxiaohu wrote: > Hi Peter, > > Sure. However, why not borrow the idea of longest-matching algorithm proposed in that RFC to SR? > > BR, > Xiaohu > > ________________________________________ > ·¢¼þÈË: isis-wg-bounces@ietf.org [isis-wg-bounces@ietf.org] ´ú±í Peter Psenak [ppsenak@cisco.com] > ·¢ËÍʱ¼ä: 2013Äê11ÔÂ9ÈÕ 3:56 > ÊÕ¼þÈË: Xuxiaohu > ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org > Ö÷Ìâ: Re: [Isis-wg] ´ð¸´: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing > > Xiaohu, > > there is no LDP in the SR network, so RFC5283 is not applicable. > > thanks, > Peter > > On 11/7/13 17:28 , Xuxiaohu wrote: >> Hi Peter, >> >> The 'longest-match algorithm' for LIB installation has been proposed by RFC5283. >> >> Best regards, >> Xiaohu >> >> ________________________________________ >> ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] >> ·¢ËÍʱ¼ä: 2013Äê11ÔÂ8ÈÕ 8:39 >> ÊÕ¼þÈË: Xuxiaohu >> ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org >> Ö÷Ìâ: Re: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing >> >> Xiaohu, >> >> On 11/7/13 16:23 , Xuxiaohu wrote: >>> >>> Hi Peter, >> ] >>> if you aggregate on area/L1L2 boundary, SIDs/labels for individual >>> prefixes that are covered by the aggregate are useless in the area to >>> which you aggregate - there will be no FIB entries for these individual >>> prefixes in such area. So if you aggregate, there is no need to >>> propagate SIDs/labels for aggregated prefixes. >>> >>> [Xiaohu] "In the multi-area/level >>> scenario where route summary between areas/levels is required, the IP >>> longest-match algorithm SHOULD be used by SR-capable routers when >>> processing label bindings advertised by the mapping server" For more details, please read the Introduction section of http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00 >> >> I don't understand. If you summarize, then only the summary prefix will >> be visible in the backbone (and remote areas) and installed in the FIB >> on all routers in these areas. >> >> Where would you apply 'longest-match algorithm' when you only see the >> single summary? How would you use the SID/label for prefixes that are >> covered by the summary? >> >> thanks, >> Peter >> > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > From xuxiaohu@huawei.com Fri Nov 8 12:51:21 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798EE11E8112; Fri, 8 Nov 2013 12:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[AWL=-1.811, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLui6SeHYmrc; Fri, 8 Nov 2013 12:51:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9716311E81F3; Fri, 8 Nov 2013 12:50:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR65045; Fri, 08 Nov 2013 20:50:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:50:06 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:50:08 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 04:50:03 +0800 From: Xuxiaohu To: Peter Psenak Thread-Topic: =?gb2312?B?W0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0OiBbT1NQRl0gSW5jb25zaXN0?= =?gb2312?B?ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0ZW50aW9uIGFuZCBJUy1JUyBleHRlbnNp?= =?gb2312?Q?on_for_segment_routing?= Thread-Index: AQHO3MJb+fo8LHY5bUaoeJh35tBeYpobzVgg Date: Fri, 8 Nov 2013 20:50:02 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AEE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com>, <527D4B80.6070308@cisco.com> In-Reply-To: <527D4B80.6070308@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogW0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0?= =?gb2312?b?OiAgSW5jb25zaXN0ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0ZW50aW9uIGFuZCBJ?= =?gb2312?b?Uy1JUyBleHRlbnNpb24gZm9yIHNlZ21lbnQgcm91dGluZw==?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:51:21 -0000 SGkgUGV0ZXIsDQoNCllvdSBtaXN1bmRlcnN0b29kIHdoYXQgSSBoYXZlIHNhaWQuIE9uIHRoZSBj b250cmFyeSwgdGhlIE9TUEYgZXh0ZW5zaW9uIGRyYWZ0IGxvb2tzIGZpbmUgdG8gbWUuIEl0J3Mg dGhlIElTSVMgZXh0ZW5zaW9uIGRyYWZ0IHRoYXQgSSBiZWxpZXZlZCBzaG91bGQgZm9sbG93IHRo ZSBzaW1pbGFyIGFwcHJvYWNoIGRlZmluZWQgaW4gdGhlIE9TUEYgZXh0ZW5zaW9uIGRyYWZ0Lg0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kt6K8/sjLOiBQZXRlciBQc2VuYWsgW3Bwc2VuYWtAY2lzY28uY29tXQ0Kt6LL zcqxvOQ6IDIwMTPE6jEx1MI5yNUgNDozNw0KytW8/sjLOiBYdXhpYW9odQ0Ks63LzTogb3NwZkBp ZXRmLm9yZzsgaXNpcy13Z0BpZXRmLm9yZw0K1vfM4jogUmU6IFtJc2lzLXdnXSC08Li0OiAgtPC4 tDogtPC4tDogW09TUEZdIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BGIGV4dGVudGlvbiBhbmQg SVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJvdXRpbmcNCg0KWGlhb2h1LA0KDQpPU1BGIFNS IGRyYWZ0IGNsZWFybHkgc3RhdGVzIHRoYXQgbmV3bHkgZGVmaW5lZCBFeHRlbmRlZCBQcmVmaXgg T3BhcXVlDQpMU0FzIGRvIG5vdCBjb250cmlidXRlIHRvIHRoZSBwcmVmaXggcmVhY2hhYmlsaXR5 LiBXaGF0IHlvdSBhcmUgYXNraW5nDQpmb3IgaXMgdG8gbmVnYXRlIHRoYXQgYW5kIGluc3RhbGwg Zm9yd2FyZGluZyBlbnRyaWVzIGJhc2VkIG9uIHdoYXQgaXMgaW4NCnRoZSBFUC1MU0EsIHdpdGhv dXQgcHJlZml4IGJlaW5nIGFkdmVydGlzZWQgaW4gYW55IHJlZ3VsYXIgTFNBLiBPbmNlIHlvdQ0K c3RhcnQgdG8gZG8gdGhhdCB5b3Ugd2lsbCBlbmQgdXAgd2l0aCBhbGwgc29ydHMgb2YgcHJvYmxl bXMuIEkgd291bGQNCmxpa2UgdG8ga2VlcCB0aGUgY3VycmVudCBkZWZpbml0aW9uIGluIHBsYWNl Lg0KDQoNCnRoYW5rcywNClBldGVyDQoNCg0KT24gMTEvOC8xMyAxMjowNCAsIFh1eGlhb2h1IHdy b3RlOg0KPiBIaSBQZXRlciwNCj4NCj4gU3VyZS4gSG93ZXZlciwgd2h5IG5vdCBib3Jyb3cgdGhl IGlkZWEgb2YgbG9uZ2VzdC1tYXRjaGluZyBhbGdvcml0aG0gcHJvcG9zZWQgaW4gdGhhdCBSRkMg dG8gU1I/DQo+DQo+IEJSLA0KPiBYaWFvaHUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiC3orz+yMs6IGlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZyBbaXNp cy13Zy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFBldGVyIFBzZW5hayBbcHBzZW5ha0BjaXNjby5j b21dDQo+ILeiy83KsbzkOiAyMDEzxOoxMdTCOcjVIDM6NTYNCj4gytW8/sjLOiBYdXhpYW9odQ0K PiCzrcvNOiBvc3BmQGlldGYub3JnOyBpc2lzLXdnQGlldGYub3JnDQo+INb3zOI6IFJlOiBbSXNp cy13Z10gtPC4tDogtPC4tDogW09TUEZdIEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BGIGV4dGVu dGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJvdXRpbmcNCj4NCj4gWGlhb2h1 LA0KPg0KPiB0aGVyZSBpcyBubyBMRFAgaW4gdGhlIFNSIG5ldHdvcmssIHNvIFJGQzUyODMgaXMg bm90IGFwcGxpY2FibGUuDQo+DQo+IHRoYW5rcywNCj4gUGV0ZXINCj4NCj4gT24gMTEvNy8xMyAx NzoyOCAsIFh1eGlhb2h1IHdyb3RlOg0KPj4gSGkgUGV0ZXIsDQo+Pg0KPj4gVGhlICdsb25nZXN0 LW1hdGNoIGFsZ29yaXRobScgZm9yIExJQiBpbnN0YWxsYXRpb24gaGFzIGJlZW4gcHJvcG9zZWQg YnkgUkZDNTI4My4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBYaWFvaHUNCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiC3orz+yMs6IFBldGVyIFBz ZW5hayBbcHBzZW5ha0BjaXNjby5jb21dDQo+PiC3osvNyrG85DogMjAxM8TqMTHUwjjI1SA4OjM5 DQo+PiDK1bz+yMs6IFh1eGlhb2h1DQo+PiCzrcvNOiBvc3BmQGlldGYub3JnOyBpc2lzLXdnQGll dGYub3JnDQo+PiDW98ziOiBSZTogtPC4tDogW09TUEZdIEluY29uc2lzdGVuY3kgYmV0d2VlbiBP U1BGIGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9uIGZvciBzZWdtZW50IHJvdXRpbmcNCj4+ DQo+PiBYaWFvaHUsDQo+Pg0KPj4gT24gMTEvNy8xMyAxNjoyMyAsIFh1eGlhb2h1IHdyb3RlOg0K Pj4+DQo+Pj4gSGkgUGV0ZXIsDQo+PiBdDQo+Pj4gaWYgeW91IGFnZ3JlZ2F0ZSBvbiBhcmVhL0wx TDIgYm91bmRhcnksIFNJRHMvbGFiZWxzIGZvciBpbmRpdmlkdWFsDQo+Pj4gcHJlZml4ZXMgdGhh dCBhcmUgY292ZXJlZCBieSB0aGUgYWdncmVnYXRlIGFyZSB1c2VsZXNzIGluIHRoZSBhcmVhIHRv DQo+Pj4gd2hpY2ggeW91IGFnZ3JlZ2F0ZSAtIHRoZXJlIHdpbGwgYmUgbm8gRklCIGVudHJpZXMg Zm9yIHRoZXNlIGluZGl2aWR1YWwNCj4+PiBwcmVmaXhlcyBpbiBzdWNoIGFyZWEuIFNvIGlmIHlv dSBhZ2dyZWdhdGUsIHRoZXJlIGlzIG5vIG5lZWQgdG8NCj4+PiBwcm9wYWdhdGUgU0lEcy9sYWJl bHMgZm9yIGFnZ3JlZ2F0ZWQgcHJlZml4ZXMuDQo+Pj4NCj4+PiBbWGlhb2h1XSAiSW4gdGhlIG11 bHRpLWFyZWEvbGV2ZWwNCj4+PiAgICAgICBzY2VuYXJpbyB3aGVyZSByb3V0ZSBzdW1tYXJ5IGJl dHdlZW4gYXJlYXMvbGV2ZWxzIGlzIHJlcXVpcmVkLCB0aGUgSVANCj4+PiAgICAgICBsb25nZXN0 LW1hdGNoIGFsZ29yaXRobSBTSE9VTEQgYmUgdXNlZCBieSBTUi1jYXBhYmxlIHJvdXRlcnMgd2hl bg0KPj4+ICAgICAgIHByb2Nlc3NpbmcgbGFiZWwgYmluZGluZ3MgYWR2ZXJ0aXNlZCBieSB0aGUg bWFwcGluZyBzZXJ2ZXIiIEZvciBtb3JlIGRldGFpbHMsIHBsZWFzZSByZWFkIHRoZSBJbnRyb2R1 Y3Rpb24gc2VjdGlvbiBvZiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1ydGd3 Zy1nbG9iYWwtbGFiZWwtYWR2LTAwDQo+Pg0KPj4gSSBkb24ndCB1bmRlcnN0YW5kLiBJZiB5b3Ug c3VtbWFyaXplLCB0aGVuIG9ubHkgdGhlIHN1bW1hcnkgcHJlZml4IHdpbGwNCj4+IGJlIHZpc2li bGUgaW4gdGhlIGJhY2tib25lIChhbmQgcmVtb3RlIGFyZWFzKSBhbmQgaW5zdGFsbGVkIGluIHRo ZSBGSUINCj4+IG9uIGFsbCByb3V0ZXJzIGluIHRoZXNlIGFyZWFzLg0KPj4NCj4+IFdoZXJlIHdv dWxkIHlvdSBhcHBseSAnbG9uZ2VzdC1tYXRjaCBhbGdvcml0aG0nIHdoZW4geW91IG9ubHkgc2Vl IHRoZQ0KPj4gc2luZ2xlIHN1bW1hcnk/IEhvdyB3b3VsZCB5b3UgdXNlIHRoZSBTSUQvbGFiZWwg Zm9yIHByZWZpeGVzIHRoYXQgYXJlDQo+PiBjb3ZlcmVkIGJ5IHRoZSBzdW1tYXJ5Pw0KPj4NCj4+ IHRoYW5rcywNCj4+IFBldGVyDQo+Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBJc2lzLXdnIG1haWxpbmcgbGlzdA0KPiBJc2lzLXdnQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXNpcy13Zw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJc2lz LXdnIG1haWxpbmcgbGlzdA0KPiBJc2lzLXdnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXNpcy13Zw0KPg== From ppsenak@cisco.com Fri Nov 8 12:58:50 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544E421E8087; Fri, 8 Nov 2013 12:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZs7TTM7Jec3; Fri, 8 Nov 2013 12:58:45 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DC99811E80DC; Fri, 8 Nov 2013 12:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4094; q=dns/txt; s=iport; t=1383944326; x=1385153926; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cCFKYHoX5aaFXKsBAmXs6sRGe2gggLkMlNa/4qdJOfo=; b=DFwa+KgL356Cdc1v5iwIqv9b7xGkzBm0OMX+zZY3IsbVGav2x2xhw+/U HnTCCY1CHEAxIeOLQkTAqKJwWsk7k32Bxt4uscA+ugSzheWkK244swdLG /MMvOIMB9pJKD85vkvfaJTqW0jhYRWlT9gCxPOocqssFkDB+71lCWwTZf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHRPfVKrRDoJ/2dsb2JhbABZgwc4g0e8IoExFnSCJQEBAQQBAQEvATsKARAJAhgEBRYECQIJAwIBAgEVJQsGDQEFAgEBh3wOjn6bWAiSPYEljkIHgmeBSQOJDzOOTYEvhQ6LToFogV8b X-IronPort-AV: E=Sophos;i="4.93,662,1378857600"; d="scan'208";a="96981292" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Nov 2013 20:58:45 +0000 Received: from [10.21.118.82] ([10.21.118.82]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA8KwhfZ020499; Fri, 8 Nov 2013 20:58:43 GMT Message-ID: <527D5083.6070904@cisco.com> Date: Fri, 08 Nov 2013 12:58:43 -0800 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com>, <527D4B80.6070308@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AEE@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AEE@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: Re: [OSPF] =?gb2312?b?tPC4tDogW0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0?= =?gb2312?b?OiAgSW5jb25zaXN0ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0ZW50aW9uIGFuZCBJ?= =?gb2312?b?Uy1JUyBleHRlbnNpb24gZm9yIHNlZ21lbnQgcm91dGluZw==?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:58:50 -0000 Xiaohu, I understand what you started this thread with. What I'm trying to say is that even if OSPF separates the advertisement of prefix and prefix SID/label, you should not be using the SID/label advertisement without the actual prefix reachability advertisement. thanks, Peter On 11/8/13 12:50 , Xuxiaohu wrote: > Hi Peter, > > You misunderstood what I have said. On the contrary, the OSPF extension draft looks fine to me. It's the ISIS extension draft that I believed should follow the similar approach defined in the OSPF extension draft. > > Best regards, > Xiaohu > > ________________________________________ > ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] > ·¢ËÍʱ¼ä: 2013Äê11ÔÂ9ÈÕ 4:37 > ÊÕ¼þÈË: Xuxiaohu > ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org > Ö÷Ìâ: Re: [Isis-wg] ´ð¸´: ´ð¸´: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing > > Xiaohu, > > OSPF SR draft clearly states that newly defined Extended Prefix Opaque > LSAs do not contribute to the prefix reachability. What you are asking > for is to negate that and install forwarding entries based on what is in > the EP-LSA, without prefix being advertised in any regular LSA. Once you > start to do that you will end up with all sorts of problems. I would > like to keep the current definition in place. > > > thanks, > Peter > > > On 11/8/13 12:04 , Xuxiaohu wrote: >> Hi Peter, >> >> Sure. However, why not borrow the idea of longest-matching algorithm proposed in that RFC to SR? >> >> BR, >> Xiaohu >> >> ________________________________________ >> ·¢¼þÈË: isis-wg-bounces@ietf.org [isis-wg-bounces@ietf.org] ´ú±í Peter Psenak [ppsenak@cisco.com] >> ·¢ËÍʱ¼ä: 2013Äê11ÔÂ9ÈÕ 3:56 >> ÊÕ¼þÈË: Xuxiaohu >> ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org >> Ö÷Ìâ: Re: [Isis-wg] ´ð¸´: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing >> >> Xiaohu, >> >> there is no LDP in the SR network, so RFC5283 is not applicable. >> >> thanks, >> Peter >> >> On 11/7/13 17:28 , Xuxiaohu wrote: >>> Hi Peter, >>> >>> The 'longest-match algorithm' for LIB installation has been proposed by RFC5283. >>> >>> Best regards, >>> Xiaohu >>> >>> ________________________________________ >>> ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] >>> ·¢ËÍʱ¼ä: 2013Äê11ÔÂ8ÈÕ 8:39 >>> ÊÕ¼þÈË: Xuxiaohu >>> ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org >>> Ö÷Ìâ: Re: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing >>> >>> Xiaohu, >>> >>> On 11/7/13 16:23 , Xuxiaohu wrote: >>>> >>>> Hi Peter, >>> ] >>>> if you aggregate on area/L1L2 boundary, SIDs/labels for individual >>>> prefixes that are covered by the aggregate are useless in the area to >>>> which you aggregate - there will be no FIB entries for these individual >>>> prefixes in such area. So if you aggregate, there is no need to >>>> propagate SIDs/labels for aggregated prefixes. >>>> >>>> [Xiaohu] "In the multi-area/level >>>> scenario where route summary between areas/levels is required, the IP >>>> longest-match algorithm SHOULD be used by SR-capable routers when >>>> processing label bindings advertised by the mapping server" For more details, please read the Introduction section of http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00 >>> >>> I don't understand. If you summarize, then only the summary prefix will >>> be visible in the backbone (and remote areas) and installed in the FIB >>> on all routers in these areas. >>> >>> Where would you apply 'longest-match algorithm' when you only see the >>> single summary? How would you use the SID/label for prefixes that are >>> covered by the summary? >>> >>> thanks, >>> Peter >>> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >> > From xuxiaohu@huawei.com Fri Nov 8 13:07:36 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19BC21F8FF8; Fri, 8 Nov 2013 13:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[AWL=-1.687, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZOKn7-JBFBU; Fri, 8 Nov 2013 13:07:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B49421E8082; Fri, 8 Nov 2013 13:07:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR65710; Fri, 08 Nov 2013 21:07:24 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 21:07:21 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 21:07:23 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 05:07:17 +0800 From: Xuxiaohu To: Peter Psenak Thread-Topic: =?gb2312?B?tPC4tDogW0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0OiBbT1NQRl0gSW5j?= =?gb2312?B?b25zaXN0ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0ZW50aW9uIGFuZCBJUy1JUyBl?= =?gb2312?Q?xtension_for_segment_routing?= Thread-Index: AQHO3MJb+fo8LHY5bUaoeJh35tBeYpobzVgg//99pICAAIamwA== Date: Fri, 8 Nov 2013 21:07:16 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B32@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com>, <527D4B80.6070308@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AEE@NKGEML512-MBS.china.huawei.com>, <527D5083.6070904@cisco.com> In-Reply-To: <527D5083.6070904@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: [OSPF] =?gb2312?b?tPC4tDogtPC4tDogW0lzaXMtd2ddILTwuLQ6ICC08Li0?= =?gb2312?b?OiC08Li0OiAgSW5jb25zaXN0ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0ZW50aW9u?= =?gb2312?b?IGFuZCBJUy1JUyBleHRlbnNpb24gZm9yIHNlZ21lbnQgcm91dGluZw==?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:07:37 -0000 UGV0ZXIsDQoNCkluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBPU1BGIEVQIExTQXMgY29udGFpbmlu ZyBTSUQvbGFiZWwgYmluZGluZ3MganVzdCBwbGF5IHRoZSByb2xlIG9mIGxhYmVsIGRpc3RyaWJ1 dGlvbiBwcm90b2NvbHMuIFNpbmNlIExEUCBjYW4gc3VwcG9ydCB0aGUgbG9uZ2VzdC1tYXRjaGlu ZyBhbGdvcml0aG0gZm9yIExGSUIgaW5zdGFsbGF0aW9uLCB3aHkgT1NQRiBFUCBMU0FzIGNvdWxk IG5vdCBzdXBwb3J0IHRoYXQgY2FwYWJpbGl0eT8NCg0KQlINClhpYW9odQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IFBldGVyIFBzZW5hayBbcHBz ZW5ha0BjaXNjby5jb21dDQq3osvNyrG85DogMjAxM8TqMTHUwjnI1SA0OjU4DQrK1bz+yMs6IFh1 eGlhb2h1DQqzrcvNOiBvc3BmQGlldGYub3JnOyBpc2lzLXdnQGlldGYub3JnDQrW98ziOiBSZTog tPC4tDogW0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0OiBbT1NQRl0gSW5jb25zaXN0ZW5jeSBi ZXR3ZWVuIE9TUEYgZXh0ZW50aW9uIGFuZCBJUy1JUyBleHRlbnNpb24gZm9yIHNlZ21lbnQgcm91 dGluZw0KDQpYaWFvaHUsDQoNCkkgdW5kZXJzdGFuZCB3aGF0IHlvdSBzdGFydGVkIHRoaXMgdGhy ZWFkIHdpdGguDQoNCldoYXQgSSdtIHRyeWluZyB0byBzYXkgaXMgdGhhdCBldmVuIGlmIE9TUEYg c2VwYXJhdGVzIHRoZSBhZHZlcnRpc2VtZW50DQpvZiBwcmVmaXggYW5kIHByZWZpeCBTSUQvbGFi ZWwsIHlvdSBzaG91bGQgbm90IGJlIHVzaW5nIHRoZSBTSUQvbGFiZWwNCmFkdmVydGlzZW1lbnQg d2l0aG91dCB0aGUgYWN0dWFsIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudC4NCg0K dGhhbmtzLA0KUGV0ZXINCg0KT24gMTEvOC8xMyAxMjo1MCAsIFh1eGlhb2h1IHdyb3RlOg0KPiBI aSBQZXRlciwNCj4NCj4gWW91IG1pc3VuZGVyc3Rvb2Qgd2hhdCBJIGhhdmUgc2FpZC4gT24gdGhl IGNvbnRyYXJ5LCB0aGUgT1NQRiBleHRlbnNpb24gZHJhZnQgbG9va3MgZmluZSB0byBtZS4gSXQn cyB0aGUgSVNJUyBleHRlbnNpb24gZHJhZnQgdGhhdCBJIGJlbGlldmVkIHNob3VsZCBmb2xsb3cg dGhlIHNpbWlsYXIgYXBwcm9hY2ggZGVmaW5lZCBpbiB0aGUgT1NQRiBleHRlbnNpb24gZHJhZnQu DQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBQZXRlciBQc2VuYWsgW3Bwc2VuYWtAY2lz Y28uY29tXQ0KPiC3osvNyrG85DogMjAxM8TqMTHUwjnI1SA0OjM3DQo+IMrVvP7IyzogWHV4aWFv aHUNCj4gs63LzTogb3NwZkBpZXRmLm9yZzsgaXNpcy13Z0BpZXRmLm9yZw0KPiDW98ziOiBSZTog W0lzaXMtd2ddILTwuLQ6ICC08Li0OiC08Li0OiBbT1NQRl0gSW5jb25zaXN0ZW5jeSBiZXR3ZWVu IE9TUEYgZXh0ZW50aW9uIGFuZCBJUy1JUyBleHRlbnNpb24gZm9yIHNlZ21lbnQgcm91dGluZw0K Pg0KPiBYaWFvaHUsDQo+DQo+IE9TUEYgU1IgZHJhZnQgY2xlYXJseSBzdGF0ZXMgdGhhdCBuZXds eSBkZWZpbmVkIEV4dGVuZGVkIFByZWZpeCBPcGFxdWUNCj4gTFNBcyBkbyBub3QgY29udHJpYnV0 ZSB0byB0aGUgcHJlZml4IHJlYWNoYWJpbGl0eS4gV2hhdCB5b3UgYXJlIGFza2luZw0KPiBmb3Ig aXMgdG8gbmVnYXRlIHRoYXQgYW5kIGluc3RhbGwgZm9yd2FyZGluZyBlbnRyaWVzIGJhc2VkIG9u IHdoYXQgaXMgaW4NCj4gdGhlIEVQLUxTQSwgd2l0aG91dCBwcmVmaXggYmVpbmcgYWR2ZXJ0aXNl ZCBpbiBhbnkgcmVndWxhciBMU0EuIE9uY2UgeW91DQo+IHN0YXJ0IHRvIGRvIHRoYXQgeW91IHdp bGwgZW5kIHVwIHdpdGggYWxsIHNvcnRzIG9mIHByb2JsZW1zLiBJIHdvdWxkDQo+IGxpa2UgdG8g a2VlcCB0aGUgY3VycmVudCBkZWZpbml0aW9uIGluIHBsYWNlLg0KPg0KPg0KPiB0aGFua3MsDQo+ IFBldGVyDQo+DQo+DQo+IE9uIDExLzgvMTMgMTI6MDQgLCBYdXhpYW9odSB3cm90ZToNCj4+IEhp IFBldGVyLA0KPj4NCj4+IFN1cmUuIEhvd2V2ZXIsIHdoeSBub3QgYm9ycm93IHRoZSBpZGVhIG9m IGxvbmdlc3QtbWF0Y2hpbmcgYWxnb3JpdGhtIHByb3Bvc2VkIGluIHRoYXQgUkZDIHRvIFNSPw0K Pj4NCj4+IEJSLA0KPj4gWGlhb2h1DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gt6K8/sjLOiBpc2lzLXdnLWJvdW5jZXNAaWV0Zi5vcmcgW2lzaXMt d2ctYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBQZXRlciBQc2VuYWsgW3Bwc2VuYWtAY2lzY28uY29t XQ0KPj4gt6LLzcqxvOQ6IDIwMTPE6jEx1MI5yNUgMzo1Ng0KPj4gytW8/sjLOiBYdXhpYW9odQ0K Pj4gs63LzTogb3NwZkBpZXRmLm9yZzsgaXNpcy13Z0BpZXRmLm9yZw0KPj4g1vfM4jogUmU6IFtJ c2lzLXdnXSC08Li0OiC08Li0OiBbT1NQRl0gSW5jb25zaXN0ZW5jeSBiZXR3ZWVuIE9TUEYgZXh0 ZW50aW9uIGFuZCBJUy1JUyBleHRlbnNpb24gZm9yIHNlZ21lbnQgcm91dGluZw0KPj4NCj4+IFhp YW9odSwNCj4+DQo+PiB0aGVyZSBpcyBubyBMRFAgaW4gdGhlIFNSIG5ldHdvcmssIHNvIFJGQzUy ODMgaXMgbm90IGFwcGxpY2FibGUuDQo+Pg0KPj4gdGhhbmtzLA0KPj4gUGV0ZXINCj4+DQo+PiBP biAxMS83LzEzIDE3OjI4ICwgWHV4aWFvaHUgd3JvdGU6DQo+Pj4gSGkgUGV0ZXIsDQo+Pj4NCj4+ PiBUaGUgJ2xvbmdlc3QtbWF0Y2ggYWxnb3JpdGhtJyBmb3IgTElCIGluc3RhbGxhdGlvbiBoYXMg YmVlbiBwcm9wb3NlZCBieSBSRkM1MjgzLg0KPj4+DQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+IFhp YW9odQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+ILeivP7IyzogUGV0ZXIgUHNlbmFrIFtwcHNlbmFrQGNpc2NvLmNvbV0NCj4+PiC3osvNyrG8 5DogMjAxM8TqMTHUwjjI1SA4OjM5DQo+Pj4gytW8/sjLOiBYdXhpYW9odQ0KPj4+ILOty806IG9z cGZAaWV0Zi5vcmc7IGlzaXMtd2dAaWV0Zi5vcmcNCj4+PiDW98ziOiBSZTogtPC4tDogW09TUEZd IEluY29uc2lzdGVuY3kgYmV0d2VlbiBPU1BGIGV4dGVudGlvbiBhbmQgSVMtSVMgZXh0ZW5zaW9u IGZvciBzZWdtZW50IHJvdXRpbmcNCj4+Pg0KPj4+IFhpYW9odSwNCj4+Pg0KPj4+IE9uIDExLzcv MTMgMTY6MjMgLCBYdXhpYW9odSB3cm90ZToNCj4+Pj4NCj4+Pj4gSGkgUGV0ZXIsDQo+Pj4gXQ0K Pj4+PiBpZiB5b3UgYWdncmVnYXRlIG9uIGFyZWEvTDFMMiBib3VuZGFyeSwgU0lEcy9sYWJlbHMg Zm9yIGluZGl2aWR1YWwNCj4+Pj4gcHJlZml4ZXMgdGhhdCBhcmUgY292ZXJlZCBieSB0aGUgYWdn cmVnYXRlIGFyZSB1c2VsZXNzIGluIHRoZSBhcmVhIHRvDQo+Pj4+IHdoaWNoIHlvdSBhZ2dyZWdh dGUgLSB0aGVyZSB3aWxsIGJlIG5vIEZJQiBlbnRyaWVzIGZvciB0aGVzZSBpbmRpdmlkdWFsDQo+ Pj4+IHByZWZpeGVzIGluIHN1Y2ggYXJlYS4gU28gaWYgeW91IGFnZ3JlZ2F0ZSwgdGhlcmUgaXMg bm8gbmVlZCB0bw0KPj4+PiBwcm9wYWdhdGUgU0lEcy9sYWJlbHMgZm9yIGFnZ3JlZ2F0ZWQgcHJl Zml4ZXMuDQo+Pj4+DQo+Pj4+IFtYaWFvaHVdICJJbiB0aGUgbXVsdGktYXJlYS9sZXZlbA0KPj4+ PiAgICAgICAgc2NlbmFyaW8gd2hlcmUgcm91dGUgc3VtbWFyeSBiZXR3ZWVuIGFyZWFzL2xldmVs cyBpcyByZXF1aXJlZCwgdGhlIElQDQo+Pj4+ICAgICAgICBsb25nZXN0LW1hdGNoIGFsZ29yaXRo bSBTSE9VTEQgYmUgdXNlZCBieSBTUi1jYXBhYmxlIHJvdXRlcnMgd2hlbg0KPj4+PiAgICAgICAg cHJvY2Vzc2luZyBsYWJlbCBiaW5kaW5ncyBhZHZlcnRpc2VkIGJ5IHRoZSBtYXBwaW5nIHNlcnZl ciIgRm9yIG1vcmUgZGV0YWlscywgcGxlYXNlIHJlYWQgdGhlIEludHJvZHVjdGlvbiBzZWN0aW9u IG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXJ0Z3dnLWdsb2JhbC1sYWJl bC1hZHYtMDANCj4+Pg0KPj4+IEkgZG9uJ3QgdW5kZXJzdGFuZC4gSWYgeW91IHN1bW1hcml6ZSwg dGhlbiBvbmx5IHRoZSBzdW1tYXJ5IHByZWZpeCB3aWxsDQo+Pj4gYmUgdmlzaWJsZSBpbiB0aGUg YmFja2JvbmUgKGFuZCByZW1vdGUgYXJlYXMpIGFuZCBpbnN0YWxsZWQgaW4gdGhlIEZJQg0KPj4+ IG9uIGFsbCByb3V0ZXJzIGluIHRoZXNlIGFyZWFzLg0KPj4+DQo+Pj4gV2hlcmUgd291bGQgeW91 IGFwcGx5ICdsb25nZXN0LW1hdGNoIGFsZ29yaXRobScgd2hlbiB5b3Ugb25seSBzZWUgdGhlDQo+ Pj4gc2luZ2xlIHN1bW1hcnk/IEhvdyB3b3VsZCB5b3UgdXNlIHRoZSBTSUQvbGFiZWwgZm9yIHBy ZWZpeGVzIHRoYXQgYXJlDQo+Pj4gY292ZXJlZCBieSB0aGUgc3VtbWFyeT8NCj4+Pg0KPj4+IHRo YW5rcywNCj4+PiBQZXRlcg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IElzaXMtd2cgbWFpbGluZyBsaXN0DQo+PiBJc2lzLXdn QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lzaXMt d2cNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBJc2lzLXdnIG1haWxpbmcgbGlzdA0KPj4gSXNpcy13Z0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pc2lzLXdnDQo+Pg0KPg== From ppsenak@cisco.com Fri Nov 8 13:14:34 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65F221E808D; Fri, 8 Nov 2013 13:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.034 X-Spam-Level: X-Spam-Status: No, score=-4.034 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCw1v2QewjbL; Fri, 8 Nov 2013 13:14:30 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5021E8087; Fri, 8 Nov 2013 13:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5110; q=dns/txt; s=iport; t=1383945270; x=1385154870; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=I6f3p+a34JcjJqFOpW2N+ClKlSebViT1J6x6MLsWdoM=; b=T5NqKNtxCZ3MjhcT83W5MhMZjNh0cIXfFX2W+LTt/ysEoxBm05hJMZ4Q 4VrNosSw2rAgKqWaCcD2dQWvlO0RIF5VKMzJeb0iASuP8S+WXarb2Pfb9 uEBSpxQ6zatYoBABG0ujD4LN0KFzWJox5NXm8uaIgiWvuPJNsn7ME23qs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPRSfVKrRDoG/2dsb2JhbABZgwc4g0e8IoExFnSCJQEBAQMBAQEBLwE7CgEQCQIYBAUWBAkCCQMCAQIBFSULBg0BBQIBAYd3BQ6PAJtYCJI9gSWOQgeCZ4FJA4kPM45NgS+FDotOgWiBXxs X-IronPort-AV: E=Sophos;i="4.93,662,1378857600"; d="scan'208";a="96982649" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Nov 2013 21:14:30 +0000 Received: from [10.21.118.82] ([10.21.118.82]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA8LES79001691; Fri, 8 Nov 2013 21:14:28 GMT Message-ID: <527D5434.3010201@cisco.com> Date: Fri, 08 Nov 2013 13:14:28 -0800 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com>, <527D4B80.6070308@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AEE@NKGEML512-MBS.china.huawei.com>, <527D5083.6070904@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B32@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B32@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "ospf@ietf.org" , "isis-wg@ietf.org" Subject: Re: [OSPF] =?gb2312?b?W0lzaXMtd2ddILTwuLQ6ILTwuLQ6ICC08Li0OiAgtPA=?= =?gb2312?b?uLQ6ILTwuLQ6ICBJbmNvbnNpc3RlbmN5IGJldHdlZW4gT1NQRiBleHRlbnRp?= =?gb2312?b?b24gYW5kIElTLUlTIGV4dGVuc2lvbiBmb3Igc2VnbWVudCByb3V0aW5n?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:14:35 -0000 Xiaohu, On 11/8/13 13:07 , Xuxiaohu wrote: > Peter, > > In my understanding, the OSPF EP LSAs containing SID/label bindings just play the role of label distribution protocols. Since LDP can support the longest-matching algorithm for LFIB installation, why OSPF EP LSAs could not support that capability? because we do not want OSPF EP LSAs to do what you want to use it for. thanks, Peter > > BR > Xiaohu > > ________________________________________ > ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] > ·¢ËÍʱ¼ä: 2013Äê11ÔÂ9ÈÕ 4:58 > ÊÕ¼þÈË: Xuxiaohu > ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org > Ö÷Ìâ: Re: ´ð¸´: [Isis-wg] ´ð¸´: ´ð¸´: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing > > Xiaohu, > > I understand what you started this thread with. > > What I'm trying to say is that even if OSPF separates the advertisement > of prefix and prefix SID/label, you should not be using the SID/label > advertisement without the actual prefix reachability advertisement. > > thanks, > Peter > > On 11/8/13 12:50 , Xuxiaohu wrote: >> Hi Peter, >> >> You misunderstood what I have said. On the contrary, the OSPF extension draft looks fine to me. It's the ISIS extension draft that I believed should follow the similar approach defined in the OSPF extension draft. >> >> Best regards, >> Xiaohu >> >> ________________________________________ >> ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] >> ·¢ËÍʱ¼ä: 2013Äê11ÔÂ9ÈÕ 4:37 >> ÊÕ¼þÈË: Xuxiaohu >> ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org >> Ö÷Ìâ: Re: [Isis-wg] ´ð¸´: ´ð¸´: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing >> >> Xiaohu, >> >> OSPF SR draft clearly states that newly defined Extended Prefix Opaque >> LSAs do not contribute to the prefix reachability. What you are asking >> for is to negate that and install forwarding entries based on what is in >> the EP-LSA, without prefix being advertised in any regular LSA. Once you >> start to do that you will end up with all sorts of problems. I would >> like to keep the current definition in place. >> >> >> thanks, >> Peter >> >> >> On 11/8/13 12:04 , Xuxiaohu wrote: >>> Hi Peter, >>> >>> Sure. However, why not borrow the idea of longest-matching algorithm proposed in that RFC to SR? >>> >>> BR, >>> Xiaohu >>> >>> ________________________________________ >>> ·¢¼þÈË: isis-wg-bounces@ietf.org [isis-wg-bounces@ietf.org] ´ú±í Peter Psenak [ppsenak@cisco.com] >>> ·¢ËÍʱ¼ä: 2013Äê11ÔÂ9ÈÕ 3:56 >>> ÊÕ¼þÈË: Xuxiaohu >>> ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org >>> Ö÷Ìâ: Re: [Isis-wg] ´ð¸´: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing >>> >>> Xiaohu, >>> >>> there is no LDP in the SR network, so RFC5283 is not applicable. >>> >>> thanks, >>> Peter >>> >>> On 11/7/13 17:28 , Xuxiaohu wrote: >>>> Hi Peter, >>>> >>>> The 'longest-match algorithm' for LIB installation has been proposed by RFC5283. >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>> ________________________________________ >>>> ·¢¼þÈË: Peter Psenak [ppsenak@cisco.com] >>>> ·¢ËÍʱ¼ä: 2013Äê11ÔÂ8ÈÕ 8:39 >>>> ÊÕ¼þÈË: Xuxiaohu >>>> ³­ËÍ: ospf@ietf.org; isis-wg@ietf.org >>>> Ö÷Ìâ: Re: ´ð¸´: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing >>>> >>>> Xiaohu, >>>> >>>> On 11/7/13 16:23 , Xuxiaohu wrote: >>>>> >>>>> Hi Peter, >>>> ] >>>>> if you aggregate on area/L1L2 boundary, SIDs/labels for individual >>>>> prefixes that are covered by the aggregate are useless in the area to >>>>> which you aggregate - there will be no FIB entries for these individual >>>>> prefixes in such area. So if you aggregate, there is no need to >>>>> propagate SIDs/labels for aggregated prefixes. >>>>> >>>>> [Xiaohu] "In the multi-area/level >>>>> scenario where route summary between areas/levels is required, the IP >>>>> longest-match algorithm SHOULD be used by SR-capable routers when >>>>> processing label bindings advertised by the mapping server" For more details, please read the Introduction section of http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00 >>>> >>>> I don't understand. If you summarize, then only the summary prefix will >>>> be visible in the backbone (and remote areas) and installed in the FIB >>>> on all routers in these areas. >>>> >>>> Where would you apply 'longest-match algorithm' when you only see the >>>> single summary? How would you use the SID/label for prefixes that are >>>> covered by the summary? >>>> >>>> thanks, >>>> Peter >>>> >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >> > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > From delia.kecskemeti@windriver.com Fri Nov 8 14:25:14 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46A211E80DE for ; Fri, 8 Nov 2013 14:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL8cwS2nUgmO for ; Fri, 8 Nov 2013 14:25:08 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by ietfa.amsl.com (Postfix) with ESMTP id 89A8611E80FB for ; Fri, 8 Nov 2013 14:25:08 -0800 (PST) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id rA8MP7Hl021346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Nov 2013 14:25:07 -0800 (PST) Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.135]) by ALA-HCB.corp.ad.wrs.com ([147.11.189.41]) with mapi id 14.02.0347.000; Fri, 8 Nov 2013 14:25:07 -0800 From: "Kecskemeti, Delia" To: "ospf@ietf.org" Thread-Topic: In OSPFv3 are a router's own host routes or loopback routes propagated across area boundary? Thread-Index: Ac7c0SI0gqO+JBtkSEGB68j2Q0kyOg== Date: Fri, 8 Nov 2013 22:25:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.224.146.218] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] In OSPFv3 are a router's own host routes or loopback routes propagated across area boundary? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 22:25:15 -0000 Hi In OSPFv3 are a router's own host routes or loopback routes propagated acro= ss area boundary? What happens to a router's prefixes listed in its intra-area LSAs at area b= oundary, are they visible / accessible from the rest of areas? Does the ABR describe them into the adjacent area in inter-area prefix LSA = (maybe with LA options bit set and prefix length 128) or not? That is after the SPF computation, for a routing table entry that describes= a router and its set of prefixes, are those prefixes copied into an intera= rea LSA for distribution into adjacent areas? Or are they considered the same as link local addresses and never distribut= ed beyond the area via inter-area prefix LSAs? Thank you =20 Delia Kecskemeti, MTS direct 613.270.2281 fax 613.592.2283 From acee.lindem@ericsson.com Sat Nov 9 12:36:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC09311E8175 for ; Sat, 9 Nov 2013 12:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc0MoIgZQZ7y for ; Sat, 9 Nov 2013 12:36:18 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 785BB11E80F9 for ; Sat, 9 Nov 2013 12:36:17 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-d7-527e9cbf871c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 05.FA.04556.FBC9E725; Sat, 9 Nov 2013 21:36:15 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Sat, 9 Nov 2013 15:36:09 -0500 From: Acee Lindem To: David Lamparter , OSPF List Thread-Topic: [OSPF] OSPFv3 E-LSA compatibility cases Thread-Index: AQHO3Auypltug3S4WU+oA/IPU8rhnZob1R2A Date: Sat, 9 Nov 2013 20:36:09 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> In-Reply-To: <20131107224952.GW4891@spaceboyz.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPuO7+OXVBBivaFSzWNG5gtmi5d4/d gcnjy14pjyVLfjIFMEVx2aSk5mSWpRbp2yVwZcy4NZe94Lthxdvnv5gaGD+odTFyckgImEg8 njyfFcIWk7hwbz1bFyMXh5DAEUaJrkudLBDOMkaJ9/ufMoJUsQnoSDx/9I8ZxBYRcJaYfOc1 WFwYaNKVaZtZIeKmEq8fH2KCsI0kHk/7ARZnEVCRWPL0PNAGDg5eAV+JNbNqQMKcQCUfmm6x gdiMQEd8P7UGrJVZQFzi1pP5TBDHCUgs2XOeGcIWlXj5+B/YSFEBPYnuWcuhHlCWWPJkPwtE r47Egt2f2CBsa4n9Kw9DzdSWWLbwNdgcXgFBiZMzn7BMYBSbhWTdLCTts5C0z0LSPgtJ+wJG 1lWMHKXFqWW56UaGmxiBsXNMgs1xB+OCT5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwCjxi9Np74VWzvvON120HXcbukQnOEpxBv3QCRT/8fnoB5Mkrr97qyUc1vqW lGbdYchyrP374CGnwjMXXUZmCV/5Ey3y7Vc/ZOmsFnyyrPxy+ByGeWvlM+95551b2X/z4Qyu R3wm5lHZ8j7yt0z5Tlf6xYq8fHM2uPmCg9ds5aUzC55v4EwvUGIpzkg01GIuKk4EAEOJEcVr AgAA Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 20:36:23 -0000 Hi David,=20 On 11/7/13 2:49 PM, "David Lamparter" wrote: >Hi ospf WG, > > >since most of the stuff being presented in the WG is beyond what I can >do for Quagga, I've used the time to type up an overview for E-LSA >compatibility scenarios. Quite possibly I've made a lot of mistakes. >Anyway here it goes. > >-David > > > >Compatibility mechanic A - 3 states, mixed LSA use >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >Assumes "fallback" LSA lookups, where routers may use the combined set >of E-LSAs and LSAs for calculation. (E-LSAs should probably supersede >equivalent LSAs in that case, just to get determinism.) > >- 0 (old) 1 (mixed) 2 (new) >- >- use use >E-LSAs advertise advertise >- - - - - - - - - - - - - - - - - - - - - - - - - - - >LSAs advertise advertise >- use use > >The only invalid combination is 0/1/2. This is detectable by all >routers when they see both a Router LSA without a matching E-LSA _and_ a >Router E-LSA without a matching LSA. (Except in the multi-area case.) >The routers detecting this could exclude themselves from the domain on >detecting this, but they can only detect this after getting the entire >database. For mixed mode, there are two variants. The latest variation is where one where you advertise both the LSAs and E-LSAs but only use the LSAs. > >On the adjacency level, 0 - 1 - 1 - 2 cannot be detected as each router >only sees a valid combination. > >If there is distributed knowledge about mode-1 capability, automatically >degrading the OSPF domain from mode-2 to mode-1 after seeing a mode-0 >router is possible. (If this downgrade capability is enabled and >signaled by all routers.) > >Use of the U bit in this case allows other mode-1 routers to get (and >use) the E-LSA versions of LSAs even if they're isolated by mode-0 >routers from the originator. > >The downside is that mixing LSA types opens really nice ways of messing >it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously. >Also, race conditions may start popping up if LSAs arrive from flooding >before E-LSAs. Either way, if a router is identified as E-LSA capable, >LSAs originated by it should never be used by mode-1 routers. I'm not so worried about bugs as I am about carrying the complexity of mixed-mode LSA complexity forever. If you need to use both LSA types in the SPF computation, you will have more overhead. I'm inclined to always use the OLD, aka, LSAs for the SPF computation if any backward compatibility mode is configured. > >It may also make sense to specify that mode-1 routers must flood >associated LSAs and E-LSAs simultaneously. That would be desirable but I don't think we want to change OSPF flooding behavior to require lock step flooding of both LSAs simultaneously, e.g., if you update a stale instance of an LSA, requiring E-LSA reorigination as well.=20 > > >Compatibility mechanic B - 4 states, no mixed LSA use >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >Assumes strict restriction to using only one type of LSAs on any single >particular router. Different routers may be in different modes and >therefore >be using different LSA types in their calculations. > >- 0 (old) 1 (degraded) 2 (mixed) 3 (new) >- >- use use >E-LSAs advertise advertise advertise >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >LSAs advertise advertise advertise >- use use > >A valid, working combination is composed of two neighboring of those >modes. 0/1/2 doesn't work because mode-2 routers won't see mode-0 >routers, similarly 1/2/3 won't work because mode-1 routers won't see >mode-3 routers. Folding up modes 1 & 2 into one mode isn't possible >without mixing LSA types in calculations. > >Enforcing valid, working combinations at the adjacency level can't >detect misconfigurations like 1 - 2 - 2 - 3. The simplest thing to make >this detectable on all "new" routers is probably including a TLV in the >Router E-LSA that indicates modes 1 or 2. (Mode 0 is a plain old Router >LSA and mode-3 is a Router E-LSA without the TLV.) > >Combination 0,1,2 can also be detected by mode-2 routers (and mode-2 >routers only) when they see a Router LSA without a matching Router >E-LSA. Combination 1,2,3 can be detected by mode-1 routers (only) when >they see a Router E-LSA without a matching Router LSA. The routers >detecting this could exclude themselves from the domain on detecting >this, but they can only detect this after getting the entire database. >NB: mode-3 routers can _not_ assume misconfiguration on seeing >old-style LSAs since they might be originated by mode-2 routers, which >is a valid configuration. Any router can detect a 0/1/2/3 >mixture/misconfiguration. (Again, except in a multi-area case.) > >[no suggestions on what to do after detecting the misconfiguration, a >red blinking LED and a buzzer seem appropriate to me. Automatic >downgrades are certainly possible, but quite a bit more complicated than >in case A before.] I like the idea of recommending detection and notification of the network operator. However I do not like the idea of taking any radical protocol action.=20 Thanks,=20 Acee=20 > >Note that use of the U bit on E-LSAs is not neccessary in this case. >Either the domain consists of routers in modes 0/1 and it doesn't matter >if the E-LSAs get distributed or not (because they're not used), or >there are no mode-0 routers, meaning all routers distribute E-LSAs >anyway. It does affect misconfiguration detection though. > >Overall, this seems more complex, but then again it provides robustness >against accidental or malicious LSA<>E-LSA mismatches. >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From equinox@spaceboyz.net Sat Nov 9 13:17:27 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B163F21F9FF6 for ; Sat, 9 Nov 2013 13:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEU6sDb-0Rvo for ; Sat, 9 Nov 2013 13:17:27 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3A21F9FBA for ; Sat, 9 Nov 2013 13:17:26 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1VfFuG-0006fs-1L; Sat, 09 Nov 2013 22:17:24 +0100 Date: Sat, 9 Nov 2013 22:17:24 +0100 From: David Lamparter To: Acee Lindem Message-ID: <20131109211723.GE5311@spaceboyz.net> References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: OSPF List Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 21:17:27 -0000 On Sat, Nov 09, 2013 at 08:36:09PM +0000, Acee Lindem wrote: > On 11/7/13 2:49 PM, "David Lamparter" wrote: > >The downside is that mixing LSA types opens really nice ways of messing > >it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously. > >Also, race conditions may start popping up if LSAs arrive from flooding > >before E-LSAs. Either way, if a router is identified as E-LSA capable, > >LSAs originated by it should never be used by mode-1 routers. > > I'm not so worried about bugs as I am about carrying the complexity of > mixed-mode LSA complexity forever. If you need to use both LSA types in > the SPF computation, you will have more overhead. I'm inclined to always > use the OLD, aka, LSAs for the SPF computation if any backward > compatibility mode is configured. [- Unless I'm overlooking something somewhere:] The problem with an old-only compatibility mode is moving from backward compatibility to native E-LSA only operation. Assume you have a network where all routers are in compatibility mode, using old LSAs only but advertising both. Now move one router to native mode. Unless the other routers consider the E-LSAs of that router, it will effectively vanish for them at that point. As a result of this, any operation with 3 modes (old,compat,new) requires mixing of LSA types in SPF calculation. In the presence of both, either can be preferred. Also, as a result from the mixing, any 3-mode compat can exhibit LSA<>E-LSA mismatch problems. For not mixing LSA types in calc, a total of 4 modes are required. Mismatches can still occur - when the middle 2 modes are used. But then again, that should only ever occur while moving from compat to native. Personally, 4-mode seems cleaner to me, but I don't have a strong opinion either way (and lack a foundation to build a strong opinion on.) -David From acee.lindem@ericsson.com Sat Nov 9 13:44:24 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE51811E8192 for ; Sat, 9 Nov 2013 13:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlmggsRuFh0S for ; Sat, 9 Nov 2013 13:44:19 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0C11E8189 for ; Sat, 9 Nov 2013 13:44:18 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-13-527eacb110ea Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D4.F4.04556.1BCAE725; Sat, 9 Nov 2013 22:44:17 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Sat, 9 Nov 2013 16:44:17 -0500 From: Acee Lindem To: "Kecskemeti, Delia" , "ospf@ietf.org" Thread-Topic: [OSPF] In OSPFv3 are a router's own host routes or loopback routes propagated across area boundary? Thread-Index: Ac7c0SI0gqO+JBtkSEGB68j2Q0kyOgAqo2QA Date: Sat, 9 Nov 2013 21:44:16 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030D9549@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <664145C7425E8D4593BBF4CBB7FD5A76@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPrO7GNXVBBp/nWVl8bLzJatFy7x67 A5PHkiU/mTzWb9nKFMAUxWWTkpqTWZZapG+XwJVxZV5xQR9XxYQrK1kbGNdwdDFyckgImEg8 mDWLEcIWk7hwbz1bFyMXh5DAEUaJ9t9HmSCcZYwSs7ceYgepYhPQkXj+6B8ziC0iEC3x8uo/ JhBbWKBI4uLmDUCTOIDixRI7nhlBlBhJHGl8zwZiswioSLx6dQvM5hXwlTj07zLYGE4Bf4n/ G1+A2YxAR3w/tQZsJLOAuMStJ/OZII4TkFiy5zwzhC0q8fLxP1YQW1RAT6J71nJWiLiyxJIn +1kgenUkFuz+xAZhW0v8eD+BGcLWlli28DUzxA2CEidnPmGZwCg2C8m6WUjaZyFpn4WkfRaS 9gWMrKsYOUqLU8ty040MNzECY+eYBJvjDsYFnywPMUpzsCiJ83556xwkJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgTH4R7Df1bD9DuYX995Zc+ad54Psh/vmF1d7nXA+8u9cQ/WvBr/6dtlz TC2HY89fU5Kbkchy7z1rSuNuHfcDM5d7KidXSG67v+1nt4zyPIPc3ev9RBZylm74s62Z9fo6 LjnpfREC7Y8m61taOO1l1H7oarJxocEOf6F71cwSUVZ/TtTO2nJzr64SS3FGoqEWc1FxIgCb LfaPawIAAA== Subject: Re: [OSPF] In OSPFv3 are a router's own host routes or loopback routes propagated across area boundary? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 21:44:25 -0000 Hi Delia,=20 See inline.=20 On 11/8/13 2:25 PM, "Kecskemeti, Delia" wrote: >Hi > >In OSPFv3 are a router's own host routes or loopback routes propagated >across area boundary? >What happens to a router's prefixes listed in its intra-area LSAs at area >boundary, are they visible / accessible from the rest of areas? >Does the ABR describe them into the adjacent area in inter-area prefix >LSA (maybe with LA options bit set and prefix length 128) or not? >That is after the SPF computation, for a routing table entry that >describes a router and its set of prefixes, are those prefixes copied >into an interarea LSA for distribution into adjacent areas? They are advertised in an inter-area-prefix-LSAs like any other intra-area OSPFv3 route. The prefix options for the intra-area-prefix-LSA are not propagated to the inter-area-LSAs. Hence, the LA-bit will not be set. Thanks, Acee=20 >Or are they considered the same as link local addresses and never >distributed beyond the area via inter-area prefix LSAs? > >Thank you =20 > >Delia Kecskemeti, MTS >direct 613.270.2281 fax 613.592.2283 >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From delia.kecskemeti@windriver.com Sat Nov 9 15:39:39 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9692A21E8096 for ; Sat, 9 Nov 2013 15:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLBrXtWctri7 for ; Sat, 9 Nov 2013 15:39:32 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by ietfa.amsl.com (Postfix) with ESMTP id E0F1921E8082 for ; Sat, 9 Nov 2013 15:39:17 -0800 (PST) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id rA9Nd8GY004848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Nov 2013 15:39:08 -0800 (PST) Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.135]) by ALA-HCB.corp.ad.wrs.com ([147.11.189.41]) with mapi id 14.02.0347.000; Sat, 9 Nov 2013 15:39:08 -0800 From: "Kecskemeti, Delia" To: Acee Lindem , "ospf@ietf.org" Thread-Topic: [OSPF] In OSPFv3 are a router's own host routes or loopback routes propagated across area boundary? Thread-Index: Ac7c0SI0gqO+JBtkSEGB68j2Q0kyOgAqo2QAAAoq3AA= Date: Sat, 9 Nov 2013 23:39:06 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE47030D9549@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030D9549@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.11.118.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] In OSPFv3 are a router's own host routes or loopback routes propagated across area boundary? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 23:39:39 -0000 Great, thank you very much Acee,=20 Very much appreciated All the best Delia Kecskemeti, MTS direct 613.270.2281 fax 613.592.2283 -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Saturday, November 09, 2013 4:44 PM To: Kecskemeti, Delia; ospf@ietf.org Subject: Re: [OSPF] In OSPFv3 are a router's own host routes or loopback ro= utes propagated across area boundary? Hi Delia, See inline.=20 On 11/8/13 2:25 PM, "Kecskemeti, Delia" wrote: >Hi > >In OSPFv3 are a router's own host routes or loopback routes propagated=20 >across area boundary? >What happens to a router's prefixes listed in its intra-area LSAs at=20 >area boundary, are they visible / accessible from the rest of areas? >Does the ABR describe them into the adjacent area in inter-area prefix=20 >LSA (maybe with LA options bit set and prefix length 128) or not? >That is after the SPF computation, for a routing table entry that=20 >describes a router and its set of prefixes, are those prefixes copied=20 >into an interarea LSA for distribution into adjacent areas? They are advertised in an inter-area-prefix-LSAs like any other intra-area OSPFv3 route. The prefix options for the intra-area-prefix-LSA are not prop= agated to the inter-area-LSAs. Hence, the LA-bit will not be set. Thanks, Acee=20 >Or are they considered the same as link local addresses and never=20 >distributed beyond the area via inter-area prefix LSAs? > >Thank you > >Delia Kecskemeti, MTS >direct 613.270.2281 fax 613.592.2283 >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From prz@mail.zeta2.ch Sun Nov 10 01:59:56 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850E521E8083 for ; Sun, 10 Nov 2013 01:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXo50BKJVrx2 for ; Sun, 10 Nov 2013 01:59:51 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 174B921E8098 for ; Sun, 10 Nov 2013 01:59:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAA9xhDi014335 for ; Sun, 10 Nov 2013 10:59:43 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id khnhiP6DWqDH for ; Sun, 10 Nov 2013 10:59:42 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAA9xc8s014330 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 10 Nov 2013 10:59:40 +0100 Message-ID: <527F590A.4080108@zeta2.ch> Date: Sun, 10 Nov 2013 10:59:38 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ospf@ietf.org References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> In-Reply-To: <20131109211723.GE5311@spaceboyz.net> Content-Type: multipart/mixed; boundary="------------020901020500060708080807" Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 09:59:56 -0000 This is a multi-part message in MIME format. --------------020901020500060708080807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/09/2013 10:17 PM, David Lamparter wrote: > On Sat, Nov 09, 2013 at 08:36:09PM +0000, Acee Lindem wrote: >> On 11/7/13 2:49 PM, "David Lamparter" wrote: >>> The downside is that mixing LSA types opens really nice ways of messing >>> it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously. >>> Also, race conditions may start popping up if LSAs arrive from flooding >>> before E-LSAs. Either way, if a router is identified as E-LSA capable, >>> LSAs originated by it should never be used by mode-1 routers. >> I'm not so worried about bugs as I am about carrying the complexity of >> mixed-mode LSA complexity forever. If you need to use both LSA types in >> the SPF computation, you will have more overhead. I'm inclined to always >> use the OLD, aka, LSAs for the SPF computation if any backward >> compatibility mode is configured. > zipped through the draft-ietf-ospf-ospfv3-lsa-extend-00.txt draft & it's surely all an interesting new rathole ;-) Approach is intriguing and commendable per se but as the 'mixed' stuff goes I second Acee that this kind of 'mixed-modes' _never_ go away and people drag on huge amounts of complex code long after the original stuff is obsolete. Though, yes, a mixed mode is normally necessary for a while since 'flag' days don't exist anymore for stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated over-nite for better or for worse. But back to this draft. So, as first, I think 12.1 section is overly complicated and will lead to many interesting disasters with all those 'mixed' and 'degraded' modes especially if SPF starts to be mucked with. But as second and worse, 12.1 is crippling the E-LSA proposal big time since if you have semantically completely new things in the new E-LSA TLVs (which after all is THE purpose of doing it), they may not encode into old style TLVs and so you can't issue them or otherwise you 'lie' and may create routing loops in a 'mixed' mode since you cannot decide when forwarding a packet whether it came from an 'old' router or a 'new' router. The 'new' router may understand it would create a loop based on E-TLV information only but the old router won't have it and throw the packet at you. You would forward using the 'new' info. If that is not intuitively clear, I can bring some sketches. The crux of all this has been actually the reason for multi-topology. After we looked into the math we realized you 'cannot' simply mix some new format with new info into a domain and expect loop-free-hop-by-hop. So, you can solve this only by running a multi-topology approach then (i.e. running SPF per E-TLV and TLV topology in your TDB). Or otherwise the new format is just lip-stick, it will semantcially never leave the restrictions of the old fixed format since it cannot add information. In summary, unless you want to take a 'multi-toopology' approach (which has been solved and it would mean E-LSAs are basically a new format in a new topology or you may choose to think about it as a completely new protocol engulfing the old one) I think you will have to abandon all those 'degrade/mixed/unmixed' stuff and simply fall back to old format each time you see a router with EL bit cleared, i.e. you have to migrate whole area until E-TLVs kick in. This will allow for E-TLVs to be the real flexible TLV new format with possibly new information influencing SPF you're seeking. --- tony --------------020901020500060708080807 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------020901020500060708080807-- From ppsenak@cisco.com Sun Nov 10 02:29:48 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E08721E80C4 for ; Sun, 10 Nov 2013 02:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjhFucLjdT8w for ; Sun, 10 Nov 2013 02:29:43 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD411E80E0 for ; Sun, 10 Nov 2013 02:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4546; q=dns/txt; s=iport; t=1384079383; x=1385288983; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OYzID2dcSQAL/lP6PDIAO/cZ2K52i+OYjLTqydE1GUI=; b=AEZ/ZGBlzSSmqhWZccvdVKPYSoJX7ez+K++LRimQYdRsI8eXQNOLaal4 v1Q7ntytknZufVYSgYwJshygqeT33t8bmckJCha58NRNSUDp3BVrKef25 p5HzBeIQgWoViIKfdtCefKvFEFtZK+lUoFhuAqjBa4iKcXowivyG6c8YX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAA9ff1KQ/khM/2dsb2JhbABYgwc4v2KBJxZ0giUBAQEDAQEBATU2CgEFCwsYCRYPCQMCAQIBFTAGDQEFAgEBh3cGDbxQBI9nB4QwA5gPhj2LTYMnOw X-IronPort-AV: E=Sophos;i="4.93,671,1378857600"; d="scan'208";a="18930975" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 10 Nov 2013 10:29:42 +0000 Received: from [10.55.51.194] (ams-ppsenak-8711.cisco.com [10.55.51.194]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAAATaVp019182; Sun, 10 Nov 2013 10:29:37 GMT Message-ID: <527F6012.1000100@cisco.com> Date: Sun, 10 Nov 2013 11:29:38 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "A. Przygienda" References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> In-Reply-To: <527F590A.4080108@zeta2.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 10:29:48 -0000 Hi Tony, please see inline: On 11/10/13 10:59 , A. Przygienda wrote: > On 11/09/2013 10:17 PM, David Lamparter wrote: >> On Sat, Nov 09, 2013 at 08:36:09PM +0000, Acee Lindem wrote: >>> On 11/7/13 2:49 PM, "David Lamparter" wrote: >>>> The downside is that mixing LSA types opens really nice ways of messing >>>> it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously. >>>> Also, race conditions may start popping up if LSAs arrive from flooding >>>> before E-LSAs. Either way, if a router is identified as E-LSA capable, >>>> LSAs originated by it should never be used by mode-1 routers. >>> I'm not so worried about bugs as I am about carrying the complexity of >>> mixed-mode LSA complexity forever. If you need to use both LSA types in >>> the SPF computation, you will have more overhead. I'm inclined to always >>> use the OLD, aka, LSAs for the SPF computation if any backward >>> compatibility mode is configured. >> > > > zipped through the draft-ietf-ospf-ospfv3-lsa-extend-00.txt draft & it's > surely all an interesting new rathole ;-) > > Approach is intriguing and commendable per se but > as the 'mixed' stuff goes > I second Acee that this kind of 'mixed-modes' _never_ go away and people > drag on > huge amounts of complex code long after the original stuff is obsolete. > > Though, yes, a mixed mode is normally necessary for a while since 'flag' > days don't exist anymore for > stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated > over-nite for better or > for worse. good, so you agree we need a way to introduce the new LSAs to network gradually. > > But back to this draft. > > So, as first, I think 12.1 section is overly complicated and will lead > to many interesting > disasters with all those 'mixed' and 'degraded' modes especially if SPF > starts to be > mucked with. > > But as second and worse, > 12.1 is crippling the E-LSA proposal big time since if you have > semantically completely > new things in the new E-LSA TLVs (which after all is THE purpose of > doing it), they > may not encode into old style TLVs and so you can't issue them or > otherwise you 'lie' and > may create routing loops in a 'mixed' mode since you cannot decide when > forwarding > a packet whether it came from an 'old' router or a 'new' router. The > 'new' router may > understand it would create a loop based on E-TLV information only but > the old router > won't have it and throw the packet at you. You would forward using the > 'new' info. If that is > not intuitively clear, I can bring some sketches. unless there is something in the E-LSA that directly impacts SPF and path selection, there is no problem. Today, as the new E-LSAs are defined there is nothing in the encoding that would create the problem you are referring to. As new TLVs are added to the E-LSAs, each time the new TLV is defined we can mandate to specify which compatibility mode does the new TLV supports. There can be many TLVs defined, which can happily support mixed/degraded modes and we should make an effort to let people deploy these in a incremental fashion. thanks, Peter > The crux of all this > has been actually the reason for multi-topology. After we looked into > the math > we realized you 'cannot' simply mix some new format with new info into a > domain > and expect loop-free-hop-by-hop. > So, you can solve this only by running a multi-topology > approach then (i.e. running SPF per E-TLV and TLV topology in your > TDB). Or otherwise > the new format is just lip-stick, it will semantcially never leave the > restrictions of > the old fixed format since it cannot add information. > > In summary, > unless you want to take a 'multi-toopology' approach (which has been > solved and > it would mean E-LSAs are basically a new format in a new topology or > you may choose to > think about it as a completely new protocol engulfing the old one) I > think you will > have to abandon all those 'degrade/mixed/unmixed' stuff and simply fall > back to > old format each time you see a router with EL bit cleared, i.e. you have > to migrate > whole area until E-TLVs kick in. This will allow for E-TLVs to be the > real flexible TLV > new format with possibly new information influencing SPF you're seeking. > > --- tony > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From prz@mail.zeta2.ch Sun Nov 10 02:41:16 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36111E8162 for ; Sun, 10 Nov 2013 02:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RhDiMVn7OnI for ; Sun, 10 Nov 2013 02:41:11 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 95FDA11E812F for ; Sun, 10 Nov 2013 02:41:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAAAf4Yb017275; Sun, 10 Nov 2013 11:41:04 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RhX0+RpbFn4T; Sun, 10 Nov 2013 11:41:01 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAAAexMc017271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 11:40:59 +0100 Message-ID: <527F62BB.1010707@zeta2.ch> Date: Sun, 10 Nov 2013 11:40:59 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Psenak References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> In-Reply-To: <527F6012.1000100@cisco.com> Content-Type: multipart/mixed; boundary="------------030701080302020903070009" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 10:41:16 -0000 This is a multi-part message in MIME format. --------------030701080302020903070009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >> Though, yes, a mixed mode is normally necessary for a while since 'flag' >> days don't exist anymore for >> stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated >> over-nite for better or >> for worse. > > good, so you agree we need a way to introduce the new LSAs to network > gradually. Hey Peter, ack obviously > >> understand it would create a loop based on E-TLV information only but >> the old router >> won't have it and throw the packet at you. You would forward using the >> 'new' info. If that is >> not intuitively clear, I can bring some sketches. > > unless there is something in the E-LSA that directly impacts SPF and > path selection, there is no problem. Today, as the new E-LSAs are > defined there is nothing in the encoding that would create the problem > you are referring to. > > As new TLVs are added to the E-LSAs, each time the new TLV is defined > we can mandate to specify which compatibility mode does the new TLV > supports. There can be many TLVs defined, which can happily support > mixed/degraded modes and we should make an effort to let people deploy > these in a incremental fashion. yes, today there is no problem since the whole thing is just cosmetics. Who cares whether you TLV or fix-packet if semantics are the same. And yes, as long you keep just the 'cosmetics' going, no problem. But then again, what is the stuff really good for. Maybe some excamples of carrying stuff that does not influence SPF and goes into the TLVs would be good (to my mind comes something like label distribution which is not really IGP but useful). So, the moment you add a first semantic changing TLV (basically any information influencing SPF which is basically all the information you're carrying, otherwise it's not IGP, it's generic informating faring around) you will loose all the 'degraded' and so on modes. Simple example: I add to router cap lsa something akin 'overload', i.e. don't use router (I know, it's purely hypothetical and other mechanisms exist). Old routers cannot see that in old style LSA and you cannot make them and there is no 'graceful' migration for this with old routers. You have to run TWO SPFs (basically, multi top) to avoid old routers when forwarding for certain routes or not issue the information (aka, use old style LSAs) until e'one in the area understands E-LSAs. That can span also the whole domain in case of extensions to L2 prefixes. I hope my point got across --- tony --------------030701080302020903070009 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------030701080302020903070009-- From ppsenak@cisco.com Sun Nov 10 02:57:39 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D25921F9CFB for ; Sun, 10 Nov 2013 02:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gciQOmVcRWK for ; Sun, 10 Nov 2013 02:57:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55021F9D11 for ; Sun, 10 Nov 2013 02:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3530; q=dns/txt; s=iport; t=1384081049; x=1385290649; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p+0OgEGDawNl+8ctjt0jifDw1MLqu/9gFFIVAAcHWvI=; b=cE7GZxPkfTytq8wMQoUgSgAgrlZV9fahXTg1vQRPJTQxYBfP6qJ3ZUlv lVDzGK489zNMnNsbCUkoZpLPE7hfZ88mPyKoNwJRM5KCn4oKR1dDPvqZl CuaMPszsfVPZ67QdmvyX6z/VrBXQsL8QQAqPUgL9+f0wqWII/jXgNW8GZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFANFlf1KQ/khL/2dsb2JhbABZgweDf7kignmBJxZ0giUBAQEDASMVQAEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAYd3Bqphkg6BKY4+B4JrgUUDmA+GPYtNgyc7 X-IronPort-AV: E=Sophos;i="4.93,672,1378857600"; d="scan'208";a="161634570" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2013 10:57:05 +0000 Received: from [10.55.51.194] (ams-ppsenak-8711.cisco.com [10.55.51.194]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAAAuxAZ024238; Sun, 10 Nov 2013 10:57:01 GMT Message-ID: <527F667C.9000309@cisco.com> Date: Sun, 10 Nov 2013 11:57:00 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "A. Przygienda" References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> In-Reply-To: <527F62BB.1010707@zeta2.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 10:57:39 -0000 Hi Tony, please see inline: On 11/10/13 11:40 , A. Przygienda wrote: > >>> Though, yes, a mixed mode is normally necessary for a while since 'flag' >>> days don't exist anymore for >>> stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated >>> over-nite for better or >>> for worse. >> >> good, so you agree we need a way to introduce the new LSAs to network >> gradually. > Hey Peter, ack obviously >> >>> understand it would create a loop based on E-TLV information only but >>> the old router >>> won't have it and throw the packet at you. You would forward using the >>> 'new' info. If that is >>> not intuitively clear, I can bring some sketches. >> >> unless there is something in the E-LSA that directly impacts SPF and >> path selection, there is no problem. Today, as the new E-LSAs are >> defined there is nothing in the encoding that would create the problem >> you are referring to. >> >> As new TLVs are added to the E-LSAs, each time the new TLV is defined >> we can mandate to specify which compatibility mode does the new TLV >> supports. There can be many TLVs defined, which can happily support >> mixed/degraded modes and we should make an effort to let people deploy >> these in a incremental fashion. > > yes, today there is no problem since the whole thing is just cosmetics. > Who cares whether you TLV or fix-packet if semantics are the same. > > And yes, as long you keep just the 'cosmetics' going, no problem. But > then again, what is the stuff really good for. Maybe some excamples of > carrying stuff that does not influence > SPF and goes into the TLVs would be good (to my mind comes something > like label distribution which is not really IGP but useful). draft-psenak-ospf-segment-routing-ospfv3-extension-00 is one example - you advertise labels for prefixes, but that does not impact how you select best path(s). Tags for intra/inter prefixes is another one that comes to my mind. > > So, the moment you add a first semantic changing TLV (basically any > information influencing SPF which is basically all the information > you're carrying, otherwise it's not IGP, it's generic > informating faring around) you will loose all the 'degraded' and so on > modes. Simple example: depends on what you consider IGP specific or not. The bottom line is that there is enough possibilities for OSPFv3 extensions which do not impact the path selections - actually I believe most of them will not. As we are defining new LSAs in OSPFv3, we should provide a way for people to deploy them gradually. Sure, if someone wants to deploy something that is not compatible with the current path selection, then there is no compatibility with old path selection, but that is not a problem of the E-LSAs, but rather the problem of the change in the path selection itself. thanks, Peter > > I add to router cap lsa something akin 'overload', i.e. don't use router > (I know, it's purely hypothetical and other mechanisms exist). > > Old routers cannot see that in old style LSA and you cannot make them > and there is no 'graceful' migration for this with old routers. You have > to run TWO SPFs (basically, multi top) to avoid > old routers when forwarding for certain routes or not issue the > information (aka, use old style LSAs) until e'one in the area > understands E-LSAs. That can span also the whole domain in > case of extensions to L2 prefixes. > > I hope my point got across > > --- tony > > From prz@mail.zeta2.ch Sun Nov 10 03:10:35 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DB21F9FCE for ; Sun, 10 Nov 2013 03:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDbDueteUYc3 for ; Sun, 10 Nov 2013 03:10:29 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id ED2CB21F9C0D for ; Sun, 10 Nov 2013 03:10:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAABAMFJ019055; Sun, 10 Nov 2013 12:10:22 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sL+7WTzy0SEQ; Sun, 10 Nov 2013 12:10:21 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAABAIM7019050 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 12:10:18 +0100 Message-ID: <527F699A.60103@zeta2.ch> Date: Sun, 10 Nov 2013 12:10:18 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Psenak References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> In-Reply-To: <527F667C.9000309@cisco.com> Content-Type: multipart/mixed; boundary="------------020900020501060605060205" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 11:10:35 -0000 This is a multi-part message in MIME format. --------------020900020501060605060205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/10/2013 11:57 AM, Peter Psenak wrote: > Hi Tony, > > please see inline: > > On 11/10/13 11:40 , A. Przygienda wrote: >> >>>> Though, yes, a mixed mode is normally necessary for a while since >>>> 'flag' >>>> days don't exist anymore for >>>> stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated >>>> over-nite for better or >>>> for worse. >>> >>> good, so you agree we need a way to introduce the new LSAs to network >>> gradually. >> Hey Peter, ack obviously >>> >>>> understand it would create a loop based on E-TLV information only but >>>> the old router >>>> won't have it and throw the packet at you. You would forward using the >>>> 'new' info. If that is >>>> not intuitively clear, I can bring some sketches. >>> >>> unless there is something in the E-LSA that directly impacts SPF and >>> path selection, there is no problem. Today, as the new E-LSAs are >>> defined there is nothing in the encoding that would create the problem >>> you are referring to. >>> >>> As new TLVs are added to the E-LSAs, each time the new TLV is defined >>> we can mandate to specify which compatibility mode does the new TLV >>> supports. There can be many TLVs defined, which can happily support >>> mixed/degraded modes and we should make an effort to let people deploy >>> these in a incremental fashion. >> >> yes, today there is no problem since the whole thing is just cosmetics. >> Who cares whether you TLV or fix-packet if semantics are the same. >> >> And yes, as long you keep just the 'cosmetics' going, no problem. But >> then again, what is the stuff really good for. Maybe some excamples of >> carrying stuff that does not influence >> SPF and goes into the TLVs would be good (to my mind comes something >> like label distribution which is not really IGP but useful). > > draft-psenak-ospf-segment-routing-ospfv3-extension-00 is one example - > you advertise labels for prefixes, but that does not impact how you > select best path(s). > > Tags for intra/inter prefixes is another one that comes to my mind. yepp, agreed. As I said, labels are valid example. And tags for prefixes are a yes/no example, reachability of prefixes is part of SPF really so if the tags influence reachability, they influence SPF. That's splitting hair though, there will be obviously tons useful stuff that will piggy-back on flooding (and already is). > >> >> So, the moment you add a first semantic changing TLV (basically any >> information influencing SPF which is basically all the information >> you're carrying, otherwise it's not IGP, it's generic >> informating faring around) you will loose all the 'degraded' and so on >> modes. Simple example: > > depends on what you consider IGP specific or not. The bottom line is > that there is enough possibilities for OSPFv3 extensions which do not > impact the path selections - actually I believe most of them will not. > > As we are defining new LSAs in OSPFv3, we should provide a way for > people to deploy them gradually. Sure, if someone wants to deploy > something that is not compatible with the current path selection, then > there is no compatibility with old path selection, but that is not a > problem of the E-LSAs, but rather the problem of the change in the > path selection itself. > I think that's kind of twisting the issue here. you give people a mechanism and you don't put up 'here's dragons' signs they will use it to customer's detriment and it's really easy to influence SPF results (well, that's what IGPs are for). No matter who's 'fault' it was. My only point here. So, pondered tad over the draft and I think it has huge potential and could fold in lots of other stuff that was grabbing new LSA types & so on all over the place historically. Given this, it should be probably pretty tight. What comes to my mind here would be an additional section dealing with missing sub-TLVs, repeating TLVs (which copy is being used) and such general stability issues that TLV formats bring with them. Lemme know if you think it's useful & want e.g. me to give it a stab. -- tony --------------020900020501060605060205 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="prz.vcf" YmVnaW46dmNhcmQNCmZuOkEuIFByenlnaWVuZGENCm46UHJ6eWdpZW5kYTtBLg0Kb3JnOlpl dGEyIEdtYkgNCmFkcjo7O1ZpYSBUZXJzYWdnaW8gMjA7Q29tYW5vOzs2OTQ5O1N3aXR6ZXJs YW5kDQplbWFpbDtpbnRlcm5ldDpwcnpAemV0YTIuY2gNCnRpdGxlOkRyLg0KdGVsO3dvcms6 KzQxOTE5NDAyNzY3DQp0ZWw7ZmF4Ois0MTkxOTQwMjc2OA0KdGVsO2NlbGw6KzQxNzkyOTg1 OTAwDQp4LW1vemlsbGEtaHRtbDpUUlVFDQp1cmw6aHR0cDovL3d3dy56ZXRhMi5jaA0KdmVy c2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------020900020501060605060205-- From ppsenak@cisco.com Sun Nov 10 03:37:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5AC11E816D for ; Sun, 10 Nov 2013 03:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9xoa1fcoXVw for ; Sun, 10 Nov 2013 03:37:18 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C141521F9E96 for ; Sun, 10 Nov 2013 03:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4787; q=dns/txt; s=iport; t=1384083437; x=1385293037; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zm+i6jd3wK0HnJDsEiLIWp5qaosJ4TU2b9BBlMNEvVQ=; b=Ug7Rys/n0KyieXptHsol/csjdO9yYAZXg6hpcCukqOCjSZFdMDkTc9aw 7QkVJPh6Le1tUJ5Pm2h2o+gQaCFy4TTdSnJzprU8uni2fXPwxiENtZzZC TuWUc7WzcW5rXET1scO3uUmv9RtpGIKyFr6014yCDEBncjehKA0IfX7Za w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAKJvf1KQ/khL/2dsb2JhbABZgweDf7kignmBJxZ0giUBAQEDASMVQAEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAYd3BqpYkgqBKY4+B4JrgUUDmA+GPYtNgyc7 X-IronPort-AV: E=Sophos;i="4.93,672,1378857600"; d="scan'208";a="88055802" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Nov 2013 11:37:16 +0000 Received: from [10.55.51.194] (ams-ppsenak-8711.cisco.com [10.55.51.194]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAABbAIw002308; Sun, 10 Nov 2013 11:37:11 GMT Message-ID: <527F6FE6.8010401@cisco.com> Date: Sun, 10 Nov 2013 12:37:10 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "A. Przygienda" References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> In-Reply-To: <527F699A.60103@zeta2.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 11:37:23 -0000 Hi Tony, please see inline: On 11/10/13 12:10 , A. Przygienda wrote: > On 11/10/2013 11:57 AM, Peter Psenak wrote: >> Hi Tony, >> >> please see inline: >> >> On 11/10/13 11:40 , A. Przygienda wrote: >>> >>>>> Though, yes, a mixed mode is normally necessary for a while since >>>>> 'flag' >>>>> days don't exist anymore for >>>>> stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated >>>>> over-nite for better or >>>>> for worse. >>>> >>>> good, so you agree we need a way to introduce the new LSAs to network >>>> gradually. >>> Hey Peter, ack obviously >>>> >>>>> understand it would create a loop based on E-TLV information only but >>>>> the old router >>>>> won't have it and throw the packet at you. You would forward using the >>>>> 'new' info. If that is >>>>> not intuitively clear, I can bring some sketches. >>>> >>>> unless there is something in the E-LSA that directly impacts SPF and >>>> path selection, there is no problem. Today, as the new E-LSAs are >>>> defined there is nothing in the encoding that would create the problem >>>> you are referring to. >>>> >>>> As new TLVs are added to the E-LSAs, each time the new TLV is defined >>>> we can mandate to specify which compatibility mode does the new TLV >>>> supports. There can be many TLVs defined, which can happily support >>>> mixed/degraded modes and we should make an effort to let people deploy >>>> these in a incremental fashion. >>> >>> yes, today there is no problem since the whole thing is just cosmetics. >>> Who cares whether you TLV or fix-packet if semantics are the same. >>> >>> And yes, as long you keep just the 'cosmetics' going, no problem. But >>> then again, what is the stuff really good for. Maybe some excamples of >>> carrying stuff that does not influence >>> SPF and goes into the TLVs would be good (to my mind comes something >>> like label distribution which is not really IGP but useful). >> >> draft-psenak-ospf-segment-routing-ospfv3-extension-00 is one example - >> you advertise labels for prefixes, but that does not impact how you >> select best path(s). >> >> Tags for intra/inter prefixes is another one that comes to my mind. > yepp, agreed. As I said, labels are valid example. > And tags for prefixes are a yes/no example, reachability of prefixes is > part of SPF really so if the tags influence reachability, they influence > SPF. That's splitting hair though, there will be obviously tons useful > stuff that will piggy-back on flooding (and already is). >> >>> >>> So, the moment you add a first semantic changing TLV (basically any >>> information influencing SPF which is basically all the information >>> you're carrying, otherwise it's not IGP, it's generic >>> informating faring around) you will loose all the 'degraded' and so on >>> modes. Simple example: >> >> depends on what you consider IGP specific or not. The bottom line is >> that there is enough possibilities for OSPFv3 extensions which do not >> impact the path selections - actually I believe most of them will not. >> >> As we are defining new LSAs in OSPFv3, we should provide a way for >> people to deploy them gradually. Sure, if someone wants to deploy >> something that is not compatible with the current path selection, then >> there is no compatibility with old path selection, but that is not a >> problem of the E-LSAs, but rather the problem of the change in the >> path selection itself. >> > I think that's kind of twisting the issue here. you give people a > mechanism and you don't put up 'here's dragons' signs they will use it > to customer's detriment and it's really easy to influence SPF results > (well, that's what IGPs are for). No matter who's 'fault' it was. My > only point here. my point is that over the time you may introduce new TLVs that change the path selection logic. Each time you do that, you need to make sure that all routers follow the same logic during the computation. This can not be done at the E-LSA level, the problem needs to be addressed every time the computation logic is changed - e.g. new such TLV is defined. > > So, pondered tad over the draft and I think it has huge potential and > could fold in lots of other stuff that was grabbing new LSA types & so > on all over the place historically. > Given this, it should be probably pretty tight. What comes to my mind > here would be an additional section dealing with missing sub-TLVs, > repeating TLVs (which copy is being used) and > such general stability issues that TLV formats bring with them. Lemme > know if you think it's useful & want e.g. me to give it a stab. absolutely, we are opened to any advice/recommendation. thanks, Peter > > -- tony > > From prz@mail.zeta2.ch Sun Nov 10 03:55:17 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505921E8134 for ; Sun, 10 Nov 2013 03:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8loxIQ19-af for ; Sun, 10 Nov 2013 03:55:12 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E921E8133 for ; Sun, 10 Nov 2013 03:55:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAABt5sE021840; Sun, 10 Nov 2013 12:55:05 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id THGhJZ7EhxX2; Sun, 10 Nov 2013 12:55:04 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAABt0ng021831 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 12:55:01 +0100 Message-ID: <527F7414.4070004@zeta2.ch> Date: Sun, 10 Nov 2013 12:55:00 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Psenak References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> <527F6FE6.8010401@cisco.com> In-Reply-To: <527F6FE6.8010401@cisco.com> Content-Type: multipart/mixed; boundary="------------010909070604020709040506" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 11:55:17 -0000 This is a multi-part message in MIME format. --------------010909070604020709040506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/10/2013 12:37 PM, Peter Psenak wrote: > I think that's kind of twisting the issue here. you give people a >> mechanism and you don't put up 'here's dragons' signs they will use it >> to customer's detriment and it's really easy to influence SPF results >> (well, that's what IGPs are for). No matter who's 'fault' it was. My >> only point here. > > my point is that over the time you may introduce new TLVs that change > the path selection logic. Each time you do that, you need to make sure > that all routers follow the same logic during the computation. This > can not be done at the E-LSA level, the problem needs to be addressed > every time the computation logic is changed - e.g. new such TLV is > defined. > we're in violent agreement here. A warning may nevertheless be worth putting into this draft. >> >> So, pondered tad over the draft and I think it has huge potential and >> could fold in lots of other stuff that was grabbing new LSA types & so >> on all over the place historically. >> Given this, it should be probably pretty tight. What comes to my mind >> here would be an additional section dealing with missing sub-TLVs, >> repeating TLVs (which copy is being used) and >> such general stability issues that TLV formats bring with them. Lemme >> know if you think it's useful & want e.g. me to give it a stab. > > absolutely, we are opened to any advice/recommendation. > on my list then, gimme a week. Thinking further, maybe in the type of TLV encoding it would be good to think about having a 'mandatory/transitory/optional' bit in terms of use by routers (kind of ripping off the BGP'ish and other TLV encodings). Just food for thought here when starting to think about e.g. aggregation of TLVs over prefixes and so on. --- tony --------------010909070604020709040506 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="prz.vcf" YmVnaW46dmNhcmQNCmZuOkEuIFByenlnaWVuZGENCm46UHJ6eWdpZW5kYTtBLg0Kb3JnOlpl dGEyIEdtYkgNCmFkcjo7O1ZpYSBUZXJzYWdnaW8gMjA7Q29tYW5vOzs2OTQ5O1N3aXR6ZXJs YW5kDQplbWFpbDtpbnRlcm5ldDpwcnpAemV0YTIuY2gNCnRpdGxlOkRyLg0KdGVsO3dvcms6 KzQxOTE5NDAyNzY3DQp0ZWw7ZmF4Ois0MTkxOTQwMjc2OA0KdGVsO2NlbGw6KzQxNzkyOTg1 OTAwDQp4LW1vemlsbGEtaHRtbDpUUlVFDQp1cmw6aHR0cDovL3d3dy56ZXRhMi5jaA0KdmVy c2lvbjoyLjENCmVuZDp2Y2FyZA0KDQo= --------------010909070604020709040506-- From equinox@spaceboyz.net Sun Nov 10 11:12:05 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C25F21F9FBA for ; Sun, 10 Nov 2013 11:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjFItm+oYgo1 for ; Sun, 10 Nov 2013 11:12:05 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF07F21F9D8D for ; Sun, 10 Nov 2013 11:12:04 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1VfaQS-0008Ef-8f; Sun, 10 Nov 2013 20:12:00 +0100 Date: Sun, 10 Nov 2013 20:12:00 +0100 From: David Lamparter To: "A. Przygienda" Message-ID: <20131110191200.GF5311@spaceboyz.net> References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> <527F6FE6.8010401@cisco.com> <527F7414.4070004@zeta2.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527F7414.4070004@zeta2.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 19:12:05 -0000 On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote: > Thinking further, maybe in the type of TLV encoding it would be good to > think about having a 'mandatory/transitory/optional' bit in terms of use > by routers (kind of ripping off the BGP'ish and other TLV encodings). > Just food for thought here when starting to think about e.g. aggregation > of TLVs over prefixes and so on. I suggested that a while ago, and in the end it was dismantled because there was no real use case that didn't fall apart. If you can come up with a good design and something close to a realistic scenario where this is used... -David From prz@mail.zeta2.ch Sun Nov 10 14:48:42 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCED21E8172 for ; Sun, 10 Nov 2013 14:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZVHi7kZ+bER for ; Sun, 10 Nov 2013 14:48:37 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 452A321E815F for ; Sun, 10 Nov 2013 14:48:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAAMmMOr029889 for ; Sun, 10 Nov 2013 23:48:22 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uSdwOkKPR4Ok for ; Sun, 10 Nov 2013 23:48:20 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rAAMmG7Q029884 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 10 Nov 2013 23:48:16 +0100 Message-ID: <52800D30.1020703@zeta2.ch> Date: Sun, 10 Nov 2013 23:48:16 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ospf@ietf.org References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> <527F6FE6.8010401@cisco.com> <527F7414.4070004@zeta2.ch> <20131110191200.GF5311@spaceboyz.net> In-Reply-To: <20131110191200.GF5311@spaceboyz.net> Content-Type: multipart/mixed; boundary="------------010209010302090902070503" Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 22:48:42 -0000 This is a multi-part message in MIME format. --------------010209010302090902070503 Content-Type: multipart/alternative; boundary="------------090509040101040902040105" --------------090509040101040902040105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/10/2013 08:12 PM, David Lamparter wrote: > On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote: >> Thinking further, maybe in the type of TLV encoding it would be good to >> think about having a 'mandatory/transitory/optional' bit in terms of use >> by routers (kind of ripping off the BGP'ish and other TLV encodings). >> Just food for thought here when starting to think about e.g. aggregation >> of TLVs over prefixes and so on. > I suggested that a while ago, and in the end it was dismantled because > there was no real use case that didn't fall apart. If you can come up > with a good design and something close to a realistic scenario where > this is used... > > Hey David, well, searched the archives & found it. Remember even having read it & actually seems I commented on it from a different angle. It was more of the 'ignore/strong unreachable' type & that's why my brain slipped the connection. So let me ask the question again from yet a different angle and verify some assumptions I'm making not having been to OSPF WGs recently: The way I see this draft, it's immediate purpose is to get today some 'carrier encoding' for things like Seg-Routing & Src-Dst routing without the necessity of tons of new LSA types, more flexibility than the usual rather clunky add-a-options-bit-add-something-to-an-LSA-grab-a-cap-bit or having to link lots of info between LSAs and stuff-stuffed-in-opaques. If this is the *only*reason, then further discussion I start here makes no sense, no new TLVs can ever influence core behavior such as SPF/summaries/flooding and at first glance, the whole thing could have been done using Opaque LSAs just like the optional-router-caps and this draft is a redundant, somewhat more elegant encoding. But reading and thinking about it, I see further potential to glue new TLV "things" easily (and more elegantly than opaques) to 'links' and 'interfaces' and 'routers'. In short, it could help to move OSPF more into an TLV-type-encoded protocol format rather than a fixed-format used today (to largest extent). Think OSPFv3.5 ;-) where the extended-LSA is THE LSA format. As we know, TLVs are a sharp stick, they allow to extend the protocol easily and quite elegantly but they can poke you in the eye as well. Overall, they are where things go since the strongest traditional reasons for fixed encodings such as 4-bytes-aligned MMU C structures ;-) are things of the past given the raw amounts of power & CPU available & the popularity of IGPs as loosely-synchronized-network-databases ;-) vs. the old times of well-understood one-purpose mechanism to get reachability @ L3 within AD. So, assuming you all have in mind coming glorious days of OSPFv3.5, people would use it of course to do things like adding new TLVs that will influence SPF behavior, interface types, prefix reachabilities and so on. Now, how to keep this beast in check and that's where my observations were going. In crux the question would be then, how is the draft supposed to keep compatibility with 'newer' versions of this encoding when new TLVs are being introduced and suggested and start to influence things. Well, people who have been in the game for longish time tend to think about this stuff in terms of mandatory/transitory/summarizing properties of data/TLVs and it is a rathole but one that always opens in these situations. So I follow this kind of thinking a tad down the road to clarify the scope of the extended-lsa-draft here as of how far this draft is supposed to reach [ If that thinking is tad cross to usual OSPF-hat-on-design, an optional way of thinking about this protocol architecture issue would be to 'add-another-options-bit' for every TLV that is introduced and influences SPF/redist/summaries. This is nothing else but a 'mandatory' bit on some new TLV. You may run out of bits quickly though ;-) ] Hypothetical examples to justify all this rambling (I try to keep things simple as first examples): 1. someone adds a 'I-can-only-route-traffic-on-sundays' TLV: this would be manadatory, that means any router not understanding this TLV would have to not compute through this router. Everything would go well until sunday when a router upstream understanding the TLV would send you traffic to carry through to a router downstreamnot understanding the TLV and then it would loop. Logical conclusion: you don't understand mandatory, get out of next-hop SPF or otherwise you end up in the multi-topo cornerwith multiple SPFs. 2. someone adds a 'only-generate-type-5-from-this-type-3-on-sundays': as you see, you'd have to get out the redistribution/summarization if you have a mandatory TLV like this. That leads into'transitory/summarizing' type of bits but those are difficult to get right (we can take the discussion further from here butI never saw them 'gotten right'). Logical conclusion. You don't understand the mandatory prefix TLV, leave the area (since you havedifferent reachability assumptions than other routers understanding the TLV). 3. Someone adds 'I-have-disjoint-path-computation-property' TLV which would be non-mandatory fornormal SPF but mandatory for a source-destination-disjoint-path-SPF. So, people can do SPF overit as normal but someone running disjoint-path-source-dest-SPF reads the internal mandatory flagfor it & computes the path omitting the link (should be obvious that in source-dest type of SPFs you can mix routers understanding a mandatory TLV with some that don't contrary to next-hop SPFs). To summarize: * As authors, ask yourself the intellectually honest question whether this encoding is ONLY for thingsthat will never touch SPF/redist/summarization/prefix reachability. If answer is YES, then state forcefully in the draft that this is NOT a new-OSPF-TLV-encoding but more elegant way to do opaques and nothing else. * If answer is NO and this goes into direction of OSPFv3.5 with TLV encodings: * think about reserving two or three bits in type (or length, 14 bits still give you 8K TLVs with sub-TLVs)along the mandatory/transitive line of thinking and start to work out what happens when a router does not understand mandatory/transitory. Section 12.1 is then largely unnecessary but instead maybe a new section is in order. Not only get-in-get-out behavior needs to be precisely specified (but also things like multiple copies of same TLV, misformatted TLVs, missing required TLVs, sequence of TLVs, TLV type spaces and so on). This sounds excessive but it isn't given the fact that this encoding would be a very deep foundation for many years to come (and well, I'd help to write it ;-) So, I hope I'm contributing here to clarification of purpose rather than stultifying ;-) thanks --- tony --------------090509040101040902040105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/10/2013 08:12 PM, David Lamparter wrote:
On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote:

Thinking further, maybe in the type of TLV encoding it would be good to
think about having a 'mandatory/transitory/optional' bit in terms of use
by routers (kind of ripping off the BGP'ish and other TLV encodings).
Just food for thought here when starting to think about e.g. aggregation
of TLVs over prefixes and so on.

I suggested that a while ago, and in the end it was dismantled because
there was no real use case that didn't fall apart.  If you can come up
with a good design and something close to a realistic scenario where
this is used...

Hey David, well,  searched the archives & found it. Remember even having read it & actually seems
I commented on it from a different angle. It was more of
the 'ignore/strong unreachable' type & that's why my brain slipped the connection.

So let me ask the question again from yet a different angle and verify some assumptions I'm making
not having been to OSPF WGs recently:

The way I see this draft, it's immediate
purpose is to get today some 'carrier encoding' for things like Seg-Routing
& Src-Dst routing without the necessity of tons of new LSA types, more flexibility than
the usual rather clunky add-a-options-bit-add-something-to-an-LSA-grab-a-cap-bit or having
to link lots of info between LSAs and stuff-stuffed-in-opaques.

If this is the only reason, then further discussion I start here makes no sense, no new TLVs can
ever influence core behavior such as SPF/summaries/flooding and at first glance, the whole thing could have been
done using Opaque LSAs just like the optional-router-caps and this draft is a redundant,
somewhat more elegant encoding.

But reading and thinking about it, I see further potential to glue
new TLV "things" easily (and more elegantly than opaques)
to 'links' and 'interfaces' and 'routers'. In short, it could help to move OSPF more into an
TLV-type-encoded protocol format rather than a fixed-format used today (to largest extent). Think
OSPFv3.5 ;-) where the extended-LSA is THE LSA format.
As we know, TLVs are a sharp stick, they allow to extend the protocol easily and quite elegantly
but they can poke you in the eye as well. Overall, they are where things go since the
strongest traditional reasons for fixed encodings such as 4-bytes-aligned MMU C structures
;-)  are things of the past given the raw amounts of power & CPU available & the popularity
of IGPs as loosely-synchronized-network-databases ;-)
vs. the old times of well-understood one-purpose mechanism to get reachability @ L3 within AD.

So, assuming you all have in mind coming glorious days of OSPFv3.5,
people would use it of course to do things like adding new TLVs that will influence
SPF behavior, interface types, prefix reachabilities and so on.  Now, how to keep this beast
in check and that's where my observations were going.

In crux the question would be then, how is the draft supposed to keep compatibility with 'newer' versions of this encoding
when new TLVs are being introduced and suggested and start to influence things.  Well, people who
have been in the game for longish time tend to think about this stuff in terms of
mandatory/transitory/summarizing properties of data/TLVs and it is a rathole but one that
always opens in these situations.

So I follow this kind of thinking a tad down the road to clarify the scope of the extended-lsa-draft
here as of how far this draft is supposed to
reach [ If that thinking is tad cross to usual OSPF-hat-on-design, an optional
way of thinking about this protocol architecture issue
would be to 'add-another-options-bit' for every TLV that is introduced and influences
SPF/redist/summaries. This is nothing else but a 'mandatory' bit on some new TLV. You may run out of bits quickly though ;-) ]

Hypothetical examples to justify all this rambling (I try to keep things simple as first examples):
  1. someone adds a 'I-can-only-route-traffic-on-sundays' TLV:  this would be manadatory, that means  any router not understanding this TLV would have to not compute through this router. Everything would go well until sunday when a router upstream understanding the TLV would send you traffic to carry through to a router downstreamnot understanding the TLV and then it would loop. Logical conclusion: you don't understand mandatory, get out of next-hop SPF or otherwise you end up in the multi-topo corner with multiple SPFs.
  2. someone adds a 'only-generate-type-5-from-this-type-3-on-sundays': as you see, you'd have to  get out the redistribution/summarization if you have a mandatory TLV like this. That leads into 'transitory/summarizing' type of bits but those are difficult to get right (we can take the discussion further from here but I never saw them 'gotten right'). Logical conclusion. You don't understand the mandatory prefix TLV, leave the area (since you have different reachability assumptions than other routers understanding the TLV). 
  3. Someone adds 'I-have-disjoint-path-computation-property' TLV which would be non-mandatory for normal SPF but mandatory for a source-destination-disjoint-path-SPF.  So, people can do SPF over it as normal but someone running disjoint-path-source-dest-SPF reads the internal mandatory flag for it & computes the path omitting the link (should be obvious that in source-dest type of SPFs you can mix routers understanding a mandatory TLV with some that don't contrary to next-hop SPFs).

To summarize:
  • As authors, ask yourself the intellectually honest question whether this encoding is ONLY for things that will never touch SPF/redist/summarization/prefix reachability. If answer is YES, then state forcefully in the draft that this is NOT a new-OSPF-TLV-encoding but more elegant way to do opaques and nothing else.
  • If answer is NO and this goes into direction of OSPFv3.5 with TLV encodings:
  • think about reserving two or three bits in type (or length, 14 bits still give you 8K TLVs with sub-TLVs) along the mandatory/transitive line of thinking and start to work out what happens when a router does not understand mandatory/transitory.  Section 12.1 is then largely unnecessary but instead maybe a new section is in order. Not only get-in-get-out behavior needs to be precisely specified (but also things like multiple copies of same TLV, misformatted TLVs, missing required TLVs, sequence of TLVs, TLV type spaces and so on). This sounds excessive but it isn't given the fact that this encoding would be a very deep foundation for many years to come (and well, I'd help to write it ;-)


So, I hope I'm contributing here to clarification of purpose rather than stultifying ;-)

thanks

---  tony









 


 --------------090509040101040902040105-- --------------010209010302090902070503 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------010209010302090902070503-- From prz@mail.zeta2.ch Mon Nov 11 03:23:20 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44611E8164 for ; Mon, 11 Nov 2013 03:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZVDp70w5tKN for ; Mon, 11 Nov 2013 03:23:14 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id C763D11E815F for ; Mon, 11 Nov 2013 03:23:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rABBNBmY030332 for ; Mon, 11 Nov 2013 12:23:11 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sCYS2pKrNntR for ; Mon, 11 Nov 2013 12:23:10 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rABBN7Ga030324 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 11 Nov 2013 12:23:07 +0100 Message-ID: <5280BE1B.8090701@zeta2.ch> Date: Mon, 11 Nov 2013 12:23:07 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ospf@ietf.org References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> <527F6FE6.8010401@cisco.com> <527F7414.4070004@zeta2.ch> <20131110191200.GF5311@spaceboyz.net> <52800D30.1020703@zeta2.ch> In-Reply-To: <52800D30.1020703@zeta2.ch> Content-Type: multipart/mixed; boundary="------------010608020703010705080200" Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:23:21 -0000 This is a multi-part message in MIME format. --------------010608020703010705080200 Content-Type: multipart/alternative; boundary="------------070405020801030705040901" --------------070405020801030705040901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/10/2013 11:48 PM, A. Przygienda wrote: > On 11/10/2013 08:12 PM, David Lamparter wrote: >> On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote: >>> Thinking further, maybe in the type of TLV encoding it would be good to >>> think about having a 'mandatory/transitory/optional' bit in terms of use >>> by routers (kind of ripping off the BGP'ish and other TLV encodings). >>> Just food for thought here when starting to think about e.g. aggregation >>> of TLVs over prefixes and so on. >> I suggested that a while ago, and in the end it was dismantled because >> there was no real use case that didn't fall apart. If you can come up >> with a good design and something close to a realistic scenario where >> this is used... >> >> > > Hey David, well, searched the archives & found it. Remember even > having read it & actually seems > I commented on it from a different angle. It was more of > the 'ignore/strong unreachable' type & that's why my brain slipped the > connection. > so, talking to myself (happens often) after having slept & thought about the issue more. A radically more advanced design would be to include in the E-TLV an 'endless' options bitmask which is a mandatory TLV. Think somethink like TLV-007 ;-) Length I support TLV 55,sub-TLV 45,46 I support TLV 57,sub-TLV 47,49 Think a amalgam of router options mask & optional-router-cap put together into a clean protocol design. Ideally, that would be stuck on the router LSA & TLV space be unified for all ext-LSA types (and each sub-TLV space be independent of the main TLV space or think about sub-TLV 7 in TLV 5 as TLV Type 5.7) That would allow for a mixed topology without problems, i.e. in case of 'I-can-only-transition-traffic-on-mondays' the router that does not support the TLV would be left out of computation on sunday by ALL routers that understand the TLV (since it could decide to forward to the guy that can only transition on sundays). They see his TLV-007 and decide he's too dumb to participate. Lack of TLV-007 would indicate simply an old-style router (but then, it wouldn't even have ext-lsas). You would still need a mandatory (and possibly transitory for summaries 3->5 conversions) bit on each TLV since the router not understanding the 'only-on-sundays' mandatory TLV would not compute any routes through a router advertising such TLVs (and ignore prefixes that have not-understood-mandatories) and so on. again, this all only makes real sense if ext-lsa draft is supposed to move OSPF towards a TLV-oriented packet encoding longer term. --- tony --------------070405020801030705040901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/10/2013 11:48 PM, A. Przygienda wrote:
On 11/10/2013 08:12 PM, David Lamparter wrote:
On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote:

Thinking further, maybe in the type of TLV encoding it would be good to
think about having a 'mandatory/transitory/optional' bit in terms of use
by routers (kind of ripping off the BGP'ish and other TLV encodings).
Just food for thought here when starting to think about e.g. aggregation
of TLVs over prefixes and so on.

I suggested that a while ago, and in the end it was dismantled because
there was no real use case that didn't fall apart.  If you can come up
with a good design and something close to a realistic scenario where
this is used...

Hey David, well,  searched the archives & found it. Remember even having read it & actually seems
I commented on it from a different angle. It was more of
the 'ignore/strong unreachable' type & that's why my brain slipped the connection.


so, talking to myself (happens often) after having slept & thought about the issue more.

A radically more advanced design would be to include in the E-TLV an 'endless' options bitmask which
is a mandatory TLV. Think somethink like

TLV-007 ;-)
Length
I support TLV  55,sub-TLV 45,46
I support TLV  57,sub-TLV 47,49

Think a amalgam of router options mask & optional-router-cap put together into a clean protocol design.
Ideally, that would be stuck on the router LSA &  TLV space be unified for all ext-LSA types (and each
sub-TLV space be independent of the main TLV space or think about sub-TLV 7 in TLV 5 as TLV Type 5.7)

That would allow for a mixed topology without problems, i.e. in case of
'I-can-only-transition-traffic-on-mondays' the router that does not support
the TLV would be left out of computation on sunday by ALL routers that understand
the TLV (since it could decide to forward to the guy that can only transition on sundays).
They see his TLV-007 and decide he's too dumb to participate. Lack of TLV-007 would
indicate simply an old-style router (but then, it wouldn't even have ext-lsas).

You would still need a mandatory (and possibly transitory for summaries 3->5 conversions)
bit on each TLV since the router not understanding the
'only-on-sundays' mandatory TLV would not compute any routes through a router advertising
such TLVs (and ignore prefixes that have not-understood-mandatories) and so on.

again, this all only makes real sense if ext-lsa draft is supposed to move OSPF towards a TLV-oriented
packet encoding longer term.

--- tony






 
 --------------070405020801030705040901-- --------------010608020703010705080200 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------010608020703010705080200-- From asmirnov@cisco.com Mon Nov 11 04:05:24 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493FD11E8149 for ; Mon, 11 Nov 2013 04:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs8caY+zts-3 for ; Mon, 11 Nov 2013 04:05:19 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7337111E80FA for ; Mon, 11 Nov 2013 04:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8704; q=dns/txt; s=iport; t=1384171517; x=1385381117; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=wJfiIvjevOLBo4YZfxYstfdN1NJHb36BDHboVhwwLLU=; b=lRnx3LPQo87x69kIidlsWzs4LQdspl50rzbUyYlQBFyqqeJFy5azpMXd o+4oInrzFpiuLiCTXKao0lAqT4r++CAlFaL+7OoMfXcfELPclQtmnSgK+ P+7alyb5BRyWTYix1U9wQweTv+BVrDemPDoawCy+dKa3YtHVh4/rjtx+S U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAETHgFKQ/khL/2dsb2JhbABZgwc4v2aBNxZ0giUBAQEEAQEBNS8HGwsSBgklDwIWIg4GAQwGAgEBh30NvisEji+BP4QwA5Qug2GSCoMnOw X-IronPort-AV: E=Sophos;i="4.93,676,1378857600"; d="scan'208";a="18953109" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 11 Nov 2013 12:05:16 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rABC58Y1001530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 12:05:11 GMT Message-ID: <5280C7F4.50907@cisco.com> Date: Mon, 11 Nov 2013 13:05:08 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "A. Przygienda" , ospf@ietf.org References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> <527F6FE6.8010401@cisco.com> <527F7414.4070004@zeta2.ch> <20131110191200.GF5311@spaceboyz.net> <52800D30.1020703@zeta2.ch> In-Reply-To: <52800D30.1020703@zeta2.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:05:24 -0000 Hi Tony, your thoughts, if I understand you correctly, is to propagate some universally understood handling information in the header of each TLV. So far in OSPF intention (and to large extent - the practice) was to verify ability of routers to understand the information in LSAs via option bits in LLS/RI LSA (and for older features - in option bits in LSAs and packets). BGP, which you gave as an example of protocol with per-TLV handling information, is p2p protocol with ability to filter and modify information per-session and per-prefix. OSPF, being link-state protocol, should always remember that all routers in the area share LSDB view. Verifying feature support per-TLV is not scalable, mechanism of per-router bits works better. So in your "routing on Sundays" example, author of the feature has a choice of: - Do not compute "routing on Sundays" until all routers in the scope support it - Define "routing on Sundays" computation algorithm to avoid routers not supporting it - etc. etc. This is all possible and doesn't require per-TLV handling bits. Anton On 11/10/2013 11:48 PM, A. Przygienda wrote: > On 11/10/2013 08:12 PM, David Lamparter wrote: >> On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote: >>> Thinking further, maybe in the type of TLV encoding it would be good to >>> think about having a 'mandatory/transitory/optional' bit in terms of use >>> by routers (kind of ripping off the BGP'ish and other TLV encodings). >>> Just food for thought here when starting to think about e.g. aggregation >>> of TLVs over prefixes and so on. >> I suggested that a while ago, and in the end it was dismantled because >> there was no real use case that didn't fall apart. If you can come up >> with a good design and something close to a realistic scenario where >> this is used... >> >> > > Hey David, well, searched the archives & found it. Remember even having > read it & actually seems > I commented on it from a different angle. It was more of > the 'ignore/strong unreachable' type & that's why my brain slipped the > connection. > > So let me ask the question again from yet a different angle and verify > some assumptions I'm making > not having been to OSPF WGs recently: > > The way I see this draft, it's immediate > purpose is to get today some 'carrier encoding' for things like Seg-Routing > & Src-Dst routing without the necessity of tons of new LSA types, more > flexibility than > the usual rather clunky > add-a-options-bit-add-something-to-an-LSA-grab-a-cap-bit or having > to link lots of info between LSAs and stuff-stuffed-in-opaques. > > If this is the *only*reason, then further discussion I start here makes > no sense, no new TLVs can > ever influence core behavior such as SPF/summaries/flooding and at first > glance, the whole thing could have been > done using Opaque LSAs just like the optional-router-caps and this draft > is a redundant, > somewhat more elegant encoding. > > But reading and thinking about it, I see further potential to glue > new TLV "things" easily (and more elegantly than opaques) > to 'links' and 'interfaces' and 'routers'. In short, it could help to > move OSPF more into an > TLV-type-encoded protocol format rather than a fixed-format used today > (to largest extent). Think > OSPFv3.5 ;-) where the extended-LSA is THE LSA format. > As we know, TLVs are a sharp stick, they allow to extend the protocol > easily and quite elegantly > but they can poke you in the eye as well. Overall, they are where things > go since the > strongest traditional reasons for fixed encodings such as > 4-bytes-aligned MMU C structures > ;-) are things of the past given the raw amounts of power & CPU > available & the popularity > of IGPs as loosely-synchronized-network-databases ;-) > vs. the old times of well-understood one-purpose mechanism to get > reachability @ L3 within AD. > > So, assuming you all have in mind coming glorious days of OSPFv3.5, > people would use it of course to do things like adding new TLVs that > will influence > SPF behavior, interface types, prefix reachabilities and so on. Now, how > to keep this beast > in check and that's where my observations were going. > > In crux the question would be then, how is the draft supposed to keep > compatibility with 'newer' versions of this encoding > when new TLVs are being introduced and suggested and start to influence > things. Well, people who > have been in the game for longish time tend to think about this stuff in > terms of > mandatory/transitory/summarizing properties of data/TLVs and it is a > rathole but one that > always opens in these situations. > > So I follow this kind of thinking a tad down the road to clarify the > scope of the extended-lsa-draft > here as of how far this draft is supposed to > reach [ If that thinking is tad cross to usual OSPF-hat-on-design, an > optional > way of thinking about this protocol architecture issue > would be to 'add-another-options-bit' for every TLV that is introduced > and influences > SPF/redist/summaries. This is nothing else but a 'mandatory' bit on some > new TLV. You may run out of bits quickly though ;-) ] > > Hypothetical examples to justify all this rambling (I try to keep things > simple as first examples): > > 1. someone adds a 'I-can-only-route-traffic-on-sundays' TLV: this would > be manadatory, that means any router not understanding this TLV > would have to not compute through this router. Everything would go > well until sunday when a router upstream understanding the TLV would > send you traffic to carry through to a router downstreamnot > understanding the TLV and then it would loop. Logical conclusion: > you don't understand mandatory, get out of next-hop SPF or otherwise > you end up in the multi-topo cornerwith multiple SPFs. > 2. someone adds a 'only-generate-type-5-from-this-type-3-on-sundays': > as you see, you'd have to get out the redistribution/summarization > if you have a mandatory TLV like this. That leads > into'transitory/summarizing' type of bits but those are difficult to > get right (we can take the discussion further from here butI never > saw them 'gotten right'). Logical conclusion. You don't understand > the mandatory prefix TLV, leave the area (since you havedifferent > reachability assumptions than other routers understanding the TLV). > 3. Someone adds 'I-have-disjoint-path-computation-property' TLV which > would be non-mandatory fornormal SPF but mandatory for a > source-destination-disjoint-path-SPF. So, people can do SPF overit > as normal but someone running disjoint-path-source-dest-SPF reads > the internal mandatory flagfor it & computes the path omitting the > link (should be obvious that in source-dest type of SPFs you can mix > routers understanding a mandatory TLV with some that don't contrary > to next-hop SPFs). > > > To summarize: > > * As authors, ask yourself the intellectually honest question whether > this encoding is ONLY for thingsthat will never touch > SPF/redist/summarization/prefix reachability. If answer is YES, then > state forcefully in the draft that this is NOT a > new-OSPF-TLV-encoding but more elegant way to do opaques and nothing > else. > > * If answer is NO and this goes into direction of OSPFv3.5 with TLV > encodings: > > * think about reserving two or three bits in type (or length, 14 > bits still give you 8K TLVs with sub-TLVs)along the > mandatory/transitive line of thinking and start to work out what > happens when a router does not understand mandatory/transitory. > Section 12.1 is then largely unnecessary but instead maybe a new > section is in order. Not only get-in-get-out behavior needs to > be precisely specified (but also things like multiple copies of > same TLV, misformatted TLVs, missing required TLVs, sequence of > TLVs, TLV type spaces and so on). This sounds excessive but it > isn't given the fact that this encoding would be a very deep > foundation for many years to come (and well, I'd help to write > it ;-) > > > So, I hope I'm contributing here to clarification of purpose rather than > stultifying ;-) > > thanks > > --- tony > > > > > > > > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From prz@mail.zeta2.ch Mon Nov 11 04:46:20 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A665921E81E8 for ; Mon, 11 Nov 2013 04:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C2xaono5UyL for ; Mon, 11 Nov 2013 04:46:10 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id A373811E80F2 for ; Mon, 11 Nov 2013 04:45:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rABCjZQa003110; Mon, 11 Nov 2013 13:45:35 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7SVvWyNdziSm; Mon, 11 Nov 2013 13:45:34 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rABCjVkv003105 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 13:45:31 +0100 Message-ID: <5280D16B.8030102@zeta2.ch> Date: Mon, 11 Nov 2013 13:45:31 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Anton Smirnov References: <20131107224952.GW4891@spaceboyz.net> <94A203EA12AECE4BA92D42DBFFE0AE47030D9390@eusaamb101.ericsson.se> <20131109211723.GE5311@spaceboyz.net> <527F590A.4080108@zeta2.ch> <527F6012.1000100@cisco.com> <527F62BB.1010707@zeta2.ch> <527F667C.9000309@cisco.com> <527F699A.60103@zeta2.ch> <527F6FE6.8010401@cisco.com> <527F7414.4070004@zeta2.ch> <20131110191200.GF5311@spaceboyz.net> <52800D30.1020703@zeta2.ch> <5280C7F4.50907@cisco.com> In-Reply-To: <5280C7F4.50907@cisco.com> Content-Type: multipart/mixed; boundary="------------090004050000000108010706" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:46:20 -0000 This is a multi-part message in MIME format. --------------090004050000000108010706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/11/2013 01:05 PM, Anton Smirnov wrote: > Hi Tony, > your thoughts, if I understand you correctly, is to propagate some > universally understood handling information in the header of each TLV. > So far in OSPF intention (and to large extent - the practice) was to > verify ability of routers to understand the information in LSAs via > option bits in LLS/RI LSA (and for older features - in option bits in > LSAs and packets). Hey Anton, correct > > BGP, which you gave as an example of protocol with per-TLV handling > information, is p2p protocol with ability to filter and modify > information per-session and per-prefix. nope, there are other types of TLV based IGPs, PNNI & ISIS being some. BGP is aggregating up and that is where the mandatory etc. stuff plays big time. > OSPF, being link-state protocol, should always remember that all > routers in the area share LSDB view. Verifying feature support per-TLV > is not scalable, mechanism of per-router bits works better. I was talking about per router/per TLV. It is as scalable as the scheme today if you assume new TLV=new capability=new bit basically. The only difference is a larger encoding which given today RAM & CPU is peanuts for the big prize of future extensiblity. The 007 TLV is nothing else but an 'infinite-recursive-capabilities-mask' > > So in your "routing on Sundays" example, author of the feature has > a choice of: > - Do not compute "routing on Sundays" until all routers in the scope > support it > - Define "routing on Sundays" computation algorithm to avoid routers > not supporting it > - etc. etc. > This is all possible and doesn't require per-TLV handling bits. think through it. let's use: A - old router, no new-TLV support B - new routers, new TLV-support new-TLV is mandatory for SPF you have two cases: . A does NOT compute through B, this is achievable only by seeing mandatory bit on a TLV B advertises on e.g. an interface . B does NOT compute through A, this is ONLY possible if you have the TLV-mask of A, otherwise how do you know A does NOT support the TLV (and yes, you can think about a 'capabilities' mask instead of a 007 TLV). so the condition that you have mandatory bit on a TLV AND you have TLV processing capabilities of every router in the area is NECESSARY AND SUFFICIENT in my opinion. --- tony --------------090004050000000108010706 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------090004050000000108010706-- From acee.lindem@ericsson.com Mon Nov 11 07:24:05 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE44511E817E for ; Mon, 11 Nov 2013 07:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMCQsh3WQIc3 for ; Mon, 11 Nov 2013 07:24:00 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB711E817A for ; Mon, 11 Nov 2013 07:24:00 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-f0-5280f68e716a Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BB.1C.23183.E86F0825; Mon, 11 Nov 2013 16:23:58 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 10:23:57 -0500 From: Acee Lindem To: "ospf@ietf.org" Thread-Topic: IETF-88 OSPF WG Minutes Thread-Index: AQHO3vIJSXfAp/w9iUGEeko6qqEPTg== Date: Mon, 11 Nov 2013 15:23:57 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030DB390@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030DB390eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPrG7ft4Ygg30XJSxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp0Dp9gKengqTn1aytbAeJWri5GTQ0LARGL92cfsELaYxIV7 69lAbCGBI4wS61d5dTFyAdnLGSX2zZ7HApJgE9CReP7oHzOILSKgLLFlbz9Yg7CAgsTRlh6g QRxAcVWJx33KECV6Ei/urmEFsVmAwsc75zCC2LwCvhJvDh0Ba2UE2vv91BomEJtZQFzi1pP5 TBD3CEgs2XOeGcIWlXj5+B/YHFGgmd2zlrNCxJUlljzZzwLRmy+xZ+0+Noj5ghInZz5hmcAo PAvJ2FlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGOoXmuJaTOPMCGrWcDIsYqRo7Q4tSw3 3chgEyMwTo5JsOnuYNzz0vIQozQHi5I475e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GHM7isOf9Vu7vIq2ljLsdu1wXG/YkqR6wfuYla4Vr+ODmuk2r8QvbJ3w3GfSNtd/3SJuYVcF ShQ/1kQuq7q3NT2vU0m4rW/78Z8VNx3/ukowrV7x+sWfozO3egY7zzrwsPgpW0t3wR5dDtlF 8206+q3ykrufa4XdTHu9v+F1yk15+6/T/hidVmIpzkg01GIuKk4EAKC02ddhAgAA Subject: [OSPF] IETF-88 OSPF WG Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 15:24:06 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030DB390eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've posted the meeting minutes. Thanks to Alia Atlas for taking them. Plea= se unicast me any additions or correction. http://www.ietf.org/proceedings/88/minutes/minutes-88-ospf The discussion was quite lively at times. Let's keep this momentum on the m= ailing list. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE47030DB390eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I've posted the meeting minutes. Thanks to Alia Atlas for taking them.= Please unicast me any additions or correction. 


The discussion was quite lively at times. Let's keep this momentum on = the mailing list. 

Thanks,
Acee 
--_000_94A203EA12AECE4BA92D42DBFFE0AE47030DB390eusaamb101erics_-- From acee.lindem@ericsson.com Mon Nov 11 08:58:10 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7821E8064 for ; Mon, 11 Nov 2013 08:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXEtR-aIEXdS for ; Mon, 11 Nov 2013 08:58:04 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5578A11E8128 for ; Mon, 11 Nov 2013 08:58:04 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-46-52810c9a50c4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 94.33.04556.A9C01825; Mon, 11 Nov 2013 17:58:02 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 11:57:59 -0500 From: Acee Lindem To: "A. Przygienda" , Anton Smirnov , David Lamparter Thread-Topic: [OSPF] OSPFv3 E-LSA compatibility cases Thread-Index: AQHO3Auypltug3S4WU+oA/IPU8rhnZob1R2AgAHoyACAANT3AIAACGIAgAADK4CAAAR6AIAAA7cAgAAHggCAAAT8AIAAehgAgAA8bQCAAN6kAIAAC0mA///AagA= Date: Mon, 11 Nov 2013 16:57:58 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030DB4C8@eusaamb101.ericsson.se> In-Reply-To: <5280D16B.8030102@zeta2.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXSPt+4snsYgg54pGhYt21gt1jRuYLZo uXeP3WLJjonMDiweU35vZPX4slfKY8mSn0wet24vZw1gieKySUnNySxLLdK3S+DKaFu3lr3g h1RFR/8jlgbGHaJdjJwcEgImEt/+rGeHsMUkLtxbz9bFyMUhJHCEUWJz6yNGkISQwHJGiYnN UiA2m4COxPNH/5hBbBGBYoklcyaxgtjMAsoSj7tWs4HYwkBDr0zbzApRYyrx+vEhJpChIgJd jBK7Ds8CaubgYBFQleg4VwNSwyvgK7HtxgkWEJtTQEPixexNYHMYgQ76fmoNE8R8cYlbT+Yz QRwqILFkz3lmCFtU4uXjf2C7RAX0JLpnLWeFiCtLLHmynwWiV0diwe5PbCBrmQWsJXb9yoMI a0ssW/iaGeIEQYmTM5+wTGAUn4Vk2ywk3bMQumch6Z6FpHsBI+sqRo7S4tSy3HQjw02MwKg7 JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDMyDon07i3 Q+td+8wWweSqlbyXHN6cUCn4urLOfavJ88OZvkv5RSLYfdaeUF4TeF9bxPGTzgfTtOurHSoP bNQ50ffCbM7eDN8fXqendG6dbuwt5LvmiLK/k1bkn/tbAtqCd+i++6tm2ntTn+X3Gr9cLb1V 6q06s1T8mA0ezmCVfOPIIidjdEWJpTgj0VCLuag4EQAqdvO9iAIAAA== Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 16:58:11 -0000 While this is an interesting discussion, I don't believe this level of complexity is needed or even desirable. Here are the reasons: =20 1. OSPF is an IGP and is under a single administrative domain. Hence, you have complete control over what features you deploy. 2. OSPF LSAs are flooded unchanged. This is different than BGP where routes are re-advertised with attribute changes. One could argue that there is readvertisement at the ABR. However, this is best handled by policy on the ABR rather than having the ABR generically propagate attributes it may or may not understand. 3. OSPF has been used for TE and GMPLS path computation without any requirement for these confusing TLV/sub-TLV mechanisms. In the case of GMPLS, we have added support for many types of optical networks and have not required mechanisms such as those discussed this E-mail thread. Thanks, Acee=20 On 11/11/13 4:45 AM, "A. Przygienda" wrote: >On 11/11/2013 01:05 PM, Anton Smirnov wrote: >> Hi Tony, >> your thoughts, if I understand you correctly, is to propagate some >> universally understood handling information in the header of each TLV. >> So far in OSPF intention (and to large extent - the practice) was to >> verify ability of routers to understand the information in LSAs via >> option bits in LLS/RI LSA (and for older features - in option bits in >> LSAs and packets). >Hey Anton, correct >> >> BGP, which you gave as an example of protocol with per-TLV handling >> information, is p2p protocol with ability to filter and modify >> information per-session and per-prefix. >nope, there are other types of TLV based IGPs, PNNI & ISIS being some. >BGP is aggregating up and that is where the mandatory etc. stuff plays >big time. >> OSPF, being link-state protocol, should always remember that all >> routers in the area share LSDB view. Verifying feature support per-TLV >> is not scalable, mechanism of per-router bits works better. >I was talking about per router/per TLV. It is as scalable as the scheme >today if you assume new TLV=3Dnew capability=3Dnew bit basically. The on= ly >difference is a larger encoding which given today >RAM & CPU is peanuts for the big prize of future extensiblity. The 007 >TLV is nothing else but an 'infinite-recursive-capabilities-mask' >> >> So in your "routing on Sundays" example, author of the feature has >> a choice of: >> - Do not compute "routing on Sundays" until all routers in the scope >> support it >> - Define "routing on Sundays" computation algorithm to avoid routers >> not supporting it >> - etc. etc. >> This is all possible and doesn't require per-TLV handling bits. > >think through it. > >let's use: > >A - old router, no new-TLV support >B - new routers, new TLV-support > >new-TLV is mandatory for SPF > >you have two cases: > >. A does NOT compute through B, this is achievable only by seeing >mandatory bit on a TLV B advertises on e.g. an interface >. B does NOT compute through A, this is ONLY possible if you have the >TLV-mask of A, otherwise how do you know A does NOT support the TLV (and >yes, you can think about a 'capabilities' mask instead of a 007 TLV). > >so the condition that you have mandatory bit on a TLV AND you have TLV >processing capabilities of every router in the area is NECESSARY AND >SUFFICIENT in my opinion. > >--- tony > From equinox@spaceboyz.net Mon Nov 11 12:30:34 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7F711E8112 for ; Mon, 11 Nov 2013 12:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdeNkcmYzR1g for ; Mon, 11 Nov 2013 12:30:32 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1411E817D for ; Mon, 11 Nov 2013 12:30:31 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1Vfy7q-0006Jn-IO; Mon, 11 Nov 2013 21:30:22 +0100 Date: Mon, 11 Nov 2013 21:30:22 +0100 From: David Lamparter To: "A. Przygienda" Message-ID: <20131111203022.GG5311@spaceboyz.net> References: <5280D16B.8030102@zeta2.ch> <94A203EA12AECE4BA92D42DBFFE0AE47030DB4C8@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030DB4C8@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:30:34 -0000 On Mon, Nov 11, 2013 at 04:57:58PM +0000, Acee Lindem wrote: > While this is an interesting discussion, I don't believe this level of > complexity is needed or even desirable. Here are the reasons: > > 1. OSPF is an IGP and is under a single administrative domain. Hence, > you have complete control over what features you deploy. > 2. OSPF LSAs are flooded unchanged. This is different than BGP where > routes are re-advertised with attribute changes. One could argue that > there is readvertisement at the ABR. However, this is best handled by > policy on the ABR rather than having the ABR generically propagate > attributes it may or may not understand. > 3. OSPF has been used for TE and GMPLS path computation without any > requirement for these confusing TLV/sub-TLV mechanisms. In the case of > GMPLS, we have added support for many types of optical networks and have > not required mechanisms such as those discussed this E-mail thread. +1. Additionally: > On 11/11/13 4:45 AM, "A. Przygienda" wrote: > >let's use: > > > >A - old router, no new-TLV support > >B - new routers, new TLV-support > > > >new-TLV is mandatory for SPF > > > >you have two cases: > > > >. A does NOT compute through B, this is achievable only by seeing > >mandatory bit on a TLV B advertises on e.g. an interface > >. B does NOT compute through A, this is ONLY possible if you have the > >TLV-mask of A, otherwise how do you know A does NOT support the TLV (and > >yes, you can think about a 'capabilities' mask instead of a 007 TLV). This is not correct, or rather incomplete. It is sufficient if B has knowledge of A's supported feature set through other means, i.e. Router Information LSA. It is not neccessary to include this information along with every single TLV/E-LSA. > >so the condition that you have mandatory bit on a TLV AND you have TLV > >processing capabilities of every router in the area is NECESSARY AND > >SUFFICIENT in my opinion. Yes, you need to know which router supports which features. We're already doing that. We still do not have a reasonable use case for per-TLV mandatory/... bits. Actually, your argument works quite well as an argument that we do _not_ need them. As you said, knowing the TLV processing capabilities of each router is not only neccessary, but also _sufficient_. Therefore, it is sufficient if we know these capabilites from the RI LSA. -David From prz@mail.zeta2.ch Mon Nov 11 12:57:40 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7565E11E8103 for ; Mon, 11 Nov 2013 12:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acfJVjFl1jsW for ; Mon, 11 Nov 2013 12:57:35 -0800 (PST) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id D0E1321E8090 for ; Mon, 11 Nov 2013 12:57:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rABKur3G004403; Mon, 11 Nov 2013 21:56:53 +0100 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xqe8CLIiGpVw; Mon, 11 Nov 2013 21:56:51 +0100 (CET) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.219]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id rABKumJ3004398 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 21:56:49 +0100 Message-ID: <52814490.6050109@zeta2.ch> Date: Mon, 11 Nov 2013 21:56:48 +0100 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Lamparter References: <5280D16B.8030102@zeta2.ch> <94A203EA12AECE4BA92D42DBFFE0AE47030DB4C8@eusaamb101.ericsson.se> <20131111203022.GG5311@spaceboyz.net> In-Reply-To: <20131111203022.GG5311@spaceboyz.net> Content-Type: multipart/mixed; boundary="------------080403010606020003090804" Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv3 E-LSA compatibility cases X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:57:40 -0000 This is a multi-part message in MIME format. --------------080403010606020003090804 Content-Type: multipart/alternative; boundary="------------060107000207020908060406" --------------060107000207020908060406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/11/2013 09:30 PM, David Lamparter wrote: > On Mon, Nov 11, 2013 at 04:57:58PM +0000, Acee Lindem wrote: >> While this is an interesting discussion, I don't believe this level of >> complexity is needed or even desirable. Here are the reasons: >> >> 1. OSPF is an IGP and is under a single administrative domain. Hence, >> you have complete control over what features you deploy. >> 2. OSPF LSAs are flooded unchanged. This is different than BGP where >> routes are re-advertised with attribute changes. One could argue that >> there is readvertisement at the ABR. However, this is best handled by >> policy on the ABR rather than having the ABR generically propagate >> attributes it may or may not understand. >> 3. OSPF has been used for TE and GMPLS path computation without any >> requirement for these confusing TLV/sub-TLV mechanisms. In the case of >> GMPLS, we have added support for many types of optical networks and have >> not required mechanisms such as those discussed this E-mail thread. > +1.\ fair 'nuff, let us drop that path of inquiry then. As closing remarks then from my side: The current draft with old-style-new-style compatibility modes are still a rather dangerous path to take long-term I would venture to say [for exactly the reasons Acee spelled out in first mail] and ext-lsa will serve today no other purpose but being a little bit more convienent than opaques for the price of redundant encoding (and allow later new TLVs as long they do not touch spf/reach/redist or otherwise the presence of the TLVs must be indicated in the router cap bitmask again which will turn out an incomplete solution without the mandatory bit on TLVs then as far I can foresee). So IMHO it should be spelled out in the draft that in case new TLVs are introduced into this encoding and influence spf/reach/redist the behavior of routers supporting them must include backwards-compatiblity with routers not supporting them. > > Additionally: > >> On 11/11/13 4:45 AM, "A. Przygienda" wrote: >>> let's use: >>> >>> A - old router, no new-TLV support >>> B - new routers, new TLV-support >>> >>> new-TLV is mandatory for SPF >>> >>> you have two cases: >>> >>> . A does NOT compute through B, this is achievable only by seeing >>> mandatory bit on a TLV B advertises on e.g. an interface >>> . B does NOT compute through A, this is ONLY possible if you have the >>> TLV-mask of A, otherwise how do you know A does NOT support the TLV (and >>> yes, you can think about a 'capabilities' mask instead of a 007 TLV). > This is not correct, or rather incomplete. > > It is sufficient if B has knowledge of A's supported feature set through > other means, i.e. Router Information LSA. It is not neccessary to > include this information along with every single TLV/E-LSA. we misunderstood somehow. I did *not* intend that a mask should be included with every TLV (that would be silly), only once in the router TLV (like I said it's nothing else but infinite router cap mask). >>> so the condition that you have mandatory bit on a TLV AND you have TLV >>> processing capabilities of every router in the area is NECESSARY AND >>> SUFFICIENT in my opinion. > Yes, you need to know which router supports which features. We're > already doing that. We still do not have a reasonable use case for > per-TLV mandatory/... bits. > > Actually, your argument works quite well as an argument that we do _not_ > need them. As you said, knowing the TLV processing capabilities of each > router is not only neccessary, but also _sufficient_. Therefore, it is > sufficient if we know these capabilites from the RI LSA. > yepp, again here we agree, I think my wording came across wrong but I fail to see where. Nevermind & thanks for thinking with me & keeping it all straight --- tony --------------060107000207020908060406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/11/2013 09:30 PM, David Lamparter wrote:
On Mon, Nov 11, 2013 at 04:57:58PM +0000, Acee Lindem wrote:

While this is an interesting discussion, I don't believe this level of
complexity is needed or even desirable. Here are the reasons:
   
     1. OSPF is an IGP and is under a single administrative domain. Hence,
you have complete control over what features you deploy.
     2. OSPF LSAs are flooded unchanged. This is different than BGP where
routes are re-advertised with attribute changes. One could argue that
there is readvertisement at the ABR. However, this is best handled by
policy on the ABR rather than having the ABR generically propagate
attributes it may or may not understand.
     3. OSPF has been used for TE and GMPLS path computation without any
requirement for these confusing TLV/sub-TLV mechanisms. In the case of
GMPLS, we have added support for many types of optical networks and have
not required mechanisms such as those discussed this E-mail thread.

+1.\
fair 'nuff, let us drop that path of inquiry then.

As closing remarks then from my side:

The current draft with
old-style-new-style compatibility modes are still a rather dangerous path to take
long-term I would venture to say [for exactly the reasons Acee spelled out in first mail] and ext-lsa
will serve today no other purpose but being a little bit more convienent than opaques for the
price of redundant encoding (and allow
later new TLVs as long they do not touch spf/reach/redist or otherwise the presence
of the TLVs must be indicated in the router cap bitmask again which will turn out
an incomplete solution without the mandatory bit on TLVs then as far I can foresee).  

So IMHO it should be spelled out in the draft that in case new TLVs are introduced into
this encoding
and influence spf/reach/redist the behavior of routers supporting them must include
backwards-compatiblity with routers not supporting them.
 

Additionally: 


On 11/11/13 4:45 AM, "A. Przygienda" <prz@mail.zeta2.ch> wrote:

let's use:

A - old router, no new-TLV support
B - new routers, new TLV-support

new-TLV is mandatory for SPF

you have two cases:

. A does NOT compute through B, this is achievable only by seeing
mandatory bit on a TLV B advertises on e.g. an interface
. B does NOT compute through A, this is ONLY possible if you have the
TLV-mask of A, otherwise how do you know A does NOT support the TLV (and
yes, you can think about a 'capabilities' mask instead of a 007 TLV).

This is not correct, or rather incomplete.

It is sufficient if B has knowledge of A's supported feature set through
other means, i.e. Router Information LSA.  It is not neccessary to
include this information along with every single TLV/E-LSA.
we misunderstood somehow. I did not intend that a mask should be included with every TLV (that would be silly), only once in
the router TLV (like I said it's nothing else but infinite router cap mask).  
so the condition that you have mandatory bit on a TLV  AND  you have TLV
processing capabilities of every router in the area is NECESSARY AND
SUFFICIENT in my opinion.

Yes, you need to know which router supports which features.  We're
already doing that.  We still do not have a reasonable use case for
per-TLV mandatory/... bits.

Actually, your argument works quite well as an argument that we do _not_
need them.  As you said, knowing the TLV processing capabilities of each
router is not only neccessary, but also _sufficient_.  Therefore, it is
sufficient if we know these capabilites from the RI LSA.

yepp, again here we agree, I think my wording came across wrong but I fail to see where.
Nevermind & thanks for thinking with me & keeping it all straight


--- tony
--------------060107000207020908060406-- --------------080403010606020003090804 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------080403010606020003090804-- From acee.lindem@ericsson.com Wed Nov 13 15:26:30 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BA121E80B9 for ; Wed, 13 Nov 2013 15:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc8XCw09YVoi for ; Wed, 13 Nov 2013 15:26:24 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 302DC21E8094 for ; Wed, 13 Nov 2013 15:26:24 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-b9-52840a9dfde5 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 73.E7.23183.D9A04825; Thu, 14 Nov 2013 00:26:21 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 18:26:21 -0500 From: Acee Lindem To: "ospf@ietf.org" Thread-Topic: Updated IETF 88 Minutes Thread-Index: AQHO4MfCnfEBoJB1pUCMI8IProQq1A== Date: Wed, 13 Nov 2013 23:26:19 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030E097F@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030E097Feusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyuXRPiO5crpYgg2lt1hYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoEro2HxBsaCBVwVV49tY25gnM7ZxcjJISFgInHo6lNGCFtM4sK9 9WxdjFwcQgJHGCUa3x5nhXCWM0rcvXOJBaSKTUBH4vmjf8wgtoiAssSWvf1sILawgKLEgx0/ 2CDiahJ9ffeZIGw9iZ0LF4PVswioSmw6/ZodxOYV8JVY1dgDtpkRaPP3U2vA6pkFxCVuPZnP BHGRgMSSPeeZIWxRiZeP/7GC2KJAM7tnLWeFiCtLLHmynwWiN1/i/+9trBDzBSVOznzCMoFR eBaSsbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdAvRxAtrXEyc+ZyEoWMHKsYuQoLU4t y003MtjECIyUYxJsujsY97y0PMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQZGj+mvT7lHcr49r6u6yqr0V8AktoQ5S5NE1XlrQ9SvFVW9DNT5J/SqdW7ywlre7AUuC4oD osM3z5j365vS0sSk5x7fTwR4nbDuY376MXTd7X1b7G8V/9h3MLD73ZUJS87HhDy5u5qFT8W5 +J7h9djp8+1TDqsVLHzg/1Nl0ZwGvT8ZJaYZPF+WKLEUZyQaajEXFScCAGuWgAdiAgAA Subject: [OSPF] Updated IETF 88 Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:26:31 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030E097Feusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've updated the IETF 88 Minutes with some missing statements filled in reg= arding the two-part metric discussion. http://www.ietf.org/proceedings/88/minutes/minutes-88-ospf Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE47030E097Feusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <3370D15172C8E7419CCEACB2A9E29D69@ericsson.com> Content-Transfer-Encoding: quoted-printable
I've updated the IETF 88 Minutes with some missing statements filled i= n regarding the two-part metric discussion. 


Thanks,
Acee
--_000_94A203EA12AECE4BA92D42DBFFE0AE47030E097Feusaamb101erics_-- From acee.lindem@ericsson.com Mon Nov 18 08:58:12 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74F21F9E37 for ; Mon, 18 Nov 2013 08:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o47oYYu9BZ6v for ; Mon, 18 Nov 2013 08:57:59 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id ECCA711E8160 for ; Mon, 18 Nov 2013 08:57:05 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-8e-528a46df76cc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BA.36.04556.FD64A825; Mon, 18 Nov 2013 17:57:04 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 18 Nov 2013 11:57:02 -0500 From: Acee Lindem To: OSPF List Thread-Topic: NOMCOM - final call for feedback, nominee list Thread-Index: AQHO5H5urOOhbVYNaEywtXRgGD1vBA== Date: Mon, 18 Nov 2013 16:57:01 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030F31CB@eusaamb101.ericsson.se> References: <20131116200445.11352.46676.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030F31CBeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXSPn+4Dt64gg48f+Cxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsszM1kLHnlXLOnwbWB8Z9/FyMkhIWAicXj1KSYIW0ziwr31 bF2MXBxCAkcYJRbs2sIK4SxnlLj+ZikbSBWbgI7E80f/mEFsEQFZiaVL9rOC2MICNhLn9hwD quEAittI3GiVhTD1JG7+8QYxWQRUJe7/MwIp5hXwldjXuQpsiJCAo8SfZ81gNiPQCd9PrQE7 h1lAXOLWk/lQpwlILNlznhnCFpV4+fgfK4StLLHkyX4WiPp8iaNH3jFBzBeUODnzCcsERuFZ SEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceA9VzANnWEg0tOshKFjByrGLkKC1OLctN NzLcxAiMkGMSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG Rj2fqKTZm0SMyy2nT3nzqXhWWNy57lfBx08I3CsVPHV5p47APFk1OQ3d7088Xv0/m8qxbJ9A 8oG7Uyemsz7aenSD3nbpq0+XmhgdPWB6vH5X/LE9XqKhr5XVFTQv253RvfxMddOttA0XzIyv 714/Z9rRts0Pf+zRE3Byn5K/XIH9/pdq3sCV+f1KLMUZiYZazEXFiQB42DxqXgIAAA== Subject: [OSPF] Fwd: NOMCOM - final call for feedback, nominee list X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 16:58:12 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030F31CBeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: From: NomCom Chair 2013 > Date: November 16, 2013 3:04:45 PM EST To: Working Group Chairs > Subject: NOMCOM - final call for feedback, nominee list Reply-To: > Help the Nomcom: this is the last call for general feedback on nominees. This email includes the willing nominee list for your convenience, as per RFC 5680. WG chairs, please forward this email to your WGs. WARNING - DO NOT reply to this email with feedback - the announcement tool provides an unpredictable Reply-To field. You may send mail to nomcom13, but please do continue reading for additional info. The deadline is midnight (any timezone) Wed Nov 20. Enter your feedback into the encrypted nomcom tool at: https://datatracker.ietf.org/nomcom/2013/feedback/ All feedback is confidential. Select individual nominees, or select an area (e.g. INT Multiple) if you want to give feedback on multiple nominees for that area in one entry. The Nomcom will greatly appreciate your concrete and detailed thoughts on nominees. You need to have a datatracker account in order to enter feedback. This is the site to access either to create a datatracker account or to reset the password on an existing account: https://datatracker.ietf.org/accounts/ As we announced last week, we are sharing the names of the willing nominees in this email, as part of our use of RFC 5680 Open List in this nomcom cycle. These names (appearing at the end of the email) have been available within the datatracker since our first call for feedback; we hope some people will be extra encouraged to provide feedback by seeing the names prior to datatracker login. All your feedback must be entered in the encrypted nomcom site (or mailed to nomcom-chair-2013@ietf.org or nomcom13@ietf.org). You may ask the chair or any another nomcom member to submit your feedback without your name attached, if you would prefer. Again, your feedback is absolutely confidential, however delivered. Thanks very much from all of us for your time and for helping the Nomcom to do the best possible job. Also enormous thanks to the willing nominees. Names below. Allison for the Nomcom APP Joe Hildebrand Barry Leiba (incumbent) Yoshiro Yoneya INT Donald Eastlake Wesley George Brian Haberman (incumbent) Ole Troan OPS Benoit Claise (incumbent) Linda Dunbar Victor Kuarsingh Bill Manning RAI Ben Campbell Alissa Cooper Keith Drage Dan Romascanu RTG Loa Andersson Alia Atlas Deborah Brungard Stewart Bryant (incumbent) Donald Eastlake Susan Hares Keyur Patel SEC Derek Atkins Donald Eastlake Jeff Hodges Leif Johansson Alexey Melnikov Kathleen Moriarty Eric Rescorla TSV Martin Stiemerling (incumbent) Dave Taht IAB Bernard Aboba (incumbent) Loa Andersson Alias Atlas Mary Barnes Marc Blanchet (incumbent) Ross Callon (incumbent) Hago Dafalla Linda Dunbar Roni Even Jim Gettys Ted Hardie Susan Hares Joe Hildebrand Sheng Jiang Eliot Lear (incumbent) Larry Masinter S. Moonesamy Kathleen Moriarty Kaveh Ranjbar Robert Sparks Tina Tsou Brian Trammell IAOC/IETF Trust Glenn Deen Tobias Gondrom Chris Griffiths (incumbent) John Levine Tina Tsou --_000_94A203EA12AECE4BA92D42DBFFE0AE47030F31CBeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <674E702C5DF7D04FAB4E8998FA8112B8@ericsson.com> Content-Transfer-Encoding: quoted-printable FYI

Begin forwarded message:

From: NomCo= m Chair 2013 <nomcom-chair= -2013@ietf.org>
Date: Novem= ber 16, 2013 3:04:45 PM EST
To: Worki= ng Group Chairs <wgchairs@ietf.org<= /a>>
Subject: NO= MCOM - final call for feedback, nominee list
Help the Nomcom:  this is the last call for general feedback on nominees. This email includes the willing nominee list for your
convenience, as per RFC 5680. WG chairs, please forward this
email to your WGs.

WARNING - DO NOT reply to this email with feedback - the
announcement tool provides an unpredictable Reply-To field.
You may send mail to nomcom13, but please do continue
reading for additional info.

The deadline is midnight (any timezone) Wed Nov 20.

Enter your feedback into the encrypted nomcom tool at:

https://data= tracker.ietf.org/nomcom/2013/feedback/

All feedback is confidential.

Select individual nominees, or select an area (e.g. INT Multiple) if you want to give feedback on multiple nominees for that area in one entry.

The Nomcom will greatly appreciate your concrete and detailed
thoughts on nominees.

You need to have a datatracker account in order to enter feedback.
This is the site to access either to create a datatracker account or to
reset the password on an existing account:

https://datatracker.ietf.org/accounts/

As we announced last week, we are sharing the names of the willing
nominees in this email, as part of our use of RFC 5680 Open List in this nomcom cycle.  These names (appearing at the end of the email)
have been available within the datatracker since our first call for
feedback; we hope some people will be extra encouraged to provide
feedback by seeing the names prior to datatracker login.   All yo= ur
feedback must be entered in the encrypted nomcom site (or mailed to
nomcom-chair-2013@ietf.org or nomcom13@ietf.org).  You may ask the
chair or any another nomcom member to submit your feedback without
your name attached, if you would prefer.

Again, your feedback is absolutely confidential, however delivered.

Thanks very much from all of us for your time and for helping the
Nomcom to do the best possible job.  Also enormous thanks to the
willing nominees.

Names below.

Allison for the Nomcom

APP
Joe Hildebrand
Barry Leiba (incumbent)
Yoshiro Yoneya

INT
Donald Eastlake
Wesley George
Brian Haberman (incumbent)
Ole Troan

OPS
Benoit Claise (incumbent)
Linda Dunbar
Victor Kuarsingh
Bill Manning

RAI
Ben Campbell
Alissa Cooper
Keith Drage
Dan Romascanu

RTG
Loa Andersson
Alia Atlas
Deborah Brungard
Stewart Bryant (incumbent)
Donald Eastlake
Susan Hares
Keyur Patel

SEC
Derek Atkins
Donald Eastlake
Jeff Hodges
Leif Johansson
Alexey Melnikov
Kathleen Moriarty
Eric Rescorla

TSV
Martin Stiemerling (incumbent)
Dave Taht

IAB
Bernard Aboba (incumbent)
Loa Andersson
Alias Atlas
Mary Barnes
Marc Blanchet (incumbent)
Ross Callon (incumbent)
Hago Dafalla
Linda Dunbar
Roni Even
Jim Gettys
Ted Hardie
Susan Hares
Joe Hildebrand
Sheng Jiang
Eliot Lear (incumbent)
Larry Masinter
S. Moonesamy
Kathleen Moriarty
Kaveh Ranjbar
Robert Sparks
Tina Tsou
Brian Trammell

IAOC/IETF Trust
Glenn Deen
Tobias Gondrom
Chris Griffiths (incumbent)
John Levine
Tina Tsou

--_000_94A203EA12AECE4BA92D42DBFFE0AE47030F31CBeusaamb101erics_-- From acee.lindem@ericsson.com Mon Nov 25 11:19:09 2013 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 028471ADFC0 for ; Mon, 25 Nov 2013 11:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_SAVELE=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 BJ9HKl8JbY8D for ; Mon, 25 Nov 2013 11:19:07 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E573D1ADFFA for ; Mon, 25 Nov 2013 11:19:06 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-bb-5293a2a8d248 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7E.B6.04556.8A2A3925; Mon, 25 Nov 2013 20:19:04 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 14:19:02 -0500 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-ietf-ospf-security-extension-manual-keying-06.txt Thread-Index: AQHO6g/AHPMlLhExu0eAXbb/XnEZBw== Date: Mon, 25 Nov 2013 19:19:02 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703101C99@eusaamb101.ericsson.se> References: <20131125185413.14059.39253.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4703101C99eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPlO6KRZODDL5cM7douXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGdtuPmAqeOFcsWVqF2MD42frLkZODgkBE4krL7cyQthiEhfu rWfrYuTiEBI4wijxbEcTO0hCSGA5o8TSiQUgNpuAjsTzR/+YQWwRAVmJpUv2s4LYwgIpEu1X ZrBDxFMk+ra+YIKw9STOfXvCBmKzCKhKrFrYDBbnFfCVuHTkGRvEfEeJ75c/g/UyAh3x/dQa sBpmAXGJW0/mM0EcJyCxZM95ZghbVOLl43+sELayxJIn+1m6GDmA6vMlzny2hRgvKHFy5hOW CYzCs5BMmoVQNQtJFUSJjsSC3Z/YIGxtiWULXzPD2GcOPGaCsK0lPn78wYKsZgEjxypGjtLi 1LLcdCPDTYzAKDkmwea4g3HBJ8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYCxI2LTkdpmyKK+tzZKAw+I+SpnWYhsm5Dove9dfPLfV1Oz/1pCjnosai/v4F8yX55uQ /YEne+6Jm1sLz/pNDduicqr02y05X6+Tk+O9L1rm2Vj5T0maG9+qNkujlomFfdbEAJ7/qQYt +b8DXS6VXK39mhpptN6uWnTvTK9ZRgkVyQeLzbOvKbEUZyQaajEXFScCABIt4pFgAgAA Subject: [OSPF] Fwd: New Version Notification for draft-ietf-ospf-security-extension-manual-keying-06.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, 25 Nov 2013 19:19:09 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4703101C99eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This version includes the key table clarifications to packet transmission a= nd reception that I talked about in the IETF 88 OSPF WG meeting. Hopefully,= we can WG last call this draft soon. Thanks, Acee Begin forwarded message: From: > Date: November 25, 2013 1:54:13 PM EST To: Manav Bhatia >, Sam Hartman >, Dacheng Zhang >, Acee Lindem > Subject: New Version Notification for draft-ietf-ospf-security-extension-ma= nual-keying-06.txt A new version of I-D, draft-ietf-ospf-security-extension-manual-keying-06.t= xt has been successfully submitted by Manav Bhatia and posted to the IETF repository. Filename: draft-ietf-ospf-security-extension-manual-keying Revision: 06 Title: Security Extension for OSPFv2 when using Manual Key Management Creation date: 2013-11-25 Group: ospf Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-ietf-ospf-securi= ty-extension-manual-keying-06.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ospf-security-e= xtension-manual-keying Htmlized: http://tools.ietf.org/html/draft-ietf-ospf-security-extens= ion-manual-keying-06 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-securit= y-extension-manual-keying-06 Abstract: The current OSPFv2 cryptographic authentication mechanism as defined in RFC 2328 and RFC 5709 is vulnerable to both inter-session and intra-session replay attacks when using manual keying. Additionally, the existing cryptographic authentication schemes do not cover the IP header. This omission can be exploited to carry out various types of attacks. This draft proposes changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation so that we eliminate most attacks that result from OSPFv2 not protecting the IP header. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_94A203EA12AECE4BA92D42DBFFE0AE4703101C99eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <60EDA485A3A72A43842F08AF7F205E18@ericsson.com> Content-Transfer-Encoding: quoted-printable This version includes the key table clarifications to packet transmission a= nd reception that I talked about in the IETF 88 OSPF WG meeting. Hopefully,= we can WG last call this draft soon. 
Thanks,
Acee 

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Novem= ber 25, 2013 1:54:13 PM EST
Subject: Ne= w Version Notification for draft-ietf-ospf-security-extension-manual-keying= -06.txt


A new version of I-D, draft-ietf-ospf-security-extension-manual-keying-06.t= xt
has been successfully submitted by Manav Bhatia and posted to the
IETF repository.

Filename: d= raft-ietf-ospf-security-extension-manual-keying
Revision: 0= 6
Title: Security Extens= ion for OSPFv2 when using Manual Key Management
Creation date: 2013-11-25
Group: ospf
Number of pages: 13
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ie= tf-ospf-security-extension-manual-keying-06.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-ospf-security-extension-man= ual-keying
Htmlized:        http://= tools.ietf.org/html/draft-ietf-ospf-security-extension-manual-keying-06=
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-sec= urity-extension-manual-keying-06

Abstract:
  The current OSPFv2 cryptographic authentication mechanism as de= fined
  in RFC 2328 and RFC 5709 is vulnerable to both inter-session an= d
  intra-session replay attacks when using manual keying.  Ad= ditionally,
  the existing cryptographic authentication schemes do not cover = the IP
  header.  This omission can be exploited to carry out vario= us types of
  attacks.

  This draft proposes changes to the authentication sequence numb= er
  mechanism that will protect OSPFv2 from both inter-session and = intra-
  session replay attacks when using manual keys for securing OSPF= v2
  protocol packets.  Additionally, we also describe some cha= nges in the
  cryptographic hash computation so that we eliminate most attack= s that
  result from OSPFv2 not protecting the IP header.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_94A203EA12AECE4BA92D42DBFFE0AE4703101C99eusaamb101erics_-- From iesg-secretary@ietf.org Tue Nov 26 09:39:56 2013 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 C050E1AE21F; Tue, 26 Nov 2013 09:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm0sdG9kGQdC; Tue, 26 Nov 2013 09:39:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAC21ADF6D; Tue, 26 Nov 2013 09:39:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131126173955.22383.75582.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 09:39:55 -0800 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks) to Experimental RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:39:57 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-12-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature. This document updates RFC5820. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-or/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-or/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2201/