Re: [Idr] draft-ietf-as-pathlimit-02

[Curtis Villamizar <[e-mail]>]

In message <01e701c725c1$71b74320$0601a8c0@pc6>
"tom.petch" writes:
>  
> No:-( see inline
>  
> Tom Petch


Let me just check on my understanding of ATOMIC_AGGREGATE, legal AS
Path changes, and de-aggregation.  See below.


> ----- Original Message -----
> From: "Tony Li" <[e-mail]>
> To: "tom.petch" <[e-mail]>
> Cc: "Neil Matthew" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, December 20, 2006 10:17 PM
> Subject: Re: [Idr] draft-ietf-as-pathlimit-02
>  
>  
> > Tom,
> >
> > > Sorry to be late for this particular party but I think the text
> > > still misses the
> > > point; see below.
> >
> > Welcome to the party.  Better late than never.  Don't worry, the
> > food's not gone...  ;-)
> >
> > >> To ensure loop prevention, BGP requires that all aggregate routes
> > >> with
> > > truncated
> > >> AS paths be originated with the ATOMIC_AGGREGATE attribute.  To
> > >> help  ensure
> > >> compliance with this, sites that choose to advertise the
> > >> AS_PATHLIMIT path
> > > attribute
> > >> should advertise the ATOMIC_AGGREGATE on all less specific covering
> > >> prefixes.
> > >>
> > >> Does that work for you?
> > >
> > > No!  RFC4271 does NOT talk about truncated AS paths, it says
> > > "  If an aggregate excludes at least some of the AS numbers present in
> > >    the AS_PATH of the routes that are aggregated as a result of
> > > dropping
> > >    the AS_SET ..."
> >
> > So, dropping an AS_SET is one mechanism for truncating the AS_PATH,
> > yes?  It's certainly the most likely one to happen at aggregation
> > time, but you can imagine that there might be a host of other
> > (possibly future) mechanisms that truncate the AS path.
> >
> >
> > > that is, it is not specific to truncation, it is whenever as AS
> > > number is
> > > omitted and the thrust of RFC4271 is that may occur due to an
> > > AS_SET being
> > > omitted.
> > >
> > > Your text is about truncation only and that I think is wrong.
> >
> > I'm trying to think more generally than what 4271 says.  The problem
> > that ATOMIC_AGGREGATE 'fixes' is a combination of truncation of the
> > AS_PATH in conjunction with deaggregation.
> >
> > > So I think you need text along the lines of
> > >
> > > To ensure loop prevention, BGP recommends {SHOULD not MUST} that
> > > when an
> > > aggregated route does not include all the AS numbers that were
> > > present in the
> > > more specific routes, then the ATOMIC_AGGREGATE attribute SHOULD be
> > > present.
> >
> > By the rules on aggregation, shouldn't the only way that AS number
> > might not be present in the aggregate's AS path be due to dropping
> > the AS_SET?  In other words, isn't your text semantically identical
> > to what I proposed?
> >
>  
> I think not.  Truncation in my vocabulary is about lopping off the end so
> 1, 3, (345, 324, 319), 2, 29, 416
> might be truncated to
> 1, 3, (345, 324, 319), 2
> but changing it to
> 1, 3, 345, 2, 29, 416
> does not come within the semantics of truncation.
>  
> So I agree that we should allow for more cases than RFC4271 does but see
> truncation as the wrong word.  Omit, remove, excise, drop, exclude ... lots of
> alternatives but not truncation.



Please excuse me for also joining late and maybe not paying enough
attention to this thread up to now.

My read of RFC4271 concludes:

  1.  De-aggregation MUST NOT be done under any circumstance.

     In 9.1.4:

       With the elimination of IP routing protocols that do not
       support classless routing, and the elimination of router and
       host implementations that do not support classless routing,
       there is no longer a need to de-aggregate.  Routes SHOULD NOT
       be de-aggregated.  In particular, a route that carries the
       ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated.

     Since there hasn't been a classfull host or router sighted in
     nearly 10 years (I had a Cisco IGS in my basement but that got
     recybcled :), this is effectively a MUST NOT.

  2.  The only time it is legal to truncate an AS path is when forming
      an ATOMIC_AGGREGATE.  RFC4271 is not clear about what changes to
      the AS_PATH is legal at this point, just that things can be
      omitted.

  3.  The common procedure for truncating the AS path when forming an
      ATOMIC_AGGREGATE is to drop the whole thing and advertise it out
      with only the AS of the aggregator in the AS Path.

  4.  The only other legal changes to the AS_PATH (besides prepending
      your own AS) are information reduction, forming AS_SET as
      described in 9.2.2.1 and aggregation as described in 9.2.2.2.

Also important but not in RFC4271 (me thinks):

  5.  In practice, forming an ATOMIC_AGGREGATE from a set of routes
      which include one or more that is as specific as the aggregate
      has proven to be potentially harmful.  Maybe this should have
      been noted in RFC4271 but it is not (unless I missed it).

Since the common practice is "drop the whole AS_PATH", leaving some
information on the AS_PATH when forming an ATOMIC_AGGREGATE should be
fine.  I think you'll have the same potential looping problems with or
without AS_PATHLIMIT if you ignore item #5 above.

Now back to the subject line (which is wrong, the draft name is
draft-ietf-idr-as-pathlimit-02.txt, note that the idr is missing).

The draft specifies limiting the scope of the more specific routes.
(Seems like a good idea.  Why all the fuss? :)

In this draft, Section "5.1.  Operations" warns to add
ATOMIC_AGGREGATE when forming an aggregate containing AS_PATHLIMIT.

If an aggregate is formed, limiting the more specific has no adverse
effect in terms of reachability as long as the more specific can reach
the aggregator.

If no aggregate is formed, which might be the case for anycast, then
the scope of the anycast address is limited, which besides information
reduction is the purpse of doing as-pathlimit for anycast.

If an aggregator drops the AS_PATH or any part of it, adds
ATOMIC_AGGREGATE, but does not form a less specific prefix, then a
loop is possible, but that was always the case with or without
AS_PATHLIMIT.

Whether to do creative AS_PATH manipulations and which ones are legal
and/or safe is not directly relevant to the draft (unless as is
sometimes the case and could be again, I'm missing something due to
skimming a long thread without reading every word).  It seems to me
that creative uses of AS_PATHLIMIT and ATOMIC_AGGREGATE and AS_PATH
changes beyond what is described in the draft is interesting but
should be out of scope and better saved for a new "creative uses"
draft to follow if we want to pursue it further.

So should we move forward with this draft, or did I miss something?

Curtis

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