Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Joe Touch]

HI Fred,

I'm in the process of the next update, and wanted to clarify the following:


On 3/28/2017 9:36 AM, Templin, Fred L wrote:
> 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as
> well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define
> an NBMA multipoint tunnel framework that has been around a
> lot longer than the other examples cited.
That section doesn't list examples of multipoint tunnels per se. It
lists systems that use multipoint tunnels (LISP, TRILL) and discusses
mechanisms that support multipoint tunnels (LANE, etc.).

I'm not sure there's a clearly good, original ref for multipoint tunnels
- the concept has been around in some form since basically the notion of
a tunnel.

Joe


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Joe Touch]

Fred,

Regarding the following point:


On 3/28/2017 9:36 AM, Templin, Fred L wrote:
> 19) Section 4.3.3, third paragraph, I thought it was said earlier
> that all ingress/egress pairs must support the same MTU. I
> thought we agreed earlier on that that multi-MTU subnets
> don't work. So, I think it should say that all ingress pairs
> MUST support a uniform MTU.
The cited section allows for ingress/egress pairs that don't support the
same MTU, but then says that the MTU used for that set is the minimum of
those MTUs.

There's no way (short of configuration management) to ensure that
ingress/egress pairs MUST support the same MTU, but no real value to
requiring that - AFAICT, we just use the min across that set (which is
what that section says to do).

So yes, we do not *use* different MTUs per-destination, but we don't
need to require it AFAICT.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Templin, Fred L]

Interesting timing on this message, but see below:

> -Original Message-
> From: Joe Touch [mailto:to...@isi.edu]
> Sent: Tuesday, May 16, 2017 4:13 PM
> To: Templin, Fred L 
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
> 
> HI Fred,
> 
> I'm in the process of the next update, and wanted to clarify the following:
> 
> 
> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
> > 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as
> > well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define
> > an NBMA multipoint tunnel framework that has been around a
> > lot longer than the other examples cited.
> That section doesn't list examples of multipoint tunnels per se. It
> lists systems that use multipoint tunnels (LISP, TRILL) and discusses
> mechanisms that support multipoint tunnels (LANE, etc.).

AERO embraces the tunnel as a link in the spirit of your document while
LISP does not. AERO defines "AERO interface" and "AERO link" - LISP goes
out of its way to avoid saying anything about interfaces or links.

> I'm not sure there's a clearly good, original ref for multipoint tunnels
> - the concept has been around in some form since basically the notion of
> a tunnel.

RFC2529 is the first I am aware of.

Fred

> Joe
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Templin, Fred L]

Joe,

> -Original Message-
> From: Joe Touch [mailto:to...@isi.edu]
> Sent: Tuesday, May 16, 2017 4:17 PM
> To: Templin, Fred L 
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
> 
> Fred,
> 
> Regarding the following point:
> 
> 
> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
> > 19) Section 4.3.3, third paragraph, I thought it was said earlier
> > that all ingress/egress pairs must support the same MTU. I
> > thought we agreed earlier on that that multi-MTU subnets
> > don't work. So, I think it should say that all ingress pairs
> > MUST support a uniform MTU.
> The cited section allows for ingress/egress pairs that don't support the
> same MTU, but then says that the MTU used for that set is the minimum of
> those MTUs.
> 
> There's no way (short of configuration management) to ensure that
> ingress/egress pairs MUST support the same MTU, but no real value to
> requiring that - AFAICT, we just use the min across that set (which is
> what that section says to do).

What I am trying to get at is the need for an ingress to determine the
minimum before it sends a packet that may be too big for one of the
multipoint link egresses. On IPv6 links, this could be through receipt
of an MTU option in a Router Advertisement message. Other ways
are possible (e.g., static configuration) but there needs to be some
way for all ingresses to determine the minimum.

Thanks - Fred

> So yes, we do not *use* different MTUs per-destination, but we don't
> need to require it AFAICT.
> 
> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Joe Touch]

HI, Fred,

AOK - I can add that. The point is that *IF* you get multiple answers
(regardless of how), you use the min.

And the ingress needs to determine that value before sending for sure
and there's always the possibility of PMTUD doing odd things if ICMPs
are blackholed here - but partial delivery in that case isn't unique to
tunnels.

I'll mention it, though.

joe


On 5/16/2017 4:31 PM, Templin, Fred L wrote:
> Joe,
>
>> -Original Message-
>> From: Joe Touch [mailto:to...@isi.edu]
>> Sent: Tuesday, May 16, 2017 4:17 PM
>> To: Templin, Fred L 
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
>>
>> Fred,
>>
>> Regarding the following point:
>>
>>
>> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
>>> 19) Section 4.3.3, third paragraph, I thought it was said earlier
>>> that all ingress/egress pairs must support the same MTU. I
>>> thought we agreed earlier on that that multi-MTU subnets
>>> don't work. So, I think it should say that all ingress pairs
>>> MUST support a uniform MTU.
>> The cited section allows for ingress/egress pairs that don't support the
>> same MTU, but then says that the MTU used for that set is the minimum of
>> those MTUs.
>>
>> There's no way (short of configuration management) to ensure that
>> ingress/egress pairs MUST support the same MTU, but no real value to
>> requiring that - AFAICT, we just use the min across that set (which is
>> what that section says to do).
> What I am trying to get at is the need for an ingress to determine the
> minimum before it sends a packet that may be too big for one of the
> multipoint link egresses. On IPv6 links, this could be through receipt
> of an MTU option in a Router Advertisement message. Other ways
> are possible (e.g., static configuration) but there needs to be some
> way for all ingresses to determine the minimum.
>
> Thanks - Fred
>
>> So yes, we do not *use* different MTUs per-destination, but we don't
>> need to require it AFAICT.
>>
>> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Joe Touch]

On 5/16/2017 4:24 PM, Templin, Fred L wrote:
> Interesting timing on this message, but see below:
>
>> -Original Message-
>> From: Joe Touch [mailto:to...@isi.edu]
>> Sent: Tuesday, May 16, 2017 4:13 PM
>> To: Templin, Fred L 
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
>>
>> HI Fred,
>>
>> I'm in the process of the next update, and wanted to clarify the following:
>>
>>
>> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
>>> 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as
>>> well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define
>>> an NBMA multipoint tunnel framework that has been around a
>>> lot longer than the other examples cited.
>> That section doesn't list examples of multipoint tunnels per se. It
>> lists systems that use multipoint tunnels (LISP, TRILL) and discusses
>> mechanisms that support multipoint tunnels (LANE, etc.).
> AERO embraces the tunnel as a link in the spirit of your document while
> LISP does not. AERO defines "AERO interface" and "AERO link" - LISP goes
> out of its way to avoid saying anything about interfaces or links.
>
>> I'm not sure there's a clearly good, original ref for multipoint tunnels
>> - the concept has been around in some form since basically the notion of
>> a tunnel.
> RFC2529 is the first I am aware of.
AOK - thanks.

Joe




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joel M. Halpern]

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 mailto:t...@herbertland.com>> wrote:

On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern
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

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

[Brian E Carpenter]

On 14/05/2017 05:42, Tom Herbert wrote:
> 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.

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 1101 ?

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Tom Herbert]

On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern  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.

Thanks,
Tom

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