[homenet] Alia Atlas' No Objection on draft-ietf-homenet-prefix-assignment-07: (with COMMENT)

[Pierre Pfister <[e-mail]>]

Hello Alia,

Thanks for these comments.

Please see inline for clarifications,
and please have a look at the reply to the discuss concerning a text change proposal
regarding dynamic topology support.


> Le 9 juil. 2015 à 00:06, Alia Atlas <[e-mail]> a écrit :
> 
> Alia Atlas has entered the following ballot position for
> draft-ietf-homenet-prefix-assignment-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with Alvaro and Brian on the need to clarify topology changes. 
> In Sec 3, I see
> "   The algorithm supports dynamically changing topologies:
> 
>   o  Nodes may join or leave the set of participating Nodes.
> 
>   o  Nodes may join or leave Links.
> 
>   o  Links may be joined or split."
> 
> and what isn't clearly stated is that when a link fails (partially or
> fully) or comes into existence ,
> is that a topology change?

The algorithm makes use of an abstract model.
In this abstract model, Links do not need to come into existence or be removed.
We can assume Links to have always existed, although no node was attached to it.
In that sense « Create a Link » or « Destroy a Link » is just a special case
of a node « joining a Link »  or «  leaving a Link » . 

In real life, of course, it is not that simple. You say a link may ‘fail’.
A link failure is, usually, a Link split.
Such an event may be detected by the hardware (wire unplugged), or by
an underlying mechanism (For instance, HNCP does that).

When such an event occurs, the flooding mechanism will inform the algorithm
which advertised prefix (if any) have been added or removed from the link.

   The Flooding Mechanism MUST:

   o  Specify whether an Advertised Prefix was assigned to a directly
      connected Shared Link, and if so, on which one.


> 
> For instance, if a link fails, surely that shouldn't be a topology change
> for the prefix assignment,
> but rather a matter for routing to handle.  I do see in Sec 4.3 "When a
> Link is removed, all Assigned Prefixes
> assigned to that Link MUST be destroyed."  Perhaps a link removal isn't
> considered a topology change in this
> context because it doesn't cause renumbering??

If a Link is split, you cannot keep using the same prefix on two different links.
You therefore have to renumber.

> 
> How is a new Link added to be considered?

As a node joining a Link.

>  How does a router know that
> its end of a link is the
> same link as on another router?  

That is provided by the Flooding Mechanism, as quoted before.

> How is a link "removed" versus merely
> down?

Link removal is a configuration change.
I, the admin, ask the Node to stop executing the algorithm on a given link.
That is a Node leaving a Link.

Otherwise, any kind of link failure is more to be considered as a Link split.

> 
> An assumption seems to be that the flooding mechanism can work without
> any prefix numbering.  That's fine but
> would be good to state.  I'm a bit twitchy about the bootstrapping.
> 

In the absence of topology change, yes.
That is due to the use of the ‘Flooding Delay’ as a probation delay before using 
the prefix.

But if the topology changes, as detailed in the new proposed text, renumbering may happen.


Thanks

- Pierre