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

[Alexandru Petrescu <[e-mail]>]

Le 24/10/2012 14:34, Ivo Sedlacek a écrit :
> 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?

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?

> 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.

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

>
> Thanks for clarification.
>
> Kind regards
>
> Description: Description: line
>
> *IVO SEDLACEK *
>
>
> Ericsson
> Mobile [phone]
> [e-mail]
> 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>
>
>
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>