headers
Thomas M. Knoll | 9 Jun 16:43
Picon

New Draft Notification draft-knoll-idr-qos-attribute-00.txt

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
Permalink | Reply | 18 comments |
headers
Robert Raszuk | 9 Jun 20:46
Favicon

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

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,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas M. Knoll | 9 Jun 21:45
Picon

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

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Haas | 11 Jun 04:29

Re: Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt

Joan,

On Tue, May 13, 2008 at 05:42:00PM -0400, Joan Cucchiara wrote:
>>> E: f(BGP4-MIB), (1826,13) Index item "bgpAfPathAttrUnknownCode"
[et alia]
>>> defined with syntax that includes a range

> Based on your response, could the range start at 1?
> In other words, since this index is an opaque handle and since the
> range is large, RFC2578, Section 7.7 requests that an index like
> this should start at 1, since zero should be avoided.
> The specific quote is:
>   "Instances identified by use of integer-valued objects should be
>   numbered starting from one (i.e., not from zero).  The use of zero as
>   a value for an integer-valued index object should be avoided, except
>   in special cases."

I have added OBJECT clauses that restrict these values from
1..4294967295.

>>> E: f(BGP4-MIB), (1228,5) Item "bgpNlriPrefixType" has invalid
>>> value for MAX-ACCESS
>
> This is not listed in the INDEX clause and it has a MAX-ACCESS of
> "not-accessible".    Is this supposed to be part of the INDEX?  If not,
> then it should have a different type of MAX-ACCESS.

I've made this read-only and added it to the bgpAfPathAttributesGroup
OBJECT-GROUP.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Yakov Rekhter | 11 Jun 15:32
Favicon

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

Thomas,

> 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.

Are you asking the WG to accept your document as an IDR WG document,
or just to comment on your document ?

Yakov.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 3 comments |
headers
John G. Scudder | 11 Jun 21:34
Favicon

Fwd: New Version Notification for draft-pmohapat-l3vpn-acceptown-community-00

FYI.  This version incorporates feedback received from IDR WG  
members.  We've requested a slot to discuss this at the IETF-72 l3vpn  
meeting.

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: June 8, 2008 3:47:16 AM GMT-04:00
> To: pmohapat <at> cisco.com
> Cc: uttaro <at> att.com, dasmith <at> cisco.com, raszuk <at> juniper.net, jgs <at> juniper.net 
> , ipr <at> ietf.org
> Subject: New Version Notification for  draft-pmohapat-l3vpn- 
> acceptown-community-00
>
>
> A new version of I-D, draft-pmohapat-l3vpn-acceptown- 
> community-00.txt has been successfuly submitted by Pradosh Mohapatra  
> and posted to the IETF repository.
>
> Filename:	 draft-pmohapat-l3vpn-acceptown-community
> Revision:	 00
> Title:		 BGP ACCEPT_OWN Well-known Community Attribute
> Creation_date:	 2008-06-08
> WG ID:		 Independent Submission
> Number_of_pages: 9
>
> Abstract:
> Under certain conditions it is desirable for a BGP route reflector to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Dickson | 12 Jun 06:33

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

Dear WG members,

A new draft has been uploaded, which proposes a new well-known community, LAST_RESORT.

It is available at 
http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-00.txt
and I would kindly ask you for comments to it.

I would like the IDR to consider adoption of the draft as a WG item.

Thanks in advance,

Brian Dickson

(P.S. If anyone knows a way to convince xml2rfc to avoid forcing a new page on every new section number,
I would be happy to shorten the apparent length from 15 pages to about 4. :-))

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 11 comments |
headers
Brian Dickson | 12 Jun 06:43

New Draft Notification draft-dickson-idr-last-resort

(Sorry for the double-post - bad subject line first time. -briand )

Dear WG members,

A new draft has been uploaded, which proposes a new well-known community, LAST_RESORT.

It is available at 
http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-00.txt
and I would kindly ask you for comments to it.

I would like the IDR to consider adoption of the draft as a WG item.

Thanks in advance,

Brian Dickson

(P.S. If anyone knows a way to convince xml2rfc to avoid forcing a new page on every new section number,
I would be happy to shorten the apparent length from 15 pages to about 4. :-))

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 10 comments |
headers
Thomas M. Knoll | 12 Jun 15:10
Picon

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

Dear Yakov,

since the draft is an extension to the IDR development of Extended 
Community Attributes and does foster class-based inter-domain forwarding 
capabilities by means of BGP4 messages, I would be glad to see the 
document become an IDR WG document.

I could also present a comparison between current practices and the new 
approach to the WG at IETF 72.

Regards
Thomas

On Wed, 11 Jun 2008, Yakov Rekhter wrote:

> Thomas,
>
>> 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.
>
> Are you asking the WG to accept your document as an IDR WG document,
> or just to comment on your document ?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Yakov Rekhter | 12 Jun 16:09
Favicon

Re: New Draft Notification draft-dickson-idr-last-resort

Brian,

> (Sorry for the double-post - bad subject line first time. -briand )
> 
> Dear WG members,
> 
> A new draft has been uploaded, which proposes a new well-known community, 
> LAST_RESORT.
> 
> It is available at 
> http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-00.txt
> and I would kindly ask you for comments to it.
> 
> I would like the IDR to consider adoption of the draft as a WG item.

Do you plan to present this draft at the upcoming IDR WG meeting
at IETF 72 ? If yes, would you consider asking the IDR WG to 
consider adoption of your draft as an IDR WG item after your
presentation ?

Yakov.

> 
> Thanks in advance,
> 
> Brian Dickson
> 
> (P.S. If anyone knows a way to convince xml2rfc to avoid forcing a new page o
n every new section number,
> I would be happy to shorten the apparent length from 15 pages to about 4. :-)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane