On Wed, May 17, 2017 at 12:53 AM, Tom Herbert <t...@herbertland.com> wrote:
> On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <j...@joelhalpern.com> > wrote: > > If we want the documents to be informational, then it should be about a > > context where we understand how to build the surrounding infrastructure. > > For example, if it were documented for data centers, based on Facebook's > > experience, I would have trouble objecting to informational publication. > > > > If we do not know where it applies, and what to try it out in various > > contexts with various control setups, then that sounds like experimental > > RFCs. While I have my doubts about some of the applicability, that > should > > not stop useful experimentation. > > > > But an informational document that says that this can be used (roughly > > speaking) ~anywhere you can figure out a way to control it~ seems a bit > odd. > > > Okay, thanks for the clarification. It seems like either experimental > or standard would be appropriate then. The other aspect that could be > relevant is there is no change to on the wire protocol, I'm not sure > how that would impact the track status. > > As far as how to control it, I would point out that neither GRE nor > IPIP, probably the two most common encapsulations in use, don't > specify an associated control protocol. We are taking that same > approach with GUE and I think that same approach is good for ILA. It > would be great to see a common control plane for tunneling and > virtualization that solves the larger common problem (this is why > IDEAS is exciting to me), but even if that existed it would never be > the only means to control the dataplane. In some deployments simple > configuration is more than sufficient, for example. > > Tom, I think you are confusing what Joel said, i.e. figure out a way to control it with what you have in your mind, i.e. control plane. I think a way to control it means defining a few RADIUS attributes to manage ILA which can be done in an accompanying draft. Regards, Behcet > Thanks, > Tom > > > Yours, > > Joel > > > > On 5/16/17 11:25 PM, Erik Kline wrote: > >> > >> > >> > >> On 14 May 2017 at 03:21, Tom Herbert <t...@herbertland.com > >> <mailto:t...@herbertland.com>> wrote: > >> > >> On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern > >> <j...@joelhalpern.com <mailto:j...@joelhalpern.com>> wrote: > >> > It appears to me that there are contexts in which it is likely > that > >> ILA is > >> > useful. > >> > > >> > Using the example of the progression of LISP, I have concern with > >> the > >> > current approach of NOT spelling out how and where it would be > used. > >> LISP > >> > started out as experimental in significant part because it was not > >> clear > >> > where it would be useful. We re now progressing it to PS with a > >> clear > >> > context. And that context is NOT Internet-wide deployment for > >> Internet > >> > scaling. Because that deployment problem is REALLY challenging. > >> > > >> > As such, if ILA wants to either be developed for the data center > >> context or > >> > be developed as an interesting experiment across a range of > >> potential uses, > >> > I can not object. > >> > > >> > I do have problems moving it forward towards standards track for > >> some > >> > unspecified but general use in its current form. The dependence > of > >> the data > >> > plane protocol on the information distribution is so strong that I > >> do not > >> > see how the general case can be treated. > >> > > >> Hi Joel, > >> > >> Intended status is listed as informational if that helps. > >> > >> I tend to think that the relationship between an ILA data plane and > >> control plane is analogous to the relationship between the IP > protocol > >> and routing protocols. Yes, there is a strong dependency on having a > >> control plane, but mandating a specific control plane as part of the > >> core protocol reduces flexibility and extensibility. > >> > >> > >> Put another way: the domain of applicability is the same as the > >> domain(s) over which the control plane operates. Any ILA packets > >> outside that/ose domain/s should just look like vanilla IPv6. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
