Subject: [Int-area] ILA and int-area

From: Tom Herbert <[email-masked]>
Date: Sat, 13 May 2017 10:42:45 -0700

Hello,

At the Chicago WG meeting I made a request that ILA be taken up as a
WG item in int-area. The WG chairs and AD requested that we raise a
discussion on the list about what else is needed to be done for ILA
(Identifier Locator Addressing draft-herbert-nvo3-ila-04). The
question was also raised if int-area is the right WG for ILA or if it
should have a BOF.

The current draft of ILA describes the data plane and addressing, a
model for ILA for ILA routing and network topology, several use case
scenarios on how ILA might be applied, a format for identifiers to
allow different types of identifiers and checksum neutral mapping. As
I mentioned we intend to make the last one optional so that
administrators can choose how structure the 64 bit identifiers as they
see fit-- this will be reflected in the next version of the draft.

The draft explicitly does not define a specific control plane (e.g.
routing protocol) for ILA and I don't think that it should. IMO ILA
would be better served to allow various methods that are protocol
generic where ILA could be a use case of those mechanisms. For
instance, draft-lapukhov-bgp-ila-afi-02 describes and extension for
BGP. Similarly, if a protocol agnostic control plane is developed in
IDEAS or in nvo3, then ILA could be one use case for those. I would
think the control plane seems more appropriate to be in routing area
than int-area.

As for what is still missing in the core ILA draft, besides making
typed identifiers optional, I think it is fairly complete for the data
plane description. It is being deployed in a least on datacenter for
network virtualization, and it is being discussed as part of a
solution to support IP mobility (see 5GandIP discussions).

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 May 2017 14:03:10 -0400

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.

Yours,
Joel

On 5/13/17 1:42 PM, Tom Herbert wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 13 May 2017 11:21:11 -0700

On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern <[email-masked]> wrote:
> It appears to me that there are contexts in which it is likely that ILA is
> useful.
>
> 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.
>
> 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.

Tom

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 May 2017 12:25:06 +0900

On 14 May 2017 at 03:21, Tom Herbert <[email-masked]> wrote:

> is
> or
> data

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 May 2017 23:33:54 -0400

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.

Yours,
Joel

On 5/16/17 11:25 PM, Erik Kline wrote:
>
>
> On 14 May 2017 at 03:21, Tom Herbert <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 May 2017 17:29:48 +1200

> question was also raised if int-area is the right WG for ILA or if it

I think it's fine for int-area to take this up, as long as 6man
is alerted.

A few somewhat random comments:

Is there any particular reason you chose a /64 routing prefix,
rather than say /72 or /80? I don't see any dependency on SLAAC,
so there's no reason to care about /64, right? I assume you would
use DHCPv6 or some other method of assigning addresses to VMs.

If you used /72 or /80 you'd have flexibility with a ULA prefix to
insert a subnet field.

> The format of an ILA address with a global unicast locator is:
>
>    |<--------------- Locator --------------->|
>    |3 bits| N bits        | M bits  | 61-N-M | 64 bits              |
>    +------+-------------+---------+---------------------------------+
>    | 001  | Global prefix | Subnet  | Host   |      Identifier      |
>    +------+---------------+---------+--------+----------------------+

Why is this restricted to 2000::/3?

> The format of an ILA address with a unique local IPv6 unicast locator
> is:
>
>    |<--------------- Locator --------->|
>    | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
>    +--------+-+------------+-----------+----------------------------+
>    | FC00   |L| Global ID  | Host      |        Identifier          |
>    +--------+-+------------+-----------+----------------------------+

The first byte is confusing; presumably you're trying to express
fd00::/8 so why not put 11111101 ?

I agree that the flow label would be tricky to use for this sort of
purpose, but I have a couple of comments anyway:

>   o The flow label is only twenty bits, this is too small to be a
>     discriminator in forwarding a virtual packet to a specific
>     destination. Conceptually, the flow label might be used in a
>     type of label switching to solve that.

Perhaps, but 6man fairly comprehensively rejected that type of usage.
In practice it's excluded by section 4 of RFC6437.

      o The flow label is not considered immutable in transit,
        intermediate devices may change it.

That's not phrased quite right. RFC6437 section 2 says:

"  Once set to a non-zero value, the Flow Label is expected to be
   delivered unchanged to the destination node(s).  A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons as described in
   Section 6.1.

   There is no way to verify whether a flow label has been modified en
   route..."

You could in fact have an operational guarantee that within an
administrative domain, no middleboxes will change the flow label.
So something like this is more accurate:

     o  The flow label is not protected against changes in transit.

>    o Intermediate devices must not insert extension headers
>      [RFC2460bis].

I think you could say:

      o Current specifications do not allow intermediate devices to
        insert extension headers [RFC2460bis].

Regards
   Brian

---

From: Tom Herbert <[email-masked]>
Date: Tue, 16 May 2017 22:53:10 -0700

On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <[email-masked]> wrote:
> For example, if it were documented for data centers, based on Facebook's
> experience, I would have trouble objecting to informational publication.
>
> RFCs.  While I have my doubts about some of the applicability, that should
> not stop useful experimentation.
>
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.

Thanks,
Tom

>> LISP

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 May 2017 04:27:13 -0500

> 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

> >>     > It appears to me that there are contexts in which it is likely
> that
> >> ILA is
> >>     > useful.
> >>     >
> >>     > unspecified but general use in its current form.  The dependence
> of
> >> the data

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 May 2017 09:35:36 -0400

I do not think classic Internet tunnels (e.g. IP in IP or GRE) are a 
good comparison for ILA.  The ILA mapping requires dynamic knowledge 
about the remote end.  (One of the things that is important about ILA is 
its ability to hide dynamics.)
GUE at least is proposed specifically for use in data centers.

I think you understand my point, so I will not belabour it.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 May 2017 08:00:19 -0700

> use DHCPv6 or some other method of assigning addresses to VMs.
The 64 bit was for convenience since that is what ILNP had and in the
DC we wanted enough identifier bits to be able to do identifier
assignment based on a timestamp as described in appendix B. There's no
hard requirement for it. I think we could just say an ILA domain can
define lengths of identifier and locators as they see fit-- as long as
its consistent and unambiguous within the domain there shouldn't be an
issue.

> Why is this restricted to 2000::/3?

Probably shouldn't be. If locator length isn't fixed like above, then
probably should just describe it by properties of being routable to
physical hosts.

>      o  The flow label is not protected against changes in transit.
Yes, the flow label concept came up in some early dicussions.

>         insert extension headers [RFC2460bis].
Good point.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 May 2017 20:36:36 -0500

On Wed, May 17, 2017 at 8:35 AM, Joel M. Halpern <[email-masked]>
wrote:

> I do not think classic Internet tunnels (e.g. IP in IP or GRE) are a good
> comparison for ILA.  The ILA mapping requires dynamic knowledge about the
> remote end.  (One of the things that is important about ILA is its ability
> to hide dynamics.)
I don't think this discussion, i.e. Tom's request to intarea was related to
GUE which is already a WG draft.
Also GUE is not specifically proposed for data centers, but it could be
used in data centers with certain extension headers.

I still think that especially if experimental/standard track is used means
to manage ILA would be needed.

My two cents :)

Behcet