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

Chris Bowers <chrisbowers.ietf@gmail.com> Fri, 14 February 2020 16:29 UTC

Return-Path: <chrisbowers.ietf@gmail.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 A3FC912008A; Fri, 14 Feb 2020 08:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com
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 eQdDJ0W7m2tl; Fri, 14 Feb 2020 08:29:23 -0800 (PST)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 6C62D1200E5; Fri, 14 Feb 2020 08:29:23 -0800 (PST)
Received: by mail-qt1-x82c.google.com with SMTP id d5so7366045qto.0; Fri, 14 Feb 2020 08:29:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+d4AqypyZiC/mRPzlhTmCcdPK/w/tFfBc/xsw0+LN10=; b=XDWduURo1TvfiBBsQY45wnjSsSeFTLPOur9I6/u1AIjShTYxqFRYPoJhI+LrgHRWHW BQNZttoLim5wxISBAA9/LEZQJsgV00X41apunAQs+PUsPSlM13PP6Dm0h1tTbIfg9cXZ 4owMv8ZHdW1sAE7LhRdX2W54AW90wsh4OEKBXkvGG96IKXCdBMOJ8d1ePDzIf7kjFIjU o4H6eV9QMSKUBefIUJIr2KB1aG4WnZiggtHvO+sDPVTfXjkw9Dme0RZC9x4ux64MIRkh gDj61rYbKwG6+9/9alT0/uSjECVnVOe7q1fYg2zBimBQkoLtxk/z3TVJekd7Ygp/yX1Q VV7w==
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; bh=+d4AqypyZiC/mRPzlhTmCcdPK/w/tFfBc/xsw0+LN10=; b=LWXx6I9uGfD0GuTRbFNHYrqkr6QpcW/4iBWnm4NhXPNssfoLB2XlAOM+N2+O++ki6N 903cT/SsKK+tzIahmEuhzkzN54b7nqjuDFxJVnsFZ9I2qs1a1hNceAb0yiS4lQHlwYgk CoFOf53vhbNdsVLUwcvzHoS9HAEfJXt2ul8ymYHN1IVrA207XcwQKcMw1PSsaPsg9D4X L5orfAqk2hsTQcZhmeU0KKyWCJARgICWt3OT5OugyIYpuVeRGETDIXYROm3w6+U/GX5Y q19oShLax9aXN+ZhHFcivvWXCGZx3i1SJ2l91FRT6AzO69Y7c8po8ZSWmvicD3Q0Rjms 2p7w==
X-Gm-Message-State: APjAAAW1M3T0Hp5U2kCo8QC5E05I2Ax8UioN6ulbQwkl+tdS1LlwWrL3 avSsUDk1d0GnqtRhUG93JnESqx57HnDjEJkAjv0=
X-Google-Smtp-Source: APXvYqxoTSp4V7br4zd51auzcDuiJkKOXirWg7q+XKTxbBWuEXOx+zNfZP/LacKvMrDSElR3FYckHLW6tkYBapMgk1Q=
X-Received: by 2002:ac8:1306:: with SMTP id e6mr3194067qtj.267.1581697762312; Fri, 14 Feb 2020 08:29:22 -0800 (PST)
MIME-Version: 1.0
References: <122B138F-AA4F-4C7C-969C-755DF15F5744@chopps.org> <CAHzoHbtnCjqZjrxpYWhR8RTqbviOBDp1UEecXyAwu0kTZ1nLGA@mail.gmail.com> <fa7c6ef0-e6c7-3d14-41f3-0a64861e25e0@cisco.com> <CAHzoHbtVNMn1igrab-Q770v22JkdkJZXi86ZL7jfN775he3ZrA@mail.gmail.com> <86b274ad-e26b-029b-a36f-01febc03027a@cisco.com> <CAHzoHbvPp7CGtSGBnyY+G+=CYrU3hAxQ-=wUt9fyMH1AifWSWw@mail.gmail.com> <14f7392b-0139-0e88-a40a-45dbfcfa9ab0@cisco.com> <CAHzoHbv7MnuyP7T92_8Zd2JZKxy7VHjNPAKhFLPeZFsCQrRhxA@mail.gmail.com>
In-Reply-To: <CAHzoHbv7MnuyP7T92_8Zd2JZKxy7VHjNPAKhFLPeZFsCQrRhxA@mail.gmail.com>
From: Chris Bowers <chrisbowers.ietf@gmail.com>
Date: Fri, 14 Feb 2020 10:26:48 -0600
Message-ID: <CAHzoHbu1JzpZ6ByqUPt9tt=0AOdJsuxPRFN23aPXZLRRowgd3g@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>, lsr@ietf.org, "Acee Lindem (acee)" <acee@cisco.com>, lsr-ads@ietf.org, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="00000000000043ce9a059e8bb586"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1a5HOpzTlJtkZs2CiYXZDugCXBU>
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, 14 Feb 2020 16:29:30 -0000

All,

I'm forwarding this question and subsequent response to the list because it
looks like I accidentally sent it only to Peter before.

Chris

On Fri, Feb 7, 2020 at 4:15 PM Chris Bowers <chrisbowers.ietf@gmail.com>
wrote:

> Peter,
>
> Thanks for the clarification.
>
> Can you also clarify how a receiver should interpret a locator
> advertisement that doesn't have a corresponding RFC7794 advertisement?
>
> Modifying the example below,  suppose I receive a locator advertisement
> from router R7 with locator = 7777::/64 and End-SID 7777::1, but R7 doesn't
> originate an RFC7794 advertisement for 7777::/64.  Can I conclude that
> 7777::/64 is not Anycast, so it can be used as a Node-SID when constructing
> TE paths as discussed below ?
>
> Thanks,
> Chris
>
> On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak <ppsenak@cisco.com> wrote:
>
>> Hi Chris,
>>
>> On 04/02/2020 23:17, Chris Bowers wrote:
>> > Peter,
>> >
>> > Suppose I receive a locator advertisement from router R7 with
>> > locator = 7777::/64 and End-SID 7777::1.  I would like to be able to
>> use
>> > End-SID 7777::1 as
>> > a Node-SID when constructing traffic engineered paths.  That is, I want
>> > to know that
>> > the person or system that configured R7 believes that 7777::/64
>> > is NOT owned by more than one router within the same routing domain.
>>
>> ##PP
>> sure, if the A-bit is not set, you should be fine to pick the SID from a
>> locator. Please see below why.
>>
>> >
>> > Since we are going with Interpretation I) below, a prefix can be (a) a
>> > Node Prefix, (b) an Anycast Prefix,
>> > or (c) neither of them.
>>
>> ##PP
>> above is correct in general.
>>
>> However, given that locator is non-/128, N-bit does not apply per
>> RFC7794. So for a locator you only have (b) or (c) and you would only
>> want to avoid (b) for what you want to do above.
>>
>>
>> > If I receive an RFC7794 advertisement from R7
>> > for 7777::/64 with N=0, A=0,
>> > I can only conclude that 7777::/64 is either (a) a Node Prefix or (c)
>> > neither a Node Prefix nor an
>> > Anycast Prefix. Using the N-flag for a non-/128 would allow us to
>> > unambiguously indicate that
>> > 7777::/64 is a Node Prefix, so we can use the associated End-SID
>> 7777::1
>> > in a manner
>> > consistent with the knowledge that 7777::/64 is NOT owned by more than
>> > one router
>> > within the same routing domain.
>> >
>> > One other small point relates to the statement below that "locators are
>> > never /128".
>> > I don't think it would be very useful to configure a /128 locator,
>> since
>> > it only has
>> > space for one SRv6 SID.   However, the current text of
>> > draft-ietf-lsr-isis-srv6-extensions explicitly
>> > allows the Loc-Size to be 1-128.
>>
>> ##PP
>> agree, but I don't believe we need to put any special text to state the
>> above, it's obvious.
>>
>> thanks,
>> Peter
>> >
>> > Thanks,
>> > Chris
>> >
>> > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak <ppsenak@cisco.com
>> > <mailto:ppsenak@cisco.com>> wrote:
>> >
>> >     Hi Chris,
>> >
>> >     On 03/02/2020 14:39, Peter Psenak wrote:
>> >      >> 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.
>> >      > ##PP
>> >      > right, that could be a possibility, which would allow SRv6
>> locator to
>> >      > have the "node" property, as locators are never /128.
>> >
>> >     do you have a use case, where the locator would need a N-flag?
>> >
>> >     I can not really think of any, so unless we have one, we better not
>> >     define an N-flag for a non-/128 locator prefix.
>> >
>> >     thanks,
>> >     Peter
>> >
>> > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak <ppsenak@cisco.com
>> > <mailto:ppsenak@cisco.com>> wrote:
>> >
>> >     Hi Chris,
>> >
>> >     adding to what Les has said.
>> >     Please see inline (##PP)
>> >
>> >     On 31/01/2020 21:10, Chris Bowers wrote:
>> >      > 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
>> >
>> >     ##PP
>> >     Prefix can either be Node Prefix, Anycast Prefix or neither of them.
>> >
>> >
>> >      >
>> >      > 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
>> >
>> >     ##PP
>> >     rfc7794 does not allow the N-flag to be set for non-/128 prefix, so
>> >     above is not possible for /64 locator at the moment.
>> >
>> >     If the A-flag is set, it is an anycast locator.
>> >
>> >
>> >
>> >      >or Ic) neither Node-SID nor Anycast-SID.
>> >
>> >     ##PP
>> >     if the A-flag was not set for /64 locator, above would be correct,
>> but
>> >     given that the A-flag is set, it is clearly just Anycast locator.
>> >
>> >      >
>> >      > 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.
>> >
>> >     ##PP
>> >     right, that could be a possibility, which would allow SRv6 locator
>> to
>> >     have the "node" property, as locators are never /128.
>> >
>> >     thanks,
>> >     Peter
>> >
>> >
>> >      >
>> >      > 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>
>> >      > <mailto: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>>
>> >      >      > <mailto: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>> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>
>> >      >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
>> >      >      > https://www.ietf.org/mailman/listinfo/lsr
>> >      >      >
>> >      >
>> >
>>
>>