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

2020-02-01 Thread Dongjie (Jimmy) 
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:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, January 31, 2020 8:38 PM
> To: Acee Lindem (acee) ; Peter Psenak (ppsenak)
> ; li_zhenqi...@hotmail.com; Christian Hopps
> ; lsr 
> Cc: lsr-ads ; draft-li-lsr-ospfv3-srv6-extensions
> 
> 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) 
> 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
> >

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

2020-02-01 Thread Dongjie (Jimmy) 
Hi Peter,

Please see some comments inline:

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, January 31, 2020 1:24 AM
> To: Acee Lindem (acee) ; Ketan Talaulikar (ketant)
> ; li_zhenqi...@hotmail.com; Christian Hopps
> ; lsr 
> Cc: lsr-ads ; draft-li-lsr-ospfv3-srv6-extensions
> 
> 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"  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)" 
> >  > *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,
> >  >
> >  > Acee
> >  >
> >  > *From: *"li_zhenqi...@hotmail.com
> "
> >  > mailto:li_zhenqi...@hotmail.com>>
> >  > *Date: *Thursday, January 30, 2020 at 10:20 AM
> >  > *To: *"Ketan Talaulikar (ketant)"  >  > >, Christian Hopps  >  > >, lsr  >
> >  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
> >  >  >  > >, lsr-ads
> >  > mailto:lsr-...@ietf.org>>, Christian Hopps
> >  > mailto:cho...@chopps.org>>, Acee Lindem
> >  > mailto:a...@cisco.com>>
> >  > *Subject: *Re: RE: [Lsr] WG Adoption Call for
> >