as200 aggregates

Gang,

I think the right answer here, which uses existing RIPE-181 syntax,
may be to stick all of these non-propagated more specifics into a
community of some sort (e.g., "COMM_NOPROPAGATE"), and then specify
policy ala

for MCI: export to AS690 (AS200 and NOT COMM_NOPROPAGATE)
for ANS: import from AS3561 (AS200 and NOT COMM_NOPROPAGATE)

This will work within the bounds of existing specification and
code, which supports policy based on community too, correct?  It
should work with netlist filters today (we would generate a list
those things in AS200 *and* not in the silly list), and with real
BGP communities when those are supported.

Steve

(and somebody should stick me on rr-impl at ripe.net, I guess)

------- Forwarded Message

Date:    Thu, 15 Jun 1995 14:40:30 -0400
From:    Selina Priestley <selina>
To:      heimlich at ans.net


- ------- Forwarded Message

  Date:    Thu, 15 Jun 1995 12:52:39 -0400
  From:    Curtis Villamizar <curtis>
  To:      MCI Routing Registry <mci-rr at ns.mci.net>
  Cc:      curtis at ans.net, rr-types at ns.mci.net, rr-impl at ripe.net
  Subject: Re: AS200 aggregate components 

  
  In message <199506151426.KAA16359 at excelsior.reston.mci.net>, MCI Routing Regi
st
  ry writes:
  > 
  > curtis,
  > 
  > actually, we can't withdraw those AS200 components that aren't
  > advertised and don't have advisory attributes.  *we* carry the
  > more specifics in order to do choose the optimal next-hop on our
  > two peering sessions with AS200, but we don't announce them past
  > 3561.  if we withdrew the routes, they wouldn't make our ACLs...
  > 
  > /jws
  
  I knew we'd have to deal with this problem sooner or later.  The
  problem is really that there is no support for this case.
  
  Perhpas as an interim measure we could all agree to use a remark with
  a specific format such as:
  
  remark: next hop resolution only
  
  or
  
  remark: AS3561 next hop resolution only
  
  This would indicate that only a direct peering with AS200, or in the
  second case a direct peering between AS200 and AS3561, would require
  this route.  I'd like to see it also marked "withdrawn" since it is
  announced only between AS200 and AS3561.
  
  Longer term, let's make up a new field.  Perhaps arguments to
  "withdrawn", like:
  
  withdrawn: <who> <date> [ <AS-that-needs-this-for-next-hop>.. ]"
  
  Where the last part is a list of AS numbers.
  
  Curtis
  
  >  * > 
  >  * > One of our tools generates:
  >  * > 
  >  * >   WARNING: 12440 route objects with no AS690 advisory
  >  * > 
  >  * > A lot of these are AS200 components that are not advertised.  These
  >  * > should be marked "withdrawn".  Would you like a list?  If they don't
  >  * > get marked withdrawn, we will be getting a lot of worthless filter
  >  * > components added to our import statements when we move away from
  >  * > advisories.
  >  * > 
  >  * > Curtis

- ------- End of Forwarded Message


------- End of Forwarded Message




-------- Logged at  Fri Jun 16 01:05:58 MET DST 1995  ---------