Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

bruno.decraene@orange.com Mon, 07 September 2020 09:19 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18A3A08B9 for <lsr@ietfa.amsl.com>; Mon, 7 Sep 2020 02:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 LaM5OWSgnUYz for <lsr@ietfa.amsl.com>; Mon, 7 Sep 2020 02:19:31 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808A73A005E for <lsr@ietf.org>; Mon, 7 Sep 2020 02:19:30 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4BlN5Y11m6z7x2H; Mon, 7 Sep 2020 11:19:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1599470369; bh=dZMKcl4UPG1H6VM0u4j6C5SyWFjZSeRL5KRATrymkaA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=QDjlntqZ0Z7WjJk39zM/u8vFN1F5tzT1YiiR7vOLRxLnqz21rL4FbYemHgjrJwh0M pCp++/AmjamFiuOWAa/V7bDD/sPZc89RTnfxglebS2dxn29xwGyWrlyd1Vv9kp3U3v /h2LPvED+7gesFGzNd+7EebfaFGW12zMSV2TBm+WqgkaZH5PV5I25du8InCUR8Nh3S th9I83yHEkO/59Inja4Qpwt1UHgSt3VZIUQC09mPUarP0yZ9vHNDUQhjvZYcCfLQRu mFxfSt+BYc7RsVBOFn0CHj8OF/oSV0LPpRqa0XHUbk0ScHy1ljXAVuGmDNE7kjkIIK aSQkNmgRMPO1Q==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4BlN5Y05jwz1xp6; Mon, 7 Sep 2020 11:19:29 +0200 (CEST)
From: bruno.decraene@orange.com
To: "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Thread-Index: AQHWgxoXCD4q5pTF5Uif9Xx/OFmpV6lc6U5w
Date: Mon, 07 Sep 2020 09:19:28 +0000
Message-ID: <10918_1599470369_5F55FB21_10918_311_1_53C29892C857584299CBF5D05346208A48F5D1B0@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <159665865921.15026.2581762617571023706@ietfa.amsl.com> <476BCC1F-0C33-4DEA-84DF-365FB5CBA377@tony.li> <21324_1599222537_5F523309_21324_463_12_53C29892C857584299CBF5D05346208A48F586AF@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <11428_1599228756_5F524B54_11428_211_6_53C29892C857584299CBF5D05346208A48F58912@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <D8280A67-08DD-43EE-A1E4-8DB7B81EF860@tony.li>
In-Reply-To: <D8280A67-08DD-43EE-A1E4-8DB7B81EF860@tony.li>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48F5D1B0OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/hIyX0alO1Afvg8UvD7ci0aQ4uHw>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2020 09:19:33 -0000

Hi Tony,

Thanks for your reply.
All good to me.

Thanks,
--Bruno


From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of tony.li@tony.li
Sent: Saturday, September 5, 2020 2:18 AM
To: DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Bruno,

Thank you for your comments.

1)

OLD: The
   advertisement in the Proxy LSP informs the remainder of the network
   that packets directed to the SID will be forwarded by one of the
   Inside Edge Nodes and the Area SID will be consumed.

NEW:

The

   advertisement in the Proxy LSP informs the outside area

   that packets directed to the SID will be forwarded to one of the

   Inside Edge Nodes and the Area SID will be consumed.

Motivation:
1)      More precise/descriptive and use the terminology defined in the draft
2)      The SID is a priori global in the outside area and hence will be forwarded by all nodes in the outside area (and not just by the Inside Edge Nodes). The destination is anycast to/toward any Inside Edge node.


Ok.



2)
§ 4.3.2.  The Area SID Sub-TLV

The Area SID Sub-TLV allows the Area Leader to advertise a prefix and

   SID



§4.4.13.  The Area SID

  The Area Leader SHOULD advertise the Area SID information in the

   Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1<https://tools.ietf.org/html/rfc8667#section-2.1>.


RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or /138) (rather than an IP prefix of an arbitrary length) [1].
[1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2

You may want to refer to this restriction when defining the Area SID Sub-TLV in section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. Alternatively open the option to advertise a prefix SID without the N-Flag if this is a prefix.


We are implicitly doing that by permitting a prefix.



3)
1 typo in -04 :s/ Inisde/ Inside


Fixed, thanks.



4)
OLD:
The Area Leader will generate a Proxy LSP that must be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of the
   Proxy LSP other than for flooding

My personal preference would be
NEW
The Area Leader will generate a Proxy LSP that will be flooded across
   the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) originated with the Area Proxy System Identifier other than for flooding.

Motivation:
a)      Clarify that no new behavior is involved
b)      Specifies how the proxy LSP is to be identified as a proxy LSP.



?  Ignoring the contents of an LSP is a new behavior.  I propose something slightly different:

          The Area Leader will generate a Proxy LSP that will be
          flooded across the Inside Area.  Inside Routers MUST ignore
          the contents of the Proxy LSP other than for flooding.  The
          Proxy LSP uses the Area Proxy System Identifier as its Source
          ID.




5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 LSP/LSDB or both?

“All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of the links within the topology.”
OK.

“A node advertises the Area Proxy TLV in its L2 LSP”
So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP of all Inside routers. (i.e. not in the L1 LSP).
If so:
-          Can you clarify the behavior when an Area Proxy TLV is received in an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is different in L1 and L2).


We already say:

           The Area Leader MUST advertise the Area Proxy System
           Identifier Sub-TLV when it observes that all Inside Routers
           are advertising the Area Proxy TLV.

The statement that you quote is pretty clear that the Area Proxy TLV is found in the L2 LSP.  I take it that you feel that this is insufficient.
I propose to add:

         Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST
          ignore the Area Proxy TLV if it is found in a L1 LSP.



-          “they will advertise the Area Proxy TLV.” May be adding “in their L2 LSP”


Ok.



-          “All Inside Edge Routers learn the Area Proxy System Identifier from the Level 1 LSDB”. I would have assumed  “from the Area Proxy TLV advertised in the level 2 LSDB.  So it may be a typo or I’m missing something, which is very possible.


That was a bug, thanks.  I changed it to: “ … from the Area Proxy TLV advertised by the Area Leader … “



o   “it MUST inject   the Area Proxy System Identifier into the Level 1 LSDB.” Same comment.


Also a bug.  Should be L2.  Fixed.


Thanks for the detailed review!


Tony


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.