Subject: New Version Notification for draft-sarikaya-6man-rfc4191bis-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Jul 2013 12:06:12 -0500

A new version of I-D, draft-sarikaya-6man-
>
> rfc4191bis-00.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Filename:        draft-sarikaya-6man-rfc4191bis
> Revision:        00
> Title:           IPv6 RA Options for Next Hop Routes
> Creation date:   2013-07-08
> Group:           Individual Submission
> Number of pages: 15
> URL:
> http://www.ietf.org/internet-drafts/draft-sarikaya-6man-rfc4191bis-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-sarikaya-6man-rfc4191bis
> Htmlized:
> http://tools.ietf.org/html/draft-sarikaya-6man-rfc4191bis-00
>
>
> Abstract:
>    This proposes an update on RFC 4191 in order to define new Router
>    Advertisement options for configuring next hop routes on the mobile
>    or fixed nodes.  Using these options, an operator can easily
>    configure nodes with multiple interfaces (or otherwise multi-homed)
>    to enable them to select the routes to a destination.  Each option is
>    defined together with definitions of host and router behaviors.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jul 2013 11:24:36 +0200

Hello,

This draft proposes, among other things, that Routers send
prefix/nexthop couples in the RA, towards a multi-interfaced Host.

This would allow the Host to install specific routes, and subsequently
to select the nexthop based on the destination prefix.

A similar mechanism is proposed in vehicular communications, where two
nearby vehicles exchange their prefix/nexthop using RA (Router-to-Router
communications, not Router-to-Host).  Some of these RA-based prefix
exchanges are considered at some SDO, and why not at IETF as well.

Although Router-to-Router is not the same as Router-to-Host, one
legitimately wonders whether this is not the same concept.

Given this perspective of industry interest, I wonder the following:
- what particular industry has interest in
   the mechanism of draft-sarikaya-6man-rfc4191bis-00.txt?
- where to discuss this is most appropriate: in an IPv6-specific
   group?  in a vehicular-specific group?  in a multi-interfaced
   specific group?  Maybe a cross-group review would be valuable?

Yours,

Alex

Le 08/07/2013 19:06, Behcet Sarikaya a écrit :
> rfc4191bis-00.txt has been successfully submitted by Behcet Sarikaya
> and posted to the IETF repository.
>
> Filename:        draft-sarikaya-6man-rfc4191bis Revision:        00
> Title:           IPv6 RA Options for Next Hop Routes Creation date:
> 2013-07-08 Group:           Individual Submission Number of pages: 15
> URL:
Status: http://datatracker.ietf.org/doc/draft-sarikaya-6man-rfc4191bis
> Abstract: This proposes an update on RFC 4191 in order to define new
> Router Advertisement options for configuring next hop routes on the
> mobile or fixed nodes.  Using these options, an operator can easily
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Jul 2013 16:34:53 +0300

Having read this I-D,

One question:

   When an end host receives a
   router advertisement message with a PIOMT and the prefix class
   suboption, it can use the suboption information as an additional hint
   for selecting the prefix for a desired purpose and use case.  The
   prefix class has only local administrative meaning i.e., they are
   local to the access network and may overlap both semantically and
   registry wise across different administrative domains.

How is the class information delivered to the nodes? I know this is outside the scope of this protocol specification, but having some understanding on that would help us better judge the applicability.

And, one comment:

The overall problem statement and the solution make sense. In fact, we have a complementary draft which exposes the IP address properties to the applications and allow them to make a proper selection. http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-00

Regards,

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 19 Jul 2013 17:56:38 +0300

Alper,

Thanks for the review.. 

> How is the class information delivered to the nodes? I know this is outside the scope of this protocol specification, but having some understanding on that would help us better judge the applicabil…

Since the class information is intended to be administrative domain
specific a good proponent for information delivery is a connection
manager type of application or some service daemon (something provided
e.g. by an enterprise network administrator) that application can query.
I all cases the applications need to be aware of classes. (note that we
do not have standardized means for identifying administrative domain
boundaries/provisioning domains yes - Mif works on that part..)

> The overall problem statement and the solution make sense. In fact, we have a complementary draft which exposes the IP address properties to the applications and allow them to make a proper selecti…

Great, good to know.

- JOuni

> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6