[Lsr] draft-ietf-lsr-isis-area-proxy-02

bruno.decraene@orange.com Thu, 30 July 2020 16:45 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 8722C3A0B45 for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 09:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QgBtJ1--qPBY for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 09:45:57 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0C63A0B34 for <lsr@ietf.org>; Thu, 30 Jul 2020 09:45:57 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4BHbrg56Wrz30Fd for <lsr@ietf.org>; Thu, 30 Jul 2020 18:45:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596127555; bh=9sBRpLQlD5ODj5LQ+Cc03nsBhUKn6/64sM66xIOy7e0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=YzVD8u6as9TfW1iWbPEKjRgEStjF09QbgS61r25HAoRxEJJ+5BgZXcNxyYbFHLrIA jCLTVIvfPd0lis5WyFv+svZR0S2UrjKHveuUnCSSiOepCxI+KBBUwKlDNV2lAxI6V9 Aj1ORDLeU0eUWs1qLNHbKMbp69SEIltqs21RMrP50h6avHSmmvcFv0yk3s/5MhMosI 5yTEi1BxlGNjSrUoO0s0zBOhGPCDIvJAsC4i7GzW9e9Y7aj94bYgmtORFjZTRRG65D 6eTht9HOKCH7ygBJsOInrO6D7he+teW5D16h+I9fL9UYaLfzR57TShyoiuyC8mrhr7 iHxouNRSykLzA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4BHbrg4DlQz2xCC for <lsr@ietf.org>; Thu, 30 Jul 2020 18:45:55 +0200 (CEST)
From: bruno.decraene@orange.com
To: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: draft-ietf-lsr-isis-area-proxy-02
Thread-Index: AdZmjc89KP8vS0zORxmjtu3Zfqw4mQ==
Date: Thu, 30 Jul 2020 16:45:54 +0000
Message-ID: <1656_1596127555_5F22F943_1656_24_1_53C29892C857584299CBF5D05346208A48F03919@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48F03919OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/EsorDrJTXWD1Euob_nmULvT73uE>
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02
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: Thu, 30 Jul 2020 16:46:00 -0000

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

      A new flag is defined:

         T-flag: The SID directs traffic to an area.  (Bit 5)

         When T-flag is set:

            M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside edge routers. Based on this, I would argue that the  A flag could and SHOULD be set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) [RFC8667<https://tools.ietf.org/html/rfc8667>], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the behaviour for respectively Prefix-SID propagation and P and E flags handling, so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a reachability advertisement originated by another IS-IS speaker, the router MUST set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best regards,
--Bruno


_________________________________________________________________________________________________________________________

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.