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