Subject: [GROW] Changing message type codes for BMP

From: "John G. Scudder" <[email-masked]>
Date: Mon, 16 Mar 2009 18:39:38 +0200

Folks,

draft-ietf-grow-bmp-00 Section 2 says:

    o  Message Type (1 byte): This identifies the type of the BMP
       message,

       *  Type = 1: Route Monitoring
       *  Type = 2: Statistics Report
       *  Type = 3: Peer Down Notification

FYI we're planning to revise this to make the message types start at  
zero instead, i.e. it'll be:

       *  Type = 0: Route Monitoring
       *  Type = 1: Statistics Report
       *  Type = 2: Peer Down Notification

This is to bring the draft into line with the implementation.  The  
change will be in the -01 version but we wanted to let the list know  
during the draft posting moratorium, for the benefit of anyone working  
on an implementation.

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Mar 2009 22:05:30 +0200

In addition to what I noted yesterday, we also need to update the  
statistics type codes to start from zero.  -00 says:

    This specification defines the following statistics.  All statistics
    are 4-byte quantities and the stats data are counters.

    o  Stat Type = 1: Number of prefixes rejected by inbound policy.

    o  Stat Type = 2: Number of (known) duplicate prefix advertisements.

    o  Stat Type = 3: Number of (known) duplicate withdraws.

    o  Stat Type = 4: Number of updates invalidated due to CLUSTER_LIST
       loop.

    o  Stat Type = 5: Number of updates invalidated due to AS_PATH loop.

-01 will say:

    o  Stat Type = 0: Number of prefixes rejected by inbound policy.

    o  Stat Type = 1: Number of (known) duplicate prefix advertisements.

    o  Stat Type = 2: Number of (known) duplicate withdraws.

    o  Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST
       loop.

    o  Stat Type = 4: Number of updates invalidated due to AS_PATH loop.

Regards,

--John

---

From: Paul Francis <[email-masked]>
Date: Thu, 26 Mar 2009 19:23:57 +0100

Gang,

I think there was some confusion about VA during the talk today, and I 
wanted to clear some things up:

1.  VA does not require any new hardware.  An "Aggregation Point Router" 
is a normal router that just happens to be an aggregation point for one or 
more virtual prefixes.
2.  No router FIB need carry the entire DFZ.  In our tier-1 ISP study, ALL 
routers saw 10x FIB reduction or more, NO routers saw more than a few 
percent load increase.

The basic trade-off that VA offers to an ISP is whether to change out 
hardware or to increase the amount of config it has to do.  I wouldn't 
want to presuppose that no ISP would prefer to increase config over change 
out hardware.

PF

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Mar 2009 11:57:25 -0700

Hi Paul,

Very good talk ! Thank you.

1.

Your clarification made that AP is just a normal router is perfectly 
valid one. Your VA proposal does two things which may not be very 
obvious ...
  - under the same routing infrastructure (no new investment needed) 
allows to reduce FIB size on the edge routers.
  - In the event where your current routers or subset of them can not 
keep all entries in FIB - instead of fork lift upgrade and just by 
simple configuration divide the address space into chunks and continue 
to operate fine.

2.

Observation made by Yakov that within the POP edge would tunnel to AP 
then it would go back to the same POP can be easily resolved. The proper 
design of such customer POP would be that "local" routes received from 
customers within the POP are present in the FIBs of all edge routers of 
this POP. Only intra-POP routes (Internet routes) would be subject to 
fib aggregation.

3.

As to the point of setting next hop on the Internet ASBRs to self ...
- pro for doing this is not to have additional entires in the IGP - true
- cons for doing this is that you have no _fast_ sub second IGP based 
notification about your peer ASBR or link to peer's ASBR failures to be 
propagated through your IGP domain triggering path switchovers well 
ahead of time of BGP machinery movement. I think if we add another 
benefit of not setting next hop self on ASBRs operators would accept 
this. Besides this is just a local config. I want to point out that the 
VA functionality is not something mandatory :) If operator is willing to 
save $$$ by minor network reconfiguration why not provide him with such 
tool kit ?

If they are willing to regularly keep upgrading their routers they are 
free to spend money after all ....

Cheers,
R.