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)" <ket...@cisco.com>
Date: Thursday, January 30, 2020 at 11:06 AM
To: Acee Lindem <a...@cisco.com>, "li_zhenqi...@hotmail.com" 
<li_zhenqi...@hotmail.com>, Christian Hopps <cho...@chopps.org>, lsr 
<lsr@ietf.org>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>, lsr-ads <lsr-...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Acee/Zhen,

The sec 8 of the draft has the following text which specifies the handling of 
this condition.

   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.

Thanks,
Ketan

From: Acee Lindem (acee) <a...@cisco.com>
Sent: 30 January 2020 21:01
To: li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant) <ket...@cisco.com>; 
Christian Hopps <cho...@chopps.org>; lsr <lsr@ietf.org>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>; lsr-ads <lsr-...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Ketan, Zhen,

What happens if there an algorithm conflict between the Adjacency END.X SID and 
the longest match Locator SID? Either one has to take precedence or this is an 
error condition. In either case, it needs to be documented.
Thanks,
Acee

From: "li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>" 
<li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>>
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>, lsr 
<lsr@ietf.org<mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 lsr-ads <lsr-...@ietf.org<mailto:lsr-...@ietf.org>>, Christian Hopps 
<cho...@chopps.org<mailto:cho...@chopps.org>>, Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

For the third concern, I think it is better to list the considerations behind 
the format design of the TLVs to help readers understand them better. For the 
specification behavior you mention, this doc SHOULD specify it explicitly.
By the way, what a router should do when it receives END.X SID containing 
algorithm that is different from the one carried in the convering locator?

Best Regards,
Zhenqiang Li
________________________________
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 16:44
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Please check inline again.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
<li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; 
Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; lsr 
<lsr@ietf.org<mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads <lsr-...@ietf.org<mailto:lsr-...@ietf.org>>; Christian Hopps 
<cho...@chopps.org<mailto:cho...@chopps.org>>; Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li
________________________________
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

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

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
<li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; lsr 
<lsr@ietf.org<mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads <lsr-...@ietf.org<mailto:lsr-...@ietf.org>>; Christian Hopps 
<cho...@chopps.org<mailto:cho...@chopps.org>>; Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to which the router can apply Penultimate
   Segment Pop (PSP) or Ultimate Segment Pop (USP)


NEW: The Maximum End Pop MSD Type specifies the maximum number of SIDs in

   the SRH for which the router can apply Penultimate

   Segment Pop (PSP) or Ultimate Segment Pop (USP)



[ZQ] Fine.

2. The abbreviations used in this draft should be listed in a seperated section 
or point out where they are defined.
[KT] We’ve followed the convention of expanding on first use as also providing 
reference where necessary. Please do let know if we’ve missed doing so anywhere.

[ZQ] Some examples: SPF computation in secction 5,  TBD in section 2.
[KT] Will expand SPF and some other such on first use :-). The TBD (to be 
decided) is for use until the code point are allocated by IANA.

3. Algorithm field is defined for End.x SID to carry the algorithm the end.x 
sid associates. But no algorithm field is defined for End SID in section 7. May 
I know the reason?
[KT] The SRv6 Locator TLV that is the parent of the SRv6 End SID Sub-TLV 
carries the algorithm and hence there is no need to repeat in the Sub-TLV. This 
is not the case for SRv6 End.X SID Sub-TLV and hence it has the algorithm field.



[ZQ] Make sense but still a little bit weird. Since any SID belongs to a 
locator, or it is not routable, the algorithm field in the end.x sid is not 
needed, end.x sid associates the algorithm carried in the corresponding locator 
tlv.

[KT] Having an algorithm field advertised with the End.X SID makes it easier 
for implementation to find the algorithm specific End.X SID without making the 
longest prefix match on all locators advertised by the node to find the 
algorithm to which the SID belongs. It also makes it possible to verify that 
the algorithm associated with the End.X SID matches that of the covering 
Locator when the link advertisement with End.X SID is received.



Thanks,

Ketan

Thanks,
Ketan

Best Regards,
Zhenqiang Li
________________________________
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Christian Hopps<mailto:cho...@chopps.org>
Date: 2020-01-24 04:24
To: lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem \(acee\)<mailto:a...@cisco.com>
Subject: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to