Subject: Re: [Idr] Next revision of AS_HOPCOUNT

From: [email-masked]
Date: Wed, 11 Jan 2006 15:39:01 -0500 (EST)

>> As I understand it, the NO_EXPORT attribute is intended just
>> for your immediate neighbor, and is not supposed to be propagated
>> elsewhere.
>
>That'd be NO_ADVERTISE.
>> There's this "MUST NOT be advertised" in the spec.
>
>In reality, NO_EXPORT in practice is employed to convey to
>AN ADJACENT AS that the route should not be advertised to
>BGP peers outside of that AS (i.e., eBGP peers).

Yes, sorry, inexact use of terminology.  When I said neighbors,
I meant your external peer, I wasn't thinking of iBGP neighbors.

>This is no different than any other attribute.  For example, if
>an upstream chooses not to announce a route, well, there's
>little we can do about that.

Sending an update to your (ebgp) neighbor is not a prescription
of what he/she/it does with that update.  Sending an AS_HOPCOUNT/
AS_PATHLIMIT or a community of NO_EXPORT is a prescription of
what your (ebgp) neighbor is supposed to do with that update.
So they are really very different.

>> If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that
>> and adds a AS_PATHLIMIT of 15, would that be OK?
>
>Sure, why not?  If I'm the 4th AS and have reason to do so?  I own
>my network resources?

Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request,
and you can't expect anything particular to happen.

You should make this clear in the draft text.  In particular,
you should remove all "MUST" and "MUST NOT" from the text.
It makes no sense to say "MUST advertise an AS_HOPCOUNT attribute
of one less than the value received", if replacing the value
with any other value is OK.  It makes no sense to say
"If the attribute value is zero, the path MUST be ignored
without further processing", if the BGP speaker can chose to
ignore the limit and propagate.

Are you sure you know what you want here?  The language of the
draft sounds like certainty and determinism is desired, but
you are saying that no integrity protections are desired because
local policy might do anything it wanted.

--Sandy

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Jan 2006 16:34:22 -0500

> and you can't expect anything particular to happen.

Correct. Ditto for NO_EXPORT and MED (to choose two other attributes  
that are commonly meddled-with).

> you should remove all "MUST" and "MUST NOT" from the text.

I don't think so.

The draft specifies the required behaviour for an implementation in  
the case where the attribute is present. Those requirements are  
orthogonal to whether or not an operator of an AS decides to  
implement policy which removes particular attributes which were added  
elsewhere.

This is no different to the processing of NO_EXPORT. The semantics of  
how a BGP speaker should process a route with the NO_EXPORT community  
string attribute attached are described clearly, using normative  
text, in RFC 1997. There is nothing to stop people removing NO_EXPORT  
from routes as suits their local policy, however, just as there is  
nothing to stop people adding NO_EXPORT to routes whose originators  
intended them to propagate further.

> local policy might do anything it wanted.

Influencing other peoples' policy is a necessarily inexact science.

Joe

---

From: Danny McPherson <[email-masked]>
Date: Wed, 11 Jan 2006 14:48:24 -0700

> So they are really very different.

No, it's a prescription of what *you'd like your neighbor* to do with
the update.

> and you can't expect anything particular to happen.

Like it or not, isn't that the way routing in the Internet works today?

> ignore the limit and propagate.

This applies to ALL attributes deployed today - why the exception
here?

> local policy might do anything it wanted.

Again, like it or not, that's the nature of routing in the Internet
today.  Think about it..  What if someone downstream wanted
to manipulate a competitors traffic flows and they couldn't do
anything about it?

First and foremost, operators have to protect their networks and
employ policies that make good technical and business sense.
Then they can permit and employ features such as this.  In reality,
most likely would support it, e.g., for the reasons outlined in the
draft, but determinism is a bit of a misnomer in the real world when
your considering thousands of companies globally, all with different
legal, regulatory, business and economic motivations.

-danny