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

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 29 Jul 2021 16:14:53 +0000

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-masked]
[email-masked]

---

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 30 Jul 2021 01:06:29 +0000

> But, while it is true that the AERO and OMNI docs are both large and

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-masked]] On Behalf Of Templin (US), Fred L
> Sent: Thursday, July 29, 2021 9:15 AM
> To: routing WG <[email-masked]>
> Cc: Vasilenko Eduard <[email-masked]>; Bob Hinden <[email-masked]>; Robert Moskowitz <[email-masked]
> consult.com>; Linda Dunbar <[email-masked]>; Dino Farinacci <[email-masked]>; Erik Kline <[email-masked]>;
> [email-masked]
> Subject: AERO/OMNI/ATN-BGP follow-up discussion from 07/28/2021 rtgwg session
> 
> @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
> 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
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 30 Jul 2021 09:19:11 +0000

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-masked]] 
Sent: Friday, July 30, 2021 4:06 AM
To: routing WG <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; Bob Hinden <[email-masked]>; Robert Moskowitz <[email-masked]>; Linda Dunbar <[email-masked]>; Dino Farinacci <[email-masked]>; Erik Kline <[email-masked]>; [email-masked]
Subject: RE: AERO/OMNI/ATN-BGP follow-up discussion from 07/28/2021 rtgwg session

> 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

> Cc: Vasilenko Eduard <[email-masked]>; Bob Hinden 
> <[email-masked]>; Robert Moskowitz <[email-masked] consult.com>; 
> Linda Dunbar <[email-masked]>; Dino Farinacci 
> <[email-masked]>; Erik Kline <[email-masked]>; 
> [email-masked]
> 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.
> 
> 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:
> 
> 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.
> 
> 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 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).
> 
> 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).
> 
> (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.
> 
> 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.
> 
> 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:
> 
> 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.
> 
> 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
> 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
> 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
> 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 
> 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
>