Re: [Idr] New Draft Notification draft-knoll-idr-qos-attribute-00.txt

["Thomas M. Knoll" <knoll at etit.tu-chemnitz.de>]

Thank you, Robert, for this fast reply.

The point of this draft is not to signal single QoS markings for /32 
prefixes but rather to make the class set and class encodings on different 
layers seen to all ASes (not only neighbouring ones).
Those QoS Marking Attribute (one per class and layer) would now been 
associated with the possibly long list of NLRI IP prefixes of different 
sizes.

If a traffic source now wants to send ftp traffic and voice traffic to one 
of these prefixes, the sending AS could now see which class set will be 
supported by the targeted AS and which encoding the next hop neighbour AS 
will be using for this class.
So, the assumption of having all traffic now beeing marked as voice is not 
true. The sending AS is free to choose its marking as it is today. But it 
can now make an informed decision on how to possibly remark its own DSCP 
at the egress to fit best the available class set along the forwarding 
chain.
If neighbouring ASes support equal class encodings (which they are now 
informed about by means of the attribute), the neighbour's incress layer 4 
or higher layer classification can even become redundant with this new 
approach.

As far as previous QoS attribute contributions are concerned, I have found 
some drafts, which specified certain delay, bandwidth etc. parameters 
within the attributes, but I did not find a draft, which mentioned to 
convey the QoS marking for different technologies.
So I take your advice, that I should have mentioned those drafts in order 
to make clear, that my approach is not about QoS parameter signalling but 
rather about QoS marking signalling.

I hope this resolves some concerns and I thank you again for your fast 
feedback.

Regards,
Thomas


On Mon, 9 Jun 2008, Robert Raszuk wrote:

> Hi Thomas,
>
> I would like to clarify one point this draft is suggesting ...
>
> If I understand it correctly it proposes to propagate QoS marking within BGP 
> across domain boundaries. The least granularity I could see this used with is 
> /32 (mostly unroutable in the internet). But even that .. even if this is to 
> work only across two peering ASes which allow to send to each other number of 
> /32s it assumes that this entire destination uses the same QoS marking. So if 
> this is a server with voice, video and httpd running everything to it would 
> use voice qos marking. IMHO this is already non starter.
>
> Now section 3.3 goes even further ... if we are sending an aggregate in BGP 
> (/24 /20 /16 etc ...) and if even a single member of an aggregate uses qos 
> marking (for example for voice) all packets going this entire aggregate 
> should be marked as voice ? I think this would be a mistake.
>
> Marking is usually done on packet content inspection on ingress (up to 
> application layer) and not on it's destination.
>
> IMHO BGP is too course to carry qos marking in the single SAFI. Note that 
> some time back there was an attempt to make context address family to allow 
> to achieve very similar goal to yours but at more controllable and granular 
> fashion. That included the ability to send those separate classes of traffic 
> via different next hops and map them to different forwarding paradigms in 
> peering ASes (one could use TE-LSPs, one MTR etc.). Your proposal does not 
> have any reference to it.
>
> Thx,
> R.
>
>
>> Dear WG members,
>> 
>> a new draft has been uploaded, which suggests the definition of a new 
>> extended community attribute for QoS marking.
>> It is available at 
>> http://tools.ietf.org/html/draft-knoll-idr-qos-attribute-00 and I would 
>> kindly ask you for comments to it.
>> I would like the IDR to consider the proposed mechanism for further study 
>> within the WG.
>> 
>> Regards,
>> Thomas M. Knoll
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr at ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>> 
>
>
>
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr