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: Thursday, December 01, 2016 11:08 AM
> 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
> 
> 
> 
> On 12/1/2016 10:35 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Thursday, December 01, 2016 10:21 AM
> >> 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,
> >>
> >> To wrap up:
> >>
> >> - Subnet Redirects appear to rely on AERO-specific mechanisms, so would
> >> not be of more general relevance to a bis doc IMO
> > RFC6706 already specifies how these Redirects work and is agnostic to the
> > link type. AERO(bis) tells how they work on AERO links through use of the
> > IPv6 ND protocol on a specific link type.
> My point is that the IPv6 ND extension would not be of generic use on
> other IPv6 nets because of the lack of endpoint authentication.

RFC6706 discusses security considerations that apply to any link type that
redirection can be used on - and, not just NBMA tunnel links. This is over
and above what RFC4861 discusses in terms of Redirection security, so
RFC6706 indicates methods for improving security.

> >> - multiple link addresses are already part of the Ethernet spec and
> >> already handled by most IP over Ethernet implementations (and TOS
> >> marking correlation is defined in 802.1p).
> > I'd like to see what you are talking about so I can compare it to what
> > AERO is doing.
> See below...
> >
> >> When you assign more than
> >> one link address to a single physical interface, you're acting as if you
> >> have multiple links.
> > No, you are acting as if there are multiple link-layer addresses on the
> > same link.
> >
> >> At that point, the forwarding table indicates not
> >> only the next-hop IP but the outgoing link -- for multiple link
> >> addresses these are treated as different virtual interfaces already.
> > Going with what I just said above, the forwarding table indicates only
> > the next-hop IP. It is the neighbor cache entry for the next-hop IP
> > that includes the multiple link-layer addresses. But, it is all one link.
> 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. 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.

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

Thanks - Fred
[e-mail]

> Anything that intensive IMO should involve the commitment of creating a
> BOF and WG as evidence there is sufficient interest.
>
> Joe