Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy Thu, 25 June 2020 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21A153A0C47; Thu, 25 Jun 2020 09:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8qUbDfQQzjMz; Thu, 25 Jun 2020 09:36:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B25603A0C39; Thu, 25 Jun 2020 09:36:17 -0700 (PDT)
Received: by with SMTP id 207so3074457pfu.3; Thu, 25 Jun 2020 09:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kuCDomZ/Ld9gdEFRKyAKakF5fMc0sqMvoUOYlwHELGE=; b=jvPYYXJwgHCtx5R/LZb5row7crqF4ey1AJovcxoMEmRospjdmVkzsYHq0H8SrT6laT FUvTsBIFIR5RIpnRBx4eWr9IdlPMe1BDQuwds4/k7h5CohEsjpx0SslSQ8JRF1LZjdGe 6nB7ib+uMajLmoN1y3zl5rDGcz6K7bOFao7tWVpqoiV3mSJSAYc40SAEQLvAKAipqhnJ mcAyTsqj0x030hkeT0kURR5Llij0lajCk3CzyBKdC8qVsCV6jepdF9jeLYfHUbFV8unY Ag79QTfedhl7eDZs5Q7ps9Qqu5bw7DPdCMKM+fAUG9D8tLmIwF6zR9LCZMHlSh1HMUxv dNmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=kuCDomZ/Ld9gdEFRKyAKakF5fMc0sqMvoUOYlwHELGE=; b=c+ZwpptYrPZZDQAcZjl80mtVduloauQH5MGW56SEGfidOopYnRoSAtxcryL8xn1HDx K8WkCfbDadAm0jHcNM1ADcImP7rSjCoWWwsDmdB/510ivpMhV78W3PbXnO8uYwa5Kvug Gv/dyaK5v59+5mKhIDpKPi2x/VhJWC96wAw1awTUzjF5xRo8J8HRTe1cF1KsVx3Gxcmw A541b2JyIwd3O2F8hTRT8+qNElkbQR1mW5DfQOQ+kcTASxxEAJEK/lamU19XcjruxpNA Yp79OzGYhLFyv+Xft3GfJUrECKtQyEMF8xSm6DWLtMgmFTDWCIM+JzozyKkYLGS3Bt8T GAOg==
X-Gm-Message-State: AOAM533bzp4Rhr3Wsh67G7MJXzzdsVBF2aTTDNiLm6t//KyncBYp+eNc Ux82ItvLT8vjl4SXI8S+dsI=
X-Google-Smtp-Source: ABdhPJyOnfpTta+uH6Adi1Gdn8zf6FejIYqaHEdotkuJAxN6b4vDU2gC0BDhC58Cq04KNOMVt916Mg==
X-Received: by 2002:a63:1617:: with SMTP id w23mr27414448pgl.248.1593102977161; Thu, 25 Jun 2020 09:36:17 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id b19sm22942632pft.74.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 09:36:16 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
In-Reply-To: <>
Date: Thu, 25 Jun 2020 09:36:15 -0700
Cc: Les Ginsberg <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Christian Hopps <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jun 2020 16:36:19 -0000


Thank you for your comments.  We will figure out how we would like to proceed.


> On Jun 24, 2020, at 5:17 PM, Christian Hopps <> wrote:
>> On Jun 21, 2020, at 12:50 PM, wrote:
>> Les,
>>> We don’t have to resolve this now.
>>> One of my motivations for sending this was related to Early Allocation of code points. Since you have already asked once, I am assuming that if WG adoption is achieved it will be swiftly followed by an early allocation request – and as one of the Designated Experts I wanted to share my concerns sooner rather than later.
>> I appreciate that.  Do others share Les’ perspective on the relative tradeoffs?  Especially our other Desginated Experts?
> [Designated Expert hat]
> I agree that we should try and reduce the number of top-level TLV allocations being made here.
> [WG member hat]
> I think using router capabilities to eliminate the Area Proxy TLV is one choice, and you shouldn't be afraid of storing some capability related extra octets in it, plenty of other users do this already.
> However, if you're still going to need a top-level TLV for "Inside Node" (perhaps b/c we fear using a Router Capability TLVs in pseudo-node?), then why not create a single top level "Area Proxy TLV" for all Area Proxy uses (i.e., make the current "Area Proxy TLV" and "Inside Node TLV" sub-TLVs of that top-level container) instead?
> Thanks,
> Chris.
> [see above for hats]
>>> 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.
>>> [Les:] My point was largely motivated by the statement in the draft:
>>> “Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
>>>   mode) with multiple Inside Edge Routers on them are not supported.”
>>> So it seems advantageous to be able to prevent this from happening – which requires some signaling on the circuit in question.
>> I think that the case that you’re concerned about is already easily detected.  Recall that an Inside Edge router will generate IIH’s onto a boundary circuit using the Proxy system ID.  Thus, if an Inside Edge router receives an IIH with a source address of it’s own proxy system id, then it has encountered this issue.
>> Tony
>> _______________________________________________
>> Lsr mailing list