Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Thursday, December 01, 2016 11:08 AM > To: Templin, Fred L <fred.l.temp...@boeing.com>; Lucy yong > <lucy.y...@huawei.com>; Brian E Carpenter > <brian.e.carpen...@gmail.com>; email@example.com > 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:to...@isi.edu] > >> Sent: Thursday, December 01, 2016 10:21 AM > >> To: Templin, Fred L <fred.l.temp...@boeing.com>; Lucy yong > >> <lucy.y...@huawei.com>; Brian E Carpenter > >> <brian.e.carpen...@gmail.com>; firstname.lastname@example.org > >> 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 fred.l.temp...@boeing.com > Anything that intensive IMO should involve the commitment of creating a > BOF and WG as evidence there is sufficient interest. > > Joe _______________________________________________ Int-area mailing list Intemail@example.com https://www.ietf.org/mailman/listinfo/int-area