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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9538A3A0D66; Mon, 29 Jun 2020 14:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8iNukcAhWv35; Mon, 29 Jun 2020 14:37:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC90F3A0D6D; Mon, 29 Jun 2020 14:37:33 -0700 (PDT)
Received: by with SMTP id gc9so2089422pjb.2; Mon, 29 Jun 2020 14:37:33 -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=6EQ5CVgvc7FrUsJGOgvFiL0ND4BI1QDfR68lnuo7cL8=; b=WsRY4JMHdU+dP6qYfcn0tvtRD3YupygmVivchgfwPej6FQNs/IkVKskJpGefLK/Xia w9Zzqr6E8mOxzEe+5cftuCXTD/u9xRY+I9TGrG8HTivgY8Fn8v25icFawvTDa2mnC8e3 hThTX2Vlwy5MloL6qh9jLIaVFbMAaoUKR2iiAgjWKjz3Gnp7DpVDpO75BVg5AWghAqCo rBBcJGZiEI6QhiLKXclRJAut+levZ5rMs54IWpADK9aICgl2QXDqgXgtKuiHbE8DHJrH 0239wyAXbI17Hv/29vN/PHGvMrpPhOKPQIuA79FhCI4JFSsvRsn6Ip5ihIwUSgySyMzW UGpg==
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=6EQ5CVgvc7FrUsJGOgvFiL0ND4BI1QDfR68lnuo7cL8=; b=P1cTQJcu6MCtoV/x0xUGBqlXXx8wNWiMF82bPa1ZkqMCqjAd3ztBav358BHCMoXm2U gs9Jsc2XvM/M9Olcw/smTHMjIaY7rvwyqbdXlBF35/+CzeHGG22e0iywJ5GVGcTxx44O 64oYuO6kibcF/gzUeKazv52jubcQGuya0XEUHrlokeVZl3BxPzcntUvZbpsBJN3lgo3Y GD0dI9Av3liNNKwlXbIXrJVqpszlhnqFPpE5MRigS3NjOGBYynleBlnc1G5rhu8jY4wN IMAEN0udWENA0uhNeTK91Wl7syx6O37rmuaKPzeAL/bgJC9UWqVwQ7sIEWP5wZUO1fxz pDTA==
X-Gm-Message-State: AOAM532Z9TYgBqRud6dzro3xy8WJkXyXiSlDSOwKTfoCXz4+qylWs5zy O9DRH+VPahpXQDZbp3+k2hU=
X-Google-Smtp-Source: ABdhPJwEDolGlYWz4ny13G4HtfOsw2CZz4FdjxTQjCHNTIsGRlEpiJOPtAdL7h9vzC4/fLkKQfm/qw==
X-Received: by 2002:a17:90b:3c6:: with SMTP id go6mr9906853pjb.213.1593466652849; Mon, 29 Jun 2020 14:37:32 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id u8sm523155pfh.215.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 14:37:32 -0700 (PDT)
Sender: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9978FD0-23C2-4283-B26B-5252D38F886B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 29 Jun 2020 14:37:28 -0700
In-Reply-To: <>
Cc: Hannes Gredler <>, "" <>, "" <>
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: Mon, 29 Jun 2020 21:37:36 -0000

Hi Les,

> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) <> wrote:
> Tony –
> OLD:
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
> 2)Inside Node TLV - Top level TLV
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>    Sub-TLV Area Proxy System ID
>    Sub-TLV Area Segment SID
> 4)Area Segment SID - Top Level TLV
> NEW: (Please check my interpretation)
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
> 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>    Sub-TLV Area Proxy System ID
>    Sub-TLV Area Segment SID
>    Sub-TLV Inside Node ???
> 3)Area Segment SID - Top Level TLV
> Am I correct so far??

Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.

> If so, a couple more comments/suggestions:
> a)Could the Area Proxy TLV become a bit more generic and allow advertisement of the capability (implied by presence of the TLV)?
> If  so, the Router Capability sub-TLV could go away.

Speaking just for myself, ok, that seems reasonable and doable.

> b)If the Area Segment SID is (as you suggest) a generic thing not specific to Area Proxy, then I would point you to <>

?  Your pointer is to the flags field of the SID/Label Binding TLV.

> This allows SIDs to be advertised in the SID Binding TLV for a special purpose (see the Mirror SID). One could imagine another flag bit to indicate this is an Area SID.

You’re suggesting a bit in the flags, the range would be unused, and a prefix length of 0? Then the actual SID would be in the SID/Label sub-TLV?

> I think this would need to be vetted with SR  folks

That will happen, regardless of how we proceed.

> – but I would like to avoid advertising a SID in a way different from all other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), or Binding SID (Mirror SID).

We were trying to extend the current design consistently with existing SIDs.  As the Prefix SID and Adjacency SID were top level, it made sense to continue that approach.  The approach of the Binding SID TLV would seem to mix all semantics into one encoding and seems inconsistent and complicated with respect to the other SIDs.  If this was the intent, shouldn’t prefix and adjacency SIDs be encoded in this TLV as well?

There’s only three available bits (plus one octet) here.  Aren’t we concerned about running out of bits if we go this direction?