Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
Hi Peter,

On 1/30/20, 11:36 AM, "Peter Psenak" <ppse...@cisco.com> 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.

thanks,
Peter




Thanks,
Acee

thanks,
     Peter
>
     > Thanks,
     >
     > Acee
     >
     > *From: *"Ketan Talaulikar (ketant)" <ket...@cisco.com>
     > *Date: *Thursday, January 30, 2020 at 11:06 AM
     > *To: *Acee Lindem <a...@cisco.com>, "li_zhenqi...@hotmail.com"
     > <li_zhenqi...@hotmail.com>, Christian Hopps <cho...@chopps.org>, lsr
     > <lsr@ietf.org>
     > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
     > <draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>, lsr-ads 
<lsr-...@ietf.org>
     > *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) <a...@cisco.com>
     > *Sent:* 30 January 2020 21:01
     > *To:* li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant)
     > <ket...@cisco.com>; Christian Hopps <cho...@chopps.org>; lsr 
<lsr@ietf.org>
     > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
     > <draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>; lsr-ads 
<lsr-...@ietf.org>
     > *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: *"li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>"
     > <li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>>
     > *Date: *Thursday, January 30, 2020 at 10:20 AM
     > *To: *"Ketan Talaulikar (ketant)" <ket...@cisco.com
     > <mailto:ket...@cisco.com>>, Christian Hopps <cho...@chopps.org
     > <mailto:cho...@chopps.org>>, lsr <lsr@ietf.org <mailto:lsr@ietf.org>>
     > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
     > <draft-li-lsr-ospfv3-srv6-extensi...@ietf.org
     > <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>, lsr-ads
     > <lsr-...@ietf.org <mailto:lsr-...@ietf.org>>, Christian Hopps
     > <cho...@chopps.org <mailto:cho...@chopps.org>>, Acee Lindem
     > <a...@cisco.com <mailto:a...@cisco.com>>
     > *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
     >
     > ------------------------------------------------------------------------
     >
     > li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>
     >
     >     *From:*Ketan Talaulikar (ketant) <mailto:ket...@cisco.com>
     >
     >     *Date:* 2020-01-30 16:44
     >
     >     *To:*li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>;
     >     Christian Hopps <mailto:cho...@chopps.org>; lsr <mailto:lsr@ietf.org>
     >
     >     *CC:*draft-li-lsr-ospfv3-srv6-extensions
     >     <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>; lsr-ads
     >     <mailto:lsr-...@ietf.org>; Christian Hopps
     >     <mailto:cho...@chopps.org>; Acee Lindem (acee) 
<mailto:a...@cisco.com>
     >
     >     *Subject:* RE: RE: [Lsr] WG Adoption Call for
     >     draft-li-lsr-ospfv3-srv6-extensions
     >
     >     Please check inline again.
     >
     >     *From:* li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>
     >     <li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>>
     >     *Sent:* 30 January 2020 13:46
     >     *To:* Ketan Talaulikar (ketant) <ket...@cisco.com
     >     <mailto:ket...@cisco.com>>; Christian Hopps <cho...@chopps.org
     >     <mailto:cho...@chopps.org>>; lsr <lsr@ietf.org <mailto:lsr@ietf.org>>
     >     *Cc:* draft-li-lsr-ospfv3-srv6-extensions
     >     <draft-li-lsr-ospfv3-srv6-extensi...@ietf.org
     >     <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>; lsr-ads
     >     <lsr-...@ietf.org <mailto:lsr-...@ietf.org>>; Christian Hopps
     >     <cho...@chopps.org <mailto:cho...@chopps.org>>; Acee Lindem (acee)
     >     <a...@cisco.com <mailto:a...@cisco.com>>
     >     *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
     >
     >     
------------------------------------------------------------------------
     >
     >     li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>
     >
     >         *From:*Ketan Talaulikar (ketant) <mailto:ket...@cisco.com>
     >
     >         *Date:* 2020-01-30 13:42
     >
     >         *To:*li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>;
     >         Christian Hopps <mailto:cho...@chopps.org>; lsr
     >         <mailto:lsr@ietf.org>
     >
     >         *CC:*draft-li-lsr-ospfv3-srv6-extensions
     >         <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>; lsr-ads
     >         <mailto:lsr-...@ietf.org>; Christian Hopps
     >         <mailto:cho...@chopps.org>; Acee Lindem (acee)
     >         <mailto:a...@cisco.com>
     >
     >         *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:*li_zhenqi...@hotmail.com
     >         <mailto:li_zhenqi...@hotmail.com> <li_zhenqi...@hotmail.com
     >         <mailto:li_zhenqi...@hotmail.com>>
     >         *Sent:* 30 January 2020 08:46
     >         *To:* Christian Hopps <cho...@chopps.org
     >         <mailto:cho...@chopps.org>>; lsr <lsr@ietf.org
     >         <mailto:lsr@ietf.org>>
     >         *Cc:* draft-li-lsr-ospfv3-srv6-extensions
     >         <draft-li-lsr-ospfv3-srv6-extensi...@ietf.org
     >         <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>; lsr-ads
     >         <lsr-...@ietf.org <mailto:lsr-...@ietf.org>>; Christian Hopps
     >         <cho...@chopps.org <mailto:cho...@chopps.org>>; Acee Lindem
     >         (acee) <a...@cisco.com <mailto:a...@cisco.com>>
     >         *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
     >
     >         
------------------------------------------------------------------------
     >
     >         li_zhenqi...@hotmail.com <mailto:li_zhenqi...@hotmail.com>
     >
     >             *From:*Christian Hopps <mailto:cho...@chopps.org>
     >
     >             *Date:* 2020-01-24 04:24
     >
     >             *To:*lsr <mailto:lsr@ietf.org>
     >
     >             *CC:*draft-li-lsr-ospfv3-srv6-extensions
     >             <mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
     >             lsr-ads <mailto:lsr-...@ietf.org>; Christian Hopps
     >             <mailto:cho...@chopps.org>; Acee Lindem \(acee\)
     >             <mailto:a...@cisco.com>
     >
     >             *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
     >
     >             Lsr@ietf.org <mailto:Lsr@ietf.org>
     >
     >             https://www.ietf.org/mailman/listinfo/lsr
     >



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

Reply via email to