Hello Yves,
After reading the draft I couldn't understand well the flow ID
role within the SLS. Maybe, some explanation of the granularity of a flow
is missing there. So, an SLS should have only one flowID specified/described
by some parameters (e.g. IP/TCP header fields). However, assuming a unique
flowID for a single SLS, wouldn't be appropriate to allow for multiple DScodepoints?
On the other hand, an SLS could group a set of flowID's. Each one,
describing a microflow with a single DSCodepoint...
So, I see two situations:
1. SLS with a single FlowID (specification/description):
comprising the aggregate behaviour of a traffic flow.
2. SLS with multiple flowIDs: comprising the aggregate behaviour
however through groups of microflows description...
Finally, I'm not sure of using the term "Flow Specification"
within the document. This may be confused by the Flow Spec definition
of the RFC 1363 and used within the RFC 1633 (IntServ WG). I'd
suggest to call it "Flow Description" instead.
Just some ideas and suggestions...
Cheers. Marcelo
On Mon, 16 Oct 2000, Yves T'Joens wrote:
> Marcus Brunner wrote:
> >
> > Yves,
> >
> > [...]
> >
> > > next week, a new version of the sls draft , a framework document and
> > > indicative charter will be issued. based on this, we will see how much
> > > interest there is to go for a BoF/WG. Since we are a bit late, i will
> > > however already contact Bert to ask for a slot in San Diego. So far,
> > > from private mails prior to the activation of this list, i have seen
> > > quite some interest in specification of this. Also see (
> > > http://www.totaltele.com/view.asp?ArticleID=31724&Pub=tt
> > > )
> >
> > I think it is time to go for this now. Iw ill take a lot of time until
> > any agreement can be reached.
> >
> as usual i assume.
>
> > >
> > > as for the placing of the draft in the policy framework group : as i
> > > tried to explain during the presentation in Pittsburgh, I do agree that
> > > there is affinity with the work of the policy framework group, but you
> > > don't need the policy framework architecture for supporting the SLS
> > > negotiation. In that sense, it is different enough to allow the creation
> > > of a different working group.
> >
> > Look you don't need the Policy Framework WG, on the other hand, the SLS
> > handling/negotiation may be very well suited for policy control.
> >
>
> it is indeed input to the policy control. Whether this would feed into
> the Policy management tool, or directly to the PDP is really an
> implementation/deployment detail...
>
>
> > >
> > > how do you mean?
> > >
> > Again I think the Werner and I have not understand that an SLS can have
> > multiple flow-ids (do really want to allow severel flow-ids in an SLS?)
> >
>
> i corrected this in the mail to werner. A SLS should have only one flow
> id. However, the latter should be capable of aggregating flows
> identified by various (combinations) of IP header fields or other.
>
> > the exclusive OR in the list of destination addresses means you can only
> > specify a prefix or a host address, but not both of it. But this is not
> > a problem if you have severel flow ids.
> >
>
> we should indeed be more clear on this, now i understand.
>
> > > > >5. (and also bits of 1.2, etc.)
> > > > > The discussion on signaling appears premature and probably beyond
> > > > > the scope of a document specifying SLS parameters and semantics.
> > > >
> > > > I think there should be a requirements draft for the negotiation anyway.
> > >
> > > I don't know if one can really separate them, since a request for an SLS
> > > subscription/invocation may carry a different set of parameters then the
> > > ack/offer being presented by the network. we will try to clarify this in
> > > our next version.
> >
> > I think, it should be separated. It is clear that different parameters
> > are used in the request and the offer, but both are a service
> > specification. I do not doubt, that you need some additional information
> > for the negotation process, but this should be handled seperately.
> >
>
> we'll try it, and see if it is possible.
> thanks again
>
> Yves
>
----------------------------------------------------------
Marcelo Pias - University College London (UCL)
www.cs.ucl.ac.uk/staff/m.pias/
This archive was generated by hypermail 2b29 : Tue Oct 17 2000 - 13:34:08 CEST