RE: Last Call: Textual Conventions for IPv6 Flow Label to Proposed Standard

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote:
> > As being uneducated wrt. deeper implications, I would like to see more
> > explicit justification for FlowLabelOrAny.  I cannot imagine all that many
> > uses that the extra '-1' for any value might bring, except for the
> 
> I/we are not claiming if there are MANY oir just a few who need the -1.
> 
> But the fact that Diffserv MIB (RFC3289) and Framework PIB (RFC3318) need
> to be able to filter on either a specific FlowLabel or on ANY flowlabel,
> that is why we came up with the FlowLabelOrAny spec, so that it will
> be done in ONE CONSISTENT manner. There were several ways of doing things
> already.

Ok.
 
> So that is the explanation/movivation/justification.
> 
> If you buy into that, can you suggest specific text to be added?
> Maybe it is just a matter of axpanding the first sentence of the
> introduction from:
>    Several standards-track MIB modules have defined objects to represent
>    an IPv6 Flow Label (sometimes refered to as Flow ID)
> into
>    Several standards-track MIB modules have defined objects to represent
>    an IPv6 Flow Label (sometimes refered to as Flow ID) and IPv6 Flow Label
>    filters
> Would that address your concern?

This would be fine.
 
> > implementation laziness (just report -1 with everything for read access).  
> > This might be different if you were aiming towards R/W 
> > access.. which in turn might be a bad idea.
> > 
>
> They are indded max-access READ-WRITE or READ-CREATE.
> I do not see the problem with that either. Pls explain.

The problem of READ-WRITE or READ-CREATE seems to be that the MIB object
cannot exist before a connection has been established.  But then it
already has a flow label (or none) associated to it.  It seems too late to
change it on the fly.

So, being able to change flow labels of existing flows seems like 
something you must be very, very careful about in any case.

Hope this clarifies my concern.
 
> > Another minor issue is that one might want to informationally 
> > refer to draft-ietf-ipv6-flow-label-06.txt.
> > 
>
> I can do so if it makes sense. When the question was asked before
> (I believe it was in private email), the answer we got was:
> 
> >> I think the MIB draft should have a normative reference to the 
> >> flow label draft to avoid any surprises later.
> >
> >Why?  The field is actually defined in RFC 2460, and the MIB
> >doesn't deal with any of the issues regarding the use of the
> >flow label, as defined in the flow label draft.
> >
> >If possible, we'd like to avoid a dependence on the flow label
> >draft, since the flow label TCs are needed immediately for
> >MIB work in other areas.
> 
> As informational reference, it will allow to be referenced as
> "work in progress", so that won't hold us up. So I can do so
> if it makes a big diffrence. But since the claim is that the
> field is actually defined in RFC2460 (to which there is a normative
> reference), I think we're covered already.

Yep, I certainly support this -- there is no need to tie the progress to
the flow label spec (and there is nothing used here which is not in
RFC2460 so normative is not needed AFACS).. but if you're interested in
how flow labels are to be used, it makes sense to read the flow label
draft, and informative reference seems justified.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings