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

Hi Sheng,

> -----Original Message-----
> From: cin-bounces@ietf.org [mailto:cin-bounces@ietf.org] On Behalf Of
> Sheng Jiang
> Sent: Wednesday, August 29, 2012 6:27 PM
> To: Templin, Fred L; cin@ietf.org
> Cc: terry.davis@ijetonboard.com
> 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.

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
fred.l.templin@boeing.com

> Best regards,
> 
> Sheng
> 
> >-----Original Message-----
> >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> >Sent: Thursday, August 30, 2012 12:13 AM
> >To: Sheng Jiang; cin@ietf.org
> >Cc: terry.davis@ijetonboard.com
> >Subject: RE: why not Nemo? //Aviation Networks
> >
> >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
> >fred.l.templin@boeing.com
> >
> >
> >> -----Original Message-----
> >> From: cin-bounces@ietf.org [mailto:cin-bounces@ietf.org] On Behalf Of
> >> Sheng Jiang
> >> Sent: Tuesday, August 28, 2012 6:55 PM
> >> To: cin@ietf.org
> >> Cc: terry.davis@ijetonboard.com
> >> 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
> >> cin@ietf.org
> >> https://www.ietf.org/mailman/listinfo/cin
> _______________________________________________
> cin mailing list
> cin@ietf.org
> https://www.ietf.org/mailman/listinfo/cin