Subject: RE: issue 10

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 26 Sep 2002 12:35:17 -0400

I agree, what non-conforming implementations do to limit the bad effects of
non-conforming is out of scope.

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Thursday, September 26, 2002 12:16 PM
To: [email-masked]
Cc: Jeffrey Haas; Yakov Rekhter; [email-masked]
Subject: Re: issue 10 

In message <[email-masked]>, Curtis
Villamizar 
writes:
> 
> In message <[email-masked]>, Curtis
Villamiza
> r 
> writes:
> > 
> > In message <[email-masked]>, Jeffrey Haas writes:
> > > 
> > > If I might suggest that although this is the most "valid" 
> > > (for some value judgement of "valid") case for this problem,
> > > implementations may choose for whatever reason to deal with
> > > attribute overflows differently.  For example, if a certain vendor
> > > didn't want to support AS_PATHS over 256 AS's, that's their
> > > prerogative.
> > 
> > I'd call it marginally broken rather than their prerogative.  AS path
> > padding has gotten out of hand but not this bad so it shouldn't be an
> > issue if such a route was dropped, but it is technically wrong unless
> > policy was configured to do so.
> > 
> > Curtis
> 
> 
> Actually the length is one octet so ignore the above.
> 
> Never mind,
> 
> Curtis

But the AS_PATH can have multiple AS_SEQMENTs each with 255 AS ....

In any case, I like Yakov's suggestion to leave the text as is "don't
advertise, if you do truncate somehow its outside the scope of the
spec" (paraphrased).

Curtis

---

From: [email-masked]
Date: Fri, 27 Sep 2002 12:23:14 -0700

Ok, so we are at consensus to add this to 9.2:

    If due to the limits on the maximum size of an UPDATE message
    (see Section 4) a single route doesn't fit into the message,
    the BGP speaker may choose not to advertise the route to its
    peers.

Do we want to:

1) Make any more general statement that "if you can't send all of something
don't send any"?

2) Say something about encoding AS_PATH as multiple segements?

Both of these came up during the discussion, and I'm trying to tie up
loose ends.

Andrew

On Thu, Sep 26, 2002 at 12:35:17PM -0400, Natale, Jonathan wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> From: "Natale, Jonathan" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>,
>    [email-masked]
> Subject: RE: issue 10 
> Date: Thu, 26 Sep 2002 12:35:17 -0400
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Precedence: bulk
> X-OriginalArrivalTime: 26 Sep 2002 16:37:37.0257 (UTC) FILETIME=[05CE1590:01C2657B]
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 29 Sep 2002 22:11:14 -0400

> Both of these came up during the discussion, and I'm trying to tie up

Andrew,

That isn't quite the meaning that we had consensus for.

Wording would be more like:

   If the attributes for a specific prefix becomes too large to fit
   the prefix into the maximum sized BGP UPDATE message, the prefix
   should not be advertised further.  Truncation or ommision of
   attributes should not occur unless policies for such modifications
   are specifically configured.  Such policies may contribute to the
   formation of route loops and are not within the scope of this
   protocol specification.

I couldn't find the existing text so if its already there or if Yakov
suggested something already, then please ignore my suggestion.

btw - Something like not being able to handle an AS path with a
extended size over 255 bytes would be just a bug and we should not
have to change the spec for this.  The practical thing to do is ISPs
configure policy to simply block export of the problem routes and put
pressure on to get the non-conformant routers fixed quickly.

Curtis