Subject: RE: [Diffserv] Re: FlowId and FlowIdOrAny

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 21 Jan 2003 16:21:47 +0100

OK, so if I understand you correctly, then the newly proposed
TCs would also be useable for the Intserv MIB when they do
a revision, right? And again that can then be considered
a bug fix. 

So we now have a conflict in that if we make it Integer32, 
then diffserv MIB needs to deprecate and create a new object
If we make it Unsigned32, then Intserv MIB needs to deprecate
and create a new object.

It then seems to me that making it Integer32 as suggested by
Juergen then makes the most sense, since that seems to be
then more consistent with how we have done this at other
places (that is, used a -1 value to mean any).

Comments?

Thanks,
Bert 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: dinsdag 21 januari 2003 15:18
> To: Juergen Schoenwaelder
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Diffserv] Re: FlowId and FlowIdOrAny
> 
> 
> The flow label in IPv6 was 24 bits at one time. So that looks like
> a minor obsolescence in the Intserv MIB.
> 
>     Brian
> 
> Juergen Schoenwaelder wrote:
> > 
> > >>>>> Wijnen, Bert (Bert) writes:
> > 
> > Bert> Now... if we do this, then this could still be used by the
> > Bert> framework pib.  However, for the diffserv-mib it 
> would mean they
> > Bert> must deprecate a current object and create a new one 
> (switching
> > Bert> from Unsigned to Integer32 causes a change on the wire!).
> > 
> > Oops, I missed that part of the picture. So if there is concensus to
> > change the range as a bug fix in the DIFFSERV0MIB without 
> introducing
> > a new object (which formally the SMIv2 would require to do), then
> > using Unsigned32 makes some sense. Note that this will also most
> > likely include the definition of a DEFVAL which is in fact the new
> > value.  However, if we decided that it is safer to use deprecate the
> > filter obejct and introduce a new one, I prefer to use Integer32.
> > 
> > BTW, this is what I found in the INTEGRATED-SERVICES-MIB:
> > 
> >     intSrvFlowFlowId OBJECT-TYPE
> >         SYNTAX      INTEGER (0..16777215)
> >         MAX-ACCESS  read-only
> >         STATUS      current
> >         DESCRIPTION
> >            "The flow ID that  this  sender  is  using,  if
> >            this  is  an IPv6 session."
> >        ::= { intSrvFlowEntry 11 }
> > 
> > Note that this range is [0..2^24-1] while the other 
> definitions under
> > discussion use a range of [0..2^20-1]. Note that RFC 2460 says:
> > 
> > :    Flow Label           20-bit flow label.  See section 6.
> > 
> > /js
> > 
> > --
> > Juergen Schoenwaelder    
> <http://www.informatik.uni-osnabrueck.de/schoenw/>
> 
_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 23 Jan 2003 02:51:55 +0100

I checked with authors and WG chair of SSPM MIB

I have a request outstanding to author(s) of ipsec-conf-mib

Thanks,
Bert 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]]
Sent: woensdag 22 januari 2003 23:15
To: Wijnen, Bert (Bert)
Cc: Dan Romascanu (E-mail); Carl Kalbfleisch (E-mail); Bob Cole (E-mail)
Subject: Re: FW: FlowId and FlowIdOrAny

At 04:31 PM 1/22/2003 +0100, Wijnen, Bert (Bert) wrote:
>Are you following RAP or DIFFSERV WG mailing lists?

I am on the diffserv list.
Thanks for bringing this to our attention.

To be consistent with previous decisions related to
the DSMON MIB, the RMONMIB WG would prefer it if the
WG owning IPv6 flow standards would publish a MIB
module containing the appropriate TCs, so we can import
them into the SSPM MIB.

thanks,
Andy

>We are discussing a common set of TCs to be used by multiple
>MIB and PIB modules.
>
>If your not up to date, you may want to check the mailing lists 
>archives. Discussion was over teh last week or two.
>
>Thanks,
>Bert 
>p.s. I know I have this doc in AD review.... but you may
>want to check this part of it yet
>
>From: Juergen Schoenwaelder [mailto:[email-masked]]
>Sent: woensdag 22 januari 2003 15:19
>To: [email-masked]; [email-masked]
>Subject: Re: FlowId and FlowIdOrAny
>
>
>
>I found some more objects that seem to model a flow label. It turns
>out that MIB authors are really creative...
>
>draft-ietf-ipsp-ipsec-conf-mib-05.txt:
>
>  ihfIPv6FlowLabel OBJECT-TYPE
>      SYNTAX      OCTET STRING (SIZE(3))
>      MAX-ACCESS  read-create
>      STATUS      current
>      DESCRIPTION
>          "The IPv6 Flow Label that the packet must match against.
>          This object is only used if ipv6FlowLabel is set in ihfType."
>      ::= { ipHeaderFilterEntry 13 }
>
>  They obviously have another mechanism to control whether the
>  object participates in a match.
>
>draft-ietf-rmonmib-sspm-mib-06.txt:
>
>   sspmSourceProfileFlowLabel OBJECT-TYPE
>       SYNTAX      Integer32 (0..1048575)     -- 20-bit range (0 to 0xfffff)
>       MAX-ACCESS  read-create
>       STATUS      current
>       DESCRIPTION
>           "This object is  used to specify the Flow Label  in a IPv6
>            packet (RFC 2460) to force special handling by the IPv6 routers for
>            non-default quality-of-service.
>
>            This object is meaningful only when sspmSourceDestAddressType is
>            ipv6(2).  The value of this object defaults to zero if not
>            set."
>       DEFVAL { 0 }
>       ::= { sspmSourceProfileEntry 7 }
>
>  This object seems to actually control how the flow label looks like
>  in packets coming from a synthetic traffic source.
>
>Note that these objects are called flow label rather than flowid and
>hence I did not find them the first time...
>
>/js
>
>-- 
>Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

---

From: Branislav Meandzija <[email-masked]>
Date: Mon, 27 Jan 2003 15:10:17 -0800

Procedurally, very complex fix for something very simple but it seems the best possible one.

Branislav

  > 
  > My proposal is to do the following:
  > 
  > - Someone creates a new ID that contains a small MIB module
  >   that contains two TCs:
  > 
  >   FlowId            TEXTUAL-CONVENTION
  >       DISPLAY-HINT "d"
  >       STATUS        current
  >       DESCRIPTION  "The flow identifier or flow Label in an IPv6
  >                     header that may be used to discriminate traffic
  >                     flows.
  >                    "
  >       SYNTAX        Integer32 (0..1048575)
  > 
  >   FlowIdOrAny       TEXTUAL-CONVENTION
  >       DISPLAY-HINT "d"
  >       STATUS        current
  >       DESCRIPTION  "The flow identifier or flow lable in an IPv6 
  >                     header that may be used to discriminate traffic
  >                     flows.  The value of -1 is used to indicate a
  >                     wildcard, i.e. any value.
  >                    "
  >       SYNTAX        Integer32 (-1 | 0..1048575)