Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Monday, December 05, 2016 1:25 PM
> To: Templin, Fred L <[e-mail]>; Lucy yong <[e-mail]>; Brian E Carpenter
> <[e-mail]>; [e-mail]
> Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
> 
> Hi, Fred,
> 
> 
> On 12/1/2016 12:52 PM, Templin, Fred L wrote:
> > Hi Joe,
> > ...
> > Can you say why you think redirecting an entire subnet is potentially more
> > problematic (noting that RFC6706 has been published since 2012 and so the
> > notion of subnet redirection is already well known)?
> 6706 is within the context of authenticated origin.

Yes, that is correct. And, RFC6706 applies to all link types that support
Redirection (i.e., and not just tunnel NBMA links).

> It's a problem in the more general case where that's not known - e.g.,
> where host redirect is already used.

I don't understand the point you are trying to make here, but it
might not even matter. 

> >> Yes, buried in 6706 are the issues that might be in such a rev, but we
> >> can't expect IPv6 ND implementers to dive into a large spec that has no
> >> clear relation to IPv6 and doesn't update 4861 to find it. If there is a
> >> way for this approach to be generally useful, it really needs to be in a
> >> 4861bis update.
> > Not an RFC4861bis, no, but possibly in a document that updates RFC4861.
> > Is that what you meant
> I was thinking of a single doc focused on the subnet redirect. That
> could be in a 4861bis or a single doc that updates 4861, but should not
> be a small part of a much larger doc that does many other things
> concurrently IMO.

RFC6706 specifies subnet redirect for any link type that can support
ordinary Redirect. RFC6706(bis) updates that spec.

> >>>> It acts exactly like one NMBA link on which your endpoint has multiple
> >>>> virtual interfaces.
> >>> This is from RFC4861:
> >>>
> >>>      Inbound load balancing - Nodes with replicated interfaces may want
> >>>            to load balance the reception of incoming packets across
> >>>            multiple network interfaces on the same link.  Such nodes
> >>>            have multiple link-layer addresses assigned to the same
> >>>            interface.  For example, a single network driver could
> >>>            represent multiple network interface cards as a single
> >>>            logical interface having multiple link-layer addresses.
> >>>
> >>> AERO is not talking about inbound load balancing, but it is talking about
> >>> a single logical interface having multiple link-layer addresses in exactly
> >>> the same spirit as implied by this text.
> >> Which is what I said - one link with multiple interfaces. The example
> >> given explains that this can be done through interface virtualization,
> >> which I also noted.
> > No, it agrees with what I said: "a single network driver could represent
> > multiple network interface cards as a single logical interface having multiple
> > link-layer addresses". One interface; multiple link-layer addresses; one link.
> The only difference is whether you can use vanilla IP forwarding (to
> pick the outgoing virtual interface) or need some sort of additional
> mechanism (that allows multiple IP forwarding entries to use the same
> interface and next-hop IP, but needs additional fields to differentiate
> the L2 source/dest). With virtual interfaces, you can use existing code.

To be completely clear, with AERO the tunnel interface itself (i.e., the
AERO interface) is the virtual interface. Within the AERO interface there
are one or more underlying interfaces (physical or virtual), with each
interface having one or more addresses. The underlying interface
addresses are seen as link-layer addresses of the AERO interface.

The AERO interface is the node's point of connection to the AERO link,
where the AERO link is the entire underlying network. The AERO
interface therefore has multiple link-layer addresses but it connects
to a single link. This is consistent with the link model for ISATAP which
was published as RFC4214/RFC5214.

With this model, the inner IP layer uses vanilla IP forwarding to pick
the (singular) AERO interface as the outgoing interface. Once inside
the AERO interface, the inner IP destination address is mapped to
the correct corresponding AERO interface neighbor cache entry,
then encapsulation is applied, and then the encapsulated packet
is shipped out the correct underlying interface.

> >> Whether you use them for input or output reasons is up to the forwarding
> >> plane; it shouldn't be buried inside the tunnel mechanism. That's a flaw
> >> of many other tunnel approaches.
> > I disagree with any implications of a flaw. There is one forwarding table entry,
> > but the neighbor cache entry has multiple link-layer addresses. So, IP forwarding
> > does its normal thing at the IP layer, but inside the interface the packet is
> > forwarded to the correct link-layer address of the neighbor among multiple
> > candidates at the sub-IP layer. I can demonstrate this in running code today.
> I agree this works, but you need your new code to accomplish this for
> the very reason you cite.

All tunnel drivers have code that operates at the sub-IP layer, i.e., and not
just OpenVPN. Look at the linux kernel sit.c, ipip.c, ip_gre.c, etc. drivers, and
look at any apps that use the TUN/TAP interface. This code is not flawed.

> If you treat these as different interfaces, then existing forwarding
> code would have sufficed.

Existing IP forwarding code does suffice with a single interface. It is the
same as on any multipoint interface (e.g., Ethernet).

> >> Tunnels should stop at the interface.
> > But they don't. Look at the way OpenVPN works.
> Not the poster child of how networking works, IMO.

It is not just OpenVPN, which was used as only one widely-deployed
example.

> >>>  But, by allowing multiple S/TLLAOs
> >>> on IPv6 ND messages, AERO nodes can tell their neighbors about their
> >>> multiple link-layer address and how they prefer to have those link-layer
> >>> addresses used for inbound traffic.
> >> In my terminology, they affect the forwarding table. Sure.
> > They do not affect the forwarding table at the IP layer.
> 
> They should. You're effectively using a different link source/dest.

I'm not sure if this statement is born from a misunderstanding of the
 AERO interface/link model or some kind of preconceived notions you
may have from some other context. But, it is one (virtual) interface
connected to one (virtual) link the same way as Ethernet has one
(physical) interface connected to one (physical) link.

> > The IP layer sees only
> > a single next-hop while the sub-IP layer gets to see the multiple link-layer
> > addresses in the neighbor cache entry.
> That's the flaw, IMO - it's not needed of you use VIFs (we demonstrated
> this in the X-Bone).

Not adhering to the X-Bone model does not necessarily constitute a flaw.
Otherwise, if X-Bone were the measuring stick pretty much all widely
deployed tunneling solutions would be considered flawed.

I would ask you to go through the AERO spec and tell me what you think
is broken. And, a dissimilarity with X-Bone does not necessarily mean
that something is broken.

Thanks - Fred
[e-mail]

> Joe
> 
> 
> 
> >
> > Thanks - Fred
> > [e-mail]
> >
> >>>>>> - I agree that IPv6 ND was done in an INTAREA WG; the same might be true
> >>>>>> for AERO, but the INTAREA WG should be a place where generic aspects of
> >>>>>> all Internet layer issues should be addressed, not domain-specific
> >>>>>> solutions (IMO).
> >>>>>>
> >>>>>> AERO might be one doc, but it is 60+ pages with over 70 revisions. I don't think it would be useful to bog down INTAREA with
> >>>>>> something that large.
> >>>>> The document size and number of revisions are irrelevant. By making it
> >>>>> an intarea doc, it would revert back to a -00.
> >>>> That helps only the number of revisions issue; the point is that the
> >>>> work associated with this doc involves substantial effort for review.
> >>> RFC6706 was 33pages long, but was reviewed and approved in a relatively
> >>> short time and without going through a working group formation. Is there
> >>> some kind of page count cutoff I am not aware of?
> >> It wasn't a WG doc either.
> >>
> >> Yes, individua submissionl is another option.
> >>
> >> Joe
> >>
> >
>