Re: IDR WG Last Call

Susan Hares <skh@nexthop.com> Tue, 15 January 2002 01:14 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 UAA03682 for <idr-archive@nic.merit.edu>; Mon, 14 Jan 2002 20:14:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 52B0291235; Mon, 14 Jan 2002 20:13:56 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CAEC91236; Mon, 14 Jan 2002 20:13:56 -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 C98DE91235 for <idr@trapdoor.merit.edu>; Mon, 14 Jan 2002 20:13:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A43975DEE1; Mon, 14 Jan 2002 20:13:54 -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 8661C5DEE0 for <idr@merit.edu>; Mon, 14 Jan 2002 20:13:54 -0500 (EST)
Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0F1DMo62421; Mon, 14 Jan 2002 20:13:22 -0500 (EST) (envelope-from skh@nexthop.com)
Message-Id: <5.0.0.25.0.20020114183752.034a75a8@mail.nexthop.com>
X-Sender: skh@mail.nexthop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 14 Jan 2002 20:13:20 -0500
To: Enke Chen <enke@redback.com>
From: Susan Hares <skh@nexthop.com>
Subject: Re: IDR WG Last Call
Cc: Susan Hares <skh@nexthop.com>, Yakov Rekhter <yakov@juniper.net>, idr@merit.edu, enke@redback.com
In-Reply-To: <20020114221214.3242A15D3C1@popserv1.redback.com>
References: <Message from Susan Hares <skh@nexthop.com> <5.0.0.25.0.20020111135817.028f8d28@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

Enke:

The draft (and RFC) states:

This document defines the following values for the Subsequent Address 
Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI 
attributes: 1 - Network Layer Reachability Information used for unicast 
forwarding
2 - Network Layer Reachability Information used for multicast forwarding
3 - Network Layer Reachability Information used for both unicast
     and multicast forwarding


Is the specification unclear?  If so, please let us know so
the final call can clarify the specifications.

Now as to why/how/when.. I've given my best effort
to answer your query.

          Why, because the operation person configures
                 unicast and multicast topologies are the same.

           How, because the mp-bgp software causes it to go that direction.
                the pim-sm and other multicast protocol utilize the
                 MP bgp routes for SPF.

           When, once upon a router the bgp converges and then
                 the ribs

SAFI 3 ;-)...



Sue Hares


At 02:12 PM 1/14/2002 -0800, Enke Chen wrote:
>Sue:
>In order for me to make sense out of your example, I need to be educated
>on how/why/when one would use "SAFI 3", especially in the context of
>Multi-protocol BGP.
>
>By the "same <AFI, AFI>, I really meant the same <AFI, SAFI>, i.e.,
>identical values.
>
>  -- Enke
>
> > Date: Fri, 11 Jan 2002 18:42:10 -0500
> > To: Enke Chen <enke@redback.com>
> > From: Susan Hares <skh@nexthop.com>
> > Subject: Re: IDR WG Last Call
> > Cc: Susan Hares <skh@nexthop.com>, Yakov Rekhter <yakov@juniper.net>,
> >       idr@merit.edu, enke@redback.com
> > In-Reply-To: <20020111180440.5CB8C7E6C1@popserv3.redback.com>
> > References: <Message from Susan Hares <skh@nexthop.com>
> >  <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com>
> >
> > Enke:
> >
> > It appears I was just too fuzzy in my last email and
> > I assumed something about your last message (oops!!)...
> > We may even be in violent agreement.
> >
> >
> > Let's drop to specifics...
> >
> > Problem 1 in base specification:
> >
> >          1) no ordering of Withdraws and NRLI
> >
> > draft-17 fix:
> >
> >          1) Last ordering (NLRI works) -- good idea
> >
> > Problem 2
> >
> > Order in the packet (by number)
> >          Withdrawl
> >          MP announce
> >          MP release
> >          announce
> >
> > Your solution - last announcement works for an (AFI,SAFI) pair
> >
> > Desired packet information:
> >
> > Previous announcement left us with 128.2/16 with SAFI 2 nexthop 
> 192.168.10.2
> >
> >
> >          ASPATH + community green + next hop 192.168.10.15
> >
> >          Withdraw - nothing
> >          MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2
> >          MPUNREACH - 128.2/16 with SAFI 2
> >          REACH - 128.2 (SAFI = 1 by default)
> >
> > This scenario passes your test.   All things are processed.
> > However, we have a order problem:
> >
> >          1)  If you process the sections as:
> >                  Withdraw,
> >                  MPReach,
> >                  MPUNREACH ,
> >                  Reach
> >
> >                  You get 128.2 (SAFI = 1) with next hop 192.168.10.15.
> >
> >          2) If you process:
> >                  Withdrawa,
> >                  MPUNREACH,
> >                  MPREACH,
> >                  NLRI
> >
> >                  You get 128.2 SAFI 1 next hop 192.168.10.15,
> >                          128.2 SAFI 2 next hop 192.168.10.2
> >
> >
> >
> > Can we set the order with additions of the additions within your
> > text:
> >
> >          MPBGP unreachables before MPBGP reachables.
> >
> > If we have your text plus, the MPUNREACH before MPREACH - we have specific
> > ordering.    If you like these 2 additions, we are done
> >
> >
> > If you implied that SAFI 3 = SAFI 1 + 2, your text does not
> > state it.   The scenario I listed would be illegal.
> >
> > Two summaries:
> >
> > 1) Do you want Your text + ordering of MPBGP unreachables before MP 
> reachables?
> >          If so, let's get yakov to swipe text from the bgp-4 draft 17 
> for this
> >          note.
> >
> >
> > 2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1
> >      can all be listed in the same PDU.
> >
> >
> > you've hit the mark with the need to settle this for the MPBGP protocols.
> >
> > Sue Hares
> >
> >
> >
> >
> >
> > > >
> > > >
> > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> > > > >Hi, Yakov:
> > > > >How about we add the following clarification (similar to the one in
> > > the base
> > > > >BGP spec):
> > > > >
> > > > >    An UPDATE message should not include the same address prefix (of
> > > the same
> > > > >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN
> > > ROUTES
> > > > >    field, Network Reachability Information fields, MP_REACH_NLRI
> > > field, and
> > > > >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to 
> process
> > > > > UPDATE
> > > > >    messages in this form. A BGP speaker should treat an UPDATE
> > > message of
> > > > > this
> > > > >    form as if that the address prefix were included only in the last
> > > field of
> > > > >    the message.
> > > > >
> > > > >Thanks. -- Enke
> > > > >
> > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net>
> > > > > > To: idr@merit.edu
> > > > > > Subject: IDR WG Last Call
> > > > > > MIME-Version: 1.0
> > > > > > Content-Type: text/plain; charset="us-ascii"
> > > > > > Content-ID: <18652.1010626309.1@juniper.net>
> > > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > > > > From: Yakov Rekhter <yakov@juniper.net>
> > > > > > Sender: owner-idr@merit.edu
> > > > > > Precedence: bulk
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > This is to begin the WG Last Call on advancing Multiprotocol
> > > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > > > > Jan 23, 2002.
> > > > > >
> > > > > > Yakov.
> > > > > > ------- Forwarded Message
> > > > > >
> > > > > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > > > > From:    Internet-Drafts@ietf.org
> > > > > > To:      IETF-Announce: ;
> > > > > > cc:      idr@merit.edu
> > > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > > > > >
> > > > > > - --NextPart
> > > > > >
> > > > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > > directories.
> > > > > > This draft is a work item of the Inter-Domain Routing Working 
> Group of
> > > > > the IETF
> > > > > > .
> > > > > >
> > > > > >       Title           : Multiprotocol Extensions for BGP-4
> > > > > >       Author(s)       : T. Bates et al.
> > > > > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > > > > >       Pages           : 10
> > > > > >       Date            : 08-Jan-02
> > > > > >
> > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > > > > enable it to carry routing information for multiple Network Layer
> > > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > > > > compatible - a router that supports the extensions can interoperate
> > > > > > with a router that doesn't support the extensions.
> > > > > >
> > > > > > A URL for this Internet-Draft is:
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > > > > >
> > > > > > To remove yourself from the IETF Announcement list, send a 
> message to
> > > > > > ietf-announce-request with the word unsubscribe in the body of the
> > > message.
> > > > > >
> > > > > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > > > username
> > > > > > "anonymous" and a password of your e-mail address. After 
> logging in,
> > > > > > type "cd internet-drafts" and then
> > > > > >       "get draft-ietf-idr-rfc2858bis-00.txt".
> > > > > >
> > > > > > A list of Internet-Drafts directories can be found in
> > > > > > http://www.ietf.org/shadow.html
> > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > > >
> > > >
> > > >
> >
> >