Subject: Re: [Roll] Transit information option

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Jun 2010 18:44:38 +0200

Hi Mathilde

1)      I think the MAY refers to the fact that there can also be another target option right after a target option in case multiple targets factorize a same transit info. The text should say that there MUST be at least one and possibly multiple transit option after one or possibly multiple target option(s), and all the transit options that operate one all the targets. Multiple transit options happen in the case of non-storing nodes to advertise multiple parents. Multiple targets for a same transit information happens for instance when a node has multiple addresses.

2)      Well, that's because we're not doing record route. In non-storing, the only node that cares is the root, and the root gets all the piecewise info (child->parent), from which it recursively builds the paths it needs, optimizing the preference along. The root does not care whether the info about all the parents for a target was obtained though the individual parents. Also, we expect that all nodes in the network do the same, otherwise, yes, you'd need to send to parent B to ask parent B to send its own info, etc...

3)      No, we are not recording route as I explained above. That's I guess where we have a confusion.

4)      At a given point of time I'm unsure that the root would need to load balance over multiple SR path. But if one Source route path is broken, the root needs to build another one. The control bits will enable the root to optimize the preference of the path that is it building.

Courage J

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mathilde Durvy (mdurvy)
Sent: Wednesday, June 09, 2010 3:08 PM
To: [email-masked]
Subject: [Roll] Transit information option

Hi All,

A few items that might be worth clarifying in version 09:

- "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2).

- "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help.

- In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case?

- Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice... Similar to Phil I'm getting worried about the increased complexity.

Best,

Mathilde

Durvy Mathilde
Software Engineer
Technology center

[email-masked] <mailto:[email-masked]> 
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

Cisco Systems International Sàrl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page <http://www.cisco.com> 

 Think before you print.

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.