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

From: "Thomas M. Knoll" <[email-masked]>
Date: Mon, 9 Jun 2008 16:43:21 +0200 (MEST)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Jun 2008 11:46:49 -0700

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.

---

From: "Thomas M. Knoll" <[email-masked]>
Date: Mon, 9 Jun 2008 21:45:24 +0200 (MEST)

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:

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

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Jun 2008 06:32:36 -0700

Thomas,

> I would like the IDR to consider the proposed mechanism for further study 

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

Yakov.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 00:33:34 -0400

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 00:43:10 -0400

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

Dear WG members,

It is available at 

Thanks in advance,

Brian Dickson

---

From: "Thomas M. Knoll" <[email-masked]>
Date: Thu, 12 Jun 2008 15:10:55 +0200 (MEST)

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

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 12 Jun 2008 07:09:44 -0700

Brian,

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

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 12 Jun 2008 07:07:40 -0700

Thomas,

> approach to the WG at IETF 72.

With this in mind, how about if we ask the IDR WG for accepting
your document as an IDR WG document after you present your
document at IETF 72 ?

Yakov.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 10:11:57 -0400

> consider adoption of your draft as an IDR WG item after your

Yes, and Yes.

I guess I should ask for a mini-slot to present this. Please consider 
this to be such a request. :-)

Brian

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

---

From: "Thomas M. Knoll" <[email-masked]>
Date: Thu, 12 Jun 2008 16:43:50 +0200 (MEST)

That is fine with me, Yakov.
So, please reserve a slot for it on the agenda.
Thomas

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 14:27:05 -0400

Version -01 of the document has been uploaded, mostly fixing typos, 
adding/removing appropriate References, and condensing the formatting
(so as to avoid the mostly-blank pages - thanks Joel.)

Comments are more than welcome, they are invited. :-)

http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-01.txt

Thanks,

Brian

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 12 Jun 2008 20:44:07 +0200

Brian,

> http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-01.txt

One problem which is not discussed in the draft is the incremental 
deployment. You propose to change the BGP decision process, which could 
be dangerous as you could have in an AS different BGP decision processes.

Assume that in a given network some routers have been upgraded and 
support LAST_RESSORT, while other have not been upgraded and completely 
ignore it. In this case, you may easily enter in a situation where a 
permanent loop is created between routers that understand LAST_RESSORT 
and routers that do not understand it. I think that a safer approach 
would be to use the second option that you propose, namely to convert 
LAST_RESSORT into an appropriate LOCAL_PREF value when entering an AS.

Olivier
-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 15:08:53 -0400

Olivier Bonaventure wrote:
> deployment. You propose to change the BGP decision process, which 
> could be dangerous as you could have in an AS different BGP decision 
> processes.
>
> support LAST_RESSORT, while other have not been upgraded and 
> completely ignore it. In this case, you may easily enter in a 
> situation where a permanent loop is created between routers that 
> understand LAST_RESSORT and routers that do not understand it. I think 
> that a safer approach would be to use the second option that you 
> propose, namely to convert LAST_RESSORT into an appropriate LOCAL_PREF 
> value when entering an AS.

I'm quite certain that the existing requirements on BGP path selection, 
which prevents routing loops from occurring, are upheld with the new logic.

In order for a loop to occur, two routers need to mutually think the 
other is the best next-hop.

However, BGP only sends the local-best, and thus any router receiving a 
route from a neighbor, regardless of what policy or decision process led 
to that choice, can be sure that using that route will not result in a 
routing loop.

At worst, persistent oscillations may occur.

And, I believe it is the case, that no *new* persistent oscillations are 
introduced, that conditions leading to persistent oscillations would 
have had to exist prior to the new logic, for them to exist post-upgrade.

If you have two routers, one upgraded (U) and one not (N), then the 
possibilities are:

    * U sends an LR to N. N ignores the community and installs the route.
          o This is not a problem, since U would only send the LR to N
            if the LR was also the locally-selected "best" on U.
          o Note that this could only happen if the LR that U selected,
            was from (anyone-but-N).
          o if (and only if) N's previous best being withdrawn from U,
            causes u to select a different "best", a persistent
            oscillation will occur -- but not a permanent loop.
          o No routing loop; N -> U -> (not-N).
    * N sends an LR to U. U applies the new logic.
          o U will only install the route if it is the best route, i.e.
            no other non-LR routes exist.
          o N sent the LR because it was N's best, and it did not come
            from U.
          o if (and only if) U's previous best being withdrawn from N,
            causes N to select a different "best", a persistent
            oscillation will occur -- but not a permanent loop.
          o No routing loop; U -> N - > (not-U).

In all cases, a router will only announce a prefix if it is locally 
selected as "best". LAST_RESORT affects local selection, but does not 
change what happens once local selection is complete.

If after this explanation, you still believe a condition can exist where 
a permanent routing loop would occur, please walk me through a specific 
example, as I think that would be the best way to identify what leads 
the the loop.

Thanks,

Brian

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 13 Jun 2008 08:41:55 +0200

Brian,
> example, as I think that would be the best way to identify what leads 

The problem occurs inside iBGP. For example, consider the following AS

NU1 ----1-----U1----1----NU2------100-----U2

NU1 and U2 are border routers that receive an eBGP path with same AS 
Path length, same MED, ... but NU1 receives the path with LAST_RESORT 
while U2's path does not contain LAST_RESORT. The number on the links 
indicate the IGP cost

NU1 and NU2 do not understand LAST_RESORT while U1 and U2 understand it.
There is an iBGP full mesh.

NU1 accepts the path and places it inside its FIB. Same for U2.

U1 understands LAST_RESORT and thus selects U2 as its BGP nexthop.
NU2 does not understand LAST_RESORT and thus selects NU1 as its BGP 
nexthop. There is a forwarding loop between U1 and NU2. This loop did 
not exist before the introduction of LAST_RESORT

Olivier

---

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Jun 2008 13:14:13 -0400

Olivier Bonaventure wrote:
>> If after this explanation, you still believe a condition can exist 
>> where a permanent routing loop would occur, please walk me through a 
>> specific example, as I think that would be the best way to identify 
>> what leads the the loop.
>

Ah, yes, thanks. Good example, it makes it very clear.

My original gut instinct was for the LOCAL_PREFERENCE mechanism. I went 
with the change in path selection because I didn't want to be overly 
restrictive towards implementers.

I see my original instinct was right. :-)

I'll update the draft and post it shortly.

Thanks again for your input, I think the resulting draft is much cleaner 
now.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Jun 2008 13:33:29 -0400

Greetings, IDR folks.

Version -03 of the document has been uploaded.
This includes a slight change/simplification on implementation mechanism and its impact on both code and deployment scenarios.
(Thanks, Olivier.)

I would certainly appreciate further reviews and feedback, including opinions on support for the ID (private encouragement is fine.)

Thanks,

Brian

P.S. New ID version, new link:

http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-03.txt

---

From: Brian Dickson <[email-masked]>
Date: Sat, 28 Jun 2008 19:15:28 -0400

Since we're getting closer to the time when everyone is looking at 
things for Dublin, I have cleaned up the draft and posted it.

I expect it won't be changing much between now and Dublin, so if you 
have been holding off reading it (it's quite short), this would be a 
good time to give it a look.

I would certainly appreciate further reviews and feedback, including 
opinions on support for the ID (private encouragement is fine.)

Thanks,

Brian Dickson

http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-04.txt