Comments requested to draft-ieft-ipdvb-ar-03

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

The AR draft has been udpated. The authors would like to request 
comments on this version of the draft from the list.

The current I-D is at:
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-03.txt

The differences between this and the previous I-D are at:
http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/draft-ietf-ipdvb-ar-03-from-02.diff.html

To start the process, I am reposting a summary of some of some open 
comments (from a detailed comments to the rev -02 of the AR draft, sent 
by Rupert Goodings), in case you (or anyone else on the list) wish to 
respond and discuss these for the next rev of the document.

Please do send email with anything the authors have missed, or any other
comments!

Best wishes,

Gorry Fairhurst
(as AR I-D co-editor)


---------------
1) AR motivation.
>
>>> > Rupert Goodings wrote:
>>> > more discussion in section 6 (or later) to indicate what AR work 
>>> > is needed -
>>> > i.e. explain why a new AR protocol is (or isn't!) needed.

<snip>

This is not an easy call to make in a general document, two-way 
satellite systems (as you hint) do not currently use IETF-defined 
protocols, and perform AR using other means. On the other hand, we've 
seen presentations at the IETF using ND,ARP over UDLR, and IETF-defined 
protocols are used in DOCSIS, etc.........

What else do you think we should/could say?

It is clearly within the Charter of the WG to define a new protocol, 
should there be demand and a clear requirement, and this should be done 
in the IETF. Is there interest in doing this?

---------------
2)  Bridging case.
>
>>> > Rupert Goodings wrote:
>>> > First some comments on the new introduction.
>>> >
>>> > The bridging case implies a problem...you state:
>>> > "the systems R1, R2 will normally use standard IETF-defined AR
>>> > mechanisms (e.g. ARP [RFC826], ND [RFC2461) edge-to-edge
>>> > across theIP subnetwork."
>>> >
>>> > Now you have already identified that the satellite link
>>> > causes problems for AR.
>> ##rg## I am referring to Para 5 of the intro where you state:
>>"The numbers of Receivers connected via a single MPEG-2 link may be
>>much larger than found in other common LAN technologies, (e.g.
>>Ethernet). This has implications on design/configuration of the address
>>resolution mechanisms."
>>
>> ==>hence it reads oddly to go on to state "OK to use ARP"
>> in the bridged case.
>
<snip>

Some new text added in rev-03, does it address your concerns, or did we 
miss some points?

---------------
2) Multicast AR. PIM, IGMP, ...
>
>>> > Rupert Goodings wrote:
>>> > new/more of the source address aspects (I call this SSM in my
>>> > comments). What I mean here is features to manage groups in
>>> > terms of BOTH S and G not just [*,G] group management.
>>> >
>
>> <snip> Including PIM, IGMP, etc.


What do you suggest we add here, that is important to Address Resolution?

---------------
3)  Multicast AR: Sources
>
>>> > Rupert Goodings wrote:
>>> > Section 3.2.
>>> > General comment is to suggest that this section should
>>> > also discuss SSM aspects
>>##gf##  Do you have somne particular text in mind?
>>##rg## See above.  Section 3.2. only deals with the mapping
>> and filtering ofthe destination IP group address.  I was
>> suggesting that you could also discuss possible source
>> filtering...
<snip>
>> I appreciate that this is may not be applicable
>> here since static RFC1112 mapping applies (?).
>> So my comment may simply be a request
>> to explain better the use (or not) of
>> source addresses in the MMT and INT tables.
<snip>
>>> > - in the above case, extra AR traffic may be OK if it
>>> > saves resources.

Should we add some text on this?

- If I understood, this concerns the RFC1112  mapping of IPv4
addresses to MAC addresses (and the corresponding IPv6 mapping)
which are static. One problem this raises is a lack of
differentiation between two IP multicast flows that map to the same MAC 
address - examples include:

(i) the "address overlap" (sets of IP (G) map to the same MAC),
(ii) a specified G destination address may be used by two different S
sources in SSM, therefore mapping G to a MAC address is not sufficient.
(iii) a local scope (two IP addresses are in different admin scopes and
hence are not the same group, but map to the same MAC - if sent on the 
same interface)

One solution to this, which came up at the mboned WG sometime ago
was to map some addresses to specific OTHER multicast addresses
using a differentmapping function. Such methods have been proposed
in the context of multicast Internet exchanges using L2 switches
to connect routers, where operators need to provide policy-based 
multicast routing between different exchange points and want to
avoid leaking and forwarding traffic that happens to map to the
same MAC address. This requires a multicast AR method to define
the "exceptions" or new mapping associations and inform all
receivers.

Have I understood your point?
What do you think we should say?

>>> > [Later I note that the INT does seem to offer support
>>> > for SSM?]

Yes.

---------------
4)  Additional references

Do you have a citation(s) that you think would be useful to relate this
document (e.g. to work within ETSI concerning AR). Provisional document 
titles may be OK, providing these are finalised by the time the I-D 
reaches the RFC-Editor (probably summer 2006).