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

["Dongjie (Jimmy)" <[e-mail]>]

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

> -----Original Message-----
> From: Lsr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, January 31, 2020 8:38 PM
> To: Acee Lindem (acee) <[e-mail]>; Peter Psenak (ppsenak)
> <[e-mail]>; [e-mail]; Christian Hopps
> <[e-mail]>; lsr <[e-mail]>
> Cc: lsr-ads <[e-mail]>; draft-li-lsr-ospfv3-srv6-extensions
> <[e-mail]>
> Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
> 
> Thanks Acee. Your proposed text looks much better.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Acee Lindem (acee) <[e-mail]>
> Sent: 31 January 2020 18:02
> To: Ketan Talaulikar (ketant) <[e-mail]>; Peter Psenak (ppsenak)
> <[e-mail]>; [e-mail]; Christian Hopps
> <[e-mail]>; lsr <[e-mail]>
> Cc: draft-li-lsr-ospfv3-srv6-extensions
> <[e-mail]>; lsr-ads <[e-mail]>
> 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)" <[e-mail]> 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
> 
>     -----Original Message-----
>     From: Acee Lindem (acee) <[e-mail]>
>     Sent: 30 January 2020 23:02
>     To: Peter Psenak (ppsenak) <[e-mail]>; Ketan Talaulikar
> (ketant) <[e-mail]>; [e-mail]; Christian Hopps
> <[e-mail]>; lsr <[e-mail]>
>     Cc: draft-li-lsr-ospfv3-srv6-extensions
> <[e-mail]>; lsr-ads <[e-mail]>
>     Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
> 
>     Hi Peter,
> 
>     On 1/30/20, 12:25 PM, "Peter Psenak" <[e-mail]> wrote:
> 
>         Hi Acee,
> 
>         On 30/01/2020 18:12, Acee Lindem (acee) wrote:
>         > Hi Peter,
>         >
>         > On 1/30/20, 11:36 AM, "Peter Psenak" <[e-mail]>
> 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)" <[e-mail]>
>         >      > *Date: *Thursday, January 30, 2020 at 11:06 AM
>         >      > *To: *Acee Lindem <[e-mail]>,
> "[e-mail]"
>         >      > <[e-mail]>, Christian Hopps
> <[e-mail]>, lsr
>         >      > <[e-mail]>
>         >      > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>         >      > <[e-mail]>, lsr-ads
> <[e-mail]>
>         >      > *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) <[e-mail]>
>         >      > *Sent:* 30 January 2020 21:01
>         >      > *To:* [e-mail]; Ketan Talaulikar (ketant)
>         >      > <[e-mail]>; Christian Hopps
> <[e-mail]>; lsr <[e-mail]>
>         >      > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>         >      > <[e-mail]>; lsr-ads
> <[e-mail]>
>         >      > *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: *"[e-mail]
> <mailto:[e-mail]>"
>         >      > <[e-mail]
> <mailto:[e-mail]>>
>         >      > *Date: *Thursday, January 30, 2020 at 10:20 AM
>         >      > *To: *"Ketan Talaulikar (ketant)" <[e-mail]
>         >      > <mailto:[e-mail]>>, Christian Hopps
> <[e-mail]
>         >      > <mailto:[e-mail]>>, lsr <[e-mail]
> <mailto:[e-mail]>>
>         >      > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>         >      > <[e-mail]
>         >      > <mailto:[e-mail]>>,
> lsr-ads
>         >      > <[e-mail] <mailto:[e-mail]>>, Christian
> Hopps
>         >      > <[e-mail] <mailto:[e-mail]>>, Acee
> Lindem
>         >      > <[e-mail] <mailto:[e-mail]>>
>         >      > *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
>         >      >
>         >      > ------------------------------------------------------------------------
>         >      >
>         >      > [e-mail]
> <mailto:[e-mail]>
>         >      >
>         >      >     *From:*Ketan Talaulikar (ketant)
> <mailto:[e-mail]>
>         >      >
>         >      >     *Date:* 2020-01-30 16:44
>         >      >
>         >      >     *To:*[e-mail]
> <mailto:[e-mail]>;
>         >      >     Christian Hopps <mailto:[e-mail]>; lsr
> <mailto:[e-mail]>
>         >      >
>         >      >     *CC:*draft-li-lsr-ospfv3-srv6-extensions
>         >      >     <mailto:[e-mail]>;
> lsr-ads
>         >      >     <mailto:[e-mail]>; Christian Hopps
>         >      >     <mailto:[e-mail]>; Acee Lindem (acee)
> <mailto:[e-mail]>
>         >      >
>         >      >     *Subject:* RE: RE: [Lsr] WG Adoption Call for
>         >      >     draft-li-lsr-ospfv3-srv6-extensions
>         >      >
>         >      >     Please check inline again.
>         >      >
>         >      >     *From:* [e-mail]
> <mailto:[e-mail]>
>         >      >     <[e-mail]
> <mailto:[e-mail]>>
>         >      >     *Sent:* 30 January 2020 13:46
>         >      >     *To:* Ketan Talaulikar (ketant) <[e-mail]
>         >      >     <mailto:[e-mail]>>; Christian Hopps
> <[e-mail]
>         >      >     <mailto:[e-mail]>>; lsr <[e-mail]
> <mailto:[e-mail]>>
>         >      >     *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>         >      >     <[e-mail]
>         >      >     <mailto:[e-mail]>>;
> lsr-ads
>         >      >     <[e-mail] <mailto:[e-mail]>>; Christian
> Hopps
>         >      >     <[e-mail] <mailto:[e-mail]>>;
> Acee Lindem (acee)
>         >      >     <[e-mail] <mailto:[e-mail]>>
>         >      >     *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
>         >      >
>         >      >     ------------------------------------------------------------------------
>         >      >
>         >      >     [e-mail]
> <mailto:[e-mail]>
>         >      >
>         >      >         *From:*Ketan Talaulikar (ketant)
> <mailto:[e-mail]>
>         >      >
>         >      >         *Date:* 2020-01-30 13:42
>         >      >
>         >      >         *To:*[e-mail]
> <mailto:[e-mail]>;
>         >      >         Christian Hopps <mailto:[e-mail]>;
> lsr
>         >      >         <mailto:[e-mail]>
>         >      >
>         >      >         *CC:*draft-li-lsr-ospfv3-srv6-extensions
>         >      >
> <mailto:[e-mail]>; lsr-ads
>         >      >         <mailto:[e-mail]>; Christian Hopps
>         >      >         <mailto:[e-mail]>; Acee Lindem
> (acee)
>         >      >         <mailto:[e-mail]>
>         >      >
>         >      >         *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:*[e-mail]
>         >      >         <mailto:[e-mail]>
> <[e-mail]
>         >      >         <mailto:[e-mail]>>
>         >      >         *Sent:* 30 January 2020 08:46
>         >      >         *To:* Christian Hopps <[e-mail]
>         >      >         <mailto:[e-mail]>>; lsr <[e-mail]
>         >      >         <mailto:[e-mail]>>
>         >      >         *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>         >      >         <[e-mail]
>         >      >
> <mailto:[e-mail]>>; lsr-ads
>         >      >         <[e-mail] <mailto:[e-mail]>>;
> Christian Hopps
>         >      >         <[e-mail]
> <mailto:[e-mail]>>; Acee Lindem
>         >      >         (acee) <[e-mail]
> <mailto:[e-mail]>>
>         >      >         *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
>         >      >
>         >      >
> ------------------------------------------------------------------------
>         >      >
>         >      >         [e-mail]
> <mailto:[e-mail]>
>         >      >
>         >      >             *From:*Christian Hopps
> <mailto:[e-mail]>
>         >      >
>         >      >             *Date:* 2020-01-24 04:24
>         >      >
>         >      >             *To:*lsr <mailto:[e-mail]>
>         >      >
>         >      >             *CC:*draft-li-lsr-ospfv3-srv6-extensions
>         >      >
> <mailto:[e-mail]>;
>         >      >             lsr-ads <mailto:[e-mail]>; Christian
> Hopps
>         >      >             <mailto:[e-mail]>; Acee Lindem
> \(acee\)
>         >      >             <mailto:[e-mail]>
>         >      >
>         >      >             *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
>         >      >
>         >      >             [e-mail] <mailto:[e-mail]>
>         >      >
>         >      >             https://www.ietf.org/mailman/listinfo/lsr
>         >      >
>         >
>         >
>         >
>         >
>         >
> 
> 
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr