Subject: draft-ietf-ipdvb-ar - REVISED TEXT for consideration & comments

From: Martin Stiemerling <[email-masked]>
Date: Wed, 21 Mar 2007 13:34:43 +0100

Hi all,

The authors of draft-ietf-ipdvb-ar ask for comments on the proposed  
text, as said below.

Please provide your comments until

**Thursday, March 22, 2007**

which is tomorrow. Send your comments to the ipdvb mailing list.

Thanks,
   Martin

A set of DISCUSS issues were raised by the IESG during review of the  
above
document. As described in the IPDVB WG, this includes 4 outstanding  
issues
to be addressed prior to publication.

The current list of implemented changes are specified in the change  
list of:
http://tools.ietf.org/html/draft-ietf-ipdvb-ar-06

A URL (shown in the meeting) to the difference file is:
http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/draft-ietf-ipdvb- 
ar-06-fr
om-05.diff.html

PLEASE *DO* review these corrections and send an email if you see  
anything
that could be wrong or missing in the -06 draft or the proposed text  
below.

We'd like to close these issues by Thursday (please),

Best wishes,

Gorry & Marie-Jose
(as Editors)

---

1) ISSUE:

>
> The abstract and introduction should be very
> clear that this document is only a survey
> of existing mechanisms, NOT a specification
> of how to do address resolution over DVB.
> This is reflected in the charter, but its
> not very clear in the document itself.
>

PROPOSAL:

> ********************************************************************** 
> *
>
> Insert the following new paragraph at the start of the Introduction  
> (from the
>
abstract), before all others.

>
> AFTER:
>   1. Introduction
> NEW:
>    This document describes the process of binding/associating IPv4/ 
> IPv6
>    addresses with MPEG-2 Transport Streams (TS). This procedure is
>    known as Address Resolution (AR), or Neighbour Discovery (ND). Such
>    address resolution complements the higher layer resource discovery
>    tools that are used to advertise IP sessions. The document
>    reviews current methods appropriate to a range of technologies  
> (DVB,
>    ATSC, DOCSIS, and variants). It also describes the interaction with
>    well-known protocols for address management including DHCP, ARP,  
> and
>    the ND protocol.
>
> ********************************************************************** 
> *
> OLD:
>    The MPEG-2 Transport Stream (TS) provides a
> NEW:
>    The MPEG-2 TS provides a
> ********************************************************************** 
> *
> OLD:
>    used. This document calls this mapping an Address Resolution (AR)
>
> NEW:
>    used. This document calls this mapping an AR
> ********************************************************************** 
> *
>

2) ISSUE:

>
> +-------------------------------+--------+----------------------+
> |                              | PDU    |L2 Frame Header Fields|
> | L2 Encapsulation              |overhead+----------------------+
> |                              |[bytes] |src mac|dst mac| type |
> +-------------------------------+--------+-------+-------+------+
> |6.1 ULE without dst MAC address| 8      |  -  |  -    | x    |
> |6.2 ULE with dst MAC address  | 14    |  -  |  x    | x    |
> |6.3 MPE without LLC/SNAP      | 16    |  -  |  x    | -    |
> |6.4 MPE with LLC/SNAP          | 24    |  -  |  x    | x    |
> |6.5 ULE with Bridging extension| 22    |  x  |  x    | x    |
> |6.6 ULE with Bridging & NPA    | 28    |  x  |  x    | x    |
> |6.7 MPE+LLC/SNAP+Bridging      | 38    |  x  |  x    | x    |
> +-------------------------------+--------+-------+-------+------+
>
> Considerations from draft-iab-link-encaps-05 apply.
> The use of different address resolution mechanisms
> adds new issues. The draft should make it clear
> what the interoperability implications of this
> situation are, and, hopefully, talk about how
> the involved nodes can determine what to do.
>
>
>> There is text on this. However, the essential advice appears to be
>> "An Encapsulator must therefore use only one method e.g. ULE or
>> MPE) to support a single IP network". This seems rather simplistic.
>> What if the hosts on the network support the other AR methods
>> only? Note that this is not merely about different encapsulation,
>> but about interoperability in a situation where there are multiple
>> different protocol mechanisms to achieve something.
>>

PROPOSAL:

> ********************************************************************** 
> *
> Section 6, Pqra 2. Final Sentence.
> DELETE:
>    In this way,
>    all Receivers belonging to a network will Receive the same set of
>    multicast/broadcast messages.
>
> INSERT new paragraphs after this deleted text:
>
>   All Receivers in an IP network must receive all IP packets that use
>   a broadcast (directed to all systems in the IP network) or
>   local-scope multicast (section 3) address. Packets with these
>   addresses are
>   used by many IP-based protocols including service discovery, IP AR,
>   routing protocols. Systems that fail to receive these packets can
>   suffer connectivity failure or incorrect behaviour (e.g. may be  
> unable to
>   participate in IP-based discovery, configuration, routing, and
>   announcement protocols).
>
>   Consistent delivery can be ensured by transmitting link-local  
> multicast
>   or broadcast packets using the same Stream that is used for unicast
>   packets directed to this network.
>
>   A Receiver could simultaneously use more than one L2 AR mechanism.
>   This presents a potential conflict when the Receiver receives two
>   different bindings for the same identifier. When multiple systems
>   advertise AR bindings for the same identifiers (e.g. Encapsulators),
>   these must therefore ensure advertised information is consistent.
>   Conflicts may also arise when L2 protocols duplicate the
>   functions of IP-based AR mechanisms.
>
> ********************************************************************** 
> *
>

3) ISSUE:

>
> 5.5 DHCP Tuning
>
> This section does not talk about what happens
> to DHCP when the link is not bidirectional.
>
>
>> I do not see a change here.
>>
>>
> - DHCP is only over the subset with bi-directional connectivity.
>
>
PROPOSAL:

> ********************************************************************** 
> *
> Section 5.5
> OLD:
> / may be used over MPEG-2 Networks./
> REPLACE BY:
> / may be used over MPEG-2 Networks with bi-directional connectivity./
> ********************************************************************** 
> *
>

4) ISSUE:

>
> This document has reviewed the status of these
> current address resolution mechanisms in MPEG-2
> transmission networks and defined their usage.
>
> It is fine to review existing mechanisms. But
> I am concerned that this document does not
> really in detail "define usage". I'm not
> sure I could implement anything based on this,
> though it is possible that the references
> provide additional information.
>
>>
>> I cannot find a change here.
>>
>>
> - Rationale this document does not really describe how to tune ND, or
> provide a new mechanism, that was charted as a separate PS. This is  
> clear
> that this is not the goal of this document.
>

PROPOSAL:

> ********************************************************************** 
> *
> Abstract - remove final clause of last sentence.
> OLD:
>    It also describes the interaction with
>    well-known protocols for address management including DHCP, ARP,  
> and
>    the ND protocol, and provides guidance on usage
> NEW:
>    It also describes the interaction with
>    well-known protocols for address management including DHCP, ARP,  
> and
>    the ND protocol.
> ********************************************************************** 
> *
>

KNOWN CORRECTIONS:

> **********************************************************************
> Section 6 - add open bracket
> OLD text:
>     An Encapsulator must therefore use only one method e.g. ULE or  
> MPE)
> NEW, Add a bracket to this:
>     An Encapsulator must therefore use only one method (e.g. ULE or  
> MPE)
>                                                        ^
> ********************************************************************** 
> *
>

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014