Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

tony.li@tony.li Sat, 20 June 2020 20:41 UTC

Return-Path: <tony1athome@gmail.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 3B0B63A096A; Sat, 20 Jun 2020 13:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 p-gd_PhCV-rZ; Sat, 20 Jun 2020 13:41:30 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2071D3A0969; Sat, 20 Jun 2020 13:41:27 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id x11so5612324plo.7; Sat, 20 Jun 2020 13:41:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2TEVPYf/VhUkrKYNUe6Ks6XPk6WO4MQKsV91X/tU3Ms=; b=q3QFAAJpCLtCduta13jEzeaUdiGntK4qXSyVEzqij16EYZVo4kKsCatCi7lxgnakt6 O18bm+u63W93Gu3kdhzs199W8I5P3RhU3/njBF5JTAbZPqj6JUKODexVdmoAAIKrsU9l RXV8ydx1BD93aF8kzmNLf0Adz5LgYV2yMI+c6kCNKb4pjW2EPUzBax1dfc14H/ZqFsFg wH1DYRvp0S3um83HnpYE8adbTTpp7ZUHTZei7siojE0jxifNzqgLMRFnkH233T74C2Dz MIFndDGvXPz7M2c3Lp3f7mPqseDa1rmLjaAqYvntkIStJkPE/RMfaTiP7xSgiq0Bz9rh C8Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2TEVPYf/VhUkrKYNUe6Ks6XPk6WO4MQKsV91X/tU3Ms=; b=KBh+ZdNXsILifXLifnS6rPK88fNw+SVre/sKFQEdokIaKkzdlE8usUBtJ8H5GyVhYT Fgvq/KpB2Q2beECEGsLvVITc9K64AovoDh+W3xYthIEfFTj0qWtmYzdTSYrhfAtbrULR GpX77qJn6mQuCEOpyI7JFcnUYFFP6mUcgYG/RuUDFshI1IeTnSmvPwKWFKmqYtmqy7tk 1WBYXrCVfD49OB7ElXhXKx0UGopSVpPI8q5RJPcN4iIYD5vn6x9HJ8Ac7/OtKmvi6AU6 NDHpwWYL0pJ7vRiqeneG+6ZzecOxASJetNDbnBXw2oAfTw2tYzXCc92CUXp7gOsI+iqp PQjw==
X-Gm-Message-State: AOAM531OXWlnEhvfkXp1B5hQXo5tNB/t4g4nRMWMmKxfa2Z9PPxaPb2y +b6PILxLWN3fUgvS1cs1If/Cm01+
X-Google-Smtp-Source: ABdhPJzXlzPEKWY33wJm4zbhD8UuAutb4cqWWd8MfBfOBoujN9tisq8zX6XGDHDrj/c23WybVEteGQ==
X-Received: by 2002:a17:902:c082:: with SMTP id j2mr13473094pld.175.1592685686503; Sat, 20 Jun 2020 13:41:26 -0700 (PDT)
Received: from [10.95.85.230] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id d6sm9057669pjh.5.2020.06.20.13.41.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2020 13:41:25 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <EB07BFF9-B4AF-41BE-94F0-25E229FA25FD@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C9B873E8-B239-4F01-9BE2-EC13D3E8B690"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 20 Jun 2020 13:41:24 -0700
In-Reply-To: <BY5PR11MB4337892CA6ADFD4F2E9B653FC1990@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: "draft-li-lsr-isis-area-proxy.authors@ietf.org" <draft-li-lsr-isis-area-proxy.authors@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
To: Les Ginsberg <ginsberg@cisco.com>
References: <BY5PR11MB4337892CA6ADFD4F2E9B653FC1990@BY5PR11MB4337.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/cEs5fK22EiK_I__shzl95fQRd8M>
Subject: Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy
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: Sat, 20 Jun 2020 20:41:36 -0000

Hi Les,

Thank you for your comments.  Please see my comments inline.

 
> draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new sub-TLV of Router Capabilities TLV and three new top level TLVs


It should probably be noted that the Area Segment SID is somewhat orthogonal to the rest of Area Proxy.   It could be conceivably be used without
Area Proxy, or with another solution.

It would not be unreasonable to consider the Area Segment SID to be a proposal logically independent of Area Proxy.  Thus, Area Proxy really is requesting two new top level TLVs.
 

> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Inside Node TLV - Top level TLV
>  
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>    Sub-TLV Area Proxy System ID
>    Sub-TLV Area Segment SID
>  
> 4)Area Segment SID - Top Level TLV
>  
>  
> Comments:
> This seems unnecessarily profligate in its consumption of top level TLV code points – something to which, as a Designated Expert for the IS-IS registries,  I pay close attention.
> I can imagine an alternative encoding which utilizes a single sub-TLV within the Router Capabilities TLV:
>  
> Area Proxy Router Capability sub-TLV
>  
>   Type: TBD
>   Length: Variable
>   Value: Flags + Optional sub-TLVs
>   
> 1 octet of Flags:
>  
>       0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+
>       |I|L|P| RSVD  |
>       +-+-+-+-+-+-+-+
>  
> I If set indicates Inside Node
> L If set indicates capable of performing Area Leader functions
> P If set indicates Proxy LSP advertisement
> RSVD - for future allocation
>  
> Followed by optional sub-sub-TLVs
>  
> Sub-sub-TLV Area Proxy System ID
> Sub-sub-TLV Area SID (Used only when P bit is set)
>  
> Please comment on this alternative.


One of the issues that drove us to introduce the Inside Node TLV was confusion about pseudonodes.  How does a node determine whether a pseudonode is Inside or Outside?  This is an important at flooding time because if it is Inside, it should be flooded externally.  We did not consider putting a router capability TLV into a pseudonode and opted for another top level TLV instead.

We chose to make the Area Proxy TLV a top level TLV because we felt that it was inappropriate to burden the Router Capabilities TLV with arbitrary amounts of additional data. In our humble opinion, the router capabilities TLV should be reserved for capabilities.  Yes, it’s true, we could put that data inside of the router capabilities TLV, but as we learned a long time ago with GUP, we can pretty much put anything anywhere. Just because we can doesn’t mean that we should.


> Additional Questions: 
> It is not clear to me why Area SID requires two different advertisements :
> 1)As a sub-TLV of Area Proxy TLV and
> 2)As a top Level TLV in the Proxy LSP
> Is it because you wanted a unique codepoint for the Proxy LSP advertisements?


We wanted the sub-TLV so that the Area Leader can distribute the value to all of the Inside Edge Nodes.

We wanted the top level TLV so that it could be distributed to the Outside area.


> There is a statement regarding the SR Capabilities sub-TLV advertised by the Area Leader as having:
>  
>    "an SRGB identical to that advertised by all Inside Routers"
>  
> SR does not require all nodes to advertise identical SRGBs. Are you imposing
> a new requirement in order to support SR and Area Proxy together? If so, what happens if all Inside Nodes do NOT advertise identical SRGBs?


Yes, that is a requirement that we are imposing and it applies to the Inside Nodes, and possibly only to the Inside Edge Nodes.  More thought from SR experts would be welcome here.  

I disclaim all expertise in SR. :-)

The concern here is that the SID value advertised in the Area Segment SID TLV be interpreted identically by inside and outside nodes. If the SID is an index and the SRGBs are not identical, then there would be some inconsistency between how the inside and inside nodes would interpret the SID.  Thus, mismatched SRGBs is a misconfiguration.

Regards,
Tony