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
