On 11/30/2016 3:17 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Wednesday, November 30, 2016 2:32 PM >> To: Templin, Fred L <[email protected]>; Lucy yong >> <[email protected]>; Brian E Carpenter >> <[email protected]>; [email protected] >> Subject: Re: [Int-area] Some thoughts on >> draft-yong-intarea-inter-sites-over-tunnels >> >> Hi, Fred (et al.), >> >> >> On 11/30/2016 12:51 PM, Templin, Fred L wrote: >>> Hi Joe, >>> ... >>> I didn't mention route optimization. With AERO, route optimization is what >>> happens >>> when the tunnel ingress switches from an egress that is on a suboptimal >>> path to a >>> different egress that is on a better path. >> That's internal to the tunnel itself, related to the fact that your >> tunnel is multipoint and treats all egresses as valid. >> >> That's another feature, but again it's hard to see where that would be >> discussed. It's closest in spirit to egress determination in BGP or >> LISP, and has no clear relation (AFAICT) to INTAREA (expertise or >> purview). However... > It is the same as the way the Redirect function works on physical links, > except > that the Redirect applies to an entire network prefix and not just a singleton > address. This has already been published in RFC6706, and what we are now > specifying is essentially RFC6706(bis).
OK, then the bis doc might fall within INTAREA (though I would think it could be very hazardous to allow a redirect to apply to an entire prefix! - isn't that an attack vector?) > >>> Due to the link nature of the NBMA overlay, >>> that switching is accomplished through the use of IPv6 ND Redirect messages >>> the >>> same as would occur on a physical link (and in the same spirit as published >>> in RFC6706). >> I don't think I would call that routing either when it happens in a >> regular network or inside an NMBA tunnel. > It is the moral equivalent of the Redirect function on physical links. It's the exact same thing. I agree it's useful, just not that it's routing. > .... > The AERO interface is an NBMA interface where the ingress sees all potential > egresses as potential "neighbors". Isn't that true for all multipoint links? > An AERO interface that is configured over > multiple underlying interfaces would appear to have multiple link-layer > addresses. Each link-layer address can have a different set of TOS-based > priorities so that the AERO interface can specify to its neighbors as to > which link-layer address to use for which class of traffic. That just means you have a tunnel model that allows one instance to represent multiple tunnels (or tunnel interfaces). That's fine, but seems local to the definition of the tunnel. > >From an IPv6 neighbor discovery standpoint, this is realized by allowing > >IPv6 ND > messages to include multiple S/TLLAOs - one for each underlying interface. > Each > S/TLLAO has a set of TOS-based priorities allowing neighbors to select the > best > underlying interface for the given packet TOS. This is described in Section > 3.5 > of the document. I can demonstrate how this works in actual running code > over a webex if you would like. I understand the principle, but you're describing a feature of the tunnel mechanism that seems based largely on applying existing IP capability inside the tunnel. > >>>> I'm not claiming this wouldn't be useful. I'm saying that we need to >>>> know what problem it solves to know where to home it. >>> I have identified two very important use cases relating to aviation. >> You've defined a customer, IMO - which is great, but short of taking >> this to an aerospace forum, it doesn't really help me understand where >> in the IETF it should be discussed. > It is being proposed to the International Civil Aviation Organization (ICAO) > where standards are being established for the future civil aviation data > communications architecture. Sure, so it sounds like a standard there and a de-facto one within the IETF (e.g., individual informational). I haven't seen a case yet as to why INTAREA should adopt it per se... Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
