Subject: [mif] Question to draft-ietf-mif-dhcpv6-route-option-05

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 24 Oct 2012 12:34:23 +0000

Hello,

draft-ietf-mif-dhcpv6-route-option-05 states in section 7.1:

   Metric field (available in previous version of this draft) has been
   replaced with 2-bit preference field that is in line with RIO
   information.

Issue1:

the section 4 states:

   In terms of the high level operation of the solution defined in this

   draft, a DHCPv6 client interested in obtaining routing information

   request the route options using the DHCPv6 Option Request Option

   (ORO) sent to a server.  A Server, when configured to do so, provides

   the requested route information as part of a nested options structure

   covering; the next-hop address; the destination prefix; >>the route

   metric<<; any additional options applicable to the destination or next-

   hop.

Given the statement in section 7.1, is "the route metric" above correct or is it an obsolete text?

Issue2:

section 5.2 states:
....

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |       OPTION_RT_PREFIX        |          option-len           |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                         Route lifetime                        |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     | Prefix-Length |Resvd|Prf|Resvd|                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |

     |                            Prefix                             |

     |                          (up to 16 octets)                    |

     |                                                               |

     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                               |                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |

     .                                                               .

     .                         RT_PREFIX sub-options                 .

     .                                                               .

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Route Prefix Option Format

....

   Metric:   Route Metric. 8-bit signed integer.  The Route Metric

             indicates whether to prefer the next hop associated with

             this prefix over others, when multiple identical prefixes

             (for different next hops) have been received.
....

There is no "Metric" field shown in the Figure 3.

Thanks for clarification.

Kind regards

IVO SEDLACEK

Ericsson
Mobile +420 608 234 709
[email-masked]
www.ericsson.com

[Description: Description: http://www.ericsson.com/]<http://www.ericsson.com/>

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Oct 2012 12:03:15 +0200

Le 24/10/2012 14:34, Ivo Sedlacek a écrit :
>     covering; the next-hop address; the destination prefix;_>>the route_
>
> _    metric<<;_  any additional options applicable to the destination or next-
>
>     hop.
>

I agree, I wonder the same thing as you.

In implementation, when inserting a routing entry in a routing table 
some times there is a need of a 'metric' field.  Often that is valued to 
1 or 0, when no dynamic routing protocol is used.

For default route configuration, this 'metric' field in routing table is 
not of utmost importance because often it is assumed as 1 (the next-hop 
is right next to it).

But whether or not the 'metric' field should be offered by DHCP 
Route-Option is debateable?

> section 5.2 states:

I agree and I wonder the same as you?

Also, the meaning of the "metric" as suggested above - prefer a next-hop 
over another - is relatively debateable.  I thought about this metric as 
more of a hint to a dynamic routing protocol which may be in place to 
calculate shorter routes in terms of hopcount.

On another hand, that mentioned 'preference' signification of 'metric' 
is probably more of what RFC4191 calls also "preference", instead of 
'metric'.

I wonder about the authors' intention about this 'metric' field.

Alex

> Description: Description: line
>
> *IVO SEDLACEK *
>
>
> Ericsson
> Mobile +420 608 234 709
> Description: Description: http://www.ericsson.com/
> <http://www.ericsson.com/>
>
> This Communication is Confidential. We only send and receive email on
> the basis of the terms set out at www.ericsson.com/email_disclaimer
> <http://www.ericsson.com/email_disclaimer>
>
>
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>