Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs

Acee Lindem <acee.lindem@ericsson.com> Sat, 10 May 2014 01:47 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3F1A0164; Fri, 9 May 2014 18:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.6
X-Spam-Level: *
X-Spam-Status: No, score=1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 QST8U__agWjg; Fri, 9 May 2014 18:47:01 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 63D531A0158; Fri, 9 May 2014 18:47:01 -0700 (PDT)
X-AuditID: c6180641-f799b6d000000b0f-4c-536d337beacd
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 70.02.02831.B733D635; Fri, 9 May 2014 21:58:52 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Fri, 9 May 2014 21:46:54 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Uma Chunduri <uma.chunduri@ericsson.com>
Thread-Topic: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
Thread-Index: AQHPayEhilMRcoAw9Uy/UwdzvGJxy5s4NlMAgAAJRACAACzOAIAAk7UA//+ejwCAAJTMAIAAHMaA
Date: Sat, 10 May 2014 01:46:53 +0000
Message-ID: <96F7B28A-FAE8-48BF-9A88-985E3AAC9436@ericsson.com>
References: <CF8CEDD4.2D52B%acee.lindem@ericsson.com> <5367B449.7090304@bogus.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826FEA2@NKGEML512-MBS.china.huawei.com> <EEB7CA30-C044-4A35-AF80-F71CEDF521C9@lindem.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827025D@NKGEML512-MBS.china.huawei.com> <536B9971.4080700@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08270C0C@NKGEML512-MBS.china.huawei.com> <536C9892.50107@linfre.de> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08270D2D@NKGEML512-MBS.china.huawei.com> <C080EC1B-823A-4456-9622-056C9F95821E@ericsson.com> <1B502206DFA0C544B7A60469152008633F27B228@eusaamb105.ericsson.se> <CF929EBE.2DBBE%acee.lindem@ericsson.com> <1B502206DFA0C544B7A60469152008633F27B362@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F27B362@eusaamb105.ericsson.se>
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_96F7B28AFAE848BF9A88985E3AAC9436ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyuXRPgm6NcW6wwfSFghYt21gt1je8YLc4 eug9q8WrU2sYLb4ums1k0XLvHrvFyj372S2WbL7OarH1/CpGB06Ps0cWMHrMu7CQzWPK742s Hi1H3rJ6LFnyk8lj9ZpXLAFsUVw2Kak5mWWpRfp2CVwZB1ufshc8d6loOfeerYGx166LkZND QsBEYumXacwQtpjEhXvr2boYuTiEBI4ySpw+t5YVwlnGKHHixHw2kCo2AR2J54/+gXWIANmN b2eygxQxC3xjktjYe4oVJCEsUCBx7NARVoiiQom3WxazQ9hREj/PnAeKc3CwCKhKtG+JAAnz CthLzO07wQSx7B6rxITLz1hAajgF/CR+3zcDqWEEuu77qTVMIDazgLjErSfzmSCuFpBYsuc8 1AeiEi8f/2OFsJUkPv6ezw5Rnyzx6eEidohdghInZz5hmcAoOgvJqFlIymYhKYOIa0h861wI VaMoMaX7ITuErS6x+0kDlG0tsWr/LChbW2LZwtfMCxg5VjFylBanluWmGxluYgTG9jEJNscd jAs+WR5iFOBgVOLhVVieEyzEmlhWXJl7iFGag0VJnDf9U2ywkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkYZhmUv/zpltP10VqlUMk1MnKOzp3ZL8pw91y/NkD6xwvzLj9qt7uklz/5uuruZ 6XyX6h/1qzdMM8w/3NMv3yBvWWgbf+JaYoPXrIDCw5X6lizRB6Yq6mcd7zjiOYlpxewH86pm bptTX1F42jM6cPeWb4eXri3+m+KeFFy4vHrC01MzQ+KvHt6kxFKckWioxVxUnAgAmxL+Bc4C AAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/ivki8YYKt9Zt52GEO84vnI4i_l8
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "fanpeng@chinamobile.com" <fanpeng@chinamobile.com>, Anton Smirnov <asmirnov@cisco.com>, Wes George <wesley.george@twcable.com>, Joel jaeggli <joelja@bogus.com>, OSPF List <ospf@ietf.org>, "sunset4@ietf.org" <sunset4@ietf.org>, "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
Subject: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 May 2014 01:47:03 -0000

Hi Uma,

On May 9, 2014, at 8:03 PM, Uma Chunduri <uma.chunduri@ericsson.com<mailto:uma.chunduri@ericsson.com>> wrote:

Hi Acee,
In-line [Uma]:

>I can see these -
>1.  RLFA TLDP session without having to worry a PQ node supports TE or
>not

I don't think this is a good use case. You need to have an the AF topology in order to compute the remote LFA. Also, you may inherit remote LFA targets for external and prefixes from other areas but you will never compute remote LFA targets in other areas (at least not with today's algorithms).

[Uma]: It doesn't have to be a different area. Take a simplest case of one area or an L2 domain; after having computed all the PQ nodes in that area/domain if the PQ node doesn't support TE and doesn't advertise router ID (TLV 134) which IP address you would pick for TLDP session ?  You can't reliably know from the advertised prefixes from the node that it is hosted by  the node if router ID is not emitted by the node (as it doesn't support TE).

The only advantage I can see is that a router can explicitly specify which local address it wants to use for targeted LFA sessions.


>2. Orchestration software on a controller or an application which is
>having access to
>   the topology database of the network may determine the node IP
>address without having to go through the hoops (to determine if it's
>redistributed or leaked etc..)
>   with this TLV.

Can you be more precise? If the orchestration application is going to orchestrate across multiple areas, I would hope it would have visibility to the topologies of these areas.

[Uma]: Even for a same area or domain having a node advertise it's loopback as router ID without relation any relation to TE (supported or not) is a benefit in this case.
The ability of an application on a controller to know this easily is a huge advantage.
Also there could be multiple loopback and each for different purposes. For e.g. a PCE on a controller with https://tools.ietf.org/html/draft-ietf-pce-pceps can know PCC address
with a firewall port/IP opened on the router for TLS connection. It would be great this can happen easily and automatically.

I don’t think anyone would have a firewall within an IGP routing domain. Hence, it would be the same purported advantage as above.

Thanks,
Acee




--
Uma C.