The draft currently says that when responding "yes" to a landmark option in a unicast RA, that the requested prefix is included but that other PIOs SHOULD NOT be included. Sathya suggested that this should be relaxed. I don't think it should. Any other opinions?
I agree that the other PIOs should not be included.
jak
I hate to ask this, but what was the motivation to include PIOs? What would the host do with the extra information? If there is no clear benefit just that it might be good to include other PIOs in the response, I agree that PIOs should not be included. -- Tero >> -----Original Message----- >> From: owner-dna-dt@ecselists.eng.monash.edu.au [mailto:owner-dna- >> dt@ecselists.eng.monash.edu.au] On Behalf Of James Kempf >> Sent: 18. huhtikuuta 2005 20:34 >> To: Brett Pentland; dna-dt@eng.monash.edu.au >> Subject: Re: [DNA-DT] Solution1, Issue 5: Extra PIOs in a "yes" unicast >> >> I agree that the other PIOs should not be included. >> >> jak >> >> ----- Original Message ----- >> From: "Brett Pentland" <brett.pentland@eng.monash.edu.au> >> To: <dna-dt@eng.monash.edu.au> >> Sent: Monday, April 18, 2005 12:44 AM >> Subject: [DNA-DT] Solution1, Issue 5: Extra PIOs in a "yes" unicast >> >> > >>> > The draft currently says that when responding "yes" to a landmark >>> > option in a unicast RA, that the requested prefix is included but >>> > that other PIOs SHOULD NOT be included. >>> > >>> > Sathya suggested that this should be relaxed. I don't think it >>> > should. Any other opinions?
Brett, Tero - >> I hate to ask this, but what was the motivation to include PIOs? What >> would the host do with the extra information? >> If there is no clear benefit just that it might be good to include >> otherPIOs in the response, I agree that PIOs should not be included. While responding to one of the email on multicast RA discussion, I just realized there is one benefit in adding others PIOs in the response - for the host to be able to create a CPL. (Even though its possible the host would have learned about other prefixes earlier.) I am not recommending that router MUST include other PIOs. But, it may not be prudent to restrict it either. Just thought will bring this point up - I don't have a strong position on this one. thanks, Sathya
Resolution here, it seems. Brett Pentland wrote: > The draft currently says that when responding "yes" to a landmark > option in a unicast RA, that the requested prefix is included but > that other PIOs SHOULD NOT be included. > > Sathya suggested that this should be relaxed. I don't think it > should. Any other opinions? No additional PIOs. There also seems to be support and no negatives for the idea of using an LO with or without a NAck bit set (as appropriate) to answer the question posed in the RS, and thus that LO (without the NAck flag set) would be sent in place of the requested PIO in a "yes" answer. Brett.
Hi Sathya, >> While responding to one of the email on multicast RA discussion, I just >> realized there is one benefit in adding others PIOs in the response - for the >> host to be able to create a CPL. (Even though its possible the host would have >> learned about other prefixes earlier.) Ok, I see your point. I'm just wondering that if DNA enabled messages (the DNA flag is set) are also used for the purposes of creating a CPL it surely helps in constructing the prefix list, but makes the protocol to sound a little bit complicated due to the fact that some of the information comes from the DNA process and some via its own mechanisms (I'm referring to the "DNA with unmodified routers: Prefix list based approach" as its own process). Just wondering... >> I am not recommending that router MUST include other PIOs. I understood that. Regz, Tero
Brett Pentland wrote: > Resolution here, it seems. > > Brett Pentland wrote: > >> The draft currently says that when responding "yes" to a landmark >> option in a unicast RA, that the requested prefix is included but >> that other PIOs SHOULD NOT be included. >> >> Sathya suggested that this should be relaxed. I don't think it >> should. Any other opinions? > > > > No additional PIOs. yes > There also seems to be support and no negatives for the idea of using > an LO with or without a NAck bit set (as appropriate) to answer the > question posed in the RS, and thus that LO (without the NAck flag set) > would be sent in place of the requested PIO in a "yes" answer. This is a tiny detail but ... I don't know if it makes sense to define a "yes" and a "no" bit in the LO, and have the value of those be undefined for the RS, but that the RA MUST have either a yes or a no bit? (Feels a bit more symmetrical than the RS looking like it carries as "yes".) Erik
Erik Nordmark wrote: > Brett Pentland wrote: > >> Resolution here, it seems. >> >> Brett Pentland wrote: >> >>> The draft currently says that when responding "yes" to a landmark >>> option in a unicast RA, that the requested prefix is included but >>> that other PIOs SHOULD NOT be included. >>> >>> Sathya suggested that this should be relaxed. I don't think it >>> should. Any other opinions? >> >> >> >> >> No additional PIOs. > > > > yes > >> There also seems to be support and no negatives for the idea of using >> an LO with or without a NAck bit set (as appropriate) to answer the >> question posed in the RS, and thus that LO (without the NAck flag set) >> would be sent in place of the requested PIO in a "yes" answer. > > > > This is a tiny detail but ... > > I don't know if it makes sense to define a "yes" and a "no" bit in the LO, and have the value of those be undefined for the RS, but that the RA MUST have either a yes or a no bit? > (Feels a bit more symmetrical than the RS looking like it carries as "yes".) OK. Fair enough. Should be simple to add - there's plenty of bits to spare. Brett.
| Topic DNASoln1Issue005 . { Edit | Attach | Ref-By | Printable | Diffs | r1.4 | > | r1.3 | > | r1.2 | More } |
|
Revision r1.4 - 22 Apr 2005 - 02:22 GMT - Main.BrettPentland Parents: WebHome > DNASolution1 |
Copyright © 1999-2003 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |