Subject: Re: [manet] OLSRv2 - Routable Address

From: Teco Boot <[email-masked]>
Date: Wed, 16 Nov 2011 13:51:48 +0100

I brought up the anycast topic in the meeting today. It seems
to me that anycast support in a MANET is of importance. Top
hit on search manet minutes, Oslo, July 14, 1999:
> The group seemed to agree that there was general interest in
> mobile location protocols applied to manet and that other areas
> may also be of interest including anycast,etc.
RFC2501 also mentions anycast. I see no reason to step back
from this.

Current -13 text says "anycast MUST NOT be considered
as routable addresses". But in general an anycast address
is a routable address.

BTW: nit on "routable address:  a network address which may
be used as the destination of a data packet." A network
address is a prefix (address + prefix length). Destination
of a packet is only an address.

Chris proposed a method for anycast support. I suggest to
support it slightly different:
a) The anycast address is configured on interfaces on some
routers, but these interfaces MUST NOT be included in the NHDP
message. This is somewhat an update on RFC6130:
>      o  All other network addresses of the router that are to be made
>         known to any other router for any reason.
Update is: anycast addresses are not to be made known with
NHDP to other routers, for a good reason.
b) The anycast address is included in Local Attached Network Set.

This looks a straightforward approach to me, and it is in
line with OLSRv1.

Teco.

2010/7/29 Dearlove, Christopher (UK) <[email-masked]>
>
> We need to rely on more than just luck with filters in a
> specification. Roughly speaking this would
>
> (a) Leave routable defined as is (excluding anycast).
> (b) Define a new category of attachable, also administratively
>    defined. Routable addresses SHOULD be attachable. Anycast
>    addresses MAY be attachable. (There is, I think, no reason
>    to make either of those stronger.)
> (c) Local attached addresses MUST be attachable (rather then
>    routable). Other uses of attached addresses modify accordingly
>    (such as received message sanity checking rules).
> (d) Attachable addresss can be put in the routing table.
>
> Now are there any problems with this?
>
> (Conceptually I quite like having the rules for attached addresses
> separate from the rules for interface addresses, as they already
> have reuse differences - interface addresses must be unique to a
> router, attached addresses do not need to be.)
>
> --
> Christopher Dearlove
> Technology Leader, Communications Group
> Networks, Security and Information Systems Department
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194  Fax: +44 1245 242124
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87,
> Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
> -----Original Message-----
> From: Henning Rogge [mailto:[email-masked]]
> Sent: 29 July 2010 11:52
> To: Dearlove, Christopher (UK)
> Cc: Teco Boot; MANET IETF
> Subject: Re: [manet] OLSRv2 - Routable Address
>
>
>                    *** WARNING ***
>
>  This message has originated outside your organisation,
>  either from an external partner or the Global Internet.
>      Keep this in mind if you answer this message.
>
>
> On Thu, Jul 29, 2010 at 10:49, Dearlove, Christopher (UK) > However
> extension to handle anycast addresses appears, at first
> > sight, to be relatively straightforward. Consider three classes
> > of address: routable (excluding anycast), anycast and other.
> > (This trerminology for this email only.) Then we allow anycast
> > addresses as attached networks, but not as interface addresses,
> I agree to this, this should work fine, most likely even without
> changing the code (except the filter code that prevents setting up the
> attached network addresses.
>
> (our OLSRv1 implementation can handle anycast as HNA, just because
> noone thought about implementing a filter to prevent them being set in
> the configuration).
>
> > i.e. we relax the restriction on attached addresses only to be
> > "routable or anycast" rather than "routable". Other restrictions
> > are unchanged. (Attached addresses can already be shared by
> > routers.) Are there any other addresses that could be called
> > "attachable" beyond (unicast) routable and anycast? And note
> > that I said "at first sight" above, I reserve the right to
> > realise I've made an error and this idea doesn't work.
> Multicast is routable, but it's a special case that requires
> additional work and information. So we should not allow it in the
> normal attached network case.
>
> Henning Rogge
>
> --
> "Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
> ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
> Marti)
>
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 21 Nov 2011 08:03:34 +0100

Hello everyone,

I just got back from a longer business trip, so I it will take a few 
days to look through all mails I got.

> as routable addresses". But in general an anycast address

I agree with Teco, anycast is typically trivial to implement in OLSR 
daemons, so it would be bad if the RFC forbids the usage of anycast 
addresses.

The only thing where anycast should be definitely forbidden is the 
originator address, because this must be unique through the whole network.

> This looks a straightforward approach to me, and it is in

The OLSR.org implementation supports anycast by "accident" just by 
allowing them as HNAs. The normal routing approach of 'send packet to 
closest HNA with this IP' works perfectly for anycast.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Teco Boot <[email-masked]>
Date: Mon, 21 Nov 2011 08:45:21 +0100

Op 21 nov. 2011, om 08:03 heeft Henning Rogge het volgende geschreven:

> The only thing where anycast should be definitely forbidden is the originator address, because this must be unique through the whole network.

With anycast, it is common that (short lived) connections are set up towards the anycast address. Return traffic has the anycast address as source address.

See http://tools.ietf.org/html/draft-iab-anycast-arch-implications for more info.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Nov 2011 20:13:56 +0100

> With anycast, it is common that (short lived) connections are set up towards the anycast address. Return traffic has the anycast address as source address.

Maybe I misunderstood you, let me clarify...

1) I support to allow anycast IPs as "attached networks" in TCs.
Anycast is important, and implementing it this way in OLSR should be
easy.

2) I think anycast must not be allowed as 'originator addresses' (as a
field in the RFC 5444 message header). This field must be unique for
each OLSR node.

Henning Rogge

---

From: Joe Macker <[email-masked]>
Date: Tue, 22 Nov 2011 16:54:37 -0500

agree with Henning.
On Nov 22, 2011, at 2:13 PM, Henning Rogge wrote:

---

From: Teco Boot <[email-masked]>
Date: Wed, 23 Nov 2011 19:57:17 +0100

OK, I'm looking forward to have this been fold into the document.

Teco

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 23 Nov 2011 22:32:51 +0100

You wouldn't happen to have a concrete suggestion as to what is needed, for which the authors (and the WG) could consider the consequences?

Thanks,

Thomas

On Nov 23, 2011, at 7:57 PM, Teco Boot wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 24 Nov 2011 10:13:24 -0000

Is the following sufficient or not, changing the following two
definitions:

   Routable address:
      A network address which may be used as the destination of a data
      packet.  A router MUST be able to distinguish a routable address
      from a non-routable address by direct inspection of the network
      address, based on global scope address allocations by IANA and/or
      administrative configuration.  Broadcast and multicast
      addresses, and addresses which are limited in scope to less than
      the entire MANET, MUST NOT be considered as routable addresses.
      Anycast addresses MAY be considered as routable addresses.

   Originator address
      An address which is unique (within the MANET) to a router.  A
      router MUST select an originator address; it MAY choose one of its
      interface addresses as its originator address; it MAY select
      either a routable or non-routable address.  A broadcast, multicast
      or anycast address MUST NOT be chosen as an originator address.
      If a router selects a
      routable address then this MUST be one which the router will
      accept as a destination.  An originator address MUST NOT have a
      prefix length, except for when included in an Address Block where
      it MAY be associated with a prefix of maximum prefix length (e.g.,
      if the originator address is an IPv6 address, it MUST have either
      no prefix length, or have a prefix length of 128).

?

(Deliberately not reformatted, so changes can be diffed.) Is there
anywhere else in the document that would need changing? (I believe
the question over whether anycast addresses can be source addresses
is outside the scope of OLSRv2, so we don't need an answer.)

Communications and Networks Capability

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Clausen
Sent: 23 November 2011 21:33
To: Teco Boot
Cc: [email-masked]
Subject: Re: [manet] OLSRv2 - Routable Address

Thanks,

Thomas

---

From: Teco Boot <[email-masked]>
Date: Thu, 24 Nov 2011 11:37:48 +0100

My suggestion:

1) Errata on RFC6130. On some places, "all addresses" is specified:
E.g. page 25:
>    It is not necessary to include all addresses of an interface in the
>    Local Information Base, and hence in HELLO messages.  However, any
>    address that may be the source address of an IP datagram sent from
>    that interface MUST be included (and at least one address MUST be
>    included).

Problem:
Anycast addresses MUST be excluded from "all addresses". 

Suggestion: 
Add some text in section 4.1, bottom, such as:
    Anycast addresses are excluded from signaling of this this protocol.

2) Update olsrv2-13
 - remove anycast in text on Routable Address
   (or use Christopher's proposal)
 - in 4.2, add some text on anycast and local attached networks, such as
   adding the "&>" line to:
>    o  May have one or more non-OLSRv2 interfaces and/or local attached
>       networks for which this router can accept packets.  All routable
>       addresses for which the router is to accept packets MUST be used
>       as an (OLSRv2 or non-OLSRv2) interface network address or as an
>       address of a local attached network of the router. 
&>     Anycast addresses are processed as local attached networks.
 - Text on originator address, as suggested by Christopher.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 24 Nov 2011 12:33:07 -0000

First, I don't believe we need, or are in the business of,
errata for RFC 6130. If it can't be amanaged without such
errata, we shouldn't be doing it. However I also do not see
why such an erratum is necessary.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 24 November 2011 10:38
To: Thomas Clausen; Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [manet] OLSRv2 - Routable Address

                    *** WARNING ***

My suggestion:

Problem:

Suggestion: 

2) Update olsrv2-13

Teco