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

[Joe Touch <[e-mail]>]

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.

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

>
>> 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.


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

>
>> 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.

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

>
>> 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.


>
>>>  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.

> 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).

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