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

Tony Li <tony1athome@gmail.com> Wed, 05 August 2020 23:25 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 9163F3A0912 for <lsr@ietfa.amsl.com>; Wed, 5 Aug 2020 16:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 tK5_D5Q-Z_QS for <lsr@ietfa.amsl.com>; Wed, 5 Aug 2020 16:25:47 -0700 (PDT)
Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 44D383A090D for <lsr@ietf.org>; Wed, 5 Aug 2020 16:25:47 -0700 (PDT)
Received: by mail-pl1-x644.google.com with SMTP id bh1so13434389plb.12 for <lsr@ietf.org>; Wed, 05 Aug 2020 16:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DoTGf2ERfSUoA6iaW6VhePGrS5z+6MtagflzMZgFW70=; b=UE0mrJZ1j8jadx9dyA97pLTKjXVEDWg46xvTpe53wDpLpNV63sAZJHijC8tCvrcCr9 Y64jnpOZWSPRPXfVUdID8PSIn/763pXe7VeeC/5RBv15Qs5+eMDQn3/D4ldQr3xwQeDo QD1t2QdoL+ZUmfrZ26+mO67hzea9Q42qJyfe0i5VBs83yvVNsqLvtAWRLF1oytOye5UK kdf/szeqim4FM3KdDEAk5VUkklGzhzn7hiFCvrYQgo/foVm4UNz/jRFfovAYe679R84+ 13QdQEaleCCSzlwOc8I/oLsayQC3ir3K2c6cujlE4CIUmnztOQH+t65EqznRjQCb57SE GAAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DoTGf2ERfSUoA6iaW6VhePGrS5z+6MtagflzMZgFW70=; b=kWkUnqCGZWr0m4y5uXGVWeRJgN0skKxeADL4zfXEayvZ4UOuDbswzr1g1ookhkEcs8 WMNCFbuuXzpjYgIWK5X7la0i5X0K/oayKonJncFozF4QXQccPUdJq7TKYPixGZF4X9Y5 sdrHMRB2socvcWzExlcgLNhC0n3mggQEC3Xssd8Fc92WY9uGX9eHrMhJOvOuKWP/1Wqo 2TBtY0sPQUBxsZh9ai13q6omJaNowD1kH+/mQ4tiPtgrOSTNmRNbU0Vl+pmmiCEQXm1h NlGKyGf0xetAb1AJHNW5M32UgJNVEHqHSvzIAm1N2b9eBWB3pnYk+R7wZEBXL/hLmY/g RCSQ==
X-Gm-Message-State: AOAM532P6WWe9b+2yjUwM9ZnPuj2N+zPHdFYru8WK1IKnPjvQ86O2CCu GQfEB1tXVCnGDVvNZsFnMFo=
X-Google-Smtp-Source: ABdhPJzJwBIarkzxhXuQgOStSHKXGj4KiOv18eeDnCDc2TKwk9yAI2Rq3GSHBmHExG/AvTewDl7e2Q==
X-Received: by 2002:a17:90a:2224:: with SMTP id c33mr5366112pje.56.1596669946696; Wed, 05 Aug 2020 16:25:46 -0700 (PDT)
Received: from [10.95.80.202] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id m22sm4286170pja.36.2020.08.05.16.25.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2020 16:25:45 -0700 (PDT)
From: Tony Li <tony1athome@gmail.com>
Message-Id: <2F899EBA-A1F2-4CC5-926C-7215A861E5D7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7170E10-E0CA-4200-B00B-38324499E440"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Wed, 05 Aug 2020 16:25:43 -0700
In-Reply-To: <BY5PR11MB4337E1A347464FAD04591D97C14B0@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Bruno Decraene <bruno.decraene@orange.com>, "lsr@ietf.org" <lsr@ietf.org>
To: Les Ginsberg <ginsberg@cisco.com>
References: <32323_1596545126_5F295866_32323_118_1_53C29892C857584299CBF5D05346208A48F0BB30@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <BY5PR11MB43375CB413060250B336BE64C14A0@BY5PR11MB4337.namprd11.prod.outlook.com> <4558_1596554251_5F297C0B_4558_298_1_53C29892C857584299CBF5D05346208A48F0C59B@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <95A83DB0-A58C-4BD5-AF0B-8EF49D20EB3A@gmail.com> <89F6F8E5-E11D-4A6E-A783-8C9384FE3A1A@cisco.com> <BY5PR11MB4337DB5B017781522AAF9E66C14B0@BY5PR11MB4337.namprd11.prod.outlook.com> <824DFF9C-56E4-4E4F-A249-2E9413D85CC4@gmail.com> <BY5PR11MB4337E1A347464FAD04591D97C14B0@BY5PR11MB4337.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/8kL9FEOhKfhdVVjIkSkW-WeDEog>
Subject: Re: [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: Wed, 05 Aug 2020 23:25:50 -0000

Les,

> This would make the Area Prefix mandatory for Area Proxy, which is not desired.  We would prefer it to remain optional and thus part of the Area SID sub-TLV.
>  
> [Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as you did with the Area SID. That is what I expected you would do.


Good.  I’ve just submitted -03, which does exactly that.  Please review.  Note that tools.ietf.org <http://tools.ietf.org/> appears to be down at this instant. (!!!!??!?!?!)


> b)The remaining info (reachability and SID) can then be provided using existing Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. This eliminates any potential issues if the SID advertised by “Area SID sub-TLV” were to differ from the SID advertised in Prefix Reachability for the same prefix.
>  
>  
> As we discussed privately, we view this as a non-issue.  The Area Leader is the one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a coding error, there’s a coding error. There is a single source of truth (the Area Leader’s config) and we cannot protect against every possible coding error.  Reconciling the prefix with a separate advertisement has a non-trivial chance of being broken too, and IMHO, much larger.
>  
> [Les2:] You can define the advertisements in a way which reduces the possibility of ambiguity – which seems like a good thing to me.
> And rest assured that you will be asked by someone to define the expected behavior when there is an inconsistency. 😊


Same question: same answer. :-)


> Since prefix SID and Prefix reachability are directly related in forwarding, it makes far more sense to me to have those two together.
> If you find correlating information in two different TLVs too challenging, you could opt for a new bit in the prefix attributes sub-TLV to identify a prefix as an “Area Prefix”. Then you would not need any additional info advertised in the Area Proxy TLV at all.


We prefer to keep it in the Area Proxy TLV so that its semantics are crystal clear.

>  There then remains the question as to whether the “Area Prefix” is anycast or unicast i.e., is it common to all IERs or is it unique to whomever gets elected Area Leader?
>   
> Does it matter? We have no clear semantics for this prefix. A difference that makes no difference is no difference.
>  
> [Les:] This question needs to be directed at those who prefer the Area Prefix approach. It matters as it impacts configuration and advertisement semantics. An anycast prefix is NOT a Node Prefix.
> And it impacts how traffic is forwarded into the area.
>  


How so?  Traffic will be directed to the SID value (modulo PHP). 

Tony