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

tony.li@tony.li Sun, 21 June 2020 00: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 6D4BD3A07C0; Sat, 20 Jun 2020 17:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 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, URIBL_BLOCKED=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 wxYZHpw956Ca; Sat, 20 Jun 2020 17:12:35 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 8961A3A07BF; Sat, 20 Jun 2020 17:12:35 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id s23so6480962pfh.7; Sat, 20 Jun 2020 17:12:35 -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=M0ld3ugZFsBGw6CbxRpfYl0sdTcmtyh3GqIzf5hlYPw=; b=i0Cr+Y/mQNMq77Y9JkqfXpBcVPfeinMox7B3iW5ORsVCLZJE/rSCSMeJ9g1FaZJt5Q NggHMVXGWk59ZbqpyZATt4oj8grm6gwqY8ISqmXOmLZEp728dQ6sDQ1zBBLSxIfManlB 3JKzpgp4G7uk57Q6kcW22c1HH8LGPB3PK1h0/5DmlwGcTxWD6skQ+CdVG50vOg9YuOTv j4a/K3xLxV8ek83xiQvASoYXAmlFAlwx6U9OEv3LJSPvV7qYPlx0DUawotd8qu9xmHVm eY+xIIsOzLS1m0eUffY6/jrD097KgEiDxp4Hfi0muRnVbrsKrfODUml0stcnLhnn/6Y1 S0sA==
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=M0ld3ugZFsBGw6CbxRpfYl0sdTcmtyh3GqIzf5hlYPw=; b=BUhCPagOpqA6T8XUFBa4SrWABJPcnUiy7Do/ycBra3ypbz+RRhCoBha9Su7+YXH1GK VoDmuvUFj2OoqgVX5FZuBDMJIAUcYwU0LQbgVNJFzeOl2otXorRLiIFC5zFEjj3HEWyo 6yogQFdJgW6QylO5ef1sUGSu5VmPDzq4Hm6ofVr0O46I3C+MG7o/WimzdERbZks+ZqJc OMGyg7Ijs6Q7irYPIrQzxdGB8CcSGlegOJm5AxsQhn4RwsOXp0jp87qcdaeaOoULisJu +YNswyAxN46rvde+J74dkfp4MK7FWFVH73nKQJTDc5HYBAKsUaCIqPMVjIq8ZkIdXA6L 3c9A==
X-Gm-Message-State: AOAM532yFsSGaB2GBtn08M77G+iKv+96/euJN3sx/vN6i5t9kPvHDp9t kxWaGfkYdOxMZPcdJb/yo5M=
X-Google-Smtp-Source: ABdhPJwxVa9JDKKe4Ojew5uW58ADkWiBt2QCN9+6dwQY/bTPvxTGuYNJnaoDiEMHGpTlkwW8Rprvxw==
X-Received: by 2002:a63:fc43:: with SMTP id r3mr7961094pgk.423.1592698355027; Sat, 20 Jun 2020 17:12:35 -0700 (PDT)
Received: from [10.95.85.230] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id c8sm9314708pjn.16.2020.06.20.17.12.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2020 17:12:34 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <29A0CD92-1D33-4B06-B0CF-D17BE89A9B60@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B7E91C7C-D4C8-4577-8B44-3597CAEFD392"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 20 Jun 2020 17:12:32 -0700
In-Reply-To: <BY5PR11MB4337E58E8B775A7086281C21C1990@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> <EB07BFF9-B4AF-41BE-94F0-25E229FA25FD@tony.li> <BY5PR11MB4337E58E8B775A7086281C21C1990@BY5PR11MB4337.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Jk03aObSAwII-ce-SPOAybyQewg>
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: Sun, 21 Jun 2020 00:12:37 -0000

Hi Les,

> Putting the Inside Node TLV aside for the moment, it would seem to me to be advantageous (in a modest way) to have all information relating to Area Proxy contained in one advertisement. Using Router Capabilities TLV would accomplish that.


I agree that the information should be contained, this is why we opted to put it all into one top level TLV.  Recall that only the Area Leader is advertising the Area Proxy TLV, while all inside nodes need the capability.


> Your concern about “burdening” the Router Capabilities TLV seems unwarranted.


Given that we have 64k top level code points, I’m equally confused about your concern.


> Multiple Router Capability TLVs are allowed (indeed even required to support different flooding scopes) – so TLV space is not limited.


I expect that we will have numerous bug reports when we start to cross the TLV boundary.  I’m not in favor of pushing this.

 
> Returning to Inside Node TLV, I share your concern about advertising Router Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the Inside Node TLV in a pseudo-node LSP?


It’s a clear indication that the pseudonode is intended to be inside.


> Presumably you need some capability indicator because even on boundary circuits the DIS will use the native systemid rather than the proxy systemid and therefore you cannot tell based on pseudonode-id alone what type of circuit this is.


Correct. The DIS would have a very difficult time using the proxy systemid and assigning a unique circuit id for the pseduonode.  Some other system on the other side of the area could be making exactly the same choice, leading to a collision.  Thus, it seems simpler to use the native system id and explicitly signal that the pseudonode is inside.  I’ve become a pretty big fan of explicit signaling, as it’s more robust.


> Would this argue for advertising “this is a boundary circuit” in pseudo-node LSPs for boundary circuits rather than advertising “inside” on all inside pseudo-nodes?


You could do it that way.  It inverts the semantics and inverts the deployment.  Logically, it should have the same effect.  However, it then is seen by outside nodes.  Since they need not support Area Proxy, this seemed like a riskier approach, thus we opted for marking inside pseudonodes.


> And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P IIH as well??) as protection against improperly forming adjacencies on boundary circuits?


Not required if there is consistent configuration.  All inside nodes will be using the proxy system ID in their IIH.  If a node is inconsistently configured, then it is difficult to prevent at least one side from trying to form the adjacency.


> Regarding the Area SID advertisement, I take the point that this concept might be useful more generically, but as it is key to have the correct scope for the SID, it is hard to see how the advertisement could be used apart from the context (Area Proxy in this case). So advertising it separately doesn’t seem useful.


To me, it seems like it is a useful anycast SID anytime there is hierarchy present.  It seems somewhat useful to be able to create paths that say things a bit more abstractly: Take the path from San Francisco, through Los Angeles, Dallas, St. Louis, and then Atlanta to get to Washington. This would allow higher level TE without worrying about more specific details. This also opens up the possibility of hierarhcical TE, which we may wish to explore for the sake of scalability.

 
> Regarding consistent SRGBs, you might find https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ <https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/> worth reading as something attempting to address a similar problem. It isn’t easy.


Thank you for the pointer, I will review.

I appreciate your comments.  I wish that they had been much earlier in the process.  I will take them much more seriously if and when the document is adopted by the WG.

Tony