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) <jie.d...@huawei.com>; Acee Lindem (acee)
<a...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>;
li_zhenqi...@hotmail.com; Christian Hopps <cho...@chopps.org>; lsr
<lsr@ietf.org>
Cc: lsr-ads <lsr-...@ietf.org>; draft-li-lsr-ospfv3-srv6-extensions
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>
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) <a...@cisco.com>; Ketan Talaulikar (ketant)
<ket...@cisco.com>; li_zhenqi...@hotmail.com; Christian Hopps
<cho...@chopps.org>; lsr <lsr@ietf.org>
Cc: lsr-ads <lsr-...@ietf.org>; draft-li-lsr-ospfv3-srv6-extensions
<draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>
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" <ppse...@cisco.com> 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)" <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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
