Subject: draft-walton-bgp-add-paths-01.txt

From: Manav Bhatia <[email-masked]>
Date: Tue, 22 Apr 2003 10:09:23 +0530

Hello,
Some comments on the above stated draft to start with.

1. The length of the Identifier has been kept as 2 octets. Are we
anticipating 2^16 ECMP BGP routes? I think we can use the remaining bits
from the Flags to make our IP prefixes unique. Even if we want some space
reserved for future extensions we don't need to keep 2 octets for making
the
prefix unique!

2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
indicates that the path associated with the NLRI has been selected by the
BGP speaker for installation into its FIB. If set to zero, then the path is
not selected. Why would we ever want to advertise a path which has not been
selected by BGP? If it is to withdraw a previously advertised path then a
better approach would be to send it in the WITHDRAW field.

3. What happens when a router has already advertised some ECMP routes and
it later receives a new ECMP BGP route. How does it advertise this one to
its neighbors? The problem is that it would have advertised its last ECMP
BGP route with the Lastbit set (which indicates that the particular path is
the last one in the UPDATE message for that prefix). To now advertise this
new path does it readvertise all the paths to that prefix OR does it just
advertise the new path information with Bestpath bit set, FirstPath bit
unset and LastBit set/unset (I don't know!)

This seems to be ambiguous in the draft and can be worked upon.

4. The draft does not mention the changes required in the Decision Process.
How does a router decide that the two BGP routes that it has are of the
same cost?

5. The Flags and the Identifier fields have been explained thrice in
sections 2.2.1, 2.2.2. and 2.2.3. I think we can manage with just one.

Regards,
Manav

----
Senior Software Engineer
Samsung India Software Operations
Bangalore - 560 001
+91-80-5550555/6 (1120)

---

From: Daniel Walton <[email-masked]>
Date: Tue, 22 Apr 2003 17:03:19 -0400 (EDT)

On Tue, 22 Apr 2003, Manav Bhatia wrote:

> 1. The length of the Identifier has been kept as 2 octets. Are we anticipating
> 2^16 ECMP BGP routes? I think we can use the remaining bits from the Flags to
> make our IP prefixes unique. Even if we want some space reserved for future
> extensions we don't need to keep 2 octets for making the prefix unique!
>

ack, we'll take a look at this

> better approach would be to send it in the WITHDRAW field.

To solve MED churn, see RFC 3345

> This seems to be ambiguous in the draft and can be worked upon.

Right now the plan is to remove the Lastpath section from the draft.  There are
to many cases where it causes problems.

> How does a router decide that the two BGP routes that it has are of the

hmm, so if a peer advertises me two paths with the same attributes the bestpath
decision needs a way to declare one better than the other since both paths have
the same router-id.  We can add something stating that the add-path ID can be
used as a tie-breaker in this scenario.

> sections 2.2.1, 2.2.2. and 2.2.3. I think we can manage with just one.

This will be cleaned up in the next revision.

Thanks
Daniel

---

From: Mareline Sheldon <[email-masked]>
Date: Wed, 23 Apr 2003 22:56:02 -0700 (PDT)

Dan,

> To solve MED churn, see RFC 3345

How does advertising a path which is not being used by BGP solve the MED churn. I could not
find anything in RFC 3345 which talks of this.

Regards,
Mareline S.

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

---

From: Daniel Walton <[email-masked]>
Date: Thu, 24 Apr 2003 08:41:38 -0400 (EDT)

My bad, I thought we included a section on possible solutions but in the end we
put in "It should be stated that protocol enhancements regarding this problem
must be pursued.  Imposing network design requirements, such as those outlined
above, are clearly an unreasonable long-term solution.  Problems such as this
should not occur under 'default' protocol configurations."

One possible solution for MED churn is to advertise your bestpath per
neighbor-AS in addition to your bestpath.  For the topo in 3.1, Rc and Rd would
need to advertise the AS 200/MED 0 path to Re in order to stop the oscillation.
There is still work to be done to determine when you should/should not advertise
extra paths in order to prevent MED churn but not carry lots of extra paths for
nothing.

Daniel