Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt

From: Brian Haberman <[email-masked]>
Date: Tue, 24 May 2005 07:40:03 -0400

IPv6 WG,
      This begins a 1-week Working Group Last Call on advancing:

	Title		: Bridge-like Neighbor Discovery Proxies (ND Proxy)
	Author(s)	: D. Thaler, et al.
	Filename	: draft-ietf-ipv6-ndproxy-02.txt
	Pages	: 20
	Date		: 2005-5-23

as an Informational document.  Substantive comments should be
directed to the mailing list.  Minor comments and editorial issues can
be sent to the editor.  This last call will end on June 3, 2005.

We also request that people comment on their support or opposition
to advancing this document.  There has been mixed public support for
this work and it cannot advance without consensus from the working
group.

Regards,
Brian & Bob
IPv6 WG co-chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 May 2005 09:04:09 -0400

I have a process-related concern with draft-ietf-ipv6-ndproxy-02.txt 
that I would like to discuss on this list to see what others think...

I haven't reached the point (yet) where I have a fully-formed 
objection, but I have a strong enough concern that I thought it would 
be worth some discussion before the IPv6 WG sends this document to 
the IESG.  This concern is entirely separate from any technical 
concerns that may arise when I do another full technical review of 
the document.

This document is proposed to address the following charter item:

    - Develop Proxy Neighbor Discovery solution for prefix delegation
      and publish. This enables a simple site border router to
      re-advertise downstream a prefix it hears on its upstream link.

However, it is clear that the document itself -- which proposes a 
multi-link, bridge replacement mechanism using RSTP and IPv6 
encapsulation, goes well beyond what is required to address the 
charter item.  When we agreed to include this charter item (I was an 
IPv6 WG chair at the time), I had expected a substantially 
trimmed-down version of ND Proxy that would only include the "P-bit" 
mechanism for single-step prefix delegation.

Could the current chairs perhaps comment on how they believe that the 
ND Proxy document, as it currently exists, fits within the IPv6 WG 
charter?  Is there anyone else who has an opinion on this?

This is not merely a legalistic concern.  I am concerned that the 
people who should be involved in the standardization an RSTP-based L3 
bridging technology may not be involved in the IPv6 WG.   In fact, 
they may not even be aware that this work is underway here. 
Therefore, this document may not have been developed and reviewed by 
a group that has the balance of experience needed to reach valid IETF 
consensus on this work.

Thoughts?

Margaret

At 7:40 AM -0400 5/24/05, Brian Haberman wrote:
>Content-Type: multipart/signed; micalg=sha1; 
>boundary="=_reb-r561C5807-t4293136D";
>	protocol="application/pkcs7-signature"
>
>IPv6 WG,
>Attachment converted: Macintosh HD:smime 463.p7s (    /    ) (0017E4FA)

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 May 2005 12:02:34 -0700

Margaret Wasserman wrote:

> Could the current chairs perhaps comment on how they believe that the ND 
> Proxy document, as it currently exists, fits within the IPv6 WG 
> This is not merely a legalistic concern.  I am concerned that the people 
> who should be involved in the standardization an RSTP-based L3 bridging 
> technology may not be involved in the IPv6 WG.   In fact, they may not 
> even be aware that this work is underway here. Therefore, this document 
> may not have been developed and reviewed by a group that has the balance 
> of experience needed to reach valid IETF consensus on this work.

FWIW I'm also concerned that the RSTP part of the protocol might not be 
as well understood. I've discovered that at least STP makes assumptions 
about the failure of the underlying "transport", such as the failures 
being visible to the STP. This is satisfied when the "transport" is IEEE 
802.3 etc, because the link layer provides some form of "link test", but 
wouldn't be satisfied when just encapsulating STP in IPv6.

It *might be* that RSTP (IEEE 802.1D-2004 with its addenda and 
corrigenda, and not necessarily the stuff that vendors claim being 
RSTP), does not make that assumption, but before putting out a 
specification that carries IEEE 802.1D-2004 over IPv6, I think we should 
verify this with the experts in IEEE 802.1.

Alternatively, we can go limit the draft to handling the simple cases 
(with the 'P' bit as a way to detect loops and shut them off).

   Erik