Hi all, The majority of IETF documents are possible to read between lines. It has a lot of "water". Fred's text is very dense. Almost every sentence has meaning. One needs to read it, pause to think, then read next. Almost no duplicity, if one would miss some idea - then it would be no possibility to understand much other text. The number of problems covered is huge. What Fred has developed would be proper to compare to all documents that have been developed by LISP and a little more. LIST has split it for dozens of documents. By IETF traditions, a scope that Fred represents may be considered as a separate WG.
By the way, looks like LISP is coming into the situation to compete with Fred (number of problems that they touch close and close to Fred's). I see a big overlap in the scope of problems. Solutions are completely different. English is perfect, but I am not happy about readability. Fred's defaults (the world in his mind) are different from many other people. Hence, what is evident for Fred is not evident for me. It needs more explanation. It is the first text in my life that I need to say "too dense". Fred, sorry, but you have forgotten many times to explain some important artifacts. That is possible to understand only from the context in the middle of the document. It is a little like a puzzle. That is possible to solve if one would strain his brain for a few days. I believe the work is solid because after big efforts on my side I have deleted almost all my internal doubts (that I have put on a separate list while reading). I have not found many technical errors. The team has noted 1 case when something has not been requested from IANA, I have noted 3 such cases. But such things are easy to solve. The strongest complaint that I have was: 7 IP addresses for one interface (2 underlay, 5 overlay) looks too much. Every virtual thing has CAPEX. I did suspect that 1 ULA is possible to delete, such a network needs PI anyway. ULA should not be always mandatory. And I have a concern that some boxes should play the role in 2 different domains that is an administrative challenge. IPVPN Option C was considered possible only between friendly ASs. The same is here. But wireless networks used as an underlay look not so friendly. And I had 30 other comments of the smaller value, 10 of which were positive emotions. Ed/ -----Original Message----- From: Templin (US), Fred L [mailto:[email protected]] Sent: Friday, July 30, 2021 4:06 AM To: routing WG <[email protected]> Cc: Vasilenko Eduard <[email protected]>; Bob Hinden <[email protected]>; Robert Moskowitz <[email protected]>; Linda Dunbar <[email protected]>; Dino Farinacci <[email protected]>; Erik Kline <[email protected]>; [email protected] Subject: RE: AERO/OMNI/ATN-BGP follow-up discussion from 07/28/2021 rtgwg session > 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:[email protected]] On Behalf Of Templin (US), > Fred L > Sent: Thursday, July 29, 2021 9:15 AM > To: routing WG <[email protected]> > Cc: Vasilenko Eduard <[email protected]>; Bob Hinden > <[email protected]>; Robert Moskowitz <[email protected] consult.com>; > Linda Dunbar <[email protected]>; Dino Farinacci > <[email protected]>; Erik Kline <[email protected]>; > [email protected] > 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 > [email protected] > [email protected] > > --- > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
