Last Call: NOPEER community for BGP route scope control to BCP

[Curtis Villamizar]

In message <1036692784.2228.123.camel at riga>, Justin Fletcher writes:
> > The IESG has received a request from the Prefix Taxonomy Ongoing
> > Measurement & Inter Network Experiment Working Group to consider NOPEER
> > community for BGP route scope control
> > <draft-ietf-ptomaine-nopeer-00.txt> as a BCP.
> > 
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg at ietf.org or ietf at ietf.org mailing lists by 2002-11-17.
> 
> I believe this should be considered as an experimental rather than a
> BCP.  It does not document current practice and requires implementation
> by router vendors before it can be adopted into practice.
> 
> Other issues:
> 
> The community field should be previously assigned by IANA and defined in
> the document.
> 
> There's a large motivation section, but no implementation
> section (what do I do with NOPEER if receive it?)

The ISP configures policy (a single statement) based on the NOPEER BGP
community.

What the policy does is not sufficiently specified.

> The paragraph
> 
>   This approach allows an originator of a prefix to attach a commonly
>   defined policy to a route prefix, indicate that a route should be
>   re-advertised conditionally, based on the characteristics of the
>   inter-AS connection.
> 
> does not define the conditions under which a route should be
> re-advertised.  Without such, I don't see a difference between
> NOPEER and NO-ADVERTISE.

The semantics are not defined.

A customer sends NO-ADVERTISE.  A peer sends NOPEER.  I would imagine
that a customer sending NOPEER would go out of the immediate AS
(NOPEER and current AS as the only AS in the path is exported) but no
further.  If this is what is intended the draft doesn't say so.

> There should at least be references to RFC1771 and RFC1997.
> 
> I'd like a clear definition of "bilateral inter-AS peering"
> early in the document.
> 
> Best,
> Justin Fletcher
> Proficient Networks, Inc.

I agree with your comments regarding inadequate specification of
implementation.  This draft has a good motivation but semantics need
to be clearly defined.

It is also not a BCP since it is not a current practice (unless Geoff
is already doing this with his peers, which I doubt).

Curtis