Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy Sun, 21 June 2020 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1931E3A0028; Sun, 21 Jun 2020 09:50:10 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GsnBlROb_FmY; Sun, 21 Jun 2020 09:50:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A29F3A0E0B; Sun, 21 Jun 2020 09:50:08 -0700 (PDT)
Received: by with SMTP id u14so1554865pjj.2; Sun, 21 Jun 2020 09:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sZi7AWFh72fkDg3pa+BvryATMH6dbcv/M1blIiTpRT0=; b=kMk9yzy3qahWKdvXPG0Rgdz/DUv2oOOGlZ/Up3VlgJxQ3Ut8WqBsxPP77wP/9tJDFc zQx0ZbItgT9SVUmyLPM7jUqqcvEaQsBh6rK6FgcB8SIxi5SAt4dipjt66Nk9aK9pZ7JQ x7PoycFSTQXW0RjCfX0ZEj8hFlWqvyLBbSO79pmQcMEkGQD71+OsIACXcSaB7qOQC+7Z ljcYg73mQ52OxbSt25Q9X7g8UfTZMcmI+zL/QdauXFCE+vivxWS3ahDLyysn0eQODV4s 9SUL7M0NekByh8KfC+0C+D9i0x5Z6rousk/hkbPf3R5RGJ3m0a/T6LcXdYegymtpFohQ I9GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sZi7AWFh72fkDg3pa+BvryATMH6dbcv/M1blIiTpRT0=; b=JgpXGqMjDpUovKDaaSpkEOw4Yq1VeIQyr3RNuuII9xlz/Sj2V+vP5Xo7EqYSx816UB 2oLVgh4hBB5/gGilqYB/kT9Et8oklPv6yo4OYHVJi9gMbhWn8LbcpWRJGbafTBZLvNMO ag3MQJ7yX+0z+6Jixg1emfXkcWNTJPk3KBVq95LOYKXFOnqazAOU4v2ZuwYmbFb1cIHd jArrFzFuZTsE3Pe3mW1I8LXILYxWlqMxcqwsEE0p1tBqWSqSRI+G5hyKA+sYuVRLkrLn 25Wcq5opFF6IQEcVP6ge0ld1mHdrF5kF9PzCU3cLRTHpVtLFMje06SgVR9rd4QiYsOQw +jdA==
X-Gm-Message-State: AOAM530BOzhD471g7gDfq9lf0Fu0BABTAiUn2wjSPenlaoMM5HbmJu2j R2t8m+xwim10x7baOU96YwY=
X-Google-Smtp-Source: ABdhPJwIqmsLI8ljTt3KKysspbu8InIbaNvG0OWZMj31LM1nMJE2MWV/yuL0PZUJeb75SstQ4B0CSA==
X-Received: by 2002:a17:902:7247:: with SMTP id c7mr16548194pll.103.1592758207938; Sun, 21 Jun 2020 09:50:07 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id hi19sm11070173pjb.49.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2020 09:50:06 -0700 (PDT)
Sender: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_34778A5B-8B08-41CC-980D-4B0BA9ADEFE3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sun, 21 Jun 2020 09:50:05 -0700
In-Reply-To: <>
Cc: "" <>, "" <>
To: Les Ginsberg <>
References: <> <> <> <> <>
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: Sun, 21 Jun 2020 16:50:10 -0000


> 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?

> 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.