Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy Mon, 29 June 2020 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1A4C3A03F2; Mon, 29 Jun 2020 12:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Status: No, score=-1.497 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 vxqvJa97ex9m; Mon, 29 Jun 2020 12:51:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B31743A040F; Mon, 29 Jun 2020 12:51:43 -0700 (PDT)
Received: by with SMTP id d6so8463294pjs.3; Mon, 29 Jun 2020 12:51:43 -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=ou/mB8J1nJD2cTjDqTCMz6XurmEpoXj4mUVj4QznzpI=; b=P5i3fI3bKqWD9E+OxATB1Jjt6nZxDOx/wcgSNeMncC30j3l2gm36hIMKkwJvu8SOFQ VfY3CRMD5xRuzTDHZTeUOYQuKVwd/EPr+G2B2uxtpoyZrTaUptpk8507A9LjAuP5gIg6 tQO7QgQ7/TfcYK2a2DqmpZae0sNx/vdHPbFyCUB00WDKN4AkwXTElUrpi9IlocRe6jbo rEBe1OajSwgSX+8w0BQglD9q+rEi+G12wt7qAaPLeKXKJdfs3UrsphmhRiLMpVaC2/vT I3wB65fiOf/gqn17FOcI9rFcDPabUWUeQ8XeMFYesy+h49NCb+I6Bsan+gHSkw1CW819 rI3w==
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=ou/mB8J1nJD2cTjDqTCMz6XurmEpoXj4mUVj4QznzpI=; b=jfIA/+mHORXBTel1kqnMwcBYGxnYgCMRcvZosRU3J0u8x+y3pPNF0yFjeKRt+3FqQu cp63RfoUFHR9HG9/lVP4dny/ScB1nTHHf6etWMG6YhTKG2/cpFb44uZ2rXlNoRMLlYCg KVrbYjnT21NKQAPjGx2KLwxPHMJbg5MXq0r2YeZDzvkvpPU7ok5288VqlplrsGLUYaPO Oi1awA/UwjI40ahNobFq17e/n1MMgv3rHCn832BYBGP9alQ47FHEkvDE466PfOQp4eT5 FC2wljoIP4msneY+/XSmCgLawwbEefYhPoj4EBGESES16BLAJ67RXe5N0+jDFkgkkDN6 8yXQ==
X-Gm-Message-State: AOAM532Zal7ZTgDNYhrb+4s+8hk0r+hZipBnaCCdxAwYxbu7F63AP2ym fRYZL1y2SiOdyEWJtsvJ2H+t14pu
X-Google-Smtp-Source: ABdhPJy0NsQx/eAqzy5QPef71nIybni7F77EOGpM0syFArKHD8sG65XmiH598FGI9bCeAb4D1mRMow==
X-Received: by 2002:a17:90a:2846:: with SMTP id p6mr298280pjf.163.1593460302975; Mon, 29 Jun 2020 12:51:42 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id t1sm527476pgq.66.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 12:51:42 -0700 (PDT)
Sender: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6A489A5A-1816-43BB-830F-FB66C050C3E8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 29 Jun 2020 12:51:40 -0700
In-Reply-To: <>
Cc: Les Ginsberg <>, "" <>, "" <>
To: Hannes Gredler <>
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: Mon, 29 Jun 2020 19:51:46 -0000


The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Sarah, Vivek, Gyan, and Tony

> On Jun 25, 2020, at 12:04 PM, wrote:
> Hi Hannes,
> Thanks for your comments.  We will propose an alternate encoding.
> Tony
>> On Jun 25, 2020, at 10:47 AM, Hannes Gredler < <>> wrote:
>> Hi Tony,
>> I do share Les’ concerns on burning top-level 8-bit code point space at this point.
>> At this point it is not me to judge wether CAP TLV or GENAPP TLV or something else should be a more appropriate place.
>> Please let's have a WG discussion on this.
>> Thanks,
>> /hannes
>>> On 21.06.2020, at 18:50, <> 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?
>>>> 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
>>> <>
>>> <>