Margaret Wasserman wrote: > >>>(1) I think that this document should explicitly state, in the >>>introduction, that it is not a standard and is not intended to >>>modify or contradict any IPv6 standard documents. I thought that >>>we had agreed to something like this earlier. >>> >>Yes, we had agreed this and we even had the note... until we were told >>that we shouldn't re-state the type of the document in the text. >> > > In this case, the intended audience of the document primarily lies outside of the > IETF. Do you think that they will really understand the difference between our > different document types?
I don't know. I'm happy to put the note back in if you think it is necessary and no one else objects. > It would be much clearer to state that 3GPP nodes must inlcude a full > implementation of ND, including NUD, but that other parts of the 3GPP system > may provide advice to the NUD code which result in supression of NUD messages, > and site the section of the ND specification that indicates how such advice > is used. I think this was the intention. Perhaps we can reformulate the text to be clearer in this respect. I'll send some text off-line to you to make sure you are happy with the reformulation. > Please note that the layers that provide advice to NUD about connectivity > need to be able to ensure two-way IP-level connectivity. If there are no > 3GPP layers that can do that, occasional NUD traffic may result. NUD > only happens when there is traffic to send, and when there has been no > recent confirmation of two-way connectivity (from TCP, for example), so > it is not expected to generate much traffic. Ok. >>But I'm not sure I understand why NUD should be sent when the >>lower layers tell us that the GGSN is down -- the link is then >>down, and nothing gets through. Or did I miss something? >> > > If the link is down, obviously no messages will be sent. But, what if the > link is up, but the GGSN is down? Or what if the GGSN is not forwarding > packets and/or responding at layer 3? In 3GPP, the SGSN keeps track of the status of the GGSN and will inform hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet exchange, so in order for the SGSN to think that the GGSN is up, the GGSN must be responding at layer 3. If the GGSN is up but not forwarding, I believe it would send ICMP errors. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
