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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 31 January 2020 21:41 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 2B1EF120046; Fri, 31 Jan 2020 13:41:24 -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=l0nBsMVi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Qge3nxFp
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 RCHpR7Udfs3u; Fri, 31 Jan 2020 13:41:20 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C68412002E; Fri, 31 Jan 2020 13:41:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46176; q=dns/txt; s=iport; t=1580506880; x=1581716480; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wlG8ehpCaNfLOGz7nwGqZtNTYqpK2JvSqBUqE4xY/fc=; b=l0nBsMViTQnSUNeEX6Un3N2LQNgyYHoFqX8ci00t2rOHh++Punqiacgu THzzyziI3LpMAXyrRraJHRBb6P1UO1cxQNih7dxC+MfmOM+mA0sfkEwPr mfAAcNhL4g2kLFxhEnsCr8cPEDz8q/1QV1BVOb+coCcAB6SP9YDoABPAB Y=;
IronPort-PHdr: 9a23:H0+FGhJ+beQ26wZu89mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXEL6KuXgYjY1NM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AgAADfnTRe/51dJa1bChoBAQEBAQEBAQEDAQEBAREBAQECAgEBAQGBaQMBAQEBCwGBJC8pJwVsWCAECyqEFINGA4pzgl+YD4EugSQDUAQJAQEBDAEBGAEKCgIBAYRAAheCGiQ2Bw4CAw0BAQQBAQECAQUEbYU3DIVmAQEBAQIBAQEQEQoTAQElBwsBBAsCAQgRAQMBAQEgAQYDAgICJQsUAwYIAgQBDQUIEweDBYF9TQMOIAEOomsCgTmIYnWBMoJ/AQEFgS8BE0GDCRiCDAMGgTgBjB8agUE/gRFHgkw+gmQBAQIBAYE0LRUWCYJaMoIskFaFYCSYFHYKgjuHRY8VgkiIDZAwjmCIZ5IxAgQCBAUCDgEBBYFZCiiBWHAVO4JsUBgNjh0MF4EEAQmCQoUUhT90AgEBgSWKXQaCPQEB
X-IronPort-AV: E=Sophos;i="5.70,387,1574121600"; d="scan'208,217";a="441225760"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 21:41:19 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 00VLfJZE027876 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 21:41:19 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 15:41:18 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 15:41:18 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 16:41:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ss5MgoWAC3mXbPZMGwHBHHzMf7KhXH8z5QYaTtjx15/cJYoXcr7mM1gDJDPhBaG6rEyyCEqKE4jcEufCIdL7k+pKDasAGaNigyih2lwAnwn0um8di2AqIeNk5EjEPaTfWIh7n+QUK2GZ5cMoF9ppmAH79N5n47u1j6oSFL7fjMwgMeSreMVKbRgFoYoOOOKYFrl3smGZyfd+7R5jrOMfk8+I9XL/7KaH+qHlRFduoCbDry4kgv93HyjrhnWzGvXipZCSF9dH2As5eopohU5H0d1VOi5cSm5vT0zk9jp390BCtLQ9DOhRkpEckmRK3sOtHJI/Sme8QmF94HmuuTH5Tg==
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=wlG8ehpCaNfLOGz7nwGqZtNTYqpK2JvSqBUqE4xY/fc=; b=aPC9j3wD0o4b5svN1D4rOvbRiv9XVsiz5NJlPWMXPVgJDb/e4kPoEmks1LCLrrG2ehTWmkhy+D4I/1TRlRAJs4AFDhnj1Uy/FcJVi+0EVSn+U6nYhzfprXpQ7pb62Q5gW3jk1X1/+SsWcS5ZAr38BQAepmaCKZekHNHbx3cDQgvXSD5oxmgWK7DJhGSBvi2CasRt0RePh9FAXIWdSwbt01cp61x1NbKalHnPfldkSdez5zMfsmRYXtHmeR3N3DcojiVD0zeS9eWNepm6N371+yLz2HNxUNWaCZe+2ef8d8AoslCeWwISVZ9Y06I62UtGbCFhxrHSCDpR+MeHesF5WQ==
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=wlG8ehpCaNfLOGz7nwGqZtNTYqpK2JvSqBUqE4xY/fc=; b=Qge3nxFpzk8EdaO37BkdHoc/OaztVoYxmEH5dQSz9WE5Fkdve8cgtCa0CCqnKJC4lYwR1b6CcoydKToFzZFM0K08UtP/36n9ozUzS9KS7HkJHgUxenY/jdQDM1dGFUq+jMweIGNvTJnIQ06Ew8AUA7+LfKOUH7F7Hq0y/r+627s=
Received: from MWHPR11MB1616.namprd11.prod.outlook.com (10.172.54.148) by MWHPR11MB1710.namprd11.prod.outlook.com (10.169.235.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Fri, 31 Jan 2020 21:41:16 +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; Fri, 31 Jan 2020 21:41:16 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Chris Bowers <chrisbowers.ietf@gmail.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
CC: "lsr@ietf.org" <lsr@ietf.org>, "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+aAgAEnWACAAjxVgIAAFbVA
Date: Fri, 31 Jan 2020 21:41:16 +0000
Message-ID: <MWHPR11MB161697A0E14210C81B8EE17BC1070@MWHPR11MB1616.namprd11.prod.outlook.com>
References: <122B138F-AA4F-4C7C-969C-755DF15F5744@chopps.org> <CAHzoHbtnCjqZjrxpYWhR8RTqbviOBDp1UEecXyAwu0kTZ1nLGA@mail.gmail.com> <fa7c6ef0-e6c7-3d14-41f3-0a64861e25e0@cisco.com> <CAHzoHbtVNMn1igrab-Q770v22JkdkJZXi86ZL7jfN775he3ZrA@mail.gmail.com>
In-Reply-To: <CAHzoHbtVNMn1igrab-Q770v22JkdkJZXi86ZL7jfN775he3ZrA@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:1005::41b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 851d5b17-db69-4c16-9038-08d7a6964d29
x-ms-traffictypediagnostic: MWHPR11MB1710:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR11MB17103C4D1EA44351EFE5FEEBC1070@MWHPR11MB1710.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(199004)(189003)(66446008)(76116006)(66476007)(64756008)(66946007)(5660300002)(66556008)(53546011)(2906002)(6506007)(4326008)(55016002)(9686003)(478600001)(107886003)(8676002)(110136005)(86362001)(33656002)(186003)(8936002)(71200400001)(316002)(54906003)(66574012)(52536014)(81156014)(7696005)(966005)(81166006)(6636002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1710; H:MWHPR11MB1616.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: T5zsODSOBvnrG4fyTZIzVbMSOPMVVAA9oG72cEwLa66l3BgCQaAE1oa6tw8a4zKfEWGOinNUKMow8UsNBthyHksiXftjeUj1QY2u6WYwpfBu5zmlQD4vwYSPKB5egegrL+auyHTLK2GWfZMjsft3bBqjvorhHDw6Z2N92eZfhRnGs1N2XIcxphP6f554W8FHXjN9Y/NDk+rEmNES+KJfwE5jPhjOVtGZB5uBb1he2lOEnrTIu3FLFssF6zLnLaIVWbefr1lqKJlbuQI9uzkbKX5sXmKcT9v2AyhBFWeGqxKZFr+NbOF5k8smkHhp4pXVX3Df8ExcL/KDUbjg9XbUD5CTQ7VGdC6MndBl8vFdX5dRXmxCTlaZTH50O/RcKrn/uw/tmdFI0DVvGK7RYQ2fDVIufj+U0fUMXjlJaoT6As3oN94k2qwCx9l4hfLRi1FipEfJcU9XhRsKyUEMldq4Cq7iyP4vcjLNSTnnDckqJvxxWJj4g5SxA8ZKbV789uGwiPHNNWK8c7H2qKmwrFYXeA==
x-ms-exchange-antispam-messagedata: +LhO+neqsHU8amMRCHL20KooVR3ESuRhs1QYsfgwhuBMqfes3lzU5ASaTeOK7joYTsn895a35JvhEyoRhlB+eHHL0WfhiHc364uhy+CgWd1MtTmaRWDJMnSv6DqabOp16ohAlEurU7KxH4KN7Mn8HknJKQqiXlpvM9VVu0hRZ14=
Content-Type: multipart/alternative; boundary="_000_MWHPR11MB161697A0E14210C81B8EE17BC1070MWHPR11MB1616namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 851d5b17-db69-4c16-9038-08d7a6964d29
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 21:41:16.4290 (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: qeJR+uC1odXqr2HnBQ3TkBigdeJL3lZSOoQgM7ToGaIFjH+hv2iL6M2nu2TFhgbvFPG3VpEAGrxX+DQJDWFAUQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1710
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5dYx5rtZhNfS0_sEqh6U1_mdmKU>
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: Fri, 31 Jan 2020 21:41:24 -0000

Chris –

One of the early mistakes that was made when defining SR-MPLS was defining the N-flag (and R-flag) in the Prefix-SID sub-TLV.
We quickly realized that these flags had meaning and use cases for the prefix – not simply for the SID.

RFC 7794 was then written and these flags were associated with a prefix (NOT a SID) – both for IPv4 and IPv6.

We also added in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.1

“The Prefix Attribute Flags sub-TLV [RFC7794<https://www.rfc-editor.org/rfc/rfc8667.html#RFC7794>] also defines the N-Flag and R-Flag and with the same semantics of the equivalent flags defined in this document. Whenever the Prefix Attribute Flags sub-TLV is present for a given prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be ignored.”

to address backwards compatibility with early SR-MPLS IS-IS implementations.
In a perfect world the N/R flags would not exist in the Prefix-SID advertisement.

We do not want to make the same mistake again.

The A-flag is a property of a prefix – and (as per draft-ietf-lsr-isis-srv6-extensions) also a Locator.

It is a mistake to think that these flags are associated with a SID.

Does this help?

   Les


From: Lsr <lsr-bounces@ietf.org> On Behalf Of Chris Bowers
Sent: Friday, January 31, 2020 12:11 PM
To: Peter Psenak (ppsenak) <ppsenak@cisco.com>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: lsr@ietf.org; 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

Peter and Les,


It seems to me that for the Node Flag in RFC7794 and the proposed Anycast Flag

in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned with

how to identify IGP-Node Segments and IGP-Anycast Segments, as defined in RFC8402,

the Segment Routing Architecture document.



If this is the case, then the following text from RFC8402 is very relevant.

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

3.2.  IGP-Node Segment (Node-SID)



   An IGP Node-SID MUST NOT be associated with a prefix that is owned by

   more than one router within the same routing domain.



3.3.  IGP-Anycast Segment (Anycast-SID)

   ....

   An IGP-Anycast segment MUST NOT reference a particular node.
   .....
============
This text can be interpreted in two different ways.

Interpretation I)
A prefix-SID can have the following three possible states.
Ia) Node-SID
Ib) Anycast-SID
Ic) neither Node-SID nor Anycast-SID

Interpretation II)
A prefix-SID can have the following two possible states.
IIa) Node-SID
IIb) Anycast-SID

If Interpretation I) is correct, then I think that the current encodings in
draft-ietf-lsr-isis-srv6-extensions-04 do not allow us
to unambiguously identify a Node-SID for a non-/128
prefix/locator.  For example, the End-SIDs within a /64 locator with the A-flag set could
either be Ia) a Node-SID  or Ic) neither Node-SID nor Anycast-SID.
I think a reasonable solution would be to remove the restriction
on the N-flag to allow it to be used for non-/128 prefixes/locators.  This
would allow the three possible prefix-SIDs states to be easily represented.

If Interpretation II) is correct, then I think that the current encodings in
draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to
how to interpret a /128 prefix/locator advertisement with N=0, A=0. We
have to decide between interpreting the End-SIDs within the locator
as either Node-SIDs or Anycast-SIDs, since there is no third option.
I think that interpreting the End-SIDs as Anycast-SIDs in the N=0, A=0
case is preferable because it preserves backwards compatibility.

Thanks,
Chris



On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> wrote:
Hi Chris,

please see inline (##PP)

On 29/01/2020 17:25, Chris Bowers wrote:
> 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.

##PP
above does not seem correct. Above seems to imply that for non-/128
prefix, A-bit is replacement of N-bit.

A-bit applies to both /128 and non-/128 prefixes equally.

Current draft clearly states what to do when both N a A bits are set.



>
>     When a prefix/locator iscategorized 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 forIPv6), then the flag MUST be ignored."
>
>     The current document does NOT modify this restriction on the interpretation of
>
>     the N-flag imposed by [RFC7794].

##PP
I don't think above text is needed. And I don't think above is
completely correct, as we define a new case in which the N-bit should be
ignored (when A-bit is set).


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

##PP
we have following text in the draft already:

"If both N-flag and A-flag are set in the prefix/SRv6 Locator
    advertisement, the receiving routers MUST ignore the N-flag."



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

##PP
I don't think above statement is correct. Why a node cannot advertise a
/128 prefix which is not an anycast one and does not have a N-bit set?



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

##PP
A-flag does that regardless of the length of the prefix.


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

##PP
Above seems a good suggestion. Will add it.

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

##PP
above contradicts what you suggest in the previous paragraph, where you
suggest we need to advertise with both prefix and locator, and here you
suggest we ignore what we received in the locator.

Are you talking about the case where the content of the Prefix Attribute
Flags Sub-TLV is different in prefix vs locator?
>
>
>
>     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.

##PP
do we really need this? If the originator does the right thing, then we
don't have the problem. Cross referencing data between different TLVs
complicates the implementations.


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

##PP
same as above.

thanks,
Peter

>
> ==== 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>
> <mailto: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> <mailto:Lsr@ietf.org<mailto:Lsr@ietf.org>>
>     https://www.ietf.org/mailman/listinfo/lsr
>