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

Uma Chunduri <uma.chunduri@ericsson.com> Mon, 12 May 2014 02:30 UTC

Return-Path: <uma.chunduri@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 13FF01A03C1; Sun, 11 May 2014 19:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.05
X-Spam-Level: ****
X-Spam-Status: No, score=4.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 PmbqbY_HfqFy; Sun, 11 May 2014 19:30:07 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B0B181A0145; Sun, 11 May 2014 19:30:06 -0700 (PDT)
X-AuditID: c6180641-f799b6d000000b0f-64-536fe07a5ab3
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 82.C2.02831.A70EF635; Sun, 11 May 2014 22:41:31 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Sun, 11 May 2014 22:29:59 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Acee Lindem <acee.lindem@ericsson.com>
Thread-Topic: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs
Thread-Index: AQHPayEh4teIod3/r0eOb3fsPY20bZs4NlMAgAAJRACAACzPgIAATNyggABawgD//78V0IAAfSKAgALpvfA=
Date: Mon, 12 May 2014 02:29:59 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F27B80D@eusaamb105.ericsson.se>
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> <96F7B28A-FAE8-48BF-9A88-985E3AAC9436@ericsson.com>
In-Reply-To: <96F7B28A-FAE8-48BF-9A88-985E3AAC9436@ericsson.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_1B502206DFA0C544B7A60469152008633F27B80Deusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyuXRPoG71g/xggwVr+C1atrFarG94wW5x 9NB7VotXp9YwWnxdNJvJouXePXaLlXv2s1ss2Xyd1WLr+VWMDpweZ48sYPSYd2Ehm8eU3xtZ PVqOvGX1WLLkJ5PH6jWvWALYorhsUlJzMstSi/TtErgynjxtYy3YPZ2x4s2ynAbGSd2MXYyc HBICJhIHds9mhrDFJC7cW8/WxcjFISRwlFFi9+oLYAkhgeWMEjs+iYDYbAJ6Eh+n/mQHsUUE tCQ6335nB2lgFvjGJLGx9xRrFyMHh7BAscS8d5oQNSUSV74+YoKwkyTufTnNBmKzCKhKLD62 jBXE5hXwlbjUMIsdYvEUNol7T/6BXccp4CBx6sVesGWMQNd9P7UGbBCzgLjErSfzmSCuFpBY suc81AeiEi8f/2OFsJUk5ry+xgxRny9xs2kHI8QyQYmTM5+wTGAUnYVk1CwkZbOQlEHEtSTm NfyGqlGUmNL9kB3C1pS4MvkQlK0tsWzha+YFjOyrGDlKi1PLctONDDcxAqP4mASb4w7GBZ8s DzEKcDAq8fAu2JUfLMSaWFZcmXuIUZqDRUmcN/1TbLCQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGRlax2UVvLszikxE3vZiTf/vkNXsZ9cMNd0t3ZKw8bltSnXPrYqW7WMbeCr2YCIvD6ZcU uO/ova4+eGEdlxxH5qSbz2VnX474Y3BeKHBGk+OPGb9SD2cEvlp5Xv3nSrYFd6/rmUXa1V+1 fTqPf9/W40FioQs331ixyP3L1oV7fkh/zFN+5zrbrkeJpTgj0VCLuag4EQDCALeywwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/6GE1Bcp-VbSvdF4gaHqa-NEjqv0
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: Mon, 12 May 2014 02:30:09 -0000

Hi Acee,

My comments inline [Uma1]

--
Uma C.

From: Acee Lindem
Sent: Friday, May 09, 2014 6:47 PM
To: Uma Chunduri
Cc: Xuxiaohu; isis-wg@ietf.org; Wes George; Anton Smirnov; fanpeng@chinamobile.com; Joel jaeggli; OSPF List; sunset4@ietf.org; lizhenqiang@chinamobile.com
Subject: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs

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.

[Uma1]: Yes Acee. This is more practical way and a separate IP can be hosted for this and this has to be advertised as “router IP”

>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.

[Uma]: IMO, it depends on the controller (where it’s located) and how many areas/ASes it is overseeing and also depends on applications it’s giving to access to network nodes.
             In a pure IGP environment, application of FW may not be necessary, but  giving access to the nodes through applications/controller is completely a different thing and security requirements can be different.
            Also the main point as you can see here is not only about security but it’s about giving visibility of the “router IP” through topology database to an outside entity.

Overall , FWIW it’s an useful addition to indicate this through (a sub-tlv of) the router capability TLV as presented here.

--
Uma  C.