Hi Tom,
Apologies for the delayed response. Thanks for your time reading the draft and
for the feedback. See some comments inline.
On 3/5/18, 4:42 PM, "Tom Herbert" wrote:
Thanks for posting the draft!
Overall, I think the approach straightforward, and it's very nice that
the
Dino,
On 3/5/18, 5:00 PM, "Dino Farinacci" wrote:
My comment about this spec is that you really don’t need a LCAF format to
format the addresses. You can use AFI=2 and use IPv6 format. That will reduce
the size.
Using IPv6 format is something we considered while writing the draft
> Using IPv6 format is something we considered while writing the draft. We went
> the LCAF route to have an explicit way to (1) distinguish ILA
> Identifiers/Locators from other addresses in the Mapping System, (2) specify
> the Identifier/Locator length and (3) include metadata bits. However, f
On Tue, Mar 13, 2018 at 12:28 PM, Alberto Rodriguez Natal (natal)
wrote:
> Hi Tom,
>
> Apologies for the delayed response. Thanks for your time reading the draft
> and for the feedback. See some comments inline.
>
> On 3/5/18, 4:42 PM, "Tom Herbert" wrote:
>
> Thanks for posting the draft!
On 3/13/18, 12:56 PM, "Dino Farinacci" wrote:
> Using IPv6 format is something we considered while writing the draft. We
went the LCAF route to have an explicit way to (1) distinguish ILA
Identifiers/Locators from other addresses in the Mapping System, (2) specify
the Identifier/Locator
On 3/13/18, 1:05 PM, "Tom Herbert" wrote:
>
> This is reflected below in: "While the mapping is being resolved via
> the Map-Request/ Map-Reply process, the ILA-N can send the data
> packets to the underlay using the SIR address."
>
> I think it should b
On Tue, Mar 13, 2018 at 3:50 PM, Alberto Rodriguez Natal (natal)
wrote:
>
>
> On 3/13/18, 1:05 PM, "Tom Herbert" wrote:
> >
> > This is reflected below in: "While the mapping is being resolved via
> > the Map-Request/ Map-Reply process, the ILA-N can send the data
> >
On 3/13/18, 4:27 PM, "Tom Herbert" wrote:
>
Yes, but you are ignoring the load on the mapping servers which also
needs to scale.
I completely agree that the Mapping System needs to scale. The LISP community
has extensively explored that over the years and has come up with several
Not sure about ILA-R but typically when deploying LISP, RTR/Proxy-ITRs have
enough memory to store most, if not all, of the identity to location mappings.
Therefore, once in steady state, most of the requests to the mapping system are
triggered by edge devices ITR/ILA-N.
This then means that j
On Tue, Mar 13, 2018 at 6:37 PM, Florin Coras wrote:
> Not sure about ILA-R but typically when deploying LISP, RTR/Proxy-ITRs have
> enough memory to store most, if not all, of the identity to location
> mappings. Therefore, once in steady state, most of the requests to the
> mapping system are tr
》 enlightening or convincing. I am really hoping we can get something
》more concrete for dealing with DOS threats in a control plane for ILA.
Isn’t DOS a data plane problem?
Richard
From: Tom Herbert
To: Florin Coras;
Cc: i...@ietf.org; lisp@ietf.org;
Subject: Re: [lisp] [Ila] LISP for ILA
Time:
On Tue, Mar 13, 2018 at 10:46 PM, Richard Li wrote:
> 》 enlightening or convincing. I am really hoping we can get something
> 》more concrete for dealing with DOS threats in a control plane for ILA.
>
> Isn’t DOS a data plane problem?
>
Richard,
The potential attack is on the mapping cache that ne
12 matches
Mail list logo
