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