Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

tony.li@tony.li Wed, 08 July 2020 18:12 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 936783A0769 for <lsr@ietfa.amsl.com>; Wed, 8 Jul 2020 11:12:13 -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, 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 ZEaMnM8LKVRx for <lsr@ietfa.amsl.com>; Wed, 8 Jul 2020 11:12:12 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 49B6B3A05A0 for <lsr@ietf.org>; Wed, 8 Jul 2020 11:12:12 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id ls15so892157pjb.1 for <lsr@ietf.org>; Wed, 08 Jul 2020 11:12:12 -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=P4X016ixOcH/WqGMXJ00tCrOJPdpn64WiCGstD606dI=; b=YhEiZcJojwTK2aJesR4ouFHnLSwLzDgYphDlMxqkPBC4j6Fc2Xu/271XRsA9p1g4OH l8PGlz6L3CBRnnIb8NHB4rkP+XBADGh91KMSZkahbYQD4sU4pDugzYEcgm66HF8ymL56 jlJbxKG2dSBVCRHOimjFbXXPswDErCYJzQJcf8wmdHKs7RFxNUzHxkz+t4L+p3H7e2MD f73e1mYzhACPjGfszgRs68pUPt/QxSW8RqKF27QXNg48kLtOlVUQI306x4dgGo7+qFxa XO0erFkNhKt1l3IVajYIZd+OzWjCfGXcb19zyrkLuB+51JyIGCt2iNhZwtcumyr8es1l hJWw==
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=P4X016ixOcH/WqGMXJ00tCrOJPdpn64WiCGstD606dI=; b=Sjx15NoZsQ217zXYsoWOFlQllXuVOow2Pq4S9F80FnQThCvBzAcMQPcnKWi/CzcKl5 eOkOwo1F04OBck5it7At9HZxzuHDRjzM44KYHUWNVq1IB70FMxcu6S5hF+6PFt+qANdU 1c6ORVx9nUocCupg9W5uXgZmTTXdMphgslG6cuqfhO2iH5ji9Qq9GSVSNlSq1UaDrHak 6Hyk9EdlFdNbEbwTAyJ23ns3rALl2yWOFBtnmBU6BTXFdyYDGmqt8hMvVTbwIoQAjPvw i3YvGggfD1bMiSOz3uRSNyR4Bpn1WW9+LBMywy4t0UiNI6SPNU2Fyul2g79/Zxqhp3Vx WLoQ==
X-Gm-Message-State: AOAM533TD/SHasHRuXvXWisg4h2OoSxP1ZWsZ/qi+oVZqBTA30asA/Iy lTV/xAQeielcSNLkyHft0CY=
X-Google-Smtp-Source: ABdhPJz+F1VzewdJRuu+CalidBs5onk0MIwxR2RJpbQytek7eoPv5knS+c0MojC0Z5LxEt0Q+2dngA==
X-Received: by 2002:a17:902:9689:: with SMTP id n9mr25586066plp.160.1594231931251; Wed, 08 Jul 2020 11:12:11 -0700 (PDT)
Received: from [10.95.80.3] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id j11sm453566pfn.38.2020.07.08.11.12.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 11:12:10 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <58583156-3E21-4CBF-9842-23E9ECF6B05F@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0278C6F7-4B03-4760-AC70-74FAEC56BFF6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 08 Jul 2020 11:12:08 -0700
In-Reply-To: <BY5PR11MB433793CA15945C7DEE929D3CC1670@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
To: Les Ginsberg <ginsberg@cisco.com>
References: <159413489833.5281.16624960404974015532@ietfa.amsl.com> <BA0B8614-4F8C-46D0-B494-E0A8C7ED9E47@tony.li> <MN2PR11MB4352D858C40388E04A534C83C1670@MN2PR11MB4352.namprd11.prod.outlook.com> <2C44E16A-E7D1-4092-8454-5CE066A2F4B9@tony.li> <BY5PR11MB433793CA15945C7DEE929D3CC1670@BY5PR11MB4337.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ipIZLgTJbkahMoSeUHsbwCHRwIc>
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.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: Wed, 08 Jul 2020 18:12:14 -0000

Hi Les,


> Again, the subTLVs of the area proxy TLV are for the coordination of the Inside Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.
>  
> The Proxy LSP is for informing the Outside Area.
>  
> [Les:] Understood – but I do not see why this requires you to advertise the SID in two different TLVs. As you allow the Binding SID TLVs to be advertised in both standard LSPs and Proxy LSPs, there seems to be no need for two different TLVs to include the advertisement.
> ??


The semantics are completely different. Advertising it in the Binding TLV is permission to use the SID for packet forwarding.

The advertisement in the Area Proxy LSP is to instruct the Inside Nodes to use that SID to establish the forwarding state.  


> [Les:] Yes – of course – this is pathological. (Probably not hilarious to the customer. 😊 )


No doubt, but I’ve found that if one doesn’t regard bugs with some humor, our profession would be morose, in the extreme.


> I am just saying by having two sources for the advertisement you introduce the possibility of inconsistency – and the spec would have to speak to this – even if it should not happen.


Ummm…. Not sure what I can say other than “don’t write bugs”.  But ok, I’ll happily do so.


> We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s not what we’re doing, so it’s not too surprising that there’s some conflicts.
>  
> [Les:] Yes – the Binding TLV has some issues being generalized. There is history here as to why the format is the way it is and why it isn’t more easily extensible – and that is open for discussion AFAIAC, but we cannot break backwards compatibility for SR.


Agreed, trying not to. :-)


> But I am also responding (in part) to your desire to make the Area Segment SID a more general tool – usable outside of Area Proxy – which seems like a good goal.


And you’ve requested that we put the Area Segment SID in the Binding TLV.  I’ve tried to do so and you don’t like how I’ve done it.  Please tell me what I can do that will satisfy you.  From what you’ve said so far, there is no legal way to use the Binding TLV.

Catch-22.  Yossarian!

Regards,
Tony