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

[Les Ginsberg (ginsberg)]

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] 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  On Behalf Of Chris Bowers
Sent: Friday, January 31, 2020 12:11 PM
To: Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg) 

Cc: lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ; Acee 
Lindem (acee) 
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 
mailto:ppse...@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 bi

Re: [Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

[Lee, Yiu]

Dear Acee, Chris and LSR WG,

In the Post Multi-Chassis era, it is more and more common to consider CLOS 
design for core router (aka De-segregated router). Unlike data center, it 
requires to run LSR in the “fabric” and dramatically increase the numbers of 
LSR speakers in the core network. So, the “Fabric” abstraction described in 
these drafts are important for deployment. We support the WG to work on them.

Best regards,
Yiu


On January 27, 2020 at 1:27:13 PM, Acee Lindem (acee) 
(a...@cisco.com)

wrote:


Speaking as WG Co-chair:



At IETF 107, we had a protracted discussion of several drafts having  goal of 
reducing the amount of link-state information that must be flooded into the 
level-2 area. We have two drafts that do this essentially via abstraction of 
the level-1 areas. These are:



https://www.ietf.org/id/draft-li-lsr-isis-area-proxy-01.txt

https://www.ietf.org/id/draft-chen-isis-ttz-07.txt



There are various reasons why these drafts can’t consolidated involving both 
IPR and government restrictions. Refer to 
https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00 for the 
complete discussion.



We have another draft that also reduces the amount of link-state information 
each IS-IS router must maintain but using IS-IS reflectors. This is slightly 
different but also avoids leaking all the level-1 area link-state to the 
level-2 area.



https://www.ietf.org/id/draft-przygienda-lsr-flood-reflection-01.txt



Given the amount of overlap and the conflicts amongst these drafts, the 
chairs/Ads are now asking whether there is a really a strong requirement to 
advance one or more of these documents. Especially given that we are already 
moving forward with both IS-IS/OSPF flooding reductions and the Hierarchal 
IS-IS work. Additionally,  we anticipate we’ll reach an impasse in 
consolidating these drafts. We’d really like to hear from the operators that 
would deploy these mechanisms.



Thanks,

Acee and Chris

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Chris Bowers]

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

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Thanks Acee. Your proposed text looks much better.

Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 31 January 2020 18:02
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hey Ketan, 

Looks good - but can we simplify/shorten the last sentence?


On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know 
if this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


How about  "... with the algorithm that will be used for computing paths 
destined to the SID."? 

Do we refer to "specific algorithm topologies" in the flex algorithm draft? I 
haven't read it for a while... 

Thanks,
Acee


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. 
I don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was 
configured for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way 
of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't 
defined as the algorithm from the longest match locator. That way, everyone in 
>the area would use the same one and there would be less that could go wrong. 
What am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different 
algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along 
with the test for ignoring END.X SIDs that have conflicting algorithms with 
their longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps 
, lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies 
the
>  > handling of this cond

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Acee Lindem (acee)]

Hey Ketan, 

Looks good - but can we simplify/shorten the last sentence?


On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know 
if this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


How about  "... with the algorithm that will be used for computing
paths destined to the SID."? 

Do we refer to "specific algorithm topologies" in the flex algorithm draft? I 
haven't read it for a while... 

Thanks,
Acee


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. 
I don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was 
configured for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way 
of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't 
defined as the algorithm from the longest match locator. That way, everyone in 
>the area would use the same one and there would be less that could go wrong. 
What am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different 
algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along 
with the test for ignoring END.X SIDs that have conflicting algorithms with 
their longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps 
, lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies 
the
>  > handling of this condition.
>  >
>  > All End.X SIDs MUST be subsumed by the subnet of a Locator 
with the
>  >
>  > matching algorithm which is advertised by the same node in 
an SRv6
>  >
>  > Locator TLV.  End.X SIDs which do not meet this 
requirement MUST be
>  >
>  > ignored.
>

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know if 
this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. I 
don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was configured 
for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't defined 
as the algorithm from the longest match locator. That way, everyone in >the 
area would use the same one and there would be less that could go wrong. What 
am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along with 
the test for ignoring END.X SIDs that have conflicting algorithms with their 
longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps , 
lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies the
>  > handling of this condition.
>  >
>  > All End.X SIDs MUST be subsumed by the subnet of a Locator 
with the
>  >
>  > matching algorithm which is advertised by the same node in an 
SRv6
>  >
>  > Locator TLV.  End.X SIDs which do not meet this requirement 
MUST be
>  >
>  > ignored.
>  >
>  > Thanks,
>  >
>  > Ketan
>  >
>  > *From:* Acee Lindem (acee) 
>  > *Sent:* 30 January 2020 21:01
>  > *To:* li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant)
>  > ; Christian Hopps ; lsr 

>  > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>  > ; lsr-ads 

>  > *Subject:* Re: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Ketan, Zhen,
>  >
>  > What happens if there an algorithm conflict between the Adjacency 
END.X
>  > SID and the longest match Locator SID? Either one has to take 
precedence
>  > or this is an error condition. In either case, it needs to be 
documented.
>  >
>  > Thanks,
>  >
>