Re: [geonet/its] Comments on draft-petrescu-autoconf-ra-based-routing

[Alexandru Petrescu <[e-mail]>]

Emmanuel,

Thank you for having read through the document, I am happy.

First, please know that the solution described in this draft (RA-based
IP prefix exchanges for direct Vehicle-to-Vehicle communications) is no
longer a focus for the work here in this list.

The focus now and here is about GeoNet - geographical networking, with
some applicability in vehicular communications, and with wider
applicability at Internet scale.  The token prefixing each email is now
[geonet/its] rather than [its].

That said, see below some comments.

Le 10/01/2014 18:08, Emmanuel Thierry a écrit :
> Hello,
>
> I took a look to the I.D. draft-petrescu-autoconf-ra-based-routing
> and i have some comments and questions about it. I don't know if it
> is the best place to discuss, please redirect me to the appropriate
> list if not !

This kind of things have been discussed here on this list during recent
years.  However, it is no longer the right place.

Other potential places where this could be discussed include the 6MAN
WG, because there is the place where Router Advertisement messages are
discussed.  Or maybe v6ops WG because there is where operational aspects
are discussed, and vehicular communications could be considered as
particular kinds of IPv6 deployments.

> 1/ RA Routing limit: My understanding of this draft is that RAs will
> be "forwarded" across multiple links.

Err, no.  The draft considers exclusively what happens on a single link.
  Like several vehicles being in close vicinity and forming a single IP
subnet; realized with maybe WiFi ad-hoc mode; without IP nor link-layer
forwarding.

This may be an inconvenient of this draft's solution, but that's how we
present it: a single link, single IP subnet between a few vehicles.

> A look to section 4.3 makes me think that, since Route Information
> are stored by the intermediate node (MR2), then resent to the next
> Mobile Router (either MR1 or MR3).

Well, I think it is the fault of the initial figure in that section.  In
that figure MR1, MR2 and MR3 all have their egress interface in the same
subnet, not different subnets.  Even if the figure shows 3 vertical
parallel bars it's to suggest message sequenced in time, but not space.
  A message received by MR2 from MR1 is not propagated to MR3.

We should better picture that.

> However i don't see any limit. It may be a concern if there is a
> undiscontinuing queue of moving objects.

CErtainly there is a problem if we interpret the figure as suggested.
If the routing messages are propagated then there should be limits
somewhere, to control looping, and more.  More than just the Hop Limit
field of the base IPv6 header.

One may imagine new particular fields in the RA to express such limits.
  For example in OLSR there is this concept of 2-hop neighborhood, 2-hop
set.  In our context we try to address this limit concept in another
draft draft-pfister-moving-net-autoconf-00 where 2bits are set aside for
later thinking.

But certainly there should be a way to limit propagation.

> Where this broadcast is supposed to be stopped ? Shouldn't there
> exist a TTL for that ?

Right question.

> 2/ Fixed Scene: The concept of "Fixed Scene" is quite abstract to
> me, i don't understand what it means and how it could be interpreted
> in a protocol standard. At no moment i envision in which Fixed Scene
> i am supposed to be. Could you elaborate on that ?

Yes, thanks for asking.

In a relatively distanced past there was some secrecy involved with
respect to the term "Incident Scene", so a more comfortable term was
invented "Fixed Scene".  But I will revert back to Incident Scene in the
next versions of the draft, if it looks appropriate.

An Incident Scene is an area around a car accident, or fire hazard.  At
this scene several vehicles arrive and stay fixed for a while.  For
example, at a car accident site one could notice the Police car, the
Pompiers car, and sometimes even the GDF car.  They stay there for a
while, and are coordinated by another smaller car.  They need to
communicate among them and with people intervening at the scene.

> 3/ Preference value: You use a preference value of 0x09, so that
> this route is not preferred among others. I think there is a typo and
> it should be 0x03, as stated in RFC 4191.

I think that's right.  It is indeed a typo, at least because one couldnt
fit the value 0x09 in 2 bits.

However, I am not sure it should be 0x03?  Does RFC4191 really says it
should be 0x03?

> 4/ Default router Even if you set the preference value to 0x03 to
> lower the preference of the advertising router, it remains a valid
> router for the receiver of this Router Advertisement. As a
> consequence, if there is no other router available (no road
> infrastructure), the Mobile Router which receives this Router
> Advertisement (or a node that don't understand the newly introduced
> "M" flag) may try to use it as a default router. Moreover, if a
> roadside router chooses to use the same preference value to lower
> its preference compared to other routers (for example a roadside
> router which serves as a backup router), a Mobile Router advertising
> its prefix through Router Advertisements may be preferred among this
>  valid backup router.
>
> It is unclear in section 4.3 if by "preference" and "lifetime", you
> mean the corresponding fields in the RA itself or in the RIO.

Right, good question.

> I assumed you meant in the RA. The RFC 4861 section 4.2 clearly
> states that the proper way to indicate that an advertising router is
> not likely to forward traffic for the default route, is to set Router
> Lifetime to 0. So the Router lifetime shouldn't be used there.

I think you're right.  I think these mobile routers are little likely to
present themselves as default routers, except in some cases. (e.g. in a
V2V2I deployment one would use V2V and V2I in sequence).

I guess yes that we should describe better how the Lifetime (of the RA)
should be used in conjunction with this Prf value.

> A Mobile Router (or roadside router) that wants to advertise specific
> prefixes may want to advertise it independently of whether the node
> is or isn't a router.

Err, if it sends RA then it is a Router, can't otherwise.

> The draft should allow to use these fields normally, i.e. set the
> Router Lifetime to 0 and Router preference to 0x00 if you don't
> forward traffic for ::/0, set the Router Lifetime and Router
> preference to an appropriate value if you forward traffic for ::/0.

Sounds reasonable.

> In order to code lifetime, Mobile Routers should use the lifetime
> field in the RIO, and set the preference field in the RIO to an
> appropriate value, according to whether or not the node considers it
> is the best candidate for reaching the destination.

Sounds reasonable.

We would need to discuss this further.

Alex

>
> Best regards Emmanuel Thierry
>
> _______________________________________________ its mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/its
>
>