Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 29 January 2020 20:52 UTC

Return-Path: <ginsberg@cisco.com>
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 36824120059; Wed, 29 Jan 2020 12:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CgT4YQer; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ljxjzXeq
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 OsSxupBpFAtc; Wed, 29 Jan 2020 12:52:18 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4649120033; Wed, 29 Jan 2020 12:52:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34062; q=dns/txt; s=iport; t=1580331138; x=1581540738; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r8EO3f5khBHdbDZq8x2fXlWeaYlSpmtkdQonFpN6j3A=; b=CgT4YQer841GovzDLESgfUXvJXroHjWPwxWhCRGkkifpRYIekwb3uroI 0tnhzcxmoLrb1b8HwSVQJ5JwcfUkaBAn4PfCKmoCmXPC1S2/bygh9aLcZ fjH5CcwzIiPc7l804bdMMUiHxTaV1Gtq/pzY4dAKtu81goe9qn54R/hFU M=;
IronPort-PHdr: 9a23:mlEK/RALZkqi3Su0AE1xUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHwQAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AaAABS7zFe/4cNJK1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFnBQEBAQELAYEkLyQsBWxYIAQLKoQUg0YDhFqGGIJfmA+BLoEkA1QJAQEBDAEBGAEKCgIBAYMKgTYCF4ITJDQJDgIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBEBEKEwEBJQcLAQ8CAQgRBAEBIQcDAgICJQsUCQgCBAENBQgagwWBfU0DLgEOomMCgTmIYnWBMoJ/AQEFgS8BE0GDAhiCDAMGgTgBjB8agUE/gRFHgkw+gmQBAQMBgWErCYJaMoIskFWFXiSJUY80CoI5h0KPEIJIiAqQLY5giGSSKQIEAgQFAg4BAQWBUjmBWHAVO4JsUBgNjXkkg3OFFIU/dIEpilsGgj0BAQ
X-IronPort-AV: E=Sophos;i="5.70,379,1574121600"; d="scan'208,217";a="417587247"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 20:52:16 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00TKqGYp026044 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2020 20:52:16 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 14:52:15 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 14:52:15 -0600
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 29 Jan 2020 14:52:15 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hsmt7Ny1j1FQNAHb1tQjjL6+Wv1pXJOxW2Io6l8Ao2snYGDgoLK6U5yCvm+CFdnGJ93gn8kJdLDamS8JequCwxXA45qYqgxA0IjvhHfn1xK1c3VdUr3nnuIE6DrFel2lNhU9lZeVVJKp3TYzAaeLCh+fK5EkpbFBtLyqzu6CmHJB7epW6e8rLgnb193d9i2h+4B8vI1XRrcG0WYxVuYwBIe92TthHtJ+qev9v/uNQ9L8Zh/2KlsiJEAvB080PslhaY/evW90ckQUR5aEvxie1sg5qh3bTiuIDzozMXjcHB5HCPjNuz1WLpDaYK/cFS8SqmZIDpKsDP0yxbaPTVw/4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r8EO3f5khBHdbDZq8x2fXlWeaYlSpmtkdQonFpN6j3A=; b=ndFbyxc4veD/DqcF9vTR2QdISTUwMu0Q/f0OPDMp4NcRR8mrdFA2jpVFt+KmY2or02jChEyAJeAh8X5CKwXTjm3AzsN0svk2W7TiVnJSs2UZngKIhVoKe9sbrPEAKlaKPkX/Zjuic0trL9IYnHI5gXMyCk9LVW9QHu5+dcXGAtqIx2Q+bWCNtT21HJA8mX12sI+mfpY2BcTqunlD+qzmIrlIbEnq9KRnIlH0HenIqaXRhBJd35oMSpEmzrxC5GiR93Oi234EHHus/QHH9Bn0TQRqJ3hCSPWALcEBZcFJJ9iEUkg/aNeQnmipEmD+GmK0fYvLqPLk0+dw8sKoFlwyLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r8EO3f5khBHdbDZq8x2fXlWeaYlSpmtkdQonFpN6j3A=; b=ljxjzXeqfIZR0phFlW5V/ENUUgBiCCXeDpsRU8zDK+xtwjUM2ON9l6bQHjnvQG6F5K/4H5uigV0NxXi9zy5W3TOKTMAyZ7pkbtmB9b7XG9gJ/qQmZ3koef0wKqW0+kvC8FeHvoerKvTwqcFJ5tUvnbCEF7B0W1wypz/17S3nRj8=
Received: from MWHPR11MB1616.namprd11.prod.outlook.com (10.172.54.148) by MWHPR11MB1568.namprd11.prod.outlook.com (10.172.55.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Wed, 29 Jan 2020 20:52:14 +0000
Received: from MWHPR11MB1616.namprd11.prod.outlook.com ([fe80::a938:c4d:6d94:3c54]) by MWHPR11MB1616.namprd11.prod.outlook.com ([fe80::a938:c4d:6d94:3c54%3]) with mapi id 15.20.2665.027; Wed, 29 Jan 2020 20:52:14 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Chris Bowers <chrisbowers.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: "lsr-ads@ietf.org" <lsr-ads@ietf.org>, Christian Hopps <chopps@chopps.org>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Thread-Index: AQHV0LlF42dYR6Z79EGZR3bmFlsGPqgB3+aAgABFi/A=
Date: Wed, 29 Jan 2020 20:52:14 +0000
Message-ID: <MWHPR11MB16164A4BA369042889910C07C1050@MWHPR11MB1616.namprd11.prod.outlook.com>
References: <122B138F-AA4F-4C7C-969C-755DF15F5744@chopps.org> <CAHzoHbtnCjqZjrxpYWhR8RTqbviOBDp1UEecXyAwu0kTZ1nLGA@mail.gmail.com>
In-Reply-To: <CAHzoHbtnCjqZjrxpYWhR8RTqbviOBDp1UEecXyAwu0kTZ1nLGA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1001::1b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dfae48a7-e84a-4b3f-b306-08d7a4fd1eab
x-ms-traffictypediagnostic: MWHPR11MB1568:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR11MB1568F907A0A81F9922E25D55C1050@MWHPR11MB1568.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39860400002)(136003)(396003)(366004)(189003)(199004)(55016002)(81166006)(81156014)(4326008)(107886003)(8936002)(9686003)(76116006)(66476007)(66556008)(64756008)(5660300002)(52536014)(966005)(66446008)(66946007)(186003)(6506007)(53546011)(7696005)(478600001)(2906002)(8676002)(66574012)(33656002)(54906003)(110136005)(86362001)(71200400001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1568; H:MWHPR11MB1616.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /ck5zcdLUJ6JAxzff8ZysLhIQSoEA1aCkRjho9mOaH3TEW2rjLK/MKb1HUKuDRZej2weYdcwfR1s6m4fPmFPHKP5YL/MiZ2W92nNd45T+G6v6cJQsCS1YFTe+qVyBnRbFuDIQGx9lqA94WDnZKUINHGak869TMpqf+X+db/6WTuJDyhhClo1ToduxYD19devX1RAM+f+ZjE99FWcrF6D4lIEKz7NyU32IbaDnDs3A7Yy6XlINhhcq/5niD9QMZQ8eD76sqk+WfXdmU2Vksm5Vy2YPAkRiTtcAyFIFdWfX8lb3emSmGaKKheuyA/M86GAtGOz98sE8hg9W4OYc7B3n9OFLagzze6oMng8ZOOjr5niFPN071lUrKS60GLSNs/Nd/X9rUBTpkHjBjThrjQ5SNR85NOsgoLzMH75FuaY/bioCWdAmhRWpSwcm0F/QyCpPcdZFKHUbmeYm9wTlCYSyhsbKm9qn8HF7xkVOzP3BOdZzct569CF0pe42mcWjX4Kt3Mrkizx1zG0KiRPNfxb6Q==
x-ms-exchange-antispam-messagedata: G96fuBKDe8kedDpzRMISE0ctNl6Q4DrB2nL6S9icK1c5iROpbQKYlurKnE00+EclHxEotWGxnzYzbJy6U68+X7QCXIzTP2LrV4KZ3lNGzowlKKqTvEFN5RhqKTZIPentYE00xJJ54i0XVGsNA+mQC1rQlS3KJxahoOqXthtCdUU=
Content-Type: multipart/alternative; boundary="_000_MWHPR11MB16164A4BA369042889910C07C1050MWHPR11MB1616namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dfae48a7-e84a-4b3f-b306-08d7a4fd1eab
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 20:52:14.1515 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lzZSAuRZWGFY58Q+I/ELYv22V4vucdT2giK3ISjDI5RKeYuMPqL4ZSh7UvjHE8DHxfsviggk7nX1oly8ZVfcHQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1568
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/4bimjYDQKuc_54FWkzxMxSJuHbI>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
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: Wed, 29 Jan 2020 20:52:27 -0000

Chris –

I will let the authors of isis-srv6-extensions reply to the bulk of your suggestion.
But as an author of RFC 7794, I do have some concerns.

Please see inline.

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Chris Bowers
Sent: Wednesday, January 29, 2020 8:25 AM
To: lsr@ietf.org
Cc: lsr-ads@ietf.org; Christian Hopps <chopps@chopps.org>; Acee Lindem (acee) <acee@cisco.com>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

I would like to proposed the following text to make section 6 more clear.

Thanks,
Chris
====================
 (existing text)

6.  Advertising Anycast Property

   Both prefixes and SRv6 Locators may be configured as anycast and as
   such the same value can be advertised by multiple routers.  It is
   useful for other routers to know that the advertisement is for an
   anycast identifier.

   A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"
   registry [RFC7794] is defined to advertise the anycast property:

       Bit #: 4 (Suggested - to be assigned by IANA)
       Name: Anycast Flag (A-flag)

       When the prefix/SRv6 locator is configured as anycast, the A-flag
       SHOULD be set. Otherwise, this flag MUST be clear.

   The A-flag MUST be preserved when leaked between levels.

   The A-flag and the N-flag MUST NOT both be set.

==== start insert new text =======

   Certain use cases require prefixes/locators that uniquely belong to a node.
   Since prefixes/locators which are not /128 should not have the N bit set,
   this node local uniqueness is decided based on A bit for non-/128 prefixes.
   When a prefix/locator is categorized as anycast, it does not uniquely belong
   to a node and cannot be used for such use cases.  The rules below specify
   how to determine whether or not a prefix/locator should be treated as anycast
   in various situations.


   [RFC7794] contains the following restriction on the interpretation of the N-flag.

   "If the flag is set and the prefix length is NOT a host prefix

    (/32 for IPV4, /128 for IPv6), then the flag MUST be ignored."



   The current document does NOT modify this restriction on the interpretation of

   the N-flag imposed by [RFC7794].

[Les:] I am not sure why you feel the above two paragraphs are necessary. In general, I find the idea that I have to say “I am not changing that other specification” disturbing.
It suggests that the document should list everything else which it isn’t changing.
Perhaps you feel that there is something in the current text which suggests that the meaning of the N flag when associated with a non-host prefix has been changed by this document? If so, please point out that text.

   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,
   if both N-flag and A-flag are set, the receiving router MUST treat the
   prefix advertisement as anycast.

   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,
   if the N-flag and A-flag are NOT set, the receiving routers
   MUST treat the prefix advertisement as anycast.  This rule ensures the
   correct interpretation of a prefix advertisement originated by
   a router that is not SRv6 capable and originates a legacy
   Prefix Attribute Flags Sub-TLV based on [RFC7794] alone.

[Les:] This suggestion confuses me – and seems incorrect.
You imply by this that there are only two possibilities for a host address:
1)It is a node address or
2)It is an anycast address

But it is also possible that the prefix is a unicast address but the originator does not intend for the address to be used as a node address.
Your text disallows that possibility.

I get that prior to the definition of the A-bit there is no way to tell by looking at a prefix advertisement alone whether the address is anycast (hence the desire to define the A-bit).
But it does not then follow that if A-bit and N-bit are both NOT set that this is equivalent to having A-bit set.

   Les

   For a prefix/SRv6 Locator advertisement with a prefix/locator that
   is NOT /128, the N-flag must be ignored, so the setting of the
   A-flag determines the anycast treatment of the prefix advertisement.

   The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator TLV
   as well as the Prefix Reachability TLVs.  When a router originates

   both the Prefix Reachability TLV and the SRv6 Locator TLV for a given

   prefix, and the router is originating the Prefix Attribute Flags Sub-TLV

   in one of the TLVs, the router SHOULD advertise identical versions of the

   Prefix Attribute Flags Sub-TLV in both TLVs.



   If a router receives one Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV and another in the SRv6 Locator TLV, the router should

   use the prefix attribute flags received in the Prefix Reachability TLV.



   If a router receives a Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV but not in the SRv6 Locator TLV, the router should

   use the prefix attribute flags received in the Prefix Reachability TLV.



   If a router receives a Prefix Attribute Flags Sub-TLV in the

   SRv6 Locator TLV but not in the Prefix Reachability TLV,

   the router should use the prefix attribute flags received in the SRv6 Locator TLV.

==== end insert new text =========

   The same prefix/SRv6 Locator can be advertised by multiple routers.
   If at least one of them sets the A-Flag in its advertisement, the
   prefix/SRv6 Locator SHOULD be considered as anycast.


===================

On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>> wrote:
This begins a 2 week WG Last Call, ending after Feb 4, 2020, for draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf..org/doc/draft-ietf-lsr-isis-srv6-extensions/<https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/>

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr