[manet] Re: HELP

Please unsubscribe from this list. thanks

________________________________
From: [email protected] <[email protected]>
Sent: Friday, August 2, 2024 2:41 AM
To: [email protected] <[email protected]>
Subject: manet Digest, Vol 233, Issue 1

Send manet mailing list submissions to
        [email protected]

To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of manet digest..."

Today's Topics:

   1. Re: OLSRv2 draft (Christopher Dearlove)
   2. Re: OLSRv2 draft (Juliusz Chroboczek)
   3. IPv6 Address for Ad Hoc Networks (Templin (US), Fred L)


----------------------------------------------------------------------

Message: 1
Date: Thu, 1 Aug 2024 14:24:29 +0100
From: Christopher Dearlove <[email protected]>
Subject: [manet] Re: OLSRv2 draft
To: Juliusz Chroboczek <[email protected]>
Cc: "[email protected] List" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain;       charset=utf-8

Juliusz

As I outlined in a previous post, I think the presentation in this draft is not ideal.

This is not a variant of OLSRv2. The normative part presents a recommendation (technically not always a RECOMMENDATION as it has MAY/SHOULD/MUST levels) as to the sending of a specific responsive TC message.

However it does motivate it by noting that in a very specific scenario this message is needed. That scenario is one where routers only arrive and depart. As such the case you provide is outside that scenario, and doesn’t consider it. Also note the discussion in the draft about message loss, making this doubly outside the scope of the discussed scenario. So the answer is nothing changes, the new message doesn’t help, but it’s not being suggested.

More generally, where messages might have long, but not infinite, intervals, this responsive message (sending a TC message when the presence of a new router is identified) might accelerate convergence.

[There is a case not discussed that involves link changes that would trigger the message, which is network joining, where multiple new routers will appear in short order. The responsive TC message to the first of these should reach all of them. But to prevent a cascade of new messages, message minimum interval should be respected, as always.]

I think if I were to rewrite the draft - I might, or might wait see what other responses there are - I would restructure as follows.

Discuss that there can be scenarios with longer interval times, including backoff case. This can be combined with using responsive messages where changes occur.

But one case where responsive messages don’t bridge gap between scheduled messages with a long interval is the remote TC message. While permitted by OLSRv2, there is no recommendation to use them.

This draft is that.

The extreme case is only arrivals and departures, and can messages be purely responsive? Discuss in Appendix.

Normative part as currently.

There’s a few details to get right in that reorganisation, but address that if I do this.

Christopher

> On 27 Jul 2024, at 00:15, Juliusz Chroboczek <[email protected]> wrote:
>
> Hi Chris,
>
>> That asymmetry can be broken if an additional form of responsive message
>> is sent - a TC message in response to a new tuple in the Advertised
>> Remote Router Set.
>
> What happens if that message is lost?
>
> Suppose you've got this topology, where the integers are the link metrics:
>
>
>    A
>    | \ 4
>    |  \
>  1 |   C
>    |  /
>    | / 1
>    B
>
> A is using the route A-B-C, B is using the route B-C.
>
> Now the link B-C breaks, so B reroutes its traffic through A.  It sends
> a TC, but the TC is lost, so A is still sending its packets to C.
>
> In ordinary OLSR, the loop will be broken at the next TC.  What happens in
> your variant of OLSR?
>
> -- Juliusz


------------------------------

Message: 2
Date: Thu, 01 Aug 2024 17:52:14 +0200
From: Juliusz Chroboczek <[email protected]>
Subject: [manet] Re: OLSRv2 draft
To: Christopher Dearlove <[email protected]>
Cc: "[email protected] List" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8

> However it does motivate it by noting that in a very specific scenario
> this message is needed. That scenario is one where routers only arrive
> and depart. As such the case you provide is outside that scenario, and
> doesn’t consider it.

Ok, then let's add a new router Z:

       4
    A-----C
    |     |
    |     |
  1 |     | 1
    |     |
    |     |
    B-----Z
       1

A is going A-B-Z-C, B is going B-Z-C.  Router Z leaves the network,
B reroutes through A, the TC that B sends to A gets lost, and you've got
a persistent routing loop.

I know of two ways to solve the problem:

  - send periodic TCs, as in OLSR(v2);
  - use reliable flooding for distributing topolgy, as in OSPF and IS-IS.

If you have a novel solution, then I'm very much interested.

-- Juliusz


------------------------------

Message: 3
Date: Thu, 1 Aug 2024 21:40:50 +0000
From: "Templin (US), Fred L" <[email protected]>
Subject: [manet] IPv6 Address for Ad Hoc Networks
To: IPv6 List <[email protected]>, "[email protected]" <[email protected]>
Message-ID: <[email protected]
        110.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="utf-8"

Hi, this draft has been updated based on feedback from the IETF120 6MAN and MANET working
group sessions where the work was presented. The updates include:

  - Drop support for fec0::/10 - reason: RFC3879 deprecation has rendered this prefix inoperable
  - Use prefix 2001:20::/28 [RFC7343][RFC7401] as "Type-1" Multilink-Local Address (MLA) prefix
  - Use prefix 2001:30::/28 [RFC9374] as "Type-2" MLA prefix
  - Allow future documents to define new MLA types, if necessary

While MANETs represent a natural basic use case, the IPv6 Ad Hoc network addressing
scheme applies to all manners of IPv6 networks and not just those that fall within the auspices
of the MANET working group. The work is therefore in scope for the larger Internet area in
general the same as RFC5889, but is more specifically targeted for 6MAN due to its exclusive
focus on IPv6. For full context, please view the IETF120 MANET session presentation beginning
at the 22minute mark here:

https://play.conf.meetecho.com/Playout/?session=IETF120-MANET-20240726-1630

Please review and comment so that this essential work can move forward.

Thank you - Fred Templin

-----Original Message-----
From: [email protected] <[email protected]>
Sent: Thursday, August 01, 2024 12:49 PM
To: [email protected]
Subject: I-D Action: draft-templin-6man-mla-19.txt

Internet-Draft draft-templin-6man-mla-19.txt is now available.

   Title:   IPv6 Addresses for Ad Hoc Networks
   Author:  Fred L. Templin
   Name:    draft-templin-6man-mla-19.txt
   Pages:   13
   Dates:   2024-08-01

Abstract:

   Ad Hoc networks often present a challenging environment for IPv6
   addressing due to the indeterminant neighborhood properties of their
   interfaces.  IPv6 nodes must assign IPv6 addresses to their interface
   connections to Ad Hoc networks that are locally unique but must not
   be propagated to other networks.  IPv6 nodes must therefore be able
   to assign self-generated addresses to their interfaces when there are
   no IPv6 Internetworking routers present that can coordinate topology-
   relative IPv6 addresses or prefixes.  This document specifies IPv6
   address types that can be assigned to Ad Hoc network interfaces.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-mla/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-templin-6man-mla-19

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-templin-6man-mla-19

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list -- [email protected]
To unsubscribe send an email to [email protected]

------------------------------

Subject: Digest Footer

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]


------------------------------

End of manet Digest, Vol 233, Issue 1
*************************************

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]