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

From: Ahmed Bashandy <[email-masked]>
Date: Sun, 2 Feb 2020 14:51:34 -0800

I am not aware of any IPR that has not been disclosed

Ahmed

On 1/21/20 4:14 PM, Christian Hopps 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/
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 3 Feb 2020 14:25:33 +0900

I support the WGLC to move this doc forward.
And as a contributor, I’m not aware of any IPR that has not been disclosed.

cheers,
--satoru

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Feb 2020 14:39:38 +0100

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>     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:
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 4 Feb 2020 02:00:51 +0000

I support progressing this draft.

Best regards,
Jie

> -----Original Message-----
> From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
> Sent: Wednesday, January 22, 2020 8:15 AM
> To: [email-masked]
> Cc: [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem
> (acee) <[email-masked]>
> Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 4 Feb 2020 09:44:19 +0100

Hi Chris,

> 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

---

From: Chris Bowers <[email-masked]>
Date: Tue, 4 Feb 2020 16:17:07 -0600

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.

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

Thanks,
Chris

On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak <[email-masked]> 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/>
> >      >

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Feb 2020 12:28:00 +0100

Hi Chris,

On 04/02/2020 23:17, Chris Bowers wrote:
> a Node-SID when constructing traffic engineered paths.  That is, I want 
> to know that

##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,
> 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
> I don't think it would be very useful to configure a /128 locator, since 
> it only has

##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 <[email-masked] 
> On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak <[email-masked] 
>      >     more than one router within the same routing domain..
>      >
>      > how to interpret a /128 prefix/locator advertisement with N=0,
>     A=0.. We
>      >
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Chris,
>      >
>      >     please see inline (##PP)
>      >
>      >      > 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
>      >      >
>      >      >     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
>      >      >
>      >      >     "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
>      >      >
>      >      >     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
>      >      >
>      >      >     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
>      >      > 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
>      >      >
>      >      >     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
>      >      >
>      >      >
>      >      >
>      >      >     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
>      >      >
>      >      >
>      >      >
>      >      >     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
>      >      >
>      >      >
>      >      >
>      >      >     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
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     This begins a 2 week WG Last Call, ending after Feb 4,
>     2020, for
>      >      >     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
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >
>

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 11 Feb 2020 17:20:53 -0800

As a co-author I support this draft and I am not aware of any 
undisclosed IPR related to this draft

Ahmed

---

From: Chris Bowers <[email-masked]>
Date: Fri, 14 Feb 2020 10:26:48 -0600

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 <[email-masked]>
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 <[email-masked]> wrote:
>
>> Hi Chris,
>>
>> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
>> >      >      >     This begins a 2 week WG Last Call, ending after Feb 4,
>> >     2020, for

---

From: Chris Bowers <[email-masked]>
Date: Fri, 14 Feb 2020 10:28:07 -0600

All,

Chris

On Sat, Feb 8, 2020 at 3:25 AM Peter Psenak <[email-masked]> wrote:

> Hi Chris,
>
> On 07/02/2020 23:15, Chris Bowers wrote:
> > Peter,
> >
> > 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 ?
>
> yes. That's the only reasonable choice.
>
> Implementation may also check if the same locator is not advertised by
> some other node in addition. But I would not mandate that in the spec.
>
> thanks,
> Peter
> >
> > Thanks,
> > Chris
> >
> > On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak <[email-masked]
> >      >      >> would allow the three possible prefix-SIDs states to be
> >     easily
> >      >     represented.
> >      >      > ##PP
> >      >      > 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,
> >      >      >
> >      >      > If this is the case, then the following text from RFC8402
> >     is very
> >      >     relevant.
> >      >      >
> >      >      > ============
> >      >      >
> >      >      >     An IGP Node-SID MUST NOT be associated with a prefix
> >     that is
> >      >     owned by
> >      >      >
> >      >      > If Interpretation I) is correct, then I think that the
> current
> >      >     encodings in
> >      >      >
> >      >      > prefix/locator.  For example, the End-SIDs within a /64
> >     locator
> >      >     with the
> >      >      > A-flag set could
> >      >      >
> >      >      > either be Ia) a Node-SID
> >      >
> >      >     ##PP
> >      >      > would allow the three possible prefix-SIDs states to be
> easily
> >      >     represented.
> >      >
> >      >     ##PP
> >      >      > draft-ietf-lsr-isis-srv6-extensions-04 need clarification
> with
> >      >     respect to
> >      >      >
> >      >      > I think that interpreting the End-SIDs as Anycast-SIDs in
> the
> >      >     N=0, A=0
> >      >      >
> >      >      > On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak
> >     <[email-masked] <mailto:[email-masked]>
> >      >     <mailto:[email-masked] <mailto:[email-masked]>>
> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >      >      >
> >      >      >     Hi Chris,
> >      >      >
> >      >      >     please see inline (##PP)
> >      >      >
> >      >      >      >     Both prefixes and SRv6 Locators may be
> >     configured as
> >      >     anycast
> >      >      >     and as
> >      >      >      >
> >      >      >      >     such the same value can be advertised by
> multiple
> >      >     routers.  It is
> >      >      >      >
> >      >      >      >     A new flag in "Bit Values for Prefix Attribute
> >     Flags
> >      >     Sub-TLV"
> >      >      >      >
> >      >      >      >     registry [RFC7794] is defined to advertise the
> >     anycast
> >      >     property:
> >      >      >      >
> >      >      >      > 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
> >      >      >     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
> >      >      >      >
> >      >      >      >     "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
> >      >      >      >
> >      >      >          advertisement, the receiving routers MUST ignore
> the
> >      >     N-flag."
> >      >      >
> >      >      >
> >      >      >
> >      >      >      >
> >      >      >      >     if the N-flag and A-flag are NOT set, the
> receiving
> >      >     routers
> >      >      >      >
> >      >      >     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
> >      >      >      >
> >      >      >      >     The Prefix Attribute Flags Sub-TLV can be
> >     carried in
> >      >     the SRv6
> >      >      >      > Locator TLV
> >      >      >      >
> >      >      >      >     both the Prefix Reachability TLV and the SRv6
> >     Locator
> >      >     TLV for
> >      >      >     a given
> >      >      >      >
> >      >      >     above contradicts what you suggest in the previous
> >     paragraph,
> >      >     where you
> >      >      >     suggest we need to advertise with both prefix and
> locator,
> >      >     and here you
> >      >      >      >     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
> >      >      >      >
> >      >      >     do we really need this? If the originator does the
> right
> >      >     thing, then we
> >      >      >      >     If a router receives a Prefix Attribute Flags
> >     Sub-TLV
> >      >     in the
> >      >      >      >
> >     <mailto:[email-masked] <mailto:[email-masked]>>>
> >      >      >      > <mailto:[email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
> >      >      >      >
> >      >      >      >     Authors please indicate if you aware of any
> >     other IPR
> >      >     beyond
> >      >      >     what is
> >      >      >      >     posted:
> >      >      >      >
> >      >      >      > [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
> >     <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>
> >      >      >     <mailto:[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>>