Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-01.txt

From: [email-masked]
Date: Fri, 07 Oct 2011 06:29:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Dissemination of Flow Specification Rules for IPv6
	Author(s)       : Robert Raszuk
                          Burjiz Pithawala
                          Danny McPherson
	Filename        : draft-ietf-idr-flow-spec-v6-01.txt
	Pages           : 8
	Date            : 2011-10-07

   Dissemination of Flow Specification Rules [RFC5575] provides a
   protocol extension for propagation of traffic flow information for
   the purpose of rate limiting or filtering.  The [RFC5575] specifies
   those extensions for IPv4 protocol data packets.

   This specification extends the current [RFC5575] and defines changes
   to the original document in order to make it also usable and
   applicable to IPv6 data packets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-01.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Oct 2011 08:09:16 +1300

Hi,

My comments below don't seem to have been addresed.
draft-ietf-6man-flow-3697bis is now in the RFC Editor queue, by the way.

Regards
   Brian Carpenter

-------- Original Message --------
Subject: Re: I-D Action: draft-ietf-idr-flow-spec-v6-00.txt
Date: Wed, 15 Jun 2011 01:54:04 +1200
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: [email-masked]
References: <[email-masked]>

Hi,

I have a couple of concerns about this draft.

>    Type 13 - Flow Label - New type
>
>       Encoding: <type (1 octet), [op, value]+>
>
>       Contains a set of {operator, value} pairs that are used to match
>       the 20-bit Flow Label field [RFC2460].The operator byte is encoded
>       as specified in the component type 3 of [RFC5575].

One point is that RFC 2460 really doesn't specify anything about the flow
label except where it sits in the IPv6 header. The current spec is RFC 3697,
but that is close to being replaced by draft-ietf-6man-flow-3697bis.
However, that describes a stateless model where there is no need for
flow signaling.

So, I have no idea what this new type is good for. If  there is no use case,
why define it? At the very least, there should be a pointer to 3697bis.

>    Traffic Marking: The traffic marking extended community instructs a
>    system to modify the Traffic Class bits of a transiting IPv6 packet
>    to the corresponding value.  This extended community is encoded as a
>    sequence of 5 zero bytes followed by the 8 bit Traffic Class value
>    encoded in the 6th byte.

This breaks ECN. You must only touch the 6 DSCP bits, according to
RFC 2474. (That would also be true for IPv4.) Of course there should be
a reference to RFC 2474 too.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Oct 2011 08:33:44 +1300

Hi Robert,

On 2011-10-09 01:14, Robert Raszuk wrote:
> Hi Brian,
> 
> Thank you for your comments. Indeed I have not received the former email
> ... sending any comment to draft-ietf-idr-flow-spec-v6.all list is very
> unreliable for two reasons ... we all use mail filters and this may not
> made it to idr folder .. 

Well, this is an IETF de facto standard mechanism so I think people's
filter rules should be adapted...

> mail alias expands to email address which may
> have been already obsoleted (job transfer) and most employees at least
> in California do not provide fwd facilities nor mail reject message - it
> just goes to /dev/null.

If the email address is obsolete, that will happen anyway, since the alias
is extracted automatically from the draft and other IETF sources, which
is where I would look for the addresses if entering them manually.

> Now let me address your comments:
> 
> It is there for compliance with base IPv6 RFC. Even if we see no use of
> that today when one extends any protocol it seems worthwhile to be
> prepared to match on any field IPv6 address may carry in the future
> without describing the applications behind it. We are not creating new
> protocol here .. we are just extending flow spec encoding to accommodate
> what IPv6 header authors had in mind.
> 
> However I have no problem in providing the use case example of
> draft-ietf-6man-flow-3697bis if you consider this as useful.

3697bis is not a use case - it is a standards track update of 2460.
I think that adding a normative reference to 3697bis is necessary and
sufficient; since it's already in the RFC Editor queue, it will
be published before your draft anyway.

>>>     Traffic Marking:
>> RFC 2474. (That would also be true for IPv4.) Of course there should
>> be a reference to RFC 2474 too.
> 
> Excellent point- thank you very much for catching it. I have reworded
> this section to the below:
> 
>    system to modify first 6 bits of Traffic Class field as (recommended
>    by RFC2472) of a transiting IPv6 packet to the corresponding
>    value. This extended community is encoded as a sequence of 42 zero
>    bits followed by the 6 bits overwriting DSCP portion of Traffic
>    Class value.

s/2472/2474/
Otherwise this looks fine.

Thanks
    Brian
> 
> Let me know if this addresses yr points before I republish. RFC2472 will
> be also added as normative reference while draft-ietf-6man-flow-3697bis
> as an informative one.
> 
> Many thx and apologies for missing your first email,
> R.
> 
>> Hi,
>>
>> From: Brian E Carpenter<[email-masked]>
>> References:<[email-masked]>
>>
>> Hi,
>>
>>>        Encoding:<type (1 octet), [op, value]+>
>>>
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
> 
>