Hey Ketan, 

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


On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)" <ket...@cisco.com> 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) <a...@cisco.com> 
    Sent: 30 January 2020 23:02
    To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar (ketant) 
<ket...@cisco.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 Peter, 
    
    On 1/30/20, 12:25 PM, "Peter Psenak" <ppse...@cisco.com> wrote:
    
        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.
    
    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)" <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