Subject: [cin] why not Nemo? //Aviation Networks

From: Sheng Jiang <[email-masked]>
Date: Wed, 29 Aug 2012 01:54:56 +0000

Hi, all,

Read through the mail archive, Aviation Networks looks like an interesting case that needs to work on. It needs some protocol work by the current description.

However, I don't find the discussion so far mentioned MEMO at all. For my memory, MEMO (RFC 3963, also a set of relevant  RFCs later, referring as Network Mobility) was designed for these scenarios, aircrafts, trains, etc. Mobile routers with Nemo do NOT generate any extra global routing items. IETF had put considerable efforts on mobility support, particularly in IPv6. It would be good to start investigation from these existing works though they were not deployed yet. Maybe further investigation found Nemo was not enough for certain technical requirements, then some improvement may be needed.

Best regardsm

Sheng

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Aug 2012 09:12:39 -0700

Hi Sheng,

IRON was also designed specifically for aviation networks, and
I believe it is better suited to that purpose (and others) than
NEMO. A first version of the IRON architecture was published as
RFC6179, and is based on its constituent mechanisms VET (RFC5558)
and SEAL (RFC5320). These three documents are now being published
in a second edition, found here:

https://datatracker.ietf.org/doc/draft-templin-ironbis/
https://datatracker.ietf.org/doc/draft-templin-intarea-vet/
https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

Let me know if you have any questions or comments on these.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sheng Jiang
> Sent: Tuesday, August 28, 2012 6:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [cin] why not Nemo? //Aviation Networks
> 
> Hi, all,
> 
> Read through the mail archive, Aviation Networks looks like an interesting
> case that needs to work on. It needs some protocol work by the current
> description.
> 
> However, I don't find the discussion so far mentioned MEMO at all. For my
> memory, MEMO (RFC 3963, also a set of relevant  RFCs later, referring as
> Network Mobility) was designed for these scenarios, aircrafts, trains,
> etc. Mobile routers with Nemo do NOT generate any extra global routing
> items. IETF had put considerable efforts on mobility support, particularly
> in IPv6. It would be good to start investigation from these existing works
> though they were not deployed yet. Maybe further investigation found Nemo
> was not enough for certain technical requirements, then some improvement
> may be needed.
> 
> Best regardsm
> 
> Sheng
> _______________________________________________
> cin mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cin

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 Aug 2012 01:27:09 +0000

Hi, Fred,

I knew IRON, VET and SEAL. They looks like a set of well-designed system. However, they all published as Experimental or Informational documents. They all published through independent submission. It means these designs are deployable in theory, but not really proven in working system. So, the primary question would be: are there existing implementations, have they been tested for interoperability?

Best regards,

Sheng

>From: Templin, Fred L [mailto:[email-masked]]
>Sent: Thursday, August 30, 2012 12:13 AM
>To: Sheng Jiang; [email-masked]
>Subject: RE: why not Nemo? //Aviation Networks
>
>Hi Sheng,
>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 30 Aug 2012 08:40:41 +0000

Hi, in the bar bof, has any conclusion been made on the topics which cin intends to cover or what cin is not interest in? It would be good if we can clarify the issues we intend to address before we start the discussion..

Dacheng

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sheng
> Jiang
> Sent: Thursday, August 30, 2012 9:27 AM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [cin] why not Nemo? //Aviation Networks
> 
> Hi, Fred,
> 
> I knew IRON, VET and SEAL. They looks like a set of well-designed system.
> However, they all published as Experimental or Informational documents. They
> all published through independent submission. It means these designs are
> deployable in theory, but not really proven in working system. So, the primary
> question would be: are there existing implementations, have they been tested
> for interoperability?
> 
> Best regards,
> 
> Sheng
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Aug 2012 07:24:58 -0700

Hi Sheng,

> Sent: Wednesday, August 29, 2012 6:27 PM
> However, they all published as Experimental or Informational documents.
> They all published through independent submission.

The first editions of IRON, VET and SEAL were indeed published
as independent submissions. The second editions are now being
published as individual submissions through AD sponsorship. This
publication track requires thorough review by the IESG and an
IETF last call. This same model was applied for the publication
of AERO (RFC6706), for which a UDP port is now allocated.

> It means these designs
> are deployable in theory, but not really proven in working system.

Not necessarily. There are certainly examples of widely-deployed
and proven working systems based on independent-submission RFCs
(e.g., RFC5214).

> So, the
> primary question would be: are there existing implementations, have they
> been tested for interoperability?

There is an implementation of the first edition of SEAL here:

http://www.isatap.com/seal/

Thanks - Fred

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 Aug 2012 01:34:20 +0000

>and proven working systems based on independent-submission RFCs

OK, change my expression: not every independent-submission RFCs has been proven in working system by the time of publish.

>http://www.isatap.com/seal/

Glad to know this.

Regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 31 Aug 2012 02:24:32 +0000

In my observation, Critical Infrastructure Networks can be very different from each other: aviation networks may have more common with train networks, while hospital networks and Grid networks may have very different requirements. It may be worth to starting investigation/analysis/ps with one or two specific network. Aviation network would be a good start, I guess. Or focusing on a certain technical branch may work out, like mobility network support.

Regards,

Sheng

>From: Zhangdacheng (Dacheng)
>Sent: Thursday, August 30, 2012 4:41 PM
>To: Sheng Jiang; Templin, Fred L; [email-masked]
>Hi, in the bar bof, has any conclusion been made on the topics which cin
>intends to cover or what cin is not interest in? It would be good if we can
>clarify the issues we intend to address before we start the discussion..
>
>Dacheng
>
>They

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 31 Aug 2012 02:30:42 +0000

Agree! I also think we need to clarify whether the backward compatibility is a critical issues we should consider since in the previous discussion in the list it seems that people have more interests in how to generate critical networks with new technologies. 

Dacheng 

> From: Sheng Jiang
> Sent: Friday, August 31, 2012 10:25 AM
> To: Zhangdacheng (Dacheng); Templin, Fred L; [email-masked]
> In my observation, Critical Infrastructure Networks can be very different from
> each other: aviation networks may have more common with train networks,
> while hospital networks and Grid networks may have very different
> requirements. It may be worth to starting investigation/analysis/ps with one or
> two specific network. Aviation network would be a good start, I guess. Or
> focusing on a certain technical branch may work out, like mobility network
> support.
> 
> Regards,
> 
> Sheng
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Aug 2012 09:02:07 -0700

Hi Sheng,

> Sent: Thursday, August 30, 2012 6:34 PM
> OK, change my expression: not every independent-submission RFCs has been
> proven in working system by the time of publish.

I think the "multiple independent interoperable implementations"
requirement doesn't come into play until Draft Standard. So, I
believe it is OK for a document to go forward even as Proposed
Standard without necessarily needing a backing implementation.

Thanks - Fred

> >> >> However, I don't find the discussion so far mentioned MEMO at all.
> For
> >> my
> >> >> memory, MEMO (RFC 3963, also a set of relevant  RFCs later,
> referring
> >> as

---

From: SM <[email-masked]>
Date: Fri, 31 Aug 2012 13:04:43 -0700

>requirement doesn't come into play until Draft Standard. So, I

The Draft Standard status is no longer available (see BCP 9)

>Standard without necessarily needing a backing implementation.

Yes.

Regards,
-sm