Re: [MEXT] Protocol Action: 'Traffic Selectors for Flow Bindings' toProposed Standard

[<[e-mail]>]

Dear all,
Sorry for late reaction - but I think I have detected another nit in the not yet RFC draft-ietf-mext-binary-ts-04 on binary TS (which BTW is going to expire today ;-) ).

As quoted below it (still) says in Section 3.2:
	According to [RFC2460] the flow label is 24-bit long.  For the
      purpose of this specification the sender of this option MUST
      prefix the flow label value with 8-bits of "0" before inserting it
      in this field.  The receiver SHOULD ignore the first 8-bits of
      this field.

When checking in RFC2460 however I find in Sections 3 and 6: 
  Flow Label           20-bit flow label.
and
  The 20-bit Flow Label field in the IPv6 header ...

The explanation is found in the section CHANGES SINCE RFC-1883, which mentions the
 ... reduction of size of Flow Label field from 24 bits to 20 bits.

So IMHO in Section 3.2 of draft-ietf-mext-binary-ts-04.txt it should read

	According to [RFC2460] the flow label is 20-bit long.  For the
      purpose of this specification the sender of this option MUST
      prefix the flow label value with 12-bits of "0" before inserting it
      in this field.  The receiver SHOULD ignore the first 12-bits of
      this field.

... since I think we won't refer to obsolete RFC 1883, right?

Sorry for disturbing in case I have misunderstood something!

;-) 
Best regards
Dirk 

Von: [e-mail] [mailto:[e-mail]] Im Auftrag von The IESG
Gesendet: Montag, 15. März 2010 17:33
An: IETF-Announce
Cc: mext mailing list; Internet Architecture Board; mext chair; RFC Editor
Betreff: [MEXT] Protocol Action: 'Traffic Selectors for Flow Bindings' toProposed Standard

The IESG has approved the following document:

- 'Traffic Selectors for Flow Bindings '
   <> as a Proposed Standard


This document is the product of the Mobility EXTensions for IPv6 Working Group. 

The IESG contact persons are Jari Arkko and Ralph Droms.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-04.txt

Technical Summary

  This document defines binary formats for IPv4 and IPv6 traffic
  selectors to be used in conjunction with flow bindings for Mobile
  IPv6.

Working Group Summary

  The document has been discussed in depth in the WG.
  The WG feels that this is an important document
  and should be published.

  The main controversy was whether there should be one or more
  traffic selector format defined. This is one format. There
  is no objection to this format, but rather some people ask for
  an additional format. Chairs do not see that as a stopper for this 
  document but it is a related issue that as worth mentioning.

Document Quality

  There is at least on ongoing effort for implementing this
  specification.

  There were many reviewers of the document, but especial
  in depth reviews were provided by Dave Craig, Benjamin Lim,
  Patrick Stupar, and Basavaraj Patil

  No MIB review nor media type reviews were needed.

Personnel

  The document shepherd is Marcelo Bagnulo
  Responsible INT AD is Jari Arkko

RFC Editor Note

OLD:
(K)Start DS - Differential Services

      This field identifies the first differential services value, from
      the range of differential services values to be matched, on data
      packets sent from a corresponding node to the mobile node as seen
      by the home agent.  Note that this field is called Type of Service
      field in [RFC0791].  [RFC3260] then clarified that the field has
      been redefined as 6 bits DS field and 2 bits reserved, later
      claimed by Explicit Congestion Notification (ECN) [RFC3168].  For
      the purpose of this specification the DS field is 8 bits long,
      were the 6 most significant bits indicating the DS field to be
      matched and the 2 least significant bits MUST be set to 0 by the
      sender and ignored by the receiver.

NEW: 

(K)Start DS - Differential Services

      This field identifies the first differential services value, from
      the range of differential services values to be matched, on data
      packets sent from a corresponding node to the mobile node as seen
      by the home agent.  Note that this field is called Type of Service
      field in [RFC0791].  [RFC3260] then clarified that the field has
      been redefined as 6 bits DS field and 2 bits reserved, later
      claimed by Explicit Congestion Notification (ECN) [RFC3168].  For
      the purpose of this specification the (K)Start DS field is 8 bits 
      long, were the 6 most significant bits indicating the DS field to 
      be matched and the 2 least significant bit's value MUST be ignored 
      in any comparision. 

And change this in Section 3.2:
OLD:
   (G)Start Flow Label

      This field identifies the first flow label value, from the range
      of flow label values to be matched, on data packets sent from a
      corresponding node to the mobile node as seen by the home agent.
      According to [RFC2460] the flow label is 24-bit long.  For the
      purpose of this specification the sender of this option MUST
      prefix the flow label value with 8-bits of "0" before inserting it
      in this field.  The receiver SHOULD ignore the first 8-bits of
      this field.

   (H)End Flow Label

      If more than one contiguous flow label values need to be matched
      then this field can be used to indicate the end value of a range
      starting from the value of the Start Flow Label field.  This field
      MUST NOT be included unless the Start Flow Label field is
      included.  When this field is included the receiver will match all
      of the flow label values between fields (G) and (H), inclusive of
      (G) and (H).
      

NEW:
   (G)Start Flow Label

      This field identifies the first flow label value, from the range
      of flow label values to be matched, on data packets sent from a
      corresponding node to the mobile node as seen by the home agent.
      According to [RFC2460] the flow label is 24-bit long.  For the
      purpose of this specification the sender of this option MUST
      prefix the flow label value with 8-bits of "0" before inserting it
      in the (G)Start Flow Label field.  The receiver SHOULD ignore the
      first 8-bits of this field before using it comparisons with 
      flow labels in packets.

   (H)End Flow Label

      If more than one contiguous flow label values need to be matched
      then this field can be used to indicate the end value of a range
      starting from the value of the Start Flow Label field.  This field
      MUST NOT be included unless the Start Flow Label field is
      included.  When this field is included the receiver will match all
      of the flow label values between fields (G) and (H), inclusive of
      (G) and (H). When this field
      is included, it MUST be coded the same way as defined for (G).

And this in Section 3.2:
OLD:

    (M)Start TC - Traffic Class

      This field identifies the first traffic class value, from the
      range of traffic class values to be matched, on data packets sent
      from a corresponding node to the mobile node as seen by the home
      agent.  This field is equivalent to the Start DS field in the IPv4
      traffic selector in Figure 1.  As per [RFC3260], the field is
      defined as 6 bits DS field and 2 bits reserved, later claimed by
      Explicit Congestion Notification (ECN) [RFC3168].  For the purpose
      of this specification the TC field is 8 bits long, were the 6 most
      significant bits indicating the DS field to be matched and the 2
      least significant bits MUST be set to 0 by the sender and ignored
      by the receiver.

NEW:

    (M)Start TC - Traffic Class

      This field identifies the first traffic class value, from the
      range of traffic class values to be matched, on data packets sent
      from a corresponding node to the mobile node as seen by the home
      agent.  This field is equivalent to the Start DS field in the IPv4
      traffic selector in Figure 1.  As per [RFC3260], the field is
      defined as 6 bits DS field and 2 bits reserved, later claimed by
      Explicit Congestion Notification (ECN) [RFC3168].  For the purpose
      of this specification the (M)Start TC field is 8 bits long, where 
      the 6 most significant bits indicating the DS field to be matched 
      and the 2 least significant bit's value MUST be ignored in any 
      comparison.

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext