Suresh, On 8/19/10 9:43 AM, Suresh Krishnan wrote: > Hi Woj, > > On 10-08-19 09:22 AM, Wojciech Dec wrote: >> There seems to be reason to explain the context/workings more clearly, >> both in terms of multicasting an RA and the overall expected BBF usage. > > The draft describes how the sender of the RA deals with a tunneled RS > with a LIO. No RS received, nothing in the draft is applicable. > Multicasting an unsolicited RA is performed as per RFC4861/RFC4862. This > is not something covered in the draft. I am not sure what you want me to > explain here. As the editor of the BBF spec in question, I would have > thought that you would be more qualified than me to explain the BBF usage.
I think there is some misunderstanding going on here and I believe it may have to do with the lack of detail (and maybe some typos) in the draft. It appears that sections 5 & 6 could be made more clear with a few additions. First, it would be useful to expand all the acronyms in Figure 1 so that there is a clear understanding what the roles are of all the nodes in the diagram. A *short* description of each node's role would be quite useful. Second, it would be useful if the text in sections 5 & 6 referenced the figure so that we know what nodes are originating which messages. For example, section 5.1 talks about receiving an RS from a subscriber, but there is no node in the diagram labeled as the subscriber. Which node sends that RS? Finally, I found the section heading of 6.1 confusing. It references a subscriber, but the text only talks about the access node. One can infer how this works, but it would be better if it was clarified so that we don't have differing views of what is going on. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
