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

Sorry to be late for this particular party but I think the text still misses the
point; see below.

Tom Petch

----- Original Message -----
From: "Tony Li" <tony.li@tony.li>
To: "Neil Matthew" <neil@abelon.com>
Cc: <idr@ietf.org>
Sent: Tuesday, December 19, 2006 5:58 PM
Subject: Re: [Idr] draft-ietf-as-pathlimit-02

>
> Neil,
>
> > OK, can we agree that the text in section 5.1.6 ATOMIC_AGGREGATE as
> > it appears in RFC 4271 is different to the text found in the same
> > section of RFC 1771?
>
> Of course.
>
> > Further can we agree that section 5.1 of the AS_PATHLIMIT draft
> > refers to the earlier text?
>
> Well, it wasn't meant to.  It was meant to be consistent with both
> 1771 and 4271, but wasn't meant to refer specifically to either.
>
> > From section 5.1 of the AS_PATHLIMIT draft:
> >
> >   "BGP requires that a BGP speaker that advertises a less specific
> >   prefix, but not a more specific prefix that it is using, must
> >   advertise the less specific prefix with the ATOMIC_AGGREGATE
> >   attribute. "
> >
> > This is not what appears in section 5.1.6 of the latest BGP draft
> > but words to this effect do appear in RFC 1771.  This is a tad
> > confusing.
>
> Sorry.
>
> > In the latest BGP RFC the focus is on the node performing the
> > aggregation - this is a controlled point with configured
> > aggregation policy.  This is referred to in the AS_PATHLIMIT draft
> > in the following text (the end of the last paragraph of section 5.1):
> >
> >   To help ensure compliance with this, sites that choose to
> > advertise the
> >   AS_PATHLIMIT path attribute should advertise the ATOMIC_AGGREGATE
> >   attribute on all less specific covering prefixes.
> >
> > Cool.  What concerns me is the bit that comes before:
> >
> >   BGP speakers that do not advertise a more specific prefix
> >   based on the AS_PATHLIMIT must comply with this rule and advertise
> >   the less specific prefixes with the ATOMIC_AGGREGATE attribute.
> >
> > This seems to reference the earlier BGP RFC.  So the idea is that
> > if the originating node 'forgot' to attach the ATOMIC AGGREGATE
> > then it is a 'must' requirement that some later node 'fix' up the
> > situation?  I am concerned this is a non-trivial and processor
> > intensive requirement hence my labouring of the point!  I'd just
> > like clarification.
>
> Got it, thanks for clarifying your concern.
>
>  From my reading of 4271, I'm not sure that you can transfer all
> responsibility to the node that originated the aggregate.  Recall
> Postel's robustness principle: "Be conservative in what you do; be
> liberal in what you accept from others."
>
> This implies that a node other than the originating node that saw
> both the aggregate and the more specific should, in being liberal,
> accept both regardless of ATOMIC_AGGREGATE.  Since that same node can
> (albeit painfully) detect that it has an aggregate without
> ATOMIC_AGGREGATE, it has a responsibility, in being conservative, to
> rectify the situation or at least not propagate the error.
>
> That said, that's all about 4271 and is completely orthogonal to
> AS_PATHLIMIT.  As I said before (and I really meant), I'm not trying
> to change the semantics of 4271.  What I'd like to do then is to
> morph the AS_PATHLIMIT text to address your concern.  Let me propose
> a replacement to the entire paragraph:
>
> 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 ..."

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.

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.

Tom Petch

>
> Tony
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr