Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"

From: "Peter Tam" <[email-masked]>
Date: Fri, 16 Feb 2001 18:02:13 -0800

Alex:

I can live with your clarifications. Thanks ...Peter

   -----Original Message-----
   From:   Alex Conta [SMTP:[email-masked]]
   Sent:   Monday, July 10, 2000 6:43 PM
   To:     Tam, Peter [NORSE:6L73:EXCH]
   Cc:     [email-masked]
   Subject:        Re: W.G. Last Call on "Extensions to IPv6 Neighbor
   Discovery for  Inverse Discovery Specification"

   Peter,

   Thanks for a more detailed list of comments. Your reviewing is going to
   be acknowledged in the I-D.

   As I am preparing the text for a new version of the draft,  my thoughts
   related to your comments are:

   Regarding your first suggestion, whose ramifications I understand now
   better than before:

   >      >...
   >
   >      >> Currently, the draft does not restrict the types of addresses
   >      within the Source/Target Address Lists in the IND
   >      Solicitation/Advertisement messages. Thus, it implies that both
   >      unicast and multicast addresses are legitimate. This address
   >      information is used to build the Neighbor cache, which I believe
   >      can contain only unicast addresses.If unicast-only addresses are
   >      imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should
   >      discard IND messages containing multicast addresses, so that they
   >      will not be entered into the cache. After all, resolution should
   >      be between link layer addresses and unicast network addresses.
   >

   the text in the current draft is aligned with the original intentions in
   specifying the protocol:

     - do not make strong implementation requirements

        the I-D specifies that  the Neighbor Discovery Cache MAY be
        populated with address information acquired via IND.  Which is
        to say strongly that the Protocol for populating the ND cache
        is and remains ND.

     - allow a certain level of generality and flexibility to the address
   discovery mechanism, which may be useful for the type of links to which
   the protocol applies.

         for links that do not have an algorithmic mapping of  IP
        multicast addresses into link addresses, there is - I think -
        a need for storing/caching the address information used in
        resolution. What is, or how  the place for storing multicast
        address information is called, is an implementation issue.  A
        mechanism to convey the information used in resolution is also
        useful . In saying this, as I did in the I-D,  I am trying to
        stay away though from making implementation suggestions.

   As I still do not see any particular bad side effects, I think the
   original goals as followed by the text are worth maintaining,  In that
   sense,  I think,  RFC 2390 sets also an example.

   >      >....
   >
   >      >   1. Appendix A: Frame Relay (FR) as a link-layer address. But
   >      it
   >      >      should have a note up front that the DLCI applies to the
   >      member
   >      >      DLCI in the case of a Multi-link Frame Relay.
   >      >
   >
   >      The appendix was intended to contain one simple example to
   >      illustrate
   >      the use of the protocol. Some particular details of the link in
   >      the
   >      example were considered out of scope.
   >      >> Out-of/in scope is an artificial line. In this case, all it
   >      takes is only 1 line of clarification.
   >

   Let me rephrase my thoughts on this:

   the example in Appendix A is not a Multi-link Frame Relay example, and
   Multi-link Frame Relay is not mentioned at all. If Multi-link would have
   been mentioned, in one way or another, then I could have better seen a
   reason for confusion, and a need for clarification, but without that,
   this is a way to not extend the scope beyond what was intended, and also
   minimize the number of words or sentences.

   Thanks again for your input.
   and regards,
   Alex

   --------------------------------------------------------------------
   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-masked]
   --------------------------------------------------------------------

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------