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

[Brian E Carpenter <[e-mail]>]

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:
> 
>>>     Type 13 - Flow Label - New type
> 
> 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:
>>
>> 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.
> 
> Excellent point- thank you very much for catching it. I have reworded
> this section to the below:
> 
>    Traffic Marking: The traffic marking extended community instructs a
>    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,
>>
>> 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<[e-mail]>
>> Organization: University of Auckland
>> To: [e-mail]
>> References:<[e-mail]>
>>
>> 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
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
> 
>