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

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 1 Feb 2020 12:53:43 +0000

Hi Peter,

Please see some comments inline:

> -----Original Message-----
> From: Lsr [mailto:[email-masked]] On Behalf Of Peter Psenak
> Sent: Friday, January 31, 2020 1:24 AM
> To: Acee Lindem (acee) <[email-masked]>; Ketan Talaulikar (ketant)
> <[email-masked]>; [email-masked]; Christian Hopps
> <[email-masked]>; lsr <[email-masked]>
> Cc: lsr-ads <[email-masked]>; draft-li-lsr-ospfv3-srv6-extensions
> <[email-masked]>
> Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
> 
> Hi Acee,
>  
> On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> > Hi Peter,
> >
> > On 1/30/20, 11:36 AM, "Peter Psenak" <[email-masked]> 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.

In what scenarios will the longest match locator of the END.X SID be advertised by a different router? Does this only happen due to bug or misconfiguration? 

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

In this case just checking the algorithm may not be enough, if the algorithm happens to be the same, will the END.X SID be considered valid and be used by transit nodes to route towards the originator of the incorrect locator? Some mechanism needs to be considered to avoid using invalid END.X SIDs in such case.

Best regards,
Jie

> 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.
> 
> thanks,
> Peter
> 
> 
> 
> >
> > Thanks,
> > Acee
> >
> >
> >      thanks,
> >      Peter
> >
> >      >
> >      > Thanks,
> >      >
> >      > Acee
> >      >
> >      > *From: *"Ketan Talaulikar (ketant)" <[email-masked]>
> >      > *Date: *Thursday, January 30, 2020 at 11:06 AM
> >      > *To: *Acee Lindem <[email-masked]>, "[email-masked]"
> >      > <[email-masked]>, Christian Hopps
> <[email-masked]>, lsr
> >      > <[email-masked]>
> >      > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
> >      > <[email-masked]>, lsr-ads
> <[email-masked]>
> >      > *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) <[email-masked]>
> >      > *Sent:* 30 January 2020 21:01
> >      > *To:* [email-masked]; Ketan Talaulikar (ketant)
> >      > <[email-masked]>; Christian Hopps <[email-masked]>; lsr
> <[email-masked]>
> >      > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
> >      > <[email-masked]>; lsr-ads
> <[email-masked]>
> >      > *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,
> >      >
> >      > Acee
> >      >
> >      > *From: *"[email-masked]
> <mailto:[email-masked]>"
> >      > <[email-masked] <mailto:[email-masked]>>
> >      > *Date: *Thursday, January 30, 2020 at 10:20 AM
> >      > *To: *"Ketan Talaulikar (ketant)" <[email-masked]
> >      > <mailto:[email-masked]>>, Christian Hopps <[email-masked]
> >      > <mailto:[email-masked]>>, lsr <[email-masked]
> <mailto:[email-masked]>>
> >      > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
> >      > <[email-masked]
> >      > <mailto:[email-masked]>>, lsr-ads
> >      > <[email-masked] <mailto:[email-masked]>>, Christian Hopps
> >      > <[email-masked] <mailto:[email-masked]>>, Acee Lindem
> >      > <[email-masked] <mailto:[email-masked]>>
> >      > *Subject: *Re: RE: [Lsr] WG Adoption Call for
> >      > draft-li-lsr-ospfv3-srv6-extensions
> >      >
> >      > For the third concern, I think it is better to list the considerations
> >      > behind the format design of the TLVs to help readers understand
> them
> >      > better. For the specification behavior you mention, this doc SHOULD
> >      > specify it explicitly.
> >      >
> >      > By the way, what a router should do when it receives END.X SID
> >      > containing algorithm that is different from the one carried in the
> >      > convering locator?
> >      >
> >      > Best Regards,
> >      >
> >      > Zhenqiang Li
> >      >
> >      > ------------------------------------------------------------------------
> >      >
> >      > [email-masked] <mailto:[email-masked]>
> >      >
> >      >     *From:*Ketan Talaulikar (ketant) <mailto:[email-masked]>
> >      >
> >      >     *Date:* 2020-01-30 16:44
> >      >
> >      >     *To:[email-masked]
> <mailto:[email-masked]>;
> >      >     Christian Hopps <mailto:[email-masked]>; lsr
> <mailto:[email-masked]>
> >      >
> >      >     *CC:*draft-li-lsr-ospfv3-srv6-extensions
> >      >     <mailto:[email-masked]>; lsr-ads
> >      >     <mailto:[email-masked]>; Christian Hopps
> >      >     <mailto:[email-masked]>; Acee Lindem (acee)
> <mailto:[email-masked]>
> >      >
> >      >     *Subject:* RE: RE: [Lsr] WG Adoption Call for
> >      >     draft-li-lsr-ospfv3-srv6-extensions
> >      >
> >      >     Please check inline again.
> >      >
> >      >     *From:* [email-masked]
> <mailto:[email-masked]>
> >      >     <[email-masked]
> <mailto:[email-masked]>>
> >      >     *Sent:* 30 January 2020 13:46
> >      >     *To:* Ketan Talaulikar (ketant) <[email-masked]
> >      >     <mailto:[email-masked]>>; Christian Hopps
> <[email-masked]
> >      >     <mailto:[email-masked]>>; lsr <[email-masked]
> <mailto:[email-masked]>>
> >      >     *Cc:* draft-li-lsr-ospfv3-srv6-extensions
> >      >     <[email-masked]
> >      >     <mailto:[email-masked]>>; lsr-ads
> >      >     <[email-masked] <mailto:[email-masked]>>; Christian Hopps
> >      >     <[email-masked] <mailto:[email-masked]>>; Acee
> Lindem (acee)
> >      >     <[email-masked] <mailto:[email-masked]>>
> >      >     *Subject:* Re: RE: [Lsr] WG Adoption Call for
> >      >     draft-li-lsr-ospfv3-srv6-extensions
> >      >
> >      >     Thank you KT for your quick response. Please see my reply
> begins
> >      >     with [ZQ].
> >      >
> >      >     Best Regards,
> >      >
> >      >     Zhenqiang Li
> >      >
> >      >     ------------------------------------------------------------------------
> >      >
> >      >     [email-masked]
> <mailto:[email-masked]>
> >      >
> >      >         *From:*Ketan Talaulikar (ketant)
> <mailto:[email-masked]>
> >      >
> >      >         *Date:* 2020-01-30 13:42
> >      >
> >      >         *To:[email-masked]
> <mailto:[email-masked]>;
> >      >         Christian Hopps <mailto:[email-masked]>; lsr
> >      >         <mailto:[email-masked]>
> >      >
> >      >         *CC:*draft-li-lsr-ospfv3-srv6-extensions
> >      >         <mailto:[email-masked]>;
> lsr-ads
> >      >         <mailto:[email-masked]>; Christian Hopps
> >      >         <mailto:[email-masked]>; Acee Lindem (acee)
> >      >         <mailto:[email-masked]>
> >      >
> >      >         *Subject:* RE: [Lsr] WG Adoption Call for
> >      >         draft-li-lsr-ospfv3-srv6-extensions
> >      >
> >      >         Hello Zhenqiang Li,
> >      >
> >      >         Thanks for your review and comments. Please check inline
> below.
> >      >
> >      >         *From:[email-masked]
> >      >         <mailto:[email-masked]>
> <[email-masked]
> >      >         <mailto:[email-masked]>>
> >      >         *Sent:* 30 January 2020 08:46
> >      >         *To:* Christian Hopps <[email-masked]
> >      >         <mailto:[email-masked]>>; lsr <[email-masked]
> >      >         <mailto:[email-masked]>>
> >      >         *Cc:* draft-li-lsr-ospfv3-srv6-extensions
> >      >         <[email-masked]
> >      >         <mailto:[email-masked]>>;
> lsr-ads
> >      >         <[email-masked] <mailto:[email-masked]>>; Christian
> Hopps
> >      >         <[email-masked] <mailto:[email-masked]>>;
> Acee Lindem
> >      >         (acee) <[email-masked] <mailto:[email-masked]>>
> >      >         *Subject:* Re: [Lsr] WG Adoption Call for
> >      >         draft-li-lsr-ospfv3-srv6-extensions
> >      >
> >      >         support the adoption with the following comments.
> >      >
> >      >         1. What does SRH stack mean in section 4.2? AS specified
> in
> >      >         RFC8200 and draft-ietf-6man-segment-routing-header,
> only one SRH
> >      >         can be presented in one IPv6 header.
> >      >
> >      >         */[KT] Thanks for catching this error and will fix as
> below:/*
> >      >
> >      >         *//*
> >      >
> >      >         */OLD: /*The Maximum End Pop MSD Type specifies the
> maximum number of SIDs in
> >      >
> >      >             the top SRH in an SRH stack to which the router can
> apply
> >      >         Penultimate
> >      >
> >      >             Segment Pop (PSP) or Ultimate Segment Pop (USP)
> >      >
> >      >         *//*
> >      >
> >      >         */NEW:/*The Maximum End Pop MSD Type specifies the
> maximum number of SIDs in
> >      >
> >      >             the SRH for which the router can apply Penultimate
> >      >
> >      >             Segment Pop (PSP) or Ultimate Segment Pop (USP)
> >      >
> >      >
> >      >
> >      >
> >      >         [ZQ] Fine.
> >      >
> >      >         2. The abbreviations used in this draft should be listed in a
> >      >         seperated section or point out where they are defined.
> >      >
> >      >         */[KT] We’ve followed the convention of expanding on
> first use
> >      >         as also providing reference where necessary. Please do let
> know
> >      >         if we’ve missed doing so anywhere./*
> >      >
> >      >         [ZQ] Some examples: SPF computation in secction 5,  TBD
> in
> >      >         section 2.
> >      >
> >      >         */[KT] Will expand SPF and some other such on first use :-).
> The
> >      >         TBD (to be decided) is for use until the code point are
> >      >         allocated by IANA./*
> >      >
> >      >         3. Algorithm field is defined for End.x SID to carry the
> >      >         algorithm the end.x sid associates. But no algorithm field is
> >      >         defined for End SID in section 7. May I know the reason?
> >      >
> >      >         */[KT] The SRv6 Locator TLV that is the parent of the SRv6
> End
> >      >         SID Sub-TLV carries the algorithm and hence there is no
> need to
> >      >         repeat in the Sub-TLV. This is not the case for SRv6 End.X
> SID
> >      >         Sub-TLV and hence it has the algorithm field./*
> >      >
> >      >         */
> >      >
> >      >
> >      >         /*
> >      >
> >      >         [ZQ] Make sense but still a little bit weird. Since any SID
> >      >         belongs to a locator, or it is not routable, the algorithm
> field
> >      >         in the end.x sid is not needed, end.x sid associates the
> >      >         algorithm carried in the corresponding locator tlv.
> >      >
> >      >         */[KT] Having an algorithm field advertised with the End.X
> SID
> >      >         makes it easier for implementation to find the algorithm
> >      >         specific End.X SID without making the longest prefix match
> on
> >      >         all locators advertised by the node to find the algorithm to
> >      >         which the SID belongs. It also makes it possible to verify
> that
> >      >         the algorithm associated with the End.X SID matches that
> of the
> >      >         covering Locator when the link advertisement with End.X
> SID is
> >      >         received. /*
> >      >
> >      >         *//*
> >      >
> >      >         */Thanks,/*
> >      >
> >      >         */Ketan/*
> >      >
> >      >         *//*
> >      >
> >      >         */Thanks,/*
> >      >
> >      >         */Ketan/*
> >      >
> >      >         Best Regards,
> >      >
> >      >         Zhenqiang Li
> >      >
> >      >         ------------------------------------------------------------------------
> >      >
> >      >         [email-masked]
> <mailto:[email-masked]>
> >      >
> >      >             *From:*Christian Hopps
> <mailto:[email-masked]>
> >      >
> >      >             *Date:* 2020-01-24 04:24
> >      >
> >      >             *To:*lsr <mailto:[email-masked]>
> >      >
> >      >             *CC:*draft-li-lsr-ospfv3-srv6-extensions
> >      >             <mailto:[email-masked]>;
> >      >             lsr-ads <mailto:[email-masked]>; Christian Hopps
> >      >             <mailto:[email-masked]>; Acee Lindem \(acee\)
> >      >             <mailto:[email-masked]>
> >      >
> >      >             *Subject:* [Lsr] WG Adoption Call for
> >      >             draft-li-lsr-ospfv3-srv6-extensions
> >      >
> >      >             Hi LSR WG and Draft Authors,
> >      >
> >      >             The authors originally requested adoption back @
> 105;
> >      >             however, some comments were received and new
> version was
> >      >             produced. Moving forward...
> >      >
> >      >             This begins a 2 week WG adoption poll for the
> following draft:
> >      >
> >      >
> https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
> >      >
> >      >             Please indicate your support or objection by Feb 6,
> 2020.
> >      >
> >      >             Authors, please respond indicating whether you are
> aware of
> >      >             any IPR that applies to this draft.
> >      >
> >      >             Thanks,
> >      >
> >      >             Chris & Acee.
> >      >
> >      >
> _______________________________________________
> >      >
> >      >             Lsr mailing list
> >      >
> >      >             [email-masked] <mailto:[email-masked]>
> >      >
> >      >             https://www.ietf.org/mailman/listinfo/lsr
> >      >
> >
> >
> >
> >
> >
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 1 Feb 2020 13:04:17 +0000

Hi Ketan, 

I agree the text proposed by Acee is better. In the flex-algo draft, there is no description of "specific algorithm topologies". OTOH, Flex-algo can specify the constraints on particular topologies.

Best regards,
Jie

> From: Lsr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, January 31, 2020 8:38 PM
> To: Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>; [email-masked]; Christian Hopps
> Thanks Acee. Your proposed text looks much better.
> 
> Thanks,
> Ketan
> 
> From: Acee Lindem (acee) <[email-masked]>
> Sent: 31 January 2020 18:02
> To: Ketan Talaulikar (ketant) <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>; [email-masked]; Christian Hopps
> Cc: draft-li-lsr-ospfv3-srv6-extensions
> <[email-masked]>; lsr-ads <[email-masked]>
> Hey Ketan,
> Looks good - but can we simplify/shorten the last sentence?
> 
> 
> On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)" <[email-masked]> wrote:
> 
>     Hi Acee,
> 
>     We'll update the text as follows in sec 8 to clarify this. Please let know if
> this works.
> 
>     <OLD/>
>        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.
>     </OLD>
> 
>     <NEW/>
>        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.
>     </NEW>
> 
> 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
> 
>     From: Acee Lindem (acee) <[email-masked]>
>     Sent: 30 January 2020 23:02
>     To: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar
> (ketant) <[email-masked]>; [email-masked]; Christian Hopps
>     Cc: draft-li-lsr-ospfv3-srv6-extensions
> <[email-masked]>; lsr-ads <[email-masked]>
>     On 1/30/20, 12:25 PM, "Peter Psenak" <[email-masked]> wrote:
> 
>         Hi Acee,
> 
>         >      > advertisement since you need to look it up to check it
> anyway. I don’t
>         >      > see any benefit here.
>         > 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
>         >      >
>         >      >     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
>         >      >
>         >      > <[email-masked]>; Christian Hopps
>         >      > 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
>         >      > behind the format design of the TLVs to help readers
> understand them
> Acee Lindem (acee)
>         >      >     Thank you KT for your quick response. Please see my
> reply begins
>         >      >     with [ZQ].
>         >      >
>         >      >     Best Regards,
>         >      >
>         >      >     Zhenqiang Li
>         >      >
>         >      >         Thanks for your review and comments. Please
> check inline below.
>         >      >
> <mailto:[email-masked]>>; Acee Lindem
>         >      >         (acee) <[email-masked]
> <mailto:[email-masked]>>
>         >      >         1. What does SRH stack mean in section 4.2? AS
> specified in
>         >      >         RFC8200 and
> draft-ietf-6man-segment-routing-header, only one SRH
>         >      >         */[KT] Thanks for catching this error and will fix
> as below:/*
>         >      >
>         >      >         *//*
>         >      >
>         >      >         */OLD: /*The Maximum End Pop MSD Type
> specifies the maximum number of SIDs in
>         >      >
>         >      >             the top SRH in an SRH stack to which the
> router can apply
>         >      >         Penultimate
>         >      >
>         >      >         */NEW:/*The Maximum End Pop MSD Type
> specifies the maximum number of SIDs in
>         >      >
>         >      >         */[KT] We’ve followed the convention of
> expanding on first use
>         >      >         as also providing reference where necessary.
> Please do let know
>         >      >         [ZQ] Some examples: SPF computation in
> secction 5,  TBD in
>         >      >         section 2.
>         >      >
>         >      >         */[KT] Will expand SPF and some other such on
> first use :-). The
>         >      >         */[KT] The SRv6 Locator TLV that is the parent of
> the SRv6 End
>         >      >         SID Sub-TLV carries the algorithm and hence
> there is no need to
>         >      >         repeat in the Sub-TLV. This is not the case for
> SRv6 End.X SID
>         >      >         belongs to a locator, or it is not routable, the
> algorithm field
>         >      >         */[KT] Having an algorithm field advertised with
> the End.X SID
>         >      >         specific End.X SID without making the longest
> prefix match on
>         >      >         which the SID belongs. It also makes it possible to
> verify that
>         >      >         the algorithm associated with the End.X SID
> matches that of the
>         >      >         covering Locator when the link advertisement
> with End.X SID is
>         >      >         received. /*
>         >      >
>         >      >         *//*
>         >      >
>         >      >         */Thanks,/*
>         >      >
>         >      >         */Ketan/*
>         >      >
>         >      >         *//*
>         >      >
>         >      >         */Thanks,/*
>         >      >
>         >      >         */Ketan/*
>         >      >
>         >      >         Best Regards,
>         >      >
>         >      >         Zhenqiang Li
>         >      >
>         >      >
>         >      >             The authors originally requested adoption
> back @ 105;
>         >      >             however, some comments were received
> and new version was
>         >      >             This begins a 2 week WG adoption poll for
> the following draft:
>         >      >
>         >      >
>         >      >             Please indicate your support or objection by
> Feb 6, 2020.
>         >      >
>         >      >             Authors, please respond indicating whether
> you are aware of

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Feb 2020 10:08:13 +0100

Hi Jie,

please see inline:

> In what scenarios will the longest match locator of the END.X SID be advertised by a different router? Does this only happen due to bug or misconfiguration?

it's not the different OSPFv3 router, it's a different LSA/LSP.
> In this case just checking the algorithm may not be enough, if the algorithm happens to be the same, will the END.X SID be considered valid and be used by transit nodes to route towards the origina…

if the algo is the same, then the locator is correct. What else do you 
want to check?

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 3 Feb 2020 14:36:21 +0000

Hi Peter, 

Thanks for your reply. Please see inline:

> From: Peter Psenak [mailto:[email-masked]]
> Sent: Monday, February 3, 2020 5:08 PM
> To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>;
> [email-masked]; Christian Hopps <[email-masked]>; lsr
> <[email-masked]>
> >>> anyway. I
> >> for the longest match locator - which may be advertised by a
> >> >different
> >> OSPFv3 router. Correct?
> >>
> >> yes.
> >
> > In what scenarios will the longest match locator of the END.X SID be
> advertised by a different router? Does this only happen due to bug or
> misconfiguration?
> 

This sounds more reasonable. But the above case mentioned by Acee is also possible, one example is during locator reconfiguration as you mentioned below. 

> >>> 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.
> >
> > In this case just checking the algorithm may not be enough, if the algorithm
> happens to be the same, will the END.X SID be considered valid and be used by
> transit nodes to route towards the originator of the incorrect locator? Some
> mechanism needs to be considered to avoid using invalid END.X SIDs in such
> case.
> 
> if the algo is the same, then the locator is correct. What else do you want to
> check?

During the reconfiguration of a locator on one node, is it possible that the longest match locator of the END.X SID is from another node? And the algorithm may happen to be the same. In this case it is necessary to add that the END.X SID is considered invalid if its longest match locator is not from the originating router of this SID. After checking the draft I think this is already covered in the last paragraph of section 8, so it should be OK. 

BTW, I support the adoption of this document. 

Best regards,
Jie

> Locator
> requirement
> >>> Adjacency
> >>> take
> >>> understand
> specified
> verify

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Feb 2020 15:44:11 +0100

Hi Jie,

please see inline (##PP):

> This sounds more reasonable. But the above case mentioned by Acee is also possible, one example is during locator reconfiguration as you mentioned below.

##PP
well, the locator from other node should not be used to resolve the SID.

> During the reconfiguration of a locator on one node, is it possible that the longest match locator of the END.X SID is from another node? And the algorithm may happen to be the same. In this case i…

##PP
right.

thanks,
Peter