[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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) 
                                                       ^
********************************************************************** * 






stiemerling@netlab.nec.de
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014