Re: IDR WG Last Call

Susan Hares <skh@nexthop.com> Tue, 15 January 2002 23:18 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12399 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 18:18:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 52322912A1; Tue, 15 Jan 2002 18:17:25 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 726E0912A3; Tue, 15 Jan 2002 18:17:23 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADAC6912A1 for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 18:17:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8B1805DDAD; Tue, 15 Jan 2002 18:17:21 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 413D15DDA0 for <idr@merit.edu>; Tue, 15 Jan 2002 18:17:21 -0500 (EST)
Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FNGw302361; Tue, 15 Jan 2002 18:16:59 -0500 (EST) (envelope-from skh@nexthop.com)
Message-Id: <5.0.0.25.0.20020115175015.029288f0@mail.nexthop.com>
X-Sender: skh@mail.nexthop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 15 Jan 2002 18:16:57 -0500
To: Enke Chen <enke@redback.com>
From: Susan Hares <skh@nexthop.com>
Subject: Re: IDR WG Last Call
Cc: idr@merit.edu
In-Reply-To: <20020115214125.47805979C1@popserv2.redback.com>
References: <Message from Susan Hares <skh@nexthop.com> <5.0.0.25.0.20020115163041.02879998@mail.nexthop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NextHop-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk

Sending as well as receiving on the implementations
that I know about.

Ask Dave Thaler and Dory about deployments.

Sue


At 01:41 PM 1/15/2002 -0800, you wrote:
>Sue,
>
> > Date: Tue, 15 Jan 2002 16:32:23 -0500
> > To: Russ White <riw@cisco.com>
> > From: Susan Hares <skh@nexthop.com>
> > Subject: Re: IDR WG Last Call
> > Cc: Enke Chen <enke@redback.com>om>, Susan Hares <skh@nexthop.com>om>,
> >       Jeffrey Haas <jhaas@nexthop.com>om>, idr@merit.edu
> > In-Reply-To: <Pine.GSO.4.21.0201151501420.20905-100000@ruwhite-u10.cisco
> >  .com>
> >
> > I know of at least 2 implementations that do 1,2,3 and
>
>Do we know if "SAFI 3" is used in sending? That would not work without
>the receiver supporting it.
>
>If "SAFI 3" is not used in sending, it seems that it would be safe to
>remove it from the spec..
>
>-- Enke
>
> > I know of at least 2 implementations that do not (1,2 only).
> >
> > Sigh..  Yakov is drafting a change to text to try
> > to address all of these concerns.  I'll await
> > his note.
> >
> > sue
> >
> > At 03:02 PM 1/15/2002 -0500, Russ White wrote:
> >
> > >Correct--SAFI 3.... There aren't any implementations that I've
> > >seen, and it does complicate matters a bit more than needed.
> > >
> > >Russ
> > >
> > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > >
> > > > Sue,
> > > >
> > > > > Date: Tue, 15 Jan 2002 14:49:14 -0500
> > > > > To: Russ White <riw@cisco.com>
> > > > > From: Susan Hares <skh@nexthop.com>
> > > > > Subject: Re: IDR WG Last Call
> > > > > Cc: Enke Chen <enke@redback.com>om>, Jeffrey Haas <jhaas@nexthop.com>om>,
> > > > >     idr@merit.edu
> > > > > In-Reply-To: 
> <Pine.GSO.4.21.0201151303290.20852-100000@ruwhite-u10.cisco
> > > > >  .com>
> > > > > References: <20020115174716.CC5A815D3C1@popserv1.redback.com>
> > > > > Mime-Version: 1.0
> > > > > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > > > > X-NextHop-MailScanner: Found to be clean
> > > > >
> > > > > Russ:
> > > > >
> > > > > We had that vote 1 month ago.  The overwhelming
> > > > > majority was to keep it in. We are not re-opening
> > > > > that issue having closed it on the mail list already.
> > > >
> > > > The issue then was the "BGP State Machine". Russ was talking abut 
> "SAFI 3"
> > > > in his message if I am not mistaken.
> > > >
> > > > -- Enke
> > > >
> > > > >
> > > > >
> > > > > Sue
> > > > >
> > > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> > > > >
> > > > > >I think it's probably a good idea to get rid of this out of the
> > > > > >spec--it would make things cleaner.
> > > > > >
> > > > > >Russ
> > > > > >
> > > > > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > > > > >
> > > > > > > Jeff,
> > > > > > >
> > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > > > > > From: Jeffrey Haas <jhaas@nexthop.com>
> > > > > > > > To: Enke Chen <enke@redback.com>
> > > > > > > > Cc: idr@merit.edu
> > > > > > > > Subject: Re: IDR WG Last Call
> > > > > > > > Message-ID: <20020114232128.B14701@nexthop.com>
> > > > > > > >
> > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand
> > > much more
> > > > > > > > > complicated.
> > > > > > > >
> > > > > > > > IMO, SAFI 3 was probably not a very good idea.  Dealing 
> with it can
> > > > > > > > be a real pain in the implementation. :-)
> > > > > > >
> > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem
> > > to add
> > > > > > > much value, but has caused a lot of confusion and complexity. I
> > > am not
> > > > > > > aware of any depolyment either.
> > > > > > >
> > > > > > > >
> > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > > > > > having one prefix in multiple fields of an update 
> message. How
> > > > > > about the
> > > > > > > > > following text:
> > > > > > > > >
> > > > > > > > >    An UPDATE message should not include the same address
> > > prefix in
> > > > > > more than
> > > > > > > > >    one of the following fields: WITHDRAWN ROUTES field, 
> Network
> > > > > > Reachability
> > > > > > > > >    Information fields, MP_REACH_NLRI field, and 
> MP_UNREACH_NLRI
> > > > > > field. The
> > > > > > > > >    processing of an UPDATE message in this form is 
> un-defined.
> > > > > > > >
> > > > > > > > I think that "undefined" is overkill.  I would suggest the
> > > following
> > > > > > instead:
> > > > > > > >
> > > > > > > > An UPDATE message should not include the same address prefix in
> > > > > > > > more than one of the following fields: WITHDRAWN ROUTES, 
> Network
> > > > > > > > Layer Reachability Information, MP_REACH_NLRI and 
> MP_UNREACH_NLRI.
> > > > > > > > An implementation that receives a packet in this form should
> > > process
> > > > > > > > the Update as if it had processed it in the following order:
> > > > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > > > > > Reachability Information.
> > > > > > > >
> > > > > > > > The wording could probably use some tightening.
> > > > > > > >
> > > > > > > > The intended result is that reachability rules over 
> unreachability.
> > > > > > >
> > > > > > > If we want to define the behavior, I would like to suggest
> > > sticking to
> > > > > > > the order in the message. That probably would reflect the 
> sender's
> > > > > > > intention more closely, and make the processing simpler.
> > > > > > >
> > > > > > > -- Enke
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >_____________________________
> > > > > >riw@cisco.com <>< Grace Alone
> > > > >
> > > > >
> > > >
> > >
> > >_____________________________
> > >riw@cisco.com <>< Grace Alone
> >
> >