From nobody Thu Dec 3 06:27:42 2015 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE1F1A88C6; Thu, 3 Dec 2015 06:27:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203142741.22934.31401.idtracker@ietfa.amsl.com> Date: Thu, 03 Dec 2015 06:27:41 -0800 Archived-At: Cc: draft-ietf-ospf-node-admin-tag@ietf.org, ospf@ietf.org, The IESG , ospf-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] Protocol Action: 'Advertising per-node administrative tags in OSPF' to Proposed Standard (draft-ietf-ospf-node-admin-tag-09.txt) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 14:27:41 -0000 The IESG has approved the following document: - 'Advertising per-node administrative tags in OSPF' (draft-ietf-ospf-node-admin-tag-09.txt) as Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/ Technical Summary This document specifies extensions to OSPF Router Informational (RI) to advertise multiple 32-bit admin tags. These tags can be then used for policy decisions in OSPF routers in the OSPF routing domain. While the tag applications are enumerated, they are not formally specified. Working Group Summary Initially, there was a concern with the number of tags being unbounded and the size of the OSPF RI LSA being finite. However, RFC 4970 has updated (publication requested) to allow an OSPF Router to advertise multiple instances of the OSPF RI LSA. During WG last call, it was noted that the behavior must be specified when there are multiple instances of the Admin Tag TLV. Document Quality This document has been a WG document for about a year and has been stable other than addressing minor comments. Personnel Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. From nobody Fri Dec 4 09:33:00 2015 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 238F71A8F3B for ; Fri, 4 Dec 2015 09:32:59 -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, HTML_MESSAGE=0.001, 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 FQsZlmAtz-ik for ; Fri, 4 Dec 2015 09:32:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12811A8BC0 for ; Fri, 4 Dec 2015 09:32:55 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by DM2PR05MB624.namprd05.prod.outlook.com (10.141.157.27) with Microsoft SMTP Server (TLS) id 15.1.331.20; Fri, 4 Dec 2015 17:32:35 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0331.023; Fri, 4 Dec 2015 17:32:35 +0000 From: Chris Bowers To: OSPF WG List Thread-Topic: proposed text for draft-ppsenak-ospf-te-link-attr-reuse Thread-Index: AdEuuVWGMPE2YtM+Qkqm7ANnmAmrvw== Date: Fri, 4 Dec 2015 17:32:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; DM2PR05MB624; 5:i5UgnP9rA4x0dzH5j7RvU55UIjKQt4a0u5Sspv3fk8SL5eMrCtU5R23h2MWpZKOHaTtatwEJJvm5aQDI5UBarfOnC2eghRNW6CKaFJA4oZgS+78aqYkiCZWX2HDzlakYJZfml5u/M5MwG7LwuViTuA==; 24:Dlpk+r0ZrBDKDR0ChJG/u0YEvQLds4FXjCDbdttgZ8vmKp45ljGiS3ZA7zB3BfpmnfFedop3suaotAj0OT6lYrP42v+dusKPlQD3QtJ6fGg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:DM2PR05MB624; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB624; x-forefront-prvs: 07807C55DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(66066001)(6116002)(586003)(102836003)(11100500001)(122556002)(10400500002)(5008740100001)(1220700001)(106356001)(450100001)(1096002)(3846002)(5004730100002)(76576001)(40100003)(97736004)(110136002)(74316001)(230783001)(5001960100002)(50986999)(5003600100002)(107886002)(81156007)(189998001)(5002640100001)(87936001)(86362001)(101416001)(105586002)(92566002)(19580395003)(99286002)(15975445007)(77096005)(2900100001)(33656002)(54356999)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB624; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR05MB62385A916E792E20E1EB583A90C0DM2PR05MB623namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2015 17:32:34.6065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB624 Archived-At: Subject: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 17:32:59 -0000 --_000_DM2PR05MB62385A916E792E20E1EB583A90C0DM2PR05MB623namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft authors, I would like to suggest the following text for the Backwards Compatibility = section of this document. ------- Some deployments of LFA and remote LFA currently rely on link attributes (s= uch as SRLG and admin groups) being carried in the TE Opaque LSA. These ap= plications are described in RFC 5286, RFC 7490, draft-ietf-rtgwg-lfa-manag= eability, and draft-psarkar-rtgwg-rlfa-node-protection. When a network is = using an application that relies on link attributes being carried in the TE= Opaque LSA , care should be taken to continue to advertise the appropriate= link attributes in the TE Opaque LSA. Note that a node that does not directly participate in remote LFA by origin= ating repair tunnels itself may still need to continue originating link att= ributes in the TE Opaque LSA for use by other nodes in the network. There= fore, when evaluating software upgrades or configuration changes which may = result in changes to which link attributes are being advertised in the TE O= paque LSA, even for a subset of routers in the network, care should be tak= en to evaluate the impact of that change across the entire network. ------- Thanks, Chris --_000_DM2PR05MB62385A916E792E20E1EB583A90C0DM2PR05MB623namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Draft authors,
 
I would like to suggest the following text for the Backwards Compatibi= lity section of this document.
 
-------
Some deployments of LFA and remote LFA currently rely on link attribut= es (such as SRLG and admin groups) being carried in the TE Opaque LSA. = ; These applications are described in RFC 5286, RFC 7490,  draft-ietf-= rtgwg-lfa-manageability, and draft-psarkar-rtgwg-rlfa-node-protection. = ; When a network is using an application that relies on link attributes being= carried in the TE Opaque LSA , care should be taken to continue to adverti= se the appropriate link attributes in the TE Opaque LSA.
 
Note that a node that does not directly participate in remote LFA by o= riginating repair tunnels itself may still need to continue originating lin= k attributes in the TE Opaque LSA for use by other nodes in the network.&nb= sp;  Therefore, when evaluating software upgrades or configuration changes which may result in changes to which link= attributes are being advertised in the TE Opaque LSA, even for a subset of= routers in the network,  care should be taken to evaluate the impact = of that change across the entire network.
-------
 
Thanks,
Chris
 
 
 --_000_DM2PR05MB62385A916E792E20E1EB583A90C0DM2PR05MB623namprd_-- From nobody Fri Dec 4 13:31:36 2015 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 1E4F11A90E1 for ; Fri, 4 Dec 2015 13:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mhJlwR_p-_vc for ; Fri, 4 Dec 2015 13:31:27 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B2E1A90E0 for ; Fri, 4 Dec 2015 13:31:27 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-22-566205f50302 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F6.1E.06940.5F502665; Fri, 4 Dec 2015 22:30:29 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 16:31:25 -0500 From: Jeff Tantsura To: Chris Bowers Thread-Topic: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse Thread-Index: AQHRLtsgURFEVpb9Tke8VfuIrKZfDQ== Date: Fri, 4 Dec 2015 21:31:24 +0000 Message-ID: <9908429A-3B31-4E44-8B24-6EDE883C051A@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9908429A3B314E448B246EDE883C051Aericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLrHW/cra1KYQc83U4sf610tWu7dY3dg 8liy5CeTx/Wmq+wBTFFcNimpOZllqUX6dglcGY9e3WYsWKBWsfvWfPYGxsMKXYycHBICJhJt My6wQthiEhfurWfrYuTiEBI4wihx8fBFRghnGaPEt/Vd7CBVbAIGEv+/HWcBsUUE1CT2X25l BrGZBRQkrl28xQZiCwt4Syw/3soIUeMj8fLyJiYIW0/i5LcmMJtFQEXi1pHjYDN5BewlJjTP BosLCURJ7Np+HWw+p0C0ROO+dWBzGIGu+35qDRPELnGJW0/mM0FcLSCxZM95ZghbVOLl43+s EDXJEs9/vWGFmC8ocXLmE5YJjCKzkLTPQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGL L2BkX8XIUVpckJObbmSwiREYPcck2HR3MN6f7nmIUYCDUYmHd8OjxDAh1sSy4srcQ4wSHMxK IrzMMkAh3pTEyqrUovz4otKc1OJDjNIcLErivIwMDAxCAumJJanZqakFqUUwWSYOTqkGRsaP vfz2HX624Srv07Osk095981b8dyiyZLlt/Ga849VWrgnHWdyuzBxYUGN1r1NrUpnHy6Wn391 xUS+tH8nlu6Pni8379xUmcs37zxleWxepHZ8d7bK5VW5gWkO+n/2Mgn0R7is13w/a2mm16GS uRMZqr/XR2zTfdVa4N5Xx+RrtPAfd8N3QyWW4oxEQy3mouJEAIbE3/+aAgAA Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 21:31:32 -0000 --_000_9908429A3B314E448B246EDE883C051Aericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, Thanks for your comments - sounds reasonable to me. With inclusion of your comments - would you be satisfied with the solution = proposed? Thanks and have a great weekend! Regards, Jeff On Dec 4, 2015, at 9:33 AM, Chris Bowers > wrote: Draft authors, I would like to suggest the following text for the Backwards Compatibility = section of this document. ------- Some deployments of LFA and remote LFA currently rely on link attributes (s= uch as SRLG and admin groups) being carried in the TE Opaque LSA. These ap= plications are described in RFC 5286, RFC 7490, draft-ietf-rtgwg-lfa-manag= eability, and draft-psarkar-rtgwg-rlfa-node-protection. When a network is = using an application that relies on link attributes being carried in the TE= Opaque LSA , care should be taken to continue to advertise the appropriate= link attributes in the TE Opaque LSA. Note that a node that does not directly participate in remote LFA by origin= ating repair tunnels itself may still need to continue originating link att= ributes in the TE Opaque LSA for use by other nodes in the network. There= fore, when evaluating software upgrades or configuration changes which may = result in changes to which link attributes are being advertised in the TE O= paque LSA, even for a subset of routers in the network, care should be tak= en to evaluate the impact of that change across the entire network. ------- Thanks, Chris _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_9908429A3B314E448B246EDE883C051Aericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Chris,

Thanks for your comments - sounds reasonable= to me.
With inclusion of your comments - would you = be satisfied with the solution proposed?

Thanks and have a great weekend!

Regards,
Jeff

On Dec 4, 2015, at 9:33 AM, Chris Bowers <cbowers@juniper.net> wrote:

Draft authors,
 
I would like to suggest the following text for the Backwards Compatibi= lity section of this document.
 
-------
Some deployments of LFA and remote LFA currently rely on link attribut= es (such as SRLG and admin groups) being carried in the TE Opaque LSA. = ; These applications are described in RFC 5286, RFC 7490,  draft-ietf-= rtgwg-lfa-manageability, and draft-psarkar-rtgwg-rlfa-node-protection. = ; When a network is using an application that relies on link attributes bein= g carried in the TE Opaque LSA , care should be taken to continue to advert= ise the appropriate link attributes in the TE Opaque LSA.
 
Note that a node that does not directly participate in remote LFA by o= riginating repair tunnels itself may still need to continue originating lin= k attributes in the TE Opaque LSA for use by other nodes in the network.&nb= sp;  Therefore, when evaluating software upgrades or configuration changes which may result in changes to which lin= k attributes are being advertised in the TE Opaque LSA, even for a subset o= f routers in the network,  care should be taken to evaluate the impact= of that change across the entire network.
-------
 
Thanks,
Chris
 
 
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ie= tf.org/mailman/listinfo/ospf
--_000_9908429A3B314E448B246EDE883C051Aericssoncom_-- From nobody Fri Dec 4 13:50:23 2015 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 1F0E11A9231 for ; Fri, 4 Dec 2015 13:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d1IxSrrHyaZ for ; Fri, 4 Dec 2015 13:50:20 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5741A9171 for ; Fri, 4 Dec 2015 13:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9133; q=dns/txt; s=iport; t=1449265820; x=1450475420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kElysnY5813xrnBtUeDoBG5bOdilXbqFf6ShEPPRS4s=; b=iKi0GZf1LTG+GqHXgY6rwAACeKJHNAXq8euksopR9ZtuSmd/+wGSYLvv QRFFCSSwMGtPW2QYTjUPnI5HO24ZWPe3yzHG6erWiHjnYNkGk96PBjETF OEjDkccCiywdKj58GUKJgsufBzIDUo0+5vMHnFryue69Cje9WOr9DcTW4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAoCWJW/51dJa1egm5MU24GvT8BD?= =?us-ascii?q?YFuFwEJgj2DMAIcgQ44FAEBAQEBAQGBCoQ0AQEBBAEBASAKOgcLEAIBCBEDAQI?= =?us-ascii?q?oAwICAiULFAkIAQEEAQ0FG4gUDa9GkGMBAQEBAQEBAQEBAQEBAQEBAQEBAQEUB?= =?us-ascii?q?ItRhEswDYJvgUQFlmEBjTuBW5cgg3EBHwEBQoQEcoQnQYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,382,1444694400"; d="scan'208,217";a="214859503" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Dec 2015 21:50:18 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tB4LoIrM031875 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 21:50:18 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Dec 2015 16:50:17 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 4 Dec 2015 16:50:17 -0500 From: "Acee Lindem (acee)" To: Jeff Tantsura , Chris Bowers Thread-Topic: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse Thread-Index: AdEuuVWGMPE2YtM+Qkqm7ANnmAmrvwAS7NMA//+xZoA= Date: Fri, 4 Dec 2015 21:50:17 +0000 Message-ID: References: <9908429A-3B31-4E44-8B24-6EDE883C051A@ericsson.com> In-Reply-To: <9908429A-3B31-4E44-8B24-6EDE883C051A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.199] Content-Type: multipart/alternative; boundary="_000_D2877495410E0aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 21:50:22 -0000 --_000_D2877495410E0aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmVmZiwgQ2hyaXMsDQoNClRoZXNlIGFkZGl0aW9ucyBsb29rIHJlYXNvbmFibGUgdG8gbWUgYXMg d2VsbC4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogT1NQRiA8b3NwZi1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmVmZiBUYW50c3Vy YSA8amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb208bWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nz b24uY29tPj4NCkRhdGU6IEZyaWRheSwgRGVjZW1iZXIgNCwgMjAxNSBhdCA0OjMxIFBNDQpUbzog Q2hyaXMgQm93ZXJzIDxjYm93ZXJzQGp1bmlwZXIubmV0PG1haWx0bzpjYm93ZXJzQGp1bmlwZXIu bmV0Pj4NCkNjOiBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9zcGZAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtPU1BGXSBwcm9wb3NlZCB0ZXh0IGZvciBkcmFmdC1wcHNlbmFr LW9zcGYtdGUtbGluay1hdHRyLXJldXNlDQoNCkhpIENocmlzLA0KDQpUaGFua3MgZm9yIHlvdXIg Y29tbWVudHMgLSBzb3VuZHMgcmVhc29uYWJsZSB0byBtZS4NCldpdGggaW5jbHVzaW9uIG9mIHlv dXIgY29tbWVudHMgLSB3b3VsZCB5b3UgYmUgc2F0aXNmaWVkIHdpdGggdGhlIHNvbHV0aW9uIHBy b3Bvc2VkPw0KDQpUaGFua3MgYW5kIGhhdmUgYSBncmVhdCB3ZWVrZW5kIQ0KDQpSZWdhcmRzLA0K SmVmZg0KDQpPbiBEZWMgNCwgMjAxNSwgYXQgOTozMyBBTSwgQ2hyaXMgQm93ZXJzIDxjYm93ZXJz QGp1bmlwZXIubmV0PG1haWx0bzpjYm93ZXJzQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQoNCkRyYWZ0 IGF1dGhvcnMsDQoNCkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgdGV4dCBm b3IgdGhlIEJhY2t3YXJkcyBDb21wYXRpYmlsaXR5IHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudC4N Cg0KLS0tLS0tLQ0KU29tZSBkZXBsb3ltZW50cyBvZiBMRkEgYW5kIHJlbW90ZSBMRkEgY3VycmVu dGx5IHJlbHkgb24gbGluayBhdHRyaWJ1dGVzIChzdWNoIGFzIFNSTEcgYW5kIGFkbWluIGdyb3Vw cykgYmVpbmcgY2FycmllZCBpbiB0aGUgVEUgT3BhcXVlIExTQS4gIFRoZXNlIGFwcGxpY2F0aW9u cyBhcmUgZGVzY3JpYmVkIGluIFJGQyA1Mjg2LCBSRkMgNzQ5MCwgIGRyYWZ0LWlldGYtcnRnd2ct bGZhLW1hbmFnZWFiaWxpdHksIGFuZCBkcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9kZS1wcm90 ZWN0aW9uLiAgV2hlbiBhIG5ldHdvcmsgaXMgdXNpbmcgYW4gYXBwbGljYXRpb24gdGhhdCByZWxp ZXMgb24gbGluayBhdHRyaWJ1dGVzIGJlaW5nIGNhcnJpZWQgaW4gdGhlIFRFIE9wYXF1ZSBMU0Eg LCBjYXJlIHNob3VsZCBiZSB0YWtlbiB0byBjb250aW51ZSB0byBhZHZlcnRpc2UgdGhlIGFwcHJv cHJpYXRlIGxpbmsgYXR0cmlidXRlcyBpbiB0aGUgVEUgT3BhcXVlIExTQS4NCg0KTm90ZSB0aGF0 IGEgbm9kZSB0aGF0IGRvZXMgbm90IGRpcmVjdGx5IHBhcnRpY2lwYXRlIGluIHJlbW90ZSBMRkEg Ynkgb3JpZ2luYXRpbmcgcmVwYWlyIHR1bm5lbHMgaXRzZWxmIG1heSBzdGlsbCBuZWVkIHRvIGNv bnRpbnVlIG9yaWdpbmF0aW5nIGxpbmsgYXR0cmlidXRlcyBpbiB0aGUgVEUgT3BhcXVlIExTQSBm b3IgdXNlIGJ5IG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrLiAgIFRoZXJlZm9yZSwgd2hlbiBl dmFsdWF0aW5nIHNvZnR3YXJlIHVwZ3JhZGVzIG9yIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyB3aGlj aCBtYXkgcmVzdWx0IGluIGNoYW5nZXMgdG8gd2hpY2ggbGluayBhdHRyaWJ1dGVzIGFyZSBiZWlu ZyBhZHZlcnRpc2VkIGluIHRoZSBURSBPcGFxdWUgTFNBLCBldmVuIGZvciBhIHN1YnNldCBvZiBy b3V0ZXJzIGluIHRoZSBuZXR3b3JrLCAgY2FyZSBzaG91bGQgYmUgdGFrZW4gdG8gZXZhbHVhdGUg dGhlIGltcGFjdCBvZiB0aGF0IGNoYW5nZSBhY3Jvc3MgdGhlIGVudGlyZSBuZXR3b3JrLg0KLS0t LS0tLQ0KDQpUaGFua3MsDQpDaHJpcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPU1BGIG1haWxpbmcgbGlzdA0KT1NQRkBpZXRmLm9yZzxtYWls dG86T1NQRkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b3NwZg0K --_000_D2877495410E0aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <98C9948A5C652140862E7C10A46EF6C1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5KZWZmLCBDaHJp cywmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXNlIGFkZGl0aW9ucyBs b29rIHJlYXNvbmFibGUgdG8gbWUgYXMgd2VsbC4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhhbmtzLDwv ZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7 IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9U VE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRP TTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9Q OiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1U T1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk9T UEYgJmx0OzxhIGhyZWY9Im1haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmciPm9zcGYtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKZWZmIFRhbnRzdXJhICZsdDs8YSBocmVm PSJtYWlsdG86amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb20iPmplZmYudGFudHN1cmFAZXJpY3Nz b24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPkZyaWRheSwgRGVjZW1iZXIgNCwgMjAxNSBhdCA0OjMxIFBNPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Q2hyaXMgQm93ZXJzICZsdDs8YSBocmVm PSJtYWlsdG86Y2Jvd2Vyc0BqdW5pcGVyLm5ldCI+Y2Jvd2Vyc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+T1NQRiBXRyBM aXN0ICZsdDs8YSBocmVmPSJtYWlsdG86b3NwZkBpZXRmLm9yZyI+b3NwZkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogW09TUEZdIHByb3Bvc2VkIHRleHQgZm9yIGRyYWZ0LXBwc2VuYWstb3NwZi10ZS1saW5rLWF0 dHItcmV1c2U8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+ DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2PkhpIENocmlzLDwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIC0gc291bmRzIHJlYXNvbmFibGUgdG8gbWUuPC9kaXY+ DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPldpdGggaW5jbHVzaW9uIG9mIHlvdXIgY29t bWVudHMgLSB3b3VsZCB5b3UgYmUgc2F0aXNmaWVkIHdpdGggdGhlIHNvbHV0aW9uIHByb3Bvc2Vk PzwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4NCjxkaXYg aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+VGhhbmtzIGFuZCBoYXZlIGEgZ3JlYXQgd2Vla2VuZCE8 YnI+DQo8YnI+DQpSZWdhcmRzLA0KPGRpdj5KZWZmPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K T24gRGVjIDQsIDIwMTUsIGF0IDk6MzMgQU0sIENocmlzIEJvd2VycyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNib3dlcnNAanVuaXBlci5uZXQiPmNib3dlcnNAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+ DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAtLT48c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7IG1h cmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAwMCAy cHggc29saWQ7IH0gLS0+PC9zdHlsZT48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+RHJhZnQgYXV0aG9ycyw8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoZSBmb2xsb3dp bmcgdGV4dCBmb3IgdGhlIEJhY2t3YXJkcyBDb21wYXRpYmlsaXR5IHNlY3Rpb24gb2YgdGhpcyBk b2N1bWVudC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tLS08L2Rpdj4NCjxk aXY+U29tZSBkZXBsb3ltZW50cyBvZiBMRkEgYW5kIHJlbW90ZSBMRkEgY3VycmVudGx5IHJlbHkg b24gbGluayBhdHRyaWJ1dGVzIChzdWNoIGFzIFNSTEcgYW5kIGFkbWluIGdyb3VwcykgYmVpbmcg Y2FycmllZCBpbiB0aGUgVEUgT3BhcXVlIExTQS4mbmJzcDsgVGhlc2UgYXBwbGljYXRpb25zIGFy ZSBkZXNjcmliZWQgaW4gUkZDIDUyODYsIFJGQyA3NDkwLCZuYnNwOyBkcmFmdC1pZXRmLXJ0Z3dn LWxmYS1tYW5hZ2VhYmlsaXR5LCBhbmQgZHJhZnQtcHNhcmthci1ydGd3Zy1ybGZhLW5vZGUtcHJv dGVjdGlvbi4mbmJzcDsNCiBXaGVuIGEgbmV0d29yayBpcyB1c2luZyBhbiBhcHBsaWNhdGlvbiB0 aGF0IHJlbGllcyBvbiBsaW5rIGF0dHJpYnV0ZXMgYmVpbmcgY2FycmllZCBpbiB0aGUgVEUgT3Bh cXVlIExTQSAsIGNhcmUgc2hvdWxkIGJlIHRha2VuIHRvIGNvbnRpbnVlIHRvIGFkdmVydGlzZSB0 aGUgYXBwcm9wcmlhdGUgbGluayBhdHRyaWJ1dGVzIGluIHRoZSBURSBPcGFxdWUgTFNBLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Tm90ZSB0aGF0IGEgbm9kZSB0aGF0IGRvZXMgbm90 IGRpcmVjdGx5IHBhcnRpY2lwYXRlIGluIHJlbW90ZSBMRkEgYnkgb3JpZ2luYXRpbmcgcmVwYWly IHR1bm5lbHMgaXRzZWxmIG1heSBzdGlsbCBuZWVkIHRvIGNvbnRpbnVlIG9yaWdpbmF0aW5nIGxp bmsgYXR0cmlidXRlcyBpbiB0aGUgVEUgT3BhcXVlIExTQSBmb3IgdXNlIGJ5IG90aGVyIG5vZGVz IGluIHRoZSBuZXR3b3JrLiZuYnNwOyZuYnNwOyBUaGVyZWZvcmUsIHdoZW4gZXZhbHVhdGluZyBz b2Z0d2FyZQ0KIHVwZ3JhZGVzIG9yIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyB3aGljaCBtYXkgcmVz dWx0IGluIGNoYW5nZXMgdG8gd2hpY2ggbGluayBhdHRyaWJ1dGVzIGFyZSBiZWluZyBhZHZlcnRp c2VkIGluIHRoZSBURSBPcGFxdWUgTFNBLCBldmVuIGZvciBhIHN1YnNldCBvZiByb3V0ZXJzIGlu IHRoZSBuZXR3b3JrLCZuYnNwOyBjYXJlIHNob3VsZCBiZSB0YWtlbiB0byBldmFsdWF0ZSB0aGUg aW1wYWN0IG9mIHRoYXQgY2hhbmdlIGFjcm9zcyB0aGUgZW50aXJlIG5ldHdvcmsuPC9kaXY+DQo8 ZGl2Pi0tLS0tLS08L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4N CjxkaXY+Q2hyaXM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5PU1BGIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8 c3Bhbj48YSBocmVmPSJtYWlsdG86T1NQRkBpZXRmLm9yZyI+T1NQRkBpZXRmLm9yZzwvYT48L3Nw YW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vc3BmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGY8L2E+ PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D2877495410E0aceeciscocom_-- From nobody Sat Dec 5 05:39:26 2015 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 395B01B2A22 for ; Sat, 5 Dec 2015 05:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFijuQYF_4pE for ; Sat, 5 Dec 2015 05:39:24 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C64C1B2A20 for ; Sat, 5 Dec 2015 05:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1721; q=dns/txt; s=iport; t=1449322764; x=1450532364; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Dd/KagA+SqNQpGFN3GfLaP6z8v6/A8hFu1eSZWy49uc=; b=b/1lucSVJ9WLbOfCCUKUncc5Qd5ChghgRymn8ZtUrBmKNRJLxCSbNfPS Fkg/Wu5FywBhtbflngR7+o68o9v+hNmwLviRZDCiiX9A1OYTOQOI0KHBN GtWHIE+0ZPz3Gk/NsAsuatE9Q2UNpker36YUIfwCxOdT4xNxjSOrOLcF+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAj52JW/xbLJq1ehA1uv0UXCoI9g?= =?us-ascii?q?zACgW4BAQEBAQGBC4Q0AQEBAwEBAQE1LwcKBgsLDgoJFg8JAwIBAgEVMAYBDAY?= =?us-ascii?q?CAQGIIwgNwBMBAQEBAQEBAQEBAQEBAQEBAQEXBIZUhH2ES4RwAQSWYY08iSGTT?= =?us-ascii?q?GOEBT00hCeBSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,385,1444694400"; d="scan'208";a="607024424" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2015 13:39:21 +0000 Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tB5DdKbs001984; Sat, 5 Dec 2015 13:39:20 GMT Message-ID: <5662E908.1000403@cisco.com> Date: Sat, 05 Dec 2015 14:39:20 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Chris Bowers , OSPF WG List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 13:39:26 -0000 Hi Chris, On 12/4/15 18:32 , Chris Bowers wrote: > Draft authors, > I would like to suggest the following text for the Backwards > Compatibility section of this document. > ------- > Some deployments of LFA and remote LFA currently rely on link attributes > (such as SRLG and admin groups) being carried in the TE Opaque LSA. > These applications are described in RFC 5286, RFC 7490, > draft-ietf-rtgwg-lfa-manageability, and > draft-psarkar-rtgwg-rlfa-node-protection. When a network is using an > application that relies on link attributes being carried in the TE > Opaque LSA , care should be taken to continue to advertise the > appropriate link attributes in the TE Opaque LSA. Here I would add: "Doing so would make the link part of the traffic engineering topology as defined in RCF 3630." "Advertising the particular link attribute in TE Opaque LSA does not prevent the same attribute to be advertised in Extended Prefix LSA for the same link." thanks, Peter > Note that a node that does not directly participate in remote LFA by > originating repair tunnels itself may still need to continue originating > link attributes in the TE Opaque LSA for use by other nodes in the > network. Therefore, when evaluating software upgrades or configuration > changes which may result in changes to which link attributes are being > advertised in the TE Opaque LSA, even for a subset of routers in the > network, care should be taken to evaluate the impact of that change > across the entire network. > ------- > Thanks, > Chris > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Dec 15 08:30:28 2015 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 727481A9084; Tue, 15 Dec 2015 08:30:26 -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_20=-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 WLI9O_Itgzo7; Tue, 15 Dec 2015 08:30:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4381AC3A1; Tue, 15 Dec 2015 08:23:28 -0800 (PST) Received: from BY1PR0201CA0041.namprd02.prod.outlook.com (10.160.191.179) by BL2PR02MB433.namprd02.prod.outlook.com (10.141.94.146) with Microsoft SMTP Server (TLS) id 15.1.337.19; Tue, 15 Dec 2015 16:23:13 +0000 Received: from BN1AFFO11FD008.protection.gbl (2a01:111:f400:7c10::127) by BY1PR0201CA0041.outlook.office365.com (2a01:111:e400:4814::51) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Tue, 15 Dec 2015 16:23:12 +0000 Authentication-Results: spf=pass (sender IP is 192.91.191.64) smtp.mailfrom=metaswitch.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=metaswitch.com; Received-SPF: Pass (protection.outlook.com: domain of metaswitch.com designates 192.91.191.64 as permitted sender) receiver=protection.outlook.com; client-ip=192.91.191.64; helo=metaswitch.com; Received: from metaswitch.com (192.91.191.64) by BN1AFFO11FD008.mail.protection.outlook.com (10.58.52.68) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Tue, 15 Dec 2015 16:23:12 +0000 Received: from ENFICSCAS2.datcon.co.uk (172.18.4.11) by ENFICSCAS2.datcon.co.uk (172.18.4.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Dec 2015 16:23:10 +0000 Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSCAS2.datcon.co.uk (172.18.4.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 15 Dec 2015 16:23:10 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%12]) with mapi id 14.03.0266.001; Tue, 15 Dec 2015 16:23:10 +0000 From: Alan Davey To: "draft-ietf-ospf-yang@ietf.org" Thread-Topic: draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zg== Date: Tue, 15 Dec 2015 16:23:09 +0000 Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.209.34] Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804012A72782AENFICSMBX1dat_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD008; 1:6XATyjHUHOV/lRA5IAb4iVb4/SvQFdj653RpYJnV10QrMORS4+IHY7h97OS97XEBASvpaCaHLDM7fmIGg42Vi3oJQoziB5+x6YQJKtpeWhEWu6S4Qn+DWxHBYXWqDnRsJhQfXd/dvZV79NUk8ImGV8kDSqTaReVdCyynLq1KyWqv9PFLjBCT3kK+5Znx4Rq6dM1ZLffRe7BDTB4piduqMfBmYJluxk0nrT1K2XTcjNkbR2E72ZjVwp35d8WZzV6LwdqyXQPAiAOPHhM989Abv1NmBmsxbbQAfYNaK5Sux9oL7+QPimB8s4abG9+NBZ9jLfXiWKtvfY2My94pFGBXI/dymfIVVnbUw+4H/7sWcgdUTAQo6meFMm7t0EkeqI6NKj6l7Lc/DiEZcCGdkL+yUMabEKdlYaJHvDL+cPDNXJE= X-Forefront-Antispam-Report: CIP:192.91.191.64; CTRY:GB; IPV:CAL; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(51444003)(189002)(1096002)(55846006)(6116002)(300700001)(230783001)(15975445007)(19625215002)(5003600100002)(512934002)(54356999)(19300405004)(19580395003)(50986999)(92566002)(2900100001)(5250100002)(790700001)(40036005)(86362001)(586003)(53416004)(110136002)(2351001)(33656002)(84326002)(2501003)(102836003)(5001970100001)(1220700001)(2920100001)(229853001)(6806005)(189998001)(26826002)(22756006)(450100001)(87936001)(3846002)(5008740100001)(5004730100002)(11100500001)(2930100002)(16236675004)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB433; H:metaswitch.com; FPR:; SPF:Pass; PTR:enficscas2.metaswitch.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2PR02MB433; 2:WFR3CRXHcsaQLNUiRi28kzpAqxRRKljeDo8i/KxI1fC6GVRUIgmBy7k2xmoTVporqw9vnGDWxvCrJ6+eB0mk6X+jcp229n+cRNzaeEf7TZe+tPJZcOWH9b1vNxZq8lKZtAgGibwunHBgsrAMzx2kbw==; 3:rReJuxMluIlyJgsirfEbFrYXKlycL0ZUOf7Ct65nHbLi2mMTSqOdP1uhbu48MOpop/o9ZJGv9vOEDabm/el/mxFP8Hq57LWv6ZJ47BwOHOPWuSPbzvxJKBZRwvVm4DtKdJNuNJ4mUpR9zD1PnA1aQW7Ru7nyaVIoIWN603LkxxkEQ/IRxDZ7BT1R+zwcdxNYw/ikhebJsKyP0KsM5ZAhh0q3pLLOhDd1Bw2MtS0wlgMjxf9XA1CB50NzXMDgGLUulhvEXRckiI1cURu12ntAkg==; 25:CSwc1H3xLYVRTVXMOsik9xrw+H5PGoWte2BAN4TPJMUSD2KPondDw/RT/jl+i2PVCtjyZ8yHvEsB/y49TpsOsnf0+emnEksnLMy729talmxxTlTajWMCf5ZTHkESYF0vJcnJgkqFPifoKxsJIGGN/aGqnT/BKHcGI8++LW64eJr+sIvl4ep0EG+5Rq3U550qf6FTuBU+VwS/OG/xiVLIBM33ROrW1+xaSIItMAffbGTfBnmQEbdqnxnyWPhIx8PiY9bOygkmJIpqVbOZIe0Ryw==; 20:ZUy+ExH3dtN/zKZV8nJL0LkiL6qCyRHGNBzb+qgQX02++WajAlWKQ8FMyjsQedmx841Hoy044eCI3cHZoXFpaVBcbagBIZg3cfl21+/SQH2cjNt3pYtStladanojbN5nYVgR4CfmZmBiHFUGa5IlKac8x68muBP6stuqbYPvzjo= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BL2PR02MB433; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BL2PR02MB433; BCL:0; PCL:0; RULEID:; SRVR:BL2PR02MB433; X-Microsoft-Exchange-Diagnostics: 1; BL2PR02MB433; 4:aA43R12TKhLMF9Gi5P0UBjXG313I99437x+nWwiTH6fHBU9KRuw/PIzal8mpD5qNbq2jPiyjGrITVYuXglP4zXO4FLLOeedJIDizmcU8hm8i3Rgoc7Cw7l2fTHi40q3Nl59YBcuGNETRfK28wRw1Fkxz+nrPDzylGNBizbxbCRL/7fIsJYoVDXfjB7XZvMT2bkj4tpKaBMsdDZSL1bBagJ/zPIP4cCL56Zb9cciLx7TKs+4lXm2HGUYJ6tPVGL+0OCM+zd1AvV/JJqLHPiVbM9fMpwt2enODKfOZQyg3bhc6mTU0HKZW9jPmqLZkqC0GoVMy8K+SkkD1V/waNXl16YI8Q5uP9RYngGMrrZWJTSDb6WgSEbHtsbR3JUTjRLYj X-Forefront-PRVS: 07915F544A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR02MB433; 23:L0EvdTusCm498XjoALYMyMKIFnNhqT2+rPj5o90fCq?= =?us-ascii?Q?RRuZVQViCBO7ZF2l6SmOAEAMBkdXeolDM5w3LxbXX8TnBu1XdGRu//c4WHxp?= =?us-ascii?Q?crNZQF64sEqe+56f1DWu/JnQc+G3IZH/EFMHFb428/8yGVmrArrBRrStqbTU?= =?us-ascii?Q?hFUdkjLEY4NU5bXo6BZoR0q7ULDqFa+JWfon6DOBxJ5OAr6xRAjOhJovarNf?= =?us-ascii?Q?FSce94yhfR35COEQ34ZtIfxZHeIkWg59ZXJpk4tNLc43DGEZR59hRs01zlJt?= =?us-ascii?Q?0vqZaVtCb7fGwHd57mDDTH+lGykED/6YBpVVcjNc2tU4N7J3kZ3IQ/fr5P18?= =?us-ascii?Q?SnIynmtkoa3VS//nldB959EJhU7cnIejtdMzdRiMiakO6aMlpvbR06HC/iTA?= =?us-ascii?Q?yl+9ZFdmUvAdCMcxWmCYUkTTdyawpx8j1CZE8G4MOK4dFnWjGD5SUj2DE4Dt?= =?us-ascii?Q?schdnJuz1k3+W+Oy4V1uzhX0kAbfRjn6Qytx6Rsxekr7BXqnWG9xt8VLlOCC?= =?us-ascii?Q?MjnXJlyZ2zqY5soSvhnd/z0r9ZcTvxIT0QbW5IvmCrmG7TkIV/BhffDLNyEW?= =?us-ascii?Q?5piN9jrx2ekTxv7+KzVsfNxpJTr+5vWLQLK8MBm3vhtUmnKOJSc2rmI45mW+?= =?us-ascii?Q?waYb0deXhiisC9ZC8+egDaCYnTUJgvVM01nBh6eFlTIutBdsrvZhvOcpq0ow?= =?us-ascii?Q?z6XY2jCE2MGzJYF/+iEOCbRiXWhNPsT3WWG/lUg8dCHGej9sNNZevLJ/Rit7?= =?us-ascii?Q?pA6WY7laLgBFYTMCpvm3hE9/+5UWh+M3J9NfAGcd6LWZ7S0lDtpbYUuz+9Ep?= =?us-ascii?Q?VYuEGts5PTXkIormBCy4hl17orzTdH9fKNLzNf3BDSAL/kkb5jFbAMpoPgnD?= =?us-ascii?Q?QL7kvpEzeGKppzsZqxU6q6XYgmSWOcKd2y7KdvZ10JifloK53Yiq3wPyD1JV?= =?us-ascii?Q?pP8X1rmshYAAIeykX44/jksD2hSMpZwDgKifFLKh1FGAooNKLgl/S4K7Avoz?= =?us-ascii?Q?yLrMpvyM78f4ehY6CCOR/b37LV78CUzOmiXIF/qqgfFAYgnHO+fC6YkK8l+S?= =?us-ascii?Q?mBRfOC/RVoWr9jJTiAx7srD3F+VO6vt3e+1juKaASbdfqNzZDtHWfsf1CrNh?= =?us-ascii?Q?xqjWgkhR+/C9luuG9kZfd4P/G8cObDmGpTsEhhSMGJKCk5WpMMjsUhcOzs5z?= =?us-ascii?Q?ayQQgUCU+obDhsy/cJSlA16IvE/4P53jRPpMn1O+pVav22td/+nDcF57QXFM?= =?us-ascii?Q?uLkVP4N2kPCqcckOeEQ14MPeJYUDwTyl0PCwzjdsocIe3JvylUL7chI1Zd5N?= =?us-ascii?Q?Qj+NGg+xjRTQhWvE+71mw=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR02MB433; 5:uvqWjl43sUBOLhsdJEZkk0wXwIzgwxOMG8/NSqL1WU6/NvP2KFnOpMH35QBEiyz5jFH1eu3rKU8/PLI9Y8CbAN1kQjDde/8+2O9e+WYcAttrgqgo1xFQ70Ju5YM5R5aocF/5GZ2q7QK/x00pesHiZQ==; 24:5tEO3t4LJ4bWu01mpYnh1IcTE80/LxK9rc01fXFzcK7w/XZrQBRicfPif4GptjR0ftoFxvADuN8ycHWBb9qrasxXRkFV+gRnoFvLOzdg6gM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2015 16:23:12.0347 (UTC) X-MS-Exchange-CrossTenant-Id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb; Ip=[192.91.191.64]; Helo=[metaswitch.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR02MB433 Archived-At: Cc: "ospf@ietf.org" Subject: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 16:30:26 -0000 --_000_C2EE31C852049D499842B19FC01C0804012A72782AENFICSMBX1dat_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks I have a doubt about draft-ietf-ospf-yang-03. Please let me know your thou= ghts on the following. The text is OSPFv2-specific in places. I think that it would be better to = define separate top-level groupings and containers for OSPFv2 and OSPFv3 an= d define common groupings and containers, where possible, that are used by = both. For example, grouping interface-operation contains the following, which is = incorrect for OSPFv3. - leaf dr with type ipv4-address - leaf bdr with type ipv4-address. I think that it would be better to define something along the following lin= es. - ospfv3-interface-operation { o uses interface-config o uses ospf-common-interface-operation o leaf dr { =A7 type if:interface-ref =A7 description: =B7 "The remote interface ID used by the Designated Route= r on =B7 this link. This is the interface index of the interf= ace local to the DR."; o etc - ospfv2-interface-operation { o uses interface-config o uses ospf-common-interface-operation o leaf dr { =A7 type inet:ipv4-address; =A7 description "Designated Router (DR) IP address."; o etc. Regards Alan Davey --_000_C2EE31C852049D499842B19FC01C0804012A72782AENFICSMBX1dat_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks

 

I have a doubt about draft-ietf-ospf-yang-03.  = Please let me know your thoughts on the following.

 

The text is OSPFv2-specific in places.  I think= that it would be better to define separate top-level groupings and contain= ers for OSPFv2 and OSPFv3 and define common groupings and containers, where= possible, that are used by both.

 

For example, grouping interface-operation contains t= he following, which is incorrect for OSPFv3.

 

-     &= nbsp;    leaf dr with type ipv4-address

-     &= nbsp;    leaf bdr with type ipv4-address.

 

I think that it would be better to define something = along the following lines.

 

-     &= nbsp;    ospfv3-interface-operation {

o   uses interface-config

o   uses ospf-common-interface-operation

o   leaf dr {

=A7&= nbsp; type if:interface-ref

=A7&= nbsp; description:

=B7&nbs= p;               &n= bsp;  "The remote interface ID used by the Designated Router= on

=B7&nbs= p;               &n= bsp;  this link.  This is the interface index of the interfa= ce local to the DR.";

o   etc

-     &= nbsp;    ospfv2-interface-operation {

o   uses interface-config

o   uses ospf-common-interface-operation

o   leaf dr {

=A7&= nbsp;        &n= bsp; type inet:ipv4-address;

=A7&= nbsp;        &n= bsp; description "Designated Router (DR) IP address.";<= /o:p>

o   etc.

 

Regards

Alan Davey

 

--_000_C2EE31C852049D499842B19FC01C0804012A72782AENFICSMBX1dat_-- From nobody Tue Dec 15 12:42:59 2015 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 483911ACD95 for ; Tue, 15 Dec 2015 12:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 WCYSuR-qzJTT for ; Tue, 15 Dec 2015 12:42:55 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AABC1ACD8A for ; Tue, 15 Dec 2015 12:42:55 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id n186so112946079wmn.0 for ; Tue, 15 Dec 2015 12:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=NcVuFHnZLFkFJlif8Uh+tDDQUoff8L7AW6zOsypNGVE=; b=gMFKHott2Td/gxvKQ+/XjmOK59iyuy7P5O5WUOL+KA3sIQOcZ2L8O1qGk5SD5RNwDm grZv0DeG4UYOyXidqfC5a+Z1L7KCROxwK1i47C86BbkXIsnZl3nGBvb0RKexhdY2uoGP IT8M7xiktdOxHJfG86vD92dVUHSBWEJyt/suTFieeKHaSNVyCsYRwwlVeia3hwqm7po3 drh4na+yy2J4PPKJofMP0BrFXF+NuFw7I8aIUO5v1DOuYcbh2c1DTCkbyo30YdUT3vIV wkrFed1XTsBaeu16jd7aE7E/wX+R/ORE2tTD8OOnQj55r03XA0s8zoJRx7SgKFJv0uQB C7Bw== MIME-Version: 1.0 X-Received: by 10.28.216.72 with SMTP id p69mr7692831wmg.14.1450212174133; Tue, 15 Dec 2015 12:42:54 -0800 (PST) Sender: ilcon7e@gmail.com Received: by 10.28.53.129 with HTTP; Tue, 15 Dec 2015 12:42:53 -0800 (PST) Date: Tue, 15 Dec 2015 21:42:53 +0100 X-Google-Sender-Auth: fSVBpkAdWSklEZfz8EwY37EL7sE Message-ID: From: Vlad Olariu To: ospf@ietf.org Content-Type: multipart/alternative; boundary=001a11469ac87d02110526f5d5f0 Archived-At: Subject: [OSPF] Making OSPF _not_ set the E bit in the router-lsa when redistributing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 20:42:57 -0000 --001a11469ac87d02110526f5d5f0 Content-Type: text/plain; charset=UTF-8 Hi All, I am unsure this is the right place to ask this, but there aren't many OSPF forums around the net. In dealing with a Cisco box I encountered a bug where the router would originate a default route in OSPF but it wouldn't set the E bit in the router-lsa (indicating it is an ASBR). I wanted to replicate the bug on my home computer by making OSPF behave _not_ according to RFC, yet I found it rather difficult to do. With linux I created a bridge and connected two routers on each side, yet now I am only able to see traffic go *through* but I have no power over changing the actual packet contents. People have been talking about "divert sockets" but those appear to me: 1. Related to TCP/IP ports 2. To work best on FreeBSD of which I have no particular knowledge Doing a "man in the middle" "attack" is a lot harder than what it seemed, as no tool I have looked at lets you change particular bits in packets passing through your linux box (not any with the same feel like wireshark at least). I would guess that people implementing the protocol for years now would have found a simpler way of testing things like these, hence here I am in search of any advice. I also looked into scapy which, while great in capturing, changing and sending packets it does not let me do this "real time". In reality it lets you make a copy of a packet passing through which it then lets you change and send at your will (meanwhile the original packet is long gone). Any help would be very appreciated. Vlad. --001a11469ac87d02110526f5d5f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I am unsure this is the right p= lace to ask this, but there aren't many OSPF forums around the net.

In dealing with a Cisco box I encountered a bug where= the router would originate a default route in OSPF but it wouldn't set= the E bit in the router-lsa (indicating it is an ASBR).

I wanted to replicate the bug on my home computer by making OSPF beh= ave _not_ according to RFC, yet I found it rather difficult to do.

With linux I created a bridge and connected two routers on= each side, yet now I am only able to see traffic go *through* but I have n= o power over changing the actual packet contents.

= People have been talking about "divert sockets" but those appear = to me:

1. Related to TCP/IP ports
2. To = work best on FreeBSD of which I have no particular knowledge

=
Doing a "man in the middle" "attack" is a lo= t harder than what it seemed, as no tool I have looked at lets you change p= articular bits in packets passing through your linux box (not any with the = same feel like wireshark at least).

I would guess = that people implementing the protocol for years now would have found a simp= ler way of testing things like these, hence here I am in search of any advi= ce.

I also looked into scapy which, while great in= capturing, changing and sending packets it does not let me do this "r= eal time". In reality it lets you make a copy of a packet passing thro= ugh which it then lets you change and send at your will (meanwhile the orig= inal packet is long gone).

Any help would be very = appreciated.

Vlad.
--001a11469ac87d02110526f5d5f0--