Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Robert Raszuk <robert@raszuk.net> Mon, 03 August 2020 18:14 UTC

Return-Path: <robert@raszuk.net>
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 4F9DD3A104E for <lsr@ietfa.amsl.com>; Mon, 3 Aug 2020 11:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 KY-ocOFXsNgX for <lsr@ietfa.amsl.com>; Mon, 3 Aug 2020 11:14:24 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 9F91B3A07F8 for <lsr@ietf.org>; Mon, 3 Aug 2020 11:14:23 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id kq25so26671565ejb.3 for <lsr@ietf.org>; Mon, 03 Aug 2020 11:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x8U/MKQ8rXw48DoxbXz1etk2YDT1TQKIdNwiyerHgM0=; b=MJ+t1DQte28+z1e2P6Tjj6NtsTqB8ANooG2bd5GotglOmYKiMkUU0oeEAKO9taWwGN dpRoq6y5KrUR9l/delMsvhfWF98usVU3RzjmnyQ9+6aFLsrOalnY3FGNbv0oX6iICQ2w cKytTz23I2EOIrrn2JC7rA5LVuoO9ROQIurVIH57A25BAQi81XI9FJb+JeSSfv8DpGrR +md4Pfwtwp7HPaXUXoLMKhyhIbjJ871byUYDSkizZdyCfpl9qCUvw++xEQGGExqvYd18 avOlCzWyRR1Wd/gJ4VgiF6DufGctfOqpEf8CUPqLesgUsr8APhZl831XPdZz3x5N2a0E ahqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x8U/MKQ8rXw48DoxbXz1etk2YDT1TQKIdNwiyerHgM0=; b=rGs40E6CtoFsG+aq1kA1VG/E17YcakUVIufYHpfCkBUucETaYTCn2CouqUewH8pn16 oVdXw5810ptw6rDTJ+/fIXHsVGj3dZRrLYSbyaWEDGXTEVEbbqGZZ1lftqf1INdXpyta ULPYGyF0LlddNRmdoxYMedItSSqKzTW6nTBCYpH1nDTwMr9pSiBZLkOj12DWoa/24Q+g MXiuuTlnt2otAF4jTLVfeDlDT2qPz82aN1GL5f1DnA2j8NklNnZvdaBjm9u/bhPQp4wV k0RTPKcDSC7eBPVErZTUjD1A/+qQ31ycmWuYpMojIg4k9NDpGZGxFdLvDMF1FC48Xi4Z ytzg==
X-Gm-Message-State: AOAM532Av1uRKYavDVgQIL7k/8Q2XGinw3JODARQw4UFJyBx/pG00G7B T947esatFS/Dtap5sRAEjZ+Hp0bBp6t0thvxmECNBGS9LqU=
X-Google-Smtp-Source: ABdhPJwVp+R3PVm4R/MEjk5Ko1rMXTNFJvBBPvKHK2OzMzKuQc4xXyqI5hVozF4HtoSm8EDoBZbGggh5XfdXusbfOPE=
X-Received: by 2002:a17:906:7104:: with SMTP id x4mr18820377ejj.417.1596478461967; Mon, 03 Aug 2020 11:14:21 -0700 (PDT)
MIME-Version: 1.0
References: <159572796513.12445.6949559311624487038@ietfa.amsl.com> <5527A777-4FBC-4EA6-8284-E7771DE2E733@tony.li> <23641_1596126124_5F22F3AC_23641_95_1_53C29892C857584299CBF5D05346208A48F03814@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <DE06DEED-B9DE-405C-B074-F79D8D56D2A6@tony.li> <8689_1596187448_5F23E338_8689_312_1_53C29892C857584299CBF5D05346208A48F05036@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <F5A06FBF-8AD7-4DFC-BE08-4B25BA5E6422@tony.li> <29827_1596442221_5F27C66D_29827_84_1_53C29892C857584299CBF5D05346208A48F0974E@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <BY5PR11MB4337B7B33953B54812C8A5A8C14D0@BY5PR11MB4337.namprd11.prod.outlook.com> <20913_1596469945_5F2832B9_20913_328_1_53C29892C857584299CBF5D05346208A48F0A516@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <BY5PR11MB43374490A51445C095995E22C14D0@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMG0kvnCTrbAeiEVRTuC9dSQFnoZxHvHsr+aQx3Oz3-JcA@mail.gmail.com> <BY5PR11MB43375613B6D583293B4B2D5FC14D0@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMGxFfCZWqhq=GTJq2yg9O4VTrNYB=SZLFyR60SH1_bR-g@mail.gmail.com> <BY5PR11MB43373313D18BA1116F8F0B43C14D0@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43373313D18BA1116F8F0B43C14D0@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 03 Aug 2020 20:14:11 +0200
Message-ID: <CAOj+MMHccT48MkGwHWVbtD23YAWrL2sRFXS2hpRrP=gQUEd2QQ@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "tony.li@tony.li" <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009e18f005abfd1b8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/m4zVneSvjpElYReq0Cws7OSRbI4>
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
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: Mon, 03 Aug 2020 18:14:25 -0000

Les,

>  You need to allow that not everything in the world is identified by an
IP/IPv6 address.

Thought we are talking about WAN networks here and not about the world :)

>  assign a common anycast address on all nodes.

First not all nodes need to participate here. At most ABRs.

Then if you already have a summary route from a given area - you do not
need to invent anything else - area summary routes are effectively area
prefixes. And in fact last time I checked routable too.

>  I can associate the SID with an identifier

Do you ping SID or IP address ?

Maybe time for examples.

What would be your MPLS area SID format ? How about SRv6 SID format for the
same ?

Bottom line I think we must not lock ourselves into single transport
technology - that's all I am after here.

Thx,
Robert.


On Mon, Aug 3, 2020 at 7:56 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Robert –
>
>
>
> You need to allow that not everything in the world is identified by an
> IP/IPv6 address.
>
>
>
> If you want an IP address shared by all nodes in an area there is already
> a mean of doing that: assign a common anycast address on all nodes.
>
>
>
> The value add (if there is any) of an Area SID is that I don’t have to
> assign an anycast address to all nodes. I can associate the SID with an
> identifier that is already shared and known by all nodes in the area.
>
> If you don’t see that as worthwhile, fine, let’s abandon the Area SID idea.
>
>
>
>    Les
>
>
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Monday, August 03, 2020 10:47 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* bruno.decraene@orange.com; tony.li@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> Hi Les,
>
>
>
> Well I am talking about IP routable identifier which I can place on the
> front of the packet and which can assure that the packet will arrive at
> given area.
>
>
>
> Then Area SID becomes analogy of Node SID :)
>
>
>
> Thx
>
>
>
> On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> wrote:
>
> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>    Les
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* bruno.decraene@orange.com; tony.li@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
>