RE: AERO/OMNI/ATN-BGP follow-up discussion from 07/28/2021 rtgwg session

["Templin (US), Fred L" <[e-mail]>]

> But, while it is true that the AERO and OMNI docs are both large and
> dense, there have been other IETF publication for which the same has been true,
> e.g., RFC6275 (169 pages).

Folks, I will offer RFC2328 (244 pages) as another example that should be very
familiar to this working group. Sometimes big things are best delivered in big
packages, and not in lots and lots of little packages. IMHO as someone who has
been working them for a very long time, the AERO/OMNI technologies fit the
"big things in big packages" model.

Thanks - Fred

> -----Original Message-----
> From: rtgwg [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: Thursday, July 29, 2021 9:15 AM
> To: routing WG <[e-mail]>
> Cc: Vasilenko Eduard <[e-mail]>; Bob Hinden <[e-mail]>; Robert Moskowitz <[e-mail]-
> consult.com>; Linda Dunbar <[e-mail]>; Dino Farinacci <[e-mail]>; Erik Kline <[e-mail]>;
> [e-mail]
> Subject: AERO/OMNI/ATN-BGP follow-up discussion from 07/28/2021 rtgwg session
> 
> Hello, during my presentation on AERO/OMNI/ATN-BGP at the rtgwg session on 07/28/2021
> there was apparently a fairly robust discussion taking place in the chat window followed by a
> significant comment at the microphone at the end of the talk. I would like to take a moment
> to provide general responses to the questions and invite further discussion on the rtgwg list
> regarding the points listed below:
> 
> 1) What is the OAL?
> 
> As one person correctly responded, the OAL is the "OMNI Adaptation Layer". It can be
> thought of as an equivalent of AAL5, but adapted to heterogeneous Internetworks and
> not specific to ATM networks.
> 
> 2) What is meant by using the 6to4 Anycast IPv4 prefix?
> 
> Several responders commented that the 6to4 Anycast IPv4 prefix (192.88.99.0/24)
> is still visible on the Internet, i.e., even though its use has been deprecated by RFC7526.
> I will admit that the OMNI document seized on the concept of reclaiming that prefix
> based on a partial read of RFC7526 which states:
> 
>    "The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except
>    by a future IETF Standards Action."
> 
> However, Section 6 of RFC7526 ("Operational Recommendations") notes that
> existing users of the prefix *need not* cease using it and withdraw it from the
> global Internet routing system altogether, which explains why it still has a visible
> presence on the IPv4 Internet.
> 
> I will therefore note in the OMNI Issue Tracker that an IPv4 prefix must be
> obtained for the purpose of advertising an OMNI link Anycast service without
> explicitly referencing the 6to4 IPv4 anycast prefix. The prefix length must be
> no longer than /24 to ensure that it will be carried by the global Internet routing
> tables. However, IPv4 prefixes of /24 or shorter are becoming increasingly more
> difficult to come by due to the IPv4 address space runout. Does anyone have a
> spare IPv4 /24 they would like to offer?
> 
> 3) MTU adaptation refers to the fragmentation done by OAL, right? The encapsulated IP
> packets used a fixed MTU? Is my understanding correct?
> 
> Yes, it is correct that the OAL applies fragmentation at a layer below IP in exactly the
> same way as AAL5, but with a different "cell size". The OAL maintains a "Maximum
> Payload Size (MPS)" that is assured to be no larger than the smallest link MTU on the
> path from the OAL source to the OAL destination (while possibly traversing one or
> several OAL intermediate nodes). The minimum MPS is based on the IPv4 minimum
> Maximum Receive Unit (MRU) which by RFC1122 is 576 bytes. This means that the
> minimum "cell size" for the OAL is 576 bytes, and the OAL must fragment any IP
> packets that are larger. However, if the OAL source has knowledge that the path
> can support a larger MPS, it can use this larger size rather than 576 bytes. In terms
> of having a fixed MTU, however, the original source seems an OMNI interface MTU
> of 9180 bytes, however it may receive a Packet Too Big (PTB) "soft error" message
> that recommends reducing the packet size to a smaller value. This provides for an
> optimum packet size determination on a per-flow basis.
> 
> 4) Document sizes are large
> 
> There are currently three separate documents. The ATN-BGP document is a working
> group item of the rtgwg. It is 23 pages in length (18 not counting the change log and
> references) and is now ready for WGLC. The AERO document is 102 pages in length,
> but only 84 not counting trailing sections. The document is now ready for IETF adoption.
> The OMNI document is 124 pages in length but only 103 not counting trailing sections.
> The OMNI document was actually broken out of AERO as a separate document a few
> years ago; otherwise, a single combined AERO/OMNI document would have been
> quite large. But, while it is true that the AERO and OMNI docs are both large and
> dense, there have been other IETF publication for which the same has been true,
> e.g., RFC6275 (169 pages).
> 
> 5) At least one responder has provided significant input to the drafts
> 
> It is true that Eduard Vasilenko in particular provided many helpful recommendations
> or improvements to the documents that were greatly appreciated, for which I believe
> I have incorporated effective resolutions for most/all points raised. I have also
> benefitted from correspondences with the RFC-ISE as we entertained the possibility
> of moving the documents onto the Independent stream. However, I believe that a
> better service to the community would be realized if the documents were to be
> adopted by an existing working group. Candidate working groups include 6man,
> rtgwg and possibly also intarea. But, since AERO is mostly about routing and OMNI
> is mostly about Internetworking, one possible outcome would be to have rtgwg
> adopt AERO while intarea adopts OMNI (i.e., all pieces do not necessarily need
> to be done all in the same wg).
> 
> 6) It currently requires changes to IPv6 that were not adopted by 6man
> 
> There are no changes to existing IPv6 standards, including the IPv6 protocol itself
> (RFC8200) nor IPv6 Neighbor Discovery (RFC4861). It is true that OMNI does request
> a new IPv6 ND message option type assignment, but all uses of that option are
> specific to the OMNI protocol and the option is simply ignored by any receivers
> that do not implement the OMNI protocol. All other aspects of IPv6 and IPv6 ND
> are coordinated exactly as for the RFCs.
> 
> It is true, however, that OMNI asks to update RFC1191 and RFC8201 to include a
> new "Code" value for PTB messages to indicate an MTU "soft error" as opposed to
> a "hard error" which is currently indicated by Code=0. If this raises any sensitivities,
> I am open to discussion about other ways to approach this subject.
> 
> 7) TCP-over-ND and other ND-related changes.
> 
> First, there are no ND-related *changes*; only OMNI-specific ND *augmentations*.
> IPv6 ND works exactly as specified in RFC4861, but when an IPv6 ND message includes
> an OMNI option the OMNI protocol is also invoked (i.e., if and only if the recipient
> recognizes the OMNI protocol). There are no changes to RFC4861 proposed.
> 
> Second, about TCP, the mechanism needed by OMNI is exactly equivalent to the TCP
> "three-way handshake". But, instead of being a byte-sequenced protocol, OMNI is an
> OAL packet-sequenced protocol. So, the "windows" established in the three-way
> handshake provide an acceptable range of OAL packet sequence numbers and that
> is it - they do not provide for reliable in-order delivery, flow control, etc. Since the
> mechanism is exactly equivalent to TCP, a common terminology was used. But, if
> readers find that too confusing a new terminology could be adopted.
> 
> 8) The International Civil Aviation Organization (ICAO) is working on this.
> 
> Yes, it is true that much of the AERO/OMNI work was inspired by the ICAO
> Aeronautical Telecommunications Network (ATN) program. It is also true that
> ICAO is still considering multiple alternative solutions, with AERO/OMNI being
> the "distributed" mobility management alternative. ICAO had earlier issued a
> liaison statement hoping to encourage the IETF to take up the work:
> 
> https://datatracker.ietf.org/liaison/1676/
> 
> But, up to just a few weeks ago, the technical details in the draft(s) were still
> undergoing transformations. That is no longer the case, and I see no further
> significant transformations from what the drafts currently say. I therefore
> believe that the time has arrived for the IETF to take up the work.
> 
> 9) RFC 4380 is Teredo, what was the other RFC he cited?
> 
> The other is RFC6081 ("Teredo Extensions"), which essentially extends Teredo to
> make it useful for previously unsupported NAT variations.
> 
> 10) Are there any changes to existing routing protocols (asked by Linda Dunbar at the
> microphone after the talk)?
> 
> No; this is based entirely on standard IP routing protocols, including primarily BGP for
> establishing IPv6-based ULA routing information in a "spanning tree". The ATN-BGP
> document is therefore solely concerned with detailing the peering arrangements
> between core and stub Autonomous System Border Routers (ASBRs) and makes no
> non-standard requirements of the BGP protocol itself. Similarly, at the intradomain
> level it is expected that standard routing protocols such as OSPF, RIP, IS-IS and even
> MANET routing protocols would be used with no modifications.
> ---
> 
> Thank you for your attention to the above topics, and/or for any other topics
> that may need to be addressed. Again, please direct correspondences to the
> rtgwg list.
> 
> Fred Templin
> [e-mail]
> [e-mail]
> 
> ---
> 
> IETF111 rtgwg Chat Log (07/28/2021)
> 
> Juliusz Chroboczek
> OAL?12:17:33
> Alvaro Retana
> OMNI Adaptation Layer ???12:18:14
> Juliusz Chroboczek
> Makes sense, thanks.12:18:22
> Tom Hill
> 192.88.99.0/24 is still pretty visible on the Internet12:23:43
> Erik Kline
> reassigning 6to4 doesn't seem likely to me.12:24:39
> Juliusz Chroboczek
> 64 bytes from 192.88.99.1: icmp_seq=1 ttl=49 time=32.1 ms12:24:45
> Robert Moskowitz
> Almost never can reuse, though in has been done...12:25:10
> Bob Hinden
> I don't see anything about these addresses in this draft.12:25:35
> Robert Moskowitz
> TBD?12:25:47
> Tom Hill
> I thought I saw an email the other day that said 'this was done'?12:26:25
> Robert Moskowitz
> note it...12:27:20
> oops wrong chat window :(12:27:43
> Juliusz Chroboczek
> MTU adaptation refers to the fragmentation done by OAL, right? The encapsulated IP packets used a fixed MTU? Is my understanding
> correct?12:28:04
> Eduard V
> yes12:28:18
> Juliusz Chroboczek
> Thanks.12:28:29
> Eduard V
> and this fragment is the small one to be available in any situation12:28:43
> hence, 20+ fragments possible12:29:05
> Jeff Tantsura
> Juliusz/Eduard - please discuss verbally in Q&A part of the presentation12:29:32
> Eduard V
> all fixed size except last one12:29:32
> I have read it carefully. It is so big that does not make sense to discuss in IETF meeting format.12:30:16
> Robert Moskowitz
> atn mailing list, then?12:31:58
> Eduard V
> but who else spend a few days understanding this? I have generated 20+ recommendations or improvements to Fred directly.12:33:29
> Jeff Tantsura
> that's a very good question12:34:08
> Adrian Farrel
> @Eduard Really good that you took the time to provide feedback and recommendations. I know Fred has been busy making updates to the
> documents. Would be useful to have some feeling for the scope of the changes (you already gave a feeling for the volume) because this
> helps us understand what the status of the work is12:36:00
> Eduard V
> My conclusion is: "I believe that it should be ADOPTED because nothing else is competitive for the environment with Mobility
> requirements on a big scale. Or else sooner or later, the mobility requirement would be solved below IP by non-IP tools (like 3GPP
> did)."12:37:21
> The solution is solid, just HUGE.12:37:51
> Erik Kline
> It currently requires changes to IPv6 that were not adopted by 6man12:38:12
> Robert Moskowitz
> Boeing makes BIG things...12:38:12
> Eduard V
> Erik, I do not understand what should be changed.12:38:56
> Robert Moskowitz
> I think mostly due to "where are the users for this?"12:39:09
> Boris Khasanov
> good question Robert12:39:55
> Eduard V
> It s just L2 overlay cross everything with mobility support and all problems resolved in the universe (42).12:39:59
> Robert Moskowitz
> And my conversations within ICAO is why is this not moving in IETF? Are there technical problems????12:40:10
> Eduard V
> Only: nobody did read this.12:40:38
> Erik Kline
> Eduard: TCP-over-ND and other ND-related changes, as proposed12:40:58
> Robert Moskowitz
> The users don't come to the IETF. They expect tools they need already done. Working with new stuff is hard for the community. They do
> seem to be adapting.12:41:23
> Eduard V
> Yes, ND expansion is big here.12:41:47
> Dino Farinacci
> And that is a problem @BobM12:41:53
> Eduard V
> I do not understand what "TCP-over-ND" means12:42:09
> Robert Moskowitz
> Why I have become really active in ICAO TFSG.12:42:33
> ICAO = International Civil Aviation Authority and TFSG = Trust Framework Study Group12:43:25
> Bob Hinden
> See slide 13, is proposes adding TCP type flags to ND and a window.12:43:34
> Robert Moskowitz
> ICAO is a UN agency, but older!12:44:09
> Bob Hinden
> BTW, The last time I checked a few months ago, International Civil Aviation Organization (ICAO) was working on a different solution than
> what Fred has proposed. I don't know that current status.12:44:18
> Eduard V
> no. he has not expressed it properly. He called "window" something else. I was trapped into this too but later understood that it is not a
> window in reality (not for flow control). Just bad name.12:45:03
> Robert Moskowitz
> Lots being discussed. I am co-author of the GRAIN addressing proposal. I thing GRAIN and OMNI can work together.12:45:15
> Bob Hinden
> Eduard: I only know what I heard him say and what is on the slide.12:45:43
> Eduard V
> yes, the document is not easy to understand.12:46:15
> As I said to Fred: needs more structure and should be split into smaller pieces.12:46:50
> Juliusz Chroboczek
> RFC 4380 is Teredo, what was the other RFC he cited?12:47:23
> Robert Moskowitz
> All this part is outside my expertise. I have to count on others to interact on the routing stuff. Probably reorg and dividing will help us
> all.12:48:16
> Adrian Farrel
> @robert Does "reorg" mean break up the doc?12:48:52
> Robert Moskowitz
> in part, or 'just' move sections around for smoother reading.12:49:35
> Eduard V
> just move would not help.12:49:56
> Robert Moskowitz
> If sections can stand on their own, it could make sense for them all to be in a single document. Too many documents have stalled other
> areas in IETF.12:50:40
> And too big a doc makes it so that nothing gets done until it is all done.12:53:33
> I want to hop over to madinas now. Catch you all around!12:58:11
> Ketan Talaulikar
> @ Xuesong, what is the relation of this draft with draft-hu-spring-segment-routing-proxy-forwarding? Does it depend on the proxy
> forwarding draft?13:02:48
> Yingzhen Qu
> @Ketan, can you please ask Xuesong after her presentation?13:03:36
> Ketan Talaulikar
> ack13:03:52
> 
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg