TWiki > DNA > DNASolution1 > DNASoln1Issue003	TWiki webs: Main | TWiki | Know | Sandbox
	DNA . { History of Changes | DNA Documents | Search | Go }

Content of multicast RAs

There has been discussion lately about aggregating responses in
multicast RAs. The draft mentions sending RAs multicast for aggregation
of responses but doesn't specify how this is done - specifically, it
makes no mention of including multiple LNOLOs.

It may, due to MTU constraints, not be possible to include all the
necessary LNOLOs (as it also may not be possible to fit a completeRA
within the MTU).

Given this, is it worth having LNOLOs in multicast RAs at all?
I think the reason for them was to cover cases where it was not
possible to fit a completeRA, but they seem to have the same
limitation.

In solicited multicast RAs:
   - Should there be LNOLOs if applicable?
   - If yes, should there be multiple LNOLOs if applicable?
   - If yes, and there is not space for both CompleteRA and
     applicable LNOLOs, which should take preference? 

Discussion

Jim

Brett,

I think that RAs which are multicast in res;ponse to a depletion of unicast
tokens should contain exactly the same information as the RAs that are
multicast as beacons on the link. So, I'd say that they should be CompleteRA
or CPL, but not contain LNOLOs or any specific responses to RSs received.
Makes things simpler.

            jak

Sathya

Brett Pentland wrote:

> There has been discussion lately about aggregating responses in
> multicast RAs. The draft mentions sending RAs multicast for aggregation
> of responses but doesn't specify how this is done - specifically, it
> makes no mention of including multiple LNOLOs.
>
> It may, due to MTU constraints, not be possible to include all the
> necessary LNOLOs (as it also may not be possible to fit a completeRA
> within the MTU).


There is a subtle difference in these two cases: with the compeleRA scenario, if you can not do it due to MTU restriction, the host MUST depend on its CPL to infer landmark not on link, when it receives a multicast RA. While with LNOLO's even if you cannot include all the necessary LNOLOs, the ones you include gives a specific answer to atleast those landmark questions.

Backward compatability is one thing. But, I am not in favor of depending on CPL as much as possible when DNA solution is implemented on the hosts/routers on the link. The issue is how to define 'as much as possible' - if we feel that the complexity of the solution increases too much, I am open to the idea of depending on CPL as part of the DNA solution. IMHO, defining LNOLO doesn't increase the complexity that much - it provides an explicit mechanism for the routers to respond to a 'yes/no' question - 'I think explicit is good' ;-)

> Given this, is it worth having LNOLOs in multicast RAs at all?
> I think the reason for them was to cover cases where it was not
> possible to fit a completeRA, but they seem to have the same
> limitation.


Again, not the same limitation. But, I understand what you mean here.

>
> In solicited multicast RAs:
>    - Should there be LNOLOs if applicable?


Yes.

>    - If yes, should there be multiple LNOLOs if applicable?


Yes. If all LNOLO's can fit in the RA, prioritize the landmark questions in order they were received.

>    - If yes, and there is not space for both CompleteRA and
>      applicable LNOLOs, which should take preference?


If the router can do CompleteRA - I think the text should recommend (SHOULD) completeRA for multicast messages. LNOLO is useful mostly when completeRA is not possible becos of MTU/bandwidth restrictions.

thanks,
Sathya

PS: Brett - the issues I am not responding to, please assume I don't have a strong opinion about them and I defer to the group/you to make the decision. Is that alright? 

Brett

Sathya Narayanan wrote:

> Brett Pentland wrote:
>
>> There has been discussion lately about aggregating responses in
>> multicast RAs. The draft mentions sending RAs multicast for aggregation
>> of responses but doesn't specify how this is done - specifically, it
>> makes no mention of including multiple LNOLOs.
>>
>> It may, due to MTU constraints, not be possible to include all the
>> necessary LNOLOs (as it also may not be possible to fit a completeRA
>> within the MTU).
>
>
>
> There is a subtle difference in these two cases: with the compeleRA scenario, if you can not do it due to MTU restriction, the host MUST depend on its CPL to infer landmark not on link, when it receives a multicast RA. While with LNOLO's even if you cannot include all the necessary LNOLOs, the ones you include gives a specific answer to atleast those landmark questions.


Multicast is already just being used to handle overflow and non-DNA
hosts so it's a limited set.  The cases not handled by CompleteRA is
only a subset of those special cases.  I don't think it's worth
the complexity to add this.

Not having a completeRA doesn't have to mean that a decision can't
be made just based on that one RA either.  If a host does receive an
incomplete multicast RA that has a disjoint set of prefixes from it's
current list, then unless there is a need to be really conservative
about not inferring movement, it seems pretty reasonable to just infer
movement and form a new address etc.  The only cases where this will be
incorrect will be where the entire list of prefixes the host has stored
from the link don't match any of the prefixes that did make it into the
RA.  The penalty is that a new address/router gets used, but that should
settle pretty quickly anyway.

>
> PS: Brett - the issues I am not responding to, please assume I don't have a strong opinion about them and I defer to the group/you to make the decision. Is that alright?


That's fine.
Brett. 

Tero

>Brett,
>> 
>> I think that RAs which are multicast in res;ponse to a depletion of

unicast

>> tokens should contain exactly the same information as the RAs that are
>> multicast as beacons on the link. So, I'd say that they should be

CompleteRA

>> or CPL, but not contain LNOLOs or any specific responses to RSs

received.

>> Makes things simpler.


The more I think about this, the more I'm starting to lean towards Jak's
opinion. It may sound like a lucrative choice to aggregate responses but
I'm getting the feeling that it can get complicated. Complication will
make the specification be more open to various interpretations.

Tero

Brett

Resolution here too?

Brett Pentland wrote:

> There has been discussion lately about aggregating responses in
> multicast RAs. The draft mentions sending RAs multicast for aggregation
> of responses but doesn't specify how this is done - specifically, it
> makes no mention of including multiple LNOLOs.
>
> It may, due to MTU constraints, not be possible to include all the
> necessary LNOLOs (as it also may not be possible to fit a completeRA
> within the MTU).
>
> Given this, is it worth having LNOLOs in multicast RAs at all?
> I think the reason for them was to cover cases where it was not
> possible to fit a completeRA, but they seem to have the same
> limitation.
>
> In solicited multicast RAs:
>    - Should there be LNOLOs if applicable?


No.

>    - If yes, should there be multiple LNOLOs if applicable?
>    - If yes, and there is not space for both CompleteRA and
>      applicable LNOLOs, which should take preference?


Furthermore, the content of solicited multicast RAs should be the
same as unsolicited multicast RAs and should include all PIOs as
well as all learned prefixes in a DNAO, if possible. 

-- Main.BrettPentland - 18 Apr 2005

Back to DNA Issue Tracker Base Page