Subject: Re: -18 last call comments

From: Manav <[email-masked]>
Date: Mon, 02 Dec 2002 13:03:50 -0800

> Right.  In fact this is nothing new.  The existence of the "AS
> Routing Loop" error incorrectly implied that such an UPDATE was a
> protocol violation, which it is not.

I understand that there can be situations when you receive your own AS
number in the UPDATE message and the best course of action is to simply
ignore it and proceed with the next set. But I personally feel uncomfortable
at simply ignoring UPDATE messages without doing anything else! I agree,
that tearing down a  session based solely on one UPDATE message is rather
unfair but isn't there something which we should do to inform our remote
peer that it is sending us UPDATEs which have our AS nos in the AS Path.
Some sort of no destructive CEASE message with an appropriate sub-code. I am
sure there can be plenty of other uses too!

I remember there was a discussion going on some time back in this list over
such non destructive messages (I think it was INFORM messages) and it
somehow never clicked! Are we sure that we *don't* require any such
mechanisms?

Just a thought.

Regards,
Manav

---

From: [email-masked]
Date: Mon, 02 Dec 2002 13:47:29 +0100

Manav wrote:

> at simply ignoring UPDATE messages without doing anything else!

In case of VPNs, it seems that loop prevention based on  AS-path is sometimes
disabled and replaced by loop prevention based on 'site of origin' to make sure
that routes learned from a  site (via eBGP)  are not readvertised to that site.
(example of hub and spoke VPN architecture). In this case it seems that ignoring
the UPDATE is a fair thing to do.

regards,
 Hans De Vleeschouwer

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Dec 2002 10:25:40 -0500

Manav,

On Mon, Dec 02, 2002 at 01:03:50PM -0800, Manav wrote:
> ignore it and proceed with the next set.

In the case of receiving your own AS number, this is fairly typical.

You may wish to search the archives for the thread on outbound 
as-loop detection.

> But I personally feel uncomfortable

This is a case of doing the thing that is least annoying to the user.
*Sure* you could log the messages, but in the above case, you'd 
end up saturating your logs with useless messages.

> I agree,

But this is normal behavior.

If I have some route which I have selected as active, I will propagate
this route to you and prepend my AS number to the AS PATH.  Nothing
in the current protocol specification says that I should check the
outgoing AS Path to see if *your* AS number is in it before I send it 
to you.

Note that actually *doing* the outbound loop detection may speed
convergence and is completely interoperable with existing implementations.

> somehow never clicked! Are we sure that we *don't* require any such

In this particular case, definitely not.

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 2 Dec 2002 10:54:45 -0500

>You may wish to search the archives for the thread on outbound
[etc]

I agree with Jeff's comments.

I have one further comment just in case it's not perfectly obvious to 
everyone, which is that "ignore the UPDATE" is not strictly the 
action you take when receiving a looped update.  Rather, you treat it 
as an implicit withdraw, i.e. you process it as any other update but 
treat the contained NLRI as unfeasible.

I was going to write that this is sufficiently clear from the spec, 
but I regret to say that it isn't.  Here is the fourth paragraph of 
section 9:

    The information carried by the AS_PATH attribute is checked for AS
    loops. AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.  If
    the autonomous system number appears in the AS path the route may be
    stored in the Adj-RIB-In, but unless the router is configured to
    accept routes with its own autonomous system in the AS path, the
    route shall not be passed to the BGP Decision Process. Operations of
    a router that is configured to accept routes with its own autonomous
    system number in the AS path are outside the scope of this document.

I don't think this is quite right -- the decision process needs to be 
run if the looped routes had previously been advertised feasibly on 
the same session.  This could be fixed by hacking the quoted 
paragraph, but it seems more straightforward to do it by removing the 
quoted paragraph and making the fix in 9.1.2 Phase 2 instead.  This 
could be done by inserting the following between the third and fourth 
paragraphs of 9.1.2 Phase 2:

    If the AS_PATH attribute of a BGP route contains an AS loop, the
    BGP route should be excluded from the Phase 2 decision function.
    AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.
    Operations of a router that is configured to accept routes with its
    own autonomous system number in the AS path are outside the scope of
    this document.

Section 9.3, first bullet, also addresses this topic, but I don't 
think it's sufficient.

--John

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 02 Dec 2002 08:17:30 -0800

John,

> Section 9.3, first bullet, also addresses this topic, but I don't 

The change you suggested seems reasonable. Will be incorporated
in the next revision.

Yakov.