From xuxiaohu@huawei.com Tue Dec 17 17:45:04 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 561971AE031 for ; Tue, 17 Dec 2013 17:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLmsbx2zxuQw for ; Tue, 17 Dec 2013 17:45:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 425981ADFFD for ; Tue, 17 Dec 2013 17:45:02 -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 AZC74599; Wed, 18 Dec 2013 01:44:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 01:43:52 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 01:44:21 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 09:44:17 +0800 From: Xuxiaohu To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-xu-ospf-mpls-elc-00.txt Thread-Index: AQHO+5H/Fj3gwu6IfEqZ+WTiPG2DtJpZLVbQ Date: Wed, 18 Dec 2013 01:44:16 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0823E16F@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.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OSPF] fwd: New Version Notification for draft-xu-ospf-mpls-elc-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 01:45:04 -0000 SGkgYWxsLA0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7 tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQxMuaciDE45pelIDk6MzkNCj4g5pS25Lu2 5Lq6OiBDbGFyZW5jZSBGaWxzZmlsczsgU3JpZ2FuZXNoIEtpbmk7IFh1eGlhb2h1OyBTaXZhIFNp dmFiYWxhbjsgWHV4aWFvaHUNCj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXh1LW9zcGYtbXBscy1lbGMtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXh1LW9zcGYtbXBscy1lbGMtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eQ0KPiBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQteHUtb3NwZi1tcGxzLWVsYw0KPiBSZXZpc2lv bjoJIDAwDQo+IFRpdGxlOgkJIFNpZ25hbGluZyBFbnRyb3B5IExhYmVsIENhcGFiaWxpdHkgVXNp bmcgT1NQRg0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMi0xOA0KPiBHcm91cDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiA0DQo+IFVSTDoNCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtb3NwZi1tcGxzLWVsYy0wMC50eHQN Cj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXh1LW9zcGYtbXBscy1lbGMNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC14dS1vc3BmLW1wbHMtZWxjLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIE11bHRpIFByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgaGFzIGRlZmluZWQgYSBt ZWNoYW5pc20gdG8gbG9hZA0KPiAgICBiYWxhbmNlIHRyYWZmaWMgZmxvd3MgdXNpbmcgRW50cm9w eSBMYWJlbHMgKEVMKS4gIEFuIGluZ3Jlc3MgTFNSDQo+ICAgIGNhbm5vdCBpbnNlcnQgRUxzIGZv ciBwYWNrZXRzIGdvaW5nIGludG8gYSBnaXZlbiB0dW5uZWwgdW5sZXNzIGFuDQo+ICAgIGVncmVz cyBMU1IgaGFzIGluZGljYXRlZCB2aWEgc2lnbmFsaW5nIHRoYXQgaXQgY2FuIHByb2Nlc3MgRUxz IG9uDQo+ICAgIHRoYXQgdHVubmVsLiAgVGhpcyBkcmFmdCBkZWZpbmVzIGEgbWVjaGFuaXNtIHRv IHNpZ25hbCB0aGF0DQo+ICAgIGNhcGFiaWxpdHkgdXNpbmcgT1NQRi4gIFRoaXMgbWVjaGFuaXNt IGlzIHVzZWZ1bCB3aGVuIHRoZSBsYWJlbA0KPiAgICBhZHZlcnRpc2VtZW50IGlzIGFsc28gZG9u ZSB2aWEgT1NQRi4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From acee.lindem@ericsson.com Sat Dec 28 14:37:45 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 4C0C71AE3A8 for ; Sat, 28 Dec 2013 14:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiXva9J2WXeQ for ; Sat, 28 Dec 2013 14:37:42 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B88491AE3A6 for ; Sat, 28 Dec 2013 14:37:42 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-0e-52bf52ad3613 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.58.23183.DA25FB25; Sat, 28 Dec 2013 23:37:34 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0347.000; Sat, 28 Dec 2013 17:37:22 -0500 From: Acee Lindem To: OSPF List Thread-Topic: OSPFv3 E-LSA Compatibility Thread-Index: AQHPBB1foZn+2fbk5kKCz+yBAumuxg== Date: Sat, 28 Dec 2013 22:37:21 +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.6.130613 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_CEE492D324ADBaceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXSPt+66oP1BBkues1q03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA2bljAXLNaqWHLRroHxpWIXIyeHhICJxLO2O6wQtpjEhXvr 2boYuTiEBI4wSlztmc4O4SxnlDjweD1YFZuAjsTzR/+YQWwRAVmJpUv2g8WFBVQkOv7eYOli 5ACKa0qs+6sJUaInsXnRdUYQm0VAVWLb3PPsIDavgKlE74WfTCA2I9Di76fWgNnMAuISt57M Z4I4SEBiyZ7zzBC2qMTLx//AVokCzeyetRzqaGWJ73MesUD0Rklc+buRBWK+oMTJmU9YJjAK z0IydhaSsllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2lphy5Ds7spoFjByrGDlKi1PL ctONDDYxAuPkmASb7g7GPS8tDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoHRbEbTXC3elSuu2n7qO6li1DNv/9PuMMn1Gtwq029fZzPb9/DSTbcnRwsYwnxm1zPkKe7R 4JkksFn7ZejaXKfI7Wdmb1LPTk69tqh+65KeMzOSE0JOauVu918T7tLYJ/uD++Dd/jMmdSWy Zt6P7xV3/nrt/nVqYXCz/6S0Ey8WFc85VONRu+CKEktxRqKhFnNRcSIAqPS4JWECAAA= Subject: [OSPF] OSPFv3 E-LSA Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 22:37:45 -0000 --_000_CEE492D324ADBaceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Given that the authors really don't want to leave a legacy of complexity wi= th the backward compatibility cases. I think we are going to reduce the com= patibility cases to: ExtendedLSASupport This is an enumeration type indicating the extent to which the OSPFv3 instance supports the TLV format described herein for Extended LSAs. The valid value for the enumeration are: * None - Non-extended LSAs will not be originated or used in the SPF calculation. * Normal - Extended LSAs will be originated and adjacencies will not be formed with OSPFv3 routers not supporting this specification. * MixedMode - Both extended and non-extended LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The non-extended LSAs are used for the SPF computation. One thing that occurred to me is that it might be useful to migrate a singl= e area. In this case, one would allow the following modes: AreaExtendedLSASupport This is an enumeration type indicating the extent to which the OSPFv3 area supports the TLV format described herein for Extended LSAs. The valid value for the enumeration are: * None - Non-extended LSAs will not be originated or used in the SPF calculation. * Normal =96 Area and link-local scoped Extended LSAs will be originat= ed and adjacencies will not be formed with OSPFv3 routers in the area not s= upporting this Extended LSAs. AS scoped LSAs will be originated as non-exte= nded LSAs. Thoughts? Thanks, Acee --_000_CEE492D324ADBaceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Given that the authors really don't want to leave a legacy of complexity wi= th the backward compatibility cases. I think we are going to reduce the com= patibility cases to: 

ExtendedLSASupport
      This is an enumeration type indicating the extent to which the
      OSPFv3 instance supports the TLV format described herein for
      Extended LSAs.  The valid value for the enumeration are:

      *  None - Non-extended LSAs will not be originated or used in the
         SPF calculation.

      *  Normal - Extended LSAs will be originated and adjacencies will
         not be formed with OSPFv3 routers not supporting this
         specification.

      *  MixedMode - Both extended and non-extended LSAs will be
         originated.  OSPFv3 adjacencies will be formed with OSPFv3
         routers not supporting this specification.  The non-extended
         LSAs are used for the SPF computation.


One thing that occurred to me is that it might be useful to mi=
grate a single area. In this case, one would allow the following modes: 

AreaExtendedLSASupport
      This is an enumeration type indicating the extent to which the
      OSPFv3 area supports the TLV format described herein for
      Extended LSAs.  The valid value for the enumeration are:

      *  None - Non-extended LSAs will not be originated or used in the
         SPF calculation.


     * Normal =96 Area and link-loca=
l scoped Extended LSAs will be originated and adjacencies will not be forme=
d with OSPFv3 routers in the area not supporting this Extended LSAs. AS sco=
ped LSAs will be originated as non-extended LSAs.  





Thoughts?





Thanks,


Acee






=20
--_000_CEE492D324ADBaceelindemericssoncom_-- From acee.lindem@ericsson.com Sat Dec 28 15:42:43 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 828701AE3F9 for ; Sat, 28 Dec 2013 15:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGZfD9SjJcuA for ; Sat, 28 Dec 2013 15:42:41 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A1E601AE3F7 for ; Sat, 28 Dec 2013 15:42:41 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-46-52bf61eb2f88 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.98.04556.BE16FB25; Sun, 29 Dec 2013 00:42:35 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0347.000; Sat, 28 Dec 2013 18:42:20 -0500 From: Acee Lindem To: OSPF List Thread-Topic: OSPF Topology Transparant Zone Thread-Index: AQHPBCZy3jGHQ/YPik6tFvDzYOUXzA== Date: Sat, 28 Dec 2013 23:42:20 +0000 Message-ID: <6C781C4E-3419-4B86-A807-ECC0BB6423A3@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <525B6FC7831AD948BC7C44BA33730055@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXSPn+7rxP1BBtM7JS1a7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtTPr9gK3vBVvHn1nLWB8S13FyMnh4SAicTVlk3MELaYxIV7 69m6GLk4hASOMEr8XzmJBcJZziixd+8RdpAqNgEdieeP/oF1iAjISixdsp8VxBYW0JBovz2N FSKuK/FqyiGmLkYOIFtP4vxZD5Awi4CqxKtbU9hAbF4Be4k331cxgdiMQIu/n1oDZjMLiEvc ejKfCeIgAYkle85DHScq8fLxP1YIW1ni+5xHLBD1OhILdn9ig7CtJX7+PMkMYWtLLFv4mhli l6DEyZlPWCYwisxCsmIWkvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I8NNjMDAPybB5riDccEn y0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgzJ89dbnf7DsVD7kLe9T/ XIkK92u71C6pJ+9Z2F868US7pu3kb/sXbfOz/v6hYJv1igo7tTXq7un1D8+yXImdwRkaffjA oZUdtVwKcr7PORtrSvboXjI2E3g/yyv8q4eJk07tpUmXhLpvz0v/dnOR18cHG55/MX+RnPDl 5C+2va17b5o1hu5LU2Ipzkg01GIuKk4EALC908RKAgAA Subject: [OSPF] OSPF Topology Transparant Zone X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 23:42:43 -0000 We've discussed this proposal at several IETF meetings now and at IETF 88 w= e committed to more discussion on the list due to the variance in opinions.= I feel that while the TTZ mechanism has some admirable goals. However, I d= on't believe it satisfies its claims and believe this would be apparent if = it were to implemented and deployed.=20 The main goal of TTZ is scalability. However, all the comparisons have no I= P visibility into the TTZ. This begs the question of why the TTZ internal r= outers exist in the first place if there is nothing to be advertised outsid= e the TTZ. Also, even without any connectivity, there is full mesh of P2P c= onnections between TTZ border routers. The LSAs for the border routers will= change every time any P2P cost across the TTZ changes. Thus one is trading= more small LSAs for fewer LSAs that are larger and change more frequently.= This is not necessarily a win.=20 A secondary claim is that the TTZ requires less policy. However, I don't be= lieve it is realistic to have no connectivity inside the TTZ. Hence, we wil= l need some type of policy to control what is and isn't leaked. So, we are = trading a TBD TTZ policy for the area policies that have been deployed for = decades.=20 Given there are no summary LSAs, one will need to advertise these leaked ro= utes as stub networks in the TTZ border router-LSAs. This will further add = to the scaling problems with large frequently changing router-LSAs. IMO, th= is is a very bad tradeoff.=20 There is also a claim of simpler Traffic Engineering. This assumes that the= TTZ border routers perform so unspecified magic to make it all transparent= . It would seem the RSVP signaling would have to somehow be made transparen= t as well as OSPF.=20 Finally, if the core of the TTZ is opaque - how are providers going to mana= ge it?=20 Thanks, Acee = From ppsenak@cisco.com Sun Dec 29 03:22:13 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 598D51AE019 for ; Sun, 29 Dec 2013 03:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qogH5haTwWZf for ; Sun, 29 Dec 2013 03:22:11 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 243551ADFB3 for ; Sun, 29 Dec 2013 03:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2641; q=dns/txt; s=iport; t=1388316126; x=1389525726; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PklyXd7SO70WfRRl6uCn2F53Ubl1KY3Iu/G4SXUldlU=; b=ZqFM1TIq9HYRlth38yykaeSThQGhyzokJFLhmPzLP69/Gcv/XdShbcf/ S0PWlxpiwMuLQ1af2QxWqQiWNFUSy6P1qH+yGX3T7m/56AEVWKGKxRo7o xHfPyLZ7d5tnHfgkVeQSGy/QM9I0NWta+HPrfNWzV0D98KrKmr2zgEjgt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEsFwFKQ/khM/2dsb2JhbABYgws4ui+BFRZ0giUBAQEEAQEBLwEFNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiAANyRATBI8dB4Q2AQOYF4ZFi0+DLjs X-IronPort-AV: E=Sophos;i="4.95,569,1384300800"; d="scan'208";a="2895287" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 29 Dec 2013 11:22:04 +0000 Received: from [10.55.51.196] (ams-ppsenak-8713.cisco.com [10.55.51.196]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBTBM45g031673; Sun, 29 Dec 2013 11:22:04 GMT Message-ID: <52C005DA.7020800@cisco.com> Date: Sun, 29 Dec 2013 12:22:02 +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: Acee Lindem References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: OSPF List Subject: Re: [OSPF] OSPFv3 E-LSA Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 11:22:13 -0000 Hi Acee, some clarification is required in terms of EL-bit setting in various compatibility cases. I assume EL-bit is set only in "Normal" mode. Regarding the AreaExtendedLSASupport, you defined only two modes for it, MixedMode is missing, not sure why. Also, if we keep both global and per area compatibility support, some intersection analysis between the two is required - e.g. do we support 'MixedMode' at global level with 'Normal' at area level - these two contradict each other in terms of adjacency formation with legacy routers. I'm afraid that keeping the compatibility support at two different levels is going to create a lot of confusion. thanks, Peter On 12/28/13 23:37 , Acee Lindem wrote: > Given that the authors really don't want to leave a legacy of complexity > with the backward compatibility cases. I think we are going to reduce > the compatibility cases to: > > ExtendedLSASupport > This is an enumeration type indicating the extent to which the > OSPFv3 instance supports the TLV format described herein for > Extended LSAs. The valid value for the enumeration are: > > * None - Non-extended LSAs will not be originated or used in the > SPF calculation. > > * Normal - Extended LSAs will be originated and adjacencies will > not be formed with OSPFv3 routers not supporting this > specification. > > * MixedMode - Both extended and non-extended LSAs will be > originated. OSPFv3 adjacencies will be formed with OSPFv3 > routers not supporting this specification. The non-extended > LSAs are used for the SPF computation. > > > One thing that occurred to me is that it might be useful to migrate a single area. In this case, one would allow the following modes: > > AreaExtendedLSASupport > This is an enumeration type indicating the extent to which the > OSPFv3 area supports the TLV format described herein for > Extended LSAs. The valid value for the enumeration are: > > * None - Non-extended LSAs will not be originated or used in the > SPF calculation. > > * Normal – Area and link-local scoped Extended LSAs will be originated and adjacencies will not be formed with OSPFv3 routers in the area not supporting this Extended LSAs. AS scoped LSAs will be originated as non-extended LSAs. > > > Thoughts? > > > Thanks, > > Acee > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From huaimo.chen@huawei.com Sun Dec 29 12:21:49 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 B281B1AE1E2 for ; Sun, 29 Dec 2013 12:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y1Uoq89HYSX for ; Sun, 29 Dec 2013 12:21:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7F1AE1DC for ; Sun, 29 Dec 2013 12:21:41 -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 BBZ03427; Sun, 29 Dec 2013 20:21:34 +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; Sun, 29 Dec 2013 20:21:26 +0000 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 29 Dec 2013 20:21:29 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.165]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sun, 29 Dec 2013 12:21:22 -0800 From: Huaimo Chen To: Acee Lindem , OSPF List Thread-Topic: [OSPF] OSPF Topology Transparant Zone Thread-Index: AQHPBCZy3jGHQ/YPik6tFvDzYOUXzJprZAVw Date: Sun, 29 Dec 2013 20:21:21 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C2156E@sjceml501-mbs.china.huawei.com> References: <6C781C4E-3419-4B86-A807-ECC0BB6423A3@ericsson.com> In-Reply-To: <6C781C4E-3419-4B86-A807-ECC0BB6423A3@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OSPF] OSPF Topology Transparant Zone X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 20:21:49 -0000 Hi Acee, Thanks much for your comments! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Saturday, December 28, 2013 6:42 PM To: OSPF List Subject: [OSPF] OSPF Topology Transparant Zone We've discussed this proposal at several IETF meetings now and at IETF 88 w= e committed to more discussion on the list due to the variance in opinions.= I feel that while the TTZ mechanism has some admirable goals. However, I d= on't believe it satisfies its claims and believe this would be apparent if = it were to implemented and deployed.=20 Huaimo:=20 There is a saying: "Hearing about it a hundred times is not better than see= ing it once (seeing is believing)". We will try to implement the TTZ and le= t people seeing its advantages. The main goal of TTZ is scalability. However, all the comparisons have no I= P visibility into the TTZ. This begs the question of why the TTZ internal r= outers exist in the first place if there is nothing to be advertised outsid= e the TTZ. Also, even without any connectivity, there is full mesh of P2P c= onnections between TTZ border routers. The LSAs for the border routers will= change every time any P2P cost across the TTZ changes. Thus one is trading= more small LSAs for fewer LSAs that are larger and change more frequently.= This is not necessarily a win.=20 Huaimo:=20 Splitting a network from one area into multiple areas or from a number of e= xisting areas to even more areas for resolving scalability issue, is a very= challenging task and may raise some new issues.=20 At first, it is a time consuming job. For some networks, it may take more t= han one year. For some networks, it may take a couple of months. Because th= ere are significant changes on network architecture when splitting a networ= k with one area into multiple areas or splitting a network with some existi= ng areas into even more areas. Considering the one area case, originally th= e network has only one area, which is the backbone area. This original back= bone area will be split into a new backbone area and a number of non backbo= ne areas. In general, each of the non backbone areas is connected to the ne= w backbone area through the area border routers between the non backbone ar= ea and the backbone area. There is not any direct connection between any t= wo non backbone areas. Each area border router summarizes the topology of = its attached non backbone area for transmission on the backbone area, and h= ence to all other area border routers. Secondly, service may be interrupted while the network is being split from = one area into multiple areas or from a number of existing areas into even m= ore areas.=20 Moreover, it is complex for MPLS TE tunnel to be set up after the network i= s split. In addition to resolving the scalability issue, the TTZ does not have the a= bove new issues.=20 A secondary claim is that the TTZ requires less policy. However, I don't be= lieve it is realistic to have no connectivity inside the TTZ. Hence, we wil= l need some type of policy to control what is and isn't leaked. So, we are = trading a TBD TTZ policy for the area policies that have been deployed for = decades.=20 Huaimo: It seems that there are two sets of policies at an area border router: one = set for controlling route leak from backbone to non backbone area, the othe= r for controlling route leak from non backbone to backbone area. In TTZ, th= ere is no policy for the former at a TTZ border router. The policy for cont= rolling the route leak from the inside TTZ to outside at a TTZ border route= r may be automatic or semi-automatic. Given there are no summary LSAs, one will need to advertise these leaked ro= utes as stub networks in the TTZ border router-LSAs. This will further add = to the scaling problems with large frequently changing router-LSAs. IMO, th= is is a very bad tradeoff.=20 Huaimo: We will do some analysis on this. If there is any big issue, we will resolv= e it. There is also a claim of simpler Traffic Engineering. This assumes that the= TTZ border routers perform so unspecified magic to make it all transparent= . It would seem the RSVP signaling would have to somehow be made transparen= t as well as OSPF.=20 Huaimo: We are working on TTZ Traffic Engineering part. It seems that RSVP-TE is we= ll fit for the TTZ. The TTZ border routers make the TTZ as a fully messed T= E link connections among the TTZ border routers. The RSVP-TE signaling for = an MPLS TE LSP crossing the TTZ is almost the same as before (the existing = way). It signals the segment of the LSP to the TTZ border router in the sam= e way as before. At this TTZ border router, it just gets the detail TE path= inside the TTZ and then signals the segment of the LSP inside the TTZ to a= nother TTZ border router in the same way as before. From this exit TTZ bord= er router, the RSVP-TE continues to signal the rest of the LSP in the same = way as before. Finally, if the core of the TTZ is opaque - how are providers going to mana= ge it?=20 Huaimo: This is similar to the backbone area. On a router outside of the backbone a= rea, providers cannot see anything inside the backbone area. When they log = in to a (border) router of the backbone area, they can see all the details = about the backbone. On a router outside of the TTZ, providers cannot see an= ything inside the TTZ except for the TTZ border routers. When providers log= in on a TTZ (border) router, they can see all the details about the TTZ.=20 Thanks, Acee=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Dec 30 09:28:26 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 275A31AE2A1 for ; Mon, 30 Dec 2013 09:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBnRw8U5b0oF for ; Mon, 30 Dec 2013 09:28:23 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACD2E1AE227 for ; Mon, 30 Dec 2013 09:28:23 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-35-52c1ad2e58f2 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CE.DB.23183.E2DA1C25; Mon, 30 Dec 2013 18:28:14 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0347.000; Mon, 30 Dec 2013 12:27:58 -0500 From: Acee Lindem To: Peter Psenak Thread-Topic: [OSPF] OSPFv3 E-LSA Compatibility Thread-Index: AQHPBIgs5sAzcXtLSUG/o5I6jWJL75ptU8sA Date: Mon, 30 Dec 2013 17:27:57 +0000 Message-ID: References: <52C005DA.7020800@cisco.com> In-Reply-To: <52C005DA.7020800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="Windows-1252" Content-ID: <54D4B99D590BB14C97AEFFDD573B4C16@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXRPuK7e2oNBBn/6JS1a7t1jt9ixu53N gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYvu8Ic8Fe+Yqfb3YwNTCuluhi5OCQEDCR 2LTSr4uRE8gUk7hwbz1bFyMXh5DAEUaJ9X+uMUE4yxklZv3eyAZSxSagI/H80T9mEFtEQEVi 3vUeFhCbWUBW4tm2JrC4sICexOTnF5hAFogI6EtsuMANUW4kcf30fjaQMIuAqsTjKykgYV4B e4mdnVvApgsJhEjcePkEzOYU0JT41vgabCIj0G3fT61hgtgkLnHryXwmiJsFJJbsOc8MYYtK vHz8jxXCVpb4PucR1GUGEu/PzWcGWcssYC2xbmkwRFhbYtlCiPG8AoISJ2c+YZnAKD4LyYZZ SLpnIXTPQtI9C0n3AkbWVYwcpcWpZbnpRgabGIHRdEyCTXcH456XlocYpTlYlMR5v7x1DhIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaFI13bnYp6rMKnHNY60GkdboZJVtes8C9s/fHb7n uNhtg6745ff3dZ90Xv7kpY54eseZu3EeZYyfwh2mqf7KN9tVt3nxSxMH0wjOvjWaoRuSZwTa 68tcy205sLRRXn7hoTBuQcHNZ4U1Ja5JrJ3S5cV6eWHuy/Azusq2LE82Lanvuy59sO2mEktx RqKhFnNRcSIABuuEWXQCAAA= Cc: OSPF List Subject: Re: [OSPF] OSPFv3 E-LSA Compatibility 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, 30 Dec 2013 17:28:26 -0000 Hi Peter, On Dec 29, 2013, at 6:22 AM, Peter Psenak wrote: > Hi Acee, >=20 > some clarification is required in terms of EL-bit setting in various comp= atibility cases. I assume EL-bit is set only in "Normal" mode. >=20 > Regarding the AreaExtendedLSASupport, you defined only two modes for it, = MixedMode is missing, not sure why. Also, if we keep both global and per ar= ea compatibility support, some intersection analysis between the two is req= uired - e.g. do we support 'MixedMode' at global level with 'Normal' at are= a level - these two contradict each other in terms of adjacency formation w= ith legacy routers. We could support all three values at the area level as well. My intention i= s that the area setting would take precedence over the global level for are= a/link-local scoped LSAs in the area and area adjacency formation. I see wh= at you mean about a contradiction. Let me see if I can clear it up. AreaExtendedLSASupport * Global - Support for Extended LSAs is controlled by the value of Exten= dedLSASupport. * Normal - Extended LSAs will be originated for Area and Link-local scop= ed LSAs within the area. Adjacencies are not formed with Routers not suppor= ting the Extended LSAs. The handling of AS External LSA is controlled by th= e value of ExtendedLSASupport.=20 * MixedMode - Both extended and non-extended LSAs will be originated fo= r Area and Link-local scoped LSAs within the area. Adjacencies are not form= ed with Routers not supporting the Extended LSAs. The handling of AS Extern= al LSA is controlled by the value of ExtendedLSASupport.=20 >=20 > I'm afraid that keeping the compatibility support at two different levels= is going to create a lot of confusion. I don't want to add more confusion. I was merely looking for a way to migra= te one area at a time to the extended LSA format.=20 Thanks, Acee=20 >=20 > thanks, > Peter >=20 >=20 > On 12/28/13 23:37 , Acee Lindem wrote: >> Given that the authors really don't want to leave a legacy of complexity >> with the backward compatibility cases. I think we are going to reduce >> the compatibility cases to: >>=20 >> ExtendedLSASupport >> This is an enumeration type indicating the extent to which the >> OSPFv3 instance supports the TLV format described herein for >> Extended LSAs. The valid value for the enumeration are: >>=20 >> * None - Non-extended LSAs will not be originated or used in the >> SPF calculation. >>=20 >> * Normal - Extended LSAs will be originated and adjacencies will >> not be formed with OSPFv3 routers not supporting this >> specification. >>=20 >> * MixedMode - Both extended and non-extended LSAs will be >> originated. OSPFv3 adjacencies will be formed with OSPFv3 >> routers not supporting this specification. The non-extended >> LSAs are used for the SPF computation. >>=20 >>=20 >> One thing that occurred to me is that it might be useful to migrate a si= ngle area. In this case, one would allow the following modes: >>=20 >> AreaExtendedLSASupport >> This is an enumeration type indicating the extent to which the >> OSPFv3 area supports the TLV format described herein for >> Extended LSAs. The valid value for the enumeration are: >>=20 >> * None - Non-extended LSAs will not be originated or used in the >> SPF calculation. >>=20 >> * Normal =96 Area and link-local scoped Extended LSAs will be origi= nated and adjacencies will not be formed with OSPFv3 routers in the area no= t supporting this Extended LSAs. AS scoped LSAs will be originated as non-e= xtended LSAs. >>=20 >>=20 >> Thoughts? >>=20 >>=20 >> Thanks, >>=20 >> Acee >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >=20 From ppsenak@cisco.com Mon Dec 30 09:48:13 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 7E3E11AE19A for ; Mon, 30 Dec 2013 09:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmzyaldmKJDA for ; Mon, 30 Dec 2013 09:48:10 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8456C1AE0E7 for ; Mon, 30 Dec 2013 09:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4325; q=dns/txt; s=iport; t=1388425685; x=1389635285; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J1nup2cv4Pm6UASg1iWVavTyLtHHst+fgwcigLBLtPI=; b=mDVe1DqNOoBfU2/z3zUXXZksr1Np1AG14K3jpCWv/ocxV4S8OUwH+gaM j91w1Es7/yNmy2NWtVH/sRCibuNeRwzqFGY81z0zO/uVyJVbo3mjd2kG4 nNl7lWGE4dWfubJe3jxosMCtebf2+lhwc4jfBS/w4BXwHUlyFhCcyFgS5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJGwwVKQ/khR/2dsb2JhbABYgws4uj6BGxZ0giUBAQEDAQEBAS8BBTYKARALGAkWDwkDAgECARUwBg0BBQIBAYd4CA3ICBMEjx0HhDYBA5gXhkWLT4MuOw X-IronPort-AV: E=Sophos;i="4.95,574,1384300800"; d="scan'208";a="2956234" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 30 Dec 2013 17:48:03 +0000 Received: from [10.55.51.196] (ams-ppsenak-8713.cisco.com [10.55.51.196]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBUHm1je030091; Mon, 30 Dec 2013 17:48:01 GMT Message-ID: <52C1B1CC.2000004@cisco.com> Date: Mon, 30 Dec 2013 18:47:56 +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: Acee Lindem References: <52C005DA.7020800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: OSPF List Subject: Re: [OSPF] OSPFv3 E-LSA Compatibility 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, 30 Dec 2013 17:48:13 -0000 Hi Acee, On 12/30/13 18:27 , Acee Lindem wrote: > Hi Peter, > > On Dec 29, 2013, at 6:22 AM, Peter Psenak wrote: > >> Hi Acee, >> >> some clarification is required in terms of EL-bit setting in various compatibility cases. I assume EL-bit is set only in "Normal" mode. can you please clarify the EL-bit setting in various compatibility modes? >> >> Regarding the AreaExtendedLSASupport, you defined only two modes for it, MixedMode is missing, not sure why. Also, if we keep both global and per area compatibility support, some intersection analysis between the two is required - e.g. do we support 'MixedMode' at global level with 'Normal' at area level - these two contradict each other in terms of adjacency formation with legacy routers. > > We could support all three values at the area level as well. My intention is that the area setting would take precedence over the global level for area/link-local scoped LSAs in the area and area adjacency formation. I see what you mean about a contradiction. Let me see if I can clear it up. I see. > > > AreaExtendedLSASupport > > * Global - Support for Extended LSAs is controlled by the value of ExtendedLSASupport. > * Normal - Extended LSAs will be originated for Area and Link-local scoped LSAs within the area. Adjacencies are not formed with Routers not supporting the Extended LSAs. The handling of AS External LSA is controlled by the value of ExtendedLSASupport. > * MixedMode - Both extended and non-extended LSAs will be originated for Area and Link-local scoped LSAs within the area. Adjacencies are not formed with Routers not supporting the Extended LSAs. The handling of AS External LSA is controlled by the value of ExtendedLSASupport. should not MixeMode above allow adjacency to be formed with routers not supporting the Extended LSAs? MixedMode at global level allows that, which is what we want. thanks, Peter > >> >> I'm afraid that keeping the compatibility support at two different levels is going to create a lot of confusion. > > I don't want to add more confusion. I was merely looking for a way to migrate one area at a time to the extended LSA format. > > Thanks, > Acee > > > >> >> thanks, >> Peter >> >> >> On 12/28/13 23:37 , Acee Lindem wrote: >>> Given that the authors really don't want to leave a legacy of complexity >>> with the backward compatibility cases. I think we are going to reduce >>> the compatibility cases to: >>> >>> ExtendedLSASupport >>> This is an enumeration type indicating the extent to which the >>> OSPFv3 instance supports the TLV format described herein for >>> Extended LSAs. The valid value for the enumeration are: >>> >>> * None - Non-extended LSAs will not be originated or used in the >>> SPF calculation. >>> >>> * Normal - Extended LSAs will be originated and adjacencies will >>> not be formed with OSPFv3 routers not supporting this >>> specification. >>> >>> * MixedMode - Both extended and non-extended LSAs will be >>> originated. OSPFv3 adjacencies will be formed with OSPFv3 >>> routers not supporting this specification. The non-extended >>> LSAs are used for the SPF computation. >>> >>> >>> One thing that occurred to me is that it might be useful to migrate a single area. In this case, one would allow the following modes: >>> >>> AreaExtendedLSASupport >>> This is an enumeration type indicating the extent to which the >>> OSPFv3 area supports the TLV format described herein for >>> Extended LSAs. The valid value for the enumeration are: >>> >>> * None - Non-extended LSAs will not be originated or used in the >>> SPF calculation. >>> >>> * Normal – Area and link-local scoped Extended LSAs will be originated and adjacencies will not be formed with OSPFv3 routers in the area not supporting this Extended LSAs. AS scoped LSAs will be originated as non-extended LSAs. >>> >>> >>> Thoughts? >>> >>> >>> Thanks, >>> >>> Acee >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> > > . >