From acee.lindem@ericsson.com Wed Feb 5 12:21:39 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 8B02A1A01C2 for ; Wed, 5 Feb 2014 12:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IYoSYsFfdgkO for ; Wed, 5 Feb 2014 12:21:37 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 62AB41A01C1 for ; Wed, 5 Feb 2014 12:21:37 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-39-52f29d50ebb9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B6.6B.11484.05D92F25; Wed, 5 Feb 2014 21:21:36 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 15:21:35 -0500 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPIq/dNVql86yF+EmUBLoKgXt2Rw== Date: Wed, 5 Feb 2014 20:21:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_CF17DD4E2696Baceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXSPn27A3E9BBqd7VS1a7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv3fk5kL7itVvPg5ibWB8ZZMFyMnh4SAicT7O82MELaYxIV7 69m6GLk4hASOMEocO7OaBcJZxigx6e8xdpAqNgEdieeP/jGD2CIC6hKrJ+9mBbGFBXwkpm+a zA4RD5ZYfWE+C4StJ7Hm2HM2EJtFQEWi7cp8MJtXwFTi38H7YPWMQJu/n1rDBGIzC4hL3Hoy nwniIgGJJXvOM0PYohIvH/8D2yUKNLN71nJWiLiSxKSl54BsDqDeKIk9G0QhxgtKnJz5hGUC o/AsJFNnIVTNQlIFUaIjsWD3JzYIW1ti2cLXzDD2mQOPmSBsa4kdm3pR1Cxg5FjFyFFanFqW m25kuIkRGCfHJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYxzts+Z/mrxjItnrpkttJRZvOUNy583Gl/nzu5PFxE8bjdld+fOmO8Gt/etUHt65sjL2Aff Vn9fPqFq9Y/wvx1Xrj45bLo6praBwZDll9yOJVFT3rEtcm87y2E37fg3B9vnJx/xSRZcXJZ/ 9vqMffsP3hEyWnCg2eKWfTn/h5XRbx/z5d1+uPDMoS4lluKMREMt5qLiRAB0ATXxYQIAAA== Subject: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 05 Feb 2014 20:21:39 -0000 --_000_CF17DD4E2696Baceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OSPFv3 autoconfiguration draft was cloned and presented in the ISIS WG = (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In the ISIS WG, t= here was a concern that the resolution of a duplicate system ID did not inc= lude the amount of time the router was operational when determining which r= outer would need to choose a new router ID. With additional complexity, we = could incorporate router uptime into the resolution process. One way to do = this would be to: 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include the = uptime in seconds. 2. Use the Router Uptime TLV as the primary determinant in deciding wh= ich router must choose a new OSPFv3 Router ID. Router uptimes less than 360= 0 (MaxAge) seconds apart are considered equal. 3. When an OSPFv3 Hello is received with a different link-local source= address but a different router-id, unicast the OSPFv3 AC-LSA to the neighb= or so that OSPFv3 duplicate router resolution can proceed as in the case wh= ere it is received through the normal flooding process. This is somewhat of= a hack as the we'd also need to accept OSPF Link State Updates from a neig= hbor that is not in Exchange State or greater. An alternative to #3 would be to use Link-Local Signaling (LLS) for signali= ng the contents of the OSPFv3 AC-LSA. However, you'd only want to send the = Router-Uptime and Router Hardware Fingerprint when a duplicate Router-ID is= detected. This requires implementing the resolution two ways but may be pr= eferable since it doesn't require violating the flooding rules. In any case, I'd like to get other opinions as to whether this problem is w= orth solving. Thanks, Acee --_000_CF17DD4E2696Baceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <128CB610576EBE4A936AB3FCBC730826@ericsson.com> Content-Transfer-Encoding: quoted-printable

The OSPFv3 autoconfiguration draft was cloned and presented in the ISI= S WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In the ISIS = WG, there was a concern that the resolution of a duplicate system ID did no= t include the amount of time the router was operational when determining which router would need to choose = a new router ID. With additional complexity, we could incorporate router up= time into the resolution process. One way to do this would be to:

     1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. I= t would include the uptime in seconds. 
     2. Use the Router Uptime TLV as the primary determ= inant in deciding which router must choose a new OSPFv3 Router ID. Router u= ptimes less than 3600 (MaxAge) seconds apart are considered equal. 
     3. When an OSPFv3 Hello is received with a differe= nt link-local source address but a different router-id, unicast the OSPFv3 = AC-LSA to the neighbor so that OSPFv3 duplicate router resolution can proce= ed as in the case where it is received through the normal flooding process. This is somewhat of a hack as the we'd also n= eed to accept OSPF Link State Updates from a neighbor that is not in Exchan= ge State or greater. 

An alternative to #3 would be to use Link-Local Signaling (LLS) for si= gnaling the contents of the OSPFv3 AC-LSA. However, you'd only want to send= the Router-Uptime and Router Hardware Fingerprint when a duplicate Router-= ID is detected. This requires implementing the resolution two ways but may be preferable since it doesn't require vio= lating the flooding rules. 

In any case, I'd like to get other opinions as to whether this problem= is worth solving. 

Thanks,
Acee 



--_000_CF17DD4E2696Baceelindemericssoncom_-- From curtis@ipv6.occnc.com Wed Feb 5 12:58:56 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 2A6F61A021F for ; Wed, 5 Feb 2014 12:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDznrSvKgdD6 for ; Wed, 5 Feb 2014 12:58:54 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4089B1A0214 for ; Wed, 5 Feb 2014 12:58:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s15KwoGH012796; Wed, 5 Feb 2014 15:58:50 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Wed, 05 Feb 2014 20:21:34 +0000." Date: Wed, 05 Feb 2014 15:58:50 -0500 Cc: OSPF - OSPF WG List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:58:56 -0000 In message Acee Lindem writes: > The OSPFv3 autoconfiguration draft was cloned and presented in the > ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In > the ISIS WG, there was a concern that the resolution of a duplicate > system ID did not include the amount of time the router was > operational when determining which router would need to choose a new > router ID. With additional complexity, we could incorporate router > uptime into the resolution process. One way to do this would be to: > > 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include > the uptime in seconds. > > 2. Use the Router Uptime TLV as the primary determinant in > deciding which router must choose a new OSPFv3 Router > ID. Router uptimes less than 3600 (MaxAge) seconds apart are > considered equal. > > 3. When an OSPFv3 Hello is received with a different link-local > source address but a different router-id, unicast the OSPFv3 > AC-LSA to the neighbor so that OSPFv3 duplicate router > resolution can proceed as in the case where it is received > through the normal flooding process. This is somewhat of a > hack as the we'd also need to accept OSPF Link State Updates > from a neighbor that is not in Exchange State or greater. > > An alternative to #3 would be to use Link-Local Signaling (LLS) for > signaling the contents of the OSPFv3 AC-LSA. However, you'd only want > to send the Router-Uptime and Router Hardware Fingerprint when a > duplicate Router-ID is detected. This requires implementing the > resolution two ways but may be preferable since it doesn't require > violating the flooding rules. > > In any case, I'd like to get other opinions as to whether this problem > is worth solving. > > Thanks, > Acee Acee, If the basis for router-id on boot up results in a fixed value, and if a duplicate will occur on a give network, then which of two duplicate routers gets that value may change after one of them reboots. If uptime is not considered, it will never change as long as one router stays up at any given time. We are talking about a very low probability event (a duplicate) except if this is a DoS attack and then either using or not using uptime won't matter since the attacker will claim an impossibly long uptime. Curtis From acee.lindem@ericsson.com Thu Feb 6 17:11:56 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 5B2091A0585 for ; Thu, 6 Feb 2014 17:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfdYoPW0Ko7X for ; Thu, 6 Feb 2014 17:11:54 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1FD1A0584 for ; Thu, 6 Feb 2014 17:11:54 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-44-52f432d47dcd Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DB.53.12743.4D234F25; Fri, 7 Feb 2014 02:11:48 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 20:11:50 -0500 From: Acee Lindem To: Curtis Villamizar Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPIrUalidEs1+lNkOnzIePWuX0dJqpUY0A Date: Fri, 7 Feb 2014 01:11:49 +0000 Message-ID: <7113CE23-C2B0-40C7-9968-22C224571B3B@ericsson.com> References: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.com> In-Reply-To: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPoO4Voy9BBgfnW1tMnnWGzaLl3j12 ByaPJUt+Mnksu3+RLYApissmJTUnsyy1SN8ugSvjb9sLloIvohVXfu9jbWCcJtjFyMkhIWAi cbF5ASuELSZx4d56ti5GLg4hgSOMEjtvfGUHSQgJLGOUeLmzGMRmE9CReP7oHzOILSKgK9F3 4zIbiM0sICvxbFsTWFxYIFJi7s1NQL0cQDVREj82CUOUG0lc+/qbEcRmEVCRONMynQXE5hWw l/hyZwIbxConiaNPjoHVcAo4S2yZtQ3sNkag276fWsMEsUpc4taT+UwQNwtILNlznhnCFpV4 +fgf1C9KEpOWnmOFqNeRWLD7E9SZ1hIb3hyGsrUlli18zQxxg6DEyZlPWCYwis9CsmIWkvZZ SNpnIWmfhaR9ASPrKkaO0uLUstx0I4NNjMCYOibBpruDcc9Ly0OM0hwsSuK8X946BwkJpCeW pGanphakFsUXleakFh9iZOLglGpgXK9jM/VRCMdSQ2N2r6cHi7nlQhTe/a+e31swaacGT73U CjFb42D5NONtzC+PL7hxgt9Exn8l2wS/uRdCzRLbdKaEPL9VHt8gvnV5YIiqzffyXJlWzZAr sys+lcT8fnCh0zXkcdGX9BUxujcTYmoWZ5e/mtXvbhLl4mq6XefTRBaRnVsS5uorsRRnJBpq MRcVJwIA58E0VHcCAAA= Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 01:11:56 -0000 Hi Curtis,=20 I agree and believe the significance of this use case where a new router is= inserted into an auto-configured domain has been greater exaggerated. Thanks, Acee On Feb 5, 2014, at 3:58 PM, Curtis Villamizar wrote= : >=20 > In message > Acee Lindem writes: >=20 >> The OSPFv3 autoconfiguration draft was cloned and presented in the >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In >> the ISIS WG, there was a concern that the resolution of a duplicate >> system ID did not include the amount of time the router was >> operational when determining which router would need to choose a new >> router ID. With additional complexity, we could incorporate router >> uptime into the resolution process. One way to do this would be to: >>=20 >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include >> the uptime in seconds. >>=20 >> 2. Use the Router Uptime TLV as the primary determinant in >> deciding which router must choose a new OSPFv3 Router >> ID. Router uptimes less than 3600 (MaxAge) seconds apart are >> considered equal. >>=20 >> 3. When an OSPFv3 Hello is received with a different link-local >> source address but a different router-id, unicast the OSPFv3 >> AC-LSA to the neighbor so that OSPFv3 duplicate router >> resolution can proceed as in the case where it is received >> through the normal flooding process. This is somewhat of a >> hack as the we'd also need to accept OSPF Link State Updates >> from a neighbor that is not in Exchange State or greater. >>=20 >> An alternative to #3 would be to use Link-Local Signaling (LLS) for >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want >> to send the Router-Uptime and Router Hardware Fingerprint when a >> duplicate Router-ID is detected. This requires implementing the >> resolution two ways but may be preferable since it doesn't require >> violating the flooding rules. >>=20 >> In any case, I'd like to get other opinions as to whether this problem >> is worth solving. >>=20 >> Thanks, >> Acee >=20 >=20 > Acee, >=20 > If the basis for router-id on boot up results in a fixed value, and if > a duplicate will occur on a give network, then which of two duplicate > routers gets that value may change after one of them reboots. If > uptime is not considered, it will never change as long as one router > stays up at any given time. >=20 > We are talking about a very low probability event (a duplicate) except > if this is a DoS attack and then either using or not using uptime > won't matter since the attacker will claim an impossibly long uptime. >=20 > Curtis From ginsberg@cisco.com Fri Feb 7 00:31: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 915F91A05D1 for ; Fri, 7 Feb 2014 00:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 3rMl47fd6hx6 for ; Fri, 7 Feb 2014 00:31:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7EC1A0058 for ; Fri, 7 Feb 2014 00:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5031; q=dns/txt; s=iport; t=1391761873; x=1392971473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WHcB6zNumANoFn4XaWCAoKeueuUpiX3OmevcdagBJWM=; b=ljNjnS9ABGn6hGV7WCI4Ye6qWJI2SRVeVe0iPJ70KgeSFx2SwD2wpcKW dyiYuUvAAuBFz/paXPI3JvUObklH4XWBWegCvqfGJI2orJRFVXzi2WBZJ l30ARdIlnYASFQjtVvk1TrSjPq3oDVlehMYUjdt5dPL4BmTH8EYiolhjf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKaY9FKtJXHA/2dsb2JhbABTBoMMOFe+f4EKFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIAYd8Dc0LF446EgYrBwaDHoEUBKpMgy2CKg X-IronPort-AV: E=Sophos;i="4.95,799,1384300800"; d="scan'208";a="302512231" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 07 Feb 2014 08:31:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s178VCt5010152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 08:31:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 02:31:12 -0600 From: "Les Ginsberg (ginsberg)" To: Acee Lindem , Curtis Villamizar Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPI6Gc/pYRbYVsxUaPEbmLjnjkwpqpcLjw Date: Fri, 7 Feb 2014 08:31:11 +0000 Message-ID: References: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.com> <7113CE23-C2B0-40C7-9968-22C224571B3B@ericsson.com> In-Reply-To: <7113CE23-C2B0-40C7-9968-22C224571B3B@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 08:31:21 -0000 So, I am one person who raised this concern to Acee - but the proposal outl= ined by Acee is not what I had in mind. There is no need to use "uptime" or= to invent some unusual exchange of LSAs prior to Exchange state. Also, in regards to Curtis's comment - it is not DOS attacks that I am tryi= ng to mitigate here. As he says if an attacker is in your network and able = to originate credible packets no strategy is safe. The motivating use case is to minimize disruption of a stable network when = a new router is added or an existing router is replaced/rebooted. In other = words non-disruptive handling of the common maintenance/upgrade scenarios. What I have in mind is this: 1)A router needs a way to advertise that it has been up and running for a m= inimum length of time - for the sake of discussion let's say 20 minutes. Ro= uters then fall into two categories: o Old routers (up >=3D minimum time) o New routers (up < minimum time) 2)When a duplicate router-id is detected, the first tie breaker is between = old routers and new routers. The old router gets to keep its router-id and = the new router picks a new router-id. If both routers are "new" or both routers are "old" then we revert to the e= xisting tie breakers defined in the document (link local address for direct= ly connected routers and fingerprint info for non-neighbors). 3)Advertisement of the "old/new" state requires a single bit - but it has t= o be available both in hellos and the new AC-LSA. Adding it to the AC-LSA i= s easy to do. For hellos, there are two possibilities: o Use one of the Options Bits o Use LLS Be interested in how folks feel about this. Les > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > Sent: Thursday, February 06, 2014 5:12 PM > To: Curtis Villamizar > Cc: OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 > Hi Curtis, > I agree and believe the significance of this use case where a new router = is > inserted into an auto-configured domain has been greater exaggerated. > Thanks, > Acee > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar wro= te: >=20 > > > > In message > > Acee Lindem writes: > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In > >> the ISIS WG, there was a concern that the resolution of a duplicate > >> system ID did not include the amount of time the router was > >> operational when determining which router would need to choose a new > >> router ID. With additional complexity, we could incorporate router > >> uptime into the resolution process. One way to do this would be to: > >> > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include > >> the uptime in seconds. > >> > >> 2. Use the Router Uptime TLV as the primary determinant in > >> deciding which router must choose a new OSPFv3 Router > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart are > >> considered equal. > >> > >> 3. When an OSPFv3 Hello is received with a different link-local > >> source address but a different router-id, unicast the OSPFv3 > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > >> resolution can proceed as in the case where it is received > >> through the normal flooding process. This is somewhat of a > >> hack as the we'd also need to accept OSPF Link State Updates > >> from a neighbor that is not in Exchange State or greater. > >> > >> An alternative to #3 would be to use Link-Local Signaling (LLS) for > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want > >> to send the Router-Uptime and Router Hardware Fingerprint when a > >> duplicate Router-ID is detected. This requires implementing the > >> resolution two ways but may be preferable since it doesn't require > >> violating the flooding rules. > >> > >> In any case, I'd like to get other opinions as to whether this problem > >> is worth solving. > >> > >> Thanks, > >> Acee > > > > > > Acee, > > > > If the basis for router-id on boot up results in a fixed value, and if > > a duplicate will occur on a give network, then which of two duplicate > > routers gets that value may change after one of them reboots. If > > uptime is not considered, it will never change as long as one router > > stays up at any given time. > > > > We are talking about a very low probability event (a duplicate) except > > if this is a DoS attack and then either using or not using uptime > > won't matter since the attacker will claim an impossibly long uptime. > > > > Curtis >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From ginsberg@cisco.com Fri Feb 7 00:58:39 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 25DC51A05DA for ; Fri, 7 Feb 2014 00:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 eiz_6G-2KZOd for ; Fri, 7 Feb 2014 00:58:37 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id F0FED1A05C7 for ; Fri, 7 Feb 2014 00:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6200; q=dns/txt; s=iport; t=1391763515; x=1392973115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gz7GC0jvAv6WdySHlGl9o3uXnXnGWa2tMOsYY0cxoDI=; b=K7s5TgkwLnoun6it2EK6PTkqxiEiFDc3j4ZeEJpINYI15RJeWfbIF8dj i6xn/119GzWTQrCHfyMsQ4zp3szI1bEdilGEAsT9MtzfiIjtausngp0aY 7ggHeqwi+mst3/n3KqSWEFab0WMr1VuwIbExpSpw4Ufs3XQYCD0rRDsqS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADOf9FKtJXG8/2dsb2JhbABTBoMMOFe+f4EKFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIAYd8Dc0VF446EgYrBwaDHoEUBKpMgy2CKg X-IronPort-AV: E=Sophos;i="4.95,799,1384300800"; d="scan'208";a="18686561" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 07 Feb 2014 08:58:35 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s178wZw0011286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 08:58:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 02:58:35 -0600 From: "Les Ginsberg (ginsberg)" To: Acee Lindem , Curtis Villamizar Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPI6Gc/pYRbYVsxUaPEbmLjnjkwpqpcLjwgAAMcxA= Date: Fri, 7 Feb 2014 08:58:34 +0000 Message-ID: References: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.com> <7113CE23-C2B0-40C7-9968-22C224571B3B@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 08:58:39 -0000 One other thing I forgot to mention. Using the mechanisms I define below, a modestly clever implementation could= implement a startup mode where it does not advertise any reachability unti= l it has formed at least one neighbor and acquired the full LSA database. A= t this point it should know whether it has a duplicate router-id or not and= if so it can assign itself a new router-id without affecting forwarding be= havior at all. Les > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Friday, February 07, 2014 12:31 AM > To: Acee Lindem; Curtis Villamizar > Cc: OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 > So, I am one person who raised this concern to Acee - but the proposal > outlined by Acee is not what I had in mind. There is no need to use "upti= me" > or to invent some unusual exchange of LSAs prior to Exchange state. >=20 > Also, in regards to Curtis's comment - it is not DOS attacks that I am tr= ying > to mitigate here. As he says if an attacker is in your network and able t= o > originate credible packets no strategy is safe. >=20 > The motivating use case is to minimize disruption of a stable network whe= n a > new router is added or an existing router is replaced/rebooted. In other > words non-disruptive handling of the common maintenance/upgrade scenarios= . >=20 > What I have in mind is this: >=20 > 1)A router needs a way to advertise that it has been up and running for a > minimum length of time - for the sake of discussion let's say 20 minutes. > Routers then fall into two categories: >=20 > o Old routers (up >=3D minimum time) > o New routers (up < minimum time) >=20 > 2)When a duplicate router-id is detected, the first tie breaker is betwee= n > old routers and new routers. The old router gets to keep its router-id an= d > the new router picks a new router-id. > If both routers are "new" or both routers are "old" then we revert to the > existing tie breakers defined in the document (link local address for > directly connected routers and fingerprint info for non-neighbors). >=20 > 3)Advertisement of the "old/new" state requires a single bit - but it has= to > be available both in hellos and the new AC-LSA. Adding it to the AC-LSA i= s > easy to do. For hellos, there are two possibilities: >=20 > o Use one of the Options Bits > o Use LLS >=20 > Be interested in how folks feel about this. >=20 > Les >=20 >=20 > > -----Original Message----- > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > > Sent: Thursday, February 06, 2014 5:12 PM > > To: Curtis Villamizar > > Cc: OSPF List > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > autoconfig-05.txt > > > > Hi Curtis, > > I agree and believe the significance of this use case where a new route= r is > > inserted into an auto-configured domain has been greater exaggerated. > > Thanks, > > Acee > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > wrote: > > > > > > > > In message > > > Acee Lindem writes: > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In > > >> the ISIS WG, there was a concern that the resolution of a duplicate > > >> system ID did not include the amount of time the router was > > >> operational when determining which router would need to choose a new > > >> router ID. With additional complexity, we could incorporate router > > >> uptime into the resolution process. One way to do this would be to: > > >> > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would includ= e > > >> the uptime in seconds. > > >> > > >> 2. Use the Router Uptime TLV as the primary determinant in > > >> deciding which router must choose a new OSPFv3 Router > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart are > > >> considered equal. > > >> > > >> 3. When an OSPFv3 Hello is received with a different link-local > > >> source address but a different router-id, unicast the OSPFv3 > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > >> resolution can proceed as in the case where it is received > > >> through the normal flooding process. This is somewhat of a > > >> hack as the we'd also need to accept OSPF Link State Updates > > >> from a neighbor that is not in Exchange State or greater. > > >> > > >> An alternative to #3 would be to use Link-Local Signaling (LLS) for > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only wan= t > > >> to send the Router-Uptime and Router Hardware Fingerprint when a > > >> duplicate Router-ID is detected. This requires implementing the > > >> resolution two ways but may be preferable since it doesn't require > > >> violating the flooding rules. > > >> > > >> In any case, I'd like to get other opinions as to whether this probl= em > > >> is worth solving. > > >> > > >> Thanks, > > >> Acee > > > > > > > > > Acee, > > > > > > If the basis for router-id on boot up results in a fixed value, and i= f > > > a duplicate will occur on a give network, then which of two duplicate > > > routers gets that value may change after one of them reboots. If > > > uptime is not considered, it will never change as long as one router > > > stays up at any given time. > > > > > > We are talking about a very low probability event (a duplicate) excep= t > > > if this is a DoS attack and then either using or not using uptime > > > won't matter since the attacker will claim an impossibly long uptime. > > > > > > Curtis > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From asmirnov@cisco.com Fri Feb 7 05:46: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 F0FE11A0103 for ; Fri, 7 Feb 2014 05:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 yjehJVJvZIhn for ; Fri, 7 Feb 2014 05:46:39 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id DA0B91A00F5 for ; Fri, 7 Feb 2014 05:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2640; q=dns/txt; s=iport; t=1391780799; x=1392990399; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Kiz5WZwD3tNVPQSQWA3dFzGUG2mjeXTKiK77a2l63Yg=; b=iyGOFuWESrrlLiSqScvJFHVTFaSbgSFZfZUBGr4glVzxYsITmprcVNXn EnLcXFvHdNTBE7RBcZrr9qssvW1ppsDl9kNqos5Rawjjx4S3kpOtgzwXJ i7gaosHBDu0Vs2qzFtawy7TS20OmA+KWvMFj7qRQVG/tPpmF+vXhjDKGR E=; X-IronPort-AV: E=Sophos;i="4.95,800,1384300800"; d="scan'208";a="4775121" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 07 Feb 2014 13:46:38 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s17DkbeF023631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Feb 2014 13:46:37 GMT Message-ID: <52F4E3BD.6030800@cisco.com> Date: Fri, 07 Feb 2014 14:46:37 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" , Acee Lindem , Curtis Villamizar References: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.com> <7113CE23-C2B0-40C7-9968-22C224571B3B@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 13:46:41 -0000 Hi Les, if I understand correctly, all this is in addition to RID duplication and resolution mechanisms, i.e. you do not expect that doing *only* this will render RID duplication resolution unnecessary, right? If RID selection algorithm is good (i.e. statistical spread of selected RIDs is even over the whole space) then quick math shows that a device joining home network with, say, 1000 already connected devices has less than 1 chance in billion to generate conflicting RID. To me this risk looks not worth solving. The big question of course is in statistical quality of RID selection algorithm implementations. Since there will be many different implementations some of them are going to be subpar. And bad implementation may make probability of RID conflict close to 1. Is this what you are worried about? Anton On 02/07/2014 09:31 AM, Les Ginsberg (ginsberg) wrote: > So, I am one person who raised this concern to Acee - but the proposal outlined by Acee is not what I had in mind. There is no need to use "uptime" or to invent some unusual exchange of LSAs prior to Exchange state. > > Also, in regards to Curtis's comment - it is not DOS attacks that I am trying to mitigate here. As he says if an attacker is in your network and able to originate credible packets no strategy is safe. > > The motivating use case is to minimize disruption of a stable network when a new router is added or an existing router is replaced/rebooted. In other words non-disruptive handling of the common maintenance/upgrade scenarios. > > What I have in mind is this: > > 1)A router needs a way to advertise that it has been up and running for a minimum length of time - for the sake of discussion let's say 20 minutes. Routers then fall into two categories: > > o Old routers (up >= minimum time) > o New routers (up < minimum time) > > 2)When a duplicate router-id is detected, the first tie breaker is between old routers and new routers. The old router gets to keep its router-id and the new router picks a new router-id. > If both routers are "new" or both routers are "old" then we revert to the existing tie breakers defined in the document (link local address for directly connected routers and fingerprint info for non-neighbors). > > 3)Advertisement of the "old/new" state requires a single bit - but it has to be available both in hellos and the new AC-LSA. Adding it to the AC-LSA is easy to do. For hellos, there are two possibilities: > > o Use one of the Options Bits > o Use LLS > > Be interested in how folks feel about this. > > Les > From ing-wher.chen@ericsson.com Fri Feb 7 06:50:50 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 314B81A1F66 for ; Fri, 7 Feb 2014 06:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCszvKKpDaHL for ; Fri, 7 Feb 2014 06:50:48 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 803821A1F65 for ; Fri, 7 Feb 2014 06:50:48 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-ef-52f4f2c497ae Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 36.01.12743.4C2F4F25; Fri, 7 Feb 2014 15:50:45 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 09:50:47 -0500 From: Ing-Wher Chen To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-chen-ospf-transition-to-ospfv3-00.txt Thread-Index: AQHPG0oM8JCQiJNLekaNLSSqLgcyE5qp8OEA Date: Fri, 7 Feb 2014 14:50:46 +0000 Message-ID: References: <20140127102503.24239.31809.idtracker@ietfa.amsl.com> In-Reply-To: <20140127102503.24239.31809.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyuXSPt+7RT1+CDP7f5rNouXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGbd3L2EtOCRU8fHOAqYGxhahLkZODgkBE4nrl5qYIGwxiQv3 1rN1MXJxCAkcYZQ4f3wyK4SzjFFiyd5/rCBVbAIGEhs+bgHrEBFQltiyt58NxBYWCJd41vWC DSIeIbFjfgtQPQeQbSRx/WAUSJhFQEXi4pV5YK28At4Sr/6sAhspJOAoMXP6UWYQm1PASeLV gVNgNiPQQd9PrQGrZxYQl7j1ZD7UoQISS/acZ4awRSVePoY4TUJAUWJf/3R2kLXMApoS63fp Q7QqSkzpfsgOsVZQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGLkKC1OLctNNzLYxAgM+mMS bLo7GPe8tDzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRgFZxuJbNT1V i5h4VDo6zXiVj7+8O0NamdXl6c2pk68ubdh/nvHcWYkFCnPEs1omaHC+vpuX9eO/z+Kc19+P MvIv7jlxfs/H0AsLH0ofEA20M3TxlLiQXFVyZX3ZJgPl+seNlw+oPzKcrZYhUPncueVOVu5G j2knjqyTTGDtv8R2cXPql2mL5ZVYijMSDbWYi4oTAcbTI9xIAgAA Subject: [OSPF] FW: New Version Notification for draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:50:50 -0000 SGVsbG8sDQoNClRoZSBpbmZvcm1hdGlvbiBkcmFmdCBiZWxvdyBkb2N1bWVudHMgaG93IHRvIGVu Y2Fwc3VsYXRlIE9TUEZ2MyBwYWNrZXRzIGluIElQdjQNCmluIGFuIGVmZm9ydCB0byB0cmFuc2l0 aW9uIHRvIE9TUEZ2MyBhbmQgSVB2Ni4NCg0KVGhhbmtzLA0KSGVsZW4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEphbnVhcnkgMjcsIDIwMTQg MjoyNSBBTQ0KVG86IEluZy1XaGVyIENoZW47IEluZy1XaGVyIENoZW47IEFjZWUgTGluZGVtOyBB Y2VlIExpbmRlbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1j aGVuLW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWNoZW4tb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSS4gQ2hlbiBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1jaGVuLW9zcGYtdHJhbnNpdGlvbi10by1v c3BmdjMNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlPU1BGdjMgb3ZlciBJUHY0IGZvciBJUHY2IFRy YW5zaXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMDEtMjYNCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVuLW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtY2hlbi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2 My0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkZWZpbmVzIGEgbWVjaGFuaXNtIHRv IHVzZSBJUHY0IHRvIHRyYW5zcG9ydCBPU1BGdjMNCiAgIHBhY2tldHMsIGluIG9yZGVyIHRvIGZh Y2lsaXRhdGUgdHJhbnNpdGlvbiBmcm9tIElQdjQtb25seSB0byBJUHY2IGFuZA0KICAgZHVhbC1z dGFjayB3aXRoaW4gYSByb3V0aW5nIGRvbWFpbi4gIFVzaW5nIE9TUEZ2MyBvdmVyIElQdjQgd2l0 aCB0aGUNCiAgIGV4aXN0aW5nIE9TUEZ2MyBBZGRyZXNzIEZhbWlseSBleHRlbnNpb24gc2ltcGxp ZmllcyB0cmFuc2l0aW9uIGZyb20NCiAgIGFuIE9TRlB2MiBJUHY0LW9ubHkgcm91dGluZyBkb21h aW4gdG8gYW4gT1NQRnYzIGR1YWwtc3RhY2sgcm91dGluZw0KICAgZG9tYWluLCBhbmQgbGF0ZXIg cG9zc2libHkgdG8gYW4gSVB2Ni1vbmx5IHJvdXRpbmcgZG9tYWluLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From ginsberg@cisco.com Fri Feb 7 07:52: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 9F1181AC7EF for ; Fri, 7 Feb 2014 07:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 RzH6YyKCWEfs for ; Fri, 7 Feb 2014 07:52:20 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id CFA171AC497 for ; Fri, 7 Feb 2014 07:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4207; q=dns/txt; s=iport; t=1391788340; x=1392997940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PDC/FP/VgwV9aDKnSKMaIh+g9lHdG4yDssX8Vf7flJg=; b=L5uGmSFiGs+nkHzwW1uOW28Rrk4MAtiOLTQku5fv1J9V4IUo2N2yZ1rM kUPhGCq/VyRH7qpqfgjuXgBZyDIvlxijg14iLhX6RsHz6S2ri7pIv/SOR G/38b9gzc+nMpMi8/+popkWajIvtREIt5AiCqisCqlka+DoOSr8c0g2Za 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAD0A9VKtJV2Y/2dsb2JhbABTBoMMgQ+7X4MJgQ4WdIIlAQEBBDo/DAQCAQgRBAEBAQoUEDIdCAIEAQ0Nh33MUxeOOhIxBwaDHoEUAQOqTIMtgio X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="18751183" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 07 Feb 2014 15:52:19 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s17FqJaE004974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 15:52:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 09:52:19 -0600 From: "Les Ginsberg (ginsberg)" To: "Anton Smirnov (asmirnov)" , Acee Lindem , Curtis Villamizar Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPI6Gc/pYRbYVsxUaPEbmLjnjkwpqpcLjwgADCpID//7poYA== Date: Fri, 7 Feb 2014 15:52:19 +0000 Message-ID: References: <201402052058.s15KwoGH012796@maildrop2.v6ds.occnc.com> <7113CE23-C2B0-40C7-9968-22C224571B3B@ericsson.com> <52F4E3BD.6030800@cisco.com> In-Reply-To: <52F4E3BD.6030800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 15:52:21 -0000 Anton - Everyone agrees that router-id duplication is a low probability event if (a= s you say) implementations follow the rules about selecting a router id. Ne= vertheless the draft - quite correctly IMO - defines how to resolve duplica= tion if it occurs because it is still possible. My proposal is a simple ext= ension to the existing tie breaker rules to lessen the probability that the= network need be disrupted in the event router-id duplication occurs during= normal maintenance/upgrade procedures. I have proposed no changes to the router-id selection logic and I was not m= otivated by the possibility of poor implementations - though I think that p= oint only adds to the value of my proposal. (Of course one may rightly wond= er if an implementation doesn't correctly implement router-id selection whe= ther it can be expected to correctly implement tie breaking - but I think w= e are wandering into areas we have no control over. Buggy implementations c= an disrupt a network and we hope the marketplace eventually resolves that i= ssue by not buying such products.) Les > -----Original Message----- > From: Anton Smirnov (asmirnov) > Sent: Friday, February 07, 2014 5:47 AM > To: Les Ginsberg (ginsberg); Acee Lindem; Curtis Villamizar > Cc: OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 > Hi Les, > if I understand correctly, all this is in addition to RID > duplication and resolution mechanisms, i.e. you do not expect that doing > *only* this will render RID duplication resolution unnecessary, right? >=20 > If RID selection algorithm is good (i.e. statistical spread of > selected RIDs is even over the whole space) then quick math shows that a > device joining home network with, say, 1000 already connected devices > has less than 1 chance in billion to generate conflicting RID. To me > this risk looks not worth solving. > The big question of course is in statistical quality of RID > selection algorithm implementations. Since there will be many different > implementations some of them are going to be subpar. And bad > implementation may make probability of RID conflict close to 1. > Is this what you are worried about? >=20 > Anton >=20 >=20 > On 02/07/2014 09:31 AM, Les Ginsberg (ginsberg) wrote: > > So, I am one person who raised this concern to Acee - but the proposal > outlined by Acee is not what I had in mind. There is no need to use "upti= me" > or to invent some unusual exchange of LSAs prior to Exchange state. > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I am > trying to mitigate here. As he says if an attacker is in your network and > able to originate credible packets no strategy is safe. > > > > The motivating use case is to minimize disruption of a stable network w= hen > a new router is added or an existing router is replaced/rebooted. In othe= r > words non-disruptive handling of the common maintenance/upgrade scenarios= . > > > > What I have in mind is this: > > > > 1)A router needs a way to advertise that it has been up and running for= a > minimum length of time - for the sake of discussion let's say 20 minutes. > Routers then fall into two categories: > > > > o Old routers (up >=3D minimum time) > > o New routers (up < minimum time) > > > > 2)When a duplicate router-id is detected, the first tie breaker is betw= een > old routers and new routers. The old router gets to keep its router-id an= d > the new router picks a new router-id. > > If both routers are "new" or both routers are "old" then we revert to t= he > existing tie breakers defined in the document (link local address for > directly connected routers and fingerprint info for non-neighbors). > > > > 3)Advertisement of the "old/new" state requires a single bit - but it h= as > to be available both in hellos and the new AC-LSA. Adding it to the AC-LS= A is > easy to do. For hellos, there are two possibilities: > > > > o Use one of the Options Bits > > o Use LLS > > > > Be interested in how folks feel about this. > > > > Les > > From asmirnov@cisco.com Fri Feb 7 09:17: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 B62AF1ACCE3 for ; Fri, 7 Feb 2014 09:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 NxIjSrS0zS3I for ; Fri, 7 Feb 2014 09:17:39 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id CC67E1AC7F2 for ; Fri, 7 Feb 2014 09:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1391793457; x=1393003057; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4peW4+jGu6Exa2eqRzFGrjpldCoaZ+hpWxUSPsi8dVY=; b=j/vFfgGrov8GkCUbEk9YwTNmzSYriVXeS/2m0fNUKg5U1uwDXdnhdSSA V5w41odpK3wdHRPZU+b5FTgx3tOJ1saD/C0+VdxaFFRMkVRY585PrVr8L LW+gqw0VHSK6tXvYdHspkh3W//rPjj8tnUbyOyZcvNFfA+ZZzwwUJ4uZk I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADAU9VKQ/khN/2dsb2JhbABZgww4vz+BDhZ0giUBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGAQwGAgEBBYd8DcwJF48EhDgEmCuSIYMuOw X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="4113503" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 07 Feb 2014 17:17:35 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s17HHZPG032410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Feb 2014 17:17:35 GMT Message-ID: <52F5152F.2000009@cisco.com> Date: Fri, 07 Feb 2014 18:17:35 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Acee Lindem , OSPF - OSPF WG List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 17:17:42 -0000 Hi Acee, weighing probability of RID conflict against complexity of the proposed method I agree it does not look attractive. I think RID conflict avoidance can be made optional. What if feedback to change RID is given to device before it has joined the OSPF domain? I.e. before router established at least one FULL adjacency it advertises in its Hellos "I am new". Neighboring devices weigh if new RID looks conflicting or not and advise back to the new device via unicast Hellos. Anton On 02/05/2014 09:21 PM, Acee Lindem wrote: > > The OSPFv3 autoconfiguration draft was cloned and presented in the ISIS > WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In the ISIS > WG, there was a concern that the resolution of a duplicate system ID did > not include the amount of time the router was operational when > determining which router would need to choose a new router ID. With > additional complexity, we could incorporate router uptime into the > resolution process. One way to do this would be to: > > 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include > the uptime in seconds. > 2. Use the Router Uptime TLV as the primary determinant in > deciding which router must choose a new OSPFv3 Router ID. Router uptimes > less than 3600 (MaxAge) seconds apart are considered equal. > 3. When an OSPFv3 Hello is received with a different link-local > source address but a different router-id, unicast the OSPFv3 AC-LSA to > the neighbor so that OSPFv3 duplicate router resolution can proceed as > in the case where it is received through the normal flooding process. > This is somewhat of a hack as the we'd also need to accept OSPF Link > State Updates from a neighbor that is not in Exchange State or greater. > > An alternative to #3 would be to use Link-Local Signaling (LLS) for > signaling the contents of the OSPFv3 AC-LSA. However, you'd only want to > send the Router-Uptime and Router Hardware Fingerprint when a duplicate > Router-ID is detected. This requires implementing the resolution two > ways but may be preferable since it doesn't require violating the > flooding rules. > > In any case, I'd like to get other opinions as to whether this problem > is worth solving. > > Thanks, > Acee > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From curtis@ipv6.occnc.com Fri Feb 7 09:22:35 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 36E941ACC89 for ; Fri, 7 Feb 2014 09:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLWCq_O3jmdg for ; Fri, 7 Feb 2014 09:22:31 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id D4E081A0416 for ; Fri, 7 Feb 2014 09:22:30 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s17HMMe5063042; Fri, 7 Feb 2014 12:22:22 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402071722.s17HMMe5063042@maildrop2.v6ds.occnc.com> To: "Les Ginsberg (ginsberg)" From: Curtis Villamizar In-reply-to: Your message of "Fri, 07 Feb 2014 08:31:11 +0000." Date: Fri, 07 Feb 2014 12:22:22 -0500 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:22:35 -0000 In message "Les Ginsberg (ginsberg)" writes: > > So, I am one person who raised this concern to Acee - but the proposal > outlined by Acee is not what I had in mind. There is no need to use > "uptime" or to invent some unusual exchange of LSAs prior to Exchange > state. > > Also, in regards to Curtis's comment - it is not DOS attacks that I am > trying to mitigate here. As he says if an attacker is in your network > and able to originate credible packets no strategy is safe. > > The motivating use case is to minimize disruption of a stable network > when a new router is added or an existing router is > replaced/rebooted. In other words non-disruptive handling of the > common maintenance/upgrade scenarios. > > What I have in mind is this: > > 1) A router needs a way to advertise that it has been up and running > for a minimum length of time - for the sake of discussion let's say > 20 minutes. Routers then fall into two categories: > > o Old routers (up >= minimum time) > o New routers (up < minimum time) > > 2) When a duplicate router-id is detected, the first tie breaker is > between old routers and new routers. The old router gets to keep > its router-id and the new router picks a new router-id. If both > routers are "new" or both routers are "old" then we revert to the > existing tie breakers defined in the document (link local address > for directly connected routers and fingerprint info for > non-neighbors). > > 3) Advertisement of the "old/new" state requires a single bit - but it > has to be available both in hellos and the new AC-LSA. Adding it to > the AC-LSA is easy to do. For hellos, there are two possibilities: > > o Use one of the Options Bits > o Use LLS > > Be interested in how folks feel about this. > > Les Les, Excluding DoS attack, we are talking about a one in 4 billion case (for any two routers, so with 400 routers, still well under one in 1M) where two routers hash a MAC address or pick a one time random number from out of nowhere and end up with the same number. If that does happen (and one in 1M is certainly possible), then it would be nice if the routers always ended up with the same router-id. This could be accomplished by some fixed method such as hashing a constant with the first choice or router-id or using the router-id as a seed for the random number generator (which will pick the same sequence of random numbers each time). If this is done, then a conflict would always produce the same set of next picks. The set of routers in a given network would always end up with the same router-ids once they all came up and if only one went down at a time then it would always end up with the same router-id when it came up. Zero conf was mainly intended for unmanaged networks (motivated by work in the homenet WG). In these small unmanaged networks it doesn't matter which router gets what router-id as long as they end up unique and convergence is in a reasonable time relative to keeping eyeballs happy. It could be applied to enterprise or providers but in either case having the routers end up with the same router-ids would make for easier management. For your scenario to matter at all with current rules, both routers in the conflict would have to go down. If only the one that is preferred goes down, the other is not going to change its router-id as a result so when it comes up it gets its first pick with no conflict. If the one that was not preferred goes down, it comes up, sees a conflict and takes its second pick (loses the conflict every time). It is only if they both go down and the one that normally loses the conflict comes up first that there is a change in router-id. That too can be solved with a rule that you always come up with the last router-id used. Curtis > > -----Original Message----- > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > > Sent: Thursday, February 06, 2014 5:12 PM > > To: Curtis Villamizar > > Cc: OSPF List > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > autoconfig-05.txt > > > > Hi Curtis, > > I agree and believe the significance of this use case where a new router is > > inserted into an auto-configured domain has been greater exaggerated. > > Thanks, > > Acee > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar wrote: > > > > > > > > In message > > > Acee Lindem writes: > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In > > >> the ISIS WG, there was a concern that the resolution of a duplicate > > >> system ID did not include the amount of time the router was > > >> operational when determining which router would need to choose a new > > >> router ID. With additional complexity, we could incorporate router > > >> uptime into the resolution process. One way to do this would be to: > > >> > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include > > >> the uptime in seconds. > > >> > > >> 2. Use the Router Uptime TLV as the primary determinant in > > >> deciding which router must choose a new OSPFv3 Router > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart are > > >> considered equal. > > >> > > >> 3. When an OSPFv3 Hello is received with a different link-local > > >> source address but a different router-id, unicast the OSPFv3 > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > >> resolution can proceed as in the case where it is received > > >> through the normal flooding process. This is somewhat of a > > >> hack as the we'd also need to accept OSPF Link State Updates > > >> from a neighbor that is not in Exchange State or greater. > > >> > > >> An alternative to #3 would be to use Link-Local Signaling (LLS) for > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want > > >> to send the Router-Uptime and Router Hardware Fingerprint when a > > >> duplicate Router-ID is detected. This requires implementing the > > >> resolution two ways but may be preferable since it doesn't require > > >> violating the flooding rules. > > >> > > >> In any case, I'd like to get other opinions as to whether this problem > > >> is worth solving. > > >> > > >> Thanks, > > >> Acee > > > > > > > > > Acee, > > > > > > If the basis for router-id on boot up results in a fixed value, and if > > > a duplicate will occur on a give network, then which of two duplicate > > > routers gets that value may change after one of them reboots. If > > > uptime is not considered, it will never change as long as one router > > > stays up at any given time. > > > > > > We are talking about a very low probability event (a duplicate) except > > > if this is a DoS attack and then either using or not using uptime > > > won't matter since the attacker will claim an impossibly long uptime. > > > > > > Curtis > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf From curtis@ipv6.occnc.com Fri Feb 7 09:23: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 1FCAB1ACC91 for ; Fri, 7 Feb 2014 09:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CTLfDAofvYM for ; Fri, 7 Feb 2014 09:23:44 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0957D1ACCED for ; Fri, 7 Feb 2014 09:23:34 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s17HNUh6063047; Fri, 7 Feb 2014 12:23:31 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402071723.s17HNUh6063047@maildrop2.v6ds.occnc.com> To: "Les Ginsberg (ginsberg)" From: Curtis Villamizar In-reply-to: Your message of "Fri, 07 Feb 2014 08:58:34 +0000." Date: Fri, 07 Feb 2014 12:23:30 -0500 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:23:47 -0000 In message "Les Ginsberg (ginsberg)" writes: > One other thing I forgot to mention. > > Using the mechanisms I define below, a modestly clever implementation > could implement a startup mode where it does not advertise any > reachability until it has formed at least one neighbor and acquired > the full LSA database. At this point it should know whether it has a > duplicate router-id or not and if so it can assign itself a new > router-id without affecting forwarding behavior at all. > > Les Good suggestion. Curtis > > -----Original Message----- > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Les Ginsberg > > (ginsberg) > > Sent: Friday, February 07, 2014 12:31 AM > > To: Acee Lindem; Curtis Villamizar > > Cc: OSPF List > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > autoconfig-05.txt > > > > So, I am one person who raised this concern to Acee - but the proposal > > outlined by Acee is not what I had in mind. There is no need to use "uptime" > > or to invent some unusual exchange of LSAs prior to Exchange state. > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I am trying > > to mitigate here. As he says if an attacker is in your network and able to > > originate credible packets no strategy is safe. > > > > The motivating use case is to minimize disruption of a stable network when a > > new router is added or an existing router is replaced/rebooted. In other > > words non-disruptive handling of the common maintenance/upgrade scenarios. > > > > What I have in mind is this: > > > > 1)A router needs a way to advertise that it has been up and running for a > > minimum length of time - for the sake of discussion let's say 20 minutes. > > Routers then fall into two categories: > > > > o Old routers (up >= minimum time) > > o New routers (up < minimum time) > > > > 2)When a duplicate router-id is detected, the first tie breaker is between > > old routers and new routers. The old router gets to keep its router-id and > > the new router picks a new router-id. > > If both routers are "new" or both routers are "old" then we revert to the > > existing tie breakers defined in the document (link local address for > > directly connected routers and fingerprint info for non-neighbors). > > > > 3)Advertisement of the "old/new" state requires a single bit - but it has to > > be available both in hellos and the new AC-LSA. Adding it to the AC-LSA is > > easy to do. For hellos, there are two possibilities: > > > > o Use one of the Options Bits > > o Use LLS > > > > Be interested in how folks feel about this. > > > > Les > > > > > > > -----Original Message----- > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > > > Sent: Thursday, February 06, 2014 5:12 PM > > > To: Curtis Villamizar > > > Cc: OSPF List > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > > autoconfig-05.txt > > > > > > Hi Curtis, > > > I agree and believe the significance of this use case where a new router is > > > inserted into an auto-configured domain has been greater exaggerated. > > > Thanks, > > > Acee > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > wrote: > > > > > > > > > > > In message > > > > Acee Lindem writes: > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In > > > >> the ISIS WG, there was a concern that the resolution of a duplicate > > > >> system ID did not include the amount of time the router was > > > >> operational when determining which router would need to choose a new > > > >> router ID. With additional complexity, we could incorporate router > > > >> uptime into the resolution process. One way to do this would be to: > > > >> > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include > > > >> the uptime in seconds. > > > >> > > > >> 2. Use the Router Uptime TLV as the primary determinant in > > > >> deciding which router must choose a new OSPFv3 Router > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart are > > > >> considered equal. > > > >> > > > >> 3. When an OSPFv3 Hello is received with a different link-local > > > >> source address but a different router-id, unicast the OSPFv3 > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > > >> resolution can proceed as in the case where it is received > > > >> through the normal flooding process. This is somewhat of a > > > >> hack as the we'd also need to accept OSPF Link State Updates > > > >> from a neighbor that is not in Exchange State or greater. > > > >> > > > >> An alternative to #3 would be to use Link-Local Signaling (LLS) for > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want > > > >> to send the Router-Uptime and Router Hardware Fingerprint when a > > > >> duplicate Router-ID is detected. This requires implementing the > > > >> resolution two ways but may be preferable since it doesn't require > > > >> violating the flooding rules. > > > >> > > > >> In any case, I'd like to get other opinions as to whether this problem > > > >> is worth solving. > > > >> > > > >> Thanks, > > > >> Acee > > > > > > > > > > > > Acee, > > > > > > > > If the basis for router-id on boot up results in a fixed value, and if > > > > a duplicate will occur on a give network, then which of two duplicate > > > > routers gets that value may change after one of them reboots. If > > > > uptime is not considered, it will never change as long as one router > > > > stays up at any given time. > > > > > > > > We are talking about a very low probability event (a duplicate) except > > > > if this is a DoS attack and then either using or not using uptime > > > > won't matter since the attacker will claim an impossibly long uptime. > > > > > > > > Curtis From ginsberg@cisco.com Fri Feb 7 10:45:44 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF7E1A0447 for ; Fri, 7 Feb 2014 10:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 j-Wsc1rH6paQ for ; Fri, 7 Feb 2014 10:45:41 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC61A03CD for ; Fri, 7 Feb 2014 10:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10119; q=dns/txt; s=iport; t=1391798741; x=1393008341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8CjtcRpIKuqEAKVg5xwQEGVm2SJYiseE+7oDzqeqlJk=; b=JdiZ4CrbRx+Raycsg9pWiWcg+/t8VrmK0pIauW5Afw9xsC3ltCrUPpGV ehiPafkIbZ7gNcKHEWcW9kSvFy9VdSLUwHkiQyebVuLKsbqBuM/3RKP7Z RyaX7S8eBMCkTGgkuERYD9ACHN7NoKgiukelk6F6Nt42dcd5MDxHpuUt8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAPAo9VKtJXG9/2dsb2JhbABTBoMMOFe+aIEOFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAgQOBQgBEodqDcwaF446EgYrBwaDHoEUBKpMgy2CKg X-IronPort-AV: E=Sophos;i="4.95,802,1384300800"; d="scan'208";a="302608502" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 07 Feb 2014 18:45:40 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s17Ijelc015646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 18:45:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 12:45:40 -0600 From: "Les Ginsberg (ginsberg)" To: "curtis@ipv6.occnc.com" Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJCkp/pYRbYVsxUaPEbmLjnjkwpqqGxnw Date: Fri, 7 Feb 2014 18:45:40 +0000 Message-ID: References: Your message of "Fri, 07 Feb 2014 08:31:11 +0000." <201402071722.s17HMMe5063042@maildrop2.v6ds.occnc.com> In-Reply-To: <201402071722.s17HMMe5063042@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 07 Feb 2014 18:45:44 -0000 Curtis - Your reply below is talking about things which I think do not directly bear= on the value add of what I have proposed. You mention various ways to insure that a given device assigns the same rou= ter-id each time it starts up and ways to insure it picks the same sequence= of second/third... choices in the event it has to change its router-id. Al= l good suggestions, but what I am talking about is what we do in the event = a conflict occurs despite our best efforts to avoid it. With the current dr= aft content preference is based solely on a fixed identifier (fingerprint) = without regard to which choice would minimize disruption to the network. Wh= en preference is given to the "old router" to retain its existing router-id= this shortcoming is addressed. Your statement that what I propose is only relevant when two routers go dow= n does not match the scenarios I envision. If I want to add a new device to= my network or if I need to replace an existing device in my network I am o= nly affecting one device - but as I am introducing a device with a new fing= erprint it is possible that it will introduce a conflict with an existing r= outer-id. In a subsequent reply you liked the idea of the new device delaying adverti= sing reachability until it is has determined that its router-id choice is n= ot in conflict. The old/new router paradigm supports this strategy by assur= ing that the old router will not consider changing its router-id until enou= gh time has elapsed for the new router to transition to being an old router= . Finally, what I propose is extremely simple to implement. I think it isn't = much of an exaggeration to say that any one of us could have implemented th= e enhancement in the time it has taken to discuss its merits. So we aren't = overengineering for a case which is admittedly very unlikely to occur - we = are adding a modest extension to make our solution less disruptive. Les > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Friday, February 07, 2014 9:22 AM > To: Les Ginsberg (ginsberg) > Cc: Acee Lindem; Curtis Villamizar; OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 >=20 > In message > "Les Ginsberg (ginsberg)" writes: > > > > So, I am one person who raised this concern to Acee - but the proposal > > outlined by Acee is not what I had in mind. There is no need to use > > "uptime" or to invent some unusual exchange of LSAs prior to Exchange > > state. > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I am > > trying to mitigate here. As he says if an attacker is in your network > > and able to originate credible packets no strategy is safe. > > > > The motivating use case is to minimize disruption of a stable network > > when a new router is added or an existing router is > > replaced/rebooted. In other words non-disruptive handling of the > > common maintenance/upgrade scenarios. > > > > What I have in mind is this: > > > > 1) A router needs a way to advertise that it has been up and running > > for a minimum length of time - for the sake of discussion let's say > > 20 minutes. Routers then fall into two categories: > > > > o Old routers (up >=3D minimum time) > > o New routers (up < minimum time) > > > > 2) When a duplicate router-id is detected, the first tie breaker is > > between old routers and new routers. The old router gets to keep > > its router-id and the new router picks a new router-id. If both > > routers are "new" or both routers are "old" then we revert to the > > existing tie breakers defined in the document (link local address > > for directly connected routers and fingerprint info for > > non-neighbors). > > > > 3) Advertisement of the "old/new" state requires a single bit - but it > > has to be available both in hellos and the new AC-LSA. Adding it to > > the AC-LSA is easy to do. For hellos, there are two possibilities: > > > > o Use one of the Options Bits > > o Use LLS > > > > Be interested in how folks feel about this. > > > > Les >=20 >=20 > Les, >=20 > Excluding DoS attack, we are talking about a one in 4 billion case > (for any two routers, so with 400 routers, still well under one in 1M) > where two routers hash a MAC address or pick a one time random number > from out of nowhere and end up with the same number. >=20 > If that does happen (and one in 1M is certainly possible), then it > would be nice if the routers always ended up with the same router-id. > This could be accomplished by some fixed method such as hashing a > constant with the first choice or router-id or using the router-id as > a seed for the random number generator (which will pick the same > sequence of random numbers each time). If this is done, then a > conflict would always produce the same set of next picks. The set of > routers in a given network would always end up with the same > router-ids once they all came up and if only one went down at a time > then it would always end up with the same router-id when it came up. >=20 > Zero conf was mainly intended for unmanaged networks (motivated by > work in the homenet WG). In these small unmanaged networks it doesn't > matter which router gets what router-id as long as they end up unique > and convergence is in a reasonable time relative to keeping eyeballs > happy. It could be applied to enterprise or providers but in either > case having the routers end up with the same router-ids would make for > easier management. >=20 > For your scenario to matter at all with current rules, both routers in > the conflict would have to go down. If only the one that is preferred > goes down, the other is not going to change its router-id as a result > so when it comes up it gets its first pick with no conflict. If the > one that was not preferred goes down, it comes up, sees a conflict and > takes its second pick (loses the conflict every time). It is only if > they both go down and the one that normally loses the conflict comes > up first that there is a change in router-id. That too can be solved > with a rule that you always come up with the last router-id used. >=20 > Curtis >=20 >=20 > > > -----Original Message----- > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > > > Sent: Thursday, February 06, 2014 5:12 PM > > > To: Curtis Villamizar > > > Cc: OSPF List > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3= - > > > autoconfig-05.txt > > > > > > Hi Curtis, > > > I agree and believe the significance of this use case where a new rou= ter > is > > > inserted into an auto-configured domain has been greater exaggerated. > > > Thanks, > > > Acee > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > wrote: > > > > > > > > > > > In message > > > > Acee Lindem writes: > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). = In > > > >> the ISIS WG, there was a concern that the resolution of a duplicat= e > > > >> system ID did not include the amount of time the router was > > > >> operational when determining which router would need to choose a n= ew > > > >> router ID. With additional complexity, we could incorporate router > > > >> uptime into the resolution process. One way to do this would be to= : > > > >> > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would incl= ude > > > >> the uptime in seconds. > > > >> > > > >> 2. Use the Router Uptime TLV as the primary determinant in > > > >> deciding which router must choose a new OSPFv3 Router > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart ar= e > > > >> considered equal. > > > >> > > > >> 3. When an OSPFv3 Hello is received with a different link-loca= l > > > >> source address but a different router-id, unicast the OSPFv3 > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > > >> resolution can proceed as in the case where it is received > > > >> through the normal flooding process. This is somewhat of a > > > >> hack as the we'd also need to accept OSPF Link State Updates > > > >> from a neighbor that is not in Exchange State or greater. > > > >> > > > >> An alternative to #3 would be to use Link-Local Signaling (LLS) fo= r > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only w= ant > > > >> to send the Router-Uptime and Router Hardware Fingerprint when a > > > >> duplicate Router-ID is detected. This requires implementing the > > > >> resolution two ways but may be preferable since it doesn't require > > > >> violating the flooding rules. > > > >> > > > >> In any case, I'd like to get other opinions as to whether this pro= blem > > > >> is worth solving. > > > >> > > > >> Thanks, > > > >> Acee > > > > > > > > > > > > Acee, > > > > > > > > If the basis for router-id on boot up results in a fixed value, and= if > > > > a duplicate will occur on a give network, then which of two duplica= te > > > > routers gets that value may change after one of them reboots. If > > > > uptime is not considered, it will never change as long as one route= r > > > > stays up at any given time. > > > > > > > > We are talking about a very low probability event (a duplicate) exc= ept > > > > if this is a DoS attack and then either using or not using uptime > > > > won't matter since the attacker will claim an impossibly long uptim= e. > > > > > > > > Curtis > > > > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www.ietf.org/mailman/listinfo/ospf From curtis@ipv6.occnc.com Sat Feb 8 07:30:37 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AA21A033A for ; Sat, 8 Feb 2014 07:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUL8XqJBHcii for ; Sat, 8 Feb 2014 07:30:33 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 741CD1A03A8 for ; Sat, 8 Feb 2014 07:30:32 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s18FUOGq082867; Sat, 8 Feb 2014 10:30:24 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402081530.s18FUOGq082867@maildrop2.v6ds.occnc.com> To: "Les Ginsberg (ginsberg)" From: Curtis Villamizar In-reply-to: Your message of "Fri, 07 Feb 2014 18:45:40 +0000." Date: Sat, 08 Feb 2014 10:30:24 -0500 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 15:30:37 -0000 In message "Les Ginsberg (ginsberg)" writes: > Curtis - > > Your reply below is talking about things which I think do not directly > bear on the value add of what I have proposed. > > You mention various ways to insure that a given device assigns the > same router-id each time it starts up and ways to insure it picks the > same sequence of second/third... choices in the event it has to change > its router-id. All good suggestions, but what I am talking about is > what we do in the event a conflict occurs despite our best efforts to > avoid it. With the current draft content preference is based solely on > a fixed identifier (fingerprint) without regard to which choice would > minimize disruption to the network. When preference is given to the > "old router" to retain its existing router-id this shortcoming is > addressed. In the lifetime of a router it only gets added once. In the lifetime of a router we would hope it only reboots zero time but experience so far has been that reboots over a router's lifetime tend to be > 0 and in some cases >> 0. So you are optimizing for a 1 in 4 billion occurance that can happen only once in the lifetime of a router. We also need to look at the consequences of this very improbably occurance. Today's routers accomplish IGP convergence in large networks in subsecond times, in some cases << 1 second. Note that if flooding is completed (both withdraw old and install new) in less than the SPF delay which is commonly implemented (some delay after receiving the first flooded IGP change), then there is no impact on routing. > Your statement that what I propose is only relevant when two routers > go down does not match the scenarios I envision. If I want to add a > new device to my network or if I need to replace an existing device in > my network I am only affecting one device - but as I am introducing a > device with a new fingerprint it is possible that it will introduce a > conflict with an existing router-id. In provider networks routers are generally added during maintenance windows so should anything unexpected happen, impact is minimized. In home nets, the home user isn't going to notice the convergence time if there is any. A 10 msec SPF delay is likely to be plenty. > In a subsequent reply you liked the idea of the new device delaying > advertising reachability until it is has determined that its router-id > choice is not in conflict. The old/new router paradigm supports this > strategy by assuring that the old router will not consider changing > its router-id until enough time has elapsed for the new router to > transition to being an old router. If it wins the coin toss, the router would advertise at least one LSA to indicate its existance and could hold back on any additional advertisements until the other router has withdrawn routes. > Finally, what I propose is extremely simple to implement. I think it > isn't much of an exaggeration to say that any one of us could have > implemented the enhancement in the time it has taken to discuss its > merits. So we aren't overengineering for a case which is admittedly > very unlikely to occur - we are adding a modest extension to make our > solution less disruptive. Yes but it it *bad* for the more common case where routers go down occasionally. > Les Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > Sent: Friday, February 07, 2014 9:22 AM > > To: Les Ginsberg (ginsberg) > > Cc: Acee Lindem; Curtis Villamizar; OSPF List > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > autoconfig-05.txt > > > > > > In message > > "Les Ginsberg (ginsberg)" writes: > > > > > > So, I am one person who raised this concern to Acee - but the proposal > > > outlined by Acee is not what I had in mind. There is no need to use > > > "uptime" or to invent some unusual exchange of LSAs prior to Exchange > > > state. > > > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I am > > > trying to mitigate here. As he says if an attacker is in your network > > > and able to originate credible packets no strategy is safe. > > > > > > The motivating use case is to minimize disruption of a stable network > > > when a new router is added or an existing router is > > > replaced/rebooted. In other words non-disruptive handling of the > > > common maintenance/upgrade scenarios. > > > > > > What I have in mind is this: > > > > > > 1) A router needs a way to advertise that it has been up and running > > > for a minimum length of time - for the sake of discussion let's say > > > 20 minutes. Routers then fall into two categories: > > > > > > o Old routers (up >= minimum time) > > > o New routers (up < minimum time) > > > > > > 2) When a duplicate router-id is detected, the first tie breaker is > > > between old routers and new routers. The old router gets to keep > > > its router-id and the new router picks a new router-id. If both > > > routers are "new" or both routers are "old" then we revert to the > > > existing tie breakers defined in the document (link local address > > > for directly connected routers and fingerprint info for > > > non-neighbors). > > > > > > 3) Advertisement of the "old/new" state requires a single bit - but it > > > has to be available both in hellos and the new AC-LSA. Adding it to > > > the AC-LSA is easy to do. For hellos, there are two possibilities: > > > > > > o Use one of the Options Bits > > > o Use LLS > > > > > > Be interested in how folks feel about this. > > > > > > Les > > > > > > Les, > > > > Excluding DoS attack, we are talking about a one in 4 billion case > > (for any two routers, so with 400 routers, still well under one in 1M) > > where two routers hash a MAC address or pick a one time random number > > from out of nowhere and end up with the same number. > > > > If that does happen (and one in 1M is certainly possible), then it > > would be nice if the routers always ended up with the same router-id. > > This could be accomplished by some fixed method such as hashing a > > constant with the first choice or router-id or using the router-id as > > a seed for the random number generator (which will pick the same > > sequence of random numbers each time). If this is done, then a > > conflict would always produce the same set of next picks. The set of > > routers in a given network would always end up with the same > > router-ids once they all came up and if only one went down at a time > > then it would always end up with the same router-id when it came up. > > > > Zero conf was mainly intended for unmanaged networks (motivated by > > work in the homenet WG). In these small unmanaged networks it doesn't > > matter which router gets what router-id as long as they end up unique > > and convergence is in a reasonable time relative to keeping eyeballs > > happy. It could be applied to enterprise or providers but in either > > case having the routers end up with the same router-ids would make for > > easier management. > > > > For your scenario to matter at all with current rules, both routers in > > the conflict would have to go down. If only the one that is preferred > > goes down, the other is not going to change its router-id as a result > > so when it comes up it gets its first pick with no conflict. If the > > one that was not preferred goes down, it comes up, sees a conflict and > > takes its second pick (loses the conflict every time). It is only if > > they both go down and the one that normally loses the conflict comes > > up first that there is a change in router-id. That too can be solved > > with a rule that you always come up with the last router-id used. > > > > Curtis > > > > > > > > -----Original Message----- > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > > > > Sent: Thursday, February 06, 2014 5:12 PM > > > > To: Curtis Villamizar > > > > Cc: OSPF List > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > > > autoconfig-05.txt > > > > > > > > Hi Curtis, > > > > I agree and believe the significance of this use case where a new router > > is > > > > inserted into an auto-configured domain has been greater exaggerated. > > > > Thanks, > > > > Acee > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > wrote: > > > > > > > > > > > > > > In message > > > > > Acee Lindem writes: > > > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In > > > > >> the ISIS WG, there was a concern that the resolution of a duplicate > > > > >> system ID did not include the amount of time the router was > > > > >> operational when determining which router would need to choose a new > > > > >> router ID. With additional complexity, we could incorporate router > > > > >> uptime into the resolution process. One way to do this would be to: > > > > >> > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include > > > > >> the uptime in seconds. > > > > >> > > > > >> 2. Use the Router Uptime TLV as the primary determinant in > > > > >> deciding which router must choose a new OSPFv3 Router > > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart are > > > > >> considered equal. > > > > >> > > > > >> 3. When an OSPFv3 Hello is received with a different link-local > > > > >> source address but a different router-id, unicast the OSPFv3 > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > > > >> resolution can proceed as in the case where it is received > > > > >> through the normal flooding process. This is somewhat of a > > > > >> hack as the we'd also need to accept OSPF Link State Updates > > > > >> from a neighbor that is not in Exchange State or greater. > > > > >> > > > > >> An alternative to #3 would be to use Link-Local Signaling (LLS) for > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want > > > > >> to send the Router-Uptime and Router Hardware Fingerprint when a > > > > >> duplicate Router-ID is detected. This requires implementing the > > > > >> resolution two ways but may be preferable since it doesn't require > > > > >> violating the flooding rules. > > > > >> > > > > >> In any case, I'd like to get other opinions as to whether this problem > > > > >> is worth solving. > > > > >> > > > > >> Thanks, > > > > >> Acee > > > > > > > > > > > > > > > Acee, > > > > > > > > > > If the basis for router-id on boot up results in a fixed value, and if > > > > > a duplicate will occur on a give network, then which of two duplicate > > > > > routers gets that value may change after one of them reboots. If > > > > > uptime is not considered, it will never change as long as one router > > > > > stays up at any given time. > > > > > > > > > > We are talking about a very low probability event (a duplicate) except > > > > > if this is a DoS attack and then either using or not using uptime > > > > > won't matter since the attacker will claim an impossibly long uptime. > > > > > > > > > > Curtis > > > > > > > > _______________________________________________ > > > > OSPF mailing list > > > > OSPF@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ospf From ginsberg@cisco.com Sat Feb 8 10:24:18 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 B2BCA1A050B for ; Sat, 8 Feb 2014 10:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 YGLlgA9lCzqM for ; Sat, 8 Feb 2014 10:24:15 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id AD4E91A0176 for ; Sat, 8 Feb 2014 10:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15314; q=dns/txt; s=iport; t=1391883855; x=1393093455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fDbT/3FX2pJM7Cb0eYjnQXaj+n+/lRr7cA0Zs41qERw=; b=ePrJqaK8FncOioloFrR3vCzf0fcW7YN0vni1lHgJtXZRYISw1J/P51D8 7bPtrFIvVjALcVddayE/EGjctL6Px4176S4xbfGC5oz4xkKy2W9VZJaPB TPxTQ26uaoqfcmj23tKjv9JauvTXXQ1X/+OLU3eFAm/pkn3a2Ho9otvv0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJl19lKtJV2c/2dsb2JhbABQAwaDDDhXv1iBCBZ0giUBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQOAwIIARKHYggNyTEXjiIYEgYrBwaDHoEUBIxikw2KXYMtQIFq X-IronPort-AV: E=Sophos;i="4.95,807,1384300800"; d="scan'208";a="18978288" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 08 Feb 2014 18:24:14 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s18IOECM018822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Feb 2014 18:24:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sat, 8 Feb 2014 12:24:14 -0600 From: "Les Ginsberg (ginsberg)" To: "curtis@ipv6.occnc.com" Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJOKv/pYRbYVsxUaPEbmLjnjkwpqro/Cg Date: Sat, 8 Feb 2014 18:24:14 +0000 Message-ID: References: Your message of "Fri, 07 Feb 2014 18:45:40 +0000." <201402081530.s18FUOGq082867@maildrop2.v6ds.occnc.com> In-Reply-To: <201402081530.s18FUOGq082867@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 08 Feb 2014 18:24:18 -0000 Curtis - > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Saturday, February 08, 2014 7:30 AM > To: Les Ginsberg (ginsberg) > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 >=20 > In message > "Les Ginsberg (ginsberg)" writes: >=20 > > Curtis - > > > > Your reply below is talking about things which I think do not directly > > bear on the value add of what I have proposed. > > > > You mention various ways to insure that a given device assigns the > > same router-id each time it starts up and ways to insure it picks the > > same sequence of second/third... choices in the event it has to change > > its router-id. All good suggestions, but what I am talking about is > > what we do in the event a conflict occurs despite our best efforts to > > avoid it. With the current draft content preference is based solely on > > a fixed identifier (fingerprint) without regard to which choice would > > minimize disruption to the network. When preference is given to the > > "old router" to retain its existing router-id this shortcoming is > > addressed. >=20 > In the lifetime of a router it only gets added once. In the lifetime > of a router we would hope it only reboots zero time but experience so > far has been that reboots over a router's lifetime tend to be > 0 and > in some cases >> 0. >=20 > So you are optimizing for a 1 in 4 billion occurance that can happen > only once in the lifetime of a router. The entire duplicate router-id resolution logic is addressing the improbabl= e case. My proposal adds - literally - one line of code to the logic used t= o decide whether "I" should change my router-id or whether "you" should cha= nge your router-id. >=20 > We also need to look at the consequences of this very improbably > occurance. Today's routers accomplish IGP convergence in large > networks in subsecond times, in some cases << 1 second. >=20 > Note that if flooding is completed (both withdraw old and install new) > in less than the SPF delay which is commonly implemented (some delay > after receiving the first flooded IGP change), then there is no impact > on routing. Your analysis does not apply to this scenario. The router which changes its= router-id is effectively doing a cold start. All adjacencies will go down.= All LSAs originated by this router become invalid. All routes will be remo= ved from the forwarding plane. If you are running BGP all the BGP nexthops = will be gone on the router which is changing its identity. Restoration of t= he adjacencies and reacquisition of the LSDB will take multiple seconds. Th= e best you can hope for is several seconds of disruption - it could easily = be much longer. For the new node which has usurped the old node's identity it will have to = purge/replace all of the LSAs generated by the old node. While normal opera= tion of the update process will insure that this happens in a reliable way = the amount of flooding network-wide required to bringup a new node has now = been roughly doubled i.e. the old node must reissue all of its LSAs using a= new identity and the new node must purge/replace the old node's LSAs with = its own versions. This will result in multiple SPFs on all nodes in the net= work and likely cause loops/blackholes during the transition since some of = the SPFs will be run on versions of the LSDB which are inaccurate (part old= node's old LSAs and part new node's LSAs). Suggesting that this could be h= andled in the same way/time as we typically handle a single link failure is= n't credible. >=20 > > Your statement that what I propose is only relevant when two routers > > go down does not match the scenarios I envision. If I want to add a > > new device to my network or if I need to replace an existing device in > > my network I am only affecting one device - but as I am introducing a > > device with a new fingerprint it is possible that it will introduce a > > conflict with an existing router-id. >=20 > In provider networks routers are generally added during maintenance > windows so should anything unexpected happen, impact is minimized. >=20 > In home nets, the home user isn't going to notice the convergence time > if there is any. A 10 msec SPF delay is likely to be plenty. As I stated above, disruption will be orders of magnitude longer than 10 ms= .=20 >=20 > > In a subsequent reply you liked the idea of the new device delaying > > advertising reachability until it is has determined that its router-id > > choice is not in conflict. The old/new router paradigm supports this > > strategy by assuring that the old router will not consider changing > > its router-id until enough time has elapsed for the new router to > > transition to being an old router. >=20 > If it wins the coin toss, the router would advertise at least one LSA > to indicate its existance and could hold back on any additional > advertisements until the other router has withdrawn routes. >=20 This suggestion does not alter the fact that if the old node changes its ro= uter-id the network has to respond to three events: 1)Loss of the old node 2)Introduction of the old-node with a new identity 3)Introduction of the new node with the identity of the old-node If however we insure that the old-node does not change its identity then th= e network only has to respond to a single event - the introduction of the n= ew-node. > > Finally, what I propose is extremely simple to implement. I think it > > isn't much of an exaggeration to say that any one of us could have > > implemented the enhancement in the time it has taken to discuss its > > merits. So we aren't overengineering for a case which is admittedly > > very unlikely to occur - we are adding a modest extension to make our > > solution less disruptive. >=20 > Yes but it it *bad* for the more common case where routers go down > occasionally. You are going to have to clarify exactly what "bad side effects" you see fo= r what I propose - because I don't see any - whereas I do see benefits as d= escribed above. Les >=20 > > Les >=20 > Curtis >=20 >=20 > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > Sent: Friday, February 07, 2014 9:22 AM > > > To: Les Ginsberg (ginsberg) > > > Cc: Acee Lindem; Curtis Villamizar; OSPF List > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3= - > > > autoconfig-05.txt > > > > > > > > > In message x02.cisco.com> > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > So, I am one person who raised this concern to Acee - but the propo= sal > > > > outlined by Acee is not what I had in mind. There is no need to use > > > > "uptime" or to invent some unusual exchange of LSAs prior to Exchan= ge > > > > state. > > > > > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I= am > > > > trying to mitigate here. As he says if an attacker is in your netwo= rk > > > > and able to originate credible packets no strategy is safe. > > > > > > > > The motivating use case is to minimize disruption of a stable netwo= rk > > > > when a new router is added or an existing router is > > > > replaced/rebooted. In other words non-disruptive handling of the > > > > common maintenance/upgrade scenarios. > > > > > > > > What I have in mind is this: > > > > > > > > 1) A router needs a way to advertise that it has been up and runnin= g > > > > for a minimum length of time - for the sake of discussion let's = say > > > > 20 minutes. Routers then fall into two categories: > > > > > > > > o Old routers (up >=3D minimum time) > > > > o New routers (up < minimum time) > > > > > > > > 2) When a duplicate router-id is detected, the first tie breaker is > > > > between old routers and new routers. The old router gets to keep > > > > its router-id and the new router picks a new router-id. If both > > > > routers are "new" or both routers are "old" then we revert to th= e > > > > existing tie breakers defined in the document (link local addres= s > > > > for directly connected routers and fingerprint info for > > > > non-neighbors). > > > > > > > > 3) Advertisement of the "old/new" state requires a single bit - but= it > > > > has to be available both in hellos and the new AC-LSA. Adding it= to > > > > the AC-LSA is easy to do. For hellos, there are two possibilitie= s: > > > > > > > > o Use one of the Options Bits > > > > o Use LLS > > > > > > > > Be interested in how folks feel about this. > > > > > > > > Les > > > > > > > > > Les, > > > > > > Excluding DoS attack, we are talking about a one in 4 billion case > > > (for any two routers, so with 400 routers, still well under one in 1M= ) > > > where two routers hash a MAC address or pick a one time random number > > > from out of nowhere and end up with the same number. > > > > > > If that does happen (and one in 1M is certainly possible), then it > > > would be nice if the routers always ended up with the same router-id. > > > This could be accomplished by some fixed method such as hashing a > > > constant with the first choice or router-id or using the router-id as > > > a seed for the random number generator (which will pick the same > > > sequence of random numbers each time). If this is done, then a > > > conflict would always produce the same set of next picks. The set of > > > routers in a given network would always end up with the same > > > router-ids once they all came up and if only one went down at a time > > > then it would always end up with the same router-id when it came up. > > > > > > Zero conf was mainly intended for unmanaged networks (motivated by > > > work in the homenet WG). In these small unmanaged networks it doesn'= t > > > matter which router gets what router-id as long as they end up unique > > > and convergence is in a reasonable time relative to keeping eyeballs > > > happy. It could be applied to enterprise or providers but in either > > > case having the routers end up with the same router-ids would make fo= r > > > easier management. > > > > > > For your scenario to matter at all with current rules, both routers i= n > > > the conflict would have to go down. If only the one that is preferre= d > > > goes down, the other is not going to change its router-id as a result > > > so when it comes up it gets its first pick with no conflict. If the > > > one that was not preferred goes down, it comes up, sees a conflict an= d > > > takes its second pick (loses the conflict every time). It is only if > > > they both go down and the one that normally loses the conflict comes > > > up first that there is a change in router-id. That too can be solved > > > with a rule that you always come up with the last router-id used. > > > > > > Curtis > > > > > > > > > > > -----Original Message----- > > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Linde= m > > > > > Sent: Thursday, February 06, 2014 5:12 PM > > > > > To: Curtis Villamizar > > > > > Cc: OSPF List > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- > ospfv3- > > > > > autoconfig-05.txt > > > > > > > > > > Hi Curtis, > > > > > I agree and believe the significance of this use case where a new > router > > > is > > > > > inserted into an auto-configured domain has been greater exaggera= ted. > > > > > Thanks, > > > > > Acee > > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > > wrote: > > > > > > > > > > > > > > > > > In message > > > > > > Acee Lindem writes: > > > > > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in= the > > > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.tx= t). > In > > > > > >> the ISIS WG, there was a concern that the resolution of a > duplicate > > > > > >> system ID did not include the amount of time the router was > > > > > >> operational when determining which router would need to choose= a > new > > > > > >> router ID. With additional complexity, we could incorporate ro= uter > > > > > >> uptime into the resolution process. One way to do this would b= e > to: > > > > > >> > > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would > include > > > > > >> the uptime in seconds. > > > > > >> > > > > > >> 2. Use the Router Uptime TLV as the primary determinant in > > > > > >> deciding which router must choose a new OSPFv3 Router > > > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apar= t > are > > > > > >> considered equal. > > > > > >> > > > > > >> 3. When an OSPFv3 Hello is received with a different link- > local > > > > > >> source address but a different router-id, unicast the > OSPFv3 > > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > > > > >> resolution can proceed as in the case where it is receive= d > > > > > >> through the normal flooding process. This is somewhat of = a > > > > > >> hack as the we'd also need to accept OSPF Link State > Updates > > > > > >> from a neighbor that is not in Exchange State or greater. > > > > > >> > > > > > >> An alternative to #3 would be to use Link-Local Signaling (LLS= ) > for > > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd on= ly > want > > > > > >> to send the Router-Uptime and Router Hardware Fingerprint when= a > > > > > >> duplicate Router-ID is detected. This requires implementing th= e > > > > > >> resolution two ways but may be preferable since it doesn't req= uire > > > > > >> violating the flooding rules. > > > > > >> > > > > > >> In any case, I'd like to get other opinions as to whether this > problem > > > > > >> is worth solving. > > > > > >> > > > > > >> Thanks, > > > > > >> Acee > > > > > > > > > > > > > > > > > > Acee, > > > > > > > > > > > > If the basis for router-id on boot up results in a fixed value,= and > if > > > > > > a duplicate will occur on a give network, then which of two > duplicate > > > > > > routers gets that value may change after one of them reboots. = If > > > > > > uptime is not considered, it will never change as long as one > router > > > > > > stays up at any given time. > > > > > > > > > > > > We are talking about a very low probability event (a duplicate) > except > > > > > > if this is a DoS attack and then either using or not using upti= me > > > > > > won't matter since the attacker will claim an impossibly long > uptime. > > > > > > > > > > > > Curtis > > > > > > > > > > _______________________________________________ > > > > > OSPF mailing list > > > > > OSPF@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ospf From karsten_thomann@linfre.de Sat Feb 8 11:52:01 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 37F471A05D7 for ; Sat, 8 Feb 2014 11:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMxcCx5JFr49 for ; Sat, 8 Feb 2014 11:51:58 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id D16B51A058F for ; Sat, 8 Feb 2014 11:51:57 -0800 (PST) Received: from linne.localnet (194.64.241.52) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 1D72E1; Sat, 8 Feb 2014 20:51:48 +0100 From: Karsten Thomann To: ospf@ietf.org Date: Sat, 08 Feb 2014 20:51:52 +0100 Message-ID: <1403870.9GCab44eum@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: References: <20140127102503.24239.31809.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2331153.zBl0q4Lnmp" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Subject: Re: [OSPF] FW: New Version Notification for draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 19:52:01 -0000 This is a multi-part message in MIME format. --nextPart2331153.zBl0q4Lnmp Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, I don't know if i have missed that part, but what would happen if OSPFv3 is running over IPv4 and there are two (or more) IPv6 Islands already deployed within the network, should there be any LSA flooding checks, like do not flood LSA with IPv6 networks over IPv4 only links, or should the route calculation/installation of the information simply fail as there is no valid path? Regarding: In situations where the IPv4 deployment is a proper superset of the IPv6 deployment, it is expected that OSPFv3 packets would be carried over IPv4, until the rest of the network deployment is upgraded to support IPv6 in addition to IPv4. Is there any explicit preference over which version the adjacency is build if v4 and v6 is available in that specific part of the network? What should happen when an IPv4 Link gets v6 added, graceful reestablish the adjacency over IPv6, or wait until forced protocol switch? Regards Karsten Am Freitag, 7. Februar 2014, 14:50:46 schrieb Ing-Wher Chen: > Hello, > > The information draft below documents how to encapsulate OSPFv3 packets in > IPv4 in an effort to transition to OSPFv3 and IPv6. > > Thanks, > Helen > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 27, 2014 2:25 AM > To: Ing-Wher Chen; Ing-Wher Chen; Acee Lindem; Acee Lindem > Subject: New Version Notification for > draft-chen-ospf-transition-to-ospfv3-00.txt > > > A new version of I-D, draft-chen-ospf-transition-to-ospfv3-00.txt > has been successfully submitted by I. Chen and posted to the IETF > repository. > > Name: draft-chen-ospf-transition-to-ospfv3 > Revision: 00 > Title: OSPFv3 over IPv4 for IPv6 Transition > Document date: 2014-01-26 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-chen-ospf-transition-to-ospfv3-00 > .txt Status: > https://datatracker.ietf.org/doc/draft-chen-ospf-transition-to-ospfv3/ > Htmlized: > http://tools.ietf.org/html/draft-chen-ospf-transition-to-ospfv3-00 > > > Abstract: > This draft defines a mechanism to use IPv4 to transport OSPFv3 > packets, in order to facilitate transition from IPv4-only to IPv6 and > dual-stack within a routing domain. Using OSPFv3 over IPv4 with the > existing OSPFv3 Address Family extension simplifies transition from > an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing > domain, and later possibly to an IPv6-only routing domain. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --nextPart2331153.zBl0q4Lnmp Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Hello,

 

I don't know if i have missed that part, but what would happen if OSPFv3 is running over IPv4 and there are two (or more) IPv6 Islands already deployed within the network, should there be any LSA flooding checks, like do not flood LSA with IPv6 networks over IPv4 only links, or should the route calculation/installation of the information simply fail as there is no valid path?

 

Regarding:

In situations where the IPv4 deployment is a proper

   superset of the IPv6 deployment, it is expected that OSPFv3 packets
   would be carried over IPv4, until the rest of the network deployment
   is upgraded to support IPv6 in addition to IPv4.
Is there any explicit preference over which version the adjacency is build if v4 and v6 is available in that specific part of the network?
What should happen when an IPv4 Link gets v6 added, graceful reestablish the adjacency over IPv6, or wait until forced protocol switch?

Regards

Karsten

 

Am Freitag, 7. Februar 2014, 14:50:46 schrieb Ing-Wher Chen:

> Hello,

>

> The information draft below documents how to encapsulate OSPFv3 packets in

> IPv4 in an effort to transition to OSPFv3 and IPv6.

>

> Thanks,

> Helen

>

> -----Original Message-----

> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

> Sent: Monday, January 27, 2014 2:25 AM

> To: Ing-Wher Chen; Ing-Wher Chen; Acee Lindem; Acee Lindem

> Subject: New Version Notification for

> draft-chen-ospf-transition-to-ospfv3-00.txt

>

>

> A new version of I-D, draft-chen-ospf-transition-to-ospfv3-00.txt

> has been successfully submitted by I. Chen and posted to the IETF

> repository.

>

> Name: draft-chen-ospf-transition-to-ospfv3

> Revision: 00

> Title: OSPFv3 over IPv4 for IPv6 Transition

> Document date: 2014-01-26

> Group: Individual Submission

> Pages: 8

> URL:

> http://www.ietf.org/internet-drafts/draft-chen-ospf-transition-to-ospfv3-00

> .txt Status:

> https://datatracker.ietf.org/doc/draft-chen-ospf-transition-to-ospfv3/

> Htmlized:

> http://tools.ietf.org/html/draft-chen-ospf-transition-to-ospfv3-00

>

>

> Abstract:

> This draft defines a mechanism to use IPv4 to transport OSPFv3

> packets, in order to facilitate transition from IPv4-only to IPv6 and

> dual-stack within a routing domain. Using OSPFv3 over IPv4 with the

> existing OSPFv3 Address Family extension simplifies transition from

> an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing

> domain, and later possibly to an IPv6-only routing domain.

>

>

>

>

> Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretariat

>

> _______________________________________________

> OSPF mailing list

> OSPF@ietf.org

> https://www.ietf.org/mailman/listinfo/ospf

--nextPart2331153.zBl0q4Lnmp-- From acee.lindem@ericsson.com Sun Feb 9 09:58:15 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 365D21A040B for ; Sun, 9 Feb 2014 09:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FUYLTOIfRVFn for ; Sun, 9 Feb 2014 09:58:13 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE681A03B2 for ; Sun, 9 Feb 2014 09:58:13 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-d0-52f7c1abd92f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 09.0B.12743.BA1C7F25; Sun, 9 Feb 2014 18:58:03 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Sun, 9 Feb 2014 12:58:05 -0500 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: OSPF WG Meeting at IETF 89 Thread-Index: AQHPJcB7OntBcFrtTUmjBCa2uQfFvg== Date: Sun, 9 Feb 2014 17:58:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CF1D01AC26D64aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXSPt+7qg9+DDD4tNrVouXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGTvn/mQq2MRZcXb+BcYGxi6OLkZODgkBE4lfF1uYIWwxiQv3 1rN1MXJxCAkcYZS4OWsvI4SzjFHi7+RnjCBVbAI6Es8f/QPrEBFQl1g9eTcriC0soCKxb9d+ qLimxPGft6FsPYlbM9tYQGwWoJqFbTuZQGxeAVOJawd2gNmMQJu/n1oDZjMLiEvcejKfCeIi AYkle85DXScq8fLxP7BdokAzu2ctZ4WIK0rs65/ODtEbJXHv/V1WiPmCEidnPmGZwCg8C8nY WUjKZiEpg4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNtaYu2S/WzIahYwcqxi5CgtTi3LTTcy 2MQIjJVjEmy6Oxj3vLQ8xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYz lm1X+WMP+6sZXXvLqFP9U+Tv/3/BzLO8Ks66Tjr5K2+lZmnAop5PItYOXMe0TyVE7Hs2ZZnT 5KjeVSuKp3PJrWoLmLjw9qe5BjMdVde5XVn1+kVOu5f6k6LtH7i6BGSbpr/ZeWjl7fuqkSWF D4QT3v26r7ytIkctLHjG8j/6IYbMc86cfvNciaU4I9FQi7moOBEA0JYza2MCAAA= Subject: [OSPF] OSPF WG Meeting at IETF 89 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, 09 Feb 2014 17:58:15 -0000 --_000_CF1D01AC26D64aceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We will be meeting in London and have the first IETF session slot (9:00 =96= 11:30 AM on Monday, March 3, 2014). Please agenda requests to Abhay and myself. Thanks, Abhay and Acee --_000_CF1D01AC26D64aceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <91BA00724E7B12459030061C2B051A8B@ericsson.com> Content-Transfer-Encoding: quoted-printable
We will be meeting in London and have the first IETF session slot (9:0= 0 =9611:30 AM on Monday, March 3, 2014). 
Please agenda requests to Abhay and myself.

Thanks,
Abhay and Acee 



--_000_CF1D01AC26D64aceelindemericssoncom_-- From acee.lindem@ericsson.com Sun Feb 9 10:22: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 BFA481A0411 for ; Sun, 9 Feb 2014 10:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EpGVTRoZWSCP for ; Sun, 9 Feb 2014 10:22:22 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1880A1A040F for ; Sun, 9 Feb 2014 10:22:22 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-61-52f7c75a18c1 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F1.3B.12743.A57C7F25; Sun, 9 Feb 2014 19:22:19 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Sun, 9 Feb 2014 13:22:21 -0500 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: OSPF WG Meeting at IETF 89 (Revised) Thread-Index: AQHPJcPfkg2oEN4R4kGPxz2iqsqsyQ== Date: Sun, 9 Feb 2014 18:22:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_CF1D06D626D73aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPrG708e9BBu8Wc1u03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFuPLzAVzOapWPduF3sD41quLkZODgkBE4nGRTPZIGwxiQv3 1gPZXBxCAkcYJQ7tWAGWEBJYxijx+nEWiM0moCPx/NE/ZhBbREBdYvXk3awgtrCAnsSSOc+Y IOLGEm2dh9kgbD2JNydmsnQxcnCwCKhIvJ1qCxLmFTCVuLr4E1grI9De76fWgLUyC4hL3Hoy nwniHgGJJXvOM0PYohIvH/8DqxcFGtk9azkrRFxJYtLSc6wQvVESW1vesELMF5Q4OfMJywRG 4VlIxs5CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hL3Xu5hR1azgJFjFSNHaXFq WW66kcEmRmCcHJNg093BuOel5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUw8nkyO8ydXJne2ZJ6zllat06Wr8K2ud9uEtO1ekfnGuMt/9iETkfuN8voPGB3R3HdDuHQ o1rTzE32G8y7ZSBY+OjajHKltoh+bfazOdmMYt+Mw8Ui28V+t2h7H1ndo62wO7ZZrtpHp61e /2T2w3Xa97VvCVyInjHvh0WDz/f3swNPOXdw8yqxFGckGmoxFxUnAgC7UsOrYQIAAA== Subject: [OSPF] OSPF WG Meeting at IETF 89 (Revised) 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, 09 Feb 2014 18:22:23 -0000 --_000_CF1D06D626D73aceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We will be meeting in London and have the first IETF session slot (9:00 =96= 11:30 AM on Monday, March 3, 2014). Please send agenda requests to Abhay and myself. Also note that the deadlin= e for draft submission is 23:59 UTC on February 14th. So, remember to push = your new and updated drafts prior to any romantic dinner plans. Thanks, Abhay and Acee --_000_CF1D06D626D73aceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
We will be meeting in London and have the first IETF session slot (9:0= 0 =9611:30 AM on Monday, March 3, 2014). 
Please send agenda requests to Abhay and myself. Also note that the de= adline for draft submission is 23:59 UTC on February 14th. So, remember to = push your new and updated drafts prior to any romantic dinner plans. <= /div>

Thanks,
Abhay and Acee 



--_000_CF1D06D626D73aceelindemericssoncom_-- From curtis@ipv6.occnc.com Sun Feb 9 12:39:00 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD51A05F3 for ; Sun, 9 Feb 2014 12:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRUP9zRpJ_63 for ; Sun, 9 Feb 2014 12:38:54 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 608581A05D5 for ; Sun, 9 Feb 2014 12:38:54 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s19KciP5015271; Sun, 9 Feb 2014 15:38:44 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402092038.s19KciP5015271@maildrop2.v6ds.occnc.com> To: "Les Ginsberg (ginsberg)" From: Curtis Villamizar In-reply-to: Your message of "Sat, 08 Feb 2014 18:24:14 +0000." Date: Sun, 09 Feb 2014 15:38:44 -0500 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 20:39:00 -0000 Les, Perhaps you should read the abstract of the document you are commenting about: SPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. Home network! Or the introductio: OSPFv3 [OSPFV3] is a candidate for deployments in environments where auto-configuration is a requirement. [...] 1.2. Acknowledgments This specification was inspired by the work presented in the Homenet working group meeting in October 2011 in Philadelphia, Pennsylvania. The Homenet WG works on what? Home networks! So please keep that in mind when commenting. Unless a provider were to be so stupid or lazy to use this on a SP network then most of the comments from both of us don't apply, *except* the few comments below about "in a home network". Perhaps the draft should add text explicitly stating that the last router-id used successfully should be used on a reboot rather than a new random number. I notice that only the Router-Hardware-Fingerprint TLV is persistent across reboots. This is insufficient if we want to minimize disruption. The only case then (if router-id is remembered across reboots) would be a new router. In that case your uptime rule would help. So perhaps two things could be reocmmended: 1. In section 4, include a "SHOULD remember the most recent successfully used router-id across reboots and reuse that". Reword the rest so if that information is not available, then pick a random number. 2. a. In section 6, mention the uptime rule. Modify the Router Uptime TLV as suggested. b. Alternately add a flag to the Router-Hardware-Fingerprint TLV that indicates that since last reboot this router-id has been used and acheived a "full state". A router just rebooting would not have ever reached the full state before noticing a conflict as long as the conflct check is run before considering itself in the full state. Note: A second flag bit indicating that this router-id had been used successfully in a past reboot might also help but would only matter among two routers both rebooting and neither having reached the full state. I think #1 above is sufficient and does more to prevent surprises. I think #2 above helps only in the new router case but #2a requires adding a TLV and so isn't worth it IMHO. Case #2b accomplished the same thing with only a flag. I would not object to #2b above if #1 above is also added. See inline anyway. In message "Les Ginsberg (ginsberg)" writes: > > Curtis - > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > Sent: Saturday, February 08, 2014 7:30 AM > > To: Les Ginsberg (ginsberg) > > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > autoconfig-05.txt > > > > > > In message > > "Les Ginsberg (ginsberg)" writes: > > > > > Curtis - > > > > > > Your reply below is talking about things which I think do not directly > > > bear on the value add of what I have proposed. > > > > > > You mention various ways to insure that a given device assigns the > > > same router-id each time it starts up and ways to insure it picks the > > > same sequence of second/third... choices in the event it has to change > > > its router-id. All good suggestions, but what I am talking about is > > > what we do in the event a conflict occurs despite our best efforts to > > > avoid it. With the current draft content preference is based solely on > > > a fixed identifier (fingerprint) without regard to which choice would > > > minimize disruption to the network. When preference is given to the > > > "old router" to retain its existing router-id this shortcoming is > > > addressed. > > > > In the lifetime of a router it only gets added once. In the lifetime > > of a router we would hope it only reboots zero time but experience so > > far has been that reboots over a router's lifetime tend to be > 0 and > > in some cases >> 0. > > > > So you are optimizing for a 1 in 4 billion occurance that can happen > > only once in the lifetime of a router. > > The entire duplicate router-id resolution logic is addressing the > improbable case. My proposal adds - literally - one line of code to > the logic used to decide whether "I" should change my router-id or > whether "you" should change your router-id. > > > > > We also need to look at the consequences of this very improbably > > occurance. Today's routers accomplish IGP convergence in large > > networks in subsecond times, in some cases << 1 second. > > > > Note that if flooding is completed (both withdraw old and install new) > > in less than the SPF delay which is commonly implemented (some delay > > after receiving the first flooded IGP change), then there is no impact > > on routing. > > Your analysis does not apply to this scenario. The router which > changes its router-id is effectively doing a cold start. All > adjacencies will go down. All LSAs originated by this router become > invalid. All routes will be removed from the forwarding plane. If > you are running BGP all the BGP nexthops will be gone on the router > which is changing its identity. Restoration of the adjacencies and > reacquisition of the LSDB will take multiple seconds. The best you > can hope for is several seconds of disruption - it could easily be > much longer. > > For the new node which has usurped the old node's identity it will > have to purge/replace all of the LSAs generated by the old > node. While normal operation of the update process will insure that > this happens in a reliable way the amount of flooding network-wide > required to bringup a new node has now been roughly doubled > i.e. the old node must reissue all of its LSAs using a new identity > and the new node must purge/replace the old node's LSAs with its > own versions. This will result in multiple SPFs on all nodes in the > network and likely cause loops/blackholes during the transition > since some of the SPFs will be run on versions of the LSDB which > are inaccurate (part old node's old LSAs and part new node's > LSAs). Suggesting that this could be handled in the same way/time > as we typically handle a single link failure isn't credible. All routers are supposed to keep a fixed router-id across reboots. If interfaces are changed when down, the last used router-id should be on flash. If flash is removed and replaced (rather than a new image installed), then with the same set of interfaces, the same decision should be made. We are down to a very special case where both flash and interfaces are removed and replaced yielding no history and a different set of MACs to pick from. > > > Your statement that what I propose is only relevant when two routers > > > go down does not match the scenarios I envision. If I want to add a > > > new device to my network or if I need to replace an existing device in > > > my network I am only affecting one device - but as I am introducing a > > > device with a new fingerprint it is possible that it will introduce a > > > conflict with an existing router-id. > > > > In provider networks routers are generally added during maintenance > > windows so should anything unexpected happen, impact is minimized. > > > > In home nets, the home user isn't going to notice the convergence time > > if there is any. A 10 msec SPF delay is likely to be plenty. > > As I stated above, disruption will be orders of magnitude longer than 10 ms. In a home net? With perhaps a half dozen routers and a default route? Someone has a very bad OSPF implementation. :-) Or did you miss the "In home nets" at the front of the paragraph. For example, in a 10 node network with average degree 4, perhpas 40 links in 10 router LSA exist. A few RTT (less than 1 msec for a homenet) for each neighbor adjacency (which happen in parallel) and ten packets from 4 sources is needed to reach the full state followed by one SPF to be fully up and running. Other routers get one additional router LSA plus four new links in existing router LSA and have to run an SPF. Even on a software based homenet router using an ARM, 10 msec is likely to be enough time and if it is "orders of magnitude" longer, something is wrong with one of the implementations. This would be an more complicated than usual home net or even soho, more likely a small business. > > > In a subsequent reply you liked the idea of the new device delaying > > > advertising reachability until it is has determined that its router-id > > > choice is not in conflict. The old/new router paradigm supports this > > > strategy by assuring that the old router will not consider changing > > > its router-id until enough time has elapsed for the new router to > > > transition to being an old router. > > > > If it wins the coin toss, the router would advertise at least one LSA > > to indicate its existance and could hold back on any additional > > advertisements until the other router has withdrawn routes. > > > > This suggestion does not alter the fact that if the old node changes > > > its router-id the network has to respond to three events: > > 1)Loss of the old node > 2)Introduction of the old-node with a new identity > 3)Introduction of the new node with the identity of the old-node Again, the old node should remember the last router-id used and try to reuse it. > If however we insure that the old-node does not change its identity > then the network only has to respond to a single event - the > introduction of the new-node. Yes and if it were up and won the resolution last time, it will have saved that router-id and will reuse it. If it came up previously and lost the resolution, then it will remember the router-id it used, whether second or third pick, and use that. > > > Finally, what I propose is extremely simple to implement. I think it > > > isn't much of an exaggeration to say that any one of us could have > > > implemented the enhancement in the time it has taken to discuss its > > > merits. So we aren't overengineering for a case which is admittedly > > > very unlikely to occur - we are adding a modest extension to make our > > > solution less disruptive. > > > > Yes but it it *bad* for the more common case where routers go down > > occasionally. > > You are going to have to clarify exactly what "bad side effects" you > see for what I propose - because I don't see any - whereas I do > see benefits as described above. If router-id is not remembered between reboots, then there is the one in 4 billion time number of routers (less than 10 for a home net today, but maybe more in the future). If router-id is remembered between reboots, then no matter how long a router has been down, if nothing else in the network changed, there is zero chance of having a collision. With either method, if router-id is remembered between reboots, then there is zero chance of collision. IMO should this ever be used on a managed network (including a home net / soho / small business net that happens to be managed) then having routers come back from a reboot with the same router-ids would be a big plus. For example, after a power outage NMS discovery would not have to be repeated. > Les > > > > > > > Les > > > > Curtis > > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > Sent: Friday, February 07, 2014 9:22 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: Acee Lindem; Curtis Villamizar; OSPF List > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > > > autoconfig-05.txt > > > > > > > > > > > > In message > x02.cisco.com> > > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > > > So, I am one person who raised this concern to Acee - but the proposal > > > > > outlined by Acee is not what I had in mind. There is no need to use > > > > > "uptime" or to invent some unusual exchange of LSAs prior to Exchange > > > > > state. > > > > > > > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I am > > > > > trying to mitigate here. As he says if an attacker is in your network > > > > > and able to originate credible packets no strategy is safe. > > > > > > > > > > The motivating use case is to minimize disruption of a stable network > > > > > when a new router is added or an existing router is > > > > > replaced/rebooted. In other words non-disruptive handling of the > > > > > common maintenance/upgrade scenarios. > > > > > > > > > > What I have in mind is this: > > > > > > > > > > 1) A router needs a way to advertise that it has been up and running > > > > > for a minimum length of time - for the sake of discussion let's say > > > > > 20 minutes. Routers then fall into two categories: > > > > > > > > > > o Old routers (up >= minimum time) > > > > > o New routers (up < minimum time) > > > > > > > > > > 2) When a duplicate router-id is detected, the first tie breaker is > > > > > between old routers and new routers. The old router gets to keep > > > > > its router-id and the new router picks a new router-id. If both > > > > > routers are "new" or both routers are "old" then we revert to the > > > > > existing tie breakers defined in the document (link local address > > > > > for directly connected routers and fingerprint info for > > > > > non-neighbors). > > > > > > > > > > 3) Advertisement of the "old/new" state requires a single bit - but it > > > > > has to be available both in hellos and the new AC-LSA. Adding it to > > > > > the AC-LSA is easy to do. For hellos, there are two possibilities: > > > > > > > > > > o Use one of the Options Bits > > > > > o Use LLS > > > > > > > > > > Be interested in how folks feel about this. > > > > > > > > > > Les > > > > > > > > > > > > Les, > > > > > > > > Excluding DoS attack, we are talking about a one in 4 billion case > > > > (for any two routers, so with 400 routers, still well under one in 1M) > > > > where two routers hash a MAC address or pick a one time random number > > > > from out of nowhere and end up with the same number. > > > > > > > > If that does happen (and one in 1M is certainly possible), then it > > > > would be nice if the routers always ended up with the same router-id. > > > > This could be accomplished by some fixed method such as hashing a > > > > constant with the first choice or router-id or using the router-id as > > > > a seed for the random number generator (which will pick the same > > > > sequence of random numbers each time). If this is done, then a > > > > conflict would always produce the same set of next picks. The set of > > > > routers in a given network would always end up with the same > > > > router-ids once they all came up and if only one went down at a time > > > > then it would always end up with the same router-id when it came up. > > > > > > > > Zero conf was mainly intended for unmanaged networks (motivated by > > > > work in the homenet WG). In these small unmanaged networks it doesn't > > > > matter which router gets what router-id as long as they end up unique > > > > and convergence is in a reasonable time relative to keeping eyeballs > > > > happy. It could be applied to enterprise or providers but in either > > > > case having the routers end up with the same router-ids would make for > > > > easier management. > > > > > > > > For your scenario to matter at all with current rules, both routers in > > > > the conflict would have to go down. If only the one that is preferred > > > > goes down, the other is not going to change its router-id as a result > > > > so when it comes up it gets its first pick with no conflict. If the > > > > one that was not preferred goes down, it comes up, sees a conflict and > > > > takes its second pick (loses the conflict every time). It is only if > > > > they both go down and the one that normally loses the conflict comes > > > > up first that there is a change in router-id. That too can be solved > > > > with a rule that you always come up with the last router-id used. > > > > > > > > Curtis > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > > > > > > Sent: Thursday, February 06, 2014 5:12 PM > > > > > > To: Curtis Villamizar > > > > > > Cc: OSPF List > > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- > > ospfv3- > > > > > > autoconfig-05.txt > > > > > > > > > > > > Hi Curtis, > > > > > > I agree and believe the significance of this use case where a new > > router > > > > is > > > > > > inserted into an auto-configured domain has been greater exaggerated. > > > > > > Thanks, > > > > > > Acee > > > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > > > wrote: > > > > > > > > > > > > > > > > > > > > In message > > > > > > > Acee Lindem writes: > > > > > > > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in the > > > > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). > > In > > > > > > >> the ISIS WG, there was a concern that the resolution of a > > duplicate > > > > > > >> system ID did not include the amount of time the router was > > > > > > >> operational when determining which router would need to choose a > > new > > > > > > >> router ID. With additional complexity, we could incorporate router > > > > > > >> uptime into the resolution process. One way to do this would be > > to: > > > > > > >> > > > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would > > include > > > > > > >> the uptime in seconds. > > > > > > >> > > > > > > >> 2. Use the Router Uptime TLV as the primary determinant in > > > > > > >> deciding which router must choose a new OSPFv3 Router > > > > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds apart > > are > > > > > > >> considered equal. > > > > > > >> > > > > > > >> 3. When an OSPFv3 Hello is received with a different link- > > local > > > > > > >> source address but a different router-id, unicast the > > OSPFv3 > > > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router > > > > > > >> resolution can proceed as in the case where it is received > > > > > > >> through the normal flooding process. This is somewhat of a > > > > > > >> hack as the we'd also need to accept OSPF Link State > > Updates > > > > > > >> from a neighbor that is not in Exchange State or greater. > > > > > > >> > > > > > > >> An alternative to #3 would be to use Link-Local Signaling (LLS) > > for > > > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only > > want > > > > > > >> to send the Router-Uptime and Router Hardware Fingerprint when a > > > > > > >> duplicate Router-ID is detected. This requires implementing the > > > > > > >> resolution two ways but may be preferable since it doesn't require > > > > > > >> violating the flooding rules. > > > > > > >> > > > > > > >> In any case, I'd like to get other opinions as to whether this > > problem > > > > > > >> is worth solving. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Acee > > > > > > > > > > > > > > > > > > > > > Acee, > > > > > > > > > > > > > > If the basis for router-id on boot up results in a fixed value, and > > if > > > > > > > a duplicate will occur on a give network, then which of two > > duplicate > > > > > > > routers gets that value may change after one of them reboots. If > > > > > > > uptime is not considered, it will never change as long as one > > router > > > > > > > stays up at any given time. > > > > > > > > > > > > > > We are talking about a very low probability event (a duplicate) > > except > > > > > > > if this is a DoS attack and then either using or not using uptime > > > > > > > won't matter since the attacker will claim an impossibly long > > uptime. > > > > > > > > > > > > > > Curtis From ginsberg@cisco.com Mon Feb 10 00:28: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 E24FC1A05D0 for ; Mon, 10 Feb 2014 00:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 bZVZFt1556DI for ; Mon, 10 Feb 2014 00:28:12 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4891A0068 for ; Mon, 10 Feb 2014 00:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25871; q=dns/txt; s=iport; t=1392020893; x=1393230493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ihcicxc/YG1x3UTFkzGHfpY4lXGI009jm6G78LwxBSM=; b=E5NRF/uJS5AkNXIVCza0JsoRb3Z7jYLbHW8c95q4XEENSs4R8SVtnccM tlcNI0wqoD6HLfXdjgYT2f/cGoxEfURA0mt1fSlZ3wheff/7mjpHbOZml rjVAupo6k7XptR5PcdbG4oBjmcoMfXk3nvNXwm3iDmTmwm49Z2KghV0x6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEuN+FKtJXG8/2dsb2JhbABQAwaDDDhXv02BChZ0giUBAQEDARogPwUHBAIBCBEEAQEBChQJBzIUCQgCBA4DAggBEgSHXggNyGMXjiINCxIGKwcCBIMegRQEjGKTDYpdgy1AgWo X-IronPort-AV: E=Sophos;i="4.95,816,1384300800"; d="scan'208";a="302966226" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 10 Feb 2014 08:28:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1A8SA6o031424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 08:28:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 02:28:10 -0600 From: "Les Ginsberg (ginsberg)" To: "curtis@ipv6.occnc.com" Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJdbs/pYRbYVsxUaPEbmLjnjkwpquHJhg Date: Mon, 10 Feb 2014 08:28:10 +0000 Message-ID: References: Your message of "Sat, 08 Feb 2014 18:24:14 +0000." <201402092038.s19KciP5015271@maildrop2.v6ds.occnc.com> In-Reply-To: <201402092038.s19KciP5015271@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 08:28:18 -0000 Curtis - I think we are converging. Some context from my side... I am fully aware that this draft is about Homenet environments, but there i= s a suspicion in the back of my mind that once the duplicate-id resolution = mechanism is defined and deployed that folks may want to use it in other en= vironments e.g. TRILL has targeted auto-config as a goal (just an example).= You may remember a few years ago a proposal to automatically resolve syste= m-id conflicts was discussed in IS-IS WG. The proposal had a lot of flaws a= nd we shot it down - but it does suggest that some folks may want to use su= ch a mechanism in other types of deployments someday. So I would like to de= fine things such that it is robust enough to be used elsewhere. And since w= hat I am proposing is quite simple I don't think it unduly burdens the Home= net environments. As regards preserving router-id across reboots - sure - that is a good idea= also. And what I am proposing is supportive of that because it guarantees = that so long as an existing router's LSAs are in the LSDB (even if it is cu= rrently undergoing maintenance) any new router that comes up (or even anoth= er old router that reboots and is not so well behaved as to remember the ro= uter-id it previously used) will not take the router-id of any router seen = in the LSDB (reachable or not). This is better than the existing logic whic= h leaves the decision to chance.=20 More inline. > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Sunday, February 09, 2014 12:39 PM > To: Les Ginsberg (ginsberg) > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 >=20 > Les, >=20 > Perhaps you should read the abstract of the document you are > commenting about: >=20 > SPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This > document describes the necessary mechanisms for OSPFv3 to be > self-configuring. >=20 > Home network! >=20 > Or the introductio: >=20 > OSPFv3 [OSPFV3] is a candidate for deployments in environments > where auto-configuration is a requirement. >=20 > [...] >=20 > 1.2. Acknowledgments >=20 > This specification was inspired by the work presented in the > Homenet working group meeting in October 2011 in Philadelphia, > Pennsylvania. >=20 > The Homenet WG works on what? Home networks! >=20 > So please keep that in mind when commenting. >=20 > Unless a provider were to be so stupid or lazy to use this on a SP > network then most of the comments from both of us don't apply, > *except* the few comments below about "in a home network". >=20 > Perhaps the draft should add text explicitly stating that the last > router-id used successfully should be used on a reboot rather than a > new random number. I notice that only the Router-Hardware-Fingerprint > TLV is persistent across reboots. This is insufficient if we want to > minimize disruption. >=20 > The only case then (if router-id is remembered across reboots) would > be a new router.=20 Also a router which fails to remember its old router-id across a reboot. > In that case your uptime rule would help. So > perhaps two things could be reocmmended: >=20 > 1. In section 4, include a "SHOULD remember the most recent > successfully used router-id across reboots and reuse that". > Reword the rest so if that information is not available, then > pick a random number. Fine with me. >=20 > 2. a. In section 6, mention the uptime rule. Modify the Router > Uptime TLV as suggested. >=20 > b. Alternately add a flag to the Router-Hardware-Fingerprint > TLV that indicates that since last reboot this router-id has > been used and acheived a "full state". A router just > rebooting would not have ever reached the full state before > noticing a conflict as long as the conflct check is run > before considering itself in the full state. Yes - this is what I had in mind. Also note we need a flag in hellos as wel= l - for which I had proposed using an option bit (or LLS if folks don't wan= t to consume an options bit). But what is your definition of "full state"? It cannot be just having reach= ed "full state" with a single neighbor as it is possible the first neighbor= that comes up might also be in the process of coming up itself and does no= t yet have the full LSDB. What I had in mind was a short but sufficient tim= e that if we had been up for that long we could be comfortable that our exi= stence was known network-wide. I had mentioned 20 minutes - but that was qu= ite a conservative number - I think we could safely be more aggressive (5 m= inutes??). Once that period had passed we set the flag and leave it set. An= d if we are smart enough to reuse the same router-id following reboot when = we get our own Fingerprint from our old incarnation we will see that the fl= ag is set and can therefore set it immediately following reboot without wai= ting for 5 minutes. The significance of the time interval is only to define the period during w= hich if we are unlucky enough to have two new routers come up within that i= nterval and happen to pick the same router-id that we will defer to the fin= gerprint/link local address tie breaker i.e. both routers are considered "n= ew" and so neither one has staked a claim yet. If you and I are now in consensus (as I think we are), it is time for the a= uthors of the draft to weigh in and if they agree update the draft with the= specifics. Les >=20 > Note: A second flag bit indicating that this router-id had > been used successfully in a past reboot might also help but > would only matter among two routers both rebooting and > neither having reached the full state. >=20 > I think #1 above is sufficient and does more to prevent surprises. I > think #2 above helps only in the new router case but #2a requires > adding a TLV and so isn't worth it IMHO. Case #2b accomplished the > same thing with only a flag. I would not object to #2b above if #1 > above is also added. >=20 > See inline anyway. >=20 > In message > "Les Ginsberg (ginsberg)" writes: > > > > Curtis - > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > Sent: Saturday, February 08, 2014 7:30 AM > > > To: Les Ginsberg (ginsberg) > > > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3= - > > > autoconfig-05.txt > > > > > > > > > In message x02.cisco.com> > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > Curtis - > > > > > > > > Your reply below is talking about things which I think do not direc= tly > > > > bear on the value add of what I have proposed. > > > > > > > > You mention various ways to insure that a given device assigns the > > > > same router-id each time it starts up and ways to insure it picks t= he > > > > same sequence of second/third... choices in the event it has to cha= nge > > > > its router-id. All good suggestions, but what I am talking about is > > > > what we do in the event a conflict occurs despite our best efforts = to > > > > avoid it. With the current draft content preference is based solely= on > > > > a fixed identifier (fingerprint) without regard to which choice wou= ld > > > > minimize disruption to the network. When preference is given to the > > > > "old router" to retain its existing router-id this shortcoming is > > > > addressed. > > > > > > In the lifetime of a router it only gets added once. In the lifetime > > > of a router we would hope it only reboots zero time but experience so > > > far has been that reboots over a router's lifetime tend to be > 0 and > > > in some cases >> 0. > > > > > > So you are optimizing for a 1 in 4 billion occurance that can happen > > > only once in the lifetime of a router. > > > > The entire duplicate router-id resolution logic is addressing the > > improbable case. My proposal adds - literally - one line of code to > > the logic used to decide whether "I" should change my router-id or > > whether "you" should change your router-id. > > > > > > > > We also need to look at the consequences of this very improbably > > > occurance. Today's routers accomplish IGP convergence in large > > > networks in subsecond times, in some cases << 1 second. > > > > > > Note that if flooding is completed (both withdraw old and install new= ) > > > in less than the SPF delay which is commonly implemented (some delay > > > after receiving the first flooded IGP change), then there is no impac= t > > > on routing. > > > > Your analysis does not apply to this scenario. The router which > > changes its router-id is effectively doing a cold start. All > > adjacencies will go down. All LSAs originated by this router become > > invalid. All routes will be removed from the forwarding plane. If > > you are running BGP all the BGP nexthops will be gone on the router > > which is changing its identity. Restoration of the adjacencies and > > reacquisition of the LSDB will take multiple seconds. The best you > > can hope for is several seconds of disruption - it could easily be > > much longer. > > > > For the new node which has usurped the old node's identity it will > > have to purge/replace all of the LSAs generated by the old > > node. While normal operation of the update process will insure that > > this happens in a reliable way the amount of flooding network-wide > > required to bringup a new node has now been roughly doubled > > i.e. the old node must reissue all of its LSAs using a new identity > > and the new node must purge/replace the old node's LSAs with its > > own versions. This will result in multiple SPFs on all nodes in the > > network and likely cause loops/blackholes during the transition > > since some of the SPFs will be run on versions of the LSDB which > > are inaccurate (part old node's old LSAs and part new node's > > LSAs). Suggesting that this could be handled in the same way/time > > as we typically handle a single link failure isn't credible. >=20 > All routers are supposed to keep a fixed router-id across reboots. If > interfaces are changed when down, the last used router-id should be on > flash. If flash is removed and replaced (rather than a new image > installed), then with the same set of interfaces, the same decision > should be made. We are down to a very special case where both flash > and interfaces are removed and replaced yielding no history and a > different set of MACs to pick from. >=20 > > > > Your statement that what I propose is only relevant when two router= s > > > > go down does not match the scenarios I envision. If I want to add a > > > > new device to my network or if I need to replace an existing device= in > > > > my network I am only affecting one device - but as I am introducing= a > > > > device with a new fingerprint it is possible that it will introduce= a > > > > conflict with an existing router-id. > > > > > > In provider networks routers are generally added during maintenance > > > windows so should anything unexpected happen, impact is minimized. > > > > > > In home nets, the home user isn't going to notice the convergence tim= e > > > if there is any. A 10 msec SPF delay is likely to be plenty. > > > > As I stated above, disruption will be orders of magnitude longer than 1= 0 > ms. >=20 > In a home net? With perhaps a half dozen routers and a default route? > Someone has a very bad OSPF implementation. :-) Or did you miss the > "In home nets" at the front of the paragraph. >=20 > For example, in a 10 node network with average degree 4, perhpas 40 > links in 10 router LSA exist. A few RTT (less than 1 msec for a > homenet) for each neighbor adjacency (which happen in parallel) and > ten packets from 4 sources is needed to reach the full state followed > by one SPF to be fully up and running. Other routers get one > additional router LSA plus four new links in existing router LSA and > have to run an SPF. Even on a software based homenet router using an > ARM, 10 msec is likely to be enough time and if it is "orders of > magnitude" longer, something is wrong with one of the implementations. > This would be an more complicated than usual home net or even soho, > more likely a small business. >=20 > > > > In a subsequent reply you liked the idea of the new device delaying > > > > advertising reachability until it is has determined that its router= -id > > > > choice is not in conflict. The old/new router paradigm supports thi= s > > > > strategy by assuring that the old router will not consider changing > > > > its router-id until enough time has elapsed for the new router to > > > > transition to being an old router. > > > > > > If it wins the coin toss, the router would advertise at least one LSA > > > to indicate its existance and could hold back on any additional > > > advertisements until the other router has withdrawn routes. > > > > > > > This suggestion does not alter the fact that if the old node changes > > > > its router-id the network has to respond to three events: > > > > 1)Loss of the old node > > 2)Introduction of the old-node with a new identity > > 3)Introduction of the new node with the identity of the old-node >=20 > Again, the old node should remember the last router-id used and try to > reuse it. >=20 > > If however we insure that the old-node does not change its identity > > then the network only has to respond to a single event - the > > introduction of the new-node. >=20 > Yes and if it were up and won the resolution last time, it will have > saved that router-id and will reuse it. If it came up previously and > lost the resolution, then it will remember the router-id it used, > whether second or third pick, and use that. >=20 > > > > Finally, what I propose is extremely simple to implement. I think i= t > > > > isn't much of an exaggeration to say that any one of us could have > > > > implemented the enhancement in the time it has taken to discuss its > > > > merits. So we aren't overengineering for a case which is admittedly > > > > very unlikely to occur - we are adding a modest extension to make o= ur > > > > solution less disruptive. > > > > > > Yes but it it *bad* for the more common case where routers go down > > > occasionally. > > > > You are going to have to clarify exactly what "bad side effects" you > > see for what I propose - because I don't see any - whereas I do > > see benefits as described above. >=20 > If router-id is not remembered between reboots, then there is the one > in 4 billion time number of routers (less than 10 for a home net > today, but maybe more in the future). >=20 > If router-id is remembered between reboots, then no matter how long a > router has been down, if nothing else in the network changed, there is > zero chance of having a collision. >=20 > With either method, if router-id is remembered between reboots, then > there is zero chance of collision. >=20 > IMO should this ever be used on a managed network (including a home > net / soho / small business net that happens to be managed) then > having routers come back from a reboot with the same router-ids would > be a big plus. For example, after a power outage NMS discovery would > not have to be repeated. >=20 > > Les > > > > > > > > > > > Les > > > > > > Curtis > > > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > > Sent: Friday, February 07, 2014 9:22 AM > > > > > To: Les Ginsberg (ginsberg) > > > > > Cc: Acee Lindem; Curtis Villamizar; OSPF List > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- > ospfv3- > > > > > autoconfig-05.txt > > > > > > > > > > > > > > > In message > > x02.cisco.com> > > > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > > > > > So, I am one person who raised this concern to Acee - but the > proposal > > > > > > outlined by Acee is not what I had in mind. There is no need to= use > > > > > > "uptime" or to invent some unusual exchange of LSAs prior to > Exchange > > > > > > state. > > > > > > > > > > > > Also, in regards to Curtis's comment - it is not DOS attacks th= at I > am > > > > > > trying to mitigate here. As he says if an attacker is in your > network > > > > > > and able to originate credible packets no strategy is safe. > > > > > > > > > > > > The motivating use case is to minimize disruption of a stable > network > > > > > > when a new router is added or an existing router is > > > > > > replaced/rebooted. In other words non-disruptive handling of th= e > > > > > > common maintenance/upgrade scenarios. > > > > > > > > > > > > What I have in mind is this: > > > > > > > > > > > > 1) A router needs a way to advertise that it has been up and > running > > > > > > for a minimum length of time - for the sake of discussion le= t's > say > > > > > > 20 minutes. Routers then fall into two categories: > > > > > > > > > > > > o Old routers (up >=3D minimum time) > > > > > > o New routers (up < minimum time) > > > > > > > > > > > > 2) When a duplicate router-id is detected, the first tie breake= r is > > > > > > between old routers and new routers. The old router gets to = keep > > > > > > its router-id and the new router picks a new router-id. If = both > > > > > > routers are "new" or both routers are "old" then we revert t= o > the > > > > > > existing tie breakers defined in the document (link local > address > > > > > > for directly connected routers and fingerprint info for > > > > > > non-neighbors). > > > > > > > > > > > > 3) Advertisement of the "old/new" state requires a single bit -= but > it > > > > > > has to be available both in hellos and the new AC-LSA. Addin= g it > to > > > > > > the AC-LSA is easy to do. For hellos, there are two > possibilities: > > > > > > > > > > > > o Use one of the Options Bits > > > > > > o Use LLS > > > > > > > > > > > > Be interested in how folks feel about this. > > > > > > > > > > > > Les > > > > > > > > > > > > > > > Les, > > > > > > > > > > Excluding DoS attack, we are talking about a one in 4 billion cas= e > > > > > (for any two routers, so with 400 routers, still well under one i= n > 1M) > > > > > where two routers hash a MAC address or pick a one time random nu= mber > > > > > from out of nowhere and end up with the same number. > > > > > > > > > > If that does happen (and one in 1M is certainly possible), then i= t > > > > > would be nice if the routers always ended up with the same router= -id. > > > > > This could be accomplished by some fixed method such as hashing a > > > > > constant with the first choice or router-id or using the router-i= d as > > > > > a seed for the random number generator (which will pick the same > > > > > sequence of random numbers each time). If this is done, then a > > > > > conflict would always produce the same set of next picks. The se= t of > > > > > routers in a given network would always end up with the same > > > > > router-ids once they all came up and if only one went down at a t= ime > > > > > then it would always end up with the same router-id when it came = up. > > > > > > > > > > Zero conf was mainly intended for unmanaged networks (motivated b= y > > > > > work in the homenet WG). In these small unmanaged networks it > doesn't > > > > > matter which router gets what router-id as long as they end up un= ique > > > > > and convergence is in a reasonable time relative to keeping eyeba= lls > > > > > happy. It could be applied to enterprise or providers but in eit= her > > > > > case having the routers end up with the same router-ids would mak= e > for > > > > > easier management. > > > > > > > > > > For your scenario to matter at all with current rules, both route= rs > in > > > > > the conflict would have to go down. If only the one that is > preferred > > > > > goes down, the other is not going to change its router-id as a re= sult > > > > > so when it comes up it gets its first pick with no conflict. If = the > > > > > one that was not preferred goes down, it comes up, sees a conflic= t > and > > > > > takes its second pick (loses the conflict every time). It is onl= y if > > > > > they both go down and the one that normally loses the conflict co= mes > > > > > up first that there is a change in router-id. That too can be so= lved > > > > > with a rule that you always come up with the last router-id used. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee > Lindem > > > > > > > Sent: Thursday, February 06, 2014 5:12 PM > > > > > > > To: Curtis Villamizar > > > > > > > Cc: OSPF List > > > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-osp= f- > > > ospfv3- > > > > > > > autoconfig-05.txt > > > > > > > > > > > > > > Hi Curtis, > > > > > > > I agree and believe the significance of this use case where a= new > > > router > > > > > is > > > > > > > inserted into an auto-configured domain has been greater > exaggerated. > > > > > > > Thanks, > > > > > > > Acee > > > > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > In message > > > > > > > > Acee Lindem writes: > > > > > > > > > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presente= d in > the > > > > > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf- > 00.txt). > > > In > > > > > > > >> the ISIS WG, there was a concern that the resolution of a > > > duplicate > > > > > > > >> system ID did not include the amount of time the router wa= s > > > > > > > >> operational when determining which router would need to ch= oose > a > > > new > > > > > > > >> router ID. With additional complexity, we could incorporat= e > router > > > > > > > >> uptime into the resolution process. One way to do this wou= ld > be > > > to: > > > > > > > >> > > > > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It wo= uld > > > include > > > > > > > >> the uptime in seconds. > > > > > > > >> > > > > > > > >> 2. Use the Router Uptime TLV as the primary determinan= t in > > > > > > > >> deciding which router must choose a new OSPFv3 Rout= er > > > > > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds > apart > > > are > > > > > > > >> considered equal. > > > > > > > >> > > > > > > > >> 3. When an OSPFv3 Hello is received with a different l= ink- > > > local > > > > > > > >> source address but a different router-id, unicast the > > > OSPFv3 > > > > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate > router > > > > > > > >> resolution can proceed as in the case where it is > received > > > > > > > >> through the normal flooding process. This is somewhat > of a > > > > > > > >> hack as the we'd also need to accept OSPF Link State > > > Updates > > > > > > > >> from a neighbor that is not in Exchange State or > greater. > > > > > > > >> > > > > > > > >> An alternative to #3 would be to use Link-Local Signaling > (LLS) > > > for > > > > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'= d > only > > > want > > > > > > > >> to send the Router-Uptime and Router Hardware Fingerprint = when > a > > > > > > > >> duplicate Router-ID is detected. This requires implementin= g > the > > > > > > > >> resolution two ways but may be preferable since it doesn't > require > > > > > > > >> violating the flooding rules. > > > > > > > >> > > > > > > > >> In any case, I'd like to get other opinions as to whether = this > > > problem > > > > > > > >> is worth solving. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> Acee > > > > > > > > > > > > > > > > > > > > > > > > Acee, > > > > > > > > > > > > > > > > If the basis for router-id on boot up results in a fixed va= lue, > and > > > if > > > > > > > > a duplicate will occur on a give network, then which of two > > > duplicate > > > > > > > > routers gets that value may change after one of them reboot= s. > If > > > > > > > > uptime is not considered, it will never change as long as o= ne > > > router > > > > > > > > stays up at any given time. > > > > > > > > > > > > > > > > We are talking about a very low probability event (a duplic= ate) > > > except > > > > > > > > if this is a DoS attack and then either using or not using > uptime > > > > > > > > won't matter since the attacker will claim an impossibly lo= ng > > > uptime. > > > > > > > > > > > > > > > > Curtis From rja.lists@gmail.com Mon Feb 10 11:42:39 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 9E7C91A0886 for ; Mon, 10 Feb 2014 11:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 TnFUj0-fgPFC for ; Mon, 10 Feb 2014 11:42:32 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 06AF61A087D for ; Mon, 10 Feb 2014 11:42:31 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so10136521qae.41 for ; Mon, 10 Feb 2014 11:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:resent-from:date :content-transfer-encoding:resent-date:resent-to:message-id:to; bh=UFRBh5Ot4jkUnf7za/i6Kg89VebDO7At7KngKfQpBBw=; b=HKYu7ha5eDCkV63SS8+POp/3ij0gsioVoxCzxHfpoffnaY1nFNwZTSD2FNy/vNifj2 Ukl2dd81hIwZikdhmstkyn3o2ds4dcDUzu9Cw+rwoE8DzOX5vsPd0XDtTjPPsuhW0Pp8 hLpb6SXhx1W+k03KnKAbUNw3P1Fv8ZwwKvKCXz/C0060At6HvDaSBjZ1iTRF3LE31mcY NgUWwoczaVSazFw3gUmEwsw7vj35pFxNQ7nmGefW9ZekA/lQg5HcmE0pQsdbqXBpxh3h 0I7+z39p5y2XlpC+Xg2lxhIsHXlor+PKkmIeixco1nTqhFS57LZROBKa3ruuhJYKlXrd vs7A== X-Received: by 10.140.30.66 with SMTP id c60mr47542442qgc.13.1392061351683; Mon, 10 Feb 2014 11:42:31 -0800 (PST) Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id d7sm45592936qad.10.2014.02.10.11.42.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 11:42:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson Resent-From: RJ Atkinson Date: Mon, 10 Feb 2014 14:33:05 -0500 Content-Transfer-Encoding: quoted-printable Resent-Date: Mon, 10 Feb 2014 14:42:30 -0500 Resent-To: ospf@ietf.org Message-Id: To: ospf@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:42:39 -0000 Earlier, Karsten Thomann wrote, in part: > I don't know if i have missed that part, but what would happen if = OSPFv3=20 > is running over IPv4 and there are two (or more) IPv6 Islands already = deployed=20 > within the network, should there be any LSA flooding checks, like do = not flood=20 > LSA with IPv6 networks over IPv4 only links, or should the route=20 > calculation/installation of the information simply fail=20 > as there is no valid path? The OSPF deployments I am familiar with did not "auto deploy" or "self deploy". Instead, all of the OSPF deployments that I am familiar with had engineers making deliberate decisions about how to configure the OSPF deployment, and also how to configure the OSPF routers in that deployment. One deployment option, already deployed in some places, is to run "ships in the night". In this model, the IPv4 topology exclusively uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3 over IPv6. For some sites, that is a good option. A number of my clients are very interested in this new I-D because it optimises their IPv6 transition strategy. For some sites, IPv6 transition is simplified, optimised, and also cost-reduced by using OSPFv3 over IPv4 initially, and carrying both=20 IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment=20 (i.e. using the Address Family extension to keep the prefixes clearly=20 differentiated within a single OSPFv3 deployment). This can lower operational costs because one can get by with managing only OSPFv3, rather than having to manage both OSPFv2 and OSPFv3. If one's "IPv6 islands" (to use your term) are really dual-stack (aside: having dual-stack rather than IPv6-only would be expected and normal if another part of one's OSPF deployment is using=20 OSPF over IPv4), then EITHER the whole deployment should be configured=20= to run over IPv4 XOR the whole deployment should be configured=20 to run over IPv6. =20 Having different "IPv4 islands" and "IPv6 islands" is an explicit choice=20= of a configuration engineer or design engineer. That probably is not=20 the optimal deployment choice for an engineer to make. It definitely=20 is NOT a choice that I would make or that I would recommend to my = clients. =46rom the descriptions and definitions in the draft, it would not be=20 "normal" or "expected" to mix IPv6 transport with IPv4 transport within a single OSPFv3 deployment. > Is there any explicit preference over which version the adjacency=20 > is build if v4 and v6 is available in that specific part of the = network? The choice of preferred OSPF transport really is something that the=20 configuration engineer ought to configure. As the details of = configuring=20 any IP router are outside the scope of the IETF, I am not sure that=20 this I-D properly can or should say very more than it already says. Perhaps the I-D could add clarifying text along these lines somewhere in Section 2: "Implementers of OSPFv3 over IPv4 SHOULD add a configuration knob to let the router administrator select whether a given OSPFv3-enabled interface should use OSPFv3 over IPv4 or=20 OSPFv3 over IPv6. Except when an OSPFv3 deployment is being=20 transitioned from using IPv4 transmission to using IPv6=20 transmission, it is RECOMMENDED that all routers within an=20 OSPFv3 deployment use the same IP version for OSPFv3 packet=20 transmission." > What should happen when an IPv4 Link gets v6 added, graceful = reestablish=20 > the adjacency over IPv6, or wait until forced protocol switch? See my answer just above. =20 I would expect that any router that implements this I-D also would = implement=20 a configuration knob to indicate whether IPv4 transmission or IPv6 = transmission=20 is preferred. Over time, a configuration engineer might change this=20 (e.g. manually change from IPv4 transmission to IPv6 transmission AFTER=20= an entire IPv4 network has been deployed-with/converted-to dual-stack IPv4 and IPv6). Yours, Ran Atkinson From curtis@ipv6.occnc.com Mon Feb 10 13:13:18 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 C61291A05D2 for ; Mon, 10 Feb 2014 13:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J4KTyZ2R84o for ; Mon, 10 Feb 2014 13:13:13 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C553D1A0407 for ; Mon, 10 Feb 2014 13:13:03 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1AK3PQZ034418; Mon, 10 Feb 2014 15:03:25 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402102003.s1AK3PQZ034418@maildrop2.v6ds.occnc.com> To: "Les Ginsberg (ginsberg)" From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Feb 2014 08:28:10 +0000." Date: Mon, 10 Feb 2014 15:03:24 -0500 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:13:19 -0000 In message "Les Ginsberg (ginsberg)" writes: > Curtis - > > I think we are converging. > > Some context from my side... > > I am fully aware that this draft is about Homenet environments, but > there is a suspicion in the back of my mind that once the duplicate-id > resolution mechanism is defined and deployed that folks may want to > use it in other environments e.g. TRILL has targeted auto-config as a > goal (just an example). You may remember a few years ago a proposal to > automatically resolve system-id conflicts was discussed in IS-IS > WG. The proposal had a lot of flaws and we shot it down - but it does > suggest that some folks may want to use such a mechanism in other > types of deployments someday. So I would like to define things such > that it is robust enough to be used elsewhere. And since what I am > proposing is quite simple I don't think it unduly burdens the Homenet > environments. Providers tend to configure anything that is expected to be static. At least the smart ones do. But then maybe smart people don't run trill. :-) I think the prior IS-IS autoconfig may have been motivated by IEEE use of IS-IS for bridging. Again, not something providers use. > As regards preserving router-id across reboots - sure - that is a good > idea also. And what I am proposing is supportive of that because it > guarantees that so long as an existing router's LSAs are in the LSDB > (even if it is currently undergoing maintenance) any new router that > comes up (or even another old router that reboots and is not so well > behaved as to remember the router-id it previously used) will not take > the router-id of any router seen in the LSDB (reachable or not). This > is better than the existing logic which leaves the decision to chance. The router today that can't remember anything between reboots is likely to be a very low end home networking device with no non-volitile strorage at all. Anything running OSPF or ISIS is likely to be at least keeping a code image in flash and could keep a router-id there too. > More inline. > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > Sent: Sunday, February 09, 2014 12:39 PM > > To: Les Ginsberg (ginsberg) > > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > autoconfig-05.txt > > > > > > Les, > > > > Perhaps you should read the abstract of the document you are > > commenting about: > > > > SPFv3 is a candidate for deployments in environments where auto- > > configuration is a requirement. One such environment is the IPv6 > > home network where users expect to simply plug in a router and have > > it automatically use OSPFv3 for intra-domain routing. This > > document describes the necessary mechanisms for OSPFv3 to be > > self-configuring. > > > > Home network! > > > > Or the introductio: > > > > OSPFv3 [OSPFV3] is a candidate for deployments in environments > > where auto-configuration is a requirement. > > > > [...] > > > > 1.2. Acknowledgments > > > > This specification was inspired by the work presented in the > > Homenet working group meeting in October 2011 in Philadelphia, > > Pennsylvania. > > > > The Homenet WG works on what? Home networks! > > > > So please keep that in mind when commenting. > > > > Unless a provider were to be so stupid or lazy to use this on a SP > > network then most of the comments from both of us don't apply, > > *except* the few comments below about "in a home network". > > > > Perhaps the draft should add text explicitly stating that the last > > router-id used successfully should be used on a reboot rather than a > > new random number. I notice that only the Router-Hardware-Fingerprint > > TLV is persistent across reboots. This is insufficient if we want to > > minimize disruption. > > > > The only case then (if router-id is remembered across reboots) would > > be a new router. > > Also a router which fails to remember its old router-id across a reboot. See above. Seems very broken to not be able to remember a router-id across reboot. What today doesn't have any flash at all? If anything, what in an SP net? (nothing). > > In that case your uptime rule would help. So > > perhaps two things could be reocmmended: > > > > 1. In section 4, include a "SHOULD remember the most recent > > successfully used router-id across reboots and reuse that". > > Reword the rest so if that information is not available, then > > pick a random number. > > Fine with me. > > > > > 2. a. In section 6, mention the uptime rule. Modify the Router > > Uptime TLV as suggested. > > > > b. Alternately add a flag to the Router-Hardware-Fingerprint > > TLV that indicates that since last reboot this router-id has > > been used and acheived a "full state". A router just > > rebooting would not have ever reached the full state before > > noticing a conflict as long as the conflct check is run > > before considering itself in the full state. > > Yes - this is what I had in mind. Also note we need a flag in hellos > as well - for which I had proposed using an option bit (or LLS if > folks don't want to consume an options bit). I'm not sure for OSPF at least why you need a flag in hello. > But what is your definition of "full state"? It cannot be just having > reached "full state" with a single neighbor as it is possible the > first neighbor that comes up might also be in the process of coming up > itself and does not yet have the full LSDB. What I had in mind was a > short but sufficient time that if we had been up for that long we > could be comfortable that our existence was known network-wide. I had > mentioned 20 minutes - but that was quite a conservative number - I > think we could safely be more aggressive (5 minutes??). Once that > period had passed we set the flag and leave it set. And if we are > smart enough to reuse the same router-id following reboot when we get > our own Fingerprint from our old incarnation we will see that the flag > is set and can therefore set it immediately following reboot without > waiting for 5 minutes. The full state is a state in OSPF when the LSDB download between a pair of routers has completed. The assumption is that we have a "full state" bit in the Router-Hardware-Fingerprint TLV defined above. Taking in your concern over becoming full with another router that doesn't have a full LSDB, procedure when the router is not full is then: 1. An adjacency becomes "full" (formal state in OSPF). 2. Check to see if the neighbor router is "full" in its Router-Hardware-Fingerprint TLV: a. If not, and other neighbor adjacncies are not in the full state wait for others neighbor states to become full. b. If all neighbor adjacencies are in the full state, and none of the neighbor routers is in the full state in its Router-Hardware-Fingerprint TLV, then continue. c. If the neighbor's Router-Hardware-Fingerprint TLV indicates the full state, continue. 3. Check for router-id collisions. a. If no collision, set full and done. b. If a collision, continue. 4. Check the flags in the Router-Hardware-Fingerprint TLV of the router for which a collision has occurred. a. If the collision is with a full router, then pick new router-id and start over. b. If the collision is with a router that is marked as having been use successfully in the past and the router-id being used by this router was a random pick, then pick new router-id and start over. c. Otherwise it is a tie and continue. 5. In the event of a tie, use the tie breaker rules as defined in the existing draft (lowest fingerprint wins). Don't readvertise any LSDB entry from a neighbor router until it resends its Router-Hardware-Fingerprint TLV with the full state indicated. This will avoid a collision prior to the newly rebooted router reaching the full state and possibly giving up on its first pick or router-id. If a neighbor for which the adjacency is in the full state indicates that it has become "full", go to step 3 if not already in the full state. Note that 2b covers the case where no router in the entire network has declared itself in the full state (the network epoch). 2a covers most cases where the neighor has a partial LSDB. This could have been a bit simpler if we didn't want to cover most cases where the neighbor didn't have a full LSDB. > The significance of the time interval is only to define the period > during which if we are unlucky enough to have two new routers come up > within that interval and happen to pick the same router-id that we > will defer to the fingerprint/link local address tie breaker i.e. both > routers are considered "new" and so neither one has staked a claim > yet. The above can do this without a time interval. With just flag bits, there is no need to readvertise any LSA to update a time interval, only a need to update the "full state" bit after getting to the full state. > If you and I are now in consensus (as I think we are), it is time for > the authors of the draft to weigh in and if they agree update the > draft with the specifics. > > Les Very rough concensus but only that the problem is easily solvable, not on the specific solution. Curtis > > Note: A second flag bit indicating that this router-id had > > been used successfully in a past reboot might also help but > > would only matter among two routers both rebooting and > > neither having reached the full state. > > > > I think #1 above is sufficient and does more to prevent surprises. I > > think #2 above helps only in the new router case but #2a requires > > adding a TLV and so isn't worth it IMHO. Case #2b accomplished the > > same thing with only a flag. I would not object to #2b above if #1 > > above is also added. > > > > See inline anyway. > > > > In message > > "Les Ginsberg (ginsberg)" writes: > > > > > > Curtis - > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > Sent: Saturday, February 08, 2014 7:30 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > > > > autoconfig-05.txt > > > > > > > > > > > > In message > x02.cisco.com> > > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > > Curtis - > > > > > > > > > > Your reply below is talking about things which I think do not directly > > > > > bear on the value add of what I have proposed. > > > > > > > > > > You mention various ways to insure that a given device assigns the > > > > > same router-id each time it starts up and ways to insure it picks the > > > > > same sequence of second/third... choices in the event it has to change > > > > > its router-id. All good suggestions, but what I am talking about is > > > > > what we do in the event a conflict occurs despite our best efforts to > > > > > avoid it. With the current draft content preference is based solely on > > > > > a fixed identifier (fingerprint) without regard to which choice would > > > > > minimize disruption to the network. When preference is given to the > > > > > "old router" to retain its existing router-id this shortcoming is > > > > > addressed. > > > > > > > > In the lifetime of a router it only gets added once. In the lifetime > > > > of a router we would hope it only reboots zero time but experience so > > > > far has been that reboots over a router's lifetime tend to be > 0 and > > > > in some cases >> 0. > > > > > > > > So you are optimizing for a 1 in 4 billion occurance that can happen > > > > only once in the lifetime of a router. > > > > > > The entire duplicate router-id resolution logic is addressing the > > > improbable case. My proposal adds - literally - one line of code to > > > the logic used to decide whether "I" should change my router-id or > > > whether "you" should change your router-id. > > > > > > > > > > > We also need to look at the consequences of this very improbably > > > > occurance. Today's routers accomplish IGP convergence in large > > > > networks in subsecond times, in some cases << 1 second. > > > > > > > > Note that if flooding is completed (both withdraw old and install new) > > > > in less than the SPF delay which is commonly implemented (some delay > > > > after receiving the first flooded IGP change), then there is no impact > > > > on routing. > > > > > > Your analysis does not apply to this scenario. The router which > > > changes its router-id is effectively doing a cold start. All > > > adjacencies will go down. All LSAs originated by this router become > > > invalid. All routes will be removed from the forwarding plane. If > > > you are running BGP all the BGP nexthops will be gone on the router > > > which is changing its identity. Restoration of the adjacencies and > > > reacquisition of the LSDB will take multiple seconds. The best you > > > can hope for is several seconds of disruption - it could easily be > > > much longer. > > > > > > For the new node which has usurped the old node's identity it will > > > have to purge/replace all of the LSAs generated by the old > > > node. While normal operation of the update process will insure that > > > this happens in a reliable way the amount of flooding network-wide > > > required to bringup a new node has now been roughly doubled > > > i.e. the old node must reissue all of its LSAs using a new identity > > > and the new node must purge/replace the old node's LSAs with its > > > own versions. This will result in multiple SPFs on all nodes in the > > > network and likely cause loops/blackholes during the transition > > > since some of the SPFs will be run on versions of the LSDB which > > > are inaccurate (part old node's old LSAs and part new node's > > > LSAs). Suggesting that this could be handled in the same way/time > > > as we typically handle a single link failure isn't credible. > > > > All routers are supposed to keep a fixed router-id across reboots. If > > interfaces are changed when down, the last used router-id should be on > > flash. If flash is removed and replaced (rather than a new image > > installed), then with the same set of interfaces, the same decision > > should be made. We are down to a very special case where both flash > > and interfaces are removed and replaced yielding no history and a > > different set of MACs to pick from. > > > > > > > Your statement that what I propose is only relevant when two routers > > > > > go down does not match the scenarios I envision. If I want to add a > > > > > new device to my network or if I need to replace an existing device in > > > > > my network I am only affecting one device - but as I am introducing a > > > > > device with a new fingerprint it is possible that it will introduce a > > > > > conflict with an existing router-id. > > > > > > > > In provider networks routers are generally added during maintenance > > > > windows so should anything unexpected happen, impact is minimized. > > > > > > > > In home nets, the home user isn't going to notice the convergence time > > > > if there is any. A 10 msec SPF delay is likely to be plenty. > > > > > > As I stated above, disruption will be orders of magnitude longer than 10 > > ms. > > > > In a home net? With perhaps a half dozen routers and a default route? > > Someone has a very bad OSPF implementation. :-) Or did you miss the > > "In home nets" at the front of the paragraph. > > > > For example, in a 10 node network with average degree 4, perhpas 40 > > links in 10 router LSA exist. A few RTT (less than 1 msec for a > > homenet) for each neighbor adjacency (which happen in parallel) and > > ten packets from 4 sources is needed to reach the full state followed > > by one SPF to be fully up and running. Other routers get one > > additional router LSA plus four new links in existing router LSA and > > have to run an SPF. Even on a software based homenet router using an > > ARM, 10 msec is likely to be enough time and if it is "orders of > > magnitude" longer, something is wrong with one of the implementations. > > This would be an more complicated than usual home net or even soho, > > more likely a small business. > > > > > > > In a subsequent reply you liked the idea of the new device delaying > > > > > advertising reachability until it is has determined that its router-id > > > > > choice is not in conflict. The old/new router paradigm supports this > > > > > strategy by assuring that the old router will not consider changing > > > > > its router-id until enough time has elapsed for the new router to > > > > > transition to being an old router. > > > > > > > > If it wins the coin toss, the router would advertise at least one LSA > > > > to indicate its existance and could hold back on any additional > > > > advertisements until the other router has withdrawn routes. > > > > > > > > > > This suggestion does not alter the fact that if the old node changes > > > > > its router-id the network has to respond to three events: > > > > > > 1)Loss of the old node > > > 2)Introduction of the old-node with a new identity > > > 3)Introduction of the new node with the identity of the old-node > > > > Again, the old node should remember the last router-id used and try to > > reuse it. > > > > > If however we insure that the old-node does not change its identity > > > then the network only has to respond to a single event - the > > > introduction of the new-node. > > > > Yes and if it were up and won the resolution last time, it will have > > saved that router-id and will reuse it. If it came up previously and > > lost the resolution, then it will remember the router-id it used, > > whether second or third pick, and use that. > > > > > > > Finally, what I propose is extremely simple to implement. I think it > > > > > isn't much of an exaggeration to say that any one of us could have > > > > > implemented the enhancement in the time it has taken to discuss its > > > > > merits. So we aren't overengineering for a case which is admittedly > > > > > very unlikely to occur - we are adding a modest extension to make our > > > > > solution less disruptive. > > > > > > > > Yes but it it *bad* for the more common case where routers go down > > > > occasionally. > > > > > > You are going to have to clarify exactly what "bad side effects" you > > > see for what I propose - because I don't see any - whereas I do > > > see benefits as described above. > > > > If router-id is not remembered between reboots, then there is the one > > in 4 billion time number of routers (less than 10 for a home net > > today, but maybe more in the future). > > > > If router-id is remembered between reboots, then no matter how long a > > router has been down, if nothing else in the network changed, there is > > zero chance of having a collision. > > > > With either method, if router-id is remembered between reboots, then > > there is zero chance of collision. > > > > IMO should this ever be used on a managed network (including a home > > net / soho / small business net that happens to be managed) then > > having routers come back from a reboot with the same router-ids would > > be a big plus. For example, after a power outage NMS discovery would > > not have to be repeated. > > > > > Les > > > > > > > > > > > > > > > Les > > > > > > > > Curtis > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > > > Sent: Friday, February 07, 2014 9:22 AM > > > > > > To: Les Ginsberg (ginsberg) > > > > > > Cc: Acee Lindem; Curtis Villamizar; OSPF List > > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- > > ospfv3- > > > > > > autoconfig-05.txt > > > > > > > > > > > > > > > > > > In message > > > x02.cisco.com> > > > > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > > > > > > > So, I am one person who raised this concern to Acee - but the > > proposal > > > > > > > outlined by Acee is not what I had in mind. There is no need to use > > > > > > > "uptime" or to invent some unusual exchange of LSAs prior to > > Exchange > > > > > > > state. > > > > > > > > > > > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I > > am > > > > > > > trying to mitigate here. As he says if an attacker is in your > > network > > > > > > > and able to originate credible packets no strategy is safe. > > > > > > > > > > > > > > The motivating use case is to minimize disruption of a stable > > network > > > > > > > when a new router is added or an existing router is > > > > > > > replaced/rebooted. In other words non-disruptive handling of the > > > > > > > common maintenance/upgrade scenarios. > > > > > > > > > > > > > > What I have in mind is this: > > > > > > > > > > > > > > 1) A router needs a way to advertise that it has been up and > > running > > > > > > > for a minimum length of time - for the sake of discussion let's > > say > > > > > > > 20 minutes. Routers then fall into two categories: > > > > > > > > > > > > > > o Old routers (up >= minimum time) > > > > > > > o New routers (up < minimum time) > > > > > > > > > > > > > > 2) When a duplicate router-id is detected, the first tie breaker is > > > > > > > between old routers and new routers. The old router gets to keep > > > > > > > its router-id and the new router picks a new router-id. If both > > > > > > > routers are "new" or both routers are "old" then we revert to > > the > > > > > > > existing tie breakers defined in the document (link local > > address > > > > > > > for directly connected routers and fingerprint info for > > > > > > > non-neighbors). > > > > > > > > > > > > > > 3) Advertisement of the "old/new" state requires a single bit - but > > it > > > > > > > has to be available both in hellos and the new AC-LSA. Adding it > > to > > > > > > > the AC-LSA is easy to do. For hellos, there are two > > possibilities: > > > > > > > > > > > > > > o Use one of the Options Bits > > > > > > > o Use LLS > > > > > > > > > > > > > > Be interested in how folks feel about this. > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > Les, > > > > > > > > > > > > Excluding DoS attack, we are talking about a one in 4 billion case > > > > > > (for any two routers, so with 400 routers, still well under one in > > 1M) > > > > > > where two routers hash a MAC address or pick a one time random number > > > > > > from out of nowhere and end up with the same number. > > > > > > > > > > > > If that does happen (and one in 1M is certainly possible), then it > > > > > > would be nice if the routers always ended up with the same router-id. > > > > > > This could be accomplished by some fixed method such as hashing a > > > > > > constant with the first choice or router-id or using the router-id as > > > > > > a seed for the random number generator (which will pick the same > > > > > > sequence of random numbers each time). If this is done, then a > > > > > > conflict would always produce the same set of next picks. The set of > > > > > > routers in a given network would always end up with the same > > > > > > router-ids once they all came up and if only one went down at a time > > > > > > then it would always end up with the same router-id when it came up. > > > > > > > > > > > > Zero conf was mainly intended for unmanaged networks (motivated by > > > > > > work in the homenet WG). In these small unmanaged networks it > > doesn't > > > > > > matter which router gets what router-id as long as they end up unique > > > > > > and convergence is in a reasonable time relative to keeping eyeballs > > > > > > happy. It could be applied to enterprise or providers but in either > > > > > > case having the routers end up with the same router-ids would make > > for > > > > > > easier management. > > > > > > > > > > > > For your scenario to matter at all with current rules, both routers > > in > > > > > > the conflict would have to go down. If only the one that is > > preferred > > > > > > goes down, the other is not going to change its router-id as a result > > > > > > so when it comes up it gets its first pick with no conflict. If the > > > > > > one that was not preferred goes down, it comes up, sees a conflict > > and > > > > > > takes its second pick (loses the conflict every time). It is only if > > > > > > they both go down and the one that normally loses the conflict comes > > > > > > up first that there is a change in router-id. That too can be solved > > > > > > with a rule that you always come up with the last router-id used. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee > > Lindem > > > > > > > > Sent: Thursday, February 06, 2014 5:12 PM > > > > > > > > To: Curtis Villamizar > > > > > > > > Cc: OSPF List > > > > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- > > > > ospfv3- > > > > > > > > autoconfig-05.txt > > > > > > > > > > > > > > > > Hi Curtis, > > > > > > > > I agree and believe the significance of this use case where a new > > > > router > > > > > > is > > > > > > > > inserted into an auto-configured domain has been greater > > exaggerated. > > > > > > > > Thanks, > > > > > > > > Acee > > > > > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > In message > > > > > > > > > Acee Lindem writes: > > > > > > > > > > > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and presented in > > the > > > > > > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf- > > 00.txt). > > > > In > > > > > > > > >> the ISIS WG, there was a concern that the resolution of a > > > > duplicate > > > > > > > > >> system ID did not include the amount of time the router was > > > > > > > > >> operational when determining which router would need to choose > > a > > > > new > > > > > > > > >> router ID. With additional complexity, we could incorporate > > router > > > > > > > > >> uptime into the resolution process. One way to do this would > > be > > > > to: > > > > > > > > >> > > > > > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would > > > > include > > > > > > > > >> the uptime in seconds. > > > > > > > > >> > > > > > > > > >> 2. Use the Router Uptime TLV as the primary determinant in > > > > > > > > >> deciding which router must choose a new OSPFv3 Router > > > > > > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds > > apart > > > > are > > > > > > > > >> considered equal. > > > > > > > > >> > > > > > > > > >> 3. When an OSPFv3 Hello is received with a different link- > > > > local > > > > > > > > >> source address but a different router-id, unicast the > > > > OSPFv3 > > > > > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate > > router > > > > > > > > >> resolution can proceed as in the case where it is > > received > > > > > > > > >> through the normal flooding process. This is somewhat > > of a > > > > > > > > >> hack as the we'd also need to accept OSPF Link State > > > > Updates > > > > > > > > >> from a neighbor that is not in Exchange State or > > greater. > > > > > > > > >> > > > > > > > > >> An alternative to #3 would be to use Link-Local Signaling > > (LLS) > > > > for > > > > > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, you'd > > only > > > > want > > > > > > > > >> to send the Router-Uptime and Router Hardware Fingerprint when > > a > > > > > > > > >> duplicate Router-ID is detected. This requires implementing > > the > > > > > > > > >> resolution two ways but may be preferable since it doesn't > > require > > > > > > > > >> violating the flooding rules. > > > > > > > > >> > > > > > > > > >> In any case, I'd like to get other opinions as to whether this > > > > problem > > > > > > > > >> is worth solving. > > > > > > > > >> > > > > > > > > >> Thanks, > > > > > > > > >> Acee > > > > > > > > > > > > > > > > > > > > > > > > > > > Acee, > > > > > > > > > > > > > > > > > > If the basis for router-id on boot up results in a fixed value, > > and > > > > if > > > > > > > > > a duplicate will occur on a give network, then which of two > > > > duplicate > > > > > > > > > routers gets that value may change after one of them reboots. > > If > > > > > > > > > uptime is not considered, it will never change as long as one > > > > router > > > > > > > > > stays up at any given time. > > > > > > > > > > > > > > > > > > We are talking about a very low probability event (a duplicate) > > > > except > > > > > > > > > if this is a DoS attack and then either using or not using > > uptime > > > > > > > > > won't matter since the attacker will claim an impossibly long > > > > uptime. > > > > > > > > > > > > > > > > > > Curtis From acee.lindem@ericsson.com Mon Feb 10 14:09:18 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 C4FE71A088A for ; Mon, 10 Feb 2014 14:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm_vUV7c5Voa for ; Mon, 10 Feb 2014 14:09:16 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1C51A0447 for ; Mon, 10 Feb 2014 14:09:16 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-e5-52f94e0c4ad9 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B5.B4.11484.C0E49F25; Mon, 10 Feb 2014 23:09:16 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 17:09:15 -0500 From: Acee Lindem To: Anton Smirnov , OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJCiAnxm9xIN0E0e8HP9m2sLyOZqu3tWA Date: Mon, 10 Feb 2014 22:09:14 +0000 Message-ID: In-Reply-To: <52F5152F.2000009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXSPty6P388gg0OTrC1atrFatNy7x+7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZezcPomp4JVoxfwv+1gaGPcIdjFyckgImEjs a7vIAmGLSVy4t56ti5GLQ0jgCKPEpufTWEESQgLLGSWmTEsHsdkEdCSeP/rHDGKLCHhLXOyb CdYsLBApMffmJvYuRg6geJTEj03CECVGElM/bgALswioSvy5rgAS5hUwlWjYfIQJxOYU0JRo vfeIHcRmBDrh+6k1YHFmAXGJW0/mM0GcJiCxZM95ZghbVOLl439gl4kK6El0z1rOChFXlNjX P50doldHYsHuT2wQtrXEs4WLoGZqSyxb+JoZ4gZBiZMzn7BMYBSbhWTdLCTts5C0z0LSPgtJ +wJG1lWMHKXFqWW56UaGmxiBcXNMgs1xB+OCT5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwLimIEOvbI9huVfbz6jjafwXA5U4Xrt9r6kXn9B+JXoHZ3HD/1knnE+r tzXZupbsezr5ua3KJs/8GSdfTFFomCwnc6X6X97eNQqae/fPlwzT+6IXZnz4Q6F9xHzB0ssz Fi/LSu8OETPmPH4xfVoXy/Jvk7uN3FR0jKal1FtslPpltjovV/HJBSWW4oxEQy3mouJEAK/N EJZpAgAA Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:09:18 -0000 Hi Anton,=20 I really don't think "I am new" announcement (however signaled) is really necessary. Hence, I'm not inclined to add it to this draft even as an optional mechanism. Thanks, Acee=20 On 2/7/14 9:17 AM, "Anton Smirnov" wrote: > Hi Acee, > weighing probability of RID conflict against complexity of the >proposed method I agree it does not look attractive. > > I think RID conflict avoidance can be made optional. > What if feedback to change RID is given to device before it has >joined the OSPF domain? I.e. before router established at least one FULL >adjacency it advertises in its Hellos "I am new". Neighboring devices >weigh if new RID looks conflicting or not and advise back to the new >device via unicast Hellos. > >Anton > > >On 02/05/2014 09:21 PM, Acee Lindem wrote: >> >> The OSPFv3 autoconfiguration draft was cloned and presented in the ISIS >> WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In the ISIS >> WG, there was a concern that the resolution of a duplicate system ID did >> not include the amount of time the router was operational when >> determining which router would need to choose a new router ID. With >> additional complexity, we could incorporate router uptime into the >> resolution process. One way to do this would be to: >> >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include >> the uptime in seconds. >> 2. Use the Router Uptime TLV as the primary determinant in >> deciding which router must choose a new OSPFv3 Router ID. Router uptimes >> less than 3600 (MaxAge) seconds apart are considered equal. >> 3. When an OSPFv3 Hello is received with a different link-local >> source address but a different router-id, unicast the OSPFv3 AC-LSA to >> the neighbor so that OSPFv3 duplicate router resolution can proceed as >> in the case where it is received through the normal flooding process. >> This is somewhat of a hack as the we'd also need to accept OSPF Link >> State Updates from a neighbor that is not in Exchange State or greater. >> >> An alternative to #3 would be to use Link-Local Signaling (LLS) for >> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want to >> send the Router-Uptime and Router Hardware Fingerprint when a duplicate >> Router-ID is detected. This requires implementing the resolution two >> ways but may be preferable since it doesn't require violating the >> flooding rules. >> >> In any case, I'd like to get other opinions as to whether this problem >> is worth solving. >> >> Thanks, >> Acee >> >> >> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> From acee.lindem@ericsson.com Mon Feb 10 14:17:50 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 D13B41A0886 for ; Mon, 10 Feb 2014 14:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzbHktb2qTVs for ; Mon, 10 Feb 2014 14:17:45 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDBB1A0601 for ; Mon, 10 Feb 2014 14:17:45 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-f4-52f9500533ab Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3F.D2.12743.50059F25; Mon, 10 Feb 2014 23:17:41 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 17:17:44 -0500 From: Acee Lindem To: "curtis@ipv6.occnc.com" , "Les Ginsberg (ginsberg)" Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJdbsnxm9xIN0E0e8HP9m2sLyOZqu3dUA Date: Mon, 10 Feb 2014 22:17:44 +0000 Message-ID: In-Reply-To: <201402092038.s19KciP5015271@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPrC5rwM8gg+ud1haTZ51hs9jwZyO7 Rcu9e+wOzB5Tfm9k9Viy5CeTx7L7F9kCmKO4bFJSczLLUov07RK4Mno+bGEtaF/HWHHl9nbG BsZrLYxdjJwcEgImEkt3nmWGsMUkLtxbz9bFyMUhJHCEUWJe12qwhJDAckaJ+9NSQWw2AR2J 54/+gcVFBFIlljbeYQGxmQVkJZ5tawKLCwtESsy9uYm9i5EDqCZK4scmYYhyI4nFPxaD7WUR UJWY/2YtWDmvgKnEk8m9bCA2p4CzxKJpl5hAbEage76fWsMEMV5c4taT+UwQdwpILNlzHupm UYmXj/+xgtiiAnoS3bOWs0LEFSX29U9nh+jVkViw+xMbhG0t8WAGxF5mAW2JZQtfQ90gKHFy 5hOWCYzis5Csm4WkfRaS9llI2mchaV/AyLqKkaO0OLUsN93IYBMjMNaOSbDp7mDc89LyEKM0 B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgr9nmHWH9dY16nn5fprWU6d9bc FH2VrfOsdc/pL9IUY79+5pN4xIedofubDriuDduxb0H+irYtDtIBwhfFbL6uC9rwjiv46bIT 7MH3PvMGzN8UlvJwnvjqtYf1TrD4TF536E8Gm2Ob6+m1+g5Pml/piIa8fbvz9ZZtxSlRvDOL PbS22ZmuFvZQYinOSDTUYi4qTgQA1nVQN4MCAAA= Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:17:50 -0000 Hi Curtis,=20 See inline.=20 On 2/9/14 12:38 PM, "Curtis Villamizar" wrote: > >Les, > >Perhaps you should read the abstract of the document you are >commenting about: > > SPFv3 is a candidate for deployments in environments where auto- > configuration is a requirement. One such environment is the IPv6 > home network where users expect to simply plug in a router and have > it automatically use OSPFv3 for intra-domain routing. This > document describes the necessary mechanisms for OSPFv3 to be > self-configuring. > >Home network! > >Or the introductio: > > OSPFv3 [OSPFV3] is a candidate for deployments in environments > where auto-configuration is a requirement. > > [...] > > 1.2. Acknowledgments > > This specification was inspired by the work presented in the > Homenet working group meeting in October 2011 in Philadelphia, > Pennsylvania. > >The Homenet WG works on what? Home networks! > >So please keep that in mind when commenting. > >Unless a provider were to be so stupid or lazy to use this on a SP >network then most of the comments from both of us don't apply, >*except* the few comments below about "in a home network". > >Perhaps the draft should add text explicitly stating that the last >router-id used successfully should be used on a reboot rather than a >new random number. I notice that only the Router-Hardware-Fingerprint >TLV is persistent across reboots. This is insufficient if we want to >minimize disruption. > >The only case then (if router-id is remembered across reboots) would >be a new router. In that case your uptime rule would help. So >perhaps two things could be reocmmended: > > 1. In section 4, include a "SHOULD remember the most recent > successfully used router-id across reboots and reuse that". > Reword the rest so if that information is not available, then > pick a random number. I will do this.=20 > > 2. a. In section 6, mention the uptime rule. Modify the Router > Uptime TLV as suggested. > > b. Alternately add a flag to the Router-Hardware-Fingerprint > TLV that indicates that since last reboot this router-id has > been used and acheived a "full state". A router just > rebooting would not have ever reached the full state before > noticing a conflict as long as the conflct check is run > before considering itself in the full state. > > Note: A second flag bit indicating that this router-id had > been used successfully in a past reboot might also help but > would only matter among two routers both rebooting and > neither having reached the full state. > >I think #1 above is sufficient and does more to prevent surprises. I agree and appreciate you arguments in previous messages in this thread. > I >think #2 above helps only in the new router case but #2a requires >adding a TLV and so isn't worth it IMHO. Case #2b accomplished the >same thing with only a flag. I would not object to #2b above if #1 >above is also added. I agree that this would be a better mechanism and would only represent a single modification to the hardware fingerprint TLV. However, I really don't think even this is necessary. Thanks, Acee=20 > >See inline anyway. > >In message=20 > >"Les Ginsberg (ginsberg)" writes: >>=20 >> Curtis - >> =20 >> > -----Original Message----- >> > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] >> > Sent: Saturday, February 08, 2014 7:30 AM >> > To: Les Ginsberg (ginsberg) >> > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List >> > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- >> > autoconfig-05.txt >> >=20 >> >=20 >> > In message=20 >> >> > "Les Ginsberg (ginsberg)" writes: >> >=20 >> > > Curtis - >> > > >> > > Your reply below is talking about things which I think do not >>directly >> > > bear on the value add of what I have proposed. >> > > >> > > You mention various ways to insure that a given device assigns the >> > > same router-id each time it starts up and ways to insure it picks >>the >> > > same sequence of second/third... choices in the event it has to >>change >> > > its router-id. All good suggestions, but what I am talking about is >> > > what we do in the event a conflict occurs despite our best efforts >>to >> > > avoid it. With the current draft content preference is based solely >>on >> > > a fixed identifier (fingerprint) without regard to which choice >>would >> > > minimize disruption to the network. When preference is given to the >> > > "old router" to retain its existing router-id this shortcoming is >> > > addressed. >> >=20 >> > In the lifetime of a router it only gets added once. In the lifetime >> > of a router we would hope it only reboots zero time but experience so >> > far has been that reboots over a router's lifetime tend to be > 0 and >> > in some cases >> 0. >> >=20 >> > So you are optimizing for a 1 in 4 billion occurance that can happen >> > only once in the lifetime of a router. >> =20 >> The entire duplicate router-id resolution logic is addressing the >> improbable case. My proposal adds - literally - one line of code to >> the logic used to decide whether "I" should change my router-id or >> whether "you" should change your router-id. >> =20 >> >=20 >> > We also need to look at the consequences of this very improbably >> > occurance. Today's routers accomplish IGP convergence in large >> > networks in subsecond times, in some cases << 1 second. >> >=20 >> > Note that if flooding is completed (both withdraw old and install new) >> > in less than the SPF delay which is commonly implemented (some delay >> > after receiving the first flooded IGP change), then there is no impact >> > on routing. >> =20 >> Your analysis does not apply to this scenario. The router which >> changes its router-id is effectively doing a cold start. All >> adjacencies will go down. All LSAs originated by this router become >> invalid. All routes will be removed from the forwarding plane. If >> you are running BGP all the BGP nexthops will be gone on the router >> which is changing its identity. Restoration of the adjacencies and >> reacquisition of the LSDB will take multiple seconds. The best you >> can hope for is several seconds of disruption - it could easily be >> much longer. >> =20 >> For the new node which has usurped the old node's identity it will >> have to purge/replace all of the LSAs generated by the old >> node. While normal operation of the update process will insure that >> this happens in a reliable way the amount of flooding network-wide >> required to bringup a new node has now been roughly doubled >> i.e. the old node must reissue all of its LSAs using a new identity >> and the new node must purge/replace the old node's LSAs with its >> own versions. This will result in multiple SPFs on all nodes in the >> network and likely cause loops/blackholes during the transition >> since some of the SPFs will be run on versions of the LSDB which >> are inaccurate (part old node's old LSAs and part new node's >> LSAs). Suggesting that this could be handled in the same way/time >> as we typically handle a single link failure isn't credible. > >All routers are supposed to keep a fixed router-id across reboots. If >interfaces are changed when down, the last used router-id should be on >flash. If flash is removed and replaced (rather than a new image >installed), then with the same set of interfaces, the same decision >should be made. We are down to a very special case where both flash >and interfaces are removed and replaced yielding no history and a >different set of MACs to pick from. > >> > > Your statement that what I propose is only relevant when two routers >> > > go down does not match the scenarios I envision. If I want to add a >> > > new device to my network or if I need to replace an existing device >>in >> > > my network I am only affecting one device - but as I am introducing >>a >> > > device with a new fingerprint it is possible that it will introduce >>a >> > > conflict with an existing router-id. >> >=20 >> > In provider networks routers are generally added during maintenance >> > windows so should anything unexpected happen, impact is minimized. >> >=20 >> > In home nets, the home user isn't going to notice the convergence time >> > if there is any. A 10 msec SPF delay is likely to be plenty. >> =20 >> As I stated above, disruption will be orders of magnitude longer than >>10 ms.=20 > >In a home net? With perhaps a half dozen routers and a default route? >Someone has a very bad OSPF implementation. :-) Or did you miss the >"In home nets" at the front of the paragraph. > >For example, in a 10 node network with average degree 4, perhpas 40 >links in 10 router LSA exist. A few RTT (less than 1 msec for a >homenet) for each neighbor adjacency (which happen in parallel) and >ten packets from 4 sources is needed to reach the full state followed >by one SPF to be fully up and running. Other routers get one >additional router LSA plus four new links in existing router LSA and >have to run an SPF. Even on a software based homenet router using an >ARM, 10 msec is likely to be enough time and if it is "orders of >magnitude" longer, something is wrong with one of the implementations. >This would be an more complicated than usual home net or even soho, >more likely a small business. > >> > > In a subsequent reply you liked the idea of the new device delaying >> > > advertising reachability until it is has determined that its >>router-id >> > > choice is not in conflict. The old/new router paradigm supports this >> > > strategy by assuring that the old router will not consider changing >> > > its router-id until enough time has elapsed for the new router to >> > > transition to being an old router. >> >=20 >> > If it wins the coin toss, the router would advertise at least one LSA >> > to indicate its existance and could hold back on any additional >> > advertisements until the other router has withdrawn routes. >> >=20 >> =20 >> This suggestion does not alter the fact that if the old node changes >> > > its router-id the network has to respond to three events: >> =20 >> 1)Loss of the old node >> 2)Introduction of the old-node with a new identity >> 3)Introduction of the new node with the identity of the old-node > >Again, the old node should remember the last router-id used and try to >reuse it. > >> If however we insure that the old-node does not change its identity >> then the network only has to respond to a single event - the >> introduction of the new-node. > >Yes and if it were up and won the resolution last time, it will have >saved that router-id and will reuse it. If it came up previously and >lost the resolution, then it will remember the router-id it used, >whether second or third pick, and use that. > >> > > Finally, what I propose is extremely simple to implement. I think it >> > > isn't much of an exaggeration to say that any one of us could have >> > > implemented the enhancement in the time it has taken to discuss its >> > > merits. So we aren't overengineering for a case which is admittedly >> > > very unlikely to occur - we are adding a modest extension to make >>our >> > > solution less disruptive. >> >=20 >> > Yes but it it *bad* for the more common case where routers go down >> > occasionally. >> =20 >> You are going to have to clarify exactly what "bad side effects" you >> see for what I propose - because I don't see any - whereas I do >> see benefits as described above. > >If router-id is not remembered between reboots, then there is the one >in 4 billion time number of routers (less than 10 for a home net >today, but maybe more in the future). > >If router-id is remembered between reboots, then no matter how long a >router has been down, if nothing else in the network changed, there is >zero chance of having a collision. > >With either method, if router-id is remembered between reboots, then >there is zero chance of collision. > >IMO should this ever be used on a managed network (including a home >net / soho / small business net that happens to be managed) then >having routers come back from a reboot with the same router-ids would >be a big plus. For example, after a power outage NMS discovery would >not have to be repeated. > >> Les >> =20 >> =20 >> >=20 >> > > Les >> >=20 >> > Curtis >> >=20 >> >=20 >> > > > -----Original Message----- >> > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] >> > > > Sent: Friday, February 07, 2014 9:22 AM >> > > > To: Les Ginsberg (ginsberg) >> > > > Cc: Acee Lindem; Curtis Villamizar; OSPF List >> > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - >>draft-ietf-ospf-ospfv3- >> > > > autoconfig-05.txt >> > > > >> > > > >> > > > In message > > x02.cisco.com> >> > > > "Les Ginsberg (ginsberg)" writes: >> > > > > >> > > > > So, I am one person who raised this concern to Acee - but the >>proposal >> > > > > outlined by Acee is not what I had in mind. There is no need to >>use >> > > > > "uptime" or to invent some unusual exchange of LSAs prior to >>Exchange >> > > > > state. >> > > > > >> > > > > Also, in regards to Curtis's comment - it is not DOS attacks >>that I am >> > > > > trying to mitigate here. As he says if an attacker is in your >>network >> > > > > and able to originate credible packets no strategy is safe. >> > > > > >> > > > > The motivating use case is to minimize disruption of a stable >>network >> > > > > when a new router is added or an existing router is >> > > > > replaced/rebooted. In other words non-disruptive handling of the >> > > > > common maintenance/upgrade scenarios. >> > > > > >> > > > > What I have in mind is this: >> > > > > >> > > > > 1) A router needs a way to advertise that it has been up and >>running >> > > > > for a minimum length of time - for the sake of discussion >>let's say >> > > > > 20 minutes. Routers then fall into two categories: >> > > > > >> > > > > o Old routers (up >=3D minimum time) >> > > > > o New routers (up < minimum time) >> > > > > >> > > > > 2) When a duplicate router-id is detected, the first tie >>breaker is >> > > > > between old routers and new routers. The old router gets to >>keep >> > > > > its router-id and the new router picks a new router-id. If >>both >> > > > > routers are "new" or both routers are "old" then we revert >>to the >> > > > > existing tie breakers defined in the document (link local >>address >> > > > > for directly connected routers and fingerprint info for >> > > > > non-neighbors). >> > > > > >> > > > > 3) Advertisement of the "old/new" state requires a single bit - >>but it >> > > > > has to be available both in hellos and the new AC-LSA. >>Adding it to >> > > > > the AC-LSA is easy to do. For hellos, there are two >>possibilities: >> > > > > >> > > > > o Use one of the Options Bits >> > > > > o Use LLS >> > > > > >> > > > > Be interested in how folks feel about this. >> > > > > >> > > > > Les >> > > > >> > > > >> > > > Les, >> > > > >> > > > Excluding DoS attack, we are talking about a one in 4 billion case >> > > > (for any two routers, so with 400 routers, still well under one >>in 1M) >> > > > where two routers hash a MAC address or pick a one time random >>number >> > > > from out of nowhere and end up with the same number. >> > > > >> > > > If that does happen (and one in 1M is certainly possible), then it >> > > > would be nice if the routers always ended up with the same >>router-id. >> > > > This could be accomplished by some fixed method such as hashing a >> > > > constant with the first choice or router-id or using the >>router-id as >> > > > a seed for the random number generator (which will pick the same >> > > > sequence of random numbers each time). If this is done, then a >> > > > conflict would always produce the same set of next picks. The >>set of >> > > > routers in a given network would always end up with the same >> > > > router-ids once they all came up and if only one went down at a >>time >> > > > then it would always end up with the same router-id when it came >>up. >> > > > >> > > > Zero conf was mainly intended for unmanaged networks (motivated by >> > > > work in the homenet WG). In these small unmanaged networks it >>doesn't >> > > > matter which router gets what router-id as long as they end up >>unique >> > > > and convergence is in a reasonable time relative to keeping >>eyeballs >> > > > happy. It could be applied to enterprise or providers but in >>either >> > > > case having the routers end up with the same router-ids would >>make for >> > > > easier management. >> > > > >> > > > For your scenario to matter at all with current rules, both >>routers in >> > > > the conflict would have to go down. If only the one that is >>preferred >> > > > goes down, the other is not going to change its router-id as a >>result >> > > > so when it comes up it gets its first pick with no conflict. If >>the >> > > > one that was not preferred goes down, it comes up, sees a >>conflict and >> > > > takes its second pick (loses the conflict every time). It is >>only if >> > > > they both go down and the one that normally loses the conflict >>comes >> > > > up first that there is a change in router-id. That too can be >>solved >> > > > with a rule that you always come up with the last router-id used. >> > > > >> > > > Curtis >> > > > >> > > > >> > > > > > -----Original Message----- >> > > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee >>Lindem >> > > > > > Sent: Thursday, February 06, 2014 5:12 PM >> > > > > > To: Curtis Villamizar >> > > > > > Cc: OSPF List >> > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - >>draft-ietf-ospf- >> > ospfv3- >> > > > > > autoconfig-05.txt >> > > > > > >> > > > > > Hi Curtis, >> > > > > > I agree and believe the significance of this use case where a >>new >> > router >> > > > is >> > > > > > inserted into an auto-configured domain has been greater >>exaggerated. >> > > > > > Thanks, >> > > > > > Acee >> > > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar >> >> > > > wrote: >> > > > > > >> > > > > > > >> > > > > > > In message >> > > > > > > Acee Lindem writes: >> > > > > > > >> > > > > > >> The OSPFv3 autoconfiguration draft was cloned and >>presented in the >> > > > > > >> ISIS WG >>(http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). >> > In >> > > > > > >> the ISIS WG, there was a concern that the resolution of a >> > duplicate >> > > > > > >> system ID did not include the amount of time the router was >> > > > > > >> operational when determining which router would need to >>choose a >> > new >> > > > > > >> router ID. With additional complexity, we could >>incorporate router >> > > > > > >> uptime into the resolution process. One way to do this >>would be >> > to: >> > > > > > >> >> > > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It >>would >> > include >> > > > > > >> the uptime in seconds. >> > > > > > >> >> > > > > > >> 2. Use the Router Uptime TLV as the primary >>determinant in >> > > > > > >> deciding which router must choose a new OSPFv3 >>Router >> > > > > > >> ID. Router uptimes less than 3600 (MaxAge) seconds >>apart >> > are >> > > > > > >> considered equal. >> > > > > > >> >> > > > > > >> 3. When an OSPFv3 Hello is received with a different >>link- >> > local >> > > > > > >> source address but a different router-id, unicast the >> > OSPFv3 >> > > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate router >> > > > > > >> resolution can proceed as in the case where it is >>received >> > > > > > >> through the normal flooding process. This is somewhat >>of a >> > > > > > >> hack as the we'd also need to accept OSPF Link State >> > Updates >> > > > > > >> from a neighbor that is not in Exchange State or >>greater. >> > > > > > >> >> > > > > > >> An alternative to #3 would be to use Link-Local Signaling >>(LLS) >> > for >> > > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, >>you'd only >> > want >> > > > > > >> to send the Router-Uptime and Router Hardware Fingerprint >>when a >> > > > > > >> duplicate Router-ID is detected. This requires >>implementing the >> > > > > > >> resolution two ways but may be preferable since it doesn't >>require >> > > > > > >> violating the flooding rules. >> > > > > > >> >> > > > > > >> In any case, I'd like to get other opinions as to whether >>this >> > problem >> > > > > > >> is worth solving. >> > > > > > >> >> > > > > > >> Thanks, >> > > > > > >> Acee >> > > > > > > >> > > > > > > >> > > > > > > Acee, >> > > > > > > >> > > > > > > If the basis for router-id on boot up results in a fixed >>value, and >> > if >> > > > > > > a duplicate will occur on a give network, then which of two >> > duplicate >> > > > > > > routers gets that value may change after one of them >>reboots. If >> > > > > > > uptime is not considered, it will never change as long as >>one >> > router >> > > > > > > stays up at any given time. >> > > > > > > >> > > > > > > We are talking about a very low probability event (a >>duplicate) >> > except >> > > > > > > if this is a DoS attack and then either using or not using >>uptime >> > > > > > > won't matter since the attacker will claim an impossibly >>long >> > uptime. >> > > > > > > >> > > > > > > Curtis From acee@lindem.com Mon Feb 10 14:55: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 DE23C1A0488 for ; Mon, 10 Feb 2014 14:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg_ODta4eJqn for ; Mon, 10 Feb 2014 14:55:31 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 38FD71A054A for ; Mon, 10 Feb 2014 14:55:28 -0800 (PST) X-Authority-Analysis: v=2.0 cv=dq5Z+ic4 c=1 sm=0 a=6GMfd8PykZcSCX/AhX7arA==:17 a=9cW_t1CCXrUA:10 a=bxkyXclnpBsA:10 a=Wma4Of2gTTwA:10 a=h_OiLf7yGQAA:10 a=N659UExz7-8A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=dPXu___EqbMA:10 a=0FD05c-RAAAA:8 a=D7dCDJm4AAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=llD0YVhCQFvKzLp_4TAA:9 a=pILNOxqGKmIA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=gdCqGMTcc4GRl-Ss:21 a=I9wG0ikM9LYxDJ-E:21 a=6GMfd8PykZcSCX/AhX7arA==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.6.125 Received: from [65.190.6.125] ([65.190.6.125:32949] helo=[10.0.1.9]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 44/CB-21884-8D859F25; Mon, 10 Feb 2014 22:55:27 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Acee Lindem In-Reply-To: Date: Mon, 10 Feb 2014 17:55:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> References: X-Mailer: Apple Mail (2.1827) Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:55:35 -0000 One thing I neglected to mention is that a solution dependent having the = other router=92s hardware fingerprint available will greatly complicate = duplicate router-id detection for directly attached routers since the = resolution must either be deferred until the router=92s AC-LSA is = received from another router OR the hardware fingerprint must be = signaled in the OSPFv3 Hello LLS. IMO, this complexity adds to the = motivation of not attempting to solve this problem.=20 Thanks, Acee =20 On Feb 10, 2014, at 5:17 PM, Acee Lindem = wrote: > Hi Curtis,=20 >=20 > See inline.=20 >=20 > On 2/9/14 12:38 PM, "Curtis Villamizar" wrote: >=20 >>=20 >> Les, >>=20 >> Perhaps you should read the abstract of the document you are >> commenting about: >>=20 >> SPFv3 is a candidate for deployments in environments where auto- >> configuration is a requirement. One such environment is the IPv6 >> home network where users expect to simply plug in a router and have >> it automatically use OSPFv3 for intra-domain routing. This >> document describes the necessary mechanisms for OSPFv3 to be >> self-configuring. >>=20 >> Home network! >>=20 >> Or the introductio: >>=20 >> OSPFv3 [OSPFV3] is a candidate for deployments in environments >> where auto-configuration is a requirement. >>=20 >> [...] >>=20 >> 1.2. Acknowledgments >>=20 >> This specification was inspired by the work presented in the >> Homenet working group meeting in October 2011 in Philadelphia, >> Pennsylvania. >>=20 >> The Homenet WG works on what? Home networks! >>=20 >> So please keep that in mind when commenting. >>=20 >> Unless a provider were to be so stupid or lazy to use this on a SP >> network then most of the comments from both of us don't apply, >> *except* the few comments below about "in a home network". >>=20 >> Perhaps the draft should add text explicitly stating that the last >> router-id used successfully should be used on a reboot rather than a >> new random number. I notice that only the = Router-Hardware-Fingerprint >> TLV is persistent across reboots. This is insufficient if we want to >> minimize disruption. >>=20 >> The only case then (if router-id is remembered across reboots) would >> be a new router. In that case your uptime rule would help. So >> perhaps two things could be reocmmended: >>=20 >> 1. In section 4, include a "SHOULD remember the most recent >> successfully used router-id across reboots and reuse that". >> Reword the rest so if that information is not available, then >> pick a random number. >=20 > I will do this.=20 >=20 >=20 >=20 >>=20 >> 2. a. In section 6, mention the uptime rule. Modify the Router >> Uptime TLV as suggested. >>=20 >> b. Alternately add a flag to the Router-Hardware-Fingerprint >> TLV that indicates that since last reboot this router-id has >> been used and acheived a "full state". A router just >> rebooting would not have ever reached the full state before >> noticing a conflict as long as the conflct check is run >> before considering itself in the full state. >>=20 >> Note: A second flag bit indicating that this router-id had >> been used successfully in a past reboot might also help but >> would only matter among two routers both rebooting and >> neither having reached the full state. >>=20 >> I think #1 above is sufficient and does more to prevent surprises. >=20 > I agree and appreciate you arguments in previous messages in this = thread. >=20 >=20 >> I >> think #2 above helps only in the new router case but #2a requires >> adding a TLV and so isn't worth it IMHO. Case #2b accomplished the >> same thing with only a flag. I would not object to #2b above if #1 >> above is also added. >=20 > I agree that this would be a better mechanism and would only represent = a > single modification to the hardware fingerprint TLV. However, I really > don't think even this is necessary. >=20 > Thanks, > Acee=20 >=20 >=20 >=20 >>=20 >> See inline anyway. >>=20 >> In message=20 >> >> "Les Ginsberg (ginsberg)" writes: >>>=20 >>> Curtis - >>>=20 >>>> -----Original Message----- >>>> From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] >>>> Sent: Saturday, February 08, 2014 7:30 AM >>>> To: Les Ginsberg (ginsberg) >>>> Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List >>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - = draft-ietf-ospf-ospfv3- >>>> autoconfig-05.txt >>>>=20 >>>>=20 >>>> In message=20 >>> >>>> "Les Ginsberg (ginsberg)" writes: >>>>=20 >>>>> Curtis - >>>>>=20 >>>>> Your reply below is talking about things which I think do not >>> directly >>>>> bear on the value add of what I have proposed. >>>>>=20 >>>>> You mention various ways to insure that a given device assigns the >>>>> same router-id each time it starts up and ways to insure it picks >>> the >>>>> same sequence of second/third... choices in the event it has to >>> change >>>>> its router-id. All good suggestions, but what I am talking about = is >>>>> what we do in the event a conflict occurs despite our best efforts >>> to >>>>> avoid it. With the current draft content preference is based = solely >>> on >>>>> a fixed identifier (fingerprint) without regard to which choice >>> would >>>>> minimize disruption to the network. When preference is given to = the >>>>> "old router" to retain its existing router-id this shortcoming is >>>>> addressed. >>>>=20 >>>> In the lifetime of a router it only gets added once. In the = lifetime >>>> of a router we would hope it only reboots zero time but experience = so >>>> far has been that reboots over a router's lifetime tend to be > 0 = and >>>> in some cases >> 0. >>>>=20 >>>> So you are optimizing for a 1 in 4 billion occurance that can = happen >>>> only once in the lifetime of a router. >>>=20 >>> The entire duplicate router-id resolution logic is addressing the >>> improbable case. My proposal adds - literally - one line of code to >>> the logic used to decide whether "I" should change my router-id or >>> whether "you" should change your router-id. >>>=20 >>>>=20 >>>> We also need to look at the consequences of this very improbably >>>> occurance. Today's routers accomplish IGP convergence in large >>>> networks in subsecond times, in some cases << 1 second. >>>>=20 >>>> Note that if flooding is completed (both withdraw old and install = new) >>>> in less than the SPF delay which is commonly implemented (some = delay >>>> after receiving the first flooded IGP change), then there is no = impact >>>> on routing. >>>=20 >>> Your analysis does not apply to this scenario. The router which >>> changes its router-id is effectively doing a cold start. All >>> adjacencies will go down. All LSAs originated by this router become >>> invalid. All routes will be removed from the forwarding plane. If >>> you are running BGP all the BGP nexthops will be gone on the router >>> which is changing its identity. Restoration of the adjacencies and >>> reacquisition of the LSDB will take multiple seconds. The best you >>> can hope for is several seconds of disruption - it could easily be >>> much longer. >>>=20 >>> For the new node which has usurped the old node's identity it will >>> have to purge/replace all of the LSAs generated by the old >>> node. While normal operation of the update process will insure that >>> this happens in a reliable way the amount of flooding network-wide >>> required to bringup a new node has now been roughly doubled >>> i.e. the old node must reissue all of its LSAs using a new identity >>> and the new node must purge/replace the old node's LSAs with its >>> own versions. This will result in multiple SPFs on all nodes in the >>> network and likely cause loops/blackholes during the transition >>> since some of the SPFs will be run on versions of the LSDB which >>> are inaccurate (part old node's old LSAs and part new node's >>> LSAs). Suggesting that this could be handled in the same way/time >>> as we typically handle a single link failure isn't credible. >>=20 >> All routers are supposed to keep a fixed router-id across reboots. = If >> interfaces are changed when down, the last used router-id should be = on >> flash. If flash is removed and replaced (rather than a new image >> installed), then with the same set of interfaces, the same decision >> should be made. We are down to a very special case where both flash >> and interfaces are removed and replaced yielding no history and a >> different set of MACs to pick from. >>=20 >>>>> Your statement that what I propose is only relevant when two = routers >>>>> go down does not match the scenarios I envision. If I want to add = a >>>>> new device to my network or if I need to replace an existing = device >>> in >>>>> my network I am only affecting one device - but as I am = introducing >>> a >>>>> device with a new fingerprint it is possible that it will = introduce >>> a >>>>> conflict with an existing router-id. >>>>=20 >>>> In provider networks routers are generally added during maintenance >>>> windows so should anything unexpected happen, impact is minimized. >>>>=20 >>>> In home nets, the home user isn't going to notice the convergence = time >>>> if there is any. A 10 msec SPF delay is likely to be plenty. >>>=20 >>> As I stated above, disruption will be orders of magnitude longer = than >>> 10 ms.=20 >>=20 >> In a home net? With perhaps a half dozen routers and a default = route? >> Someone has a very bad OSPF implementation. :-) Or did you miss the >> "In home nets" at the front of the paragraph. >>=20 >> For example, in a 10 node network with average degree 4, perhpas 40 >> links in 10 router LSA exist. A few RTT (less than 1 msec for a >> homenet) for each neighbor adjacency (which happen in parallel) and >> ten packets from 4 sources is needed to reach the full state followed >> by one SPF to be fully up and running. Other routers get one >> additional router LSA plus four new links in existing router LSA and >> have to run an SPF. Even on a software based homenet router using an >> ARM, 10 msec is likely to be enough time and if it is "orders of >> magnitude" longer, something is wrong with one of the = implementations. >> This would be an more complicated than usual home net or even soho, >> more likely a small business. >>=20 >>>>> In a subsequent reply you liked the idea of the new device = delaying >>>>> advertising reachability until it is has determined that its >>> router-id >>>>> choice is not in conflict. The old/new router paradigm supports = this >>>>> strategy by assuring that the old router will not consider = changing >>>>> its router-id until enough time has elapsed for the new router to >>>>> transition to being an old router. >>>>=20 >>>> If it wins the coin toss, the router would advertise at least one = LSA >>>> to indicate its existance and could hold back on any additional >>>> advertisements until the other router has withdrawn routes. >>>>=20 >>>=20 >>> This suggestion does not alter the fact that if the old node changes >>>>> its router-id the network has to respond to three events: >>>=20 >>> 1)Loss of the old node >>> 2)Introduction of the old-node with a new identity >>> 3)Introduction of the new node with the identity of the old-node >>=20 >> Again, the old node should remember the last router-id used and try = to >> reuse it. >>=20 >>> If however we insure that the old-node does not change its identity >>> then the network only has to respond to a single event - the >>> introduction of the new-node. >>=20 >> Yes and if it were up and won the resolution last time, it will have >> saved that router-id and will reuse it. If it came up previously and >> lost the resolution, then it will remember the router-id it used, >> whether second or third pick, and use that. >>=20 >>>>> Finally, what I propose is extremely simple to implement. I think = it >>>>> isn't much of an exaggeration to say that any one of us could have >>>>> implemented the enhancement in the time it has taken to discuss = its >>>>> merits. So we aren't overengineering for a case which is = admittedly >>>>> very unlikely to occur - we are adding a modest extension to make >>> our >>>>> solution less disruptive. >>>>=20 >>>> Yes but it it *bad* for the more common case where routers go down >>>> occasionally. >>>=20 >>> You are going to have to clarify exactly what "bad side effects" you >>> see for what I propose - because I don't see any - whereas I do >>> see benefits as described above. >>=20 >> If router-id is not remembered between reboots, then there is the one >> in 4 billion time number of routers (less than 10 for a home net >> today, but maybe more in the future). >>=20 >> If router-id is remembered between reboots, then no matter how long a >> router has been down, if nothing else in the network changed, there = is >> zero chance of having a collision. >>=20 >> With either method, if router-id is remembered between reboots, then >> there is zero chance of collision. >>=20 >> IMO should this ever be used on a managed network (including a home >> net / soho / small business net that happens to be managed) then >> having routers come back from a reboot with the same router-ids would >> be a big plus. For example, after a power outage NMS discovery would >> not have to be repeated. >>=20 >>> Les >>>=20 >>>=20 >>>>=20 >>>>> Les >>>>=20 >>>> Curtis >>>>=20 >>>>=20 >>>>>> -----Original Message----- >>>>>> From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] >>>>>> Sent: Friday, February 07, 2014 9:22 AM >>>>>> To: Les Ginsberg (ginsberg) >>>>>> Cc: Acee Lindem; Curtis Villamizar; OSPF List >>>>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - >>> draft-ietf-ospf-ospfv3- >>>>>> autoconfig-05.txt >>>>>>=20 >>>>>>=20 >>>>>> In message >>> x02.cisco.com> >>>>>> "Les Ginsberg (ginsberg)" writes: >>>>>>>=20 >>>>>>> So, I am one person who raised this concern to Acee - but the >>> proposal >>>>>>> outlined by Acee is not what I had in mind. There is no need to >>> use >>>>>>> "uptime" or to invent some unusual exchange of LSAs prior to >>> Exchange >>>>>>> state. >>>>>>>=20 >>>>>>> Also, in regards to Curtis's comment - it is not DOS attacks >>> that I am >>>>>>> trying to mitigate here. As he says if an attacker is in your >>> network >>>>>>> and able to originate credible packets no strategy is safe. >>>>>>>=20 >>>>>>> The motivating use case is to minimize disruption of a stable >>> network >>>>>>> when a new router is added or an existing router is >>>>>>> replaced/rebooted. In other words non-disruptive handling of the >>>>>>> common maintenance/upgrade scenarios. >>>>>>>=20 >>>>>>> What I have in mind is this: >>>>>>>=20 >>>>>>> 1) A router needs a way to advertise that it has been up and >>> running >>>>>>> for a minimum length of time - for the sake of discussion >>> let's say >>>>>>> 20 minutes. Routers then fall into two categories: >>>>>>>=20 >>>>>>> o Old routers (up >=3D minimum time) >>>>>>> o New routers (up < minimum time) >>>>>>>=20 >>>>>>> 2) When a duplicate router-id is detected, the first tie >>> breaker is >>>>>>> between old routers and new routers. The old router gets to >>> keep >>>>>>> its router-id and the new router picks a new router-id. If >>> both >>>>>>> routers are "new" or both routers are "old" then we revert >>> to the >>>>>>> existing tie breakers defined in the document (link local >>> address >>>>>>> for directly connected routers and fingerprint info for >>>>>>> non-neighbors). >>>>>>>=20 >>>>>>> 3) Advertisement of the "old/new" state requires a single bit - >>> but it >>>>>>> has to be available both in hellos and the new AC-LSA. >>> Adding it to >>>>>>> the AC-LSA is easy to do. For hellos, there are two >>> possibilities: >>>>>>>=20 >>>>>>> o Use one of the Options Bits >>>>>>> o Use LLS >>>>>>>=20 >>>>>>> Be interested in how folks feel about this. >>>>>>>=20 >>>>>>> Les >>>>>>=20 >>>>>>=20 >>>>>> Les, >>>>>>=20 >>>>>> Excluding DoS attack, we are talking about a one in 4 billion = case >>>>>> (for any two routers, so with 400 routers, still well under one >>> in 1M) >>>>>> where two routers hash a MAC address or pick a one time random >>> number >>>>>> from out of nowhere and end up with the same number. >>>>>>=20 >>>>>> If that does happen (and one in 1M is certainly possible), then = it >>>>>> would be nice if the routers always ended up with the same >>> router-id. >>>>>> This could be accomplished by some fixed method such as hashing a >>>>>> constant with the first choice or router-id or using the >>> router-id as >>>>>> a seed for the random number generator (which will pick the same >>>>>> sequence of random numbers each time). If this is done, then a >>>>>> conflict would always produce the same set of next picks. The >>> set of >>>>>> routers in a given network would always end up with the same >>>>>> router-ids once they all came up and if only one went down at a >>> time >>>>>> then it would always end up with the same router-id when it came >>> up. >>>>>>=20 >>>>>> Zero conf was mainly intended for unmanaged networks (motivated = by >>>>>> work in the homenet WG). In these small unmanaged networks it >>> doesn't >>>>>> matter which router gets what router-id as long as they end up >>> unique >>>>>> and convergence is in a reasonable time relative to keeping >>> eyeballs >>>>>> happy. It could be applied to enterprise or providers but in >>> either >>>>>> case having the routers end up with the same router-ids would >>> make for >>>>>> easier management. >>>>>>=20 >>>>>> For your scenario to matter at all with current rules, both >>> routers in >>>>>> the conflict would have to go down. If only the one that is >>> preferred >>>>>> goes down, the other is not going to change its router-id as a >>> result >>>>>> so when it comes up it gets its first pick with no conflict. If >>> the >>>>>> one that was not preferred goes down, it comes up, sees a >>> conflict and >>>>>> takes its second pick (loses the conflict every time). It is >>> only if >>>>>> they both go down and the one that normally loses the conflict >>> comes >>>>>> up first that there is a change in router-id. That too can be >>> solved >>>>>> with a rule that you always come up with the last router-id used. >>>>>>=20 >>>>>> Curtis >>>>>>=20 >>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee >>> Lindem >>>>>>>> Sent: Thursday, February 06, 2014 5:12 PM >>>>>>>> To: Curtis Villamizar >>>>>>>> Cc: OSPF List >>>>>>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - >>> draft-ietf-ospf- >>>> ospfv3- >>>>>>>> autoconfig-05.txt >>>>>>>>=20 >>>>>>>> Hi Curtis, >>>>>>>> I agree and believe the significance of this use case where a >>> new >>>> router >>>>>> is >>>>>>>> inserted into an auto-configured domain has been greater >>> exaggerated. >>>>>>>> Thanks, >>>>>>>> Acee >>>>>>>> On Feb 5, 2014, at 3:58 PM, Curtis Villamizar >>> >>>>>> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> In message >>>>>>>>> Acee Lindem writes: >>>>>>>>>=20 >>>>>>>>>> The OSPFv3 autoconfiguration draft was cloned and >>> presented in the >>>>>>>>>> ISIS WG >>> (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). >>>> In >>>>>>>>>> the ISIS WG, there was a concern that the resolution of a >>>> duplicate >>>>>>>>>> system ID did not include the amount of time the router was >>>>>>>>>> operational when determining which router would need to >>> choose a >>>> new >>>>>>>>>> router ID. With additional complexity, we could >>> incorporate router >>>>>>>>>> uptime into the resolution process. One way to do this >>> would be >>>> to: >>>>>>>>>>=20 >>>>>>>>>> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It >>> would >>>> include >>>>>>>>>> the uptime in seconds. >>>>>>>>>>=20 >>>>>>>>>> 2. Use the Router Uptime TLV as the primary >>> determinant in >>>>>>>>>> deciding which router must choose a new OSPFv3 >>> Router >>>>>>>>>> ID. Router uptimes less than 3600 (MaxAge) seconds >>> apart >>>> are >>>>>>>>>> considered equal. >>>>>>>>>>=20 >>>>>>>>>> 3. When an OSPFv3 Hello is received with a different >>> link- >>>> local >>>>>>>>>> source address but a different router-id, unicast the >>>> OSPFv3 >>>>>>>>>> AC-LSA to the neighbor so that OSPFv3 duplicate router >>>>>>>>>> resolution can proceed as in the case where it is >>> received >>>>>>>>>> through the normal flooding process. This is somewhat >>> of a >>>>>>>>>> hack as the we'd also need to accept OSPF Link State >>>> Updates >>>>>>>>>> from a neighbor that is not in Exchange State or >>> greater. >>>>>>>>>>=20 >>>>>>>>>> An alternative to #3 would be to use Link-Local Signaling >>> (LLS) >>>> for >>>>>>>>>> signaling the contents of the OSPFv3 AC-LSA. However, >>> you'd only >>>> want >>>>>>>>>> to send the Router-Uptime and Router Hardware Fingerprint >>> when a >>>>>>>>>> duplicate Router-ID is detected. This requires >>> implementing the >>>>>>>>>> resolution two ways but may be preferable since it doesn't >>> require >>>>>>>>>> violating the flooding rules. >>>>>>>>>>=20 >>>>>>>>>> In any case, I'd like to get other opinions as to whether >>> this >>>> problem >>>>>>>>>> is worth solving. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Acee >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Acee, >>>>>>>>>=20 >>>>>>>>> If the basis for router-id on boot up results in a fixed >>> value, and >>>> if >>>>>>>>> a duplicate will occur on a give network, then which of two >>>> duplicate >>>>>>>>> routers gets that value may change after one of them >>> reboots. If >>>>>>>>> uptime is not considered, it will never change as long as >>> one >>>> router >>>>>>>>> stays up at any given time. >>>>>>>>>=20 >>>>>>>>> We are talking about a very low probability event (a >>> duplicate) >>>> except >>>>>>>>> if this is a DoS attack and then either using or not using >>> uptime >>>>>>>>> won't matter since the attacker will claim an impossibly >>> long >>>> uptime. >>>>>>>>>=20 >>>>>>>>> Curtis >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From xuxiaohu@huawei.com Mon Feb 10 18:12:19 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 C49481A0727; Mon, 10 Feb 2014 18:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 EjnTDm33ogwj; Mon, 10 Feb 2014 18:12:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 598391A0724; Mon, 10 Feb 2014 18:12:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ32856; Tue, 11 Feb 2014 02:12:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:11:19 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:12:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 10:12:10 +0800 From: Xuxiaohu To: Peter Psenak Thread-Topic: [spring] [OSPF] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt Thread-Index: AQHPFm0RHaJp205InUCDICUZBq6WQ5qX9Dow///P6ICAAIxY4P//i/mAgAM8uGCAADEksP//pqiAABDZ6FD//3ziAP//eUFQgACY7QD/79h8AA== Date: Tue, 11 Feb 2014 02:12:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824BC7E@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08248329@NKGEML512-MBS.china.huawei.com> <52E61BAF.2060208@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08248431@NKGEML512-MBS.china.huawei.com> <52E63015.5090404@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082493BE@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824948F@NKGEML512-MBS.china.huawei.com> <52E8C589.9010408@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082494C6@NKGEML512-MBS.china.huawei.com> <52E8C8A2.8060306@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082494F0@NKGEML512-MBS.china.huawei.com> <52E8D7E2.2030100@cisco.com> In-Reply-To: <52E8D7E2.2030100@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ospf@ietf.org" , "spring@ietf.org" Subject: Re: [OSPF] [spring] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:12:20 -0000 SGkgUGV0ZXIsDQoNClNvcnJ5IGZvciBsYXRlIHJlc3BvbnNlIGR1ZSB0byBhIGxvbmcgaG9saWRh eS4NCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogUGV0ZXIgUHNlbmFr IFttYWlsdG86cHBzZW5ha0BjaXNjby5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxNOW5tDHmnIgy OeaXpSAxODoyOQ0KPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTogb3NwZkBpZXRmLm9y Zzsgc3ByaW5nQGlldGYub3JnDQo+IOS4u+mimDogUmU6IFtzcHJpbmddIFtPU1BGXSBmd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtb3NwZi1nbG9iYWwtbGFiZWwt c2lkLWFkdi0wMC50eHQNCj4gDQo+IFh1eGlhb2h1LA0KPiANCj4gT24gMS8yOS8xNCAxMDo1OCAs IFh1eGlhb2h1IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K PiA+PiDlj5Hku7bkuro6IFBldGVyIFBzZW5hayBbbWFpbHRvOnBwc2VuYWtAY2lzY28uY29tXQ0K PiA+PiDlj5HpgIHml7bpl7Q6IDIwMTTlubQx5pyIMjnml6UgMTc6MjQNCj4gPj4g5pS25Lu25Lq6 OiBYdXhpYW9odQ0KPiA+PiDmioTpgIE6IG9zcGZAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZw0K PiA+PiDkuLvpopg6IFJlOiBbc3ByaW5nXSBbT1NQRl0gZndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+ID4+IGRyYWZ0LXh1LW9zcGYtZ2xvYmFsLWxhYmVsLXNpZC1hZHYtMDAudHh0 DQo+ID4+DQo+ID4+IFh1eGlhb2h1LA0KPiA+Pg0KPiA+PiBPbiAxLzI5LzE0IDEwOjE2ICwgWHV4 aWFvaHUgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0t DQo+ID4+Pj4g5Y+R5Lu25Lq6OiBQZXRlciBQc2VuYWsgW21haWx0bzpwcHNlbmFrQGNpc2NvLmNv bV0NCj4gPj4+PiDlj5HpgIHml7bpl7Q6IDIwMTTlubQx5pyIMjnml6UgMTc6MTENCj4gPj4+PiDm lLbku7bkuro6IFh1eGlhb2h1DQo+ID4+Pj4g5oqE6YCBOiBvc3BmQGlldGYub3JnOyBzcHJpbmdA aWV0Zi5vcmcNCj4gPj4+PiDkuLvpopg6IFJlOiBbc3ByaW5nXSBbT1NQRl0gZndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+Pj4gZHJhZnQteHUtb3NwZi1nbG9iYWwtbGFiZWwt c2lkLWFkdi0wMC50eHQNCj4gPj4+Pg0KPiA+Pj4+IFhpYW9odSwNCj4gPj4+Pg0KPiA+Pj4+IE9u IDEvMjkvMTQgMDk6NTMgLCBYdXhpYW9odSB3cm90ZToNCj4gPj4+Pj4gRm9yIGV4YW1wbGUsIGFz c3VtZSBhIGxhYmVsIGJsb2NrIHsxMDAwLCAxOTk5fSBpcyBhbGxvY2F0ZWQgZm9yDQo+ID4+Pj4+ IHByZWZpeA0KPiA+Pj4+IHNlZ21lbnRzIGJ5IGFsbW9zdCBhbGwgU1Igcm91dGVycyBhbmQgYSBn bG9iYWwgbGFiZWwgMTAwNSBpcw0KPiA+Pj4+IGFsbG9jYXRlZCB0byBhIGdpdmVuIHByZWZpeCBz ZWdtZW50LCBmb3IgYSBnaXZlbiBzZWxkb20gU1Igcm91dGVyDQo+ID4+Pj4gd2hpY2ggY291bGRu J3QgcHJlc2VydmUgdGhlIGFib3ZlIGxhYmVsIGJsb2NrIGFuZCBhbGxvY2F0ZXMgYQ0KPiA+Pj4+ IGRpZmZlcmVudCBsYWJlbCBibG9jayAoZS5nLiwgezIwMDAsIDI5OTl9KSBpbnN0ZWFkLCBhIGxv Y2FsIGxhYmVsDQo+ID4+Pj4gY29ycmVzcG9uZGluZyB0byB0aGF0IGdsb2JhbCBsYWJlbCAob3Ig dGhhdCBwcmVmaXggc2VnbWVudCkgY291bGQNCj4gPj4+PiBiZSBjYWxjdWxhdGVkIHRocm91Z2gg b2Zmc2V0dGluZywgaS5lLiwgdGhlIHJlc3VsdCBpcyAxMDA1Kw0KPiA+Pj4+ICgyMDAwLTEwMDAp PTIwMDUuIEluIHRoaXMgd2F5LCB0aGVyZSBpcyBubyBuZWVkIGZvciBpbnRyb2R1Y2luZyB0aGUN Cj4gPj4+PiBJbmRleCBjb25jZXB0IGFueW1vcmUgYW5kIHRoZXJlZm9yZSB0aGUgYXJjaGl0ZWN0 dXJlIGJlY29tZXMgbXVjaA0KPiA+Pj4+IGVhc3kgdG8gdW5kZXJzdGFuZC4gTW9yZSBpbXBvcnRh bnRseSwgY29tcGFyZWQgdG8gdGhlIGluZGV4IGJpbmRpbmcNCj4gPj4+PiBhZHZlcnRpc2VtZW50 LCB0aGUgbGFiZWwgYmluZGluZyBhZHZlcnRpc2VkIGJ5IHRoZSBJR1AgaXMgZXhhY3RseQ0KPiA+ Pj4+IHRoZSBzYW1lIGFzIHRoYXQgaW4gdGhlIGxhYmVsIGZvcndhcmRpbmcgdGFibGUgZm9yIHRo b3NlIG1vc3QgU1INCj4gPj4+PiByb3V0ZXJzIHdoaWNoIGhhdmUgYWxsb2NhdGVkIHRoZSBhYm92 ZSBjb21tb24gbGFiZWwgYmxvY2ssIHdoaWNoIGlzDQo+ID4+Pj4gbXVjaA0KPiA+PiBiZW5lZmlj aWFsIHdoZW4gZG9pbmcgdHJvdWJsZXNob290aW5nLiBUaGlzIGFwcHJvYWNoIGRvZXMgbm90IHZp b2xhdGUNCj4gPj4gdGhlIHN0cm9uZ2VzdCBNUExTIGRvZ21hIChpLmUuLCBsYWJlbHMgTVVTVCBi ZSBsb2NhbCkgd2hpbGUhDQo+ID4+Pj4gICAgdGFraW5nIGluDQo+ID4+Pj4gdG8gYWNjb3VudCB0 aGUgYWN0dWFsIHNpdHVhdGlvbiwgSU1ITw0KPiA+Pj4+DQo+ID4+Pj4gYWJvdmUgd291bGQgcmVx dWlyZSB0aGUgInNlbGRvbSBTUiByb3V0ZXIiIHRvIGtub3cgdGhlIG9mZnNldCBmcm9tDQo+ID4+ Pj4gdGhlIFNSR0IgdXNlZCBieSBvdGhlciByb3V0ZXJzLiBIb3cgZG8geW91IGVudmlzaW9uIHRo YXQgdG8gYmUgbGVhcm5lZD8NCj4gPj4+DQo+ID4+PiBIaSBQZXRlciwNCj4gPj4+DQo+ID4+PiBJ IGRvbid0IHRoaW5rIGl0J3MgYSBiaWcgcHJvYmxlbS4gVGhlIGNvbW1vbiBTUkdCIGNvdWxkIGVp dGhlciBiZQ0KPiA+Pj4gbWFudWFsbHkNCj4gPj4gY29uZmlndXJlZCBvbiB0aGUgc2VsZG9tIFNS IHJvdXRlciBvciBhZHZlcnRpc2VkIGJ5IHRoZSBNUy4NCj4gPj4NCj4gPj4gbWFudWFsIGNvbmZp Z3VyYXRpb24gaXMgbm90IGFuIG9wdGlvbiAtIGp1c3QgaW1hZ2luZSB5b3UgaGF2ZQ0KPiA+PiBt dWx0aXBsZSAic2VsZG9tIFNSIHJvdXRlcnMiLCBlYWNoIGhhdmluZyBhIGRpZmZlcmVudCBsYWJl bCBibG9jay4NCj4gPj4gTm93IHlvdSBub3Qgb25seSBuZWVkIGFuIG9mZnNldCBmb3IgImNvbW1v biIgYmxvY2ssIGJ1dCBhbHNvIG9mZnNldA0KPiA+PiBiZXR3ZWVuIGxhYmVsIGJsb2NrcyB1c2Vk IG9uIHRoZXNlICJzZWxkb20gU1Igcm91dGVycyIuDQo+ID4NCj4gPiBQZXRlciwNCj4gPg0KPiA+ IFdoeSBkbyB5b3UgbmVlZCBvZmZzZXQgYmV0d2VlbiBsYWJlbCBibG9ja3MgdXNlZCBvbiB0aGVz ZSBzZWxkb20gU1Igcm91dGVycz8NCj4gVGhlIGNvbW1vbiBibG9jayBpcyB0aGUgb25seSBmcmFt ZSBvZiByZWZlcmVuY2UsIElNTy4NCj4gDQo+IGxldCdzIGltYWdpbmUgeW91IGhhdmUgdHdvICJz ZWxkb20gU1Igcm91dGVycyIsIEEgYW5kIEIsIGRpcmVjdGx5IGNvbm5lY3RlZC4gQSBpcw0KPiB1 c2luZyBsYWJlbCBibG9jayAxMDAwLTIwMDAsIEIgaXMgdXNpbmcgMjAwMC0zMDAwLiBGb3Igc2lt cGxpY2l0eSwgbGV0J3MgYXNzdW1lDQo+IHJlc3Qgb2YgdGhlIHJvdXRlcnMgdXNlIHRoZSBibG9j ayAwLTEwMDAuDQo+IA0KPiBOb3cgbGV0J3MgaW1hZ2luZSB5b3UgaGF2ZSBhIHByZWZpeCBYLCB3 aGljaCBpcyBhZHZlcnRpc2VkIHdpdGggbGFiZWwgMjUgZnJvbSBhDQo+IHJvdXRlciB0aGF0IHVz ZXMgdGhlIGNvbW1vbiBibG9jayAoMC0xMDAwKS4gT24gQSB5b3UgY29uZmlndXJlIHRoZSBvZmZz ZXQNCj4gKzEwMDAsIHNvIGl0IGFsbG9jYXRlIGEgbG9jYWwgbGFiZWwgb2YgMTAyNSBmb3IgWC4g Tm93IEEgd2FudHMgdG8gc2VuZCBhIHRyYWZmaWMgZm9yDQo+IFggdmlhIEIuIFlvdSB3b3VsZCBo YXZlIHRvIGNvbmZpZ3VyZSBvbiBBIHRoZSBvZmZzZXQgb2YgQiBhcyArMjAwMCAoYWdhaW5zdCB0 aGUNCj4gY29tbW9uIGJsb2NrKSBvciBhcyArMTAwMCAoYWdhaW5zdCB0aGUgQSdzIGJsb2NrKSwg c28gd2hlbiBBIHNlbmRzIGEgdHJhZmZpYyB0bw0KDQpPbmx5IGFnYWluc3QgdGhlIGNvbW1vbiBi bG9jayBzaW5jZSBpdCBpcyB0aGUgb25seSBmcmFtZSBvZiByZWZlcmVuY2UuDQoNCj4gQiwgaXQg d2lsbCB1c2UgbGFiZWwgMjAyNS4NCj4gTm8gbWF0dGVyIHdoaWNoIG1ldGhvZCBvZiBzcGVjaWZ5 aW5nIHRoZSBvZmZzZXQgeW91IHVzZSwgdGhlIHBvaW50IGlzIHRoYXQgb24gQQ0KPiB5b3UgbmVl ZCB0byBrbm93IHRoZSBvZmZzZXQgb2YgYWxsICJzZWxkb20gU1IiIHJvdXRlcnMgdGhhdCB5b3Ug bWF5IGVuZCB1cA0KPiBzZW5kaW5nIHRyYWZmaWMgdG8gLSBlaXRoZXIgZGlyZWN0bHksIG9yIGlu ZGlyZWN0bHkuIFN1Y2ggYSBjb25maWd1cmF0aW9uIG1vZGVsIGRvZXMNCj4gbm90IHNjYWxlLg0K DQpUaG9zZSAic2VsZG9tIFNSIiByb3V0ZXJzIHdvdWxkIGFkdmVydGlzZSB0aGVpciBvd24gYmxv Y2tzLiBBbmQgb25seSB0aG9zZSAic2VsZG9tIFNSIiByb3V0ZXJzIG5lZWQgdG8gYWR2ZXJ0aXNl IHRoZWlyIG93biBibG9ja3MuIEluIHRoaXMgd2F5LCB0aGVyZSBpcyBubyBuZWVkIHRvIGludHJv ZHVjZSB0aGUgaW5kZXggc3BhY2UgYW55bW9yZSwgYW5kIHRoZXJlZm9yZSB0aGUgYXJjaGl0ZWN0 dXJlIGFuZCB0aGUgdHJvdWJsZXNob290aW5nIGJlY29tZSBtdWNoIHNpbXBsZXIgZ2l2ZW4gdGhl IGFzc3VtcHRpb24gdGhhdCBvbmx5IHNlbGRvbSBTUiByb3V0ZXJzIGNvdWxkIG5vdCBhbGxvY2F0 ZSB0aGF0IGNvbW1vbiBibG9jay4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gDQo+ID4N Cj4gPj4gT25jZSB5b3Ugc3RhcnQgdG8gYWR2ZXJ0aXNlIGl0LCB5b3UgYXJlIGJhY2sgdG8gdGhl IG1vZGVsIHdlIGhhdmUNCj4gPj4gYWxyZWFkeSwgYnV0IHlvdSBtYWRlIGl0IGV2ZW4gd29yc2Ug d2l0aCBvZmZzZXRzLg0KPiA+DQo+ID4gSSBkb24ndCB0aGluayBzby4gVGFrZSB0aGUgYWJvdmUg c2l0dWF0aW9uIGFzIGFuIGV4YW1wbGUsIGluIHRoZSBpbmRleCBiaW5kaW5nDQo+IG1vZGUsIHlv dSBjb3VsZCBhbGxvdyB0aGUgbW9zdCBTUiByb3V0ZXJzIHRvIGFkdmVydGlzZSBpdHMgbGFiZWwg cmFuZ2Ugc3RhcnRpbmcNCj4gd2l0aCB6ZXJvIHRvIGFjaGlldmUgdGhlIGFib3ZlIGVmZmVjdCAo YWx0aG91Z2ggaXQgY29uZmxpY3RzIHdpdGggdGhlIGRlZmluaXRpb24gb2YNCj4gbGFiZWwgcmFu Z2UpLiBIb3dldmVyLCBmb3IgdGhlIHNlbGRvbSBTUiByb3V0ZXIsIHdoYXQgbGFiZWwgcmFuZ2Ug c2hvdWxkIGl0DQo+IGFkdmVydGlzZT8NCj4gDQo+IHRoZSBzaW1wbGVzdCBtb2RlbCBpcyBmb3Ig ZXZlcnkgcm91dGVyIChzZWxkb20gb3IgY29tbW9uKSB0byBhZHZlcnRpc2UgaXRzIGxhYmVsDQo+ IGJsb2NrLg0KDQo+IHJlZ2FyZHMsDQo+IFBldGVyDQo+IA0KPiA+DQo+ID4gQmVzdCByZWdhcmRz LA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IHJlZ2FyZHMsDQo+ID4+IFBldGVyDQo+ID4+DQo+ID4+ Pg0KPiA+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4gWGlhb2h1DQo+ID4+Pg0KPiA+Pj4+IHJlZ2Fy ZHMsDQo+ID4+Pj4gUGV0ZXINCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBCZXN0IHJlZ2FyZHMs DQo+ID4+Pj4+IFhpYW9odQ0KPiA+Pj4NCj4gPg0KDQo= From ginsberg@cisco.com Mon Feb 10 22:29:49 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 254971A0696 for ; Mon, 10 Feb 2014 22:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 IAon8YV2MmgT for ; Mon, 10 Feb 2014 22:29:44 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 26C521A08C3 for ; Mon, 10 Feb 2014 22:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26551; q=dns/txt; s=iport; t=1392100184; x=1393309784; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+7Hl8so9V4Mwt58dJy2S1514D4jOeNrlTOHfNFl8cDY=; b=e8/zKV5pSN1q87B1IUxdmINeSwLSKiWW4K+AEc+efIfM2gMIXdmJu/PV EqSlpJS+mxXGP0HNWnAMm0y29LP3y9wqAxPMcGZj8kUxkVesSX49ItFiN Zx1r+2RbgucIIbJenW1Re1TQXUbjYopQfJrGjKbnGT40Lt9BrPk79RogR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAKzC+VKtJXG//2dsb2JhbABQAwaDDDhXvmSBDRZ0giUBAQEEAQEBFyA0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBA4DAggBEgSHZg3JXReOFQ0LEgYrBwIEgx6BFASMYYdgiyyKXYMtQIFq X-IronPort-AV: E=Sophos;i="4.95,823,1384300800"; d="scan'208";a="19472708" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-4.cisco.com with ESMTP; 11 Feb 2014 06:29:42 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1B6Tgai000768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 06:29:42 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 00:29:42 -0600 From: "Les Ginsberg (ginsberg)" To: Acee Lindem Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJdbs/pYRbYVsxUaPEbmLjnjkwpqvdL4AgAAKfoCAABLr4A== Date: Tue, 11 Feb 2014 06:29:41 +0000 Message-ID: References: <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> In-Reply-To: <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 06:29:49 -0000 Acee - One thing I have repeatedly emphasized is the simplicity of what I am propo= sing. You mention below that the proposal requires having fingerprint info = available before LSDB exchange would normally occur in order to handle rout= er-id collisions between neighbors - and you are understandably concerned a= bout the complexity that would introduce. There is no such requirement!! I am NOT proposing this!! This is simply a misunderstanding on your part. Here is all that is necessary: Router-id collision between neighbors -------------------------------------- I receive a hello with a duplicate router-id. The hello includes an options= bit (or LLS if you prefer) indicating whether the neighbor considers itsel= f "old/new". Because I cannot form a neighbor with "myself" I need to resol= ve the duplicate router-id. There is no need to have or wait to acquire the= neighbor fingerprint information. The logic is solely based on the content= of the received hello and my internal state (old/new). The logic is: if ((I am old) && (neighbor is new)) { return; /* Neighbor will change its router-id */ } else if (I am new) && (neighbor is old)) { Change_my_router_id(); } else /* We are both old or both new */=20 if (my link_local address < neighbor_link_local_address) { change_my_router_id(); } } That's it! No additional logic required. Similarly... Router-id collision between non-neighbors -------------------------------------- In this case we have acquired the LSDB so we detect a duplicate router-id a= s described in the draft Section 6.2. But fingerprint info includes a bit w= hich indicates whether the originator is "old" or "new". The logic is then: if ((I am old) && (non-neighbor is new)) { return; /* Non-Neighbor will change its router-id */ } else if (I am new) && (non-neighbor is old)) { Change_my_router_id(); } else /* We are both old or both new */=20 if (my fingerprint < non-neighbor fingerprint) { change_my_router_id(); } } Setting of old/new state is done simply on the basis of a minimum amount of= uptime (e.g. 5 minutes). The rather complex logic that Curtis proposed in = an earlier reply is not needed - I will address why in a follow up response= to his post. You may still not like the idea - but complexity is not a basis for rejecti= on. Hopefully what I have provided makes that clear. Les > -----Original Message----- > From: Acee Lindem [mailto:acee@lindem.com] > Sent: Monday, February 10, 2014 2:55 PM > Cc: curtis@ipv6.occnc.com; Les Ginsberg (ginsberg); OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 > One thing I neglected to mention is that a solution dependent having the > other router's hardware fingerprint available will greatly complicate > duplicate router-id detection for directly attached routers since the > resolution must either be deferred until the router's AC-LSA is received = from > another router OR the hardware fingerprint must be signaled in the OSPFv3 > Hello LLS. IMO, this complexity adds to the motivation of not attempting = to > solve this problem. > Thanks, > Acee > On Feb 10, 2014, at 5:17 PM, Acee Lindem wrote= : >=20 > > Hi Curtis, > > > > See inline. > > > > On 2/9/14 12:38 PM, "Curtis Villamizar" wrote: > > > >> > >> Les, > >> > >> Perhaps you should read the abstract of the document you are > >> commenting about: > >> > >> SPFv3 is a candidate for deployments in environments where auto- > >> configuration is a requirement. One such environment is the IPv6 > >> home network where users expect to simply plug in a router and have > >> it automatically use OSPFv3 for intra-domain routing. This > >> document describes the necessary mechanisms for OSPFv3 to be > >> self-configuring. > >> > >> Home network! > >> > >> Or the introductio: > >> > >> OSPFv3 [OSPFV3] is a candidate for deployments in environments > >> where auto-configuration is a requirement. > >> > >> [...] > >> > >> 1.2. Acknowledgments > >> > >> This specification was inspired by the work presented in the > >> Homenet working group meeting in October 2011 in Philadelphia, > >> Pennsylvania. > >> > >> The Homenet WG works on what? Home networks! > >> > >> So please keep that in mind when commenting. > >> > >> Unless a provider were to be so stupid or lazy to use this on a SP > >> network then most of the comments from both of us don't apply, > >> *except* the few comments below about "in a home network". > >> > >> Perhaps the draft should add text explicitly stating that the last > >> router-id used successfully should be used on a reboot rather than a > >> new random number. I notice that only the Router-Hardware-Fingerprint > >> TLV is persistent across reboots. This is insufficient if we want to > >> minimize disruption. > >> > >> The only case then (if router-id is remembered across reboots) would > >> be a new router. In that case your uptime rule would help. So > >> perhaps two things could be reocmmended: > >> > >> 1. In section 4, include a "SHOULD remember the most recent > >> successfully used router-id across reboots and reuse that". > >> Reword the rest so if that information is not available, then > >> pick a random number. > > > > I will do this. > > > > > > > >> > >> 2. a. In section 6, mention the uptime rule. Modify the Router > >> Uptime TLV as suggested. > >> > >> b. Alternately add a flag to the Router-Hardware-Fingerprint > >> TLV that indicates that since last reboot this router-id has > >> been used and acheived a "full state". A router just > >> rebooting would not have ever reached the full state before > >> noticing a conflict as long as the conflct check is run > >> before considering itself in the full state. > >> > >> Note: A second flag bit indicating that this router-id had > >> been used successfully in a past reboot might also help but > >> would only matter among two routers both rebooting and > >> neither having reached the full state. > >> > >> I think #1 above is sufficient and does more to prevent surprises. > > > > I agree and appreciate you arguments in previous messages in this threa= d. > > > > > >> I > >> think #2 above helps only in the new router case but #2a requires > >> adding a TLV and so isn't worth it IMHO. Case #2b accomplished the > >> same thing with only a flag. I would not object to #2b above if #1 > >> above is also added. > > > > I agree that this would be a better mechanism and would only represent = a > > single modification to the hardware fingerprint TLV. However, I really > > don't think even this is necessary. > > > > Thanks, > > Acee > > > > > > > >> > >> See inline anyway. > >> > >> In message > >> > >> "Les Ginsberg (ginsberg)" writes: > >>> > >>> Curtis - > >>> > >>>> -----Original Message----- > >>>> From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > >>>> Sent: Saturday, February 08, 2014 7:30 AM > >>>> To: Les Ginsberg (ginsberg) > >>>> Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > >>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv= 3- > >>>> autoconfig-05.txt > >>>> > >>>> > >>>> In message > >>> > >>>> "Les Ginsberg (ginsberg)" writes: > >>>> > >>>>> Curtis - > >>>>> > >>>>> Your reply below is talking about things which I think do not > >>> directly > >>>>> bear on the value add of what I have proposed. > >>>>> > >>>>> You mention various ways to insure that a given device assigns the > >>>>> same router-id each time it starts up and ways to insure it picks > >>> the > >>>>> same sequence of second/third... choices in the event it has to > >>> change > >>>>> its router-id. All good suggestions, but what I am talking about is > >>>>> what we do in the event a conflict occurs despite our best efforts > >>> to > >>>>> avoid it. With the current draft content preference is based solely > >>> on > >>>>> a fixed identifier (fingerprint) without regard to which choice > >>> would > >>>>> minimize disruption to the network. When preference is given to the > >>>>> "old router" to retain its existing router-id this shortcoming is > >>>>> addressed. > >>>> > >>>> In the lifetime of a router it only gets added once. In the lifetim= e > >>>> of a router we would hope it only reboots zero time but experience s= o > >>>> far has been that reboots over a router's lifetime tend to be > 0 an= d > >>>> in some cases >> 0. > >>>> > >>>> So you are optimizing for a 1 in 4 billion occurance that can happen > >>>> only once in the lifetime of a router. > >>> > >>> The entire duplicate router-id resolution logic is addressing the > >>> improbable case. My proposal adds - literally - one line of code to > >>> the logic used to decide whether "I" should change my router-id or > >>> whether "you" should change your router-id. > >>> > >>>> > >>>> We also need to look at the consequences of this very improbably > >>>> occurance. Today's routers accomplish IGP convergence in large > >>>> networks in subsecond times, in some cases << 1 second. > >>>> > >>>> Note that if flooding is completed (both withdraw old and install ne= w) > >>>> in less than the SPF delay which is commonly implemented (some delay > >>>> after receiving the first flooded IGP change), then there is no impa= ct > >>>> on routing. > >>> > >>> Your analysis does not apply to this scenario. The router which > >>> changes its router-id is effectively doing a cold start. All > >>> adjacencies will go down. All LSAs originated by this router become > >>> invalid. All routes will be removed from the forwarding plane. If > >>> you are running BGP all the BGP nexthops will be gone on the router > >>> which is changing its identity. Restoration of the adjacencies and > >>> reacquisition of the LSDB will take multiple seconds. The best you > >>> can hope for is several seconds of disruption - it could easily be > >>> much longer. > >>> > >>> For the new node which has usurped the old node's identity it will > >>> have to purge/replace all of the LSAs generated by the old > >>> node. While normal operation of the update process will insure that > >>> this happens in a reliable way the amount of flooding network-wide > >>> required to bringup a new node has now been roughly doubled > >>> i.e. the old node must reissue all of its LSAs using a new identity > >>> and the new node must purge/replace the old node's LSAs with its > >>> own versions. This will result in multiple SPFs on all nodes in the > >>> network and likely cause loops/blackholes during the transition > >>> since some of the SPFs will be run on versions of the LSDB which > >>> are inaccurate (part old node's old LSAs and part new node's > >>> LSAs). Suggesting that this could be handled in the same way/time > >>> as we typically handle a single link failure isn't credible. > >> > >> All routers are supposed to keep a fixed router-id across reboots. If > >> interfaces are changed when down, the last used router-id should be on > >> flash. If flash is removed and replaced (rather than a new image > >> installed), then with the same set of interfaces, the same decision > >> should be made. We are down to a very special case where both flash > >> and interfaces are removed and replaced yielding no history and a > >> different set of MACs to pick from. > >> > >>>>> Your statement that what I propose is only relevant when two router= s > >>>>> go down does not match the scenarios I envision. If I want to add a > >>>>> new device to my network or if I need to replace an existing device > >>> in > >>>>> my network I am only affecting one device - but as I am introducing > >>> a > >>>>> device with a new fingerprint it is possible that it will introduce > >>> a > >>>>> conflict with an existing router-id. > >>>> > >>>> In provider networks routers are generally added during maintenance > >>>> windows so should anything unexpected happen, impact is minimized. > >>>> > >>>> In home nets, the home user isn't going to notice the convergence ti= me > >>>> if there is any. A 10 msec SPF delay is likely to be plenty. > >>> > >>> As I stated above, disruption will be orders of magnitude longer than > >>> 10 ms. > >> > >> In a home net? With perhaps a half dozen routers and a default route? > >> Someone has a very bad OSPF implementation. :-) Or did you miss the > >> "In home nets" at the front of the paragraph. > >> > >> For example, in a 10 node network with average degree 4, perhpas 40 > >> links in 10 router LSA exist. A few RTT (less than 1 msec for a > >> homenet) for each neighbor adjacency (which happen in parallel) and > >> ten packets from 4 sources is needed to reach the full state followed > >> by one SPF to be fully up and running. Other routers get one > >> additional router LSA plus four new links in existing router LSA and > >> have to run an SPF. Even on a software based homenet router using an > >> ARM, 10 msec is likely to be enough time and if it is "orders of > >> magnitude" longer, something is wrong with one of the implementations. > >> This would be an more complicated than usual home net or even soho, > >> more likely a small business. > >> > >>>>> In a subsequent reply you liked the idea of the new device delaying > >>>>> advertising reachability until it is has determined that its > >>> router-id > >>>>> choice is not in conflict. The old/new router paradigm supports thi= s > >>>>> strategy by assuring that the old router will not consider changing > >>>>> its router-id until enough time has elapsed for the new router to > >>>>> transition to being an old router. > >>>> > >>>> If it wins the coin toss, the router would advertise at least one LS= A > >>>> to indicate its existance and could hold back on any additional > >>>> advertisements until the other router has withdrawn routes. > >>>> > >>> > >>> This suggestion does not alter the fact that if the old node changes > >>>>> its router-id the network has to respond to three events: > >>> > >>> 1)Loss of the old node > >>> 2)Introduction of the old-node with a new identity > >>> 3)Introduction of the new node with the identity of the old-node > >> > >> Again, the old node should remember the last router-id used and try to > >> reuse it. > >> > >>> If however we insure that the old-node does not change its identity > >>> then the network only has to respond to a single event - the > >>> introduction of the new-node. > >> > >> Yes and if it were up and won the resolution last time, it will have > >> saved that router-id and will reuse it. If it came up previously and > >> lost the resolution, then it will remember the router-id it used, > >> whether second or third pick, and use that. > >> > >>>>> Finally, what I propose is extremely simple to implement. I think i= t > >>>>> isn't much of an exaggeration to say that any one of us could have > >>>>> implemented the enhancement in the time it has taken to discuss its > >>>>> merits. So we aren't overengineering for a case which is admittedly > >>>>> very unlikely to occur - we are adding a modest extension to make > >>> our > >>>>> solution less disruptive. > >>>> > >>>> Yes but it it *bad* for the more common case where routers go down > >>>> occasionally. > >>> > >>> You are going to have to clarify exactly what "bad side effects" you > >>> see for what I propose - because I don't see any - whereas I do > >>> see benefits as described above. > >> > >> If router-id is not remembered between reboots, then there is the one > >> in 4 billion time number of routers (less than 10 for a home net > >> today, but maybe more in the future). > >> > >> If router-id is remembered between reboots, then no matter how long a > >> router has been down, if nothing else in the network changed, there is > >> zero chance of having a collision. > >> > >> With either method, if router-id is remembered between reboots, then > >> there is zero chance of collision. > >> > >> IMO should this ever be used on a managed network (including a home > >> net / soho / small business net that happens to be managed) then > >> having routers come back from a reboot with the same router-ids would > >> be a big plus. For example, after a power outage NMS discovery would > >> not have to be repeated. > >> > >>> Les > >>> > >>> > >>>> > >>>>> Les > >>>> > >>>> Curtis > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > >>>>>> Sent: Friday, February 07, 2014 9:22 AM > >>>>>> To: Les Ginsberg (ginsberg) > >>>>>> Cc: Acee Lindem; Curtis Villamizar; OSPF List > >>>>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - > >>> draft-ietf-ospf-ospfv3- > >>>>>> autoconfig-05.txt > >>>>>> > >>>>>> > >>>>>> In message >>>> x02.cisco.com> > >>>>>> "Les Ginsberg (ginsberg)" writes: > >>>>>>> > >>>>>>> So, I am one person who raised this concern to Acee - but the > >>> proposal > >>>>>>> outlined by Acee is not what I had in mind. There is no need to > >>> use > >>>>>>> "uptime" or to invent some unusual exchange of LSAs prior to > >>> Exchange > >>>>>>> state. > >>>>>>> > >>>>>>> Also, in regards to Curtis's comment - it is not DOS attacks > >>> that I am > >>>>>>> trying to mitigate here. As he says if an attacker is in your > >>> network > >>>>>>> and able to originate credible packets no strategy is safe. > >>>>>>> > >>>>>>> The motivating use case is to minimize disruption of a stable > >>> network > >>>>>>> when a new router is added or an existing router is > >>>>>>> replaced/rebooted. In other words non-disruptive handling of the > >>>>>>> common maintenance/upgrade scenarios. > >>>>>>> > >>>>>>> What I have in mind is this: > >>>>>>> > >>>>>>> 1) A router needs a way to advertise that it has been up and > >>> running > >>>>>>> for a minimum length of time - for the sake of discussion > >>> let's say > >>>>>>> 20 minutes. Routers then fall into two categories: > >>>>>>> > >>>>>>> o Old routers (up >=3D minimum time) > >>>>>>> o New routers (up < minimum time) > >>>>>>> > >>>>>>> 2) When a duplicate router-id is detected, the first tie > >>> breaker is > >>>>>>> between old routers and new routers. The old router gets to > >>> keep > >>>>>>> its router-id and the new router picks a new router-id. If > >>> both > >>>>>>> routers are "new" or both routers are "old" then we revert > >>> to the > >>>>>>> existing tie breakers defined in the document (link local > >>> address > >>>>>>> for directly connected routers and fingerprint info for > >>>>>>> non-neighbors). > >>>>>>> > >>>>>>> 3) Advertisement of the "old/new" state requires a single bit - > >>> but it > >>>>>>> has to be available both in hellos and the new AC-LSA. > >>> Adding it to > >>>>>>> the AC-LSA is easy to do. For hellos, there are two > >>> possibilities: > >>>>>>> > >>>>>>> o Use one of the Options Bits > >>>>>>> o Use LLS > >>>>>>> > >>>>>>> Be interested in how folks feel about this. > >>>>>>> > >>>>>>> Les > >>>>>> > >>>>>> > >>>>>> Les, > >>>>>> > >>>>>> Excluding DoS attack, we are talking about a one in 4 billion case > >>>>>> (for any two routers, so with 400 routers, still well under one > >>> in 1M) > >>>>>> where two routers hash a MAC address or pick a one time random > >>> number > >>>>>> from out of nowhere and end up with the same number. > >>>>>> > >>>>>> If that does happen (and one in 1M is certainly possible), then it > >>>>>> would be nice if the routers always ended up with the same > >>> router-id. > >>>>>> This could be accomplished by some fixed method such as hashing a > >>>>>> constant with the first choice or router-id or using the > >>> router-id as > >>>>>> a seed for the random number generator (which will pick the same > >>>>>> sequence of random numbers each time). If this is done, then a > >>>>>> conflict would always produce the same set of next picks. The > >>> set of > >>>>>> routers in a given network would always end up with the same > >>>>>> router-ids once they all came up and if only one went down at a > >>> time > >>>>>> then it would always end up with the same router-id when it came > >>> up. > >>>>>> > >>>>>> Zero conf was mainly intended for unmanaged networks (motivated by > >>>>>> work in the homenet WG). In these small unmanaged networks it > >>> doesn't > >>>>>> matter which router gets what router-id as long as they end up > >>> unique > >>>>>> and convergence is in a reasonable time relative to keeping > >>> eyeballs > >>>>>> happy. It could be applied to enterprise or providers but in > >>> either > >>>>>> case having the routers end up with the same router-ids would > >>> make for > >>>>>> easier management. > >>>>>> > >>>>>> For your scenario to matter at all with current rules, both > >>> routers in > >>>>>> the conflict would have to go down. If only the one that is > >>> preferred > >>>>>> goes down, the other is not going to change its router-id as a > >>> result > >>>>>> so when it comes up it gets its first pick with no conflict. If > >>> the > >>>>>> one that was not preferred goes down, it comes up, sees a > >>> conflict and > >>>>>> takes its second pick (loses the conflict every time). It is > >>> only if > >>>>>> they both go down and the one that normally loses the conflict > >>> comes > >>>>>> up first that there is a change in router-id. That too can be > >>> solved > >>>>>> with a rule that you always come up with the last router-id used. > >>>>>> > >>>>>> Curtis > >>>>>> > >>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee > >>> Lindem > >>>>>>>> Sent: Thursday, February 06, 2014 5:12 PM > >>>>>>>> To: Curtis Villamizar > >>>>>>>> Cc: OSPF List > >>>>>>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - > >>> draft-ietf-ospf- > >>>> ospfv3- > >>>>>>>> autoconfig-05.txt > >>>>>>>> > >>>>>>>> Hi Curtis, > >>>>>>>> I agree and believe the significance of this use case where a > >>> new > >>>> router > >>>>>> is > >>>>>>>> inserted into an auto-configured domain has been greater > >>> exaggerated. > >>>>>>>> Thanks, > >>>>>>>> Acee > >>>>>>>> On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > >>> > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> In message > >>>>>>>>> Acee Lindem writes: > >>>>>>>>> > >>>>>>>>>> The OSPFv3 autoconfiguration draft was cloned and > >>> presented in the > >>>>>>>>>> ISIS WG > >>> (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). > >>>> In > >>>>>>>>>> the ISIS WG, there was a concern that the resolution of a > >>>> duplicate > >>>>>>>>>> system ID did not include the amount of time the router was > >>>>>>>>>> operational when determining which router would need to > >>> choose a > >>>> new > >>>>>>>>>> router ID. With additional complexity, we could > >>> incorporate router > >>>>>>>>>> uptime into the resolution process. One way to do this > >>> would be > >>>> to: > >>>>>>>>>> > >>>>>>>>>> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It > >>> would > >>>> include > >>>>>>>>>> the uptime in seconds. > >>>>>>>>>> > >>>>>>>>>> 2. Use the Router Uptime TLV as the primary > >>> determinant in > >>>>>>>>>> deciding which router must choose a new OSPFv3 > >>> Router > >>>>>>>>>> ID. Router uptimes less than 3600 (MaxAge) seconds > >>> apart > >>>> are > >>>>>>>>>> considered equal. > >>>>>>>>>> > >>>>>>>>>> 3. When an OSPFv3 Hello is received with a different > >>> link- > >>>> local > >>>>>>>>>> source address but a different router-id, unicast the > >>>> OSPFv3 > >>>>>>>>>> AC-LSA to the neighbor so that OSPFv3 duplicate router > >>>>>>>>>> resolution can proceed as in the case where it is > >>> received > >>>>>>>>>> through the normal flooding process. This is somewhat > >>> of a > >>>>>>>>>> hack as the we'd also need to accept OSPF Link State > >>>> Updates > >>>>>>>>>> from a neighbor that is not in Exchange State or > >>> greater. > >>>>>>>>>> > >>>>>>>>>> An alternative to #3 would be to use Link-Local Signaling > >>> (LLS) > >>>> for > >>>>>>>>>> signaling the contents of the OSPFv3 AC-LSA. However, > >>> you'd only > >>>> want > >>>>>>>>>> to send the Router-Uptime and Router Hardware Fingerprint > >>> when a > >>>>>>>>>> duplicate Router-ID is detected. This requires > >>> implementing the > >>>>>>>>>> resolution two ways but may be preferable since it doesn't > >>> require > >>>>>>>>>> violating the flooding rules. > >>>>>>>>>> > >>>>>>>>>> In any case, I'd like to get other opinions as to whether > >>> this > >>>> problem > >>>>>>>>>> is worth solving. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Acee > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Acee, > >>>>>>>>> > >>>>>>>>> If the basis for router-id on boot up results in a fixed > >>> value, and > >>>> if > >>>>>>>>> a duplicate will occur on a give network, then which of two > >>>> duplicate > >>>>>>>>> routers gets that value may change after one of them > >>> reboots. If > >>>>>>>>> uptime is not considered, it will never change as long as > >>> one > >>>> router > >>>>>>>>> stays up at any given time. > >>>>>>>>> > >>>>>>>>> We are talking about a very low probability event (a > >>> duplicate) > >>>> except > >>>>>>>>> if this is a DoS attack and then either using or not using > >>> uptime > >>>>>>>>> won't matter since the attacker will claim an impossibly > >>> long > >>>> uptime. > >>>>>>>>> > >>>>>>>>> Curtis > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf From ginsberg@cisco.com Mon Feb 10 22:57:13 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 98CD71A07AF for ; Mon, 10 Feb 2014 22:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 3SzLttYsqKEy for ; Mon, 10 Feb 2014 22:57:08 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D41A0798 for ; Mon, 10 Feb 2014 22:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35122; q=dns/txt; s=iport; t=1392101828; x=1393311428; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RdyXTvJzOAOipfITUwaGtYFdGMzfcL5cZZ3Y7wIYnls=; b=lbZbNOyIpEsQF5k8ZrOWmrhM+qJz/dWa3LO5wQyVh1ex02plfb0ZU66S K6aVGhuETXAX6Y0vVM4QpzIgkTv4KzXjhRSn1DXHCArJJ2xHhxtptpQVO 5fJ+0Nmhyj27Bf0bkVbEbSdV5bd4osqNRIi+iXEvDgB6mAvGZIwiZmmdG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FABPJ+VKtJV2a/2dsb2JhbABQAwaDDDhXvmSBDRZ0giUBAQEDARoBHz8MBAIBCBEEAQEBChQJBzIUCQgCBA4DAggBEAIEh14IDclFF44VDQsSBisHAgSDHoEUBIxhkwyKXYMtQIFq X-IronPort-AV: E=Sophos;i="4.95,824,1384300800"; d="scan'208";a="303219679" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 11 Feb 2014 06:57:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1B6v6wh025972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 06:57:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 00:57:06 -0600 From: "Les Ginsberg (ginsberg)" To: "curtis@ipv6.occnc.com" Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJpsn/pYRbYVsxUaPEbmLjnjkwpqvmB4w Date: Tue, 11 Feb 2014 06:57:05 +0000 Message-ID: References: Your message of "Mon, 10 Feb 2014 08:28:10 +0000." <201402102003.s1AK3PQZ034418@maildrop2.v6ds.occnc.com> In-Reply-To: <201402102003.s1AK3PQZ034418@maildrop2.v6ds.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 06:57:13 -0000 Curtis - Inline... > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Monday, February 10, 2014 12:03 PM > To: Les Ginsberg (ginsberg) > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt >=20 >=20 > In message > "Les Ginsberg (ginsberg)" writes: >=20 > > Curtis - > > > > I think we are converging. > > > > Some context from my side... > > > > I am fully aware that this draft is about Homenet environments, but > > there is a suspicion in the back of my mind that once the duplicate-id > > resolution mechanism is defined and deployed that folks may want to > > use it in other environments e.g. TRILL has targeted auto-config as a > > goal (just an example). You may remember a few years ago a proposal to > > automatically resolve system-id conflicts was discussed in IS-IS > > WG. The proposal had a lot of flaws and we shot it down - but it does > > suggest that some folks may want to use such a mechanism in other > > types of deployments someday. So I would like to define things such > > that it is robust enough to be used elsewhere. And since what I am > > proposing is quite simple I don't think it unduly burdens the Homenet > > environments. >=20 > Providers tend to configure anything that is expected to be static. > At least the smart ones do. >=20 > But then maybe smart people don't run trill. :-) >=20 > I think the prior IS-IS autoconfig may have been motivated by IEEE use > of IS-IS for bridging. Again, not something providers use. >=20 > > As regards preserving router-id across reboots - sure - that is a good > > idea also. And what I am proposing is supportive of that because it > > guarantees that so long as an existing router's LSAs are in the LSDB > > (even if it is currently undergoing maintenance) any new router that > > comes up (or even another old router that reboots and is not so well > > behaved as to remember the router-id it previously used) will not take > > the router-id of any router seen in the LSDB (reachable or not). This > > is better than the existing logic which leaves the decision to chance. >=20 > The router today that can't remember anything between reboots is > likely to be a very low end home networking device with no > non-volitile strorage at all. Anything running OSPF or ISIS is likely > to be at least keeping a code image in flash and could keep a > router-id there too. There are various reasons the router-id may not be remembered across reboot= . The router may be low end w/o NVRAM. The router might have a bug in its implementation. The NVRAM might have gotten corrupted. But we need not care. The point is we can still minimize disruption to the = network by using the old/new paradigm - and that is a good thing. It is, of course, also a good thing for a router to retain its old identity= following reboot - I fully support that - and the old/new paradigm is comp= lementary to the retention of router-id across reboots. >=20 > > More inline. > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > Sent: Sunday, February 09, 2014 12:39 PM > > > To: Les Ginsberg (ginsberg) > > > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3= - > > > autoconfig-05.txt > > > > > > > > > Les, > > > > > > Perhaps you should read the abstract of the document you are > > > commenting about: > > > > > > SPFv3 is a candidate for deployments in environments where auto- > > > configuration is a requirement. One such environment is the IPv6 > > > home network where users expect to simply plug in a router and hav= e > > > it automatically use OSPFv3 for intra-domain routing. This > > > document describes the necessary mechanisms for OSPFv3 to be > > > self-configuring. > > > > > > Home network! > > > > > > Or the introductio: > > > > > > OSPFv3 [OSPFV3] is a candidate for deployments in environments > > > where auto-configuration is a requirement. > > > > > > [...] > > > > > > 1.2. Acknowledgments > > > > > > This specification was inspired by the work presented in the > > > Homenet working group meeting in October 2011 in Philadelphia, > > > Pennsylvania. > > > > > > The Homenet WG works on what? Home networks! > > > > > > So please keep that in mind when commenting. > > > > > > Unless a provider were to be so stupid or lazy to use this on a SP > > > network then most of the comments from both of us don't apply, > > > *except* the few comments below about "in a home network". > > > > > > Perhaps the draft should add text explicitly stating that the last > > > router-id used successfully should be used on a reboot rather than a > > > new random number. I notice that only the Router-Hardware-Fingerprin= t > > > TLV is persistent across reboots. This is insufficient if we want to > > > minimize disruption. > > > > > > The only case then (if router-id is remembered across reboots) would > > > be a new router. > > > > Also a router which fails to remember its old router-id across a reboot= . >=20 > See above. Seems very broken to not be able to remember a router-id > across reboot. What today doesn't have any flash at all? If > anything, what in an SP net? (nothing). >=20 > > > In that case your uptime rule would help. So > > > perhaps two things could be reocmmended: > > > > > > 1. In section 4, include a "SHOULD remember the most recent > > > successfully used router-id across reboots and reuse that". > > > Reword the rest so if that information is not available, then > > > pick a random number. > > > > Fine with me. > > > > > > > > 2. a. In section 6, mention the uptime rule. Modify the Router > > > Uptime TLV as suggested. > > > > > > b. Alternately add a flag to the Router-Hardware-Fingerprint > > > TLV that indicates that since last reboot this router-id has > > > been used and acheived a "full state". A router just > > > rebooting would not have ever reached the full state before > > > noticing a conflict as long as the conflct check is run > > > before considering itself in the full state. > > > > Yes - this is what I had in mind. Also note we need a flag in hellos > > as well - for which I had proposed using an option bit (or LLS if > > folks don't want to consume an options bit). >=20 > I'm not sure for OSPF at least why you need a flag in hello. You need a flag in the hello because you cannot form an adjacency to "yours= elf". So if duplicate router-id occurs with a neighbor it needs to be resol= vable w/o depending on having the LSDB. This is also why Sections 6.1 and 6= .2 exist in the draft. >=20 > > But what is your definition of "full state"? It cannot be just having > > reached "full state" with a single neighbor as it is possible the > > first neighbor that comes up might also be in the process of coming up > > itself and does not yet have the full LSDB. What I had in mind was a > > short but sufficient time that if we had been up for that long we > > could be comfortable that our existence was known network-wide. I had > > mentioned 20 minutes - but that was quite a conservative number - I > > think we could safely be more aggressive (5 minutes??). Once that > > period had passed we set the flag and leave it set. And if we are > > smart enough to reuse the same router-id following reboot when we get > > our own Fingerprint from our old incarnation we will see that the flag > > is set and can therefore set it immediately following reboot without > > waiting for 5 minutes. >=20 > The full state is a state in OSPF when the LSDB download between a > pair of routers has completed. >=20 > The assumption is that we have a "full state" bit in the > Router-Hardware-Fingerprint TLV defined above. Taking in your concern > over becoming full with another router that doesn't have a full LSDB, > procedure when the router is not full is then: >=20 > 1. An adjacency becomes "full" (formal state in OSPF). >=20 > 2. Check to see if the neighbor router is "full" in its > Router-Hardware-Fingerprint TLV: >=20 > a. If not, and other neighbor adjacncies are not in the full > state wait for others neighbor states to become full. >=20 > b. If all neighbor adjacencies are in the full state, and none > of the neighbor routers is in the full state in its > Router-Hardware-Fingerprint TLV, then continue. >=20 > c. If the neighbor's Router-Hardware-Fingerprint TLV indicates > the full state, continue. >=20 > 3. Check for router-id collisions. >=20 > a. If no collision, set full and done. >=20 > b. If a collision, continue. >=20 > 4. Check the flags in the Router-Hardware-Fingerprint TLV of the > router for which a collision has occurred. >=20 > a. If the collision is with a full router, then pick new > router-id and start over. >=20 > b. If the collision is with a router that is marked as having > been use successfully in the past and the router-id being > used by this router was a random pick, then pick new > router-id and start over. >=20 > c. Otherwise it is a tie and continue. >=20 > 5. In the event of a tie, use the tie breaker rules as defined in > the existing draft (lowest fingerprint wins). >=20 > Don't readvertise any LSDB entry from a neighbor router until it > resends its Router-Hardware-Fingerprint TLV with the full state > indicated. This will avoid a collision prior to the newly rebooted > router reaching the full state and possibly giving up on its first > pick or router-id. >=20 > If a neighbor for which the adjacency is in the full state indicates > that it has become "full", go to step 3 if not already in the full > state. >=20 > Note that 2b covers the case where no router in the entire network has > declared itself in the full state (the network epoch). 2a covers most > cases where the neighor has a partial LSDB. >=20 > This could have been a bit simpler if we didn't want to cover most > cases where the neighbor didn't have a full LSDB. This is unnecessarily complex - and introduces some requirements that Acee = has quite understandably expressed concern about. Old/new state should be based quite simply on a minimum uptime - say 5 minu= tes. If I can't acquire the full LSDB in 5 minutes the network is already c= ompromised in some way - having to perform an unnecessary router-id change = is the least of our problems. Also note that the persistence of a router-id for a router that had been op= erational but is currently undergoing maintenance lasts for as long as its = LSAs persist in the LSDB (one hour) i.e., even if a new router detects a du= plicate router-id based on an LSA originated by a router that is currently = down it follows the old/new rules in determining whether it should change i= ts router-id. If a router is down for longer than one hour it no longer has a "reservatio= n" on the router-id it previously used - so it is possible (though of cours= e still unlikely) that a new router could come along and usurp the router-i= d of the router undergoing maintenance after its LSAs have been purged. Thi= s is fine and even preferable as whenever the old router finally comes back= to life it will be more disruptive to force the other router which "has be= come old" to change its router-id. >=20 > > The significance of the time interval is only to define the period > > during which if we are unlucky enough to have two new routers come up > > within that interval and happen to pick the same router-id that we > > will defer to the fingerprint/link local address tie breaker i.e. both > > routers are considered "new" and so neither one has staked a claim > > yet. >=20 > The above can do this without a time interval. With just flag bits, > there is no need to readvertise any LSA to update a time interval, > only a need to update the "full state" bit after getting to the full > state. I have stated repeatedly that I do not want to advertise an "interval" that= needs periodic updating. I simply want a boolean that indicates greater th= an or less than the minimum interval has passed since a router came up and = successfully chose a router-id (i.e. no duplicates detected). Please take note of my position on this. :-) Les >=20 > > If you and I are now in consensus (as I think we are), it is time for > > the authors of the draft to weigh in and if they agree update the > > draft with the specifics. > > > > Les >=20 > Very rough concensus but only that the problem is easily solvable, not > on the specific solution. >=20 > Curtis >=20 > > > Note: A second flag bit indicating that this router-id had > > > been used successfully in a past reboot might also help but > > > would only matter among two routers both rebooting and > > > neither having reached the full state. > > > > > > I think #1 above is sufficient and does more to prevent surprises. I > > > think #2 above helps only in the new router case but #2a requires > > > adding a TLV and so isn't worth it IMHO. Case #2b accomplished the > > > same thing with only a flag. I would not object to #2b above if #1 > > > above is also added. > > > > > > See inline anyway. > > > > > > In message x02.cisco.com> > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > Curtis - > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > > Sent: Saturday, February 08, 2014 7:30 AM > > > > > To: Les Ginsberg (ginsberg) > > > > > Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- > ospfv3- > > > > > autoconfig-05.txt > > > > > > > > > > > > > > > In message > > x02.cisco.com> > > > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > > > > Curtis - > > > > > > > > > > > > Your reply below is talking about things which I think do not > directly > > > > > > bear on the value add of what I have proposed. > > > > > > > > > > > > You mention various ways to insure that a given device assigns = the > > > > > > same router-id each time it starts up and ways to insure it pic= ks > the > > > > > > same sequence of second/third... choices in the event it has to > change > > > > > > its router-id. All good suggestions, but what I am talking abou= t is > > > > > > what we do in the event a conflict occurs despite our best effo= rts > to > > > > > > avoid it. With the current draft content preference is based so= lely > on > > > > > > a fixed identifier (fingerprint) without regard to which choice > would > > > > > > minimize disruption to the network. When preference is given to= the > > > > > > "old router" to retain its existing router-id this shortcoming = is > > > > > > addressed. > > > > > > > > > > In the lifetime of a router it only gets added once. In the life= time > > > > > of a router we would hope it only reboots zero time but experienc= e so > > > > > far has been that reboots over a router's lifetime tend to be > 0= and > > > > > in some cases >> 0. > > > > > > > > > > So you are optimizing for a 1 in 4 billion occurance that can hap= pen > > > > > only once in the lifetime of a router. > > > > > > > > The entire duplicate router-id resolution logic is addressing the > > > > improbable case. My proposal adds - literally - one line of code t= o > > > > the logic used to decide whether "I" should change my router-id or > > > > whether "you" should change your router-id. > > > > > > > > > > > > > > We also need to look at the consequences of this very improbably > > > > > occurance. Today's routers accomplish IGP convergence in large > > > > > networks in subsecond times, in some cases << 1 second. > > > > > > > > > > Note that if flooding is completed (both withdraw old and install > new) > > > > > in less than the SPF delay which is commonly implemented (some de= lay > > > > > after receiving the first flooded IGP change), then there is no > impact > > > > > on routing. > > > > > > > > Your analysis does not apply to this scenario. The router which > > > > changes its router-id is effectively doing a cold start. All > > > > adjacencies will go down. All LSAs originated by this router becom= e > > > > invalid. All routes will be removed from the forwarding plane. If > > > > you are running BGP all the BGP nexthops will be gone on the route= r > > > > which is changing its identity. Restoration of the adjacencies and > > > > reacquisition of the LSDB will take multiple seconds. The best you > > > > can hope for is several seconds of disruption - it could easily be > > > > much longer. > > > > > > > > For the new node which has usurped the old node's identity it will > > > > have to purge/replace all of the LSAs generated by the old > > > > node. While normal operation of the update process will insure tha= t > > > > this happens in a reliable way the amount of flooding network-wide > > > > required to bringup a new node has now been roughly doubled > > > > i.e. the old node must reissue all of its LSAs using a new identit= y > > > > and the new node must purge/replace the old node's LSAs with its > > > > own versions. This will result in multiple SPFs on all nodes in th= e > > > > network and likely cause loops/blackholes during the transition > > > > since some of the SPFs will be run on versions of the LSDB which > > > > are inaccurate (part old node's old LSAs and part new node's > > > > LSAs). Suggesting that this could be handled in the same way/time > > > > as we typically handle a single link failure isn't credible. > > > > > > All routers are supposed to keep a fixed router-id across reboots. I= f > > > interfaces are changed when down, the last used router-id should be o= n > > > flash. If flash is removed and replaced (rather than a new image > > > installed), then with the same set of interfaces, the same decision > > > should be made. We are down to a very special case where both flash > > > and interfaces are removed and replaced yielding no history and a > > > different set of MACs to pick from. > > > > > > > > > Your statement that what I propose is only relevant when two > routers > > > > > > go down does not match the scenarios I envision. If I want to a= dd a > > > > > > new device to my network or if I need to replace an existing de= vice > in > > > > > > my network I am only affecting one device - but as I am introdu= cing > a > > > > > > device with a new fingerprint it is possible that it will intro= duce > a > > > > > > conflict with an existing router-id. > > > > > > > > > > In provider networks routers are generally added during maintenan= ce > > > > > windows so should anything unexpected happen, impact is minimized= . > > > > > > > > > > In home nets, the home user isn't going to notice the convergence > time > > > > > if there is any. A 10 msec SPF delay is likely to be plenty. > > > > > > > > As I stated above, disruption will be orders of magnitude longer th= an > 10 > > > ms. > > > > > > In a home net? With perhaps a half dozen routers and a default route= ? > > > Someone has a very bad OSPF implementation. :-) Or did you miss the > > > "In home nets" at the front of the paragraph. > > > > > > For example, in a 10 node network with average degree 4, perhpas 40 > > > links in 10 router LSA exist. A few RTT (less than 1 msec for a > > > homenet) for each neighbor adjacency (which happen in parallel) and > > > ten packets from 4 sources is needed to reach the full state followed > > > by one SPF to be fully up and running. Other routers get one > > > additional router LSA plus four new links in existing router LSA and > > > have to run an SPF. Even on a software based homenet router using an > > > ARM, 10 msec is likely to be enough time and if it is "orders of > > > magnitude" longer, something is wrong with one of the implementations= . > > > This would be an more complicated than usual home net or even soho, > > > more likely a small business. > > > > > > > > > In a subsequent reply you liked the idea of the new device dela= ying > > > > > > advertising reachability until it is has determined that its > router-id > > > > > > choice is not in conflict. The old/new router paradigm supports > this > > > > > > strategy by assuring that the old router will not consider chan= ging > > > > > > its router-id until enough time has elapsed for the new router = to > > > > > > transition to being an old router. > > > > > > > > > > If it wins the coin toss, the router would advertise at least one= LSA > > > > > to indicate its existance and could hold back on any additional > > > > > advertisements until the other router has withdrawn routes. > > > > > > > > > > > > > This suggestion does not alter the fact that if the old node change= s > > > > > > its router-id the network has to respond to three events: > > > > > > > > 1)Loss of the old node > > > > 2)Introduction of the old-node with a new identity > > > > 3)Introduction of the new node with the identity of the old-node > > > > > > Again, the old node should remember the last router-id used and try t= o > > > reuse it. > > > > > > > If however we insure that the old-node does not change its identity > > > > then the network only has to respond to a single event - the > > > > introduction of the new-node. > > > > > > Yes and if it were up and won the resolution last time, it will have > > > saved that router-id and will reuse it. If it came up previously and > > > lost the resolution, then it will remember the router-id it used, > > > whether second or third pick, and use that. > > > > > > > > > Finally, what I propose is extremely simple to implement. I thi= nk > it > > > > > > isn't much of an exaggeration to say that any one of us could h= ave > > > > > > implemented the enhancement in the time it has taken to discuss= its > > > > > > merits. So we aren't overengineering for a case which is admitt= edly > > > > > > very unlikely to occur - we are adding a modest extension to ma= ke > our > > > > > > solution less disruptive. > > > > > > > > > > Yes but it it *bad* for the more common case where routers go dow= n > > > > > occasionally. > > > > > > > > You are going to have to clarify exactly what "bad side effects" yo= u > > > > see for what I propose - because I don't see any - whereas I do > > > > see benefits as described above. > > > > > > If router-id is not remembered between reboots, then there is the one > > > in 4 billion time number of routers (less than 10 for a home net > > > today, but maybe more in the future). > > > > > > If router-id is remembered between reboots, then no matter how long a > > > router has been down, if nothing else in the network changed, there i= s > > > zero chance of having a collision. > > > > > > With either method, if router-id is remembered between reboots, then > > > there is zero chance of collision. > > > > > > IMO should this ever be used on a managed network (including a home > > > net / soho / small business net that happens to be managed) then > > > having routers come back from a reboot with the same router-ids would > > > be a big plus. For example, after a power outage NMS discovery would > > > not have to be repeated. > > > > > > > Les > > > > > > > > > > > > > > > > > > > Les > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > > > > > Sent: Friday, February 07, 2014 9:22 AM > > > > > > > To: Les Ginsberg (ginsberg) > > > > > > > Cc: Acee Lindem; Curtis Villamizar; OSPF List > > > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-osp= f- > > > ospfv3- > > > > > > > autoconfig-05.txt > > > > > > > > > > > > > > > > > > > > > In message > > > > x02.cisco.com> > > > > > > > "Les Ginsberg (ginsberg)" writes: > > > > > > > > > > > > > > > > So, I am one person who raised this concern to Acee - but t= he > > > proposal > > > > > > > > outlined by Acee is not what I had in mind. There is no nee= d to > use > > > > > > > > "uptime" or to invent some unusual exchange of LSAs prior t= o > > > Exchange > > > > > > > > state. > > > > > > > > > > > > > > > > Also, in regards to Curtis's comment - it is not DOS attack= s > that I > > > am > > > > > > > > trying to mitigate here. As he says if an attacker is in yo= ur > > > network > > > > > > > > and able to originate credible packets no strategy is safe. > > > > > > > > > > > > > > > > The motivating use case is to minimize disruption of a stab= le > > > network > > > > > > > > when a new router is added or an existing router is > > > > > > > > replaced/rebooted. In other words non-disruptive handling o= f > the > > > > > > > > common maintenance/upgrade scenarios. > > > > > > > > > > > > > > > > What I have in mind is this: > > > > > > > > > > > > > > > > 1) A router needs a way to advertise that it has been up an= d > > > running > > > > > > > > for a minimum length of time - for the sake of discussio= n > let's > > > say > > > > > > > > 20 minutes. Routers then fall into two categories: > > > > > > > > > > > > > > > > o Old routers (up >=3D minimum time) > > > > > > > > o New routers (up < minimum time) > > > > > > > > > > > > > > > > 2) When a duplicate router-id is detected, the first tie > breaker is > > > > > > > > between old routers and new routers. The old router gets= to > keep > > > > > > > > its router-id and the new router picks a new router-id. = If > both > > > > > > > > routers are "new" or both routers are "old" then we reve= rt > to > > > the > > > > > > > > existing tie breakers defined in the document (link loca= l > > > address > > > > > > > > for directly connected routers and fingerprint info for > > > > > > > > non-neighbors). > > > > > > > > > > > > > > > > 3) Advertisement of the "old/new" state requires a single b= it - > but > > > it > > > > > > > > has to be available both in hellos and the new AC-LSA. > Adding it > > > to > > > > > > > > the AC-LSA is easy to do. For hellos, there are two > > > possibilities: > > > > > > > > > > > > > > > > o Use one of the Options Bits > > > > > > > > o Use LLS > > > > > > > > > > > > > > > > Be interested in how folks feel about this. > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > Les, > > > > > > > > > > > > > > Excluding DoS attack, we are talking about a one in 4 billion > case > > > > > > > (for any two routers, so with 400 routers, still well under o= ne > in > > > 1M) > > > > > > > where two routers hash a MAC address or pick a one time rando= m > number > > > > > > > from out of nowhere and end up with the same number. > > > > > > > > > > > > > > If that does happen (and one in 1M is certainly possible), th= en > it > > > > > > > would be nice if the routers always ended up with the same > router-id. > > > > > > > This could be accomplished by some fixed method such as hashi= ng a > > > > > > > constant with the first choice or router-id or using the rout= er- > id as > > > > > > > a seed for the random number generator (which will pick the s= ame > > > > > > > sequence of random numbers each time). If this is done, then= a > > > > > > > conflict would always produce the same set of next picks. Th= e > set of > > > > > > > routers in a given network would always end up with the same > > > > > > > router-ids once they all came up and if only one went down at= a > time > > > > > > > then it would always end up with the same router-id when it c= ame > up. > > > > > > > > > > > > > > Zero conf was mainly intended for unmanaged networks (motivat= ed > by > > > > > > > work in the homenet WG). In these small unmanaged networks i= t > > > doesn't > > > > > > > matter which router gets what router-id as long as they end u= p > unique > > > > > > > and convergence is in a reasonable time relative to keeping > eyeballs > > > > > > > happy. It could be applied to enterprise or providers but in > either > > > > > > > case having the routers end up with the same router-ids would > make > > > for > > > > > > > easier management. > > > > > > > > > > > > > > For your scenario to matter at all with current rules, both > routers > > > in > > > > > > > the conflict would have to go down. If only the one that is > > > preferred > > > > > > > goes down, the other is not going to change its router-id as = a > result > > > > > > > so when it comes up it gets its first pick with no conflict. = If > the > > > > > > > one that was not preferred goes down, it comes up, sees a > conflict > > > and > > > > > > > takes its second pick (loses the conflict every time). It is > only if > > > > > > > they both go down and the one that normally loses the conflic= t > comes > > > > > > > up first that there is a change in router-id. That too can b= e > solved > > > > > > > with a rule that you always come up with the last router-id u= sed. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Ac= ee > > > Lindem > > > > > > > > > Sent: Thursday, February 06, 2014 5:12 PM > > > > > > > > > To: Curtis Villamizar > > > > > > > > > Cc: OSPF List > > > > > > > > > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf= - > ospf- > > > > > ospfv3- > > > > > > > > > autoconfig-05.txt > > > > > > > > > > > > > > > > > > Hi Curtis, > > > > > > > > > I agree and believe the significance of this use case whe= re a > new > > > > > router > > > > > > > is > > > > > > > > > inserted into an auto-configured domain has been greater > > > exaggerated. > > > > > > > > > Thanks, > > > > > > > > > Acee > > > > > > > > > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In message > > > > > > > > > > Acee Lindem writes: > > > > > > > > > > > > > > > > > > > >> The OSPFv3 autoconfiguration draft was cloned and > presented in > > > the > > > > > > > > > >> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-co= nf- > > > 00.txt). > > > > > In > > > > > > > > > >> the ISIS WG, there was a concern that the resolution o= f a > > > > > duplicate > > > > > > > > > >> system ID did not include the amount of time the route= r > was > > > > > > > > > >> operational when determining which router would need t= o > choose > > > a > > > > > new > > > > > > > > > >> router ID. With additional complexity, we could > incorporate > > > router > > > > > > > > > >> uptime into the resolution process. One way to do this > would > > > be > > > > > to: > > > > > > > > > >> > > > > > > > > > >> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. I= t > would > > > > > include > > > > > > > > > >> the uptime in seconds. > > > > > > > > > >> > > > > > > > > > >> 2. Use the Router Uptime TLV as the primary > determinant in > > > > > > > > > >> deciding which router must choose a new OSPFv3 > Router > > > > > > > > > >> ID. Router uptimes less than 3600 (MaxAge) seco= nds > > > apart > > > > > are > > > > > > > > > >> considered equal. > > > > > > > > > >> > > > > > > > > > >> 3. When an OSPFv3 Hello is received with a differe= nt > link- > > > > > local > > > > > > > > > >> source address but a different router-id, unicast= the > > > > > OSPFv3 > > > > > > > > > >> AC-LSA to the neighbor so that OSPFv3 duplicate > > > router > > > > > > > > > >> resolution can proceed as in the case where it is > > > received > > > > > > > > > >> through the normal flooding process. This is some= what > > > of a > > > > > > > > > >> hack as the we'd also need to accept OSPF Link St= ate > > > > > Updates > > > > > > > > > >> from a neighbor that is not in Exchange State or > > > greater. > > > > > > > > > >> > > > > > > > > > >> An alternative to #3 would be to use Link-Local Signal= ing > > > (LLS) > > > > > for > > > > > > > > > >> signaling the contents of the OSPFv3 AC-LSA. However, > you'd > > > only > > > > > want > > > > > > > > > >> to send the Router-Uptime and Router Hardware Fingerpr= int > when > > > a > > > > > > > > > >> duplicate Router-ID is detected. This requires > implementing > > > the > > > > > > > > > >> resolution two ways but may be preferable since it doe= sn't > > > require > > > > > > > > > >> violating the flooding rules. > > > > > > > > > >> > > > > > > > > > >> In any case, I'd like to get other opinions as to whet= her > this > > > > > problem > > > > > > > > > >> is worth solving. > > > > > > > > > >> > > > > > > > > > >> Thanks, > > > > > > > > > >> Acee > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Acee, > > > > > > > > > > > > > > > > > > > > If the basis for router-id on boot up results in a fixe= d > value, > > > and > > > > > if > > > > > > > > > > a duplicate will occur on a give network, then which of= two > > > > > duplicate > > > > > > > > > > routers gets that value may change after one of them > reboots. > > > If > > > > > > > > > > uptime is not considered, it will never change as long = as > one > > > > > router > > > > > > > > > > stays up at any given time. > > > > > > > > > > > > > > > > > > > > We are talking about a very low probability event (a > duplicate) > > > > > except > > > > > > > > > > if this is a DoS attack and then either using or not us= ing > > > uptime > > > > > > > > > > won't matter since the attacker will claim an impossibl= y > long > > > > > uptime. > > > > > > > > > > > > > > > > > > > > Curtis From ppsenak@cisco.com Tue Feb 11 00:43: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 7B1C71A0907; Tue, 11 Feb 2014 00:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 bfsy76XCLWvt; Tue, 11 Feb 2014 00:43:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 714BE1A08F5; Tue, 11 Feb 2014 00:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5936; q=dns/txt; s=iport; t=1392108220; x=1393317820; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Y8iYoi4B9KumLALNZgI2U5knN+eczryrp1hzXSj7HAM=; b=Mu96IhqOxb0yeFRdpZzMUoEHV06YbdG4FlYceJk0ObpNUbp+wf72yg7o bX97aPQEICrsce9III19Gx4DKPmZaLjGoNEwUV7FVdn6KpqCPAVxZHBOT Ec2MrDm9QdZfSgMcY7lEDkEmYIGdFKF2DD2d2Lmjiq96uOYkTUozLnciN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAHvh+VKQ/khN/2dsb2JhbABZgwyEELtkgQ0WdIIlAQEBAwEjDwEFPwEBEAkCEgYCAgUMCggDAgIJAwIBAgE0Aw4GDQEFAgEBF4diCIw1m3+gHxeBKY1QBwqCZYFJAQOYKoZHi1mBb4E/Ow X-IronPort-AV: E=Sophos;i="4.95,824,1384300800"; d="scan'208";a="4202322" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 11 Feb 2014 08:43:39 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1B8hc9R030981; Tue, 11 Feb 2014 08:43:38 GMT Message-ID: <52F9E2BA.4000201@cisco.com> Date: Tue, 11 Feb 2014 09:43:38 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08248329@NKGEML512-MBS.china.huawei.com> <52E61BAF.2060208@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08248431@NKGEML512-MBS.china.huawei.com> <52E63015.5090404@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082493BE@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824948F@NKGEML512-MBS.china.huawei.com> <52E8C589.9010408@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082494C6@NKGEML512-MBS.china.huawei.com> <52E8C8A2.8060306@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082494F0@NKGEML512-MBS.china.huawei.com> <52E8D7E2.2030100@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824BC7E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824BC7E@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "ospf@ietf.org" , "spring@ietf.org" Subject: Re: [OSPF] [spring] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 08:43:45 -0000 Hi Xuxiaohu, please see inline: On 2/11/14 03:12 , Xuxiaohu wrote: > Hi Peter, > > Sorry for late response due to a long holiday. > >> -----邮件原件----- >> 发件人: Peter Psenak [mailto:ppsenak@cisco.com] >> 发送时间: 2014年1月29日 18:29 >> 收件人: Xuxiaohu >> 抄送: ospf@ietf.org; spring@ietf.org >> 主题: Re: [spring] [OSPF] fwd: New Version Notification for >> draft-xu-ospf-global-label-sid-adv-00.txt >> >> Xuxiaohu, >> >> On 1/29/14 10:58 , Xuxiaohu wrote: >>> >>> >>>> -----邮件原件----- >>>> 发件人: Peter Psenak [mailto:ppsenak@cisco.com] >>>> 发送时间: 2014年1月29日 17:24 >>>> 收件人: Xuxiaohu >>>> 抄送: ospf@ietf.org; spring@ietf.org >>>> 主题: Re: [spring] [OSPF] fwd: New Version Notification for >>>> draft-xu-ospf-global-label-sid-adv-00.txt >>>> >>>> Xuxiaohu, >>>> >>>> On 1/29/14 10:16 , Xuxiaohu wrote: >>>>> >>>>> >>>>>> -----邮件原件----- >>>>>> 发件人: Peter Psenak [mailto:ppsenak@cisco.com] >>>>>> 发送时间: 2014年1月29日 17:11 >>>>>> 收件人: Xuxiaohu >>>>>> 抄送: ospf@ietf.org; spring@ietf.org >>>>>> 主题: Re: [spring] [OSPF] fwd: New Version Notification for >>>>>> draft-xu-ospf-global-label-sid-adv-00.txt >>>>>> >>>>>> Xiaohu, >>>>>> >>>>>> On 1/29/14 09:53 , Xuxiaohu wrote: >>>>>>> For example, assume a label block {1000, 1999} is allocated for >>>>>>> prefix >>>>>> segments by almost all SR routers and a global label 1005 is >>>>>> allocated to a given prefix segment, for a given seldom SR router >>>>>> which couldn't preserve the above label block and allocates a >>>>>> different label block (e.g., {2000, 2999}) instead, a local label >>>>>> corresponding to that global label (or that prefix segment) could >>>>>> be calculated through offsetting, i.e., the result is 1005+ >>>>>> (2000-1000)=2005. In this way, there is no need for introducing the >>>>>> Index concept anymore and therefore the architecture becomes much >>>>>> easy to understand. More importantly, compared to the index binding >>>>>> advertisement, the label binding advertised by the IGP is exactly >>>>>> the same as that in the label forwarding table for those most SR >>>>>> routers which have allocated the above common label block, which is >>>>>> much >>>> beneficial when doing troubleshooting. This approach does not violate >>>> the strongest MPLS dogma (i.e., labels MUST be local) while! >>>>>> taking in >>>>>> to account the actual situation, IMHO >>>>>> >>>>>> above would require the "seldom SR router" to know the offset from >>>>>> the SRGB used by other routers. How do you envision that to be learned? >>>>> >>>>> Hi Peter, >>>>> >>>>> I don't think it's a big problem. The common SRGB could either be >>>>> manually >>>> configured on the seldom SR router or advertised by the MS. >>>> >>>> manual configuration is not an option - just imagine you have >>>> multiple "seldom SR routers", each having a different label block. >>>> Now you not only need an offset for "common" block, but also offset >>>> between label blocks used on these "seldom SR routers". >>> >>> Peter, >>> >>> Why do you need offset between label blocks used on these seldom SR routers? >> The common block is the only frame of reference, IMO. >> >> let's imagine you have two "seldom SR routers", A and B, directly connected. A is >> using label block 1000-2000, B is using 2000-3000. For simplicity, let's assume >> rest of the routers use the block 0-1000. >> >> Now let's imagine you have a prefix X, which is advertised with label 25 from a >> router that uses the common block (0-1000). On A you configure the offset >> +1000, so it allocate a local label of 1025 for X. Now A wants to send a traffic for >> X via B. You would have to configure on A the offset of B as +2000 (against the >> common block) or as +1000 (against the A's block), so when A sends a traffic to > > Only against the common block since it is the only frame of reference. 'only' is a bit misleading here. The bottom line is that on each router that peers with 'seldom SR' router, there would need to be a specific config added - IMHO that is not an acceptable solution. > >> B, it will use label 2025. >> No matter which method of specifying the offset you use, the point is that on A >> you need to know the offset of all "seldom SR" routers that you may end up >> sending traffic to - either directly, or indirectly. Such a configuration model does >> not scale. > > Those "seldom SR" routers would advertise their own blocks. And only those "seldom SR" routers need to advertise their own blocks. In this way, there is no need to introduce the index space anymore, and therefore the architecture and the troubleshooting become much simpler given the assumption that only seldom SR routers could not allocate that common block. I believe it is simpler from both implementation and deployment perspective to consistently advertise the block from all routers. thanks, Peter > > Best regards, > Xiaohu > >> >>> >>>> Once you start to advertise it, you are back to the model we have >>>> already, but you made it even worse with offsets. >>> >>> I don't think so. Take the above situation as an example, in the index binding >> mode, you could allow the most SR routers to advertise its label range starting >> with zero to achieve the above effect (although it conflicts with the definition of >> label range). However, for the seldom SR router, what label range should it >> advertise? >> >> the simplest model is for every router (seldom or common) to advertise its label >> block. > >> regards, >> Peter >> >>> >>> Best regards, >>> Xiaohu >>> >>>> regards, >>>> Peter >>>> >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> regards, >>>>>> Peter >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Xiaohu >>>>> >>> > From acee.lindem@ericsson.com Tue Feb 11 07:37:35 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 9BA031A01A8 for ; Tue, 11 Feb 2014 07:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T08s3huD7x3t for ; Tue, 11 Feb 2014 07:37:33 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 152DF1A0547 for ; Tue, 11 Feb 2014 07:37:33 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-6f-52fa43bd425a Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 95.8B.11484.DB34AF25; Tue, 11 Feb 2014 16:37:33 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 10:37:32 -0500 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-01.txt Thread-Index: AQHPJmycIp0kYBy+tUu8JJjgskR8WA== Date: Tue, 11 Feb 2014 15:37:31 +0000 Message-ID: References: <20140210143006.2947.26102.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_B2E2D40197AE46C29E4747578B0A9DE3ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPiO5e519BBov/yFu03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK5eyYJ2h4prs7qYGxifWnQxcnJICJhIvLvexARhi0lcuLee rYuRi0NI4AijxIc3uxghnOWMEouam1hAqtgEdCSeP/rHDGKLCMhKLF2ynxXEFhYIlVi5aikb RDxU4t+8DlYIW09i7u8lYBtYBFQlrm3oArN5Bewljt+YwghiCwk4SNzb9QTMZgS64vupNWA1 zALiEreezIe6TkBiyZ7zzBC2qMTLx/9YIWwliTmvrzFD1CdLrN36mB1ivqDEyZlPWCYwCs9C MmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfAYqJcDyLaWWDXJF1nJAkaOVYwcpcWpZbnp RoabGIFxckyCzXEH44JPlocYpTlYlMR5v7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA KBsz681cq4x9k/XrPUUkEnVlXv4J1ap3OjjHhJ/16+PX5QXZL2ziIhdtVsrdcz/JdelKLRmZ aMvNIbaL+qdHtZTYrYvYV236U+mF761N8oc03lR4rdd4IGEo3P7u3u4Hb/3qGQyzn7nv/znt /cw+cx0dlo9T9dnXx2bcOfgrY+bUlWe2JDKHKLEUZyQaajEXFScCAKVAnmxhAgAA Subject: [OSPF] Fwd: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:37:35 -0000 --_000_B2E2D40197AE46C29E4747578B0A9DE3ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This version includes the backward compatibility mechanisms needed for non-= disruptive deployment. It also extends these mechanisms so that an area can= be migrated independently. I will be presenting these mechanisms at IETF 89 in London. Thanks, Acee Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-ospf-ospfv3-lsa-extend-01.= txt Date: February 10, 2014 at 9:30:06 AM EST To: Acee Lindem >= , Sina Mirtorabi >, Sina Mirtorabi >, Fred Baker >, Fred Baker >, Abhay R= oy >, Abhay Roy >, Acee Lindem > A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-01.txt has been successfully submitted by Acee Lindem and posted to the IETF repository. Name: draft-ietf-ospf-ospfv3-lsa-extend Revision: 01 Title: OSPFv3 LSA Extendibility Document date: 2014-02-10 Group: ospf Pages: 32 URL: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-= lsa-extend-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa= -extend/ Htmlized: http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-exten= d-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-l= sa-extend-01 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 LSA. This document extends the LSA format by allowing the optional inclusion of Type-Length- Value (TLV) tuples in the LSAs. Backward compatibility mechanisms are also described. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_B2E2D40197AE46C29E4747578B0A9DE3ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0CA07B69CD114F4580FF2E00C7F82E3F@ericsson.com> Content-Transfer-Encoding: quoted-printable This version includes the backward compatibility mechanisms needed for non-= disruptive deployment. It also extends these mechanisms so that an area can= be migrated independently. 
I will be presenting these mechanisms at IETF 89 in London. 
Thanks,
Acee 

Begin forwarded message:

Subje= ct: New Version Notification= for draft-ietf-ospf-ospfv3-lsa-extend-01.txt
Date:= February 10, 2014 at 9= :30:06 AM EST
To: <= /b>Acee Lindem <acee.lindem@ericsson.com>, Sina= Mirtorabi <sina@cisco.com>, Sina Mirtorabi <sina@cisco.com>= ;, Fred Baker <fred@cisco.com>,= Fred Baker <fred@cisco.com>, A= bhay Roy <akr@cisco.com>, Abhay Roy <akr@cisco.com>, Acee= Lindem <acee.lindem@ericsso= n.com>


A new version of I-D, draft-ietf-ospf-ospfv3-lsa-extend-01.txt
has been successfully submitted by Acee Lindem and posted to the
IETF repository.

Name: draft-ietf-ospf-= ospfv3-lsa-extend
Revision: 0= 1
Title: OSPFv3 LSA Exte= ndibility
Document date: 2014-02-10
Group: ospf
Pages: 32
URL:            http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-lsa-ex= tend-01.txt
Status:         https://datatr= acker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
Htmlized:       http://tools.ietf.org/html/d= raft-ietf-ospf-ospfv3-lsa-extend-01
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-lsa-extend-01

Abstract:
  OSPFv3 requires functional extension beyond what can readily be= done
  with the fixed-format Link State Advertisement (LSA) as describ= ed in
  RFC 5340.  Without LSA extension, attributes associated wi= th OSPFv3
  links and advertised IPv6 prefixes must be advertised in separa= te
  LSAs and correlated to the fixed-format LSA.  This documen= t extends
  the LSA format by allowing the optional inclusion of Type-Lengt= h-
  Value (TLV) tuples in the LSAs.  Backward compatibility me= chanisms
  are also described.




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

The IETF Secretariat


--_000_B2E2D40197AE46C29E4747578B0A9DE3ericssoncom_-- From acee.lindem@ericsson.com Tue Feb 11 07:48:11 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 E2F1E1A03AD for ; Tue, 11 Feb 2014 07:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tSpVxctOslUY for ; Tue, 11 Feb 2014 07:48:03 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E76FB1A0308 for ; Tue, 11 Feb 2014 07:48:02 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-ae-52fa46324224 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 90.4C.11484.2364AF25; Tue, 11 Feb 2014 16:48:03 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 10:48:01 -0500 From: Acee Lindem To: "Les Ginsberg (ginsberg)" Thread-Topic: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt Thread-Index: AQHPJvKvDZC46wJbXkCKRaaCM5Q+rZqwhy6A Date: Tue, 11 Feb 2014 15:48:00 +0000 Message-ID: <5BB4C965-AAD7-43EB-836A-8463B7D513C8@ericsson.com> References: <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_5BB4C965AAD743EB836A8463B7D513C8ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPrK6x268gg64jwhbTbk1ns9jwZyO7 Rcu9e+wOzB5Tfm9k9Viy5CeTx4dFF1gDmKO4bFJSczLLUov07RK4Ml62PWIv2LyGpaLh9Bum BsYFF5m7GDk5JARMJLY8OMMCYYtJXLi3nq2LkYtDSOAIo8TTl+8ZIZzljBJ/Tn1hBKliE9CR eP7oH1A3B4eIgJHE4ufaIGFmARuJmR/7wIYKC0RKzL25iR2iJErixyZhkDBI9fLdE1lBbBYB VYmb55rB9vIK2EscmLkWbLqQwBpGibln4kFsTgFfiT2t7WD1jEC3fT+1hglilbjErSfzmSBu FpBYsuc81C+iEi8f/2OFsJUkPv6ezw5Rnyzx7+c1VohdghInZz5hmcAoOgvJqFlIymYhKYOI G0i8PzefGcLWlli28DWUrS+x8ctZRgjbWuJvRwsTspoFjByrGDlKi1PLctONDDcxAmPwmASb 4w7GBZ8sDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRe9GGncpR9xe+ jHae23VmgdCSj8ZZFboS3jsaN0n43n255HrEPRd+7xffPB/Mcj+234PhfylrDXvfWb41+i4u aTbGy/P3B/NpHJZ/YlV3Z/K6lFazPcabT6iLFl6VeLnGPkVs76q555cwBPTsmLV7l/S+gKRb R86/nPlE1uBd4zLLAPuj2vfSlViKMxINtZiLihMBgat8B48CAAA= Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:48:11 -0000 --_000_5BB4C965AAD743EB836A8463B7D513C8ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Les, You=92re certainly right about one thing - I still do not like the addition= al machinery and don=92t believe it is worth the extra signaling and specif= ication to handle an extremely unlikely event. Additionally, the consequenc= es of a router-id change need not result in any traffic loss. It is all dep= endent on SPF convergence settings, timing, network size/diameter, and, mos= t of all, implementation. We can discuss when I present at IETF 89. In the = revision I just submitted, I=92ve included the following text to section 8,= Management Considerations: Since there is a small possibility of OSPFv3 Router ID collisions, manual configuration of OSPFv3 Router-IDs is RECOMMENDED in OSPFv3 routing domains where route recovergence due to a router ID change is intolerable. Thanks, Acee On Feb 11, 2014, at 1:29 AM, Les Ginsberg (ginsberg) > wrote: Acee - One thing I have repeatedly emphasized is the simplicity of what I am propo= sing. You mention below that the proposal requires having fingerprint info = available before LSDB exchange would normally occur in order to handle rout= er-id collisions between neighbors - and you are understandably concerned a= bout the complexity that would introduce. There is no such requirement!! I am NOT proposing this!! This is simply a misunderstanding on your part. Here is all that is necessary: Router-id collision between neighbors -------------------------------------- I receive a hello with a duplicate router-id. The hello includes an options= bit (or LLS if you prefer) indicating whether the neighbor considers itsel= f "old/new". Because I cannot form a neighbor with "myself" I need to resol= ve the duplicate router-id. There is no need to have or wait to acquire the= neighbor fingerprint information. The logic is solely based on the content= of the received hello and my internal state (old/new). The logic is: if ((I am old) && (neighbor is new)) { return; /* Neighbor will change its router-id */ } else if (I am new) && (neighbor is old)) { Change_my_router_id(); } else /* We are both old or both new */ if (my link_local address < neighbor_link_local_address) { change_my_router_id(); } } That's it! No additional logic required. Similarly... Router-id collision between non-neighbors -------------------------------------- In this case we have acquired the LSDB so we detect a duplicate router-id a= s described in the draft Section 6.2. But fingerprint info includes a bit w= hich indicates whether the originator is "old" or "new". The logic is then: if ((I am old) && (non-neighbor is new)) { return; /* Non-Neighbor will change its router-id */ } else if (I am new) && (non-neighbor is old)) { Change_my_router_id(); } else /* We are both old or both new */ if (my fingerprint < non-neighbor fingerprint) { change_my_router_id(); } } Setting of old/new state is done simply on the basis of a minimum amount of= uptime (e.g. 5 minutes). The rather complex logic that Curtis proposed in = an earlier reply is not needed - I will address why in a follow up response= to his post. You may still not like the idea - but complexity is not a basis for rejecti= on. Hopefully what I have provided makes that clear. Les -----Original Message----- From: Acee Lindem [mailto:acee@lindem.com] Sent: Monday, February 10, 2014 2:55 PM Cc: curtis@ipv6.occnc.com; Les Ginsberg (gins= berg); OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- autoconfig-05.txt One thing I neglected to mention is that a solution dependent having the other router's hardware fingerprint available will greatly complicate duplicate router-id detection for directly attached routers since the resolution must either be deferred until the router's AC-LSA is received fr= om another router OR the hardware fingerprint must be signaled in the OSPFv3 Hello LLS. IMO, this complexity adds to the motivation of not attempting to solve this problem. Thanks, Acee On Feb 10, 2014, at 5:17 PM, Acee Lindem > wrote: Hi Curtis, See inline. On 2/9/14 12:38 PM, "Curtis Villamizar" > wrote: Les, Perhaps you should read the abstract of the document you are commenting about: SPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. Home network! Or the introductio: OSPFv3 [OSPFV3] is a candidate for deployments in environments where auto-configuration is a requirement. [...] 1.2. Acknowledgments This specification was inspired by the work presented in the Homenet working group meeting in October 2011 in Philadelphia, Pennsylvania. The Homenet WG works on what? Home networks! So please keep that in mind when commenting. Unless a provider were to be so stupid or lazy to use this on a SP network then most of the comments from both of us don't apply, *except* the few comments below about "in a home network". Perhaps the draft should add text explicitly stating that the last router-id used successfully should be used on a reboot rather than a new random number. I notice that only the Router-Hardware-Fingerprint TLV is persistent across reboots. This is insufficient if we want to minimize disruption. The only case then (if router-id is remembered across reboots) would be a new router. In that case your uptime rule would help. So perhaps two things could be reocmmended: 1. In section 4, include a "SHOULD remember the most recent successfully used router-id across reboots and reuse that". Reword the rest so if that information is not available, then pick a random number. I will do this. 2. a. In section 6, mention the uptime rule. Modify the Router Uptime TLV as suggested. b. Alternately add a flag to the Router-Hardware-Fingerprint TLV that indicates that since last reboot this router-id has been used and acheived a "full state". A router just rebooting would not have ever reached the full state before noticing a conflict as long as the conflct check is run before considering itself in the full state. Note: A second flag bit indicating that this router-id had been used successfully in a past reboot might also help but would only matter among two routers both rebooting and neither having reached the full state. I think #1 above is sufficient and does more to prevent surprises. I agree and appreciate you arguments in previous messages in this thread. I think #2 above helps only in the new router case but #2a requires adding a TLV and so isn't worth it IMHO. Case #2b accomplished the same thing with only a flag. I would not object to #2b above if #1 above is also added. I agree that this would be a better mechanism and would only represent a single modification to the hardware fingerprint TLV. However, I really don't think even this is necessary. Thanks, Acee See inline anyway. In message > "Les Ginsberg (ginsberg)" writes: Curtis - -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] Sent: Saturday, February 08, 2014 7:30 AM To: Les Ginsberg (ginsberg) Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF = List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- autoconfig-05.txt In message > "Les Ginsberg (ginsberg)" writes: Curtis - Your reply below is talking about things which I think do not directly bear on the value add of what I have proposed. You mention various ways to insure that a given device assigns the same router-id each time it starts up and ways to insure it picks the same sequence of second/third... choices in the event it has to change its router-id. All good suggestions, but what I am talking about is what we do in the event a conflict occurs despite our best efforts to avoid it. With the current draft content preference is based solely on a fixed identifier (fingerprint) without regard to which choice would minimize disruption to the network. When preference is given to the "old router" to retain its existing router-id this shortcoming is addressed. In the lifetime of a router it only gets added once. In the lifetime of a router we would hope it only reboots zero time but experience so far has been that reboots over a router's lifetime tend to be > 0 and in some cases >> 0. So you are optimizing for a 1 in 4 billion occurance that can happen only once in the lifetime of a router. The entire duplicate router-id resolution logic is addressing the improbable case. My proposal adds - literally - one line of code to the logic used to decide whether "I" should change my router-id or whether "you" should change your router-id. We also need to look at the consequences of this very improbably occurance. Today's routers accomplish IGP convergence in large networks in subsecond times, in some cases << 1 second. Note that if flooding is completed (both withdraw old and install new) in less than the SPF delay which is commonly implemented (some delay after receiving the first flooded IGP change), then there is no impact on routing. Your analysis does not apply to this scenario. The router which changes its router-id is effectively doing a cold start. All adjacencies will go down. All LSAs originated by this router become invalid. All routes will be removed from the forwarding plane. If you are running BGP all the BGP nexthops will be gone on the router which is changing its identity. Restoration of the adjacencies and reacquisition of the LSDB will take multiple seconds. The best you can hope for is several seconds of disruption - it could easily be much longer. For the new node which has usurped the old node's identity it will have to purge/replace all of the LSAs generated by the old node. While normal operation of the update process will insure that this happens in a reliable way the amount of flooding network-wide required to bringup a new node has now been roughly doubled i.e. the old node must reissue all of its LSAs using a new identity and the new node must purge/replace the old node's LSAs with its own versions. This will result in multiple SPFs on all nodes in the network and likely cause loops/blackholes during the transition since some of the SPFs will be run on versions of the LSDB which are inaccurate (part old node's old LSAs and part new node's LSAs). Suggesting that this could be handled in the same way/time as we typically handle a single link failure isn't credible. All routers are supposed to keep a fixed router-id across reboots. If interfaces are changed when down, the last used router-id should be on flash. If flash is removed and replaced (rather than a new image installed), then with the same set of interfaces, the same decision should be made. We are down to a very special case where both flash and interfaces are removed and replaced yielding no history and a different set of MACs to pick from. Your statement that what I propose is only relevant when two routers go down does not match the scenarios I envision. If I want to add a new device to my network or if I need to replace an existing device in my network I am only affecting one device - but as I am introducing a device with a new fingerprint it is possible that it will introduce a conflict with an existing router-id. In provider networks routers are generally added during maintenance windows so should anything unexpected happen, impact is minimized. In home nets, the home user isn't going to notice the convergence time if there is any. A 10 msec SPF delay is likely to be plenty. As I stated above, disruption will be orders of magnitude longer than 10 ms. In a home net? With perhaps a half dozen routers and a default route? Someone has a very bad OSPF implementation. :-) Or did you miss the "In home nets" at the front of the paragraph. For example, in a 10 node network with average degree 4, perhpas 40 links in 10 router LSA exist. A few RTT (less than 1 msec for a homenet) for each neighbor adjacency (which happen in parallel) and ten packets from 4 sources is needed to reach the full state followed by one SPF to be fully up and running. Other routers get one additional router LSA plus four new links in existing router LSA and have to run an SPF. Even on a software based homenet router using an ARM, 10 msec is likely to be enough time and if it is "orders of magnitude" longer, something is wrong with one of the implementations. This would be an more complicated than usual home net or even soho, more likely a small business. In a subsequent reply you liked the idea of the new device delaying advertising reachability until it is has determined that its router-id choice is not in conflict. The old/new router paradigm supports this strategy by assuring that the old router will not consider changing its router-id until enough time has elapsed for the new router to transition to being an old router. If it wins the coin toss, the router would advertise at least one LSA to indicate its existance and could hold back on any additional advertisements until the other router has withdrawn routes. This suggestion does not alter the fact that if the old node changes its router-id the network has to respond to three events: 1)Loss of the old node 2)Introduction of the old-node with a new identity 3)Introduction of the new node with the identity of the old-node Again, the old node should remember the last router-id used and try to reuse it. If however we insure that the old-node does not change its identity then the network only has to respond to a single event - the introduction of the new-node. Yes and if it were up and won the resolution last time, it will have saved that router-id and will reuse it. If it came up previously and lost the resolution, then it will remember the router-id it used, whether second or third pick, and use that. Finally, what I propose is extremely simple to implement. I think it isn't much of an exaggeration to say that any one of us could have implemented the enhancement in the time it has taken to discuss its merits. So we aren't overengineering for a case which is admittedly very unlikely to occur - we are adding a modest extension to make our solution less disruptive. Yes but it it *bad* for the more common case where routers go down occasionally. You are going to have to clarify exactly what "bad side effects" you see for what I propose - because I don't see any - whereas I do see benefits as described above. If router-id is not remembered between reboots, then there is the one in 4 billion time number of routers (less than 10 for a home net today, but maybe more in the future). If router-id is remembered between reboots, then no matter how long a router has been down, if nothing else in the network changed, there is zero chance of having a collision. With either method, if router-id is remembered between reboots, then there is zero chance of collision. IMO should this ever be used on a managed network (including a home net / soho / small business net that happens to be managed) then having routers come back from a reboot with the same router-ids would be a big plus. For example, after a power outage NMS discovery would not have to be repeated. Les Les Curtis -----Original Message----- From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] Sent: Friday, February 07, 2014 9:22 AM To: Les Ginsberg (ginsberg) Cc: Acee Lindem; Curtis Villamizar; OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- autoconfig-05.txt In message > "Les Ginsberg (ginsberg)" writes: So, I am one person who raised this concern to Acee - but the proposal outlined by Acee is not what I had in mind. There is no need to use "uptime" or to invent some unusual exchange of LSAs prior to Exchange state. Also, in regards to Curtis's comment - it is not DOS attacks that I am trying to mitigate here. As he says if an attacker is in your network and able to originate credible packets no strategy is safe. The motivating use case is to minimize disruption of a stable network when a new router is added or an existing router is replaced/rebooted. In other words non-disruptive handling of the common maintenance/upgrade scenarios. What I have in mind is this: 1) A router needs a way to advertise that it has been up and running for a minimum length of time - for the sake of discussion let's say 20 minutes. Routers then fall into two categories: o Old routers (up >=3D minimum time) o New routers (up < minimum time) 2) When a duplicate router-id is detected, the first tie breaker is between old routers and new routers. The old router gets to keep its router-id and the new router picks a new router-id. If both routers are "new" or both routers are "old" then we revert to the existing tie breakers defined in the document (link local address for directly connected routers and fingerprint info for non-neighbors). 3) Advertisement of the "old/new" state requires a single bit - but it has to be available both in hellos and the new AC-LSA. Adding it to the AC-LSA is easy to do. For hellos, there are two possibilities: o Use one of the Options Bits o Use LLS Be interested in how folks feel about this. Les Les, Excluding DoS attack, we are talking about a one in 4 billion case (for any two routers, so with 400 routers, still well under one in 1M) where two routers hash a MAC address or pick a one time random number from out of nowhere and end up with the same number. If that does happen (and one in 1M is certainly possible), then it would be nice if the routers always ended up with the same router-id. This could be accomplished by some fixed method such as hashing a constant with the first choice or router-id or using the router-id as a seed for the random number generator (which will pick the same sequence of random numbers each time). If this is done, then a conflict would always produce the same set of next picks. The set of routers in a given network would always end up with the same router-ids once they all came up and if only one went down at a time then it would always end up with the same router-id when it came up. Zero conf was mainly intended for unmanaged networks (motivated by work in the homenet WG). In these small unmanaged networks it doesn't matter which router gets what router-id as long as they end up unique and convergence is in a reasonable time relative to keeping eyeballs happy. It could be applied to enterprise or providers but in either case having the routers end up with the same router-ids would make for easier management. For your scenario to matter at all with current rules, both routers in the conflict would have to go down. If only the one that is preferred goes down, the other is not going to change its router-id as a result so when it comes up it gets its first pick with no conflict. If the one that was not preferred goes down, it comes up, sees a conflict and takes its second pick (loses the conflict every time). It is only if they both go down and the one that normally loses the conflict comes up first that there is a change in router-id. That too can be solved with a rule that you always come up with the last router-id used. Curtis -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Thursday, February 06, 2014 5:12 PM To: Curtis Villamizar Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf- ospfv3- autoconfig-05.txt Hi Curtis, I agree and believe the significance of this use case where a new router is inserted into an auto-configured domain has been greater exaggerated. Thanks, Acee On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > wrote: In message > Acee Lindem writes: The OSPFv3 autoconfiguration draft was cloned and presented in the ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In the ISIS WG, there was a concern that the resolution of a duplicate system ID did not include the amount of time the router was operational when determining which router would need to choose a new router ID. With additional complexity, we could incorporate router uptime into the resolution process. One way to do this would be to: 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include the uptime in seconds. 2. Use the Router Uptime TLV as the primary determinant in deciding which router must choose a new OSPFv3 Router ID. Router uptimes less than 3600 (MaxAge) seconds apart are considered equal. 3. When an OSPFv3 Hello is received with a different link- local source address but a different router-id, unicast the OSPFv3 AC-LSA to the neighbor so that OSPFv3 duplicate router resolution can proceed as in the case where it is received through the normal flooding process. This is somewhat of a hack as the we'd also need to accept OSPF Link State Updates from a neighbor that is not in Exchange State or greater. An alternative to #3 would be to use Link-Local Signaling (LLS) for signaling the contents of the OSPFv3 AC-LSA. However, you'd only want to send the Router-Uptime and Router Hardware Fingerprint when a duplicate Router-ID is detected. This requires implementing the resolution two ways but may be preferable since it doesn't require violating the flooding rules. In any case, I'd like to get other opinions as to whether this problem is worth solving. Thanks, Acee Acee, If the basis for router-id on boot up results in a fixed value, and if a duplicate will occur on a give network, then which of two duplicate routers gets that value may change after one of them reboots. If uptime is not considered, it will never change as long as one router stays up at any given time. We are talking about a very low probability event (a duplicate) except if this is a DoS attack and then either using or not using uptime won't matter since the attacker will claim an impossibly long uptime. Curtis _______________________________________________ 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_5BB4C965AAD743EB836A8463B7D513C8ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B223D39D119264E8D18F9937355F8F4@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi Les, 
You=92re certainly right about one thing - I still do not like the add= itional machinery and don=92t believe it is worth the extra signaling and s= pecification to handle an extremely unlikely event. Additionally, the conse= quences of a router-id change need not result in any traffic loss. It is all dependent on SPF convergence setting= s, timing, network size/diameter, and, most of all, implementation. We can = discuss when I present at IETF 89. In the revision I just submitted, I=92ve= included the following text to section 8, Management Considerations:

    Since there is a small poss= ibility of OSPFv3 Router ID collisions,
   manual configuration of OSPF= v3 Router-IDs is RECOMMENDED in OSPFv3
   routing domains where route = recovergence due to a router ID change is
   intolerable.<= /div>


Thanks,
Acee 

On Feb 11, 2014, at 1:29 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

Acee -

One thing I have repeatedly emphasized is the simplicity of what I am propo= sing. You mention below that the proposal requires having fingerprint info = available before LSDB exchange would normally occur in order to handle rout= er-id collisions between neighbors - and you are understandably concerned about the complexity that woul= d introduce.

There is no such requirement!! I am NOT proposing this!!

This is simply a misunderstanding on your part.

Here is all that is necessary:

Router-id collision between neighbors
--------------------------------------

I receive a hello with a duplicate router-id. The hello includes an options= bit (or LLS if you prefer) indicating whether the neighbor considers itsel= f "old/new". Because I cannot form a neighbor with "myself&q= uot; I need to resolve the duplicate router-id. There is no need to have or wait to acquire the neighbor fingerprint inform= ation. The logic is solely based on the content of the received hello and m= y internal state (old/new). The logic is:

if ((I am old) && (neighbor is new)) {
 return; /* Neighbor will change its router-id */
} else if (I am new) && (neighbor is old)) {
  Change_my_router_id();
} else /* We are both old or both new */ 
 if (my link_local address < neighbor_link_local_address) {
   change_my_router_id();
 }
}

That's it! No additional logic required.
Similarly...

Router-id collision between non-neighbors
--------------------------------------

In this case we have acquired the LSDB so we detect a duplicate router-id a= s described in the draft Section 6.2. But fingerprint info includes a bit w= hich indicates whether the originator is "old" or "new"= .
The logic is then:

if ((I am old) && (non-neighbor is new)) {
 return; /* Non-Neighbor will change its router-id */
} else if (I am new) && (non-neighbor is old)) {
  Change_my_router_id();
} else /* We are both old or both new */ 
 if (my fingerprint < non-neighbor fingerprint) {
   change_my_router_id();
 }
}

Setting of old/new state is done simply on the basis of a minimum amount of= uptime (e.g. 5 minutes). The rather complex logic that Curtis proposed in = an earlier reply is not needed - I will address why in a follow up response= to his post.

You may still not like the idea - but complexity is not a basis for rejecti= on. Hopefully what I have provided makes that clear.

  Les

-----Original Message-----
From: Acee Lindem [mailto:acee@lindem.co= m]
Sent: Monday, February 10, 2014 2:55 PM
Cc: curtis@ipv6.occnc.com; Les= Ginsberg (ginsberg); OSPF List
Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
autoconfig-05.txt

One thing I neglected to mention is that a solution dependent having the other router's hardware fingerprint available will greatly complicate
duplicate router-id detection for directly attached routers since the
resolution must either be deferred until the router's AC-LSA is received fr= om
another router OR the hardware fingerprint must be signaled in the OSPFv3 Hello LLS. IMO, this complexity adds to the motivation of not attempting to=
solve this problem.
Thanks,
Acee
On Feb 10, 2014, at 5:17 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:

Hi Curtis,

See inline.

On 2/9/14 12:38 PM, "Curtis Villamizar" <curtis@ipv6.occnc.com> wrote:


Les,

Perhaps you should read the abstract of the document you are
commenting about:

SPFv3 is a candidate for deployments in environments where auto-
configuration is a requirement.  One such environment is the IPv6
home network where users expect to simply plug in a router and have
it automatically use OSPFv3 for intra-domain routing.  This
document describes the necessary mechanisms for OSPFv3 to be
self-configuring.

Home network!

Or the introductio:

OSPFv3 [OSPFV3] is a candidate for deployments in environments
where auto-configuration is a requirement.

[...]

1.2. Acknowledgments

   This specification was inspired by the work presented in the    Homenet working group meeting in October 2011 in Philadelphia,=
   Pennsylvania.

The Homenet WG works on what?  Home networks!

So please keep that in mind when commenting.

Unless a provider were to be so stupid or lazy to use this on a SP
network then most of the comments from both of us don't apply,
*except* the few comments below about "in a home network".

Perhaps the draft should add text explicitly stating that the last
router-id used successfully should be used on a reboot rather than a
new random number.  I notice that only the Router-Hardware-Fingerprint=
TLV is persistent across reboots.  This is insufficient if we want to<= br> minimize disruption.

The only case then (if router-id is remembered across reboots) would
be a new router.  In that case your uptime rule would help.  So perhaps two things could be reocmmended:

1.  In section 4, include a "SHOULD remember the most recent
   successfully used router-id across reboots and reuse that"= ;.
   Reword the rest so if that information is not available, then<= br>    pick a random number.

I will do this.




2.  a.  In section 6, mention the uptime rule.  Modify the R= outer
       Uptime TLV as suggested.

   b.  Alternately add a flag to the Router-Hardware-Fingerp= rint
      TLV that indicates that since last reboot this router-id has
      been used and acheived a "full state".  A router j= ust
      rebooting would not have ever reached the full state before
      noticing a conflict as long as the conflct check is run
      before considering itself in the full state.

       Note: A second flag bit indicating that this rou= ter-id had
      been used successfully in a past reboot might also help but
      would only matter among two routers both rebooting and
      neither having reached the full state.

I think #1 above is sufficient and does more to prevent surprises.

I agree and appreciate you arguments in previous messages in this thread.

I
think #2 above helps only in the new router case but #2a requires
adding a TLV and so isn't worth it IMHO.  Case #2b accomplished the same thing with only a flag.  I would not object to #2b above if #1 above is also added.

I agree that this would be a better mechanism and would only represent a single modification to the hardware fingerprint TLV. However, I really
don't think even this is necessary.

Thanks,
Acee




See inline anyway.

In message
<F3ADE4747C9E124B89F0ED2180CC814F23C62C22@xmb-aln-x02.cisco.com>
"Les Ginsberg (ginsberg)" writes:

Curtis -

-----Original Message-----
From: Curtis Villamizar [mailto:cu= rtis@ipv6.occnc.com]
Sent: Saturday, February 08, 2014 7:30 AM
To: Les Ginsberg (ginsberg)
Cc: curtis@ipv6.occnc.com; Ace= e Lindem; OSPF List
Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
autoconfig-05.txt


In message
<F3ADE4747C9E124B89F0ED2180CC814F23C621A3@xmb-aln-x02.cisco.com>
"Les Ginsberg (ginsberg)" writes:

Curtis -

Your reply below is talking about things which I think do not
directly
bear on the value add of what I have proposed.
You mention various ways to insure that a given device assigns the
same router-id each time it starts up and ways to insure it picks
the
same sequence of second/third... choices in the e= vent it has to
change
its router-id. All good suggestions, but what I a= m talking about is
what we do in the event a conflict occurs despite our best efforts
to
avoid it. With the current draft content preferen= ce is based solely
on
a fixed identifier (fingerprint) without regard t= o which choice
would
minimize disruption to the network. When preferen= ce is given to the
"old router" to retain its existing router-id this shortcoming is=
addressed.

In the lifetime of a router it only gets added once.  In the lifetime<= br> of a router we would hope it only reboots zero time but experience so
far has been that reboots over a router's lifetime tend to be > 0 and in some cases >> 0.

So you are optimizing for a 1 in 4 billion occurance that can happen
only once in the lifetime of a router.

The entire duplicate router-id resolution logic is addressing the
improbable case. My proposal adds - literally - one line of code to
the logic used to decide whether "I" should change my router-id o= r
whether "you" should change your router-id.


We also need to look at the consequences of this very improbably
occurance.  Today's routers accomplish IGP convergence in large
networks in subsecond times, in some cases << 1 second.

Note that if flooding is completed (both withdraw old and install new)
in less than the SPF delay which is commonly implemented (some delay
after receiving the first flooded IGP change), then there is no impact
on routing.

Your analysis does not apply to this scenario. The router which
changes its router-id is effectively doing a cold start. All
adjacencies will go down. All LSAs originated by this router become
invalid. All routes will be removed from the forwarding plane. If
you are running BGP all the BGP nexthops will be gone on the router
which is changing its identity. Restoration of the adjacencies and
reacquisition of the LSDB will take multiple seconds. The best you
can hope for is several seconds of disruption - it could easily be
much longer.

For the new node which has usurped the old node's identity it will
have to purge/replace all of the LSAs generated by the old
node. While normal operation of the update process will insure that
this happens in a reliable way the amount of flooding network-wide
required to bringup a new node has now been roughly doubled
i.e. the old node must reissue all of its LSAs using a new identity
and the new node must purge/replace the old node's LSAs with its
own versions. This will result in multiple SPFs on all nodes in the
network and likely cause loops/blackholes during the transition
since some of the SPFs will be run on versions of the LSDB which
are inaccurate (part old node's old LSAs and part new node's
LSAs). Suggesting that this could be handled in the same way/time
as we typically handle a single link failure isn't credible.

All routers are supposed to keep a fixed router-id across reboots.  If=
interfaces are changed when down, the last used router-id should be on
flash.  If flash is removed and replaced (rather than a new image
installed), then with the same set of interfaces, the same decision
should be made.  We are down to a very special case where both flash and interfaces are removed and replaced yielding no history and a
different set of MACs to pick from.

Your statement that what I propose is only releva= nt when two routers
go down does not match the scenarios I envision. If I want to add a
new device to my network or if I need to replace an existing device
in
my network I am only affecting one device - but a= s I am introducing
a
device with a new fingerprint it is possible that= it will introduce
a
conflict with an existing router-id.

In provider networks routers are generally added during maintenance
windows so should anything unexpected happen, impact is minimized.

In home nets, the home user isn't going to notice the convergence time
if there is any.  A 10 msec SPF delay is likely to be plenty.

As I stated above, disruption will be orders of magnitude longer than
10 ms.

In a home net?  With perhaps a half dozen routers and a default route?=
Someone has a very bad OSPF implementation.  :-)  Or did you miss= the
"In home nets" at the front of the paragraph.

For example, in a 10 node network with average degree 4, perhpas 40
links in 10 router LSA exist.  A few RTT (less than 1 msec for a
homenet) for each neighbor adjacency (which happen in parallel) and
ten packets from 4 sources is needed to reach the full state followed
by one SPF to be fully up and running.  Other routers get one
additional router LSA plus four new links in existing router LSA and
have to run an SPF.  Even on a software based homenet router using an<= br> ARM, 10 msec is likely to be enough time and if it is "orders of
magnitude" longer, something is wrong with one of the implementations.=
This would be an more complicated than usual home net or even soho,
more likely a small business.

In a subsequent reply you liked the idea of the n= ew device delaying
advertising reachability until it is has determined that its
router-id
choice is not in conflict. The old/new router par= adigm supports this
strategy by assuring that the old router will not consider changing
its router-id until enough time has elapsed for the new router to
transition to being an old router.

If it wins the coin toss, the router would advertise at least one LSA
to indicate its existance and could hold back on any additional
advertisements until the other router has withdrawn routes.


This suggestion does not alter the fact that if the old node changes
its router-id the network has to respond to three= events:

1)Loss of the old node
2)Introduction of the old-node with a new identity
3)Introduction of the new node with the identity of the old-node

Again, the old node should remember the last router-id used and try to
reuse it.

If however we insure that the old-node does not c= hange its identity
then the network only has to respond to a single event - the
introduction of the new-node.

Yes and if it were up and won the resolution last time, it will have
saved that router-id and will reuse it.  If it came up previously and<= br> lost the resolution, then it will remember the router-id it used,
whether second or third pick, and use that.

Finally, what I propose is extremely simple to im= plement. I think it
isn't much of an exaggeration to say that any one of us could have
implemented the enhancement in the time it has taken to discuss its
merits. So we aren't overengineering for a case which is admittedly
very unlikely to occur - we are adding a modest extension to make
our
solution less disruptive.

Yes but it it *bad* for the more common case where routers go down
occasionally.

You are going to have to clarify exactly what "bad side effects" = you
see for what I propose - because I don't see any - whereas I do
see benefits as described above.

If router-id is not remembered between reboots, then there is the one
in 4 billion time number of routers (less than 10 for a home net
today, but maybe more in the future).

If router-id is remembered between reboots, then no matter how long a
router has been down, if nothing else in the network changed, there is
zero chance of having a collision.

With either method, if router-id is remembered between reboots, then
there is zero chance of collision.

IMO should this ever be used on a managed network (including a home
net / soho / small business net that happens to be managed) then
having routers come back from a reboot with the same router-ids would
be a big plus.  For example, after a power outage NMS discovery would<= br> not have to be repeated.

 Les



 Les

Curtis


-----Original Message-----
From: Curtis Villamizar [mailto:cu= rtis@ipv6.occnc.com]
Sent: Friday, February 07, 2014 9:22 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem; Curtis Villamizar; OSPF List
Subject: Re: [OSPF] OSPFv3 Autoconfiguration -
draft-ietf-ospf-ospfv3-
autoconfig-05.txt


In message <F3ADE4747C9E124B89F0ED2180CC814F23C619A9@xmb-aln-
x02.cisco.com>
"Les Ginsberg (ginsberg)" writes:

So, I am one person who raised this concern to Acee - but the
proposal
outlined by Acee is not what I had in mind. There= is no need to
use
"uptime" or to invent some unusual exch= ange of LSAs prior to
Exchange
state.

Also, in regards to Curtis's comment - it is not DOS attacks
that I am
trying to mitigate here. As he says if an attacke= r is in your
network
and able to originate credible packets no strateg= y is safe.

The motivating use case is to minimize disruption of a stable
network
when a new router is added or an existing router = is
replaced/rebooted. In other words non-disruptive handling of the
common maintenance/upgrade scenarios.

What I have in mind is this:

1) A router needs a way to advertise that it has been up and
running
 for a minimum length of time - for the sake= of discussion
let's say
 20 minutes. Routers then fall into two cate= gories:

o Old routers (up >=3D minimum time)
o New routers (up < minimum time)

2) When a duplicate router-id is detected, the first tie
breaker is
 between old routers and new routers. The ol= d router gets to
keep
 its router-id and the new router picks a ne= w router-id.  If
both
 routers are "new" or both routers= are "old" then we revert
to the
 existing tie breakers defined in the docume= nt (link local
address
 for directly connected routers and fingerpr= int info for
 non-neighbors).

3) Advertisement of the "old/new" state requires a single bit -
but it
 has to be available both in hellos and the = new AC-LSA.
Adding it to
 the AC-LSA is easy to do. For hellos, there= are two
possibilities:

 o Use one of the Options Bits
 o Use LLS

Be interested in how folks feel about this.

 Les


Les,

Excluding DoS attack, we are talking about a one in 4 billion case
(for any two routers, so with 400 routers, still well under one
in 1M)
where two routers hash a MAC address or pick a on= e time random
number
from out of nowhere and end up with the same numb= er.

If that does happen (and one in 1M is certainly possible), then it
would be nice if the routers always ended up with the same
router-id.
This could be accomplished by some fixed method s= uch as hashing a
constant with the first choice or router-id or using the
router-id as
a seed for the random number generator (which wil= l pick the same
sequence of random numbers each time).  If this is done, then a
conflict would always produce the same set of next picks.  The
set of
routers in a given network would always end up wi= th the same
router-ids once they all came up and if only one went down at a
time
then it would always end up with the same router-= id when it came
up.

Zero conf was mainly intended for unmanaged networks (motivated by
work in the homenet WG).  In these small unmanaged networks it
doesn't
matter which router gets what router-id as long a= s they end up
unique
and convergence is in a reasonable time relative = to keeping
eyeballs
happy.  It could be applied to enterprise or= providers but in
either
case having the routers end up with the same rout= er-ids would
make for
easier management.

For your scenario to matter at all with current rules, both
routers in
the conflict would have to go down.  If only= the one that is
preferred
goes down, the other is not going to change its r= outer-id as a
result
so when it comes up it gets its first pick with n= o conflict.  If
the
one that was not preferred goes down, it comes up= , sees a
conflict and
takes its second pick (loses the conflict every t= ime).  It is
only if
they both go down and the one that normally loses= the conflict
comes
up first that there is a change in router-id. &nb= sp;That too can be
solved
with a rule that you always come up with the last= router-id used.

Curtis


-----Original Message-----
From: OSPF [mailto:ospf-bounces@ie= tf.org] On Behalf Of Acee
Lindem
Sent: Thursday, February 06, 2014 5:12 PM
To: Curtis Villamizar
Cc: OSPF List
Subject: Re: [OSPF] OSPFv3 Autoconfiguration -
draft-ietf-ospf-
ospfv3-
autoconfig-05.txt

Hi Curtis,
I agree and believe the significance of this use case where a
new
router
is
inserted into an auto-configured domain has been = greater
exaggerated.
Thanks,
Acee
On Feb 5, 2014, at 3:58 PM, Curtis Villamizar
<curtis@ipv6.occnc.com><= br>
wrote:


In message <CF17DD4E.2696B%a= cee.lindem@ericsson.com>
Acee Lindem writes:

The OSPFv3 autoconfiguration draft was cloned and=
presented in the
ISIS WG
(http://= www.ietf.org/id/draft-liu-isis-auto-conf-00.txt).
In
the ISIS WG, there was a concern that the resolut= ion of a
duplicate
system ID did not include the amount of time the = router was
operational when determining which router would need to
choose a
new
router ID. With additional complexity, we could
incorporate router
uptime into the resolution process. One way to do= this
would be
to:

  1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It
would
include
     the uptime in seconds.

  2. Use the Router Uptime TLV as the primary
determinant in
     deciding which router must ch= oose a new OSPFv3
Router
     ID. Router uptimes less than = 3600 (MaxAge) seconds
apart
are
     considered equal.

  3. When an OSPFv3 Hello is received with a different
link-
local
   source address but a different router-id, unicast the
OSPFv3
   AC-LSA to the neighbor so that OSPFv3 duplicate router
   resolution can proceed as in the case where it is
received
   through the normal flooding process. This is somewhat
of a
   hack as the we'd also need to accept OSPF Link State
Updates
   from a neighbor that is not in Exchange State or
greater.

An alternative to #3 would be to use Link-Local Signaling
(LLS)
for
signaling the contents of the OSPFv3 AC-LSA. Howe= ver,
you'd only
want
to send the Router-Uptime and Router Hardware Fin= gerprint
when a
duplicate Router-ID is detected. This requires
implementing the
resolution two ways but may be preferable since i= t doesn't
require
violating the flooding rules.

In any case, I'd like to get other opinions as to whether
this
problem
is worth solving.

Thanks,
Acee


Acee,

If the basis for router-id on boot up results in a fixed
value, and
if
a duplicate will occur on a give network, then wh= ich of two
duplicate
routers gets that value may change after one of t= hem
reboots.  If
uptime is not considered, it will never change as= long as
one
router
stays up at any given time.

We are talking about a very low probability event (a
duplicate)
except
if this is a DoS attack and then either using or = not using
uptime
won't matter since the attacker will claim an imp= ossibly
long
uptime.

Curtis

_______________________________________________
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_5BB4C965AAD743EB836A8463B7D513C8ericssoncom_-- From russw@riw.us Tue Feb 11 18:19: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 E95361A07C3 for ; Tue, 11 Feb 2014 18:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.548] 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 oYvxZa0d329p for ; Tue, 11 Feb 2014 18:19:39 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 198131A07B1 for ; Tue, 11 Feb 2014 18:19:39 -0800 (PST) Received: from 50-201-180-2-static.hfc.comcastbusiness.net ([50.201.180.2]:19202 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WDPQF-00082n-Hr; Wed, 12 Feb 2014 02:19:35 +0000 From: "Russ White" To: "'Acee Lindem'" , "'Les Ginsberg \(ginsberg\)'" References: <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> <5BB4C965-AAD7-43EB-836A-8463B7D513C8@ericsson.com> In-Reply-To: <5BB4C965-AAD7-43EB-836A-8463B7D513C8@ericsson.com> Date: Tue, 11 Feb 2014 21:19:27 -0500 Message-ID: <04be01cf2798$db8f2f20$92ad8d60$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEtVAQAchdalN4qR8zwXqZnUmzJCwDBH+QQAdV1qVICB01aN5vPmj0g Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: 'OSPF List' Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 12 Feb 2014 02:19:41 -0000 > Since there is a small possibility of OSPFv3 Router ID collisions, > manual configuration of OSPFv3 Router-IDs is RECOMMENDED in OSPFv3 > routing domains where route recovergence due to a router ID change is > intolerable. I like this solution -- and prefer it to the machinery involved in finding and resolving an overlapping router id. Thanks for adding this in. Russ From rja.lists@gmail.com Wed Feb 12 07:29:48 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 210E61A0342 for ; Wed, 12 Feb 2014 07:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 JdDGXVgyiZcf for ; Wed, 12 Feb 2014 07:29:46 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 42B641A02A7 for ; Wed, 12 Feb 2014 07:29:46 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id f11so14259139qae.10 for ; Wed, 12 Feb 2014 07:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=70TtIQOVcxfGONNdGKowIe8SAa0locZ59ULC5x7k/t0=; b=IeJFqH1D8Tm52iyqfcvvHCYPqPlSdUuEoEKapzbE4Q+frEGoEvPGmmmANGb91BgyiZ 7EG7WYDc0Z/eXVfMh/6sdhETWjtzBuBxf5jG5JNlTI828igsCsLbVqvvlJpcpxXZ9d0a RRkduGKAbUQbRTPbagho3PgC4dpS/uXH33sd68RoEwA2ezn4vIpp56tVhYpmCP8HvBOL IpXcYwbtPT/kyhXRbwWV71FtLwq3z3DzklREqiP5MZwxcA//CJCVTaP4q9wtRas0wOcw P+8x7MXffS/FOm5ikHSZWdJ56hBgX8jsuaMP9fhF7HCiQ6nVhr/z7BAQfWPwgqiTpcPq nuIQ== X-Received: by 10.224.51.74 with SMTP id c10mr68728209qag.33.1392218985128; Wed, 12 Feb 2014 07:29:45 -0800 (PST) Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id u20sm34051410qge.2.2014.02.12.07.29.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 07:29:44 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 12 Feb 2014 10:29:43 -0500 Message-Id: To: ospf@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.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, 12 Feb 2014 15:29:48 -0000 > Originally, Acee Lindem wrote: > > Since there is a small possibility of OSPFv3 Router ID collisions, > > manual configuration of OSPFv3 Router-IDs is RECOMMENDED in OSPFv3 > > routing domains where route recovergence due to a router ID change > > is intolerable. > > On Tuesday, February 11th, 2014, Russ White wrote: > I like this solution -- and prefer it to the machinery involved in > finding and resolving an overlapping router id. Thanks for adding this in. +1 Simpler is better. Yours, Ran From curtis@ipv6.occnc.com Wed Feb 12 09:52: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 C019A1A04E0 for ; Wed, 12 Feb 2014 09:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG5izQUl7ya2 for ; Wed, 12 Feb 2014 09:52:12 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id F09ED1A0680 for ; Wed, 12 Feb 2014 09:52:11 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1CHprr7072473; Wed, 12 Feb 2014 12:51:53 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402121751.s1CHprr7072473@maildrop2.v6ds.occnc.com> To: Acee Lindem From: Curtis Villamizar In-reply-to: Your message of "Mon, 10 Feb 2014 17:55:17 -0500." <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> Date: Wed, 12 Feb 2014 12:51:53 -0500 Cc: OSPF List Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:52:17 -0000 In message <6DFEDDF5-55F8-4A4C-8087-EB34A6716981@lindem.com> Acee Lindem writes: > > One thing I neglected to mention is that a solution dependent having > the other router's hardware fingerprint available will greatly > complicate duplicate router-id detection for directly attached routers > since the resolution must either be deferred until the router's > AC-LSA is received from another router OR the hardware fingerprint > must be signaled in the OSPFv3 Hello LLS. IMO, this complexity adds to > the motivation of not attempting to solve this problem. > > Thanks, > Acee Acee, I agree. Having tried to explore this in email with Les, solutions do exist but are clearly not worth the effort. I think the only thing agreed to so far is to use a previously successful router-id on reboot if possible rather than pick a new random router-id. Perhaps a "my router-id was configured so I win" bit would also help. This would be the equivalent of there being no fingerprint but would be capable of resolving the "bone headed operator" problem of two routers configured with the same router-id. Curtis > On Feb 10, 2014, at 5:17 PM, Acee Lindem wrote: > > > Hi Curtis, > > > > See inline. > > > > On 2/9/14 12:38 PM, "Curtis Villamizar" wrote: > > > >> > >> Les, > >> > >> Perhaps you should read the abstract of the document you are > >> commenting about: > >> > >> SPFv3 is a candidate for deployments in environments where auto- > >> configuration is a requirement. One such environment is the IPv6 > >> home network where users expect to simply plug in a router and have > >> it automatically use OSPFv3 for intra-domain routing. This > >> document describes the necessary mechanisms for OSPFv3 to be > >> self-configuring. > >> > >> Home network! > >> > >> Or the introductio: > >> > >> OSPFv3 [OSPFV3] is a candidate for deployments in environments > >> where auto-configuration is a requirement. > >> > >> [...] > >> > >> 1.2. Acknowledgments > >> > >> This specification was inspired by the work presented in the > >> Homenet working group meeting in October 2011 in Philadelphia, > >> Pennsylvania. > >> > >> The Homenet WG works on what? Home networks! > >> > >> So please keep that in mind when commenting. > >> > >> Unless a provider were to be so stupid or lazy to use this on a SP > >> network then most of the comments from both of us don't apply, > >> *except* the few comments below about "in a home network". > >> > >> Perhaps the draft should add text explicitly stating that the last > >> router-id used successfully should be used on a reboot rather than a > >> new random number. I notice that only the Router-Hardware-Fingerprint > >> TLV is persistent across reboots. This is insufficient if we want to > >> minimize disruption. > >> > >> The only case then (if router-id is remembered across reboots) would > >> be a new router. In that case your uptime rule would help. So > >> perhaps two things could be reocmmended: > >> > >> 1. In section 4, include a "SHOULD remember the most recent > >> successfully used router-id across reboots and reuse that". > >> Reword the rest so if that information is not available, then > >> pick a random number. > > > > I will do this. > > > > > > > >> > >> 2. a. In section 6, mention the uptime rule. Modify the Router > >> Uptime TLV as suggested. > >> > >> b. Alternately add a flag to the Router-Hardware-Fingerprint > >> TLV that indicates that since last reboot this router-id has > >> been used and acheived a "full state". A router just > >> rebooting would not have ever reached the full state before > >> noticing a conflict as long as the conflct check is run > >> before considering itself in the full state. > >> > >> Note: A second flag bit indicating that this router-id had > >> been used successfully in a past reboot might also help but > >> would only matter among two routers both rebooting and > >> neither having reached the full state. > >> > >> I think #1 above is sufficient and does more to prevent surprises. > > > > I agree and appreciate you arguments in previous messages in this thread. > > > > > >> I > >> think #2 above helps only in the new router case but #2a requires > >> adding a TLV and so isn't worth it IMHO. Case #2b accomplished the > >> same thing with only a flag. I would not object to #2b above if #1 > >> above is also added. > > > > I agree that this would be a better mechanism and would only represent a > > single modification to the hardware fingerprint TLV. However, I really > > don't think even this is necessary. > > > > Thanks, > > Acee > > > > > > > >> > >> See inline anyway. > >> > >> In message > >> > >> "Les Ginsberg (ginsberg)" writes: > >>> > >>> Curtis - > >>> > >>>> -----Original Message----- > >>>> From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > >>>> Sent: Saturday, February 08, 2014 7:30 AM > >>>> To: Les Ginsberg (ginsberg) > >>>> Cc: curtis@ipv6.occnc.com; Acee Lindem; OSPF List > >>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > >>>> autoconfig-05.txt > >>>> > >>>> > >>>> In message > >>> > >>>> "Les Ginsberg (ginsberg)" writes: > >>>> > >>>>> Curtis - > >>>>> > >>>>> Your reply below is talking about things which I think do not > >>> directly > >>>>> bear on the value add of what I have proposed. > >>>>> > >>>>> You mention various ways to insure that a given device assigns the > >>>>> same router-id each time it starts up and ways to insure it picks > >>> the > >>>>> same sequence of second/third... choices in the event it has to > >>> change > >>>>> its router-id. All good suggestions, but what I am talking about is > >>>>> what we do in the event a conflict occurs despite our best efforts > >>> to > >>>>> avoid it. With the current draft content preference is based solely > >>> on > >>>>> a fixed identifier (fingerprint) without regard to which choice > >>> would > >>>>> minimize disruption to the network. When preference is given to the > >>>>> "old router" to retain its existing router-id this shortcoming is > >>>>> addressed. > >>>> > >>>> In the lifetime of a router it only gets added once. In the lifetime > >>>> of a router we would hope it only reboots zero time but experience so > >>>> far has been that reboots over a router's lifetime tend to be > 0 and > >>>> in some cases >> 0. > >>>> > >>>> So you are optimizing for a 1 in 4 billion occurance that can happen > >>>> only once in the lifetime of a router. > >>> > >>> The entire duplicate router-id resolution logic is addressing the > >>> improbable case. My proposal adds - literally - one line of code to > >>> the logic used to decide whether "I" should change my router-id or > >>> whether "you" should change your router-id. > >>> > >>>> > >>>> We also need to look at the consequences of this very improbably > >>>> occurance. Today's routers accomplish IGP convergence in large > >>>> networks in subsecond times, in some cases << 1 second. > >>>> > >>>> Note that if flooding is completed (both withdraw old and install new) > >>>> in less than the SPF delay which is commonly implemented (some delay > >>>> after receiving the first flooded IGP change), then there is no impact > >>>> on routing. > >>> > >>> Your analysis does not apply to this scenario. The router which > >>> changes its router-id is effectively doing a cold start. All > >>> adjacencies will go down. All LSAs originated by this router become > >>> invalid. All routes will be removed from the forwarding plane. If > >>> you are running BGP all the BGP nexthops will be gone on the router > >>> which is changing its identity. Restoration of the adjacencies and > >>> reacquisition of the LSDB will take multiple seconds. The best you > >>> can hope for is several seconds of disruption - it could easily be > >>> much longer. > >>> > >>> For the new node which has usurped the old node's identity it will > >>> have to purge/replace all of the LSAs generated by the old > >>> node. While normal operation of the update process will insure that > >>> this happens in a reliable way the amount of flooding network-wide > >>> required to bringup a new node has now been roughly doubled > >>> i.e. the old node must reissue all of its LSAs using a new identity > >>> and the new node must purge/replace the old node's LSAs with its > >>> own versions. This will result in multiple SPFs on all nodes in the > >>> network and likely cause loops/blackholes during the transition > >>> since some of the SPFs will be run on versions of the LSDB which > >>> are inaccurate (part old node's old LSAs and part new node's > >>> LSAs). Suggesting that this could be handled in the same way/time > >>> as we typically handle a single link failure isn't credible. > >> > >> All routers are supposed to keep a fixed router-id across reboots. If > >> interfaces are changed when down, the last used router-id should be on > >> flash. If flash is removed and replaced (rather than a new image > >> installed), then with the same set of interfaces, the same decision > >> should be made. We are down to a very special case where both flash > >> and interfaces are removed and replaced yielding no history and a > >> different set of MACs to pick from. > >> > >>>>> Your statement that what I propose is only relevant when two routers > >>>>> go down does not match the scenarios I envision. If I want to add a > >>>>> new device to my network or if I need to replace an existing device > >>> in > >>>>> my network I am only affecting one device - but as I am introducing > >>> a > >>>>> device with a new fingerprint it is possible that it will introduce > >>> a > >>>>> conflict with an existing router-id. > >>>> > >>>> In provider networks routers are generally added during maintenance > >>>> windows so should anything unexpected happen, impact is minimized. > >>>> > >>>> In home nets, the home user isn't going to notice the convergence time > >>>> if there is any. A 10 msec SPF delay is likely to be plenty. > >>> > >>> As I stated above, disruption will be orders of magnitude longer than > >>> 10 ms. > >> > >> In a home net? With perhaps a half dozen routers and a default route? > >> Someone has a very bad OSPF implementation. :-) Or did you miss the > >> "In home nets" at the front of the paragraph. > >> > >> For example, in a 10 node network with average degree 4, perhpas 40 > >> links in 10 router LSA exist. A few RTT (less than 1 msec for a > >> homenet) for each neighbor adjacency (which happen in parallel) and > >> ten packets from 4 sources is needed to reach the full state followed > >> by one SPF to be fully up and running. Other routers get one > >> additional router LSA plus four new links in existing router LSA and > >> have to run an SPF. Even on a software based homenet router using an > >> ARM, 10 msec is likely to be enough time and if it is "orders of > >> magnitude" longer, something is wrong with one of the implementations. > >> This would be an more complicated than usual home net or even soho, > >> more likely a small business. > >> > >>>>> In a subsequent reply you liked the idea of the new device delaying > >>>>> advertising reachability until it is has determined that its > >>> router-id > >>>>> choice is not in conflict. The old/new router paradigm supports this > >>>>> strategy by assuring that the old router will not consider changing > >>>>> its router-id until enough time has elapsed for the new router to > >>>>> transition to being an old router. > >>>> > >>>> If it wins the coin toss, the router would advertise at least one LSA > >>>> to indicate its existance and could hold back on any additional > >>>> advertisements until the other router has withdrawn routes. > >>>> > >>> > >>> This suggestion does not alter the fact that if the old node changes > >>>>> its router-id the network has to respond to three events: > >>> > >>> 1)Loss of the old node > >>> 2)Introduction of the old-node with a new identity > >>> 3)Introduction of the new node with the identity of the old-node > >> > >> Again, the old node should remember the last router-id used and try to > >> reuse it. > >> > >>> If however we insure that the old-node does not change its identity > >>> then the network only has to respond to a single event - the > >>> introduction of the new-node. > >> > >> Yes and if it were up and won the resolution last time, it will have > >> saved that router-id and will reuse it. If it came up previously and > >> lost the resolution, then it will remember the router-id it used, > >> whether second or third pick, and use that. > >> > >>>>> Finally, what I propose is extremely simple to implement. I think it > >>>>> isn't much of an exaggeration to say that any one of us could have > >>>>> implemented the enhancement in the time it has taken to discuss its > >>>>> merits. So we aren't overengineering for a case which is admittedly > >>>>> very unlikely to occur - we are adding a modest extension to make > >>> our > >>>>> solution less disruptive. > >>>> > >>>> Yes but it it *bad* for the more common case where routers go down > >>>> occasionally. > >>> > >>> You are going to have to clarify exactly what "bad side effects" you > >>> see for what I propose - because I don't see any - whereas I do > >>> see benefits as described above. > >> > >> If router-id is not remembered between reboots, then there is the one > >> in 4 billion time number of routers (less than 10 for a home net > >> today, but maybe more in the future). > >> > >> If router-id is remembered between reboots, then no matter how long a > >> router has been down, if nothing else in the network changed, there is > >> zero chance of having a collision. > >> > >> With either method, if router-id is remembered between reboots, then > >> there is zero chance of collision. > >> > >> IMO should this ever be used on a managed network (including a home > >> net / soho / small business net that happens to be managed) then > >> having routers come back from a reboot with the same router-ids would > >> be a big plus. For example, after a power outage NMS discovery would > >> not have to be repeated. > >> > >>> Les > >>> > >>> > >>>> > >>>>> Les > >>>> > >>>> Curtis > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > >>>>>> Sent: Friday, February 07, 2014 9:22 AM > >>>>>> To: Les Ginsberg (ginsberg) > >>>>>> Cc: Acee Lindem; Curtis Villamizar; OSPF List > >>>>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - > >>> draft-ietf-ospf-ospfv3- > >>>>>> autoconfig-05.txt > >>>>>> > >>>>>> > >>>>>> In message >>>> x02.cisco.com> > >>>>>> "Les Ginsberg (ginsberg)" writes: > >>>>>>> > >>>>>>> So, I am one person who raised this concern to Acee - but the > >>> proposal > >>>>>>> outlined by Acee is not what I had in mind. There is no need to > >>> use > >>>>>>> "uptime" or to invent some unusual exchange of LSAs prior to > >>> Exchange > >>>>>>> state. > >>>>>>> > >>>>>>> Also, in regards to Curtis's comment - it is not DOS attacks > >>> that I am > >>>>>>> trying to mitigate here. As he says if an attacker is in your > >>> network > >>>>>>> and able to originate credible packets no strategy is safe. > >>>>>>> > >>>>>>> The motivating use case is to minimize disruption of a stable > >>> network > >>>>>>> when a new router is added or an existing router is > >>>>>>> replaced/rebooted. In other words non-disruptive handling of the > >>>>>>> common maintenance/upgrade scenarios. > >>>>>>> > >>>>>>> What I have in mind is this: > >>>>>>> > >>>>>>> 1) A router needs a way to advertise that it has been up and > >>> running > >>>>>>> for a minimum length of time - for the sake of discussion > >>> let's say > >>>>>>> 20 minutes. Routers then fall into two categories: > >>>>>>> > >>>>>>> o Old routers (up >= minimum time) > >>>>>>> o New routers (up < minimum time) > >>>>>>> > >>>>>>> 2) When a duplicate router-id is detected, the first tie > >>> breaker is > >>>>>>> between old routers and new routers. The old router gets to > >>> keep > >>>>>>> its router-id and the new router picks a new router-id. If > >>> both > >>>>>>> routers are "new" or both routers are "old" then we revert > >>> to the > >>>>>>> existing tie breakers defined in the document (link local > >>> address > >>>>>>> for directly connected routers and fingerprint info for > >>>>>>> non-neighbors). > >>>>>>> > >>>>>>> 3) Advertisement of the "old/new" state requires a single bit - > >>> but it > >>>>>>> has to be available both in hellos and the new AC-LSA. > >>> Adding it to > >>>>>>> the AC-LSA is easy to do. For hellos, there are two > >>> possibilities: > >>>>>>> > >>>>>>> o Use one of the Options Bits > >>>>>>> o Use LLS > >>>>>>> > >>>>>>> Be interested in how folks feel about this. > >>>>>>> > >>>>>>> Les > >>>>>> > >>>>>> > >>>>>> Les, > >>>>>> > >>>>>> Excluding DoS attack, we are talking about a one in 4 billion case > >>>>>> (for any two routers, so with 400 routers, still well under one > >>> in 1M) > >>>>>> where two routers hash a MAC address or pick a one time random > >>> number > >>>>>> from out of nowhere and end up with the same number. > >>>>>> > >>>>>> If that does happen (and one in 1M is certainly possible), then it > >>>>>> would be nice if the routers always ended up with the same > >>> router-id. > >>>>>> This could be accomplished by some fixed method such as hashing a > >>>>>> constant with the first choice or router-id or using the > >>> router-id as > >>>>>> a seed for the random number generator (which will pick the same > >>>>>> sequence of random numbers each time). If this is done, then a > >>>>>> conflict would always produce the same set of next picks. The > >>> set of > >>>>>> routers in a given network would always end up with the same > >>>>>> router-ids once they all came up and if only one went down at a > >>> time > >>>>>> then it would always end up with the same router-id when it came > >>> up. > >>>>>> > >>>>>> Zero conf was mainly intended for unmanaged networks (motivated by > >>>>>> work in the homenet WG). In these small unmanaged networks it > >>> doesn't > >>>>>> matter which router gets what router-id as long as they end up > >>> unique > >>>>>> and convergence is in a reasonable time relative to keeping > >>> eyeballs > >>>>>> happy. It could be applied to enterprise or providers but in > >>> either > >>>>>> case having the routers end up with the same router-ids would > >>> make for > >>>>>> easier management. > >>>>>> > >>>>>> For your scenario to matter at all with current rules, both > >>> routers in > >>>>>> the conflict would have to go down. If only the one that is > >>> preferred > >>>>>> goes down, the other is not going to change its router-id as a > >>> result > >>>>>> so when it comes up it gets its first pick with no conflict. If > >>> the > >>>>>> one that was not preferred goes down, it comes up, sees a > >>> conflict and > >>>>>> takes its second pick (loses the conflict every time). It is > >>> only if > >>>>>> they both go down and the one that normally loses the conflict > >>> comes > >>>>>> up first that there is a change in router-id. That too can be > >>> solved > >>>>>> with a rule that you always come up with the last router-id used. > >>>>>> > >>>>>> Curtis > >>>>>> > >>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee > >>> Lindem > >>>>>>>> Sent: Thursday, February 06, 2014 5:12 PM > >>>>>>>> To: Curtis Villamizar > >>>>>>>> Cc: OSPF List > >>>>>>>> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - > >>> draft-ietf-ospf- > >>>> ospfv3- > >>>>>>>> autoconfig-05.txt > >>>>>>>> > >>>>>>>> Hi Curtis, > >>>>>>>> I agree and believe the significance of this use case where a > >>> new > >>>> router > >>>>>> is > >>>>>>>> inserted into an auto-configured domain has been greater > >>> exaggerated. > >>>>>>>> Thanks, > >>>>>>>> Acee > >>>>>>>> On Feb 5, 2014, at 3:58 PM, Curtis Villamizar > >>> > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> In message > >>>>>>>>> Acee Lindem writes: > >>>>>>>>> > >>>>>>>>>> The OSPFv3 autoconfiguration draft was cloned and > >>> presented in the > >>>>>>>>>> ISIS WG > >>> (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). > >>>> In > >>>>>>>>>> the ISIS WG, there was a concern that the resolution of a > >>>> duplicate > >>>>>>>>>> system ID did not include the amount of time the router was > >>>>>>>>>> operational when determining which router would need to > >>> choose a > >>>> new > >>>>>>>>>> router ID. With additional complexity, we could > >>> incorporate router > >>>>>>>>>> uptime into the resolution process. One way to do this > >>> would be > >>>> to: > >>>>>>>>>> > >>>>>>>>>> 1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It > >>> would > >>>> include > >>>>>>>>>> the uptime in seconds. > >>>>>>>>>> > >>>>>>>>>> 2. Use the Router Uptime TLV as the primary > >>> determinant in > >>>>>>>>>> deciding which router must choose a new OSPFv3 > >>> Router > >>>>>>>>>> ID. Router uptimes less than 3600 (MaxAge) seconds > >>> apart > >>>> are > >>>>>>>>>> considered equal. > >>>>>>>>>> > >>>>>>>>>> 3. When an OSPFv3 Hello is received with a different > >>> link- > >>>> local > >>>>>>>>>> source address but a different router-id, unicast the > >>>> OSPFv3 > >>>>>>>>>> AC-LSA to the neighbor so that OSPFv3 duplicate router > >>>>>>>>>> resolution can proceed as in the case where it is > >>> received > >>>>>>>>>> through the normal flooding process. This is somewhat > >>> of a > >>>>>>>>>> hack as the we'd also need to accept OSPF Link State > >>>> Updates > >>>>>>>>>> from a neighbor that is not in Exchange State or > >>> greater. > >>>>>>>>>> > >>>>>>>>>> An alternative to #3 would be to use Link-Local Signaling > >>> (LLS) > >>>> for > >>>>>>>>>> signaling the contents of the OSPFv3 AC-LSA. However, > >>> you'd only > >>>> want > >>>>>>>>>> to send the Router-Uptime and Router Hardware Fingerprint > >>> when a > >>>>>>>>>> duplicate Router-ID is detected. This requires > >>> implementing the > >>>>>>>>>> resolution two ways but may be preferable since it doesn't > >>> require > >>>>>>>>>> violating the flooding rules. > >>>>>>>>>> > >>>>>>>>>> In any case, I'd like to get other opinions as to whether > >>> this > >>>> problem > >>>>>>>>>> is worth solving. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Acee > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Acee, > >>>>>>>>> > >>>>>>>>> If the basis for router-id on boot up results in a fixed > >>> value, and > >>>> if > >>>>>>>>> a duplicate will occur on a give network, then which of two > >>>> duplicate > >>>>>>>>> routers gets that value may change after one of them > >>> reboots. If > >>>>>>>>> uptime is not considered, it will never change as long as > >>> one > >>>> router > >>>>>>>>> stays up at any given time. > >>>>>>>>> > >>>>>>>>> We are talking about a very low probability event (a > >>> duplicate) > >>>> except > >>>>>>>>> if this is a DoS attack and then either using or not using > >>> uptime > >>>>>>>>> won't matter since the attacker will claim an impossibly > >>> long > >>>> uptime. > >>>>>>>>> > >>>>>>>>> Curtis > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf From nobody Sat Feb 15 04:22:24 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 A43121A01DC for ; Sat, 15 Feb 2014 04:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUDGNFAUsOfd for ; Sat, 15 Feb 2014 04:22:19 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id 26C9F1A00D5 for ; Sat, 15 Feb 2014 04:22:19 -0800 (PST) Received: from linne.localnet (91.97.110.48) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 036BA3; Sat, 15 Feb 2014 13:22:07 +0100 From: Karsten Thomann To: ospf@ietf.org Date: Sat, 15 Feb 2014 13:22:11 +0100 Message-ID: <22830726.PZv4OAbFD0@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart8146481.33cAHHMDrd" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 8 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/DF8YztoRPkKQqi1MpNmXjDFgBuU Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 12:22:22 -0000 This is a multi-part message in MIME format. --nextPart8146481.33cAHHMDrd Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson: > Earlier, Karsten Thomann wrote, in part: > > I don't know if i have missed that part, but what would happen if OSPFv3 > > is running over IPv4 and there are two (or more) IPv6 Islands already > > deployed within the network, should there be any LSA flooding checks, > > like do not flood LSA with IPv6 networks over IPv4 only links, or should > > the route > > calculation/installation of the information simply fail > > as there is no valid path? > > The OSPF deployments I am familiar with did not "auto deploy" > or "self deploy". Instead, all of the OSPF deployments that I am > familiar with had engineers making deliberate decisions about how > to configure the OSPF deployment, and also how to configure the > OSPF routers in that deployment. I know that such deployments are normally well planned, but as there is already a draft about ospfv3 autoconfig, even if it is not designed to be used in company networks. > One deployment option, already deployed in some places, is to run > "ships in the night". In this model, the IPv4 topology exclusively > uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3 > over IPv6. For some sites, that is a good option. A number of my > clients are very interested in this new I-D because it optimises > their IPv6 transition strategy. > > For some sites, IPv6 transition is simplified, optimised, and also > cost-reduced by using OSPFv3 over IPv4 initially, and carrying both > IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment > (i.e. using the Address Family extension to keep the prefixes clearly > differentiated within a single OSPFv3 deployment). This can lower > operational costs because one can get by with managing only OSPFv3, > rather than having to manage both OSPFv2 and OSPFv3. > > If one's "IPv6 islands" (to use your term) are really dual-stack > (aside: having dual-stack rather than IPv6-only would be expected > and normal if another part of one's OSPF deployment is using > OSPF over IPv4), then EITHER the whole deployment should be configured > to run over IPv4 XOR the whole deployment should be configured > to run over IPv6. > > Having different "IPv4 islands" and "IPv6 islands" is an explicit choice > of a configuration engineer or design engineer. That probably is not > the optimal deployment choice for an engineer to make. It definitely > is NOT a choice that I would make or that I would recommend to my clients. I would not do it either, but I have already seen some strange ospf designs..., and as mentioned it is a case which can happen with ospf autoconfiguration, but we don't need to discuss it further as it is for homenetworks > From the descriptions and definitions in the draft, it would not be > "normal" or "expected" to mix IPv6 transport with IPv4 transport > within a single OSPFv3 deployment. > > > Is there any explicit preference over which version the adjacency > > is build if v4 and v6 is available in that specific part of the network? > > The choice of preferred OSPF transport really is something that the > configuration engineer ought to configure. As the details of configuring > any IP router are outside the scope of the IETF, I am not sure that > this I-D properly can or should say very more than it already says. > > Perhaps the I-D could add clarifying text along these lines > somewhere in Section 2: > > "Implementers of OSPFv3 over IPv4 SHOULD add a configuration > knob to let the router administrator select whether a given > OSPFv3-enabled interface should use OSPFv3 over IPv4 or > OSPFv3 over IPv6. Except when an OSPFv3 deployment is being > transitioned from using IPv4 transmission to using IPv6 > transmission, it is RECOMMENDED that all routers within an > OSPFv3 deployment use the same IP version for OSPFv3 packet > transmission." > > > What should happen when an IPv4 Link gets v6 added, graceful reestablish > > the adjacency over IPv6, or wait until forced protocol switch? > > See my answer just above. > > I would expect that any router that implements this I-D also would implement > a configuration knob to indicate whether IPv4 transmission or IPv6 > transmission is preferred. Over time, a configuration engineer might > change this (e.g. manually change from IPv4 transmission to IPv6 > transmission AFTER an entire IPv4 network has been > deployed-with/converted-to dual-stack IPv4 and IPv6). > > Yours, > > Ran Atkinson Thanks for the detailed anwsers, I'm satisfied with the addition. Kind regards, Karsten > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --nextPart8146481.33cAHHMDrd Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson:

> Earlier, Karsten Thomann wrote, in part:

> > I don't know if i have missed that part, but what would happen if OSPFv3

> > is running over IPv4 and there are two (or more) IPv6 Islands already

> > deployed within the network, should there be any LSA flooding checks,

> > like do not flood LSA with IPv6 networks over IPv4 only links, or should

> > the route

> > calculation/installation of the information simply fail

> > as there is no valid path?

>

> The OSPF deployments I am familiar with did not "auto deploy"

> or "self deploy". Instead, all of the OSPF deployments that I am

> familiar with had engineers making deliberate decisions about how

> to configure the OSPF deployment, and also how to configure the

> OSPF routers in that deployment.

I know that such deployments are normally well planned, but as there is already a draft about ospfv3 autoconfig, even if it is not designed to be used in company networks.

 

> One deployment option, already deployed in some places, is to run

> "ships in the night". In this model, the IPv4 topology exclusively

> uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3

> over IPv6. For some sites, that is a good option. A number of my

> clients are very interested in this new I-D because it optimises

> their IPv6 transition strategy.

>

> For some sites, IPv6 transition is simplified, optimised, and also

> cost-reduced by using OSPFv3 over IPv4 initially, and carrying both

> IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment

> (i.e. using the Address Family extension to keep the prefixes clearly

> differentiated within a single OSPFv3 deployment). This can lower

> operational costs because one can get by with managing only OSPFv3,

> rather than having to manage both OSPFv2 and OSPFv3.

>

> If one's "IPv6 islands" (to use your term) are really dual-stack

> (aside: having dual-stack rather than IPv6-only would be expected

> and normal if another part of one's OSPF deployment is using

> OSPF over IPv4), then EITHER the whole deployment should be configured

> to run over IPv4 XOR the whole deployment should be configured

> to run over IPv6.

>

> Having different "IPv4 islands" and "IPv6 islands" is an explicit choice

> of a configuration engineer or design engineer. That probably is not

> the optimal deployment choice for an engineer to make. It definitely

> is NOT a choice that I would make or that I would recommend to my clients.

I would not do it either, but I have already seen some strange ospf designs..., and as mentioned it is a case which can happen with ospf autoconfiguration, but we don't need to discuss it further as it is for homenetworks

 

> From the descriptions and definitions in the draft, it would not be

> "normal" or "expected" to mix IPv6 transport with IPv4 transport

> within a single OSPFv3 deployment.

>

> > Is there any explicit preference over which version the adjacency

> > is build if v4 and v6 is available in that specific part of the network?

>

> The choice of preferred OSPF transport really is something that the

> configuration engineer ought to configure. As the details of configuring

> any IP router are outside the scope of the IETF, I am not sure that

> this I-D properly can or should say very more than it already says.

>

> Perhaps the I-D could add clarifying text along these lines

> somewhere in Section 2:

>

> "Implementers of OSPFv3 over IPv4 SHOULD add a configuration

> knob to let the router administrator select whether a given

> OSPFv3-enabled interface should use OSPFv3 over IPv4 or

> OSPFv3 over IPv6. Except when an OSPFv3 deployment is being

> transitioned from using IPv4 transmission to using IPv6

> transmission, it is RECOMMENDED that all routers within an

> OSPFv3 deployment use the same IP version for OSPFv3 packet

> transmission."

>

> > What should happen when an IPv4 Link gets v6 added, graceful reestablish

> > the adjacency over IPv6, or wait until forced protocol switch?

>

> See my answer just above.

>

> I would expect that any router that implements this I-D also would implement

> a configuration knob to indicate whether IPv4 transmission or IPv6

> transmission is preferred. Over time, a configuration engineer might

> change this (e.g. manually change from IPv4 transmission to IPv6

> transmission AFTER an entire IPv4 network has been

> deployed-with/converted-to dual-stack IPv4 and IPv6).

>

> Yours,

>

> Ran Atkinson

 

Thanks for the detailed anwsers, I'm satisfied with the addition.

 

Kind regards,

Karsten

>

>

> _______________________________________________

> OSPF mailing list

> OSPF@ietf.org

> https://www.ietf.org/mailman/listinfo/ospf

--nextPart8146481.33cAHHMDrd-- From nobody Mon Feb 17 09:20:48 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 B29EA1A03F6 for ; Mon, 17 Feb 2014 09:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2UnG6O0ymb5L for ; Mon, 17 Feb 2014 09:20:39 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF071A00B4 for ; Mon, 17 Feb 2014 09:20:38 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-2f-530244de40ae Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C2.E0.12743.FD442035; Mon, 17 Feb 2014 18:20:31 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 12:20:34 -0500 From: Acee Lindem To: Karsten Thomann , "ospf@ietf.org" Thread-Topic: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt Thread-Index: AQHPLASQC4hPn9qVfUSdHygqv/z3Nw== Date: Mon, 17 Feb 2014 17:20:33 +0000 Message-ID: In-Reply-To: <22830726.PZv4OAbFD0@linne> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_CF2757AC27498aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXSPn+59F6Zgg/e/JSy23DrKZNFy7x67 A5PHkiU/mTweHjzEHsAUxWWTkpqTWZZapG+XwJVx5NNG5oKllxgr/rX/ZmlgPLGNsYuRk0NC wERi14qZLBC2mMSFe+vZuhi5OIQEjjBKnLv5khHCWc4ocebiQ2aQKjYBHYnnj/6B2SICQRKb vh0B6xYWsJf4vOAdK0TcQaLnzCOoGj2JiwuWgNWwCKhKnG1fBxbnFTCV2Lt1PZjNKaAhsez8 F7AaRqArvp9awwRiMwuIS9x6Mp8J4joBiSV7zjND2KISLx//A9slCjS/e9ZyVoi4ksTH3/PZ IXqjJJa3f2OB2CUocXLmE5YJjCKzkIydhaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48Burl ALKtJf6eNUJWsoCRYxUjR2lxalluupHBJkZgZB2TYNPdwbjnpeUhRmkOFiVx3i9vnYOEBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MPI5fcy3Fkhqm75atf1SW+G7Rde/OaokHnvot6frRFa9 kthm16M9HAHWffa+4jobwnsL/DkMN8fvn9H86HOpedrTFNHQ1YIvDiw9u3L5hcqJt76d/hZb caPPZo7HupmapQ8jc+edupUc15zZpNJ0On+dyIfFv0/0pmlGiO3L05nyuHeSn3p0ghJLcUai oRZzUXEiAI0FH/x6AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/qdE-xWSs6CYErwP62rXOrmwMXAs Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:20:46 -0000 --_000_CF2757AC27498aceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Karsten, We wil add Ran's suggested text to the next revision. Thanks, Acee From: Karsten Thomann > Date: Saturday, February 15, 2014 4:22 AM To: OSPF - OSPF WG List > Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson: > Earlier, Karsten Thomann wrote, in part: > > I don't know if i have missed that part, but what would happen if OSPFv= 3 > > is running over IPv4 and there are two (or more) IPv6 Islands already > > deployed within the network, should there be any LSA flooding checks, > > like do not flood LSA with IPv6 networks over IPv4 only links, or shoul= d > > the route > > calculation/installation of the information simply fail > > as there is no valid path? > > The OSPF deployments I am familiar with did not "auto deploy" > or "self deploy". Instead, all of the OSPF deployments that I am > familiar with had engineers making deliberate decisions about how > to configure the OSPF deployment, and also how to configure the > OSPF routers in that deployment. I know that such deployments are normally well planned, but as there is alr= eady a draft about ospfv3 autoconfig, even if it is not designed to be used= in company networks. > One deployment option, already deployed in some places, is to run > "ships in the night". In this model, the IPv4 topology exclusively > uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3 > over IPv6. For some sites, that is a good option. A number of my > clients are very interested in this new I-D because it optimises > their IPv6 transition strategy. > > For some sites, IPv6 transition is simplified, optimised, and also > cost-reduced by using OSPFv3 over IPv4 initially, and carrying both > IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment > (i.e. using the Address Family extension to keep the prefixes clearly > differentiated within a single OSPFv3 deployment). This can lower > operational costs because one can get by with managing only OSPFv3, > rather than having to manage both OSPFv2 and OSPFv3. > > If one's "IPv6 islands" (to use your term) are really dual-stack > (aside: having dual-stack rather than IPv6-only would be expected > and normal if another part of one's OSPF deployment is using > OSPF over IPv4), then EITHER the whole deployment should be configured > to run over IPv4 XOR the whole deployment should be configured > to run over IPv6. > > Having different "IPv4 islands" and "IPv6 islands" is an explicit choice > of a configuration engineer or design engineer. That probably is not > the optimal deployment choice for an engineer to make. It definitely > is NOT a choice that I would make or that I would recommend to my clients= . I would not do it either, but I have already seen some strange ospf designs= ..., and as mentioned it is a case which can happen with ospf autoconfigura= tion, but we don't need to discuss it further as it is for homenetworks > From the descriptions and definitions in the draft, it would not be > "normal" or "expected" to mix IPv6 transport with IPv4 transport > within a single OSPFv3 deployment. > > > Is there any explicit preference over which version the adjacency > > is build if v4 and v6 is available in that specific part of the network= ? > > The choice of preferred OSPF transport really is something that the > configuration engineer ought to configure. As the details of configuring > any IP router are outside the scope of the IETF, I am not sure that > this I-D properly can or should say very more than it already says. > > Perhaps the I-D could add clarifying text along these lines > somewhere in Section 2: > > "Implementers of OSPFv3 over IPv4 SHOULD add a configuration > knob to let the router administrator select whether a given > OSPFv3-enabled interface should use OSPFv3 over IPv4 or > OSPFv3 over IPv6. Except when an OSPFv3 deployment is being > transitioned from using IPv4 transmission to using IPv6 > transmission, it is RECOMMENDED that all routers within an > OSPFv3 deployment use the same IP version for OSPFv3 packet > transmission." > > > What should happen when an IPv4 Link gets v6 added, graceful reestablis= h > > the adjacency over IPv6, or wait until forced protocol switch? > > See my answer just above. > > I would expect that any router that implements this I-D also would implem= ent > a configuration knob to indicate whether IPv4 transmission or IPv6 > transmission is preferred. Over time, a configuration engineer might > change this (e.g. manually change from IPv4 transmission to IPv6 > transmission AFTER an entire IPv4 network has been > deployed-with/converted-to dual-stack IPv4 and IPv6). > > Yours, > > Ran Atkinson Thanks for the detailed anwsers, I'm satisfied with the addition. Kind regards, Karsten > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --_000_CF2757AC27498aceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <895440F07A191A42902C8C132C13F5CE@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Karsten, 
We wil add Ran's suggested text to the next revision.
Thanks,
Acee 

From: Karsten Thomann <karsten_thomann@linfre.de>
Date: Saturday, February 15, 2014 4= :22 AM
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] draft-chen-ospf= -transition-to-ospfv3-00.txt

Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson:

> Earlier, Karsten Thomann wrote, in part:

> > I don't know if i have missed that part, but what would happen if= OSPFv3

> > is running over IPv4 and there are two (or more) IPv6 Islands alr= eady

> > deployed within the network, should there be any LSA flooding che= cks,

> > like do not flood LSA with IPv6 networks over IPv4 only links, or= should

> > the route

> > calculation/installation of the information simply fail

> > as there is no valid path?

>

> The OSPF deployments I am familiar with did not "auto deploy"= ;

> or "self deploy". Instead, all of the OSPF deployments that = I am

> familiar with had engineers making deliberate decisions about how

> to configure the OSPF deployment, and also how to configure the

> OSPF routers in that deployment.

I know that such deployments are normally well planned, but as there is alr= eady a draft about ospfv3 autoconfig, even if it is not designed to be used= in company networks.

 

> One deployment option, already deployed in some places, is to run

> "ships in the night". In this model, the IPv4 topology exclu= sively

> uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3

> over IPv6. For some sites, that is a good option. A number of my

> clients are very interested in this new I-D because it optimises

> their IPv6 transition strategy.

>

> For some sites, IPv6 transition is simplified, optimised, and also

> cost-reduced by using OSPFv3 over IPv4 initially, and carrying both

> IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment

> (i.e. using the Address Family extension to keep the prefixes clearly<= /p>

> differentiated within a single OSPFv3 deployment). This can lower

> operational costs because one can get by with managing only OSPFv3,

> rather than having to manage both OSPFv2 and OSPFv3.

>

> If one's "IPv6 islands" (to use your term) are really dual-s= tack

> (aside: having dual-stack rather than IPv6-only would be expected

> and normal if another part of one's OSPF deployment is using

> OSPF over IPv4), then EITHER the whole deployment should be configured=

> to run over IPv4 XOR the whole deployment should be configured

> to run over IPv6.

>

> Having different "IPv4 islands" and "IPv6 islands"= is an explicit choice

> of a configuration engineer or design engineer. That probably is not

> the optimal deployment choice for an engineer to make. It definitely

> is NOT a choice that I would make or that I would recommend to my clie= nts.

I would not do it either, but I have already seen some strange ospf designs= ..., and as mentioned it is a case which can happen with ospf autoconfigura= tion, but we don't need to discuss it further as it is for homenetworks

 

> From the descriptions and definitions in the draft, it would not be

> "normal" or "expected" to mix IPv6 transport with = IPv4 transport

> within a single OSPFv3 deployment.

>

> > Is there any explicit preference over which version the adjacency=

> > is build if v4 and v6 is available in that specific part of the n= etwork?

>

> The choice of preferred OSPF transport really is something that the

> configuration engineer ought to configure. As the details of configuri= ng

> any IP router are outside the scope of the IETF, I am not sure that

> this I-D properly can or should say very more than it already says.

>

> Perhaps the I-D could add clarifying text along these lines

> somewhere in Section 2:

>

> "Implementers of OSPFv3 over IPv4 SHOULD add a configuration

> knob to let the router administrator select whether a given

> OSPFv3-enabled interface should use OSPFv3 over IPv4 or

> OSPFv3 over IPv6. Except when an OSPFv3 deployment is being

> transitioned from using IPv4 transmission to using IPv6

> transmission, it is RECOMMENDED that all routers within an

> OSPFv3 deployment use the same IP version for OSPFv3 packet

> transmission."

>

> > What should happen when an IPv4 Link gets v6 added, graceful rees= tablish

> > the adjacency over IPv6, or wait until forced protocol switch?

>

> See my answer just above.

>

> I would expect that any router that implements this I-D also would imp= lement

> a configuration knob to indicate whether IPv4 transmission or IPv6

> transmission is preferred. Over time, a configuration engineer might

> change this (e.g. manually change from IPv4 transmission to IPv6

> transmission AFTER an entire IPv4 network has been

> deployed-with/converted-to dual-stack IPv4 and IPv6).

>

> Yours,

>

> Ran Atkinson

 

Thanks for the detailed anwsers, I'm satisfied with the addition.

 

Kind regards,

Karsten

>

>

> _______________________________________________

> OSPF mailing list

> OSPF@ietf.org

> https://www.iet= f.org/mailman/listinfo/ospf

 --_000_CF2757AC27498aceelindemericssoncom_-- From nobody Mon Feb 17 12:13: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 4BBA21A0257 for ; Mon, 17 Feb 2014 12:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlwAsRQ0uPCI for ; Mon, 17 Feb 2014 12:13:14 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id C11CF1A027A for ; Mon, 17 Feb 2014 12:13:13 -0800 (PST) Received: from linne.localnet (31.150.5.63) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 2A365F; Mon, 17 Feb 2014 21:13:01 +0100 From: Karsten Thomann To: Acee Lindem , ospf@ietf.org Date: Mon, 17 Feb 2014 21:13:01 +0100 Message-ID: <4840600.E243vrriOs@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart7963050.SuCmYsIaIu" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 8 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/sI6qpN09SKO6elSmSNEngFugKCg Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 20:13:18 -0000 This is a multi-part message in MIME format. --nextPart7963050.SuCmYsIaIu Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="iso-8859-1" Hi Acee, found some nits to resolve in the next draft. 1. Introduction s/to to/to 2. Encapsulation in IPv4 First sentence of the second passage s/by a OSPF/by an OSPF 3. Security Considerations In the second passage is a little typo it should be RFC6506 instead of 6505 5.2 Informative References Headline is right for RFC 6506 and is correct after the headline but listed wrong as RFC6505. Kind regards, Karsten Am Montag, 17. Februar 2014, 17:20:33 schrieben Sie: Hi Karsten, We wil add Ran's suggested text to the next revision. Thanks, Acee *From: *Karsten Thomann *Date: *Saturday, February 15, 2014 4:22 AM *To: *OSPF - OSPF WG List *Subject: *Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson: > Earlier, Karsten Thomann wrote, in part: > > I don't know if i have missed that part, but what would happen if OSPFv3 > > is running over IPv4 and there are two (or more) IPv6 Islands already > > deployed within the network, should there be any LSA flooding checks, > > like do not flood LSA with IPv6 networks over IPv4 only links, or should > > the route > > calculation/installation of the information simply fail > > as there is no valid path? > > The OSPF deployments I am familiar with did not "auto deploy" > or "self deploy". Instead, all of the OSPF deployments that I am > familiar with had engineers making deliberate decisions about how > to configure the OSPF deployment, and also how to configure the > OSPF routers in that deployment. I know that such deployments are normally well planned, but as there is already a draft about ospfv3 autoconfig, even if it is not designed to be used in company networks. > One deployment option, already deployed in some places, is to run > "ships in the night". In this model, the IPv4 topology exclusively > uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3 > over IPv6. For some sites, that is a good option. A number of my > clients are very interested in this new I-D because it optimises > their IPv6 transition strategy. > > For some sites, IPv6 transition is simplified, optimised, and also > cost-reduced by using OSPFv3 over IPv4 initially, and carrying both > IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment > (i.e. using the Address Family extension to keep the prefixes clearly > differentiated within a single OSPFv3 deployment). This can lower > operational costs because one can get by with managing only OSPFv3, > rather than having to manage both OSPFv2 and OSPFv3. > > If one's "IPv6 islands" (to use your term) are really dual-stack > (aside: having dual-stack rather than IPv6-only would be expected > and normal if another part of one's OSPF deployment is using > OSPF over IPv4), then EITHER the whole deployment should be configured > to run over IPv4 XOR the whole deployment should be configured > to run over IPv6. > > Having different "IPv4 islands" and "IPv6 islands" is an explicit choice > of a configuration engineer or design engineer. That probably is not > the optimal deployment choice for an engineer to make. It definitely > is NOT a choice that I would make or that I would recommend to my clients. I would not do it either, but I have already seen some strange ospf designs..., and as mentioned it is a case which can happen with ospf autoconfiguration, but we don't need to discuss it further as it is for homenetworks > From the descriptions and definitions in the draft, it would not be > "normal" or "expected" to mix IPv6 transport with IPv4 transport > within a single OSPFv3 deployment. > > > Is there any explicit preference over which version the adjacency > > is build if v4 and v6 is available in that specific part of the network? > > The choice of preferred OSPF transport really is something that the > configuration engineer ought to configure. As the details of configuring > any IP router are outside the scope of the IETF, I am not sure that > this I-D properly can or should say very more than it already says. > > Perhaps the I-D could add clarifying text along these lines > somewhere in Section 2: > > "Implementers of OSPFv3 over IPv4 SHOULD add a configuration > knob to let the router administrator select whether a given > OSPFv3-enabled interface should use OSPFv3 over IPv4 or > OSPFv3 over IPv6. Except when an OSPFv3 deployment is being > transitioned from using IPv4 transmission to using IPv6 > transmission, it is RECOMMENDED that all routers within an > OSPFv3 deployment use the same IP version for OSPFv3 packet > transmission." > > > What should happen when an IPv4 Link gets v6 added, graceful reestablish > > the adjacency over IPv6, or wait until forced protocol switch? > > See my answer just above. > > I would expect that any router that implements this I-D also would implement > a configuration knob to indicate whether IPv4 transmission or IPv6 > transmission is preferred. Over time, a configuration engineer might > change this (e.g. manually change from IPv4 transmission to IPv6 > transmission AFTER an entire IPv4 network has been > deployed-with/converted-to dual-stack IPv4 and IPv6). > > Yours, > > Ran Atkinson Thanks for the detailed anwsers, I'm satisfied with the addition. Kind regards, Karsten > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org[3] > https://www.ietf.org/mailman/listinfo/ospf[4] -------- [1] mailto:karsten_thomann@linfre.de [2] mailto:ospf@ietf.org [3] mailto:OSPF@ietf.org [4] https://www.ietf.org/mailman/listinfo/ospf --nextPart7963050.SuCmYsIaIu Content-Transfer-Encoding: base64 Content-Type: text/html; charset="iso-8859-1" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iICJodHRwOi8v d3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwL3N0cmljdC5kdGQiPgo8aHRtbD48aGVhZD48bWV0YSBu YW1lPSJxcmljaHRleHQiIGNvbnRlbnQ9IjEiIC8+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KcCwg bGkgeyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IH0KPC9zdHlsZT48L2hlYWQ+PGJvZHkgc3R5bGU9 IiBmb250LWZhbWlseTonVGFob21hJzsgZm9udC1zaXplOjguMjVwdDsgZm9udC13ZWlnaHQ6NDAw OyBmb250LXN0eWxlOm5vcm1hbDsiPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4t Ym90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2st aW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPkhpIEFjZWUsPC9w Pgo8cCBzdHlsZT0iLXF0LXBhcmFncmFwaC10eXBlOmVtcHR5OyBtYXJnaW4tdG9wOjBweDsgbWFy Z2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJs b2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7ICI+Jm5ic3A7PC9wPgo8cCBzdHlsZT0iIG1h cmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4t cmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXIt c3RhdGU6MDsiPmZvdW5kIHNvbWUgbml0cyB0byByZXNvbHZlIGluIHRoZSBuZXh0IGRyYWZ0Ljwv cD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1s ZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVu dDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij4xLiBJbnRyb2R1Y3Rpb248L3A+CjxwIHN0eWxlPSIg bWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7IG1hcmdp bi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNl ci1zdGF0ZTowOyI+cy90byB0by90bzwvcD4KPHAgc3R5bGU9Ii1xdC1wYXJhZ3JhcGgtdHlwZTpl bXB0eTsgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7 IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAi PiZuYnNwOzwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7 IG1hcmdpbi1sZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0 ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij4yLiBFbmNhcHN1bGF0aW9uIGluIElQ djQ8L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJn aW4tbGVmdDowcHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1p bmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+Rmlyc3Qgc2VudGVuY2Ugb2YgdGhlIHNlY29u ZCBwYXNzYWdlPC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBw eDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7 IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPnMvYnkgYSBPU1BGL2J5IGFuIE9T UEY8L3A+CjxwIHN0eWxlPSItcXQtcGFyYWdyYXBoLXR5cGU6ZW1wdHk7IG1hcmdpbi10b3A6MHB4 OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAt cXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgIj4mbmJzcDs8L3A+CjxwIHN0eWxl PSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7IG1h cmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQt dXNlci1zdGF0ZTowOyI+My4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3A+CjxwIHN0eWxlPSIg bWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7IG1hcmdp bi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNl ci1zdGF0ZTowOyI+SW4gdGhlIHNlY29uZCBwYXNzYWdlIGlzIGEgbGl0dGxlIHR5cG8gaXQgc2hv dWxkIGJlIFJGQzY1MDYgaW5zdGVhZCBvZiA2NTA1PC9wPgo8cCBzdHlsZT0iLXF0LXBhcmFncmFw aC10eXBlOmVtcHR5OyBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1s ZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVu dDowcHg7ICI+Jm5ic3A7PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90 dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5k ZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjUuMiBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzPC9wPgo8cCBzdHlsZT0iLXF0LXBhcmFncmFwaC10eXBlOmVtcHR5OyBtYXJn aW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsgbWFyZ2luLXJp Z2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7ICI+Jm5ic3A7PC9w Pgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxl ZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50 OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPkhlYWRsaW5lIGlzIHJpZ2h0IGZvciBSRkMgNjUwNiBh bmQgaXMgY29ycmVjdCBhZnRlciB0aGUgaGVhZGxpbmUgYnV0IGxpc3RlZCB3cm9uZyBhcyBSRkM2 NTA1LjwvcD4KPHAgc3R5bGU9Ii1xdC1wYXJhZ3JhcGgtdHlwZTplbXB0eTsgbWFyZ2luLXRvcDow cHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7IG1hcmdpbi1yaWdodDowcHg7 IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAiPiZuYnNwOzwvcD4KPHAgc3R5 bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsg bWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1x dC11c2VyLXN0YXRlOjA7Ij5LaW5kIHJlZ2FyZHMsPC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6 MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4 OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsi PkthcnN0ZW48L3A+CjxwIHN0eWxlPSItcXQtcGFyYWdyYXBoLXR5cGU6ZW1wdHk7IG1hcmdpbi10 b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6 MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgIj4mbmJzcDs8L3A+Cjxw IHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDow cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4 OyAtcXQtdXNlci1zdGF0ZTowOyI+QW0gTW9udGFnLCAxNy4gRmVicnVhciAyMDE0LCAxNzoyMDoz MyBzY2hyaWViZW4gU2llOjxiciAvPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjEycHg7IG1h cmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo0MHB4OyBtYXJnaW4tcmlnaHQ6NDBweDsgLXF0 LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij5IaSBL YXJzdGVuLKA8L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4 OyBtYXJnaW4tbGVmdDo0MHB4OyBtYXJnaW4tcmlnaHQ6NDBweDsgLXF0LWJsb2NrLWluZGVudDow OyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij5XZSB3aWwgYWRkIFJhbidzIHN1 Z2dlc3RlZCB0ZXh0IHRvIHRoZSBuZXh0IHJldmlzaW9uLjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4t dG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjQwcHg7IG1hcmdpbi1yaWdo dDo0MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3Rh dGU6MDsiPlRoYW5rcyw8L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0 b206MHB4OyBtYXJnaW4tbGVmdDo0MHB4OyBtYXJnaW4tcmlnaHQ6NDBweDsgLXF0LWJsb2NrLWlu ZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij5BY2VloDwvcD4KPHAg c3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjQw cHg7IG1hcmdpbi1yaWdodDo0MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBw eDsgLXF0LXVzZXItc3RhdGU6MDsiPjxiciAvPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBw eDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsg LXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48 c3BhbiBzdHlsZT0iIGZvbnQtZmFtaWx5OidDYWxpYnJpJzsgZm9udC1zaXplOjExcHQ7IGZvbnQt d2VpZ2h0OjYwMDsgY29sb3I6IzAwMDAwMDsiPkZyb206IDwvc3Bhbj48c3BhbiBzdHlsZT0iIGZv bnQtZmFtaWx5OidDYWxpYnJpJzsgZm9udC1zaXplOjExcHQ7IGNvbG9yOiMwMDAwMDA7Ij5LYXJz dGVuIFRob21hbm4gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2Fyc3Rlbl90aG9tYW5uQGxp bmZyZS5kZSI+PHNwYW4gc3R5bGU9IiBmb250LWZhbWlseTonQ2FsaWJyaSc7IGZvbnQtc2l6ZTox MXB0OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgY29sb3I6IzAwMDBmZjsiPmthcnN0ZW5f dGhvbWFubkBsaW5mcmUuZGU8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSIgZm9udC1mYW1pbHk6J0Nh bGlicmknOyBmb250LXNpemU6MTFwdDsgY29sb3I6IzAwMDAwMDsiPiZndDs8YnIgLz48L3NwYW4+ PHNwYW4gc3R5bGU9IiBmb250LWZhbWlseTonQ2FsaWJyaSc7IGZvbnQtc2l6ZToxMXB0OyBmb250 LXdlaWdodDo2MDA7IGNvbG9yOiMwMDAwMDA7Ij5EYXRlOiA8L3NwYW4+PHNwYW4gc3R5bGU9IiBm b250LWZhbWlseTonQ2FsaWJyaSc7IGZvbnQtc2l6ZToxMXB0OyBjb2xvcjojMDAwMDAwOyI+U2F0 dXJkYXksIEZlYnJ1YXJ5IDE1LCAyMDE0IDQ6MjIgQU08YnIgLz48L3NwYW4+PHNwYW4gc3R5bGU9 IiBmb250LWZhbWlseTonQ2FsaWJyaSc7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDo2MDA7 IGNvbG9yOiMwMDAwMDA7Ij5UbzogPC9zcGFuPjxzcGFuIHN0eWxlPSIgZm9udC1mYW1pbHk6J0Nh bGlicmknOyBmb250LXNpemU6MTFwdDsgY29sb3I6IzAwMDAwMDsiPk9TUEYgLSBPU1BGIFdHIExp c3QgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86b3NwZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 IiBmb250LWZhbWlseTonQ2FsaWJyaSc7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsgY29sb3I6IzAwMDBmZjsiPm9zcGZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSIgZm9udC1mYW1pbHk6J0NhbGlicmknOyBmb250LXNpemU6MTFwdDsgY29sb3I6IzAw MDAwMDsiPiZndDs8YnIgLz48L3NwYW4+PHNwYW4gc3R5bGU9IiBmb250LWZhbWlseTonQ2FsaWJy aSc7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDo2MDA7IGNvbG9yOiMwMDAwMDA7Ij5TdWJq ZWN0OiA8L3NwYW4+PHNwYW4gc3R5bGU9IiBmb250LWZhbWlseTonQ2FsaWJyaSc7IGZvbnQtc2l6 ZToxMXB0OyBjb2xvcjojMDAwMDAwOyI+UmU6IFtPU1BGXSBkcmFmdC1jaGVuLW9zcGYtdHJhbnNp dGlvbi10by1vc3BmdjMtMDAudHh0PGJyIC8+PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4t dG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsgbWFyZ2luLXJpZ2h0 OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRl OjA7Ij48YnIgLz48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206 MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6 MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PGEgbmFtZT0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PC9hPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhw dDsiPkE8L3NwYW4+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+bSBNb250YWcsIDEwLiBG ZWJydWFyIDIwMTQsIDE0OjMzOjA1IHNjaHJpZWIgUkogQXRraW5zb246PC9zcGFuPjwvcD4KPHAg c3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVw eDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7 IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IEVh cmxpZXIsIEthcnN0ZW4gVGhvbWFubiB3cm90ZSwgaW4gcGFydDo8L3NwYW4+PC9wPgo8cCBzdHls ZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBt YXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0 LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgJmd0OyBJ IGRvbid0IGtub3cgaWYgaSBoYXZlIG1pc3NlZCB0aGF0IHBhcnQsIGJ1dCB3aGF0IHdvdWxkIGhh cHBlbiBpZiBPU1BGdjM8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJn aW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxv Y2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0 eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgJmd0OyBpcyBydW5uaW5nIG92ZXIgSVB2NCBhbmQg dGhlcmUgYXJlIHR3byAob3IgbW9yZSkgSVB2NiBJc2xhbmRzIGFscmVhZHk8L3NwYW4+PC9wPgo8 cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6 NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBw eDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsg Jmd0OyBkZXBsb3llZCB3aXRoaW4gdGhlIG5ldHdvcmssIHNob3VsZCB0aGVyZSBiZSBhbnkgTFNB IGZsb29kaW5nIGNoZWNrcyw8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBt YXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQt YmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFu IHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgJmd0OyBsaWtlIGRvIG5vdCBmbG9vZCBMU0Eg d2l0aCBJUHY2IG5ldHdvcmtzIG92ZXIgSVB2NCBvbmx5IGxpbmtzLCBvciBzaG91bGQ8L3NwYW4+ PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2lu LWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5k ZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsi PiZndDsgJmd0OyB0aGUgcm91dGU8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4 OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAt cXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxz cGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgJmd0OyBjYWxjdWxhdGlvbi9pbnN0YWxs YXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIHNpbXBseSBmYWlsPC9zcGFuPjwvcD4KPHAgc3R5bGU9 IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFy Z2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11 c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7ICZndDsgYXMg dGhlcmUgaXMgbm8gdmFsaWQgcGF0aD88L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6 MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4 OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsi PjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgPC9zcGFuPjwvcD4KPHAgc3R5bGU9 IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFy Z2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11 c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IFRoZSBPU1BG IGRlcGxveW1lbnRzIEkgYW0gZmFtaWxpYXIgd2l0aCBkaWQgbm90ICZxdW90O2F1dG8gZGVwbG95 JnF1b3Q7PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRv bTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVu dDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZv bnQtc2l6ZTo4cHQ7Ij4mZ3Q7IG9yICZxdW90O3NlbGYgZGVwbG95JnF1b3Q7LiBJbnN0ZWFkLCBh bGwgb2YgdGhlIE9TUEYgZGVwbG95bWVudHMgdGhhdCBJIGFtPC9zcGFuPjwvcD4KPHAgc3R5bGU9 IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFy Z2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11 c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGZhbWlsaWFy IHdpdGggaGFkIGVuZ2luZWVycyBtYWtpbmcgZGVsaWJlcmF0ZSBkZWNpc2lvbnMgYWJvdXQgaG93 PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7 IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0 ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6 ZTo4cHQ7Ij4mZ3Q7IHRvIGNvbmZpZ3VyZSB0aGUgT1NQRiBkZXBsb3ltZW50LCBhbmQgYWxzbyBo b3cgdG8gY29uZmlndXJlIHRoZTwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7 IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1x dC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNw YW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBPU1BGIHJvdXRlcnMgaW4gdGhhdCBkZXBs b3ltZW50Ljwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0 b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRl bnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBm b250LXNpemU6OHB0OyI+SSBrbm93IHRoYXQgc3VjaCBkZXBsb3ltZW50cyBhcmUgbm9ybWFsbHkg d2VsbCBwbGFubmVkLCBidXQgYXMgdGhlcmUgaXMgYWxyZWFkeSBhIGRyYWZ0IGFib3V0IG9zcGZ2 MyBhdXRvY29uZmlnLCBldmVuIGlmIGl0IGlzIG5vdCBkZXNpZ25lZCB0byBiZSB1c2VkIGluIGNv bXBhbnkgbmV0d29ya3MuPC9zcGFuPjwvcD4KPHAgc3R5bGU9Ii1xdC1wYXJhZ3JhcGgtdHlwZTpl bXB0eTsgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDowcHg7 IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAi PiZuYnNwOzwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7 IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0 ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6 ZTo4cHQ7Ij4mZ3Q7IE9uZSBkZXBsb3ltZW50IG9wdGlvbiwgYWxyZWFkeSBkZXBsb3llZCBpbiBz b21lIHBsYWNlcywgaXMgdG8gcnVuPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBw eDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsg LXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48 c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7ICZxdW90O3NoaXBzIGluIHRoZSBuaWdo dCZxdW90Oy4gSW4gdGhpcyBtb2RlbCwgdGhlIElQdjQgdG9wb2xvZ3kgZXhjbHVzaXZlbHk8L3Nw YW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFy Z2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQt aW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhw dDsiPiZndDsgdXNlcyBPU1BGdjIgb3ZlciBJUHY0IGFuZCB0aGUgSVB2NiB0b3BvbG9neSBleGNs dXNpdmVseSB1c2VzIE9TUEZ2Mzwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7 IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1x dC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNw YW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBvdmVyIElQdjYuIEZvciBzb21lIHNpdGVz LCB0aGF0IGlzIGEgZ29vZCBvcHRpb24uIEEgbnVtYmVyIG9mIG15PC9zcGFuPjwvcD4KPHAgc3R5 bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsg bWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1x dC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGNsaWVu dHMgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiB0aGlzIG5ldyBJLUQgYmVjYXVzZSBpdCBvcHRpbWlz ZXM8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBw eDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7 IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1z aXplOjhwdDsiPiZndDsgdGhlaXIgSVB2NiB0cmFuc2l0aW9uIHN0cmF0ZWd5Ljwvc3Bhbj48L3A+ CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVm dDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6 MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0 OyA8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBw eDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7 IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1z aXplOjhwdDsiPiZndDsgRm9yIHNvbWUgc2l0ZXMsIElQdjYgdHJhbnNpdGlvbiBpcyBzaW1wbGlm aWVkLCBvcHRpbWlzZWQsIGFuZCBhbHNvPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9w OjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBw eDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7 Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGNvc3QtcmVkdWNlZCBieSB1c2lu ZyBPU1BGdjMgb3ZlciBJUHY0IGluaXRpYWxseSwgYW5kIGNhcnJ5aW5nIGJvdGg8L3NwYW4+PC9w Pgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxl ZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50 OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZn dDsgSVB2NCBwcmVmaXhlcyBhbmQgSVB2NiBwcmVmaXhlcyBpbnNpZGUgdGhhdCBvbmUgT1NQRnYz IGRlcGxveW1lbnQ8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4t Ym90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2st aW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxl PSIgZm9udC1zaXplOjhwdDsiPiZndDsgKGkuZS4gdXNpbmcgdGhlIEFkZHJlc3MgRmFtaWx5IGV4 dGVuc2lvbiB0byBrZWVwIHRoZSBwcmVmaXhlcyBjbGVhcmx5PC9zcGFuPjwvcD4KPHAgc3R5bGU9 IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFy Z2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11 c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGRpZmZlcmVu dGlhdGVkIHdpdGhpbiBhIHNpbmdsZSBPU1BGdjMgZGVwbG95bWVudCkuIFRoaXMgY2FuIGxvd2Vy PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7 IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0 ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6 ZTo4cHQ7Ij4mZ3Q7IG9wZXJhdGlvbmFsIGNvc3RzIGJlY2F1c2Ugb25lIGNhbiBnZXQgYnkgd2l0 aCBtYW5hZ2luZyBvbmx5IE9TUEZ2Myw8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6 MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4 OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsi PjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgcmF0aGVyIHRoYW4gaGF2aW5nIHRv IG1hbmFnZSBib3RoIE9TUEZ2MiBhbmQgT1NQRnYzLjwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFy Z2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1y aWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1z dGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyA8L3NwYW4+PC9wPgo8 cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6 NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBw eDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsg SWYgb25lJ3MgJnF1b3Q7SVB2NiBpc2xhbmRzJnF1b3Q7ICh0byB1c2UgeW91ciB0ZXJtKSBhcmUg cmVhbGx5IGR1YWwtc3RhY2s8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBt YXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQt YmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFu IHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgKGFzaWRlOiBoYXZpbmcgZHVhbC1zdGFjayBy YXRoZXIgdGhhbiBJUHY2LW9ubHkgd291bGQgYmUgZXhwZWN0ZWQ8L3NwYW4+PC9wPgo8cCBzdHls ZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBt YXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0 LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgYW5kIG5v cm1hbCBpZiBhbm90aGVyIHBhcnQgb2Ygb25lJ3MgT1NQRiBkZXBsb3ltZW50IGlzIHVzaW5nPC9z cGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1h cmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0 LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4 cHQ7Ij4mZ3Q7IE9TUEYgb3ZlciBJUHY0KSwgdGhlbiBFSVRIRVIgdGhlIHdob2xlIGRlcGxveW1l bnQgc2hvdWxkIGJlIGNvbmZpZ3VyZWQ8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6 MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4 OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsi PjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgdG8gcnVuIG92ZXIgSVB2NCBYT1Ig dGhlIHdob2xlIGRlcGxveW1lbnQgc2hvdWxkIGJlIGNvbmZpZ3VyZWQ8L3NwYW4+PC9wPgo8cCBz dHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4 OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsg LXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgdG8g cnVuIG92ZXIgSVB2Ni48L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJn aW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxv Y2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0 eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4t dG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0 OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRl OjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IEhhdmluZyBkaWZmZXJlbnQg JnF1b3Q7SVB2NCBpc2xhbmRzJnF1b3Q7IGFuZCAmcXVvdDtJUHY2IGlzbGFuZHMmcXVvdDsgaXMg YW4gZXhwbGljaXQgY2hvaWNlPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsg bWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0 LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3Bh biBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IG9mIGEgY29uZmlndXJhdGlvbiBlbmdpbmVl ciBvciBkZXNpZ24gZW5naW5lZXIuIFRoYXQgcHJvYmFibHkgaXMgbm90PC9zcGFuPjwvcD4KPHAg c3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVw eDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7 IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IHRo ZSBvcHRpbWFsIGRlcGxveW1lbnQgY2hvaWNlIGZvciBhbiBlbmdpbmVlciB0byBtYWtlLiBJdCBk ZWZpbml0ZWx5PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJv dHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWlu ZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0i IGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGlzIE5PVCBhIGNob2ljZSB0aGF0IEkgd291bGQgbWFrZSBv ciB0aGF0IEkgd291bGQgcmVjb21tZW5kIHRvIG15IGNsaWVudHMuPC9zcGFuPjwvcD4KPHAgc3R5 bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsg bWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1x dC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij5JIHdvdWxkIG5v dCBkbyBpdCBlaXRoZXIsIGJ1dCBJIGhhdmUgYWxyZWFkeSBzZWVuIHNvbWUgc3RyYW5nZSBvc3Bm IGRlc2lnbnMuLi4sIGFuZCBhcyBtZW50aW9uZWQgaXQgaXMgYSBjYXNlIHdoaWNoIGNhbiBoYXBw ZW4gd2l0aCBvc3BmIGF1dG9jb25maWd1cmF0aW9uLCBidXQgd2UgZG9uJ3QgbmVlZCB0byBkaXNj dXNzIGl0IGZ1cnRoZXIgYXMgaXQgaXMgZm9yIGhvbWVuZXR3b3Jrczwvc3Bhbj48L3A+CjxwIHN0 eWxlPSItcXQtcGFyYWdyYXBoLXR5cGU6ZW1wdHk7IG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90 dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5k ZW50OjA7IHRleHQtaW5kZW50OjBweDsgIj4mbmJzcDs8L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRv cDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDow cHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTow OyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBGcm9tIHRoZSBkZXNjcmlwdGlv bnMgYW5kIGRlZmluaXRpb25zIGluIHRoZSBkcmFmdCwgaXQgd291bGQgbm90IGJlPC9zcGFuPjwv cD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1s ZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVu dDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4m Z3Q7ICZxdW90O25vcm1hbCZxdW90OyBvciAmcXVvdDtleHBlY3RlZCZxdW90OyB0byBtaXggSVB2 NiB0cmFuc3BvcnQgd2l0aCBJUHY0IHRyYW5zcG9ydDwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFy Z2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1y aWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1z dGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyB3aXRoaW4gYSBzaW5n bGUgT1NQRnYzIGRlcGxveW1lbnQuPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBw eDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsg LXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48 c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48L3A+CjxwIHN0eWxlPSIg bWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdp bi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNl ci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyAmZ3Q7IElzIHRo ZXJlIGFueSBleHBsaWNpdCBwcmVmZXJlbmNlIG92ZXIgd2hpY2ggdmVyc2lvbiB0aGUgYWRqYWNl bmN5PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTow cHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDow OyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQt c2l6ZTo4cHQ7Ij4mZ3Q7ICZndDsgaXMgYnVpbGQgaWYgdjQgYW5kIHY2IGlzIGF2YWlsYWJsZSBp biB0aGF0IHNwZWNpZmljIHBhcnQgb2YgdGhlIG5ldHdvcms/PC9zcGFuPjwvcD4KPHAgc3R5bGU9 IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFy Z2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11 c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48 L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4t bGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRl bnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+ Jmd0OyBUaGUgY2hvaWNlIG9mIHByZWZlcnJlZCBPU1BGIHRyYW5zcG9ydCByZWFsbHkgaXMgc29t ZXRoaW5nIHRoYXQgdGhlPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFy Z2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJs b2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBz dHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGNvbmZpZ3VyYXRpb24gZW5naW5lZXIgb3VnaHQg dG8gY29uZmlndXJlLiBBcyB0aGUgZGV0YWlscyBvZiBjb25maWd1cmluZzwvc3Bhbj48L3A+Cjxw IHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1 cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4 OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBh bnkgSVAgcm91dGVyIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgSUVURiwgSSBhbSBub3Qg c3VyZSB0aGF0PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJv dHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWlu ZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0i IGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IHRoaXMgSS1EIHByb3Blcmx5IGNhbiBvciBzaG91bGQgc2F5 IHZlcnkgbW9yZSB0aGFuIGl0IGFscmVhZHkgc2F5cy48L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1h cmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4t cmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXIt c3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPiZndDsgPC9zcGFuPjwvcD4K PHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0 OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDow cHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7 IFBlcmhhcHMgdGhlIEktRCBjb3VsZCBhZGQgY2xhcmlmeWluZyB0ZXh0IGFsb25nIHRoZXNlIGxp bmVzPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTow cHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDow OyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQt c2l6ZTo4cHQ7Ij4mZ3Q7IHNvbWV3aGVyZSBpbiBTZWN0aW9uIDI6PC9zcGFuPjwvcD4KPHAgc3R5 bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsg bWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1x dC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bh bj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJn aW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1p bmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0 OyI+Jmd0OyAmcXVvdDtJbXBsZW1lbnRlcnMgb2YgT1NQRnYzIG92ZXIgSVB2NCBTSE9VTEQgYWRk IGEgY29uZmlndXJhdGlvbjwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1h cmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1i bG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4g c3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBrbm9iIHRvIGxldCB0aGUgcm91dGVyIGFkbWlu aXN0cmF0b3Igc2VsZWN0IHdoZXRoZXIgYSBnaXZlbjwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFy Z2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1y aWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1z dGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBPU1BGdjMtZW5hYmxl ZCBpbnRlcmZhY2Ugc2hvdWxkIHVzZSBPU1BGdjMgb3ZlciBJUHY0IG9yPC9zcGFuPjwvcD4KPHAg c3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVw eDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7 IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IE9T UEZ2MyBvdmVyIElQdjYuIEV4Y2VwdCB3aGVuIGFuIE9TUEZ2MyBkZXBsb3ltZW50IGlzIGJlaW5n PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7 IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0 ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6 ZTo4cHQ7Ij4mZ3Q7IHRyYW5zaXRpb25lZCBmcm9tIHVzaW5nIElQdjQgdHJhbnNtaXNzaW9uIHRv IHVzaW5nIElQdjY8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4t Ym90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2st aW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxl PSIgZm9udC1zaXplOjhwdDsiPiZndDsgdHJhbnNtaXNzaW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0 aGF0IGFsbCByb3V0ZXJzIHdpdGhpbiBhbjwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRv cDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDow cHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTow OyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBPU1BGdjMgZGVwbG95bWVudCB1 c2UgdGhlIHNhbWUgSVAgdmVyc2lvbiBmb3IgT1NQRnYzIHBhY2tldDwvc3Bhbj48L3A+CjxwIHN0 eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7 IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAt cXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyB0cmFu c21pc3Npb24uJnF1b3Q7PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFy Z2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJs b2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBz dHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2lu LXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdo dDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0 ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyAmZ3Q7IFdoYXQgc2hvdWxk IGhhcHBlbiB3aGVuIGFuIElQdjQgTGluayBnZXRzIHY2IGFkZGVkLCBncmFjZWZ1bCByZWVzdGFi bGlzaDwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206 MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6 MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250 LXNpemU6OHB0OyI+Jmd0OyAmZ3Q7IHRoZSBhZGphY2VuY3kgb3ZlciBJUHY2LCBvciB3YWl0IHVu dGlsIGZvcmNlZCBwcm90b2NvbCBzd2l0Y2g/PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4t dG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0 OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRl OjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48L3A+CjxwIHN0 eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7 IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAt cXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBTZWUg bXkgYW5zd2VyIGp1c3QgYWJvdmUuPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBw eDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsg LXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48 c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48L3A+CjxwIHN0eWxlPSIg bWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdp bi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNl ci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBJIHdvdWxkIGV4 cGVjdCB0aGF0IGFueSByb3V0ZXIgdGhhdCBpbXBsZW1lbnRzIHRoaXMgSS1EIGFsc28gd291bGQg aW1wbGVtZW50PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsgbWFyZ2luLWJv dHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJsb2NrLWlu ZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0i IGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGEgY29uZmlndXJhdGlvbiBrbm9iIHRvIGluZGljYXRlIHdo ZXRoZXIgSVB2NCB0cmFuc21pc3Npb24gb3IgSVB2Njwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFy Z2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1y aWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1z dGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyB0cmFuc21pc3Npb24g aXMgcHJlZmVycmVkLiBPdmVyIHRpbWUsIGEgY29uZmlndXJhdGlvbiBlbmdpbmVlciBtaWdodDwv c3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBt YXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4 dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6 OHB0OyI+Jmd0OyBjaGFuZ2UgdGhpcyAoZS5nLiBtYW51YWxseSBjaGFuZ2UgZnJvbSBJUHY0IHRy YW5zbWlzc2lvbiB0byBJUHY2PC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBweDsg bWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0 LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48c3Bh biBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IHRyYW5zbWlzc2lvbiBBRlRFUiBhbiBlbnRp cmUgSVB2NCBuZXR3b3JrIGhhcyBiZWVuPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9w OjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBw eDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7 Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IGRlcGxveWVkLXdpdGgvY29udmVy dGVkLXRvIGR1YWwtc3RhY2sgSVB2NCBhbmQgSVB2NikuPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBt YXJnaW4tdG9wOjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2lu LXJpZ2h0OjBweDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2Vy LXN0YXRlOjA7Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48L3A+ CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVm dDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6 MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0 OyBZb3Vycyw8L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90 dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5k ZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIg Zm9udC1zaXplOjhwdDsiPiZndDsgPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9wOjBw eDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBweDsg LXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7Ij48 c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IFJhbiBBdGtpbnNvbjwvc3Bhbj48L3A+ CjxwIHN0eWxlPSItcXQtcGFyYWdyYXBoLXR5cGU6ZW1wdHk7IG1hcmdpbi10b3A6MHB4OyBtYXJn aW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6MHB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxv Y2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgIj4mbmJzcDs8L3A+CjxwIHN0eWxlPSIgbWFy Z2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1y aWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1z dGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+VGhhbmtzIGZvciB0aGUgZGV0 YWlsZWQgYW53c2VycywgSSdtIHNhdGlzZmllZCB3aXRoIHRoZSBhZGRpdGlvbi48L3NwYW4+PC9w Pgo8cCBzdHlsZT0iLXF0LXBhcmFncmFwaC10eXBlOmVtcHR5OyBtYXJnaW4tdG9wOjBweDsgbWFy Z2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjBweDsgbWFyZ2luLXJpZ2h0OjBweDsgLXF0LWJs b2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7ICI+Jm5ic3A7PC9wPgo8cCBzdHlsZT0iIG1h cmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4t cmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXIt c3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsiPktpbmQgcmVnYXJkcyw8L3Nw YW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4tYm90dG9tOjBweDsgbWFy Z2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2staW5kZW50OjA7IHRleHQt aW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhw dDsiPkthcnN0ZW48L3NwYW4+PC9wPgo8cCBzdHlsZT0iIG1hcmdpbi10b3A6MHB4OyBtYXJnaW4t Ym90dG9tOjBweDsgbWFyZ2luLWxlZnQ6NXB4OyBtYXJnaW4tcmlnaHQ6MHB4OyAtcXQtYmxvY2st aW5kZW50OjA7IHRleHQtaW5kZW50OjBweDsgLXF0LXVzZXItc3RhdGU6MDsiPjxzcGFuIHN0eWxl PSIgZm9udC1zaXplOjhwdDsiPiZndDsgPC9zcGFuPjwvcD4KPHAgc3R5bGU9IiBtYXJnaW4tdG9w OjBweDsgbWFyZ2luLWJvdHRvbTowcHg7IG1hcmdpbi1sZWZ0OjVweDsgbWFyZ2luLXJpZ2h0OjBw eDsgLXF0LWJsb2NrLWluZGVudDowOyB0ZXh0LWluZGVudDowcHg7IC1xdC11c2VyLXN0YXRlOjA7 Ij48c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7Ij4mZ3Q7IDwvc3Bhbj48L3A+CjxwIHN0eWxl PSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1h cmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQt dXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3A+CjxwIHN0 eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7 IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAt cXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyBPU1BG IG1haWxpbmcgbGlzdDwvc3Bhbj48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdp bi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9j ay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5 bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9TUEZAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSIgZm9udC1zaXplOjhwdDsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IGNvbG9yOiMwMDAwZmY7Ij5PU1BGQGlldGYub3JnPC9zcGFuPjwvYT48L3A+CjxwIHN0 eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206MHB4OyBtYXJnaW4tbGVmdDo1cHg7 IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6MDsgdGV4dC1pbmRlbnQ6MHB4OyAt cXQtdXNlci1zdGF0ZTowOyI+PHNwYW4gc3R5bGU9IiBmb250LXNpemU6OHB0OyI+Jmd0OyA8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmIj48 c3BhbiBzdHlsZT0iIGZvbnQtc2l6ZTo4cHQ7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBj b2xvcjojMDAwMGZmOyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3Bm PC9zcGFuPjwvYT48L3A+CjxwIHN0eWxlPSIgbWFyZ2luLXRvcDowcHg7IG1hcmdpbi1ib3R0b206 MHB4OyBtYXJnaW4tbGVmdDowcHg7IG1hcmdpbi1yaWdodDowcHg7IC1xdC1ibG9jay1pbmRlbnQ6 MDsgdGV4dC1pbmRlbnQ6MHB4OyAtcXQtdXNlci1zdGF0ZTowOyI+PGJyIC8+PGJyIC8+PC9wPjwv Ym9keT48L2h0bWw+ --nextPart7963050.SuCmYsIaIu-- From nobody Wed Feb 26 12:58:37 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027221A06E5 for ; Wed, 26 Feb 2014 12:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 8BEqxIPb9Mx4 for ; Wed, 26 Feb 2014 12:58:27 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2F31A02A9 for ; Wed, 26 Feb 2014 12:58:27 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-e7-530e556d2389 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1A.13.12743.D655E035; Wed, 26 Feb 2014 21:58:21 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 15:58:24 -0500 From: Acee Lindem To: OSPF List Thread-Topic: Routing ADs for OSPF WG Thread-Index: AQHPMzV9NB4K0B4vO0WIReDMz+/XzA== Date: Wed, 26 Feb 2014 20:58:23 +0000 Message-ID: <65C91276-FFDE-4BD3-B270-CACEFF802AB3@ericsson.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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPgm5uKF+wwarDhhZfr6VZtNy7x25x 7ukcRgdmjym/N7J6LFnyk8njetNV9gDmKC6blNSczLLUIn27BK6MOzO6WQsOs1ZcvbWWsYFx E0sXIyeHhICJxL6Tt9kgbDGJC/fWg9lCAkcYJTYcruhi5AKylzNKnDqzgQkkwSagI/H80T9m EFtEQFZi6ZL9rF2MHBzMAp4SSxvLQcLCAooSt468Z4coUZO4tHc5K4StJ7Gi8xbYfBYBVYnd P/qZQFp5Bewlfs7lBQkzAp3w/dQasE3MAuISt57MZ4I4TUBiyZ7zzBC2qMTLx/9YIWwliUlL z7FC1BtIvD83nxniGmuJntt6EGFtiWULX4O18goISpyc+YRlAqPoLCQbZiHpnoXQPQtJ9ywk 3QsYWVcxcpQWp5blphsZbGIExssxCTbdHYx7XloeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA6P6rvMRW5YWnrY02cDWfMGn6FyONXvGv8lvO27JGTYESDmZSl2qNJVj Dpoxsbaz99miCR8NkgryHjtHr+dazd2/RPFx95plJxhOK71YONEu7Mbds35h4bJ2cm+uf163 7ev/5xoP3yt4XChhYGlT3NXF/mrfkUzXEOGstLajE3rTitIFHI6KhSixFGckGmoxFxUnAgBU EDxwZQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/To_onyC09_q-eZs5bmFlJKGsEM4 Cc: Alia Atlas Subject: [OSPF] Routing ADs for OSPF WG 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, 26 Feb 2014 20:58:29 -0000 We=92d like to take this opportunity to thank Steward Bryant for serving as= the Routing AD for the OSPF WG for these past 4 years. Stewart has been ve= ry supportive and helpful in getting our documents through the IESG reviews= (especially the documents pertaining to OSPF and OSPFv3 authentication).=20 We=92d also to like to welcome Alia Atlas in her new role as the Routing AD= specifically responsible for the OSPF WG. Alia is no stranger to OSPF as s= he has been a key player in IP FRR since the beginning (well, at least sinc= e it was taken seriously).=20 For those of you coming to London, I expect both Stewart and Alia will be a= t our meeting on Monday.=20 Abhay and Acee= From nobody Wed Feb 26 15:32:55 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B083E1A0792 for ; Wed, 26 Feb 2014 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 sd8uOr9yHw7T for ; Wed, 26 Feb 2014 15:32:41 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82AF61A06E8 for ; Wed, 26 Feb 2014 15:32:41 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-d9-530e7993fe6b Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E3.5A.12743.3997E035; Thu, 27 Feb 2014 00:32:35 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 18:32:38 -0500 From: Acee Lindem To: Karsten Thomann , "ospf@ietf.org" Thread-Topic: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt Thread-Index: AQHPLASQC4hPn9qVfUSdHygqv/z3N5q6NRiAgA3WoQA= Date: Wed, 26 Feb 2014 23:32:38 +0000 Message-ID: In-Reply-To: <4840600.E243vrriOs@linne> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_CF33B97127D16aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXSPt+7kSr5gg1tXNSy23DrKZNFy7x67 A5PHkiU/mTweHjzEHsAUxWWTkpqTWZZapG+XwJWx6f8zloKHq5kqbu5vZG5gXNfO1MXIySEh YCJxe9J8FghbTOLCvfVsXYxcHEICRxglbjd+ZoVwljNK3J8C0cEmoCPx/NE/ZhBbRCBIYtO3 I2DdwgL2Ep8XvGOFiDtI9Jx5BFVjJXH++3FGEJtFQFXi96HvYHFeAVOJvv0PgHo5ODgF1CWu LlMDCTMCHfH91BqwVcwC4hK3nsyHOlRAYsme88wQtqjEy8f/wFaJCuhJdM9azgoRV5KYtPQc K0RvlMTHPwcYIVYJSpyc+YRlAqPILCRjZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZ IWxriRkXPjAiq1nAyLGKkaO0OLUsN93IYBMjMLKOSbDp7mDc89LyEKM0B4uSOO+Xt85BQgLp iSWp2ampBalF8UWlOanFhxiZODilGhh7J/66s3D1yk2WT5iTV10q3LSm0O7s/U39XwxWSj5o XhEkyctvbSf02DXm+NzsyJVr57QZWclF6b304BRd8en8jhuHREQenOdx/VL/V0qH8aDPLNfV C3QqNi3f8C5kpZV78pv1flo8vg26V375fxJm+RD9JYFTxn6PbHCbccL9mzIlXM/KfNcosRRn JBpqMRcVJwIAVCrFGHoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/vn5aX_eSIFxNrfxicakRtTRmvwY Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 23:32:47 -0000 --_000_CF33B97127D16aceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Karsten =96 we will include all these editorial changes in the next = revision. Acee From: Karsten Thomann > Date: Monday, February 17, 2014 12:13 PM To: Ericsson >, O= SPF - OSPF WG List > Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt Hi Acee, found some nits to resolve in the next draft. 1. Introduction s/to to/to 2. Encapsulation in IPv4 First sentence of the second passage s/by a OSPF/by an OSPF 3. Security Considerations In the second passage is a little typo it should be RFC6506 instead of 6505 5.2 Informative References Headline is right for RFC 6506 and is correct after the headline but listed= wrong as RFC6505. Kind regards, Karsten Am Montag, 17. Februar 2014, 17:20:33 schrieben Sie: Hi Karsten, We wil add Ran's suggested text to the next revision. Thanks, Acee From: Karsten Thomann > Date: Saturday, February 15, 2014 4:22 AM To: OSPF - OSPF WG List > Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt Am Montag, 10. Februar 2014, 14:33:05 schrieb RJ Atkinson: > Earlier, Karsten Thomann wrote, in part: > > I don't know if i have missed that part, but what would happen if OSPFv= 3 > > is running over IPv4 and there are two (or more) IPv6 Islands already > > deployed within the network, should there be any LSA flooding checks, > > like do not flood LSA with IPv6 networks over IPv4 only links, or shoul= d > > the route > > calculation/installation of the information simply fail > > as there is no valid path? > > The OSPF deployments I am familiar with did not "auto deploy" > or "self deploy". Instead, all of the OSPF deployments that I am > familiar with had engineers making deliberate decisions about how > to configure the OSPF deployment, and also how to configure the > OSPF routers in that deployment. I know that such deployments are normally well planned, but as there is alr= eady a draft about ospfv3 autoconfig, even if it is not designed to be used= in company networks. > One deployment option, already deployed in some places, is to run > "ships in the night". In this model, the IPv4 topology exclusively > uses OSPFv2 over IPv4 and the IPv6 topology exclusively uses OSPFv3 > over IPv6. For some sites, that is a good option. A number of my > clients are very interested in this new I-D because it optimises > their IPv6 transition strategy. > > For some sites, IPv6 transition is simplified, optimised, and also > cost-reduced by using OSPFv3 over IPv4 initially, and carrying both > IPv4 prefixes and IPv6 prefixes inside that one OSPFv3 deployment > (i.e. using the Address Family extension to keep the prefixes clearly > differentiated within a single OSPFv3 deployment). This can lower > operational costs because one can get by with managing only OSPFv3, > rather than having to manage both OSPFv2 and OSPFv3. > > If one's "IPv6 islands" (to use your term) are really dual-stack > (aside: having dual-stack rather than IPv6-only would be expected > and normal if another part of one's OSPF deployment is using > OSPF over IPv4), then EITHER the whole deployment should be configured > to run over IPv4 XOR the whole deployment should be configured > to run over IPv6. > > Having different "IPv4 islands" and "IPv6 islands" is an explicit choice > of a configuration engineer or design engineer. That probably is not > the optimal deployment choice for an engineer to make. It definitely > is NOT a choice that I would make or that I would recommend to my clients= . I would not do it either, but I have already seen some strange ospf designs= ..., and as mentioned it is a case which can happen with ospf autoconfigura= tion, but we don't need to discuss it further as it is for homenetworks > From the descriptions and definitions in the draft, it would not be > "normal" or "expected" to mix IPv6 transport with IPv4 transport > within a single OSPFv3 deployment. > > > Is there any explicit preference over which version the adjacency > > is build if v4 and v6 is available in that specific part of the network= ? > > The choice of preferred OSPF transport really is something that the > configuration engineer ought to configure. As the details of configuring > any IP router are outside the scope of the IETF, I am not sure that > this I-D properly can or should say very more than it already says. > > Perhaps the I-D could add clarifying text along these lines > somewhere in Section 2: > > "Implementers of OSPFv3 over IPv4 SHOULD add a configuration > knob to let the router administrator select whether a given > OSPFv3-enabled interface should use OSPFv3 over IPv4 or > OSPFv3 over IPv6. Except when an OSPFv3 deployment is being > transitioned from using IPv4 transmission to using IPv6 > transmission, it is RECOMMENDED that all routers within an > OSPFv3 deployment use the same IP version for OSPFv3 packet > transmission." > > > What should happen when an IPv4 Link gets v6 added, graceful reestablis= h > > the adjacency over IPv6, or wait until forced protocol switch? > > See my answer just above. > > I would expect that any router that implements this I-D also would implem= ent > a configuration knob to indicate whether IPv4 transmission or IPv6 > transmission is preferred. Over time, a configuration engineer might > change this (e.g. manually change from IPv4 transmission to IPv6 > transmission AFTER an entire IPv4 network has been > deployed-with/converted-to dual-stack IPv4 and IPv6). > > Yours, > > Ran Atkinson Thanks for the detailed anwsers, I'm satisfied with the addition. Kind regards, Karsten > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --_000_CF33B97127D16aceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks Karsten =96 we will include all these editorial changes in the = next revision. 
Acee 

From: Karsten Thomann <karsten_thomann@linfre.de>
Date: Monday, February 17, 2014 12:= 13 PM
To: Ericsson <acee.lindem@ericsson.com>, OSPF - OSPF WG = List <ospf@ietf.org>
Subject: Re: [OSPF] draft-chen-ospf= -transition-to-ospfv3-00.txt

Hi Acee,

 

found some nits to resolve in the next draft.

1. Introduction

s/to to/to

 

2. Encapsulation in IPv4

First sentence of the second passage

s/by a OSPF/by an OSPF

 

3. Security Considerations

In the second passage is a little typo it should be RFC6506 instead of 6505=

 

5.2 Informative References

 

Headline is right for RFC 6506 and is correct after the headline but listed= wrong as RFC6505.

 

Kind regards,

Karsten

 

Am Montag, 17. Februar 2014, 17:20:33 schrieben Sie:

Hi Karsten, 

We wil add Ran's suggested text to the next revision.

Thanks,

Acee 


From: Karsten Thomann <= karsten_thomann@linfre.de>
Date: Saturday, February 15, 2014 4:22 AM
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] draft-chen-ospf-transition-to-ospfv3-00.txt


Am Montag, 10. Februar 2014,= 14:33:05 schrieb RJ Atkinson:

> Earlier, Karsten Thomann wrote, in par= t:

> > I don't know if i have missed tha= t part, but what would happen if OSPFv3

> > is running over IPv4 and there ar= e two (or more) IPv6 Islands already

> > deployed within the network, shou= ld there be any LSA flooding checks,

> > like do not flood LSA with IPv6 n= etworks over IPv4 only links, or should

> > the route

> > calculation/installation of the i= nformation simply fail

> > as there is no valid path?=

>

> The OSPF deployments I am familiar wit= h did not "auto deploy"

> or "self deploy". Instead, a= ll of the OSPF deployments that I am

> familiar with had engineers making del= iberate decisions about how

> to configure the OSPF deployment, and = also how to configure the

> OSPF routers in that deployment.

I know that such deployments are normally w= ell planned, but as there is already a draft about ospfv3 autoconfig, even = if it is not designed to be used in company networks.

 

> One deployment option, already deploye= d in some places, is to run

> "ships in the night". In thi= s model, the IPv4 topology exclusively

> uses OSPFv2 over IPv4 and the IPv6 top= ology exclusively uses OSPFv3

> over IPv6. For some sites, that is a g= ood option. A number of my

> clients are very interested in this ne= w I-D because it optimises

> their IPv6 transition strategy.=

>

> For some sites, IPv6 transition is sim= plified, optimised, and also

> cost-reduced by using OSPFv3 over IPv4= initially, and carrying both

> IPv4 prefixes and IPv6 prefixes inside= that one OSPFv3 deployment

> (i.e. using the Address Family extensi= on to keep the prefixes clearly

> differentiated within a single OSPFv3 = deployment). This can lower

> operational costs because one can get = by with managing only OSPFv3,

> rather than having to manage both OSPF= v2 and OSPFv3.

>

> If one's "IPv6 islands" (to = use your term) are really dual-stack

> (aside: having dual-stack rather than = IPv6-only would be expected

> and normal if another part of one's OS= PF deployment is using

> OSPF over IPv4), then EITHER the whole= deployment should be configured

> to run over IPv4 XOR the whole deploym= ent should be configured

> to run over IPv6.

>

> Having different "IPv4 islands&qu= ot; and "IPv6 islands" is an explicit choice

> of a configuration engineer or design = engineer. That probably is not

> the optimal deployment choice for an e= ngineer to make. It definitely

> is NOT a choice that I would make or t= hat I would recommend to my clients.

I would not do it either, but I have alread= y seen some strange ospf designs..., and as mentioned it is a case which ca= n happen with ospf autoconfiguration, but we don't need to discuss it furth= er as it is for homenetworks

 

> From the descriptions and definitions = in the draft, it would not be

> "normal" or "expected&q= uot; to mix IPv6 transport with IPv4 transport

> within a single OSPFv3 deployment.

>

> > Is there any explicit preference = over which version the adjacency

> > is build if v4 and v6 is availabl= e in that specific part of the network?

>

> The choice of preferred OSPF transport= really is something that the

> configuration engineer ought to config= ure. As the details of configuring

> any IP router are outside the scope of= the IETF, I am not sure that

> this I-D properly can or should say ve= ry more than it already says.

>

> Perhaps the I-D could add clarifying t= ext along these lines

> somewhere in Section 2:

>

> "Implementers of OSPFv3 over IPv4= SHOULD add a configuration

> knob to let the router administrator s= elect whether a given

> OSPFv3-enabled interface should use OS= PFv3 over IPv4 or

> OSPFv3 over IPv6. Except when an OSPFv= 3 deployment is being

> transitioned from using IPv4 transmiss= ion to using IPv6

> transmission, it is RECOMMENDED that a= ll routers within an

> OSPFv3 deployment use the same IP vers= ion for OSPFv3 packet

> transmission."

>

> > What should happen when an IPv4 L= ink gets v6 added, graceful reestablish

> > the adjacency over IPv6, or wait = until forced protocol switch?

>

> See my answer just above.

>

> I would expect that any router that im= plements this I-D also would implement

> a configuration knob to indicate wheth= er IPv4 transmission or IPv6

> transmission is preferred. Over time, = a configuration engineer might

> change this (e.g. manually change from= IPv4 transmission to IPv6

> transmission AFTER an entire IPv4 netw= ork has been

> deployed-with/converted-to dual-stack = IPv4 and IPv6).

>

> Yours,

>

> Ran Atkinson

 

Thanks for the detailed anwsers, I'm satisf= ied with the addition.

 

Kind regards,

Karsten

>

>

> ______________________________________= _________

> OSPF mailing list

> > https://www.ietf.org/mailman/listinfo/ospf



 --_000_CF33B97127D16aceelindemericssoncom_-- From nobody Thu Feb 27 11:26:08 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 5CE8A1A01A8; Thu, 27 Feb 2014 11:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRQ-_OdAEDTM; Thu, 27 Feb 2014 11:26:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id C41511A0126; Thu, 27 Feb 2014 11:26:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2C2767FC3AE; Thu, 27 Feb 2014 11:25:54 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140227192601.2C2767FC3AE@rfc-editor.org> Date: Thu, 27 Feb 2014 11:25:54 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ET1fhveBSLISWiPotv6bqZD-Fl8 Cc: drafts-update-ref@iana.org, ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 7137 on Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks 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, 27 Feb 2014 19:26:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7137 Title: Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks Author: A. Retana, S. Ratliff Status: Experimental Stream: IETF Date: February 2014 Mailbox: aretana@cisco.com, sratliff@cisco.com Pages: 8 Characters: 16017 Updates: RFC5820 I-D Tag: draft-ietf-ospf-manet-single-hop-or-04.txt URL: http://www.rfc-editor.org/rfc/rfc7137.txt This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature. This document updates RFC 5820. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC