[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: comments about draft-ietf-6man-dad-proxy-02
From:       Jean-Michel Combes <jeanmichel.combes () gmail ! com>
Date:       2012-04-24 15:35:39
Message-ID: CAA7e52q_Bnth7cZU5=TQ3CRZmoEOwYeZOpo3xvk=ntdQsS74fA () mail ! gmail ! com
[Download RAW message or body]

Hi Tassos,

at first, sorry for the delayed reply and thanks for your comments.

2012/3/27 Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>:
> Some questions/comments about this draft:
>
> 1) I think it should be better to provide an alternative terminology in
> order to better describe the topology, like hub and spokes or root and
> leaf(s).

This draft tackles an issue that exists on access architectures
defined by the Broadband Forum. The Broadband Forum uses the term
"split horizon" and it is important to re-use this term in order to
make an easy correlation with the Broadband Forum's scenarios. This
term is fully defined in the draft. Besides, Hub and spoke or
root/leafs do not help in understanding that DAD-NS are not forwarded
to other CPEs. That's why BBF terminology is re-used (since it is a
BBF architectural problem to be solved by IETF).

> 2) IPv6 over PPP is not affected and should probably be mentioned.

Agreed. In the next version of this document, a sentence will be added
in the introduction.

>
> 3) =A0Under 4.2.2, i believe there is a mixup of CPE states.
> i.e. according to the following, CPE1 has already a cache entry
>
> The BNG then has to
> =A0 verify whether there is a real conflict by checking if the CPE whose
> =A0 IPv6 address is in the entry is still connected. =A0In the following,
> =A0 we will call IPv6-CPE1 the IPv6 address of the existing entry, Link-
> =A0 layer-CPE1 the Link-layer address of that entry and Link-layer-CPE2
> =A0 the Link-layer address of the CPE which is performing DAD, which is
> =A0 different from Link-layer-CPE1.
>
> but then, the following paragraphs talk about different CPE1 cache states.
>
> If IPv6-CPE1 is in the Neighbor Cache, but it is associated with
> =A0 =A0 =A0another Link-layer address than Link-layer-CPE1...
>
> If IPv6-CPE1 is not in the Neighbor Cache...
>
> The last one surely contradicts the "we will call IPv6-CPE1 the IPv6 addr=
ess
> of the existing entry" statement.
> It also seems a little bit confusing to me.
>
>

There is not contradiction because the initial definition (cf. "we
will call IPv6-CPE1 the IPv6 address of the existing entry") refers to
the entry in the Binding Table defined in section 4.1. The 2
paragraphs "If IPv6-CPE is (not) in the Neighbor Cache" refers to the
Neighbor Cache, which is (or might be) another table. However, it is
acknowledged that clarification is required in order to avoid the
confusion. In the next version of this document, a sentence will be
added in section 4.1.

>
> 4)
>
> If IPv6-CPE1 is in the Neighbor Cache, but it is associated with
> =A0 =A0 =A0another Link-layer address than Link-layer-CPE1, that means th=
at
> =A0 =A0 =A0there is possibly a conflict with another CPE, but that CPE did
> =A0 =A0 =A0not perform DAD. =A0This situation is out of the scope of this
> =A0 =A0 =A0document, since one assumption made above is that all the node=
s of
> =A0 =A0 =A0a point-to-multipoint domain (except the DAD proxy itself) per=
form
> =A0 =A0 =A0DAD. =A0This case could be covered in the future by additional
> =A0 =A0 =A0solutions that work in conjunction with the DAD proxy.
>
>
>
> Would it be an intermediate solution to delete all "possibly wrong" entri=
es
> and/or log an error message?

Maybe but, if we say that this scenario (not all nodes perform DAD) is
in the scope of this draft, there are probably many other things to
consider. So IMHO this scenario deserves another draft. The easy
solutions like deleting all "possibly wrong" entries might have side
effects if not studied in details.


Thanks again for your comments/questions.

Best regards.

JMC, on behalf of the authors.

>
>
>
> --
> Tassos
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]