Re: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"

"Acee Lindem (acee)" <acee@cisco.com> Mon, 08 February 2016 23:28 UTC

Return-Path: <acee@cisco.com>
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 CE39F1B3D3C; Mon, 8 Feb 2016 15:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, 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 a0I6rJ1CwPCe; Mon, 8 Feb 2016 15:28:35 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643D61B3D3D; Mon, 8 Feb 2016 15:28:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41571; q=dns/txt; s=iport; t=1454974115; x=1456183715; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zQwozqLEOdGJzxt/0SSYVyfDfbu5cdBmPFGszdnYTz4=; b=YTHZNJ7EQaG/C68W+Nx8ty9sCCXWgKD2uUJGJS6sZoVylmeAXT68sAWD k9NDsj6Pb+RWDZF47gP2V62IhxNXoEw/aCANnDco/gb0Se8RcfTCBXeZF TpPpQUiffyM5f9vxZGxE/aDRo3m62AifKP5swF6G7+j68m6IzG8SBkRUW c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQBPJLlW/5RdJa1egm5MUm0GiFWxE?= =?us-ascii?q?QENgWMDFwEJhWwCHIESOBQBAQEBAQEBgQqEQQEBAQQBAQEaBgpBFwQCAQgRAwE?= =?us-ascii?q?BASEBBgMCAgIlCxQJCAIEARKIGw6ueo50AQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QSJTnuEUg2CU4E6BYddhnmEBROEBwGFS4gEgVuIYIQ4imyDUQEeAQFCg2Rqh1d?= =?us-ascii?q?8AQEB?=
X-IronPort-AV: E=Sophos; i="5.22,418,1449532800"; d="scan'208,217"; a="74855511"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 23:28:34 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u18NSXS6027690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 23:28:34 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 18:28:33 -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; Mon, 8 Feb 2016 18:28:33 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Huaimo Chen <huaimo.chen@huawei.com>, OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-ttz@ietf.org" <draft-ietf-ospf-ttz@ietf.org>
Thread-Topic: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"
Thread-Index: AQHRYi4jla7PS0s1TUqKSvLe2+v0WZ8izHcA
Date: Mon, 8 Feb 2016 23:28:33 +0000
Message-ID: <D2DE8BD6.4BF3F%acee@cisco.com>
References: <D2C1642E.4A075%acee@cisco.com> <D2DAA394.4BC86%acee@cisco.com> <5316A0AB3C851246A7CA5758973207D44E4D4E2C@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E4D4E2C@SJCEML701-CHM.china.huawei.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.196]
Content-Type: multipart/alternative; boundary="_000_D2DE8BD64BF3Faceeciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/-vUji9oMZY8-jc6Wghs77FvXu8o>
Subject: Re: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 23:28:39 -0000

Hi Huaimo,

From: Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>
Date: Monday, February 8, 2016 at 12:03 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-ospf-ttz@ietf.org<mailto:draft-ietf-ospf-ttz@ietf.org>" <draft-ietf-ospf-ttz@ietf.org<mailto:draft-ietf-ospf-ttz@ietf.org>>
Subject: RE: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"


Hi Acee,



    Thank you very much for your valuable comments.

    My answers/explanations are inline below.



Best Regards,

Huaimo

-----Original Message-----
From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Friday, February 05, 2016 7:32 PM
To: Acee Lindem (acee); OSPF WG List; draft-ietf-ospf-ttz@ietf.org<mailto:draft-ietf-ospf-ttz@ietf.org>
Subject: Re: [OSPF] Working Group Last Call for "OSPF Topology Transparent Zone"



The WG Last Call has ended. I do have a couple minor comments.



   1. Section 1 list the advantages for setting up an LSP over a TTZ as

opposed

      to an area. The details of this are not described in the document so

this

      should either be removed or the document should explicitly state the

details

      of LSP setup are out of scope.

[Huaimo]: This will be removed from the document.

Great.




   2. In section 11.2, I can see some race conditions if different TTZ

status is

      configured on different routers in the TTZ during the

migration/rollback

      period. This is addressed by saying a warning message will be issued

if

      this occurs. How is this detected and will the conflicting operation

be

      rejected?

[Huaimo]: We will add some details about the detection and operation.

The conflicting/racing condition/operation can be detected on a router on which a configuration is issued.

When a configuration for controlling an action for migration/rollback is issued on a router, the router should check whether the action is in a correct sequence of actions for migration/rollback through using the information it has. For migrating a part of an area to a TTZ, the correct sequence of actions is as follows in general:

1) configure TTZ on every router in the part of the area to be migrated to TTZ;

2) configure on one router in the TTZ to trigger every router in the TTZ to generate and distribute TTZ information for migration; and

3) configure on one router in the TTZ to trigger every router in the TTZ to migrate to TTZ.

For rolling back from TTZ, it is similar.

After receiving a configuration on a router to migrate to TTZ, which is for action 3), the router checks whether action 2) is performed through checking if it has received/originated a TTZ LSA with T=1. If it has not, it gives a warning to an operator (generation and distribution of TTZ information for migration to TTZ are not done yet) and rejects the configuration at this time.

After a router receives a TTZ LSA with M=1 for action 3) from another router, it checks whether action 2) is performed through checking if it has received/originated a TTZ LSA with T=1. If it has not, it should give a warning. The operation for migration will continue.

After receiving a configuration on a router to generate and distribute TTZ information, which is for action 2), the router checks whether action 1) is performed through checking if TTZ is configured on it. If it is not, it gives a warning to an operator (TTZ is not configured on it yet) and rejects the configuration at this time.

I guess my concern is a sequence such as migration started from multiple routers followed by rollback from multiple routers. This testing scenario is probably something that could be addressed should the protocol move to standards track.




   3. I guess one misconfigured router (no TTZ ID configured) will keep

migration

      to TTZ from occurring. What happens if a misconfigured router is

introduced

      on a broadcast link? Do all routers on the link revert to non-TTZ

operation?

[Huaimo]: You are right. When there is one mis-configured router on a broadcast link, this link will not be migrated to TTZ. If a mis-configured router is introduced on a broadcast link, this broadcast link will be revert to non-TTZ link. In other words, each of the routers on the link reverts the status for its connection to the link to non-TTZ.

Once the TTZ is migrated, it seems it may be better just not to form adjacencies with the misconfigured router.

Thanks,
Acee





I also have a number of editorial comments but will send those offline.

[Huaimo]: We will address them accordingly.



Thanks,

Acee





On 1/17/16, 3:30 PM, "OSPF on behalf of Acee Lindem (acee)"

<ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org> on behalf of acee@cisco.com<mailto:acee@cisco.com>> wrote:



>This is the start of the WG last call for the “OSPF Topology Transparent

>Zone” protocol extensions draft. We’ve had a number of discussions on this

>and Huawei has a prototype implementation. The WG last call will end at

>12:00 AM PDT on February 1st, 2016. For your convenience, here is a URL:

>

>https://datatracker.ietf.org/doc/draft-ietf-ospf-ttz/

>

>Thanks,

>Acee and Abhay

>

>_______________________________________________

>OSPF mailing list

>OSPF@ietf.org<mailto:OSPF@ietf.org>

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