Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-03.txt

[Wolfram Stering <wolfi@cosy.sbg.ac.at>]

Gorry Fairhurst wrote:
> This note starts the WG two week Last-Call for comments for the WG document
> named below:
>
> draft-ietf-ipdvb-ule-03.txt
>
> The Last-Call will end on 15/12/2004.

Following Gorry's call, please find below some comments:

As implementors of draft-ietf-ipdvb-ule-03.txt, we discovered some issues
that will be elaborated in the following paragraphs:

1. Section 5, related to fig. 10:
The text says: "a 5-bit zero prefix and a 3-bit H-Len field", but the figure
shows 4 bits zero and thus suggests 4 bit for H-Len.

2. Section 4.4.1, "Next Header Type Fields":
When considering extension headers, type field values of 0x0000 (TEST SNDU),
0x0001 (BRIDGED SNDU), and 0x0100 (PADDING) are to be interpreted as
mandatory extension headers.  We propose to describe these in section 5
and state in 4.4.1 that type field values less than 1536 denote extension
headers.

3. PADDING type: 0x0100 would decode as a 2 bytes long optional extension
header, which is obviously not as intended.

4. Section 4.5, "SNDU Destination Address Field":
If extension headers are used in combination with SNDU destination address
(i.e. D-Bit is zero), it is not clear, where exactly the NPA address has to
be placed, i.e. after which type field: after the last extension header or
after the SNDU header (thus occupying bytes 5 to 10 of the SNDU).  For
ease of processing and filtering, we propose to have the NPA address'
position fixed, directly following the 4-bytes SNDU header.  An STB would
have to decode all extension headers to find the NPA address, just to
discover that it has to be dropped, if it doesn't match its own MAC address.

5. Bridged SNDUs:
There is an inconsistency with respect to bridged SNDUs.  As a bridged
SNDU is declared as a mandatory extension header (H-Len = 0, H-Type = 1,
see above), it could principally be chained with other extension headers.
However, in the current version this is not possible as no other
type field (next level header) can follow a bridged header (the bridged
frame follows).

6. Bridging VLAN frames:
There is a note in section 4.7.5, after figure 9, stating that a
bridged SNDU could convey an 802.3 Ethernet frame (as opposed to
the examples (fig. 8, fig. 9) containing an LLC/SNAP encapsulation.
This note should be extended to also cover 802.1q frames (VLAN),
which contain a 4-byte VLAN tag after the 2 Ethernet MAC addresses.

We hope to contribute to a bullet-proof standard.
best regards,

Hilmar Linder
Wolfram Stering


--
Wolfram Stering,                 <wolfi@cosy.sbg.ac.at>
Department of Scientific Computing, Salzburg University
Tel: +43 (0)662 8044 6334      Fax: +43 (0)662 8044 172

     "If we knew what it was we were doing
      it would not be called research, would it?"