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

From: "Peter Tam" <[email-masked]>
Date: Mon, 26 Jun 2000 12:47:06 -0500

Bob:

This is the 1st time I read this draft. Apology if the following have been
discussed before:

1.	Must the Target Address List option in the Inverse Neighbor
Discovery Advertisement (InvNDA) message not contain unicast IPv6 addresses
only? I think it must. Then it will affect section 4.3.2 on the validation
procedures. 
2.	Should it not also support unsolicited InvNDA, when 1 or more of an
inteface's IP addresses have been changed? It should, and should also
enforce to re-advertise all the addresses on that interface. Otherwise, it
is not possible to cover the scenario where an IP address on the interface
was deleted. 
3.	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.
4.	Why is there a preference of FR to ATM in Appendix A? Should also
include the case for ATM as a link-layer technology.

Regards... Peter Tam, 
Nortel Networks, Ottawa

	-----Original Message-----
	From:	Bob Hinden [SMTP:[email-masked]]
	Sent:	Thursday, June 22, 2000 4:27 PM
	To:	[email-masked]
	Subject:	W.G. Last Call on "Extensions to IPv6 Neighbor
Discovery for Inverse  Discovery Specification"

	This is a IPng working group last call for comments on advancing the

	following document as a Proposed Standard:

		Title		: Extensions to IPv6 Neighbor Discovery for
Inverse
	                          Discovery Specification
		Author(s)	: A. Conta
		Filename	: draft-ietf-ion-ipv6-ind-03.txt
		Pages		: 22
		Date		: 27-Oct-99

	Please send substantive comments to the ipng mailing list, and minor
	editorial comments to the author.  This last call period will end
two
	week from today on July 6, 2000.

	Bob Hinden / Steve Deering

	--------------------------------------------------------------------
	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: Thu, 29 Jun 2000 11:13:26 -0400

Peter,

Thank you for your comments, which are important for the improving of
this specification.
For the first comment, I need more clarification, but it is probably
better if I take the comments and answer them one by one, so please see
bellow:

Peter Tam wrote:

>
>
> Bob:
>
> This is the 1st time I read this draft. Apology if the following have
> been discussed before:
>
>      Discovery Advertisement (InvNDA) message not contain unicast IPv6
>      addresses only? I think it must. Then it will affect section
>      4.3.2 on the validation procedures.
>

Would you please elaborate?

>   1. Should it not also support unsolicited InvNDA, when 1 or more of
>      an inteface's IP addresses have been changed? It should, and
>      should also enforce to re-advertise all the addresses on that
>      interface. Otherwise, it is not possible to cover the scenario
>      where an IP address on the interface was deleted.
>
The motivations to the present text in the specification were the
following:

1. Minimizing and possibly eliminating unsolicited messages is a good
thing.

2. The scenario in which one or more new IPv6 address are added to an
existent VC can be solved by having the node adding such addresses send
IND Solicitation(s).

3. The scenario in which one ore more IPv6 addresses associated with a
VC are deleted while the VC and DLCI remain was envisaged to happen
seldom - more often, the VC and DLCI would be torn down as well   - and
be resolved through the IPv6 address deprecation.

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

>   1. Why is there a preference of FR to ATM in Appendix A? Should also

As said previously, the appendix contains just one example, to
illustrate simply and briefly the use of the protocol. Although it is
mentioned that it may apply to other link technologies, it was not
intended to cover more or all possible link technologies.

> Nortel Networks, Ottawa

Thank you,
Alex Conta
Transwitch Corporation, Shelton, CT

>              Title           : Extensions to IPv6 Neighbor Discovery
>      for Inverse
>                                Discovery Specification
>              Author(s)       : A. Conta
>      -------------------------------------------------------------------
>
>      -------------------------------------------------------------------
>