Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Wednesday, November 30, 2016 4:52 PM > 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 > > > > On 11/30/2016 3:17 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:to...@isi.edu] > >> Sent: Wednesday, November 30, 2016 2:32 PM > >> 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 (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?)
It is secure, because there is a trust anchor (the AERO Server) that is trusted by both AERO Clients (the source and target) and the Clients will only accept the Redirection if it comes through the Server. The difference is that the source Client has to solicit a Redirect by first sending what is called a "Predirect". The Predirect lets the target Client know that source is authorized to source packets from its claimed prefix, and the target Client returns a Redirect. When the source Client gets the predirect, it knows that the target Client is prepared to accept its packets via the direct path not including the Server. This basic behavior is already discussed in RFC6706, but we are seeking to (bis) that work now. > >>> 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. It is a Redirect, yes, except that the Redirect is preceded by a Predirect and the exchange is brokered through a trust anchor. > > .... > > 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. No, it is one tunnel interface with potentially multiple link-layer addresses. That way, if there were an IP address assigned to the tunnel interface the inner packets could use the same inner IP address even if the encapsulated packets used different encapsulation IP addresses (e.g., with some going out over a WiFi interface and others going out over a cellular interface). This also gives rise to the possibility of asymmetric paths in the forward and reverse directions - e.g., send packets out over the cellular interface and receive packets back over the WiFi interface. > > >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. What I am describing is an augmentation of IPv6 neighbor discovery where ND messages can carry multiple S/TLLAOs and the neighbor cache entries can have multiple link-layer addresses. RFC4861 is silent on whether this is permissible. AERO makes it explicit. > >>>> 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). ICAO is not a community of network and computing equipment engineers and researchers in the same way as the IETF is. There is no one in ICAO who can serve as an RFC Editor for a standard that would be based on AERO or any other network technology. There is no one in ICAO who can build reference implementations and/or establish rough consensus among the network and computing equipment community. ICAO looks to the IETF for Internetworking standards. > I haven't seen a case yet as to why INTAREA should adopt it per se... Everything we have talked about above relates to a specific link layer model for tunnels (NBMA) and is manifested as an "IP-over-(foo)" document much in the same spirit as for IP-over-Ethernet, IP-over-FDDI, IP-over-ATM, etc. That seems like an Intarea consideration to me. Thanks - Fred fred.l.temp...@boeing.com > Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
