From nobody Wed Apr 2 02:22:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9835F1A0169; Wed, 2 Apr 2014 02:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 zx5BhZ2LH2Ka; Wed, 2 Apr 2014 02:22:34 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 703BC1A0187; Wed, 2 Apr 2014 02:22:33 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 52C7F1802AB4; Wed, 2 Apr 2014 11:22:29 +0200 (CEST) Message-ID: <533BD6D8.4010307@pi.nu> Date: Wed, 02 Apr 2014 11:22:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ospf@ietf.org, "ccamp@ietf.org" References: <533BD426.4070909@pi.nu> In-Reply-To: <533BD426.4070909@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/8Ii87dBiQkkqf-RMVWHIATXm_3Y Subject: Re: [OSPF] [mpls] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 09:22:38 -0000 OSPF and CCAMP, A victim typing expansion-tool. The mails to mpls and isis did come through correct, here are the mail to ospf and ccamp. /Loa On 2014-04-02 11:11, Loa Andersson wrote: > OSPF, ISIS and CCAMP working groups, > (mpls wg cc'ed) > > The MPLS working group have requested that > draft-ietf-mpls-extended-admin-group is published as a Standard Tracks RFC. > > The document is through the AD review; as part of the review we have > agreed that we'd like to point out to the OSPF, ISIS and CCAMP working > groups, that any comments should be sent as responses to the upcoming > IETF Last call (the document is in what we hope will be a very > quick and minor update). > > /Loa > for the mpls wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Apr 2 08:38:21 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111091A028B; Wed, 2 Apr 2014 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 f4swy4KSyuTx; Wed, 2 Apr 2014 08:38:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 70F0E1A028A; Wed, 2 Apr 2014 08:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2728; q=dns/txt; s=iport; t=1396453084; x=1397662684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X/uqgHWL8tFMm9k2+jjTbs9XsbCTtRhAazSx34c0E28=; b=BDcDov8Yi3Ge8Mt+Js1iwxTE7rT7bUhwFzZ/NG/Gv9oo41YRk/R15jLc c2zNU5NO4k5X6EX4WE8iqqFrLZ4ja+/QXr9O7r6qY3cGlkalq9XYEMtCq Ry15vMwsyUSugxomzGaXnamAmqlxbLazsv+QpQU1nCmd1I8Lpj8kUKftR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHktPFOtJV2c/2dsb2JhbABZgwY7V7wyhzWBHhZ0giUBAQEEAQEBNzEDCwwCAgIBCBEEAQELFAkHGwwLFAkIAgQBDQUIh3ENzx0TBASOChEBHzEHBoMegRQEqw+DMIFyOQ X-IronPort-AV: E=Sophos;i="4.97,780,1389744000"; d="scan'208";a="314693468" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 02 Apr 2014 15:38:03 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s32Fc35O030000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 15:38:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 10:38:03 -0500 From: "Les Ginsberg (ginsberg)" To: Loa Andersson , "isis-wg@ietf.org" , "ospf@ietf.org" , "ccamp@ietf.org" Thread-Topic: [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group Thread-Index: AQHPTlOLfcaTNk2730i4Eg0EETeVRpr+Y9OA Date: Wed, 2 Apr 2014 15:38:02 +0000 Message-ID: References: <533BD426.4070909@pi.nu> In-Reply-To: <533BD426.4070909@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ZlXE5_MO0uL4-I6MSMqEBSE-fH8 Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" , "VIGOUREUX, MARTIN \(MARTIN\)" Subject: Re: [OSPF] [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 15:38:13 -0000 (Resending w corrected OSPF/CCAMP WG addresses) Loa - In reading Section 2.3.1 the text seems contradictory: If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and SHOULD indicate this mismatch to the operator. If the AG and EAG advertised for a link differ, the EAG MUST take priority. The first quoted paragraph says when there is a conflict "AG SHOULD be used= ". The second quoted paragraph says when there is a conflict "EAG MUST take pr= iority". Which preference is intended?? I would think that AG MUST take priority in such cases - otherwise you will= have inconsistency between legacy nodes and nodes which support EAG. I would also note that conflict could be avoided entirely if you defined th= e EAG to be used only for additional (beyond the currently supported 32 gro= ups) rather than as a superset of AG. This would also eliminate the need to= advertise both AG and EAG solely as a transition strategy. Was this option= considered and if so why was it rejected? (Apologies if this was discussed= on mpls list - I do not routinely follow that list.) Les > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Loa Andersso= n > Sent: Wednesday, April 02, 2014 2:11 AM > To: ospf-request@ietf.org; isis-wg@ietf.org; ccamp-chairs@tools.ietf.org > Cc: mpls@ietf.org; Adrian Farrel; VIGOUREUX, MARTIN (MARTIN); draft-ietf- > mpls-extended-admin-group@tools.ietf.org > Subject: [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-ad= min- > group >=20 > OSPF, ISIS and CCAMP working groups, > (mpls wg cc'ed) >=20 > The MPLS working group have requested that > draft-ietf-mpls-extended-admin-group is published as a Standard Tracks RF= C. >=20 > The document is through the AD review; as part of the review we have > agreed that we'd like to point out to the OSPF, ISIS and CCAMP working > groups, that any comments should be sent as responses to the upcoming > IETF Last call (the document is in what we hope will be a very > quick and minor update). >=20 > /Loa > for the mpls wg co-chairs >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Mon Apr 7 02:57:26 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274241A06E1 for ; Mon, 7 Apr 2014 02:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 s2ct5L1hZF3T for ; Mon, 7 Apr 2014 02:57:20 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4671A06D1 for ; Mon, 7 Apr 2014 02:57:19 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Apr 2014 10:57:07 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 10:57:10 +0100 From: Alan Davey To: "ospf@ietf.org" , "draft-ietf-ospf-ospfv3-lsa-extend@tools.ietf.org" Thread-Topic: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01 Thread-Index: Ac9FAnKI5crrObGLRia8H4bMjVlUZA== Date: Mon, 7 Apr 2014 09:57:10 +0000 Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.10] Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1DBA5EAENFICSMBX1datco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pLOtfecYIqjInwD_oqdTBTv3Ico Subject: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:57:24 -0000 --_000_C2EE31C852049D499842B19FC01C0804C1DBA5EAENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks I have read draft-ietf-ospf-ospfv3-lsa-extend-01 and I think that it looks = good. I have a few comments, mostly minor. Please let me know if you have= any questions on the following. _General Points_ The TLV types are defined with global scope. Therefore, I think it is clea= rer to separate the TLV definitions from the LSA definitions. It may be be= tter to avoid defining limits on the TLV usage in sections defining the LSA= s. For an example of where it would be better to separate the TLV definitions,= in section 11, OSPFv3 E-Intra-Area-Prefix-LSA, there is a reference to TLV= type 6, which is defined in section 10, OSPFv3 E-Link-LSA. For an example of defining limits in the TLV usage in LSA definitions, in s= ection 4: - "0 - Reserved". As the Type values are OSPFv3-global in scope, = should the reserved value be defined in an overall section and not in the s= ection defining the E-Router-LSA? - "The Router-Link TLV is only applicable to the E-Router-LSA. In= clusion in other Extended LSAs MUST be ignored." This is probably true, bu= t seems too limiting. Should the sections defining the LSAs state which TL= Vs are applicable to that LSA, only, and have a default statement that othe= r TLV (and sub-TLV) types SHOULD be ignored? Where multiple sub-TLVs are defined, for example, in section 8, OSPFv3 E-AS= -External-LSA, there should be a statement that the sub-TLVs may be in any = order. _Minor Points, Typos, etc._ Section 1, para 2: s/OSPFv3 LSA/OSPFv3 LSAs/ Section 3, last sentence: "Unrecognized types are ignored." Is there a bet= ter section to put this statement? Section 3 is defining the TLV format an= d not any actions on processing them. Section 4: Should there be a statement that the E-Router-LSA can contain multiple Rout= er-Link TLVs? This is different to RFC 3630, where an LSA can only contain= one top-level TLV and this should be made explicit. Section 5, paragraph 3: s/her/the/? Section 6, paragraph 2: s/Network-LSA/Inter-Area-Prefix-LSA/. Section 8; I suggest NOT specifying the TLV lengths in the format diagrams;= this seems too restrictive. Section 12; paragraph 2, "will contain an additional options bits", s/bits/= bit/? Section 12.1, paragraph 1: s/ exteneded/extended/ and s/ MixedModeOrignateO= nly/ MixedModeOriginateOnly/ Section 12.1, 1.; s/orginate/originate/. Section 12.1.1, paragraph 1; s/In these are/In these areas/. Appendix A, ExtendedLSASupport; s/The valid value/The valid values/ Regards Alan Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_C2EE31C852049D499842B19FC01C0804C1DBA5EAENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks

 

I have read draft-ietf-ospf-ospfv3-lsa-extend-01 and= I think that it looks good.  I have a few comments, mostly minor.&nbs= p; Please let me know if you have any questions on the following.

 

_General Points_

 

The TLV types are defined with global scope.  T= herefore, I think it is clearer to separate the TLV definitions from the LS= A definitions.  It may be better to avoid defining limits on the TLV u= sage in sections defining the LSAs. 

 

For an example of where it would be better to separa= te the TLV definitions, in section 11, OSPFv3 E-Intra-Area-Prefix-LSA, ther= e is a reference to TLV type 6, which is defined in section 10, OSPFv3 E-Li= nk-LSA.

 

For an example of defining limits in the TLV usage i= n LSA definitions, in section 4:

 

-     &= nbsp;    “0 – Reserved”.  As the Type= values are OSPFv3-global in scope, should the reserved value be defined in= an overall section and not in the section defining the E-Router-LSA?<= /o:p>

 

-     &= nbsp;    “The Router-Link TLV is only applicable to th= e E-Router-LSA.  Inclusion in other Extended LSAs MUST be ignored.R= 21;  This is probably true, but seems too limiting.  Should the s= ections defining the LSAs state which TLVs are applicable to that LSA, only, and have a default statement that other TLV (and sub-TLV) = types SHOULD be ignored?

 

Where multiple sub-TLVs are defined, for example, in= section 8, OSPFv3 E-AS-External-LSA, there should be a statement that the = sub-TLVs may be in any order.

 

_Minor Points, Typos, etc._

 

Section 1, para 2: s/OSPFv3 LSA/OSPFv3 LSAs/

 

Section 3, last sentence: “Unrecognized types = are ignored.”  Is there a better section to put this statement?&= nbsp; Section 3 is defining the TLV format and not any actions on processin= g them.

 

Section 4:

 

Should there be a statement that the E-Router-LSA ca= n contain multiple Router-Link TLVs?  This is different to RFC 3630, w= here an LSA can only contain one top-level TLV and this should be made expl= icit.

 

Section 5, paragraph 3: s/her/the/?

 

Section 6, paragraph 2: s/Network-LSA/Inter-Area-Pre= fix-LSA/.

 

Section 8; I suggest NOT specifying the TLV lengths = in the format diagrams; this seems too restrictive.

 

Section 12; paragraph 2, “will contain an addi= tional options bits”, s/bits/bit/?

 

Section 12.1, paragraph 1: s/ exteneded/extended/ an= d s/ MixedModeOrignateOnly/ MixedModeOriginateOnly/

 

Section 12.1, 1.; s/orginate/originate/.<= /p>

 

Section 12.1.1, paragraph 1; s/In these are/In these= areas/.

 

Appendix A, ExtendedLSASupport; s/The valid value/Th= e valid values/

 

Regards

Alan

 

Network Technologies
Metaswitch Networks

 

ala= n.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technolo= gies.metaswitch.com

 

--_000_C2EE31C852049D499842B19FC01C0804C1DBA5EAENFICSMBX1datco_-- From nobody Thu Apr 10 23:30:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5458B1A03FB for ; Thu, 10 Apr 2014 23:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 jTb0g-WRYezk for ; Thu, 10 Apr 2014 23:30:33 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D7C291A0412 for ; Thu, 10 Apr 2014 23:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=323; q=dns/txt; s=iport; t=1397197833; x=1398407433; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=iUP1U5Wo02Xcjg1jYk3yqt0WR95yGMeKb7WYtLTuDq0=; b=kUsiI19DzL8C7ypHGkao3BtWFWJVs9ozWUOxsU6nelhKZUDJwnjx5DwS nmUZCTdz+CYHzPnREgQD7BEHWs6/zksHxECD7XnB4O/T1gLYXU4bDUvF1 s9sYuKX0yaYEuyyuqeEpkH0ypaLRVOHtm54wn3Vp7RaJvAUsQBpDoIvhF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFAEGLR1OrRDoG/2dsb2JhbABZgwasJZkeAQGBIhZ0gmRAPRYEFAMCAQIBSw0IAQGHd5posXcXjhiFEwEDiVuPA4ZTi2+BcYFfHQ X-IronPort-AV: E=Sophos;i="4.97,840,1389744000"; d="scan'208";a="107682423" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Apr 2014 06:30:32 +0000 Received: from [10.21.113.212] (sjc-vpn2-468.cisco.com [10.21.113.212]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3B6UVnN014309 for ; Fri, 11 Apr 2014 06:30:32 GMT Message-ID: <53478C07.1020006@cisco.com> Date: Thu, 10 Apr 2014 23:30:31 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/slZWXUCwHJS0LdpA8In9feKF6Os Subject: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 06:30:38 -0000 All, We are starting a WG LC on the subject document. Document has been stable for a while, and Manav was kind enough to present it one last time in IETF89 (London). LC will end at 9am PST on 25th April 2014. Please review the document and send any final comments prior to the LC deadline. Regards, -Abhay From nobody Thu Apr 10 23:34:23 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2DB1A03FB for ; Thu, 10 Apr 2014 23:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CeSzHpO98ZV for ; Thu, 10 Apr 2014 23:34:19 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DAE5C1A00C2 for ; Thu, 10 Apr 2014 23:34:18 -0700 (PDT) X-AuditID: c6180641-b7f638e000005a82-b2-53478a02a8a4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F8.A7.23170.20A87435; Fri, 11 Apr 2014 08:21:54 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 02:34:17 -0400 From: Uma Chunduri To: Abhay Roy , "ospf@ietf.org" Thread-Topic: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 Thread-Index: AQHPVU+RhokJVBtJnkGjM0tqqGHFSJsL9U8w Date: Fri, 11 Apr 2014 06:34:16 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F2659A5@eusaamb105.ericsson.se> References: <53478C07.1020006@cisco.com> In-Reply-To: <53478C07.1020006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXRPrC5Tl3uwwe6HmhaHD85is2i5d4/d gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4sKuHqeAOW8WLaXfZGhj3sHYxcnJICJhI nD9yF8oWk7hwbz1bFyMXh5DAUUaJrxeaGSGc5YwSpx9vYgSpYhPQk/g49Sc7iC0iYCexZlYD E4gtLLCSUaJvLydIg4jAKkaJjkkbWCGKjCQWNZ0AK2IRUJX4eO45cxcjBwevgK/EsV2BIGEh AQ2JjbPWgs3nFNCUWNn7gw3EZgS66PupNWCtzALiEreezGeCuFRAYsme88wQtqjEy8f/oD5Q kpi09BwrRL2OxILdn9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg5 SotTy3LTjQw3MQLj4ZgEm+MOxgWfLA8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBcYml870VNRsqiuK2nYlvWLd82vQzKUa6YorHHyWruDy7mR+13tCr7femkxMKfzOv nfLmifT/CO38fdMWqlUJ/J92N6qtf9r2Tu/Zj1nizyT9KH+XZbNONvlOEWut7vKVFx/GXlva fnbTtgMvtjvyNokfWtm4pnSlT6/u+epbkstOdT62uy5iLq7EUpyRaKjFXFScCADmSecQVQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OJ_OQMaeRXAjc6gbbFDRcFZ2g8Y Subject: Re: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 06:34:21 -0000 I have gone through this document. Support this for WGLC. -- Uma C. -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Abhay Roy Sent: Thursday, April 10, 2014 11:31 PM To: ospf@ietf.org Subject: [OSPF] Working Group last Call on "Security Extension for OSPFv2 w= hen using Manual Key Management" - draft-ietf-ospf-security-extension-manua= l-keying-07 All, We are starting a WG LC on the subject document. Document has been stable f= or a while, and Manav was kind enough to present it one last time in IETF89= (London). LC will end at 9am PST on 25th April 2014. Please review the document and send any final comments prior to the LC dead= line. Regards, -Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From nobody Tue Apr 15 15:51:43 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60601A0007 for ; Tue, 15 Apr 2014 15:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRUmwVOizH-e for ; Tue, 15 Apr 2014 15:51:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9C11A0024 for ; Tue, 15 Apr 2014 15:51:38 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-ea-534d6984b07b Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 66.AA.05011.4896D435; Tue, 15 Apr 2014 19:16:52 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 15 Apr 2014 18:51:33 -0400 From: Acee Lindem To: OSPF List Thread-Topic: OSPF Draft Discussion Thread-Index: AQHPWP0/MXmfaa7NAE+1LZHibyaYSg== Date: Tue, 15 Apr 2014 22:51:32 +0000 Message-ID: <76E38DC9-EB82-4B5F-A849-DD229B381006@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPgm5Lpm+wwbx+JYuWe/fYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0XlvGXNBJ1PFvfM3mRsYLzJ2MXJySAiYSNz+OIcZwhaTuHBv PVsXIxeHkMBRRok1ffOZIZzljBLPJ+5lB6liE9CReP7oH1iHiICsxNIl+1m7GDk4hAXkJaad SoIIq0hMXvODEcLWk+ieNwHMZhFQldi9byVYK6+AvcSnzcfARjICLf5+ag0TiM0sIC5x68l8 JoiDBCSW7DkPdZyoxMvH/1ghbCWJj7/ns0PUG0i8PzefGcK2llj8bQsrhK0tsWzha6hdghIn Zz5hmcAoMgvJillI2mchaZ+FpH0WkvYFjKyrGDlKi1PLctONDDYxAgP/mASb7g7GPS8tDzEK cDAq8fAK1eQGCLEmlhVX5h5ilOZgURLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD I6txFN/29WJFb2WXqKX9u7EyhkOu7vGTVf80xd4oMLVdeKXN19siWC8U5Mv3UDZ33/PDUsI8 blOP3om+va7yXLHdEd3Zv0Q31mb6Zi79UjbLmacvJbrsHHdGcqj91sDjl+786Pn/JurJ/BVf XYwXtXDzprz0Wbpn+v6z81YVq/ZyNtZxt7y+o8RSnJFoqMVcVJwIAC9o/SBdAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/xFkY8PKGBI_WSCD98wwIszW9Vxk Subject: [OSPF] OSPF Draft Discussion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 22:51:41 -0000 Draft Authors,=20 Don=92t hesitate to initiate discussion of your drafts on the list. There h= ave been a number of drafts that have been presented at the last two IETFs = that we explicitly decided to discuss on this list.=20 Thanks, Abhay and Acee=20 From nobody Wed Apr 16 03:57:17 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478A41A012D for ; Wed, 16 Apr 2014 03:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 sBd06cnWK5lj for ; Wed, 16 Apr 2014 03:57:05 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 685E51A012C for ; Wed, 16 Apr 2014 03:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2523; q=dns/txt; s=iport; t=1397645822; x=1398855422; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ixtM5Ina13ZtHCPxwrp7xayBfnZR3ex0WH6XPE137Ts=; b=WyLaAbzzLUAKA5XX9Ff4p8bVKlWgUsVlgko/7XijTEFgPe+vgGXJqsA+ Qcp8wWxdPZsE81tWIe/pCfofhFATcvI0EJKNanGUhEceAeM1+cDjFoE3c 3fvJv/JoC3mhJC0Di4CDJJ88qzqlCORMzhQvDbQK7Ue7Hij2BsFxOjTl4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEALxhTlOtJssW/2dsb2JhbABZg0FRgxjAIIE4dIIlAQEBBCMVPwENBBwDAQIDAgUWCwICCQMCAQIBPQgGDQYCAQEFEodhCAWkOaMAF4EpjGUyKQaCaYFJAQOUeYNtgTeREoMzOw X-IronPort-AV: E=Sophos;i="4.97,871,1389744000"; d="scan'208";a="14278010" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Apr 2014 10:56:49 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3GAumcV030479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 16 Apr 2014 10:56:49 GMT Message-ID: <534E61F0.4040105@cisco.com> Date: Wed, 16 Apr 2014 12:56:48 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: OSPF List References: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> In-Reply-To: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ANbH7DQOGVg7JJl5gA8szvz0O5A Subject: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 10:57:11 -0000 Hello, authors of this draft would like to solicit feedback. This draft was presented to WG in London and draft was updated couple of days ago to rectify notes received after the presentation. The draft proposes technique how IPv6 routes should be calculated over MPLS TE signaled by OSPFv2. The draft discusses why simple solution to the problem not requiring standardization works most of the time but if it fails it may fail with very big impact to the network and thus unacceptable. But presentation delivered during the meeting discussed this in pictures and in greater length, so if after reading the draft you would still not be convinced simple solution is not good enough I encourage you to review slide deck presented during the meeting. Anton Smirnov -------- Original Message -------- Subject: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt Date: Mon, 14 Apr 2014 13:48:01 -0700 From: A new version of I-D, draft-smirnov-ospf-xaf-te-01.txt has been successfully submitted by Anton Smirnov and posted to the IETF repository. Name: draft-smirnov-ospf-xaf-te Revision: 01 Title: OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels Document date: 2014-04-14 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-smirnov-ospf-xaf-te-01.txt Status: https://datatracker.ietf.org/doc/draft-smirnov-ospf-xaf-te/ Htmlized: http://tools.ietf.org/html/draft-smirnov-ospf-xaf-te-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-smirnov-ospf-xaf-te-01 Abstract: When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This is solved by advertising cross-address family (X-AF) OSPF TE information. This document describes an update to RFC5786 that allows for the easy identification of a router's local X-AF IP addresses. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Apr 17 14:08:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591A21A0119 for ; Thu, 17 Apr 2014 14:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8zLMPJ1XFFM for ; Thu, 17 Apr 2014 14:08:38 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB181A0054 for ; Thu, 17 Apr 2014 14:08:38 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-7e-534ff45f0c04 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 48.AC.05011.F54FF435; Thu, 17 Apr 2014 17:33:51 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 17:08:32 -0400 From: Acee Lindem To: Anton Smirnov Thread-Topic: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt Thread-Index: AQHPWWKkr2iEvctPGUWHpQX02ko1EZsWkqeA Date: Thu, 17 Apr 2014 21:08:32 +0000 Message-ID: <9DEEF3C3-BAAB-4019-82B9-82F5C392A691@ericsson.com> References: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> <534E61F0.4040105@cisco.com> In-Reply-To: <534E61F0.4040105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-ID: <345166D1692BE745BFB8AE582663DFF3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn278F/9gg/NT1S1atrFatNy7x+7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZRy99Yul4L5kxeFXNxgbGD+IdDFyckgImEi0 v3vDDGGLSVy4t56ti5GLQ0jgKKPE7p2PmSCc5YwSPReegVWxCehIPH/0D8wWEVCT2Hz3EyuI zSwgK/FsWxNYXFggWGLmmfesEDUhEi3Nz1m6GDmAbCOJKYvrQcIsAqoSc19MZQexeQXsJaa8 +QXWKiQQL3Fu3XIWEJtTQFPi4v6tYDWMQMd9P7WGCWKVuMStJ/OZII4WkFiy5zzUA6ISLx// Y4WwlSQ+/p7PDlFvIPH+3HxmCNtaovHSH0YIW1ti2cLXzBA3CEqcnPmEZQKj+CwkK2YhaZ+F pH0WkvZZSNoXMLKuYuQoLU4ty003MtjECIypYxJsujsY97y0PMQowMGoxMM75bpvsBBrYllx Ze4hRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLJoeZ5xdUkIqHyaNvWm uRJ757PeRa94lxZ57tha+avtguXK9Uu6X75cIaKW61/l3sinOPHVmoIDf39d8p727Y6O8wRb xx0/f0Rw7Tdex8RQci0uVUfApPHzlDUWxao9Vgf2exS0ROVtaP2xZ7FyuPrmuNI5fJvLY/hK HrFUJVsuF14ZWqmrpMRSnJFoqMVcVJwIAKo6BySKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/wV2jFrReLS8-lLs_kEtPdAFLI-g Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:08:40 -0000 Hi Anton,=20 I think I=92m finally understanding the application of this draft. You stat= e that the OSPF and OSPFv3 domains need not coincide. That is true but they= must at least include the head-end of the LSPs for which you want to compu= te LSP paths. Do you mean this to also apply to multiple instances of the s= ame AF? It would be a very ugly network design where they are part of the s= ame routing domain.=20 Thanks, Acee On Apr 16, 2014, at 6:56 AM, Anton Smirnov wrote: > Hello, > authors of this draft would like to solicit feedback. This draft was pr= esented to WG in London and draft was updated couple of days ago to rectify= notes received after the presentation. > The draft proposes technique how IPv6 routes should be calculated over = MPLS TE signaled by OSPFv2. >=20 > The draft discusses why simple solution to the problem not requiring st= andardization works most of the time but if it fails it may fail with very = big impact to the network and thus unacceptable. But presentation delivered= during the meeting discussed this in pictures and in greater length, so if= after reading the draft you would still not be convinced simple solution i= s not good enough I encourage you to review slide deck presented during the= meeting. >=20 > Anton Smir > -------- Original Message -------- > Subject: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt > Date: Mon, 14 Apr 2014 13:48:01 -0700 > From: >=20 >=20 > A new version of I-D, draft-smirnov-ospf-xaf-te-01.txt > has been successfully submitted by Anton Smirnov and posted to the > IETF repository. >=20 > Name: draft-smirnov-ospf-xaf-te > Revision: 01 > Title: OSPF Routing with Cross-Address Family MPLS Traffic Engineering T= unnels > Document date: 2014-04-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-smirnov-ospf-xaf-te-01.txt > Status: https://datatracker.ietf.org/doc/draft-smirnov-ospf-xaf-t= e/ > Htmlized: http://tools.ietf.org/html/draft-smirnov-ospf-xaf-te-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-smirnov-ospf-xaf-te-01 >=20 > Abstract: > When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network > the Multiprotocol Label Switching (MPLS) TE Label Switched Paths > (LSP) infrastructure may be duplicated, even if the destination IPv4 > and IPv6 addresses belong to the same remote router. In order to > achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be > computed over MPLS TE tunnels created using information propagated in > another OSPF instance. This is solved by advertising cross-address > family (X-AF) OSPF TE information. >=20 > This document describes an update to RFC5786 that allows for the easy > identification of a router's local X-AF IP addresses. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Thu Apr 17 14:12:20 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39101A011C for ; Thu, 17 Apr 2014 14:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8S5vgNaCGpRC for ; Thu, 17 Apr 2014 14:12:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 51B121A0054 for ; Thu, 17 Apr 2014 14:12:14 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-13-534ff538003c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BF.CC.05011.835FF435; Thu, 17 Apr 2014 17:37:28 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 17:12:10 -0400 From: Acee Lindem To: OSPF List Thread-Topic: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt Thread-Index: AQHPWWKkr2iEvctPGUWHpQX02ko1EQ== Date: Thu, 17 Apr 2014 21:12:09 +0000 Message-ID: <01BA9225-3C0E-4830-BE03-FBEFE51CC2D1@ericsson.com> References: <534E61F0.4040105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_01BA92253C0E4830BE03FBEFE51CC2D1ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPoK7FV/9gg/a3qhYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/O708wFG/0rXm4/ydbAeNali5GTQ0LARGLZpTtMELaYxIV7 69m6GLk4hASOMkq8+dIM5SxnlOj+N4MdpIpNQEfi+aN/zCC2iICsxNIl+1lBbGGBEInOb/MY IeIhEi3Nz1kgbD2JA2uPgdWzCKhKbNqyBMzmFbCXePKiHWgBB9ACDYl9ezRAwoxAR3w/tQbs IGYBcYlbT+ZDHScgsWTPeWYIW1Ti5eN/rBC2ksSc19eYIeqTJea+XM4EMV5Q4uTMJywTGIVn IRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4DNVrLXHz8g0WZDULGDlWMXKUFqeW5aYb GWxiBEbKMQk23R2Me15aHmIU4GBU4uGdct03WIg1say4MvcQozQHi5I475e3zkFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGBeWcB27NWHNy5Usa8+liWszHN3c4xtz4lMq79c1B16c+zl5 xs27QgwRET8Cv3ys+78id+Vme5m98/4mfjF6Lfdy39Lc1O2lNsX39s/7uLdvgny5VIX7rbOP D4Y5BhizOWgzuH9YWSv2xrztslND9LKpc+02v05+Yb/XZpqVqGKt29Qn9gZN1UeUWIozEg21 mIuKEwHZaapAdQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/LYRF2hepmCe4RIx7hyG0HPMTTWE Subject: [OSPF] Fwd: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:12:18 -0000 --_000_01BA92253C0E4830BE03FBEFE51CC2D1ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The gist of the draft is to allow a single OSPF(v3) instance to signal LSP = endpoints for both IPv4 and IPv6 and, thus, consolidate the TE routing doma= in. Is there interest in considering this work? I would support it since it seems fairly straightforward (unless my reading= has missed something). Thanks, Acee Begin forwarded message: From: Anton Smirnov > Subject: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.t= xt Date: April 16, 2014 at 6:56:48 AM EDT To: OSPF List > Hello, authors of this draft would like to solicit feedback. This draft was pres= ented to WG in London and draft was updated couple of days ago to rectify n= otes received after the presentation. The draft proposes technique how IPv6 routes should be calculated over MP= LS TE signaled by OSPFv2. The draft discusses why simple solution to the problem not requiring stan= dardization works most of the time but if it fails it may fail with very bi= g impact to the network and thus unacceptable. But presentation delivered d= uring the meeting discussed this in pictures and in greater length, so if a= fter reading the draft you would still not be convinced simple solution is = not good enough I encourage you to review slide deck presented during the m= eeting. Anton Smirnov -------- Original Message -------- Subject: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt Date: Mon, 14 Apr 2014 13:48:01 -0700 From: > A new version of I-D, draft-smirnov-ospf-xaf-te-01.txt has been successfully submitted by Anton Smirnov and posted to the IETF repository. Name: draft-smirnov-ospf-xaf-te Revision: 01 Title: OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunn= els Document date: 2014-04-14 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-smirnov-ospf-xaf-te-01.txt Status: https://datatracker.ietf.org/doc/draft-smirnov-ospf-xaf-te/ Htmlized: http://tools.ietf.org/html/draft-smirnov-ospf-xaf-te-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-smirnov-ospf-xaf-te-01 Abstract: When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This is solved by advertising cross-address family (X-AF) OSPF TE information. This document describes an update to RFC5786 that allows for the easy identification of a router's local X-AF IP addresses. 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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_01BA92253C0E4830BE03FBEFE51CC2D1ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4672FA478283D940BE5ED19BD670B78C@ericsson.com> Content-Transfer-Encoding: quoted-printable All,

The gist of the draft is to allow a single OSPF(v3) instance to signal= LSP endpoints for both IPv4 and IPv6 and, thus, consolidate the TE routing= domain. Is there interest in considering this work? 

I would support it since it seems fairly straightforward (unless my re= ading has missed something). 

Thanks,
Acee

Begin forwarded message:

From:= Anton Smirnov <asmirnov@cisco.com>
Subje= ct: [OSPF] New Version Notif= ication for draft-smirnov-ospf-xaf-te-01.txt
Date:= April 16, 2014 at 6:56= :48 AM EDT
To: <= /b>OSPF List <ospf@ietf.org>

  Hello,
  authors of this draft would like to solicit feedback. This draf= t was presented to WG in London and draft was updated couple of days ago to= rectify notes received after the presentation.
  The draft proposes technique how IPv6 routes should be calculat= ed over MPLS TE signaled by OSPFv2.

  The draft discusses why simple solution to the problem not requ= iring standardization works most of the time but if it fails it may fail wi= th very big impact to the network and thus unacceptable. But presentation d= elivered during the meeting discussed this in pictures and in greater length, so if after reading the draft you would= still not be convinced simple solution is not good enough I encourage you = to review slide deck presented during the meeting.

Anton Smirnov



-------- Original Message --------
Subject: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
Date: Mon, 14 Apr 2014 13:48:01 -0700
From: <internet-drafts@ietf.= org>


A new version of I-D, draft-smirnov-ospf-xaf-te-01.txt
has been successfully submitted by Anton Smirnov and posted to the
IETF repository.

Name: draft-smirnov-os= pf-xaf-te
Revision: 0= 1
Title: OSPF Routing wi= th Cross-Address Family MPLS Traffic Engineering Tunnels
Document date: 2014-04-14
Group: Individual Subm= ission
Pages: 7
URL: http://www.ietf.org/internet-drafts/draft-smirnov-ospf-xaf-te-01.txt Status:         https://datatracker.ie= tf.org/doc/draft-smirnov-ospf-xaf-te/
Htmlized:       http://tools.ietf.org/html/draft-smi= rnov-ospf-xaf-te-01
Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-smirnov-ospf-xaf-te-01<= br>
Abstract:
  When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 n= etwork
  the Multiprotocol Label Switching (MPLS) TE Label Switched Path= s
  (LSP) infrastructure may be duplicated, even if the destination= IPv4
  and IPv6 addresses belong to the same remote router.  In o= rder to
  achieve an integrated MPLS TE LSP infrastructure, OSPF routes m= ust be
  computed over MPLS TE tunnels created using information propaga= ted in
  another OSPF instance.  This is solved by advertising cros= s-address
  family (X-AF) OSPF TE information.

  This document describes an update to RFC5786 that allows for th= e easy
  identification of a router's local X-AF IP addresses.




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



_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

--_000_01BA92253C0E4830BE03FBEFE51CC2D1ericssoncom_-- From nobody Fri Apr 18 02:05:43 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FB81A01FB for ; Fri, 18 Apr 2014 02:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 124fAbNQferW for ; Fri, 18 Apr 2014 02:05:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 41F481A0247 for ; Fri, 18 Apr 2014 02:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4388; q=dns/txt; s=iport; t=1397811935; x=1399021535; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3iVaIvWVRb4Da0eZHUK/RV1kkwRpjcpgOgI90btwSlM=; b=k0SsQHS55w0GkItiKMEtezOED2Mb8iDUte9AibwsxCB5PX9in34jGVGd yEWzhH1ej2z4gt2BpJuklF0k3Heb+lzh7OiqvnmGLbrbIwlznNW17Tc1O /ZdrxLHDVVzaH5rhmILHbZzHFrmujP/ZtJZ92IgWroYxai8KiHQ9sGBXm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFABPqUFOtJssW/2dsb2JhbABZg0FRvDqHOIE3dIIlAQEBAwEBAQEvAQU2CQEBDAQLEQMBAgEJFg8JAwIBAgEVKAgGDQEFAgEBBRKHWQgIBcwzF44OVAcGhDIBA5UAg26BN5EYgzM7 X-IronPort-AV: E=Sophos;i="4.97,883,1389744000"; d="scan'208";a="14881584" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Apr 2014 09:05:34 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3I95WvV023066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Apr 2014 09:05:34 GMT Message-ID: <5350EADB.3050003@cisco.com> Date: Fri, 18 Apr 2014 11:05:31 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Acee Lindem References: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> <534E61F0.4040105@cisco.com> <9DEEF3C3-BAAB-4019-82B9-82F5C392A691@ericsson.com> In-Reply-To: <9DEEF3C3-BAAB-4019-82B9-82F5C392A691@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2SfnLkKyPXS97CLjxV7ytoTpHA4 Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 09:05:41 -0000 Hi Acee, > Do you mean this to also apply > to multiple instances of the same AF? It would be a very ugly network > design where they are part of the same routing domain. This technique allows one protocol instance to use TEs signaled by another protocol instance. Choice of instances may indeed be quite bizarre - for example, the same technique may be used to signal TEs via ISIS/IPv4 AF and be used for routing by OSPFv3/IPv6 AF. Possibility of making such design does not mean that this design makes practical sense or that we should care about it. As authors see it, the main application now would be to signal TEs via OSPFv2/IPv4 AF and use them for routing in OSPFv3/IPv6 AF. And, in more distant future, vice verse - signal TEs via OSPFv3/IPv6 AF and use them for routing in OSPFv2/IPv4 AF. That may be needed when OSPFv2 is being phased out of the network - but of course we are very far from this point yet. While other combinations are theoretically possible we do not see practical value in them. Anton On 04/17/2014 11:08 PM, Acee Lindem wrote: > Hi Anton, > > I think I’m finally understanding the application of this draft. You > state that the OSPF and OSPFv3 domains need not coincide. That is > true but they must at least include the head-end of the LSPs for > which you want to compute LSP paths. Do you mean this to also apply > to multiple instances of the same AF? It would be a very ugly network > design where they are part of the same routing domain. > > Thanks, Acee > > On Apr 16, 2014, at 6:56 AM, Anton Smirnov > wrote: > >> Hello, authors of this draft would like to solicit feedback. This >> draft was presented to WG in London and draft was updated couple of >> days ago to rectify notes received after the presentation. The >> draft proposes technique how IPv6 routes should be calculated over >> MPLS TE signaled by OSPFv2. >> >> The draft discusses why simple solution to the problem not >> requiring standardization works most of the time but if it fails it >> may fail with very big impact to the network and thus unacceptable. >> But presentation delivered during the meeting discussed this in >> pictures and in greater length, so if after reading the draft you >> would still not be convinced simple solution is not good enough I >> encourage you to review slide deck presented during the meeting. >> >> Anton Smir -------- Original Message -------- Subject: New Version >> Notification for draft-smirnov-ospf-xaf-te-01.txt Date: Mon, 14 Apr >> 2014 13:48:01 -0700 From: >> >> >> A new version of I-D, draft-smirnov-ospf-xaf-te-01.txt has been >> successfully submitted by Anton Smirnov and posted to the IETF >> repository. >> >> Name: draft-smirnov-ospf-xaf-te Revision: 01 Title: OSPF Routing >> with Cross-Address Family MPLS Traffic Engineering Tunnels Document >> date: 2014-04-14 Group: Individual Submission Pages: 7 URL: >> http://www.ietf.org/internet-drafts/draft-smirnov-ospf-xaf-te-01.txt >> >> Status: https://datatracker.ietf.org/doc/draft-smirnov-ospf-xaf-te/ >> Htmlized: >> http://tools.ietf.org/html/draft-smirnov-ospf-xaf-te-01 Diff: >> http://www.ietf.org/rfcdiff?url2=draft-smirnov-ospf-xaf-te-01 >> >> Abstract: When using Traffic Engineering (TE) in a dual-stack >> IPv4/IPv6 network the Multiprotocol Label Switching (MPLS) TE Label >> Switched Paths (LSP) infrastructure may be duplicated, even if the >> destination IPv4 and IPv6 addresses belong to the same remote >> router. In order to achieve an integrated MPLS TE LSP >> infrastructure, OSPF routes must be computed over MPLS TE tunnels >> created using information propagated in another OSPF instance. >> This is solved by advertising cross-address family (X-AF) OSPF TE >> information. >> >> This document describes an update to RFC5786 that allows for the >> easy identification of a router's local X-AF IP addresses. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ OSPF mailing list >> OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf > From nobody Fri Apr 18 08:44:30 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C71A0425 for ; Fri, 18 Apr 2014 08:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YoIonrwYHO0l for ; Fri, 18 Apr 2014 08:44:21 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC91A0422 for ; Fri, 18 Apr 2014 08:44:20 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-a7-5350f9ddd1c5 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 92.AD.05011.DD9F0535; Fri, 18 Apr 2014 12:09:34 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 11:44:15 -0400 From: Acee Lindem To: Alan Davey , "ospf@ietf.org" , "draft-ietf-ospf-ospfv3-lsa-extend@tools.ietf.org" Thread-Topic: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01 Thread-Index: Ac9FAnKI5crrObGLRia8H4bMjVlUZAWAXXsA Date: Fri, 18 Apr 2014 15:44:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_CF7695B22C95Daceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXSPn+69nwHBBuufslk8mTaLzeLW2Ums Fi337rE7MHssWfKTyePozbnMHl8uf2YLYI7isklJzcksSy3St0vgyrjSe4et4HsDY8X1w48Y GxhPF3QxcnJICJhINN2dywphi0lcuLeerYuRi0NI4CijxM22FihnOaPE4lkPmUCq2AR0JJ4/ +scMkhAR2MYosXzWShaQhLCApcTt5rtgo0QErCRe3DjMDGEbSTQ3/gKLswioSkz5c50NxOYV MJWY8/EcWK+QgJ/Ez46DYPWcAv4SJzqWg9mMQCd9P7UGbDGzgLjErSfzmSBOFZBYsuc8M4Qt KvHy8T+w+aICehLvjsPUKEnMeX2NGaI3SqLjaRczxF5BiZMzn7BMYBSdhWTsLCRls5CUQcQN JN6fm88MYWtLLFv4GsrWl9j45SzjLEYOINta4t07HWQlCxg5VjFylBanluWmGxlsYgRG4TEJ Nt0djHteWh5iFOBgVOLhnXLdN1iINbGsuDL3EKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWl OanFhxiZODilGhiN/a2zD3xSN7I8ER+vqu8bd4s3aAofi5Zh2CfXrmkp8kse1hXLRTLc13WX DN1+na/xraZ7xjMp1thXtjHGc3nVIgMCKlwf+/pezN/8eRbblCWnYrslu1XtLk1ZXzFhifek JKtgf4MnoQlvkxnzbixg7DudxaDQ35OwU/BMIO91VpN5wXHLlViKMxINtZiLihMBKTqQB6MC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/APVLgsGtn4RwyUIK5Q5Wf11a8iI Subject: Re: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:44:27 -0000 --_000_CF7695B22C95Daceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks much for the thorough review! I'm generally not a top-poster but in= this case I've incorporated all your comments including reorganizing the d= raft to separate the TLV specifications from the Extended LSA specification= s. Thanks, Acee From: Alan Davey > Date: Monday, April 7, 2014 2:57 AM To: OSPF - OSPF WG List >, "draft-ietf-= ospf-ospfv3-lsa-extend@tools.ietf.org" > Subject: [OSPF] draft-ietf-ospf-ospfv3-lsa-extend-01 Folks I have read draft-ietf-ospf-ospfv3-lsa-extend-01 and I think that it looks = good. I have a few comments, mostly minor. Please let me know if you have= any questions on the following. _General Points_ The TLV types are defined with global scope. Therefore, I think it is clea= rer to separate the TLV definitions from the LSA definitions. It may be be= tter to avoid defining limits on the TLV usage in sections defining the LSA= s. For an example of where it would be better to separate the TLV definitions,= in section 11, OSPFv3 E-Intra-Area-Prefix-LSA, there is a reference to TLV= type 6, which is defined in section 10, OSPFv3 E-Link-LSA. For an example of defining limits in the TLV usage in LSA definitions, in s= ection 4: - =930 =96 Reserved=94. As the Type values are OSPFv3-global in s= cope, should the reserved value be defined in an overall section and not in= the section defining the E-Router-LSA? - =93The Router-Link TLV is only applicable to the E-Router-LSA. = Inclusion in other Extended LSAs MUST be ignored.=94 This is probably true= , but seems too limiting. Should the sections defining the LSAs state whic= h TLVs are applicable to that LSA, only, and have a default statement that = other TLV (and sub-TLV) types SHOULD be ignored? Where multiple sub-TLVs are defined, for example, in section 8, OSPFv3 E-AS= -External-LSA, there should be a statement that the sub-TLVs may be in any = order. _Minor Points, Typos, etc._ Section 1, para 2: s/OSPFv3 LSA/OSPFv3 LSAs/ Section 3, last sentence: =93Unrecognized types are ignored.=94 Is there a= better section to put this statement? Section 3 is defining the TLV forma= t and not any actions on processing them. Section 4: Should there be a statement that the E-Router-LSA can contain multiple Rout= er-Link TLVs? This is different to RFC 3630, where an LSA can only contain= one top-level TLV and this should be made explicit. Section 5, paragraph 3: s/her/the/? Section 6, paragraph 2: s/Network-LSA/Inter-Area-Prefix-LSA/. Section 8; I suggest NOT specifying the TLV lengths in the format diagrams;= this seems too restrictive. Section 12; paragraph 2, =93will contain an additional options bits=94, s/b= its/bit/? Section 12.1, paragraph 1: s/ exteneded/extended/ and s/ MixedModeOrignateO= nly/ MixedModeOriginateOnly/ Section 12.1, 1.; s/orginate/originate/. Section 12.1.1, paragraph 1; s/In these are/In these areas/. Appendix A, ExtendedLSASupport; s/The valid value/The valid values/ Regards Alan Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_CF7695B22C95Daceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9ECD83F36F42DE449ABFC546F66A9900@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Alan, 
Thanks much for the thorough review!  I'm generally not a top-pos= ter but in this case I've incorporated all your comments including reorgani= zing the draft to separate the TLV specifications from the Extended LSA spe= cifications. 
Thanks,
Acee

From: Alan Davey <Alan.Davey@metaswitch.com>
Date: Monday, April 7, 2014 2:57 AM=
To: OSPF - OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-ospfv3-lsa-= extend@tools.ietf.org" <draft-ietf-ospf-ospfv3-lsa-extend@tools.ietf.o= rg>
Subject: [OSPF] draft-ietf-ospf-osp= fv3-lsa-extend-01

Folks

 

I have read draft-ietf-ospf-ospfv3-lsa-extend-01 and= I think that it looks good.  I have a few comments, mostly minor.&nbs= p; Please let me know if you have any questions on the following.

 

_General Points_

 

The TLV types are defined with global scope.  T= herefore, I think it is clearer to separate the TLV definitions from the LS= A definitions.  It may be better to avoid defining limits on the TLV u= sage in sections defining the LSAs. 

 

For an example of where it would be better to separa= te the TLV definitions, in section 11, OSPFv3 E-Intra-Area-Prefix-LSA, ther= e is a reference to TLV type 6, which is defined in section 10, OSPFv3 E-Li= nk-LSA.

 

For an example of defining limits in the TLV usage i= n LSA definitions, in section 4:

 

- &nb= sp;        =930 =96 Reserved=94.  As the Type values = are OSPFv3-global in scope, should the reserved value be defined in an over= all section and not in the section defining the E-Router-LSA?

 

- &nb= sp;        =93The Router-Link TLV is only applicable to th= e E-Router-LSA.  Inclusion in other Extended LSAs MUST be ignored.=94&= nbsp; This is probably true, but seems too limiting.  Should the secti= ons defining the LSAs state which TLVs are applicable to that LSA, only, and have a default statement that other TLV (and sub-TL= V) types SHOULD be ignored?

 

Where multiple sub-TLVs are defined, for example, in= section 8, OSPFv3 E-AS-External-LSA, there should be a statement that the = sub-TLVs may be in any order.

 

_Minor Points, Typos, etc._

 

Section 1, para 2: s/OSPFv3 LSA/OSPFv3 LSAs/

 

Section 3, last sentence: =93Unrecognized types are = ignored.=94  Is there a better section to put this statement?  Se= ction 3 is defining the TLV format and not any actions on processing them.<= o:p>

 

Section 4:

 

Should there be a statement that the E-Router-LSA ca= n contain multiple Router-Link TLVs?  This is different to RFC 3630, w= here an LSA can only contain one top-level TLV and this should be made expl= icit.

 

Section 5, paragraph 3: s/her/the/?

 

Section 6, paragraph 2: s/Network-LSA/Inter-Area-Pre= fix-LSA/.

 

Section 8; I suggest NOT specifying the TLV lengths = in the format diagrams; this seems too restrictive.

 

Section 12; paragraph 2, =93will contain an addition= al options bits=94, s/bits/bit/?

 

Section 12.1, paragraph 1: s/ exteneded/extended/ an= d s/ MixedModeOrignateOnly/ MixedModeOriginateOnly/

 

Section 12.1, 1.; s/orginate/originate/.<= /p>

 

Section 12.1.1, paragraph 1; s/In these are/In these= areas/.

 

Appendix A, ExtendedLSASupport; s/The valid value/Th= e valid values/

 

Regards

Alan

 

Network Technologies<= /i>
Metaswitch Networks

 

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

 --_000_CF7695B22C95Daceelindemericssoncom_-- From nobody Fri Apr 18 08:59:04 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18AC1A03DB for ; Fri, 18 Apr 2014 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuUmkLr7csTj for ; Fri, 18 Apr 2014 08:58:58 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 313261A03D4 for ; Fri, 18 Apr 2014 08:58:58 -0700 (PDT) X-AuditID: c6180641-f79a26d000001830-e1-5350fae2d9fe Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7B.A8.06192.2EAF0535; Fri, 18 Apr 2014 12:13:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 11:58:53 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt Thread-Index: AQHPWxvzDq21FEGbJU2CC2V6eH593ZsXVa8A Date: Fri, 18 Apr 2014 15:58:53 +0000 Message-ID: References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> In-Reply-To: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <7F4BBF4482BF70439C66F210081C1500@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPiO6jXwHBBqt/ylq03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKmv3jMVNPFXTJ80kbGBcSZPFyMnh4SAicTMnT9ZIWwxiQv3 1rN1MXJxCAkcZZToPPeFGcJZziixd9seFpAqNgEdieeP/jGD2CIC6hKrJ+8G6xYWCJG49Hce K0Q8VGLupmNQNUYSjfOXgPWyCKhKvP10CszmFTCVeHBiAdA2DqAFDhJ/FnCAhDkFHCVubN/J BGIzAh30/dQaMJtZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B/YWlEBPYl3x2FqlCQ+/p7PDtGr I7Fg9yc2CNtaYt2Zw1BxbYllC18zQ5wjKHFy5hOWCYzis5Csm4WkfRaS9llI2mchaV/AyLqK kaO0OLUsN93IcBMjMIKOSbA57mBc8MnyEKMAB6MSD6/WVd9gIdbEsuLK3EOM0hwsSuK8X946 BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgXHV75jXv05/6Lk5l7GprrTvNUfpjnoaZ28d/ VbcDDkQHv5CrFKwNe39zqtW/6lIPtlhOXvvLq/uN9micVbFXaMkJU1PaUVQxW2paethP06Jp qZ/58pqkbrceSNFR6RR9dNIjtGq7uXNeb/DhC6/07Hz6t/x9lbjzzj9jLy6bwBkMxYc9V/Ur sRRnJBpqMRcVJwIA4e6+pIECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/FWOZcExSHNhVm2GJvgiONgNXdPQ Subject: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:59:00 -0000 All, This version has been reorganized to separate the definitions of the TLVs and sub-TLVs from the Extended LSAs (Alan Davey's suggestion). It also includes the changes to the compatibility section discussed during the OSPF WG meeting in London (David Lamparter's input). Thanks, Acee=20 On 4/18/14 8:36 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt >has been successfully submitted by Acee Lindem and posted to the >IETF repository. > >Name: draft-ietf-ospf-ospfv3-lsa-extend >Revision: 02 >Title: OSPFv3 LSA Extendibility >Document date: 2014-04-18 >Group: ospf >Pages: 35 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend-02.t >xt >Status: =20 >https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-lsa-extend-02 > >Abstract: > OSPFv3 requires functional extension beyond what can readily be done > with the fixed-format Link State Advertisement (LSA) as described in > RFC 5340. Without LSA extension, attributes associated with OSPFv3 > links and advertised IPv6 prefixes must be advertised in separate > LSAs and correlated to the fixed-format LSAs. This document extends > the LSA format by encoding the existing OSPFv3 LSA information in > Type-Length-Value (TLV) tuples and allowing advertisement of > additional information with additional TLVs. Backward compatibility > mechanisms are also described. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Fri Apr 18 09:18:16 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40531A015D for ; Fri, 18 Apr 2014 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 a2UGjkJvKfq1 for ; Fri, 18 Apr 2014 09:18:06 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4D41A013F for ; Fri, 18 Apr 2014 09:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2750; q=dns/txt; s=iport; t=1397837882; x=1399047482; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IG946EG41Otsu8dguniHYIJWA9fj9ZB7TKK0VKIyjEg=; b=HJq6ZreqWarL6wtClmVdwfj8jhmy8DNwrUQBMmxakmOyui08C72Ztz8I IUZ14nOwHnVk+N+vGgMoWnncrllDFZoTJQFc7/XHOtlFQCWUgQUFNEDIv IwuSlBt3H3cTxBWST99EdYCTnugQy26RqXnacro7e4Wo0nGjUN9yAQfbu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFANJOUVOtJssW/2dsb2JhbABag1VRvD6HPIEzdIIlAQEBBAEBATU2CQERCxgJFg8JAwIBAgEVJwkGAQwGAgEBBYg4CAXNExeODluEOAEDmG6BN4Uhi3eBcoFBOw X-IronPort-AV: E=Sophos;i="4.97,885,1389744000"; d="scan'208";a="19800551" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 18 Apr 2014 16:18:01 +0000 Received: from [10.55.51.198] (ams-ppsenak-8715.cisco.com [10.55.51.198]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IGI0nA028949; Fri, 18 Apr 2014 16:18:01 GMT Message-ID: <53515038.9070407@cisco.com> Date: Fri, 18 Apr 2014 18:18:00 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem , OSPF - OSPF WG List References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2BgIVujNgnyWnqjYmW2MC-9vBvs Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:18:10 -0000 Hi Acee, quote From section (5): "In this manner, OSPFv3 routers using new encodings can be completely isolated from those OSPFv3 routers depending on the RFC 5340 encoding and not setting their options field EL-bits since the default setting indicates no support for extended LSAs." Even though you prevent adjacency to be formed between routers with certain compatibility modes, it still does not prevent all modes to coexist in the area/network. Let's imagine you have a chain of routers with following modes: Full---MixedModeOriginateSPF----MixedModeOriginateOnly-----None thanks, Peter On 4/18/14 17:58 , Acee Lindem wrote: > All, > This version has been reorganized to separate the definitions of the TLVs > and sub-TLVs from the Extended LSAs (Alan Davey's suggestion). > It also includes the changes to the compatibility section discussed during > the OSPF WG meeting in London (David Lamparter's input). > Thanks, > Acee > > On 4/18/14 8:36 AM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt >> has been successfully submitted by Acee Lindem and posted to the >> IETF repository. >> >> Name: draft-ietf-ospf-ospfv3-lsa-extend >> Revision: 02 >> Title: OSPFv3 LSA Extendibility >> Document date: 2014-04-18 >> Group: ospf >> Pages: 35 >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend-02.t >> xt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ >> Htmlized: >> http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-02 >> >> Abstract: >> OSPFv3 requires functional extension beyond what can readily be done >> with the fixed-format Link State Advertisement (LSA) as described in >> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >> links and advertised IPv6 prefixes must be advertised in separate >> LSAs and correlated to the fixed-format LSAs. This document extends >> the LSA format by encoding the existing OSPFv3 LSA information in >> Type-Length-Value (TLV) tuples and allowing advertisement of >> additional information with additional TLVs. Backward compatibility >> mechanisms are also described. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Fri Apr 18 09:23:04 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA981A0279 for ; Fri, 18 Apr 2014 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRP2C71S6BWZ for ; Fri, 18 Apr 2014 09:22:41 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8A71A013F for ; Fri, 18 Apr 2014 09:22:41 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-bb-535102dac389 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 22.FE.05011.AD201535; Fri, 18 Apr 2014 12:47:55 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 12:22:36 -0400 From: Acee Lindem To: Peter Psenak Thread-Topic: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt Thread-Index: AQHPWxvzDq21FEGbJU2CC2V6eH593ZsXVa8AgAB6rwCAAAFJAA== Date: Fri, 18 Apr 2014 16:22:36 +0000 Message-ID: <54238B77-60C7-4392-B396-A5B6B43B31BC@ericsson.com> References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> <53515038.9070407@cisco.com> In-Reply-To: <53515038.9070407@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2D9164AFB4969143AF0105DD52EEFC95@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPgu5tpsBgg4/bGC1a7t1jt9ixu53N gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY3LWFtWCWZEXf/EdsDYzPRLoYOTkkBEwk zs1bzQhhi0lcuLeerYuRi0NI4CijxN/j11ghnOWMEieWrGAFqWIT0JF4/ugfM4gtIqAiMe96 DwuIzSwgK/FsWxNYXFggXuJI+wd2iJoEiR17frJC2E4S05vngNWwCKhKnLmzgg3E5hWwl5h6 9B4TxLJORombrS/BGjgFNCWW/54LZjMCnff91BomiGXiEreezGeCOFtAYsme88wQtqjEy8f/ WCFsJYmPv+ezQ9QbSLw/Nx+ohgPItpa4+tcJIqwtsWzha2aIGwQlTs58wjKBUXwWkg2zkHTP QuiehaR7FpLuBYysqxg5SotTy3LTjQw2MQKj6pgEm+4Oxj0vLQ8xCnAwKvHwTrnuGyzEmlhW XJl7iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxlYs/+PjsazXvzvaxT jfyZzjtSdjIy5UdyDjv6zZzAdGTm9+wHv/6XhuTufPVo2cK6BQ2mOzIXTOy77XKj8NUbJ0al B0EqS9+GzFvTXOD186xP1fy0HY3Tp7yYwD53I//nq3l5/15kXMw/ejckZS/PrGIfy1OSu5/v Mry34MvlC+8idkinnUu8qsRSnJFoqMVcVJwIACkoIMuLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/GroBt5RAALsBl5L_WAJpGelXtog Cc: OSPF List Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:22:51 -0000 Hi Peter,=20 You are correct - I=92d thought about these situations myself but didn=92t = strike this statement. I=92m thinking I will remove this and discuss the op= tions of separate routing domains in more detail.=20 Thanks, Acee On Apr 18, 2014, at 12:18 PM, Peter Psenak wrote: > Hi Acee, >=20 > quote From section (5): >=20 > "In this manner, OSPFv3 routers using new encodings can be > completely isolated from those OSPFv3 routers depending on the RFC > 5340 encoding and not setting their options field EL-bits since the > default setting indicates no support for extended LSAs." >=20 > Even though you prevent adjacency to be formed between routers with certa= in compatibility modes, it still does not prevent all modes to coexist in t= he area/network. >=20 > Let's imagine you have a chain of routers with following modes: >=20 > Full---MixedModeOriginateSPF----MixedModeOriginateOnly-----None >=20 >=20 > thanks, > Peter >=20 > On 4/18/14 17:58 , Acee Lindem wrote: >> All, >> This version has been reorganized to separate the definitions of the TLV= s >> and sub-TLVs from the Extended LSAs (Alan Davey's suggestion). >> It also includes the changes to the compatibility section discussed duri= ng >> the OSPF WG meeting in London (David Lamparter's input). >> Thanks, >> Acee >>=20 >> On 4/18/14 8:36 AM, "internet-drafts@ietf.org" >> wrote: >>=20 >>>=20 >>> A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt >>> has been successfully submitted by Acee Lindem and posted to the >>> IETF repository. >>>=20 >>> Name: draft-ietf-ospf-ospfv3-lsa-extend >>> Revision: 02 >>> Title: OSPFv3 LSA Extendibility >>> Document date: 2014-04-18 >>> Group: ospf >>> Pages: 35 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend-0= 2.t >>> xt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-lsa-extend-02 >>>=20 >>> Abstract: >>> OSPFv3 requires functional extension beyond what can readily be done >>> with the fixed-format Link State Advertisement (LSA) as described in >>> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >>> links and advertised IPv6 prefixes must be advertised in separate >>> LSAs and correlated to the fixed-format LSAs. This document extends >>> the LSA format by encoding the existing OSPFv3 LSA information in >>> Type-Length-Value (TLV) tuples and allowing advertisement of >>> additional information with additional TLVs. Backward compatibility >>> mechanisms are also described. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >=20 From nobody Fri Apr 18 09:57:46 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF061A0461 for ; Fri, 18 Apr 2014 09:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 ZpBBQMOvyRrf for ; Fri, 18 Apr 2014 09:57:40 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF361A044A for ; Fri, 18 Apr 2014 09:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3853; q=dns/txt; s=iport; t=1397840251; x=1399049851; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3ZpWAhGsNb6u4YXMVPbGdHwQp0oQhSQ/yb2/IGv7II0=; b=HlQtmffh6ZN2PNmYVktfH91N9CqxsyPAJCv7dLXqKfDvzq6f5PzgppNH m7LRGquLHZQWO0gU833g0F2EmLA41zoZeDGtgHRJfT6drRi7dNYAAYHiK Bmpzc2SMkxOXJiZOkX/66I0yX17YnU5jdLz5FkeUDOI5sIinTtGgCh8gh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAAVYUVOtJssW/2dsb2JhbABag1VRvD6HPIEzdIIlAQEBBAEBAS8BBTYJAQEQCxgJFg8JAwIBAgEVJwkGDQEFAgEBBYg4CAXNCReODlQHhDgBA5hugTeFIYt3gXKBQTs X-IronPort-AV: E=Sophos;i="4.97,885,1389744000"; d="scan'208";a="15067474" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 18 Apr 2014 16:57:30 +0000 Received: from [10.55.51.198] (ams-ppsenak-8715.cisco.com [10.55.51.198]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IGvSag028582; Fri, 18 Apr 2014 16:57:28 GMT Message-ID: <53515978.5070700@cisco.com> Date: Fri, 18 Apr 2014 18:57:28 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> <53515038.9070407@cisco.com> <54238B77-60C7-4392-B396-A5B6B43B31BC@ericsson.com> In-Reply-To: <54238B77-60C7-4392-B396-A5B6B43B31BC@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/I8qLMbOWcFPzp-sCnPGPFElTopM Cc: OSPF List Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:57:44 -0000 Hi Acee, I do not see any problem with routers with various compatibility modes living in area/network together. With all the modes we have, we provide the possibility of graceful migration from old to new LSA types. I don't think we need to restrict any combination. Sure, if someone mix "full" and "none", then it can not expect the full reachability between them, but that does not mean we have to prohibit it. Separate routing is the possibility, but probably not the easiest one. I would certainly not enforce it as the only possibility. thanks, Peter On 4/18/14 18:22 , Acee Lindem wrote: > Hi Peter, > You are correct - I’d thought about these situations myself but didn’t strike this statement. I’m thinking I will remove this and discuss the options of separate routing domains in more detail. > Thanks, > Acee > On Apr 18, 2014, at 12:18 PM, Peter Psenak wrote: > >> Hi Acee, >> >> quote From section (5): >> >> "In this manner, OSPFv3 routers using new encodings can be >> completely isolated from those OSPFv3 routers depending on the RFC >> 5340 encoding and not setting their options field EL-bits since the >> default setting indicates no support for extended LSAs." >> >> Even though you prevent adjacency to be formed between routers with certain compatibility modes, it still does not prevent all modes to coexist in the area/network. >> >> Let's imagine you have a chain of routers with following modes: >> >> Full---MixedModeOriginateSPF----MixedModeOriginateOnly-----None >> >> >> thanks, >> Peter >> >> On 4/18/14 17:58 , Acee Lindem wrote: >>> All, >>> This version has been reorganized to separate the definitions of the TLVs >>> and sub-TLVs from the Extended LSAs (Alan Davey's suggestion). >>> It also includes the changes to the compatibility section discussed during >>> the OSPF WG meeting in London (David Lamparter's input). >>> Thanks, >>> Acee >>> >>> On 4/18/14 8:36 AM, "internet-drafts@ietf.org" >>> wrote: >>> >>>> >>>> A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt >>>> has been successfully submitted by Acee Lindem and posted to the >>>> IETF repository. >>>> >>>> Name: draft-ietf-ospf-ospfv3-lsa-extend >>>> Revision: 02 >>>> Title: OSPFv3 LSA Extendibility >>>> Document date: 2014-04-18 >>>> Group: ospf >>>> Pages: 35 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend-02.t >>>> xt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-02 >>>> >>>> Abstract: >>>> OSPFv3 requires functional extension beyond what can readily be done >>>> with the fixed-format Link State Advertisement (LSA) as described in >>>> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >>>> links and advertised IPv6 prefixes must be advertised in separate >>>> LSAs and correlated to the fixed-format LSAs. This document extends >>>> the LSA format by encoding the existing OSPFv3 LSA information in >>>> Type-Length-Value (TLV) tuples and allowing advertisement of >>>> additional information with additional TLVs. Backward compatibility >>>> mechanisms are also described. >>>> >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> > > . > From nobody Fri Apr 18 13:41:29 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF2E1A03BE for ; Fri, 18 Apr 2014 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhBWUA25jN1H for ; Fri, 18 Apr 2014 13:41:19 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1B1A0208 for ; Fri, 18 Apr 2014 13:41:19 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-47-53513f789e48 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A9.27.05011.87F31535; Fri, 18 Apr 2014 17:06:32 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 16:41:14 -0400 From: Acee Lindem To: Peter Psenak Thread-Topic: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt Thread-Index: AQHPW0aJPmTagfMT+kORJpirhr5Wfg== Date: Fri, 18 Apr 2014 20:41:13 +0000 Message-ID: <357C7548-A5EE-4849-B72F-4FD1D386BB8D@ericsson.com> References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> <53515038.9070407@cisco.com> <54238B77-60C7-4392-B396-A5B6B43B31BC@ericsson.com> <53515978.5070700@cisco.com> In-Reply-To: <53515978.5070700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2C7E04220F23D04DBD049CB50E67AB24@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPt26FfWCwQVufnEXLvXvsFjt2t7M5 MHlM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBntl98zFkxVqrh/dRFLA2ODTBcjJ4eEgInE p3c7GSFsMYkL99azdTFycQgJHGWU+LZ+MZSznFGid84UVpAqNgEdieeP/jGD2CICKhLzrvew gNjMArISz7Y1gcWFBaIlOjf8Y4SoiZHY3vCVCcLWk/i/aQlYnEVAVWLVt26wel4Be4mOKStZ IJbdY5RoaXkLtoxTQFPi1/t3YEWMQOd9P7WGCWKZuMStJ/OZIM4WkFiy5zwzhC0q8fLxP1YI W0lizutrzBD1BhLvz82Hsq0lFl47AWVrSyxb+BrqCEGJkzOfsExgFJ+FZMUsJO2zkLTPQtI+ C0n7AkbWVYwcpcWpZbnpRgabGIGRdUyCTXcH456XlocYBTgYlXh4p1z3DRZiTSwrrsw9xCjN waIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbGSyq2QkUqOZz/g9fY/A2WOOyx l+fWB91Jh9YrHU9lKFuxWN09O1fNYlNVwS9WASHNjRPZ7nzwEM+SPC3pUzZDdadVFfvj6FD/ fReFHYOv3z0ddOI+/4lItp0vf9T9vjX/TlBs95ysl4fszk7Q/r5C+ZDDmy0Nr5hSD7jNCjLl dPM5yPB0/QclluKMREMt5qLiRAAEHCJGjQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/jEQ_io-97Nv5Sdh_-Z1pA-a3IoI Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 20:41:26 -0000 Hi Peter,=20 On Apr 18, 2014, at 12:57 PM, Peter Psenak wrote: > Hi Acee, >=20 > I do not see any problem with routers with various compatibility modes li= ving in area/network together. With all the modes we have, we provide the p= ossibility of graceful migration from old to new LSA types. I don't think w= e need to restrict any combination. Sure, if someone mix "full" and "none",= then it can not expect the full reachability between them, but that does n= ot mean we have to prohibit it. I agree.=20 >=20 > Separate routing is the possibility, but probably not the easiest one. I = would certainly not enforce it as the only possibility. We started with this as the only migration mechanism. It is still one optio= n and I will attempt to assure both migration paths are clear.=20 Thanks, Acee=20 >=20 > thanks, > Peter >=20 > On 4/18/14 18:22 , Acee Lindem wrote: >> Hi Peter, >> You are correct - I=92d thought about these situations myself but didn= =92t strike this statement. I=92m thinking I will remove this and discuss t= he options of separate routing domains in more detail. >> Thanks, >> Acee >> On Apr 18, 2014, at 12:18 PM, Peter Psenak wrote: >>=20 >>> Hi Acee, >>>=20 >>> quote From section (5): >>>=20 >>> "In this manner, OSPFv3 routers using new encodings can be >>> completely isolated from those OSPFv3 routers depending on the RFC >>> 5340 encoding and not setting their options field EL-bits since the >>> default setting indicates no support for extended LSAs." >>>=20 >>> Even though you prevent adjacency to be formed between routers with cer= tain compatibility modes, it still does not prevent all modes to coexist in= the area/network. >>>=20 >>> Let's imagine you have a chain of routers with following modes: >>>=20 >>> Full---MixedModeOriginateSPF----MixedModeOriginateOnly-----None >>>=20 >>>=20 >>> thanks, >>> Peter >>>=20 >>> On 4/18/14 17:58 , Acee Lindem wrote: >>>> All, >>>> This version has been reorganized to separate the definitions of the T= LVs >>>> and sub-TLVs from the Extended LSAs (Alan Davey's suggestion). >>>> It also includes the changes to the compatibility section discussed du= ring >>>> the OSPF WG meeting in London (David Lamparter's input). >>>> Thanks, >>>> Acee >>>>=20 >>>> On 4/18/14 8:36 AM, "internet-drafts@ietf.org" >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-02.txt >>>>> has been successfully submitted by Acee Lindem and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-ietf-ospf-ospfv3-lsa-extend >>>>> Revision: 02 >>>>> Title: OSPFv3 LSA Extendibility >>>>> Document date: 2014-04-18 >>>>> Group: ospf >>>>> Pages: 35 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-extend= -02.t >>>>> xt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-02 >>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-lsa-extend-= 02 >>>>>=20 >>>>> Abstract: >>>>> OSPFv3 requires functional extension beyond what can readily be don= e >>>>> with the fixed-format Link State Advertisement (LSA) as described i= n >>>>> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >>>>> links and advertised IPv6 prefixes must be advertised in separate >>>>> LSAs and correlated to the fixed-format LSAs. This document extend= s >>>>> the LSA format by encoding the existing OSPFv3 LSA information in >>>>> Type-Length-Value (TLV) tuples and allowing advertisement of >>>>> additional information with additional TLVs. Backward compatibilit= y >>>>> mechanisms are also described. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>>=20 >>>=20 >>=20 >> . >>=20 >=20 From nobody Fri Apr 18 15:39:16 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28411A02F2 for ; Fri, 18 Apr 2014 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmfMGbhWzWRF for ; Fri, 18 Apr 2014 15:39:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71A5F1A02D8 for ; Fri, 18 Apr 2014 15:39:10 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-85-53515b17ecd7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 28.A9.05011.71B51535; Fri, 18 Apr 2014 19:04:24 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 18:39:05 -0400 From: Acee Lindem To: prz Thread-Topic: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt Thread-Index: AQHPW0aJPmTagfMT+kORJpirhr5WfpsYN6cAgAAC2gA= Date: Fri, 18 Apr 2014 22:39:04 +0000 Message-ID: <574D52F9-8870-4035-85D6-FB40E37AA91A@ericsson.com> References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> <53515038.9070407@cisco.com> <54238B77-60C7-4392-B396-A5B6B43B31BC@ericsson.com> <53515978.5070700@cisco.com> <357C7548-A5EE-4849-B72F-4FD1D386BB8D@ericsson.com> <001e83b64d76b7eadea70a1854378b2d@zeta2.ch> In-Reply-To: <001e83b64d76b7eadea70a1854378b2d@zeta2.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-ID: <868EA0EC7CB4214095448830D259FD8E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonVlciOjDYYEm7gEXLvXvsFjt2t7NZ 3Ot6zOrA7DHl90ZWjyVLfjJ5/Fj2hzmAOYrLJiU1J7MstUjfLoErY+fcPpaCp9wVX6a1sDUw zufsYuTgkBAwkWiaENLFyAlkiklcuLeerYuRi0NI4CijxMx/21khnOWMEgsvdDGDVLEJ6Eg8 f/SPGaRZBKij+WESSJhZwF5ie38/E4gtLBAt0bnhHyOILSIQI7G94SsThG0lcWXrCrAxLAKq Eu0rp7GBjOEF6j3yrgpi1SEmiZ0TX7CA1HAKWEisWfcErJ4RaNX3U2uYIHaJS9x6Mp8J4mgB iSV7zjND2KISLx//Y4WwlSQ+/p7PDlFvIPH+3HxmCNta4tTkNSwQtrbEsoWvweK8AoISJ2c+ YZnAKD4LyYpZSNpnIWmfhaR9FpL2BYysqxg5SotTy3LTjQw2MQLj7JgEm+4Oxj0vLQ8xCnAw KvHwTrnuGyzEmlhWXJl7iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyN YSU6yk+LX7P6LdO8Pv2a/3StBWs+5zzO/a0V/l1mjc5xVeaXK91C7FI3m/b/mCizrVIkj+2s 7z4ty/oMXnHeu63uPNzrruTetzqbd+qejEBevIjD9F3Je37u3Hej1lJ5Wmzx6ZdHU1et/XDo gkyJbvemHTePLIgM4zz1hJ2r9YPfm6It6yYosRRnJBpqMRcVJwIAIb0bppQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/gRcrlpip3NM01bYvtKOYV_5_f8w Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 22:39:14 -0000 Hi Tony, On Apr 18, 2014, at 6:28 PM, prz wrote: > On Fri, 18 Apr 2014 20:41:13 +0000, Acee Lindem wrote: >> Hi Peter, >>=20 >> On Apr 18, 2014, at 12:57 PM, Peter Psenak wrote: >>=20 >>> Hi Acee, >>>=20 >>> I do not see any problem with routers with various compatibility modes = living in area/network together. With all the modes we have, we provide the= possibility of graceful migration from old to new LSA types. I don't think= we need to restrict any combination. Sure, if someone mix "full" and "none= ", then it can not expect the full reachability between them, but that does= not mean we have to prohibit it. >>=20 >=20 > Zipped through the diffs on the new one. See most work went into migratio= n. Two observations: >=20 > . nitpick: WILL is _not_ any kind of normative language. Use MUST Ok - I=92ll search these out.=20 > . the only reason the migration holds together without stable loops is th= at there is an implicit assumption in the draft (I didn't see it spelled ou= t but then again I skimmed over it only) that the metric advertised in TLVs= and old style is always absolutely the same. I suggest to spell that out s= trongly. It is implicit but it seems rather obvious that if one originates the non-e= xtended and extended versions of the same LSA, the content MUST be the same= . However, I can state this explicitly.=20 Thanks, Acee=20 >=20 > --- tony From nobody Fri Apr 18 19:08:45 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA111A00FC for ; Fri, 18 Apr 2014 19:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75l_E0smBBVD for ; Fri, 18 Apr 2014 19:08:38 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8F1A0062 for ; Fri, 18 Apr 2014 19:08:38 -0700 (PDT) X-AuditID: c6180641-f79a26d000001830-40-535189c58b7e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1F.16.06192.5C981535; Fri, 18 Apr 2014 22:23:33 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 22:08:32 -0400 From: Acee Lindem To: prz Thread-Topic: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt Thread-Index: AQHPW0aJPmTagfMT+kORJpirhr5WfpsYN6cAgAAC2gCAADPcgP//kVQA Date: Sat, 19 Apr 2014 02:08:31 +0000 Message-ID: References: <20140418153616.2339.51730.idtracker@ietfa.amsl.com> <53515038.9070407@cisco.com> <54238B77-60C7-4392-B396-A5B6B43B31BC@ericsson.com> <53515978.5070700@cisco.com> <357C7548-A5EE-4849-B72F-4FD1D386BB8D@ericsson.com> <001e83b64d76b7eadea70a1854378b2d@zeta2.ch> <574D52F9-8870-4035-85D6-FB40E37AA91A@ericsson.com> <334a85406cc387a012a5962c112c21c8@zeta2.ch> In-Reply-To: <334a85406cc387a012a5962c112c21c8@zeta2.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <6416A69433B8D248B65A852EC50DBD45@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLrHW/doZ2CwweznZhYt9+6xW9zreszq wOSxZMlPJo8fy/4wBzBFcdmkpOZklqUW6dslcGUca3/DVHCMs+L6kgcsDYx72bsYOTkkBEwk uhc/ZoOwxSQu3FsPZgsJHGWUmNck3MXIBWQvZ5Q48bCJGSTBJqAj8fzRPyCbg0MEqKH5YRJI mFlAVuLZNogSYYFoic4N/xhBbBGBGIntDV+ZIGw3iRUNu8BsFgFViakPL7OA2LwCphLfZn1k hNi1jFni5LGbYMdxClhItO6fwQpiMwLt+n5qDRPEMnGJW0/mM0EcLSCxZM95ZghbVOLl439g 9aICehLvjsPUKEnMeX2NGaJXR2LB7k9sELa1xLeX8xghbG2JZQtfM0McJChxcuYTlgmMErOQ rJuFpH0WkvZZSNpnIWlfwMi6ipGjtDi1LDfdyHATIzDajkmwOe5gXPDJ8hCjAAejEg+v1lXf YCHWxLLiytxDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYDTdWze/t0up ZvnfC9OPmsh7XN7XeULIONLfOrij1EKKcdvzGuEv9do/b5XzzK8Kvr8qb7OkhPnB9KaXL35u fcqUmH340J6/8Xm7l1zq2XFcYUvOttOi3S6n5X+tV0h7J5L6uGK2kFIP24eTDhkJt6fo5pa8 WXp5kqPHCZ0Db1IrTrkdfC2TEafEUpyRaKjFXFScCADRDQL8lwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/JLOKmIUThmYDC6JXlwnfR4sYqP8 Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 02:08:43 -0000 Ok - Agreed.=20 Thanks, Acee=20 On 4/18/14 6:44 PM, "prz" wrote: > >>> . the only reason the migration holds together without stable loops >>> is that there is an implicit assumption in the draft (I didn't see it >>> spelled out but then again I skimmed over it only) that the metric >>> advertised in TLVs and old style is always absolutely the same. I >>> suggest to spell that out strongly. >> >> It is implicit but it seems rather obvious that if one originates the >> non-extended and extended versions of the same LSA, the content MUST >> be the same. However, I can state this explicitly. >> > > agreed but then again, there are so many metrics floating in those > protocols now that if you couple them implicitly (which you do with this > draft) I don't think spelling it out cleanly and strongly hurts (given > that the whole migration in the draft only holds together under this > very assumption). > > And I never seize to be amazed what kind of stuff people build based on > RFCs and how I come to completely wrong conclusion as what they mean > when I read them (but that can be just feeble old age of mine or > intentional by authors ;-) > > --- tony > > From nobody Fri Apr 18 19:14:41 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D6A1A0141 for ; Fri, 18 Apr 2014 19:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yi0Er2YiAWiL for ; Fri, 18 Apr 2014 19:14:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 172431A003A for ; Fri, 18 Apr 2014 19:14:37 -0700 (PDT) X-AuditID: c6180641-f79a26d000001830-61-53518b2c9865 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BA.26.06192.C2B81535; Fri, 18 Apr 2014 22:29:33 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 22:14:32 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: WG Discussion Thread-Index: AQHPW3UZuVEhhaXla0ylFkJXGFj+Og== Date: Sat, 19 Apr 2014 02:14:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_CF772A1A2CA63aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPoK5ud2CwwdEXfBYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4//mUywF87grfvb2MjcwHuHsYuTkkBAwkfj4/ToThC0mceHe erYuRi4OIYGjjBIfp01iBkkICSxnlNi9NwzEZhPQkXj+6B9YXERAXWL15N2sILawgLjE2zcb 2SHiMhL3j9xkhLD1JO48bAarYRFQlThy5hpYDa+AqcTn5ffAFjMCLf5+ag2YzQw059aT+VAH CUgs2XOeGcIWlXj5+B/YHFGgme+Ow9QoSXz8PZ8dojdK4s+7q0wQ8wUlTs58wjKBUXgWkrGz kJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHUL3WElfmXGBCVrOAkWMVI0dpcWpZbrqR4SZG YKQck2Bz3MG44JPlIUYBDkYlHl6tq77BQqyJZcWVuYcYpTlYlMR5v7x1DhISSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXA2Jrce2iKzYtpSSeubf6gqPTONuy44YtN3qz6dnmL13IWrwrynrj7 O0vbSs9rXGZC/8vPa7iqzXc67PK9dSVzw5aZb660/zzdIPaO5/0cl5O2696eWZCrOLH+POPz u9MkrMsqFa50/kyL0Iqqn8wadjJ24gPTCVf2aoZFfxe9bba37uFN29iVZ5VYijMSDbWYi4oT AX3xCmF1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/pmLNBO1NziCkIhZUe0nGPsLEKIk Subject: [OSPF] WG Discussion 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, 19 Apr 2014 02:14:38 -0000 --_000_CF772A1A2CA63aceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As of late, we've had some good discussion on a couple drafts. Please conti= nue! However, I'll be out for the next week and wouldn't want my silence to= be interpreted as lack of interest. Note that I don't turn on my automatic= OTO reply for external senders since I'm subscribed to at least 20 IETF li= sts. Thanks, Acee --_000_CF772A1A2CA63aceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7F2DE81A1E8469488FDA3371DA585535@ericsson.com> Content-Transfer-Encoding: quoted-printable
As of late, we've had some good discussion on a couple drafts. Please = continue! However, I'll be out for the next week and wouldn't want my = silence to be interpreted as lack of interest. Note that I don't turn on my= automatic OTO reply for external senders since I'm subscribed to at least 20 IETF lists.  

Thanks,
Acee 

--_000_CF772A1A2CA63aceelindemericssoncom_-- From nobody Fri Apr 18 20:49:06 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735B01A0225 for ; Fri, 18 Apr 2014 20:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 peIQk1za1p2S for ; Fri, 18 Apr 2014 20:49:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 607D11A0039 for ; Fri, 18 Apr 2014 20:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=806; q=dns/txt; s=iport; t=1397879336; x=1399088936; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6wmvN4RK+TUXVegf2xAEMNWwhxK+dYGOk2qtXcY1CbE=; b=a3GvnQoPC1sggrqZsWFBR83RKYPSLqV97CaJ7zPdjvUlGczRYND3Sa7v +CaiUdmId3iTyu/ukVx+dmBaqKE3xWfg9+v2lXKVNwwN2N+K93oOnNG2o 1GHQg2rOH6TB1Ouj5AVxfLv98uJBq8fGEZQ9qSLXloTOHL7TN+J7ivIXF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAPxUVOtJA2M/2dsb2JhbABagwZPV7w+hzyBGhZ0giUBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCAGIOA3NPReOMTgGgx6BFASrPYMxgis X-IronPort-AV: E=Sophos;i="4.97,887,1389744000"; d="scan'208";a="37085796" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 19 Apr 2014 03:48:56 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3J3muUu025873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Apr 2014 03:48:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 22:48:55 -0500 From: "Mike Dubrovskiy (mdubrovs)" To: Acee Lindem , OSPF List Thread-Topic: [OSPF] OSPF Draft Discussion Thread-Index: AQHPWP0/MXmfaa7NAE+1LZHibyaYSpsYMHUw Date: Sat, 19 Apr 2014 03:48:54 +0000 Message-ID: <534FD0D7D9E99740A077CE1A38EB79C33FA6620F@xmb-aln-x03.cisco.com> References: <76E38DC9-EB82-4B5F-A849-DD229B381006@ericsson.com> In-Reply-To: <76E38DC9-EB82-4B5F-A849-DD229B381006@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.81.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/p59BxTr350QTVpNdycEnrf8-nnE Subject: Re: [OSPF] OSPF Draft Discussion 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, 19 Apr 2014 03:49:04 -0000 Hi folks, Could you please take a look at the draft below and let us know your opinio= n. http://www.ietf.org/id/draft-dubrovsky-ospf-non-compatible-01.txt Thank you, Mike > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > Sent: Tuesday, April 15, 2014 3:52 PM > To: OSPF List > Subject: [OSPF] OSPF Draft Discussion >=20 > Draft Authors, >=20 > Don't hesitate to initiate discussion of your drafts on the list. There h= ave > been a number of drafts that have been presented at the last two IETFs th= at > we explicitly decided to discuss on this list. >=20 > Thanks, > Abhay and Acee >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Wed Apr 23 23:39:12 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08A1A07B5 for ; Wed, 23 Apr 2014 23:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 UF9JswnItp1I for ; Wed, 23 Apr 2014 23:39:07 -0700 (PDT) Received: from nm42-vm10.bullet.mail.bf1.yahoo.com (nm42-vm10.bullet.mail.bf1.yahoo.com [216.109.114.155]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12D1A07B2 for ; Wed, 23 Apr 2014 23:39:07 -0700 (PDT) Received: from [98.139.215.142] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2014 06:39:01 -0000 Received: from [98.139.212.246] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2014 06:39:00 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 24 Apr 2014 06:39:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 901636.91885.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 26600 invoked by uid 60001); 24 Apr 2014 06:39:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398321540; bh=Uiujm7qXMZ7j4tDmzYa1GN59HHMxcBbiS2EDatekMkk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5svpTkH6b815lZxBoSEJZ3T8eRHGBifjpWxJ7szS13fJ1kMMKl6aykn0p4lri36iOqjOatXz75pyfD+1EIqLADh4bMvJaKM1Nqkmtly1HqBY1Om1Z7GKWrcszfM75Y41d6pyoycL0SOAkZXE2ckklyDlZgcy5lsDZYggOeFz6qg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2nHWGbL5AiSDiX78qyMoOQgIQllG9jEIjqJTcpPlVplO9hk0irAU11w/ap3sCrx3djV3GB1R/NB/d2MBG09vulyuP87bByDpfg3e7gKKrpS7qo31iy8X58f+jjjX8sFJjrQArAx6GJmjyUCpHdH8gfeVeyOf21YxDULfX/OXeag=; X-YMail-OSG: x6jiYGMVM1kULRQsJdOhhtU7TfxlzTqm304NUY6Rmi0lROj xjiI4aSy0mDIuxxmt7u2Bfs7o3fyEuc9CgcBE6KRB1NVqngFwDShwOK.iUw2 .nQ5DHJ_8Cp6CeDHuaBUlR_67WGUC4d8dGce93Gyre7PbSix5XkeV918TgKT lhuAW5mSerxZUzI2LiNBTPgtREQ8k1OfY9aD0TZB1ylgfwiLjIBpipjPItQb y3uY0iFBAqfjULstDlQYezrX7w6QcVdelxN1NONd.bEx6LelqjIzXbyHlOQw 4NEkfTTMl6dfXLfxLPRrbng11HCnjG3zAVajG5TRVExNdKdoHWnUAD7nWRDp mtwjqBOBIHsARC.RUa0qBaqZXmWwyjGhkcs9NO24akrGOdXZr_21SffMlKy9 eSMLRm_kfvdTDiEsO2_gM3VvOmFSI4jGQgNfjry1ZS.MmSoWOZGRsv.QTiCW YewgIH2LT32VWYMLhfQxKx1huUES8Lp9.wklV.2b0Au8G.edH.YV78jLqvq7 r0vWi70RyIR4w5l_FVYUDUH6NbieuXsUFNpqTWJVMvoZvOe4CU6Q- Received: from [109.186.61.54] by web165005.mail.bf1.yahoo.com via HTTP; Wed, 23 Apr 2014 23:39:00 PDT X-Rocket-MIMEInfo: 002.001, SGksCkkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyBhIHNpZ25pZmljYW50IHN0ZXAgZm9yd2FyZCBmb3IgdGhlIHNlY3VyaXR5IG9mIE9TUEYuIEkgZG8gaGF2ZSBvbmUgY29tbWVudCwgdGhvdWdoLsKgSXQgaXMgY29uY2VybmVkIHdpdGggdGhlIGNhc2UgaW4gd2hpY2ggdGhlIHNhbWUga2V5IGlzIGNvbmZpZ3VyZWQgb24gZGlmZmVyZW50IGxpbmtzLiBJZiBzdWNoIGEgc2l0dWF0aW9uIG9jY3VycyB0aGVuIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gcmVjb3JkIGFuIE9TUEYgbWVzc2FnZSBvbiBvbmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <53478C07.1020006@cisco.com> Message-ID: <1398321540.26301.YahooMailNeo@web165005.mail.bf1.yahoo.com> Date: Wed, 23 Apr 2014 23:39:00 -0700 (PDT) From: Gabi Nakibly To: Abhay Roy , "ospf@ietf.org" In-Reply-To: <53478C07.1020006@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="571662966-391532315-1398321540=:26301" Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/m2Paij4PudCbldRnf5-bmwHsoMQ Subject: Re: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Gabi Nakibly List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:39:09 -0000 --571662966-391532315-1398321540=:26301 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0AI think this document is a significant step forward for the security = of OSPF. I do have one comment, though.=A0It is concerned with the case in = which the same key is configured on different links. If such a situation oc= curs then an attacker might be able to record an OSPF message on one link a= nd replay it on another. This is particularly relevant for cases where one = router uses the same source address in multiple links (e.g. a virtual link = and a physical link). So the attacker can record a packet sent by that rout= er on one of the links and replay it over the other as if it was sent by th= e router itself. This may allow an attacker to cause an adjacency to be bro= ught down.=0AMoreover, a recorded Hello message may be replayed on arbitrar= y links (even those that do not share a router using the same source addres= s). If I am not mistaken, RFC2328 does not mandate to discard an Hello mess= age having a source address that is not part of the subnet of the interface= on which the message was received. Therefore, the recipient of the replaye= d message would allocate a new neighbor entry, thus giving rise to a DoS at= tack.=0A=0AI know that the OSPF standard allows to configure different keys= for different links, nonetheless in most of the OSPF deployments I have se= en the same key is configured for all links in the AS (or area). I do not k= now if this is representative of OSPF deployments worldwide, but it might b= e prudent to analyse the security of the proposed extensions in the context= of such cases as well.=0A=0AGabi=0A=0A=0A=0A>_____________________________= ___=0A> From: Abhay Roy =0A>To: "ospf@ietf.org" =0A>Sent: Friday, April 11, 2014 9:30 AM=0A>Subject: [OSPF] Working Gro= up last Call on "Security Extension for OSPFv2 when using Manual Key Manage= ment" - draft-ietf-ospf-security-extension-manual-keying-07=0A> =0A>=0A>All= ,=0A>=0A>We are starting a WG LC on the subject document. Document has been= =0A>stable for a while, and Manav was kind enough to present it one last = =0A>time in IETF89 (London). LC will end at 9am PST on 25th April 2014.=0A>= =0A>Please review the document and send any final comments prior to the LC = =0A>deadline.=0A>=0A>Regards,=0A>-Abhay=0A>=0A>____________________________= ___________________=0A>OSPF mailing list=0A>OSPF@ietf.org=0A>https://www.ie= tf.org/mailman/listinfo/ospf=0A>=0A>=0A> --571662966-391532315-1398321540=:26301 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
I think this document is a significant= step forward for the security of OSPF. I do have one comment, though. = ;It is concerned with the case in which th= e same key is configured on different links. If such a situation occurs the= n an attacker might be able to record an OSPF message on one link and repla= y it on another. This is particularly relevant for cases where one router u= ses the same source address in multiple links (e.g. a virtual link and a ph= ysical link). So the attacker can record a packet sent by that router on on= e of the links and replay it over the other as if it was sent by the router= itself. This may allow an attacker to cause an adjacency to be brought down.
Moreover, a recorded Hello me= ssage may be replayed on arbitrary links (even those that do not share a ro= uter using the same source address). If I am not mistaken, RFC2328 does not= mandate to discard an Hello message having a source address that is not pa= rt of the subnet of the interface on which the message was received. Theref= ore, the recipient of the replayed message would allocate a new neighbor en= try, thus giving rise to a DoS attack.

I know that the OSPF= standard allows to configure different keys for different links, nonethele= ss in most of the OSPF deployments I have seen the same key is configured f= or all links in the AS (or area). I do not know if this is representative o= f OSPF deployments worldwide, but it might be prudent to analyse the securi= ty of the proposed extensions in the context of such cases as well.

Gabi

From: Abhay Roy <akr@cisco.com> To: "ospf@ietf.org" <ospf@ietf.org> Sent: Friday, April 11, 2014 9:30 AM
Subject: [OSPF] Working Group last Call on "Security Ext= ension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-secur= ity-extension-manual-keying-07

All,

We are starting a WG LC on the subject docu= ment. Document has been
stable for a while, and M= anav was kind enough to present it one last
time = in IETF89 (London). LC will end at 9am PST on 25th April 2014.

Please review the document and send = any final comments prior to the LC
deadline.

Regards,
-Abhay

___________= ____________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listin= fo/ospf


= --571662966-391532315-1398321540=:26301-- From nobody Thu Apr 24 10:29:36 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6856F1A026A for ; Thu, 24 Apr 2014 10:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onyCGtmU58WN for ; Thu, 24 Apr 2014 10:29:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 34A721A01DB for ; Thu, 24 Apr 2014 10:29:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6ABD01801A2; Thu, 24 Apr 2014 10:28:27 -0700 (PDT) To: jmoy@casc.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140424172827.6ABD01801A2@rfc-editor.org> Date: Thu, 24 Apr 2014 10:28:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/BJ9ksaJQEycC80SL3AyL3eOkc44 Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC2328 (3974) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:29:26 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3974 -------------------------------------- Type: Technical Reported by: Mike Dubrovsky Section: 13 Original Text ------------- (6) Else, if there is an instance of the LSA on the sending neighbor's Link state request list, an error has occurred in the Database Exchange process. In this case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor and stop processing the Link State Update packet. (7) Else, if the received LSA is the same instance as the database copy (i.e., neither one is more recent) the following two steps should be performed: (a) If the LSA is listed in the Link state retransmission list for the receiving adjacency, the router itself is expecting an acknowledgment for this LSA. The router should treat the received LSA as an acknowledgment by removing the LSA from the Link state retransmission list. This is termed an "implied acknowledgment". Its occurrence should be noted for later use by the acknowledgment process (Section 13.5). (b) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5. Corrected Text -------------- (6) Else, if the received LSA is the same instance as the database copy (i.e., neither one is more recent) the following two steps should be performed: (a) If the LSA is listed in the Link state retransmission list for the receiving adjacency, the router itself is expecting an acknowledgment for this LSA. The router should treat the received LSA as an acknowledgment by removing the LSA from the Link state retransmission list. This is termed an "implied acknowledgment". Its occurrence should be noted for later use by the acknowledgment process (Section 13.5). (b) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5. (7) Else, if there is an instance of the LSA on the sending neighbor's Link state request list, an error has occurred in the Database Exchange process. In this case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor and stop processing the Link State Update packet. Notes ----- The problem arises when the routing domain has two instances of LSA with the same sequence number and the same checksum, but with an age difference bigger than MaxAgeDiff. The above could take place in multiple scenarios. Here are two examples: 1) There is a demand circuit somewhere in the routing domain 2) The router lost its ASBR status and therefore flushed the self-originated Type 5 LSAs but later on gained the ASBR status back and re-originated Type 5. If the network was partitioned, each partition can have two instances of LSA with an age difference bigger than MaxAgeDiff. The two instances of LSA can temporarily prevent the adjacency formation. Consider the example below: Topology ======== RT1 ----- RT2 Initial state: ============== The physical link between RT1 and R2 just came up The routers are about to form ospf adjacency. Initial link-state databases: ============================= R1 ospf database has LSA 10.0.0.1 age 910 seq # 0x80000001 R2 ospf database has the same LSA 10.0.0.1 age 9 seq # 0x80000001 RT1 Event Sequence: =============== RT1 is starting to form adjacency with RT2. 1) During the Database Exchange, RT2's LSA instance is more recent because of more than 900 (MaxAgeDiff) seconds age difference (section 13.1 of RFC 2328). 2) So RT1 requests the LSA 3) RT2 sends the LSA after incrementing the age by 1 (InfTransDelay). 4) When the LSA instance arrives to RT1, it is identical (the difference is exactly 900 seconds now). So RT1 aborts Loading according to step (6) of section 13. Solution: ========= Swap steps (6) and (7) of section 13. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Apr 27 12:33:52 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB831A03FC for ; Sun, 27 Apr 2014 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.853 X-Spam-Level: X-Spam-Status: No, score=-101.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhEgVvmshtnj for ; Sun, 27 Apr 2014 12:33:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 4184F1A03B3 for ; Sun, 27 Apr 2014 12:33:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2093918000E; Sun, 27 Apr 2014 12:33:44 -0700 (PDT) To: aretana@cisco.com, dean.cheng@huawei.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140427193344.2093918000E@rfc-editor.org> Date: Sun, 27 Apr 2014 12:33:44 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/miXedi8H_u_czMgrISfXi7Faemc Cc: ospf@ietf.org, Peter.Paluch@fri.uniza.sk, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC6969 (3975) 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, 27 Apr 2014 19:33:51 -0000 The following errata report has been submitted for RFC6969, "OSPFv3 Instance ID Registry Update". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6969&eid=3975 -------------------------------------- Type: Editorial Reported by: Peter Palúch Section: 1 Original Text ------------- +---------+---------------------------------------------+-----------+ | Value | Description | Reference | +---------+---------------------------------------------+-----------+ | 0 | IPv6 unicast AF | [RFC5838] | | 1 - 31 | Base IPv6 Unicast AF dependent on local | [RFC5838] | | | policy | | | 32 | Base IPv6 Multicast | [RFC5838] | | 33-63 | IPv6 Multicast AFs dependent on local | [RFC5838] | | | policy | | | 64 | Base IPv4 Unicast AF | [RFC5838] | | 65-95 | IPv4 Unicast AFs dependent on local policy | [RFC5838] | | 96 | Base IPv4 Multicast | [RFC5838] | | 97-127 | IPv4 Multicast AFs dependent on local | [RFC5838] | | | policy | | | 128-255 | Unassigned | [RFC5838] | +---------+---------------------------------------------+-----------+ Corrected Text -------------- +---------+---------------------------------------------+-----------+ | Value | Description | Reference | +---------+---------------------------------------------+-----------+ | 0 | Base IPv6 Unicast AF | [RFC5838] | | 1 - 31 | IPv6 Unicast AFs dependent on local policy | [RFC5838] | | 32 | Base IPv6 Multicast AF | [RFC5838] | | 33-63 | IPv6 Multicast AFs dependent on local | [RFC5838] | | | policy | | | 64 | Base IPv4 Unicast AF | [RFC5838] | | 65-95 | IPv4 Unicast AFs dependent on local policy | [RFC5838] | | 96 | Base IPv4 Multicast | [RFC5838] | | 97-127 | IPv4 Multicast AFs dependent on local | [RFC5838] | | | policy | | | 128-255 | Unassigned | [RFC5838] | +---------+---------------------------------------------+-----------+ Notes ----- The term "Base" applies to Instance ID 0, not to IDs 1-31 which are additional IPv6 unicast AFs. Additionally, to keep the formatting consistent, the first letter in terms "Unicast" and "Multicast" is capitalized in each term instance. Also, in the description of values 1-31, "AF" is replaced with "AFs". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6969 (draft-ietf-ospf-ospfv3-iid-registry-update-04) -------------------------------------- Title : OSPFv3 Instance ID Registry Update Publication Date : July 2013 Author(s) : A. Retana, D. Cheng Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Apr 27 12:43:26 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0486B1A03B3 for ; Sun, 27 Apr 2014 12:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFgo08P7SMSO for ; Sun, 27 Apr 2014 12:43:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7301A03B1 for ; Sun, 27 Apr 2014 12:43:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E60D718000F; Sun, 27 Apr 2014 12:43:17 -0700 (PDT) To: aretana@cisco.com, dean.cheng@huawei.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140427194317.E60D718000F@rfc-editor.org> Date: Sun, 27 Apr 2014 12:43:17 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/-f-zsk38vTbc9qY_9DgdhSaINdA Cc: ospf@ietf.org, Peter.Paluch@fri.uniza.sk, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC6969 (3976) 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, 27 Apr 2014 19:43:24 -0000 The following errata report has been submitted for RFC6969, "OSPFv3 Instance ID Registry Update". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6969&eid=3976 -------------------------------------- Type: Editorial Reported by: Peter Palúch Section: 2 Original Text ------------- +--------------------------+---------------+-----------------------+ | Value | Description | Reference | +--------------------------+---------------+-----------------------+ | 128-191 | Unassigned | 192-255 | | Reserved for Private Use | this document | Private Use [RFC5226] | +--------------------------+---------------+-----------------------+ Corrected Text -------------- +-------------+--------------------------+-------------------------+ | Value | Description | Reference | +-------------+--------------------------+-------------------------+ | 128-191 | Unassigned | | | 192-255 | Reserved for Private Use | This Document [RFC6969] | +-------------+--------------------------+-------------------------+ Notes ----- The table was obviously misformatted. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6969 (draft-ietf-ospf-ospfv3-iid-registry-update-04) -------------------------------------- Title : OSPFv3 Instance ID Registry Update Publication Date : July 2013 Author(s) : A. Retana, D. Cheng Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Apr 28 08:06:34 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54DB1A0971 for ; Mon, 28 Apr 2014 08:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aNhiyHwZt5y6 for ; Mon, 28 Apr 2014 08:06:27 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id F09661A04C5 for ; Mon, 28 Apr 2014 08:06:26 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-f3-535e1fe54b20 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.B9.07420.5EF1E535; Mon, 28 Apr 2014 11:31:17 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 11:06:25 -0400 From: Acee Lindem To: Gabi Nakibly Thread-Topic: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 Thread-Index: AQHPX4fmHHGQC+tyAEGkxngfSa1O6JsnatUA Date: Mon, 28 Apr 2014 15:06:24 +0000 Message-ID: <481A10B2-4F1F-478C-A7A9-DFA780005D7A@ericsson.com> References: <53478C07.1020006@cisco.com> <1398321540.26301.YahooMailNeo@web165005.mail.bf1.yahoo.com> In-Reply-To: <1398321540.26301.YahooMailNeo@web165005.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_481A10B24F1F478CA7A9DFA780005D7Aericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLrHW/epfFywwdE2NYvDB2exWWw9OoXR ouXePXYHZo8pvzeyeixZ8pPJY9asw0wBzFFcNimpOZllqUX6dglcGXs+zGEtWBJT8XWPSgPj Fd8uRk4OCQETiT9/b7JB2GISF+6tB7K5OIQEjjJKzJv4khUkISSwnFGiuVsJxGYT0JF4/ugf M4gtIqAqMXnOKsYuRg4OZgELidZr2SC9wgIrGSW2d6xkB3FEBFYxSnRM2sAK0WAk8erMNiYQ mwWoedLHrWBxXgF7ieut96CWpUssv/KGHcTmFPCUeL3gCZjNCHTd91NrwHqZBcQlbj2ZzwRx tYDEkj3nmSFsUYmXj/+xQthKEnNeX2OGOC5Z4tq5TIhVghInZz5hmcAoOgvJpFkIVbOQVEGU GEi8PzefGcLWlli28DWUrS+x8ctZRgjbWmLp2ouMyGoWMHKsYuQoLU4ty003MtjECIy+YxJs ujsY97y0PMQowMGoxMPLuCwyWIg1say4MvcQozQHi5I4b8GX2GBgGCSWpGanphakFsUXleak Fh9iZOLglGpgFM81dbIwbFzLULZoRvF/ac/pRrOr5XX1f/lzbjo/rdk9I6Hj8svjC+aZhDsm C2RL3cuauWFSynvOLVZvc5d0fPDmOL54rXDcxdUHPF0N/c1PKX1dqbqm+KtYncL2sF8ftYIn FS5fvWjv8XeC5QKr75gbRnCszThi8EnmxvxjEo83Tmyynh4vosRSnJFoqMVcVJwIAC4KzZKf AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/-_MS6oRiV6eWBnOYMRywderR2r4 Cc: OSPF List Subject: Re: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 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, 28 Apr 2014 15:06:32 -0000 --_000_481A10B24F1F478CA7A9DFA780005D7Aericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gabi, Thanks much for your review and comment. On Apr 24, 2014, at 2:39 AM, Gabi Nakibly > wrote: Hi, I think this document is a significant step forward for the security of OSP= F. I do have one comment, though. It is concerned with the case in which th= e same key is configured on different links. If such a situation occurs the= n an attacker might be able to record an OSPF message on one link and repla= y it on another. This is particularly relevant for cases where one router u= ses the same source address in multiple links (e.g. a virtual link and a ph= ysical link). So the attacker can record a packet sent by that router on on= e of the links and replay it over the other as if it was sent by the router= itself. This may allow an attacker to cause an adjacency to be brought dow= n. Note that in section 2 we are recommending one sequence number space for th= e OSPF router as opposed to one per interface. Hence, this would have to be= a replayed packet received from another router with the same source addres= s since the OSPF Router ID in the OSPF header would be protected by the aut= hentication hash. I would consider this to be a misconfiguration. Moreover, a recorded Hello message may be replayed on arbitrary links (even= those that do not share a router using the same source address). If I am n= ot mistaken, RFC2328 does not mandate to discard an Hello message having a = source address that is not part of the subnet of the interface on which the= message was received. RFC 2328 does mandate source subnet checking on multi-access networks but n= ot P2P networks. On P2P networks, this could be a problem but would require= the attacker to have an active tap on both the P2P interface and another i= nterface using the same key. Again, this would have to be a replayed packe= t received from another router due to the OSPF router=92s use a single sequ= ence number space. There really isn=92t a good solution for this problem on= P2P links since the routers don=92t share any common identifier for the P2= P link. They have an ifIndex but this is a locally unique interface identif= ier. We can document the problem and recommend use of different keys if the= possibility of active taps on P2P interfaces exists. Thanks, Acee Therefore, the recipient of the replayed message would allocate a new neigh= bor entry, thus giving rise to a DoS attack. I know that the OSPF standard allows to configure different keys for differ= ent links, nonetheless in most of the OSPF deployments I have seen the same= key is configured for all links in the AS (or area). I do not know if this= is representative of OSPF deployments worldwide, but it might be prudent t= o analyse the security of the proposed extensions in the context of such ca= ses as well. Gabi ________________________________ From: Abhay Roy > To: "ospf@ietf.org" > Sent: Friday, April 11, 2014 9:30 AM Subject: [OSPF] Working Group last Call on "Security Extension for OSPFv2 w= hen using Manual Key Management" - draft-ietf-ospf-security-extension-manua= l-keying-07 All, We are starting a WG LC on the subject document. Document has been stable for a while, and Manav was kind enough to present it one last time in IETF89 (London). LC will end at 9am PST on 25th April 2014. Please review the document and send any final comments prior to the LC deadline. Regards, -Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_481A10B24F1F478CA7A9DFA780005D7Aericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <306C17F945AB6449A9F8A4FCD216A188@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi Gabi, 
Thanks much for your review and comment.

On Apr 24, 2014, at 2:39 AM, Gabi Nakibly <gnakibly@yahoo.com> wrote:

Hi,
I think this document is a significant step forw= ard for the security of OSPF. I do have one comment, though. It is concerned with the case in which the same key= is configured on different links. If such a situation occurs then an attacker might be able to record an OSPF messag= e on one link and replay it on another. This is particularly relevant for c= ases where one router uses the same source address in multiple links (e.g. = a virtual link and a physical link). So the attacker can record a packet sent by that router on one of the link= s and replay it over the other as if it was sent by the router itself. This= may allow an attacker to cause an adjacency to be brought down.

Note that in section 2 we are recommending one sequence number space f= or the OSPF router as opposed to one per interface. Hence, this would have = to be a replayed packet received from another router with the same source a= ddress since the OSPF Router ID in the OSPF header would be protected by the authentication hash. I would = consider this to be a misconfiguration. 

Moreover, a recorded Hello message may be replay= ed on arbitrary links (even those that do not share a router using the same= source address). If I am not mistaken, RFC2328 does not mandate to discard= an Hello message having a source address that is not part of the subnet of the interface on which the message was r= eceived.

RFC 2328 does mandate source subnet checking on multi-access networks = but not P2P networks. On P2P networks, this could be a problem but would re= quire the attacker to have an active tap on both the P2P interface and anot= her interface using the same key.  Again, this would have to be a replayed packet received from another= router due to the OSPF router=92s use a single sequence number space. Ther= e really isn=92t a good solution for this problem on P2P links since the ro= uters don=92t share any common identifier for the P2P link. They have an ifIndex but this is a locally unique interface = identifier. We can document the problem and recommend use of different keys= if the possibility of active taps on P2P interfaces exists. 

Thanks,
Acee

Therefore, the recipient of the replayed message= would allocate a new neighbor entry, thus giving rise to a DoS attack.

I know that the OSPF standard allows to configur= e different keys for different links, nonetheless in most of the OSPF deplo= yments I have seen the same key is configured for all links in the AS (or a= rea). I do not know if this is representative of OSPF deployments worldwide, but it might be prudent to analyse the secu= rity of the proposed extensions in the context of such cases as well.

Gabi

From: Abhay Ro= y <akr@cisco.com>
To: "ospf@ietf.org" &l= t;ospf@ietf.org>
Sent:= Friday, April 11, 2014 9:30 AM
Subje= ct: [OSPF] Working Group last Call on "Security Extension f= or OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security= -extension-manual-keying-07

All,

We are starting a WG LC on the subject document. Document has been
stable for a while, and Manav was kind enough to present it one last
time in IETF89 (London). LC will end at 9am PST on 25th April 2014.

Please review the document and send any final comments prior to the LC
deadline.

Regards,
-Abhay

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

--_000_481A10B24F1F478CA7A9DFA780005D7Aericssoncom_-- From nobody Mon Apr 28 08:15:47 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431491A08C5 for ; Mon, 28 Apr 2014 08:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U487Vx9B1_PE for ; Mon, 28 Apr 2014 08:15:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B5C691A01DF for ; Mon, 28 Apr 2014 08:15:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9396B18000E; Mon, 28 Apr 2014 08:15:35 -0700 (PDT) To: yiya@cisco.com, aretana@cisco.com, akr@cisco.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140428151535.9396B18000E@rfc-editor.org> Date: Mon, 28 Apr 2014 08:15:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Cvn6sJ-yKtPhtyWwzC3fCAw5KT4 Cc: ospf@ietf.org, Peter.Paluch@fri.uniza.sk, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC6860 (3977) 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, 28 Apr 2014 15:15:45 -0000 The following errata report has been submitted for RFC6860, "Hiding Transit-Only Networks in OSPF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6860&eid=3977 -------------------------------------- Type: Technical Reported by: Peter Paluch Section: 3 Original Text ------------- To hide a transit-only network in [OSPFv3], the IPv6 address prefixes are omitted from the router-LSA. Consequently, when a Designated Router builds an intra-area-prefix-LSA referencing a network-LSA, these IPv6 address prefixes will be omitted. Corrected Text -------------- To hide a transit-only network in [OSPFv3], the associated IPv6 address prefixes MUST be omitted from the link-LSA. Consequently, when a Designated Router builds an intra-area-prefix-LSA referencing a network-LSA, these IPv6 address prefixes will be omitted. Notes ----- The change essentially reverts the paragraph back to the formulation from http://tools.ietf.org/html/draft-ietf-ospf-prefix-hiding-05#section-3 . Most importantly, the term "router-LSA" is replaced with "link-LSA", as there are already no prefixes carried in OSFPv3 router-LSA whatsoever, and the removal of transit-network prefixes influences link-LSAs and intra-area-prefix-LSAs. Also, the change reintroduces the keyword "MUST" that underlines the behavior that is crucial to the proper implementation of the feature. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6860 (draft-ietf-ospf-prefix-hiding-07) -------------------------------------- Title : Hiding Transit-Only Networks in OSPF Publication Date : January 2013 Author(s) : Y. Yang, A. Retana, A. Roy Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Apr 29 06:18:34 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8251A08DC for ; Tue, 29 Apr 2014 06:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alhGNi-Gvdal for ; Tue, 29 Apr 2014 06:18:30 -0700 (PDT) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF5F1A08C6 for ; Tue, 29 Apr 2014 06:18:30 -0700 (PDT) Received: from [98.139.212.151] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 13:18:29 -0000 Received: from [98.139.212.201] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 13:18:28 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 29 Apr 2014 13:18:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 860167.39416.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 16906 invoked by uid 60001); 29 Apr 2014 13:18:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398777508; bh=ZxbwuSJjoo35zB6ZDeel77hckvjfAQtjpmtEeSsVYa8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BKZOBoMkeKe/o3+KxnE5ltfIxmhxSwtMB5yyG1DrkmqRdfe9BO6d3gTTuAAx9MaFsnSaw2ZxfEDj9jhph6KFGwNtAmsO1WJXUqu4IfnCC6kZ1WRicpXyok2IV2oxOr7l/HjAuqLg9fgaFWAYEv4gtbLAqF40quK7BkMve9CGHBo= X-YMail-OSG: z8fwK1oVM1mz3w0Y2M7MF2kI_aaib.BlBK3o_83yHHvB74z FDsXcpW8TlP0_ZBbpVafWImMVcW4pW7_Bao1nKoGGLKXW.S8mrY4g4GCIpwY S9cNoIFqx1Hd3.FDuQRe6n1Ts2jjd._Kg4Q0toP8Jj0oAqG3InzlG.aKsXl0 tvqKp4dAJKEL2exqVtNvUXS7ikatl6FHkYhI.0cBwD8fnwkVhHfysx9hdtGl wuDNRQobyBwMdQzl1WJgZqvo_SGlTKaXohAciUzBrqdRoWPtU68Lm8yDP6X0 kVImGyQEgZ0oioN.6MiUpJpoz8T_1W3ynqvc8SHVA8aK2B0UabVanrRbXEPE 0k9Ssnga0m7sMsPIVZTgg53fCFkys9TcCPL8ghZw50E2BkvxpmPjiaIFo3Ia ZdYk85nIkD3zosiZEXEosvhz40K86M4Ke.kZLui01CIOpfShTAFkDnigjcEL QKmnlFqWlqCD3ax5bTi0NT9uhzqbVyFHEnLOOEYCSTfbJQQKLpT3gRgsSQru mrPUctknreuIuAQFDACldPTnzzi2LyMOidulwRkHLLjFoQ0DSdfo- Received: from [109.186.61.54] by web165006.mail.bf1.yahoo.com via HTTP; Tue, 29 Apr 2014 06:18:28 PDT X-Rocket-MIMEInfo: 002.001, SGkgQWNlZSwKVGhhbmtzIGZvciB0aGUgcmVwbHkuCkp1c3QgdG8gY2xhcmlmeSBteSB0aG91Z2h0cywgSSBiZWxpZXZlIHRoYXQgdGhlIHVzZSBvZiBhIHNpbmdsZSBzZXF1ZW5jZSBudW1iZXIgc3BhY2UgcGVyIHJvdXRlciBkb2VzIG5vdCBwcmV2ZW50IHRoZSBhdHRhY2suIEhlcmUgaXMgYW4gZXhhbXBsZS4gTGV0J3Mgc2F5IGEgcm91dGVyIGlzIGF0dGFjaGVkIHRvIHR3byBsaW5rcyAoQSBhbmQgQikgd2hpbGUgdXNpbmcgdGhlIHNhbWUgSVAgYWRkcmVzcy4gTGV0J3Mgc2F5IHRoZSBhdHRhY2tlciBoYXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <53478C07.1020006@cisco.com> <1398321540.26301.YahooMailNeo@web165005.mail.bf1.yahoo.com> <481A10B2-4F1F-478C-A7A9-DFA780005D7A@ericsson.com> Message-ID: <1398777508.12837.YahooMailNeo@web165006.mail.bf1.yahoo.com> Date: Tue, 29 Apr 2014 06:18:28 -0700 (PDT) From: Gabi Nakibly To: Acee Lindem In-Reply-To: <481A10B2-4F1F-478C-A7A9-DFA780005D7A@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="235176295-301273287-1398777508=:12837" Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/NNZfrCvNZSmD0t4-GqM2HPLFUSQ Cc: OSPF List Subject: Re: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-extension-manual-keying-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Gabi Nakibly List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 13:18:33 -0000 --235176295-301273287-1398777508=:12837 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Acee,=0AThanks for the reply.=0AJust to clarify my thoughts, I believe t= hat the use of a single sequence number space per router does not prevent t= he attack. Here is an example. Let's say a router is attached to two links = (A and B) while using the same IP address. Let's say the attacker has recor= ded an Hello message the router just sent on link A. When the router sends = this message its SN is higher than any other packet sent on any other link = by that router. The attacker would now be able successfully replay the reco= rded Hello message on link B as long as it does so before the router sends = another OSPF message on link B. Such an attack will probably bring down all= adjacencies of the router on link B.=0A=0AI think it would be good to docu= ment this type of attacks as many network operators configure the same key = on different links. It would be good to bring to their attention the conseq= uences of such configurations. If you wish, I can assist in writing this.= =0A=0AGabi=0A=0A=0A>________________________________=0A> From: Acee Lindem = =0A>To: Gabi Nakibly =0A>Cc:= Abhay Roy ; OSPF List =0A>Sent: Monday, Apr= il 28, 2014 6:06 PM=0A>Subject: Re: [OSPF] Working Group last Call on "Secu= rity Extension for OSPFv2 when using Manual Key Management" - draft-ietf-os= pf-security-extension-manual-keying-07=0A> =0A>=0A>=0A>Hi Gabi,=C2=A0 =0A>T= hanks much for your review and comment.=0A>=0A>=0A>On Apr 24, 2014, at 2:39= AM, Gabi Nakibly wrote:=0A>=0A>Hi,=0A>>I think this d= ocument is a significant step forward for the security of OSPF. I do have o= ne comment, though.=C2=A0It is concerned with the case in which the same ke= y is configured on different links. If such a situation occurs then an atta= cker might be able to record an OSPF message on one link and replay it on a= nother. This is particularly relevant for cases where one router uses the s= ame source address in multiple links (e.g. a virtual link and a physical li= nk). So the attacker can record a packet sent by that router on one of the = links and replay it over the other as if it was sent by the router itself. = This may allow an attacker to cause an adjacency to be brought down.=0A>=0A= >=0A>Note that in section 2 we are recommending one sequence number space f= or the OSPF router as opposed to one per interface. Hence, this would have = to be a replayed packet received from another router with the same source a= ddress since the OSPF Router ID in the OSPF header would be protected by th= e authentication hash. I would consider this to be a misconfiguration.=C2= =A0=0A>=0A>=0A>Moreover, a recorded Hello message may be replayed on arbitr= ary links (even those that do not share a router using the same source addr= ess). If I am not mistaken, RFC2328 does not mandate to discard an Hello me= ssage having a source address that is not part of the subnet of the interfa= ce on which the message was received.=0A>=0A>=0A>RFC 2328 does mandate sour= ce subnet checking on multi-access networks but not P2P networks. On P2P ne= tworks, this could be a problem but would require the attacker to have an a= ctive tap on both the P2P interface and another interface using the same ke= y. =C2=A0Again, this would have to be a replayed packet received from anoth= er router due to the OSPF router=E2=80=99s use a single sequence number spa= ce. There really isn=E2=80=99t a good solution for this problem on P2P link= s since the routers don=E2=80=99t share any common identifier for the P2P l= ink. They have an ifIndex but this is a locally unique interface identifier= . We can document the problem and recommend use of different keys if the po= ssibility of active taps on P2P interfaces exists.=C2=A0=0A>=0A>=0A>Thanks,= =0A>Acee=0A>=0A>=0A>Therefore, the recipient of the replayed message would = allocate a new neighbor entry, thus giving rise to a DoS attack.=0A>>=0A>>= =0A>>I know that the OSPF standard allows to configure different keys for d= ifferent links, nonetheless in most of the OSPF deployments I have seen the= same key is configured for all links in the AS (or area). I do not know if= this is representative of OSPF deployments worldwide, but it might be prud= ent to analyse the security of the proposed extensions in the context of su= ch cases as well.=0A>>=0A>>=0A>>Gabi=0A>>=0A>>=0A>>=0A>>=0A>>>_____________= ___________________=0A>>> From: Abhay Roy =0A>>>To: "ospf@ie= tf.org" =0A>>>Sent: Friday, April 11, 2014 9:30 AM=0A>>>Sub= ject: [OSPF] Working Group last Call on "Security Extension for OSPFv2 when= using Manual Key Management" - draft-ietf-ospf-security-extension-manual-k= eying-07=0A>>>=0A>>>=0A>>>All,=0A>>>=0A>>>We are starting a WG LC on the su= bject document. Document has been =0A>>>stable for a while, and Manav was k= ind enough to present it one last =0A>>>time in IETF89 (London). LC will en= d at 9am PST on 25th April 2014.=0A>>>=0A>>>Please review the document and = send any final comments prior to the LC =0A>>>deadline.=0A>>>=0A>>>Regards,= =0A>>>-Abhay=0A>>>=0A>>>_______________________________________________=0A>= >>OSPF mailing list=0A>>>OSPF@ietf.org=0A>>>https://www.ietf.org/mailman/li= stinfo/ospf=0A>>>=0A>>>=0A>>>=0A___________________________________________= ____=0A>>OSPF mailing list=0A>>OSPF@ietf.org=0A>>https://www.ietf.org/mailm= an/listinfo/ospf=0A>>=0A>=0A>=0A>=0A> --235176295-301273287-1398777508=:12837 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ace= e,
Thanks for the reply.
Just t= o clarify my thoughts, I believe that the use of a single sequence number s= pace per router does not prevent the attack. Here is an example. Let's say = a router is attached to two links (A and B) while using the same IP address= . Let's say the attacker has recorded an Hello message the router just sent on link A. Whe= n the router sends this message its SN is higher than any other packet sent= on any other link by that router. The attacker would now be able successfu= lly replay the recorded Hello message on link B as long as it does so befor= e the router sends another OSPF message on link B. Such an attack will prob= ably bring down all adjacencies of the router on link B.

I t= hink it would be good to document this type of attacks as many network oper= ators configure the same key on different links. It would be good to bring = to their attention the consequences of such configurations. If you wish, I = can assist in writing this.

Gabi
<= div class=3D"" style=3D"">
=
From: Acee Lindem <acee.l= indem@ericsson.com>
<= span style=3D"font-weight: bold" class=3D"">To: Gabi Nakibly <gnakibly@yahoo.com>
Cc: Abh= ay Roy <akr@cisco.com>; OSPF List <ospf@ietf.org>
Sent: Monday, April 28, 2014 6:06 PM
Subject: Re: [OSPF] Working Group last Call on "Security Exte= nsion for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-securi= ty-extension-manual-keying-07

=0AHi Gabi, =0A
Thanks much for your review and comment.
=0A

=0A
=0A
On Apr 24, 2014, at 2:39 AM= , Gabi Nakibly <gnakibly@yahoo.com> wrote:
=0A
=0A
=0A
=0A
=0A
Hi,
=0A
I think this document is a significant step forward for the security = of OSPF. I do have one comment, though. It is concerned with the case in which the same key is configur= ed on different links. If such=0A a situation occurs then an attacker might= be able to record an OSPF message on one link and replay it on another. Th= is is particularly relevant for cases where one router uses the same source= address in multiple links (e.g. a virtual link and a physical link).=0A So= the attacker can record a packet sent by that router on one of the links a= nd replay it over the other as if it was sent by the router itself. This ma= y allow an attacker to cause an adjacency to be brought down.
= =0A
=0A
=0A
=0A

=0A
=0A
Note= that in section 2 we are recommending one sequence number space for the OS= PF router as opposed to one per interface. Hence, this would have to be a r= eplayed packet received from another router with the same source address si= nce the OSPF Router ID=0A in the OSPF header would be protected by the auth= entication hash. I would consider this to be a misconfiguration. =0A

=0A=
=0A
=0A
=0A
=0A
Moreover, a = recorded Hello message may be replayed on arbitrary links (even those that = do not share a router using the same source address). If I am not mistaken,= RFC2328 does not mandate to discard an Hello message having a source addre= ss=0A that is not part of the subnet of the interface on which the message = was received.
=0A
=0A
=0A
=0A

=0A
=0A
RFC 2328 does mandate source subnet checking on multi-access n= etworks but not P2P networks. On P2P networks, this could be a problem but = would require the attacker to have an active tap on both the P2P interface = and another interface using the same key.=0A  Again, this would have t= o be a replayed packet received from another router due to the OSPF router= =E2=80=99s use a single sequence number space. There really isn=E2=80=99t a= good solution for this problem on P2P links since the routers don=E2=80=99= t share any common identifier for=0A the P2P link. They have an ifIndex but= this is a locally unique interface identifier. We can document the problem= and recommend use of different keys if the possibility of active taps on P= 2P interfaces exists. 
=0A

=0A
=0A
Thanks,=
=0A
Acee
=0A

= =0A
=0A
=0A
=0A
Therefore, the rec= ipient of the replayed message would allocate a new neighbor entry, thus gi= ving rise to a DoS attack.
=0A

=0A
=0A
I know t= hat the OSPF standard allows to configure different keys for different link= s, nonetheless in most of the OSPF deployments I have seen the same key is = configured for all links in the AS (or area). I do not know if this is repr= esentative=0A of OSPF deployments worldwide, but it might be prudent to ana= lyse the security of the proposed extensions in the context of such cases a= s well.
=0A

=0A
=0A
Gabi
=0A=0A

=0A=
=0A
=0A
=0A
=0A
=0A
=0AFrom:= Abhay Roy <akr@cisco.com>
=0ATo: "ospf@= ietf.org" <ospf@ietf.org>=0A
=0A<= b class=3D"" style=3D"">Sent: Friday, April 11, 2014 9:30 AM
=0ASubject: [OSPF] Working Group last Call on "Security Extensio= n for OSPFv2 when using Manual Key Management" - draft-ietf-ospf-security-e= xtension-manual-keying-07
=0A
=0A

=0AAll,
=0A
=0AWe are starting a WG LC on the subject document. Doc= ument has been
=0Astable for a whi= le, and Manav was kind enough to present it one last
=0Atime in IETF89 (London). LC will end at 9am PST on 25= th April 2014.
=0A
=0APlease review the document and send any final co= mments prior to the LC
=0Adeadline= .
=0A
=0ARegards,
=0A-Abhay=0A
=0A_______________________________________________
=0AOSPF mailing list
=0A= OSPF@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo= /ospf
=0A
=0A
=0A
=0A=
=0A
=0A
=0A
=0A=0A
=0A_______________________________________________
=0AOSPF mailing list
=0AOSPF@ietf.org
=0Ahttps://www= .ietf.org/mailman/listinfo/ospf
=0A=
=0A
=0A
=0A
=0A
<= br class=3D"" style=3D"">
--235176295-301273287-1398777508=:12837--