RE: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 15 October 2020 23:08 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB973A0D25; Thu, 15 Oct 2020 16:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm9anXsIv6vw; Thu, 15 Oct 2020 16:08:45 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B8B3A0CF2; Thu, 15 Oct 2020 16:08:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09FN8dQl000891; Thu, 15 Oct 2020 19:08:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602803321; bh=611rdDAhQsPSMfseN92uPJJp1BVTmTGjogzTMMoo72k=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=cd8Uneet9iUjQxej8YsjjDLEbyblLJ4R8MstmJz8UybRmiMMPM6k8dbll/b7Fhj3N HclgMzu4jJfOGotoCHsm6sKQ98BISHCINrBAGBHx2nSXrkLSO6cK9edYL7Jwp8YqOO 9yLScj9JnaSG5hV9rzyVfxyYTgGMR4qxV+xie69rAxf/exj/z3aSk4JJ8Ifwi625hd JSey9kdnwzFGEAAnZrGC8qbmHsjdITpvJFgtCE3Kez84hOozDmT38E1xvGRSBlVhXz xcZYw3yBhvjEpzPPD1OmMMDl47gHOIR0Aed8sbWob38RDP801gEUND6frHE6PsWyM0 HGCZu64FAQwKw==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FN8RnP031889 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 19:08:27 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 15 Oct 2020 16:08:26 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Thu, 15 Oct 2020 16:08:26 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: Ole Trøan <otroan@employees.org>, IPv6 List <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
Subject: RE: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AdajMsD1xD3hGdlTThaXSslc4Lj72wATEuMAAA4kJFA=
Date: Thu, 15 Oct 2020 23:08:26 +0000
Message-ID: <423a090e400a4ca3960cee27364b1a16@boeing.com>
References: <6664a427f0334468ac0b8cba75b37d03@boeing.com> <B5035814-3F27-4B81-A585-24F114DE5AEC@gmail.com>
In-Reply-To: <B5035814-3F27-4B81-A585-24F114DE5AEC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 53FA3E950F1AB5E541D78076290CD152C60F09105A1C63D15E93C2CA4A0D4D322000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/t4N7FhQYTR-V4sH3G7oRciAE1-I>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 23:08:54 -0000

Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Thursday, October 15, 2020 3:42 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; Ole Trøan <otroan@employees.org>; IPv6 List <ipv6@ietf.org>; atn@ietf.org
> Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> > On Oct 15, 2020, at 1:58 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Bob,
> >
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> >> Sent: Thursday, October 15, 2020 1:29 PM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: Bob Hinden <bob.hinden@gmail.com>; Ole Trøan <otroan@employees.org>; IPv6 List <ipv6@ietf.org>; atn@ietf.org
> >> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> >>
> >> Fred,
> >>
> >>> On Oct 15, 2020, at 12:40 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >>>
> >>>>>>
> >>>>>
> >>>>> That circles us right back to the subject of how RFC4861 is intrinsically tied to
> >>>>> the use of link-local address and the fact that all IPv6 interfaces are required
> >>>>> to configure a unique link-local address. It would be a bear to try to change
> >>>>> that, so OMNI employs RFC2473 encapsulation instead of trying to override
> >>>>> the bedrock IPv6 standards. The use of RFC2473 encapsulation also brings
> >>>>> other important benefits.
> >>>>
> >>>> Right, that how ND works.   Seems to me that you are proposing many changes to IPv6 for some degree of optimization.   It’s
> >> unclear
> >>>> to me that the benefit outweighs the cost.
> >>>
> >>> Rather than repeating them again here, I would invite you to go back over the
> >>> message exchanges I had with Ole yesterday (10/14/2020) where I outlined the
> >>> benefits.
> >>
> >> I read that, but was not convinced that the benefits were sufficient to justify what you are proposing.
> >
> > I think that may be due to the fact that we have only examined a few fundamental
> > aspects of the architecture, and there is more to it than what has been discussed
> > so far - a *lot* more.  For instance, the reason for wanting both LLAs and SLAs is so
> > that we can use overlay "L2 bridging" to join disjoint Internetworks together as
> > though they were one big bridged campus LAN. For example, in civil aviation there
> > are many network service providers including ARINC, SITA, Inmarsat and others and
> > each runs their own networks as an independent entity. But, an aircraft connected
> > to ARINC may need to communicate with an air traffic controller in SITA. OMNI then
> > views each of the providers as a link *segment* and bridges the segments using
> > RFC2473 encapsulation with SLAs and BGP router peerings between the providers.
> > The IPv6 layer then sees this bridged arrangement as a single, connected IPv6 link
> > and the aircraft and ATC can communicate as peers on the link even though they
> > are located in different provider networks in the underlay.
> 
> I think this is a bad idea, that is trying to make a set of networks with a whole range of characteristics (i.e., speed, delay, drop rates,
> errors, cost, etc.) look like a single "big bridged campus LAN”.   Most people have stopped buildings “big bridged campus LANs” a long
> while ago, what your are proposing is much harder given the different characteristics of the networks you mention.

I think you may have gotten a polar opposite read from what the OMNI technology
is all about - OMNI is about diversity; not homogeneity. The OMNI "multilink" concept
in particular is about accommodating all manners of data links having diverse properties
and characteristics, while presenting the best possible performance profiles to mobile
nodes in the face of dynamically changing conditions. The "bridged campus LAN"
concept is not a physical thing; it is a virtual one that allows nodes to communicate as
single-hop neighbors at the IP layer while their underlying data link properties may be
varying dynamically. This discussion now starts to enter into the realm of what we have
been debating in the ICAO working groups for the past several years, and has motivated
the design based on expert input from the aviation community. And, what is good for
aviation also turns out to be good for the worldwide mobile Internet for any manners
of mobile nodes.

Fred

> I think a better approach is to treat the networks separately and use transport protocols techniques to use them efficiently separately
> and concurrently.   Likely the transport protocols and applications above them will need to be aware of the underlying networks.
> 
> >
> >>> About changes to IPv6, all that has been asked so far is for the OMNI
> >>> interface to define its own link-local addresses - having that, none of the IPv6
> >>> standards like RFC4861, RFC8200 etc. are changed.
> >>
> >> The OMNI draft updated RFC1191, RFC3879, RFC4291, RFC4443, and RFC8201.
> >
> > When I said "all that has been asked for *so far*", I meant in terms of what has
> > been discussed on the list up to now. Up to now, the only aspects of OMNI we
> > have touched on are the LLAs and SLAs, and it is only RFC3879 and RFC4291 that
> > are in question. So, until we get around to discussing the OAL let's put the other
> > RFCs aside for now.
> 
> I disagree, you are clearly proposing a lot of changes, discussing them separately doesn’t change that.
> 
> Bob
> 
>