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

From: "Peter Tam" <[email-masked]>
Date: Tue, 11 Jul 2000 18:45:51 -0400

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

---

From: Alex Conta <[email-masked]>
Date: Wed, 12 Jul 2000 09:53:51 -0400

Peter,

Thank you again for your feedback.

Alex

Peter Tam wrote:

>      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
>      >      can contain only unicast addresses.If unicast-only
>      addresses are
>      >      discard IND messages containing multicast addresses, so
>      that they
>      >      >   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
>      >      the use of the protocol. Some particular details of the
>      link in
>      >      the
>      >      >> Out-of/in scope is an artificial line. In this case,
>      all it
>      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
>      this is a way to not extend the scope beyond what was intended,
>      and also
>      -------------------------------------------------------------------
>
>      -------------------------------------------------------------------
>

---

From: Alex Conta <[email-masked]>
Date: Wed, 12 Jul 2000 09:53:51 -0400

Peter,

Alex