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>; int-area@ietf.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.

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

>> - 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.
Anything that intensive IMO should involve the commitment of creating a
BOF and WG as evidence there is sufficient interest.


Int-area mailing list

Reply via email to