IETF Logo Mail Archive

Re: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps

Huaimo Chen <huaimo.chen@huawei.com> Sat, 06 July 2013 23:44 UTC

Return-Path: <huaimo.chen@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9361521F8FDC for <ospf@ietfa.amsl.com>; Sat, 6 Jul 2013 16:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpIVDQ7UOizt for <ospf@ietfa.amsl.com>; Sat, 6 Jul 2013 16:44:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 702EC21F883B for <ospf@ietf.org>; Sat, 6 Jul 2013 16:44:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATE64487; Sat, 06 Jul 2013 23:44:13 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 7 Jul 2013 00:43:49 +0100
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 7 Jul 2013 00:43:56 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Sat, 6 Jul 2013 16:43:51 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: William McCall <william.mccall@gmail.com>, Russ White <russw@riw.us>
Thread-Topic: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps
Thread-Index: AQHOenxIhIVtYWrsm0OIrIePYTiJJplYjyoAgAAXDQD//6bu0A==
Date: Sat, 06 Jul 2013 23:43:50 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D4451E28B7@dfweml509-mbx.china.huawei.com>
References: <94A203EA12AECE4BA92D42DBFFE0AE471993A4@eusaamb101.ericsson.se> <002201ce7a87$6648e530$32daaf90$@riw.us> <51D8914C.3030200@gmail.com>
In-Reply-To: <51D8914C.3030200@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.246.214]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: 'OSPF List' <ospf@ietf.org>
Subject: Re: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 06 Jul 2013 23:44:21 -0000

Hi William,

    Thanks much for your very helpful comments!
    My responses are inline below.

Best Regards,
Huaimo
-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of William McCall
Sent: Saturday, July 06, 2013 5:51 PM
To: Russ White
Cc: 'OSPF List'
Subject: Re: [OSPF] OSPF Topology Transparent Zone (TTZ) Next Steps

Seems like, to me, the net accomplishment is to avoid a L2VPN layer sitting where the internal TTZ nodes are, based on the scenarios proposed in these drafts. Looks like it would also allow a lot more flexibility in adding nodes to the TTZ vs. trying to do L2VPNs, particularly with regard to metric calculation (but also future growth if an internal node is made edge).

 From draft-chen-ospf-ttz-05:
>   A TTZ MUST hide the information inside the TTZ from the outside.  It
>     MUST NOT directly distribute any internal information about the TTZ
>     to a router outside of the TTZ.

One thing I'm not so happy about in the drafts is that they seem to imply that ANYTHING from the internal TTZ nodes is not sent to the TTZ-external nodes from an OSPF perspective. IMO, I'd want the option to advertise a loopback (or whatever) from the internal TTZ nodes out to the TTZ-external nodes so I can reach them for management, etc. I guess this could be done with BGP, but that seems overkill for what I'm looking for.

[Huaimo] This is very good point. We will consider the option to advertise a loopback from the internal TTZ nodes out to the TTZ-external nodes.

On 07/06/2013 03:28 PM, Russ White wrote:
> In general, I think this is useful. I can think of specific situations 
> where it would be nice/would have been nice to have.
My opinion would be to adopt it as a WG draft, but with a bit of scrutiny as to the use cases. Russ got it right when he said there are "specific situations", but I guess the question would be around whether the situations are prolific enough to warrant work on this. I vote "probably", but smarter people than me know better.

[Huaimo] We will work more on the use cases.

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

v2.23.0 | Report a Bug | By Email