Subject: [Idr] Next revision of AS_HOPCOUNT

From: Tony Li <[email-masked]>
Date: Tue, 10 Jan 2006 12:35:57 -0800

Hi folks,

Based on the discussion that we've had so far, the authors of the  
AS_HOPCOUNT draft would
like to make some substantive changes to the draft.  The chairs have  
asked that we poll you to
ensure that we have rough consensus on the new direction.  The  
primary technical points of
these changes:

- Convert AS_HOPCOUNT from being decremented at each AS boundary and  
instead have it
   be a static upper bound on the AS path length.

- Rename the attribute to AS_PATHLIMIT.

- Completely remove the interaction with NO_EXPORT.

There are, of course, a number of details more fully explained in the  
revised draft, but before we
are allowed to present you with the revision, we need to have your  
approval on the above.

Could folks please comment to the list within the next two weeks as  
to whether or not this direction
is acceptable?  As this is to help gauge consensus, both positive and  
negative comments are
solicited.

Regards,
Joe & Rex & Tony

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

---

From: Danny McPherson <[email-masked]>
Date: Tue, 10 Jan 2006 13:57:43 -0700

On Jan 10, 2006, at 1:35 PM, Tony Li wrote:
> is acceptable?  As this is to help gauge consensus, both positive  
> and negative comments are
> solicited.

For sake of progress: I'm in favor of all these changes to the draft...

--------------
For sake of other: I'm surprised you're being asked to poll the WG
before instituting them.  Out of curiosity, how many hands are required
to move forward?  And is there some pre-determined percentage of
in-favor/not-in-favor that dictates reasonable consensus in the face of
contention?

It's just that I'd really rather not see the noise - if folks take  
issue with
these changes shouldn't they comment when said issues are being
discussed?

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jan 2006 17:37:08 -0500

Tony,

Apologies for not chiming in earlier.  Vacations and all that. :-)
My comments for the proposed feature are interspersed and cover
a number of previous e-mails.

> - Rename the attribute to AS_PATHLIMIT.

I prefer the decrement behavior.

> - Completely remove the interaction with NO_EXPORT.

I would agree.

John Leslie brought up an interesting case that it woule be safe to
simply set NO_EXPORT when hopcount was 1 and we are propagating the
route.  It helps to guarantee that the next AS will not propagate
it, even if it doesn't understand the AS_HOPCOUNT attribute.

Another comment (Danny I think) spoke about where we check the
value.  If the value was checked upon egress, then we can avoid
sending the route to a downstream BGP speaker that may not understand
the attribute.

(Checking the value upon ingress in addition to egress is probably
a safe thing to do.)

Another previous comment suggests that we may not simply want to rely
on the behavior of BGP speakers that understand the feature to
decrement the value, but that we may wish to decrement it when
we think that it may not have been decremented for us.  If confederations
weren't a condition upon which the value was decremented, then it
would be possible to use the number of distinct ASes after the
advisory value to determine if the count was what we expected.

In the following example, presume that the BGP speaker doesn't
propagate the route if the decremented value would be zero.  (Change
from the spec in-line with my comments above.)

E.g.:

 A --- B --- C --- D --- E

If A sets the value to 2, we would expect B and C to receive
the route and AS-A would be in the attribute.  If C doesn't
understand the attribute, but D does, D can examine the AS_PATH C B A
and determine that the expected hop count has already been
exceeded.

Padding would need to be accounted for, so padding would need to 
be ignored when determining the number of ASes that have been
transited.

Other comments:

The 4 byte AS number in the attribute is probably a good idea.
However, we should carefully explain the behavior when the 4 byte
AS must be utilized by a 2byte speaker.

Like Danny, I would prefer that confederation boundaries be ignored
for purposes of the count.  However, this is also something I expect
that vendors may prefer to implement a knob to affect the behavior.

I think it would be good to specify behavior when aggregating routes
containing this attribute.

Your text regarding ATOMIC_AGGREGATE seems very 1771'ish.  The current
text on ATOMIC_AGGREGATE isn't quite as stringent on how this
attribute is set.

-- 
Jeff Haas 
NextHop Technologies

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Jan 2006 15:00:08 -0800

Jeffrey,

> sending the route to a downstream BGP speaker that may not understand

This is also addressed in the revised draft, but is actually more of  
an implementation
issue.

> (Checking the value upon ingress in addition to egress is probably

Yes, the revised draft specifies both checks.

> advisory value to determine if the count was what we expected.

This was exactly why we were shifting to a static value and way from
decrement.

> AS must be utilized by a 2byte speaker.

The draft references the encoding rules used in the 4 octet draft.

> that vendors may prefer to implement a knob to affect the behavior.

The revised draft specifies that confederations be ignored.  Extensions
on top of this are, as you note, optional and perhaps inevitable.

> text on ATOMIC_AGGREGATE isn't quite as stringent on how this

You'll pardon me if my paranoia regarding deaggregation hasn't abated in
the last 15 years.  ;-)  If you feel additional text is warranted,  
contributions are
most welcome.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Wed, 11 Jan 2006 00:37:43 +0000 (GMT)

On Tue, 10 Jan 2006, Tony Li wrote:

> - Convert AS_HOPCOUNT from being decremented at each AS boundary 
> and instead have it be a static upper bound on the AS path length.

Hmm, a simple decrement seems nicer.

I hate dependencies between attributes, particularly (here) on the 
relatively vague property of path length. If you have to depend on 
some other attribute, I'd prefer the no-export interaction/dependency 
to this one.

My €0.02 anyway.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
On Thanksgiving Day all over America, families sit down to dinner at the
same moment -- halftime.

---

From: Enke Chen <[email-masked]>
Date: Tue, 10 Jan 2006 18:12:50 -0800

Hi, Tony:

Tony Li wrote:

> ensure that we have rough consensus on the new direction. The primary 
> technical points of
> these changes:
>

It is not clear to me how this would work with "ASPATH prepend", 
especially in an environment where some routers recognize the new 
attribute, and some do not (thus can not adjust the hopcount with prepend).

More specifically, consider a routing announcement from A --> B --> C -- 
 > D --> E, each has its own AS (say a, b, c, d, e respectively).

1) Router A recognizes the attribute, and set the hopcount to 5 with the 
intention for the announcement to reach E.
2) Router B does not recognize the attribute, thus would pass the new 
attribute. But it does AS prepend toward C, and the ASPATH would be: b b 
b b a
3) Router C recognize the attribute, and would not advertise the route 
to D due to the hopcount.

On the other hand, the AS_HOPCOUNT as a decrementor does not have this 
loss of connectivity issue.

-- Enke

---

From: Russ White <[email-masked]>
Date: Tue, 10 Jan 2006 21:23:35 -0500

> loss of connectivity issue.

It seems to me that what you want is the "absolute length" of the AS 
Path--the number of unique AS' in the path--rather than the "literal 
length." I know most implemenations (no implementations?) can do this 
today, but the absolute length seems like the only way to actually make 
the as hop count work in all situations.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Enke Chen <[email-masked]>
Date: Tue, 10 Jan 2006 18:28:34 -0800

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>  
>

What if the prepend is "x y z" instead?

It seems to me that the "decrementor" as previously defined is simpler.

-- Enke

---

From: Keyur <[email-masked]>
Date: Tue, 10 Jan 2006 18:49:38 -0800

Enke:

> attribute. But it does AS prepend toward C, and the ASPATH would be: b b 

Would it be too bad to modify the hopcount at this point to reflect the 
number of prepend ASes?

-Keyur

---

From: Joe Abley <[email-masked]>
Date: Tue, 10 Jan 2006 22:20:49 -0500

On 10-Jan-2006, at 21:12, Enke Chen wrote:

>  not clear to me how this would work with "ASPATH prepend",  

I think the intention of Tony's text is clearer if it is rephrased as  
"static upper bound on the length of the modified AS_PATH attribute",  
where the modification referred to is the elimination of private-use  
numbers, etc.

> More specifically, consider a routing announcement from A --> B -->  
> C -- > D --> E, each has its own AS (say a, b, c, d, e respectively).
>
> 1) Router A recognizes the attribute, and set the hopcount to 5  
> with the intention for the announcement to reach E.
> 2) Router B does not recognize the attribute, thus would pass the  
> new attribute. But it does AS prepend toward C, and the ASPATH  
> would be: b b b b a
> 3) Router C recognize the attribute, and would not advertise the  
> route to D due to the hopcount.

Correct.

> On the other hand, the AS_HOPCOUNT as a decrementor does not have  
> this loss of connectivity issue.

When viewed from another angle, AS_HOPCOUNT as decrementor fails to  
take account of the fact that B is prepending towards C (presumably  
for a reason). It does not seem inconsistent with the intentions of  
A's operator for the route to be dropped in this case before it  
reaches E.

Even with more elaborate mechanisms at your disposal, when you're  
second-guessign the routing policies of remote networks, the best you  
can do is try to influence propagation. There is no absolute control.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 10 Jan 2006 22:30:41 -0500

> It seems to me that the "decrementor" as previously defined is  

I think they are both fairly simple.

I think that bounding the AS_PATH length has greater chance of being  
useful in the short term for applications where propagating too  
little is greatly preferred over propagating too widely (e.g. "local  
nodes" providing anycast service distribution): the AS-count variable  
(AS_PATH) continues to happen in routers without this new functionality.

By comparison, the decrementor behaviour (without the NO_EXPORT  
interaction, which was intended to bridge the implementation gap)  
will need quite substantial deployment before it can be used for the  
anycast node application.

Clearly anycast nodes are not the only potential consumers of this  
mechanism, but it seems like a shame not to accommodate their  
requirements if we can.

Joe

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Jan 2006 21:12:53 -0800

> It seems to me that the "decrementor" as previously defined is  

In addition to Joe's comments...

The problem that we had with decrementing the hopcount is that the  
semantics of this got VERY
messy when we also tried to take into account partial deployment.   
Which AS's decrement?  Which
routers within the AS decrement?  It all depends on the software rev  
of each individual router.
You could have two routers from the same AS that advertise the same  
prefix to you with
two different hopcounts, all based on the same original advertisement.

Having a static constant in the attribute is simpler, in that the  
first receiver that supports PATHLIMIT
that sees a too-long AS_PATH can discard the route.  There is no  
ambiguity about the semantics.

Yes, we need to deal with prepend, but whatever way we choose, the  
semantics are straightforward.
And if there is *ANYTHING* that my years of experience have taught  
me, it's to favor the
straightforward semantics.  ;-)

Tony

p.s. I should also point out that this issue was discussed on the  
mailing list a few weeks ago.  The
consensus on this issue seemed pretty clear to me.  Folks in favor of  
decrement were NOT
speaking up.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Jan 2006 07:51:59 +0200 (EET)

On Tue, 10 Jan 2006, Tony Li wrote:
> - Convert AS_HOPCOUNT from being decremented at each AS boundary and instead 
> have it

I think this is exactly the direction to follow.  This lessens my 
concerns of this attribute considerably.  The simpler, the better.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dana Blair <[email-masked]>
Date: Wed, 11 Jan 2006 08:25:45 -0500

>   be a static upper bound on the AS path length.

This is necessary for partial deployment.

> - Rename the attribute to AS_PATHLIMIT.

I don't have an opinion on renaming as long as the draft moves forward.

> - Completely remove the interaction with NO_EXPORT.

I'm not expert enough (yet) to have an opinion on NO_EXPORT.

Dana

> Could folks please comment to the list within the next two weeks as to 
> whether or not this direction

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Jan 2006 10:33:03 -0500

Tony,

> This was exactly why we were shifting to a static value and way from

I don't have a strong enough opinion on wanting the decrement to
warrant a serious objection, just a preference.  I think I'll buy
into your argument that the fewer routers that have to worry about
actually changing the attribute, the better.  I withdraw my previous
support for using decrement. 

I would definitely like to see more language about how we do the
counting.  Absolute path length seems to be the wrong choice.  I think that
Russ's verbiage about distinct ASes is close.  I'd suggest that
we count any recurring adjacent sequences of an AS in one or more 
AS_SEQUENCEs as length 1 and simply count an entire AS_SET, regardless
of content, as length 1.

Ergo:

1 1 1 2 3 3 2 [5 6 7]

would count as length 5.  Yes, there's an intentional loop in there.

> The draft references the encoding rules used in the 4 octet draft.

This is somewhat problematic when dealing with a 2 byte speaker
with AS_TRANS in the AS_PATH.  Without peeking into the NEW_AS_PATH,
you can't tell if multiple occurrences are distinct ASes or not.  This
affects how I'd expect path length counting to occur.

Of course, if you're counting absolute path length, that changes things.

(I'm really hoping you're not counting absolute path length.)

> contributions are most welcome.

Let's just say I share your paranoia.  However, the current BGP RFC-to-be
doesn't use that particular verbiage and this leaves this document
out of "harmony".  I say this mostly because no one seems to implement
ATOMIC_AGGREGATE in the way that suggested in 1771.  Additionally, per
some e-mail chains a few years ago, adding ATOMIC_AGGREGATE on an
outbound-only basis isn't sufficient.  Safest to just pretend we don't
deaggregate since it leads to madness.

-- 
Jeff Haas 
NextHop Technologies

---

From: Tony Li <[email-masked]>
Date: Wed, 11 Jan 2006 16:16:00 -0800

Jeff,

> AS_SEQUENCEs as length 1 and simply count an entire AS_SET, regardless

Well, the language that I'm proposing is slightly different in intent  
and result.
Regardless, when the revised draft is issued, I'd welcome alternate  
proposals
and contributions of specific language that capture WG consensus.

> affects how I'd expect path length counting to occur.

Good point.  Let's also put that on the agenda.

Tony

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 13 Jan 2006 15:53:01 +0100

----- Original Message -----
From: "Tony Li" <[email-masked]>
To: "Inter-Domain Routing List" <[email-masked]>
Sent: Tuesday, January 10, 2006 9:35 PM
Subject: [Idr] Next revision of AS_HOPCOUNT

> - Convert AS_HOPCOUNT from being decremented at each AS boundary and  >
instead have it  be a static upper bound on the AS path length.
Yes, I think that is absolutely right.  Decrementing counts was fine when the
community was smaller and closer knit, more trustworthy perhaps.  In the present
heterogeneous world, I think static upper bound the right approach.  It is also
easier to secure whatever form security ultimately takes.

> - Rename the attribute to AS_PATHLIMIT.

Fits in with the abouve

> - Completely remove the interaction with NO_EXPORT.

Not sure that this is completely possible; to take the view that any reason not
to advertise means do not advertise is a form of interaction, which might
conflict with the use of AS_PATHLIMIT (no, I haven't got a concrete example of
when this would happen)

Tom Petch.

---

From: Joe Abley <[email-masked]>
Date: Fri, 13 Jan 2006 12:49:32 -0500

> conflict with the use of AS_PATHLIMIT (no, I haven't got a concrete  

I think what Tony meant by his sentence above was that the  
interaction specified in draft-idr-as-hopcount-00 would be removed as  
part of this revision. No greater philosophical message should be  
inferred :-)

Joe