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

2020-02-12 Thread Ketan Talaulikar (ketant)
Hi Chris/Acee,

The WG version of the draft has just been posted. It also includes the changes 
for the comments received during the adoption as discussed on the mailing list.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Christian Hopps  
Sent: 12 February 2020 16:42
To: lsr@ietf.org
Cc: Christian Hopps ; 
draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Acee Lindem 
(acee) 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

The document is adopted.

Authors, please repost as draft-ietf-lsr-ospfv3-srv6-extensions.

Thanks,
Chris & Acee.

> On Jan 23, 2020, at 3:24 PM, Christian Hopps  wrote:
> 
> 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
> https://www.ietf.org/mailman/listinfo/lsr
> 

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


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

2020-02-12 Thread Christian Hopps
The document is adopted.

Authors, please repost as draft-ietf-lsr-ospfv3-srv6-extensions.

Thanks,
Chris & Acee.

> On Jan 23, 2020, at 3:24 PM, Christian Hopps  wrote:
> 
> 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
> https://www.ietf.org/mailman/listinfo/lsr
> 

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


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

2020-02-12 Thread stefano previdi
support.

s.


> On Jan 23, 2020, at 9:24 PM, Christian Hopps  wrote:
> 
> 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
> https://www.ietf.org/mailman/listinfo/lsr

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


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

2020-02-03 Thread Peter Psenak

Hi Jie,

please see inline (##PP):

On 03/02/2020 15:36, Dongjie (Jimmy) wrote:

Hi Peter,

Thanks for your reply. Please see inline:


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, February 3, 2020 5:08 PM
To: Dongjie (Jimmy) ; 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 Jie,

please see inline:


On 01/02/2020 13:53, Dongjie (Jimmy) wrote:

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?

it's not the different OSPFv3 router, it's a different LSA/LSP.


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.










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.

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.


##PP
right.

thanks,
Peter



BTW, I support the adoption of this document.

Best regards,
Jie



thanks,
Peter




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

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

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

Thanks for your reply. Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Monday, February 3, 2020 5:08 PM
> To: Dongjie (Jimmy) ; 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 Jie,
> 
> please see inline:
> 
> 
> On 01/02/2020 13:53, Dongjie (Jimmy) wrote:
> > 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?
> 
> it's not the different OSPFv3 router, it's a different LSA/LSP.

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

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

> 
> thanks,
> Peter
> 
> 
> >
> > 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

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

2020-02-03 Thread Peter Psenak

Hi Jie,

please see inline:


On 01/02/2020 13:53, Dongjie (Jimmy) wrote:

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?


it's not the different OSPFv3 router, it's a different LSA/LSP.






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.


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


thanks,
Peter




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

  > mailto:li_zhenqi...@hotmail.com>>
  > *Date: *Thursday, January 30, 2020 at 10:20 AM
  > *To: *"Ketan Talaulikar (ketant)"  <mailto:ket...@cisco.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
  

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 adverti

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 n

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

2020-01-31 Thread Ketan Talaulikar (ketant)
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
>  
>  >
>  > 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: [

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

2020-01-31 Thread Acee Lindem (acee)
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
>  
>  >
>  > 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 sub

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

2020-01-31 Thread Ketan Talaulikar (ketant)
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. 


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

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

2020-01-30 Thread Acee Lindem (acee)
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
>  
>  >
>  > 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>"
>  > mailto:li_zhenqi...@hotmail.com>>
>  > *Date: *Thursday, January 30, 2020 at 10:20 AM
>      > *To: *"Ketan Talaulikar (ketant)"   > <mailto:ket...@cisco.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...@ch

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

2020-01-30 Thread Peter Psenak

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.


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>"
 > mailto:li_zhenqi...@hotmail.com>>
 > *Date: *Thursday, January 30, 2020 at 10:20 AM
 > *To: *"Ketan Talaulikar (ketant)"  <mailto:ket...@cisco.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
 > 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 &

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

2020-01-30 Thread Acee Lindem (acee)
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? 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? 

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>" 
> mailto:li_zhenqi...@hotmail.com>>
> *Date: *Thursday, January 30, 2020 at 10:20 AM
> *To: *"Ketan Talaulikar (ketant)"  <mailto:ket...@cisco.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 
> 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
> 
>

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

2020-01-30 Thread Peter Psenak

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.


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>" 
mailto:li_zhenqi...@hotmail.com>>

*Date: *Thursday, January 30, 2020 at 10:20 AM
*To: *"Ketan Talaulikar (ketant)" <mailto:ket...@cisco.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 
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>
mailto:li_zhenqi...@hotmail.com>>
*Sent:* 30 January 2020 13:46
*To:* Ketan Talaulikar (ketant) mailto:ket...@cisco.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

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

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

2020-01-30 Thread Acee Lindem (acee)
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.
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>" 
mailto:li_zhenqi...@hotmail.com>>
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.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 
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> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.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

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> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: 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...@cisc

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

2020-01-30 Thread Ketan Talaulikar (ketant)
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>" 
mailto:li_zhenqi...@hotmail.com>>
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.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 
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> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.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

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> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: 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

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 whic

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

2020-01-30 Thread Acee Lindem (acee)
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" 
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 , 
Christian Hopps , Acee Lindem 
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

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 
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) ; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
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> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: 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

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

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

2020-01-30 Thread Ketan Talaulikar (ketant)
Please check inline again.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) ; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
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> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: 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

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 

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

2020-01-29 Thread Ketan Talaulikar (ketant)
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 08:46
To: Christian Hopps ; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
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)

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.

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.

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


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

2020-01-28 Thread Zhuangshunwan
Support.

Thanks,
Shunwan

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Friday, January 24, 2020 4:25 AM
To: lsr@ietf.org
Cc: draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Christian 
Hopps ; Acee Lindem (acee) 
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
https://www.ietf.org/mailman/listinfo/lsr

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


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

2020-01-26 Thread Lizhenbin

Support. Not aware of any undisclosed IPR.

Best Regards,
Zhenbin (Robin)

--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com

发件人:Christian Hopps 
收件人:lsr 
抄 送:Christian Hopps ;Acee Lindem (acee) 
;lsr-ads ;draft-li-lsr-ospfv3-srv6-extensions 

时 间:2020-01-24 04:24:51
主 题: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
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-24 Thread Les Ginsberg (ginsberg)
I support adopting this draft.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Thursday, January 23, 2020 12:25 PM
> To: lsr@ietf.org
> Cc: draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Christian
> Hopps ; Acee Lindem (acee) 
> 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
> https://www.ietf.org/mailman/listinfo/lsr

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


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

2020-01-24 Thread Ketan Talaulikar (ketant)
Hi All,

Support the draft as a co-author and I am not aware of any IPR other than what 
has been disclosed on this draft.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 24 January 2020 01:55
To: lsr@ietf.org
Cc: Christian Hopps ; Acee Lindem (acee) ; 
lsr-...@ietf.org; draft-li-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: 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
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-24 Thread Acee Lindem (acee)
Speaking as WG member:

I have reviewed the document and my comments have been incorporated. I support 
WG adoption.

Thanks,
Acee

On 1/23/20, 3:25 PM, "Lsr on behalf of Christian Hopps"  wrote:

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
https://www.ietf.org/mailman/listinfo/lsr


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


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

2020-01-24 Thread Peter Psenak

Hi Chris, Acee,

as a coauthor, I support the WG adoption of this document.

I'm not aware of any undisclosed IPRs.

thanks,
Peter



On 23/01/2020 21:24, Christian Hopps wrote:

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
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-24 Thread Xiejingrong (Jingrong)
support.

From:Christian Hopps 
To:lsr 
Cc:draft-li-lsr-ospfv3-srv6-extensions 
;lsr-ads 
;Christian Hopps ;Acee Lindem (acee) 

Date:2020-01-24 04:25:11
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
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-24 Thread Huzhibo
Support. Not aware of any undisclosed IPR.

Zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人:Christian Hopps 
收件人:lsr 
抄 送:draft-li-lsr-ospfv3-srv6-extensions 
;lsr-ads 
;Christian Hopps ;Acee Lindem (acee) 

时 间:2020-01-24 04:25:13
主 题:[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
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-24 Thread Huaimo Chen
Support.



Best Regards,

Huaimo



From: Lsr  on behalf of Christian Hopps 

Date: Thursday, January 23, 2020 at 3:25 PM
To: "lsr@ietf.org" 
Cc: "draft-li-lsr-ospfv3-srv6-extensi...@ietf.org" 
, "lsr-...@ietf.org" 
, Christian Hopps , "Acee Lindem (acee)" 

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

https://www.ietf.org/mailman/listinfo/lsr


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


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

2020-01-24 Thread Zafar Ali (zali)
Support!

Thanks

Regards … Zafar

From: Lsr  on behalf of Christian Hopps 

Date: Thursday, January 23, 2020 at 3:25 PM
To: "lsr@ietf.org" 
Cc: "draft-li-lsr-ospfv3-srv6-extensi...@ietf.org" 
, "lsr-...@ietf.org" 
, Christian Hopps , "Acee Lindem (acee)" 

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
https://www.ietf.org/mailman/listinfo/lsr

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