Subject: RE: BGP without an IGP
From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Ken Benstead'" <[email-masked]>, [email-masked]
Date: Thu, 28 Mar 2002 16:36:15 -0500

I think you are assuming that the direct routes advertisement can be
iteratively
done across several BGP hops more than 2. The answer is, by the second hop,
the routes will not go any further, since they will become pure BGP routes
and 
thus have to adhere to the IBGP rules for route propagations.

Hope this thread was helpfull. I have spent enough time with this stuff to
know
better.

BTW: If you are going to have a large AS BGP topology with multi IBGP hops
between
peers, you should consider using clusters of Route Reflectors or 
Confederations (As Pedro mentioned here) if you are really advanturous.

Regards,
Ben

-----Original Message-----
From: Ken Benstead [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 4:19 PM
To: [email-masked]
Subject: FW: BGP without an IGP

Forgot to send this to the list.

> -----Original Message-----
> From: Ken Benstead [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 4:17 PM
> To: Abarbanel, Benjamin
> Subject: RE: BGP without an IGP
> 
> 
> Ben,
> 
> I realized I messed up my example just before your message 
> arrived. I broke the IBGP readvertisment rule. 
> 
> Below is what I should have said. As each peering comes up the 
> routers only advertise their directly connected networks which, I 
> think, does not violate the readvertisement rule. As each set of 
> peerings come up they are able to advertise networks that are one 
> hop further away and thus allow the next set of peerings to come up.
> 
> Ken
> 
> ==================================================================
> ===============
> 
> Assume we have four routers running BGP with IBGP sessions configured
> between them and "next-hop-self" enabled on each session. Each router
> redistributes its directly connected networks into BGP.
>  
>  
>    -----R1---------R2---------R3---------R4-----
>   NET A     NET B      NET C      NET D     NET E
> 
>  
> The configured sessions are:
>  
> 	1-hop: B.R1 - B.R2    C.R2 - C.R3    D.R3 - D.R4
>       2-hop: B.R1 - C.R3    C.R2 - D.R4
> 	3-hop: B.R1 - D.R4
> 
> Initially only the one-hop sessions will come up. Each router 
> will have the following routes.
> 
> 	  R1             R2             R3             R4
>   A via direct   B via direct   C via direct   D via direct
>   B via direct   C via direct   D via direct   E via direct
>   C via B.R2     A via B.R1     B via C.R2     C via D.R3
>                  D via C.R3     E via D.R4
> 
> With these tables the two-hop sessions can come up resulting in a further
> exchange of routes. The result, after route selection, would be:
> 
> 	  R1             R2             R3             R4
>   A via direct   B via direct   C via direct   D via direct
>   B via direct   C via direct   D via direct   E via direct
>   C via B.R2     A via B.R1     B via C.R2     C via D.R3
>   D via C.R3     D via C.R3     E via D.R4     B via C.R2
>                  E via D.R4     A via B.R1 
> 
> Now the three-hop session can come up and exchange routes. You 
> end up with:
> 
> 	  R1             R2             R3             R4
>   A via direct   B via direct   C via direct   D via direct
>   B via direct   C via direct   D via direct   E via direct
>   C via B.R2     A via B.R1     B via C.R2     C via D.R3
>   D via C.R3     D via C.R3     E via D.R4     B via C.R2
>   E via D.R4     E via D.R4     A via B.R1     A via B.R1
> 
> This gives full reachability.
> 
> 
> 
> 
> 

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: FW: BGP without an IGP
Date: Thu, 28 Mar 2002 16:18:45 -0500
Importance: Normal
Sender: [email-masked]

Forgot to send this to the list.

> -----Original Message-----
> From: Ken Benstead [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 4:17 PM
> To: Abarbanel, Benjamin
> Subject: RE: BGP without an IGP
> 
> 
> Ben,
> 
> I realized I messed up my example just before your message 
> arrived. I broke the IBGP readvertisment rule. 
> 
> Below is what I should have said. As each peering comes up the 
> routers only advertise their directly connected networks which, I 
> think, does not violate the readvertisement rule. As each set of 
> peerings come up they are able to advertise networks that are one 
> hop further away and thus allow the next set of peerings to come up.
> 
> Ken
> 
> ==================================================================
> ===============
> 
> Assume we have four routers running BGP with IBGP sessions configured
> between them and "next-hop-self" enabled on each session. Each router
> redistributes its directly connected networks into BGP.
>  
>  
>    -----R1---------R2---------R3---------R4-----
>   NET A     NET B      NET C      NET D     NET E
> 
>  
> The configured sessions are:
>  
> 	1-hop: B.R1 - B.R2    C.R2 - C.R3    D.R3 - D.R4
>       2-hop: B.R1 - C.R3    C.R2 - D.R4
> 	3-hop: B.R1 - D.R4
> 
> Initially only the one-hop sessions will come up. Each router 
> will have the following routes.
> 
> 	  R1             R2             R3             R4
>   A via direct   B via direct   C via direct   D via direct
>   B via direct   C via direct   D via direct   E via direct
>   C via B.R2     A via B.R1     B via C.R2     C via D.R3
>                  D via C.R3     E via D.R4
> 
> With these tables the two-hop sessions can come up resulting in a further
> exchange of routes. The result, after route selection, would be:
> 
> 	  R1             R2             R3             R4
>   A via direct   B via direct   C via direct   D via direct
>   B via direct   C via direct   D via direct   E via direct
>   C via B.R2     A via B.R1     B via C.R2     C via D.R3
>   D via C.R3     D via C.R3     E via D.R4     B via C.R2
>                  E via D.R4     A via B.R1 
> 
> Now the three-hop session can come up and exchange routes. You 
> end up with:
> 
> 	  R1             R2             R3             R4
>   A via direct   B via direct   C via direct   D via direct
>   B via direct   C via direct   D via direct   E via direct
>   C via B.R2     A via B.R1     B via C.R2     C via D.R3
>   D via C.R3     D via C.R3     E via D.R4     B via C.R2
>   E via D.R4     E via D.R4     A via B.R1     A via B.R1
> 
> This gives full reachability.
> 
> 
> 
> 
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Ken Benstead'" <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 15:55:54 -0500
Sender: [email-masked]

Ken:

Response below.

Ben

-----Original Message-----
From: Ken Benstead [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 3:45 PM
To: [email-masked]
Subject: RE: BGP without an IGP

Ben,
Sorry to take so long in replying.

I was thinking of your Case 2. Here's how I think it would work.

Assume we have four routers running BGP with IBGP sessions configured
between them and "next-hop-self" enabled on each session. Each router
redistributes its directly connected networks into BGP.

   -----R1---------R2---------R3---------R4-----
  NET A     NET B      NET C      NET D     NET E

The configured sessions are:

	1-hop: B.R1 - B.R2    C.R2 - C.R3    D.R3 - D.R4
      2-hop: B.R1 - C.R3    C.R2 - D.R4
	3-hop: B.R1 - D.R4

Initially only the one-hop sessions will come up. Each router will have the
following routes.

	  R1             R2             R3             R4
  A via direct   B via direct   C via direct   D via direct
  B via direct   C via direct   D via direct   E via direct
  C via B.R2     A via B.R1     B via C.R2     C via D.R3
                 D via C.R3     E via D.R4

With these tables the two-hop sessions can come up resulting in a further
exchange of routes. The result, after route selection, would be:

	  R1             R2             R3             R4
  A via direct   B via direct   C via direct   D via direct
  B via direct   C via direct   D via direct   E via direct
  C via B.R2     A via B.R1     B via C.R2     C via D.R3
  D via C.R3     D via C.R3     E via D.R4     A via C.R2
  E via C.R3     E via D.R4     A via B.R1     B via C.R2

>> I dont think that R1 can see R3's routes (NET D or E), 
>> because R2 will not be allowed to propagate R3's (IBGP ) routes to
another
>> IBGP peer namely R1. This also symmetrically applies to R4 seeing Net A
and B.
>> If you have 2 or less hops you can get away without
>> breaking the IBGP rule. Especially if all routes
>> being propagated are direct connect routes redistributed to BGP.
>> Because of the third hop, is why you need IGP or static routes in R1 and
R4.
>> IMHO.

>> Ben

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Abarbanel, Benjamin
> Sent: Thursday, March 28, 2002 12:04 PM
> To: 'Ken Benstead'; [email-masked]
> Subject: RE: BGP without an IGP
>
>
> Ken,
>
> I dont see how a 1 hop IBGP peering can propagate addresses that are
> multi-hop away
> with BGP protocol.
>
> example:
> --------
>
> Case 1:
>     R1 --- I1 --- I2 --- R3
>
>     if R1 and R3 are IBGP routers and I1 and I2 are not. There is
> no way for
> R1 to setup a TCP call to R3 without a static route in R1 and R3.
>
> Case 2:
>        IBGP   IBGP   IBGP
>     R1 --- I1 --- I2 --- R3
>
> If I1 and I2 are IBGP routers they cannot prapagate routes
> learned from IBGP
> routers
> to other IBGP routers unless they are route reflectors, by BGP
> RFC rules. So
> again
> you have no reachability between R1 and R2. If you are talking of this,
>
> Case 3:
>
>    R1 --- I1(RR) --- I2(RR) --- R2
>
>    I1 and I2 are IBGP route reflectors.
>
>    Then yes, you would not need static routes to make it work.
>
> Regards,
> Ben
>
> Ben
>
> -----Original Message-----
> From: Ken Benstead [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 11:56 AM
> To: [email-masked]
> Subject: RE: BGP without an IGP
>
>
> Hi Ben,
>
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[email-masked]]
> > Sent: Thursday, March 28, 2002 11:14 AM
> > To: 'Ken Benstead'; [email-masked]
> > Subject: RE: BGP without an IGP
> >
> >
> > Ken:
> >
> > You missed one important point.
> >
> > You need an IGP or equivalent next hop route in each IBGP
> router, in order
> > to setup a IBGP connection that spans more than two adjacent
> routers. The
> > only other route that can do this other than an IGP route is a
> > static route.
> > So your IBGP routers must all have static routes to establish the IBGP
> > peering.
>
> That's what I thought too but, if you work through a scenario,
> what happens
> is that first only the one-hop peerings come up. Those peerings
> allow routes
> to the networks that are two hops away to be exchanged which, in
> turn, allow
> the two-hop peerings to come up. The two-hop peerings exchange routes that
> are three-hops away and so on. Its a bootstrapping process that
> requires BGP
> intermediate next-hops be resolved into BGP routes. That part seems to be
> illegal given the responses so far.
>
> >
> > Also, are you going to filter 100,000 routes from entering the
> forwarding
> > table of each IBGP router and use default routes for IBGP
> routers that are
> > not Border AS routers? I am thinking of route reflectors in the
> > core of your
> > AS.
> >
>
> I haven't thought through the consequences yet. That's one of the
> reasons I
> asked the question.
>
> > Ben
> >
>
> Ken
> > -----Original Message-----
> > From: Ken Benstead [mailto:[email-masked]]
> > Sent: Thursday, March 28, 2002 9:23 AM
> > To: [email-masked]
> > Subject: BGP without an IGP
> >
> >
> > Hi Folks,
> >
> > It seems that BGP might be able to operate within an AS without an
> > underlying IGP, (or static routes), if the following conditions
> are true:
> >
> > 1) BGP is present in every router.
> > 2) The routers are in a full-mesh, or equivalent.
> > 3) Loopback addresses are not used for BGP sessions.
> > 4) Each IBGP peer forces the Next-Hop attribute to be its own
> > address, e.g.
> > Cisco's "next-hop-self" command.  (This is non-standard
> behavior but seems
> > to be a common extension.)
> > 5) The resolved next-hop of a BGP route is allowed to be another
> > BGP route.
> > (The standard, RFC and draft, seems to allow this.)
> >
> > I have only tried this on paper but it seems like it would work. So, my
> > question is, "did I miss something or is this a well-known
> > technique"? If it
> > a well-known technique then:
> >
> > 1) What are its advantages?
> > 2) What are its disadvantages?
> > 3) Does anyone actually deploy BGP this way?
> >
> > Thanks,
> > Ken Benstead

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 15:45:16 -0500
Importance: Normal
Sender: [email-masked]

Ben,
Sorry to take so long in replying.

I was thinking of your Case 2. Here's how I think it would work.

Assume we have four routers running BGP with IBGP sessions configured
between them and "next-hop-self" enabled on each session. Each router
redistributes its directly connected networks into BGP.

   -----R1---------R2---------R3---------R4-----
  NET A     NET B      NET C      NET D     NET E

The configured sessions are:

	1-hop: B.R1 - B.R2    C.R2 - C.R3    D.R3 - D.R4
      2-hop: B.R1 - C.R3    C.R2 - D.R4
	3-hop: B.R1 - D.R4

Initially only the one-hop sessions will come up. Each router will have the
following routes.

	  R1             R2             R3             R4
  A via direct   B via direct   C via direct   D via direct
  B via direct   C via direct   D via direct   E via direct
  C via B.R2     A via B.R1     B via C.R2     C via D.R3
                 D via C.R3     E via D.R4

With these tables the two-hop sessions can come up resulting in a further
exchange of routes. The result, after route selection, would be:

	  R1             R2             R3             R4
  A via direct   B via direct   C via direct   D via direct
  B via direct   C via direct   D via direct   E via direct
  C via B.R2     A via B.R1     B via C.R2     C via D.R3
  D via C.R3     D via C.R3     E via D.R4     A via C.R2
  E via C.R3     E via D.R4     A via B.R1     B via C.R2

Now the three-hop session can come up and exchange routes although, as all
routers already have full reachabiity, it doesn't add much to the picture
until some EBGP routes arrive at R1 or R4.

What do you think?

Ken

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Abarbanel, Benjamin
> Sent: Thursday, March 28, 2002 12:04 PM
> To: 'Ken Benstead'; [email-masked]
> Subject: RE: BGP without an IGP
>
>
> Ken,
>
> I dont see how a 1 hop IBGP peering can propagate addresses that are
> multi-hop away
> with BGP protocol.
>
> example:
> --------
>
> Case 1:
>     R1 --- I1 --- I2 --- R3
>
>     if R1 and R3 are IBGP routers and I1 and I2 are not. There is
> no way for
> R1 to setup a TCP call to R3 without a static route in R1 and R3.
>
> Case 2:
>        IBGP   IBGP   IBGP
>     R1 --- I1 --- I2 --- R3
>
> If I1 and I2 are IBGP routers they cannot prapagate routes
> learned from IBGP
> routers
> to other IBGP routers unless they are route reflectors, by BGP
> RFC rules. So
> again
> you have no reachability between R1 and R2. If you are talking of this,
>
> Case 3:
>
>    R1 --- I1(RR) --- I2(RR) --- R2
>
>    I1 and I2 are IBGP route reflectors.
>
>    Then yes, you would not need static routes to make it work.
>
> Regards,
> Ben
>
> Ben
>
> -----Original Message-----
> From: Ken Benstead [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 11:56 AM
> To: [email-masked]
> Subject: RE: BGP without an IGP
>
>
> Hi Ben,
>
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[email-masked]]
> > Sent: Thursday, March 28, 2002 11:14 AM
> > To: 'Ken Benstead'; [email-masked]
> > Subject: RE: BGP without an IGP
> >
> >
> > Ken:
> >
> > You missed one important point.
> >
> > You need an IGP or equivalent next hop route in each IBGP
> router, in order
> > to setup a IBGP connection that spans more than two adjacent
> routers. The
> > only other route that can do this other than an IGP route is a
> > static route.
> > So your IBGP routers must all have static routes to establish the IBGP
> > peering.
>
> That's what I thought too but, if you work through a scenario,
> what happens
> is that first only the one-hop peerings come up. Those peerings
> allow routes
> to the networks that are two hops away to be exchanged which, in
> turn, allow
> the two-hop peerings to come up. The two-hop peerings exchange routes that
> are three-hops away and so on. Its a bootstrapping process that
> requires BGP
> intermediate next-hops be resolved into BGP routes. That part seems to be
> illegal given the responses so far.
>
> >
> > Also, are you going to filter 100,000 routes from entering the
> forwarding
> > table of each IBGP router and use default routes for IBGP
> routers that are
> > not Border AS routers? I am thinking of route reflectors in the
> > core of your
> > AS.
> >
>
> I haven't thought through the consequences yet. That's one of the
> reasons I
> asked the question.
>
> > Ben
> >
>
> Ken
> > -----Original Message-----
> > From: Ken Benstead [mailto:[email-masked]]
> > Sent: Thursday, March 28, 2002 9:23 AM
> > To: [email-masked]
> > Subject: BGP without an IGP
> >
> >
> > Hi Folks,
> >
> > It seems that BGP might be able to operate within an AS without an
> > underlying IGP, (or static routes), if the following conditions
> are true:
> >
> > 1) BGP is present in every router.
> > 2) The routers are in a full-mesh, or equivalent.
> > 3) Loopback addresses are not used for BGP sessions.
> > 4) Each IBGP peer forces the Next-Hop attribute to be its own
> > address, e.g.
> > Cisco's "next-hop-self" command.  (This is non-standard
> behavior but seems
> > to be a common extension.)
> > 5) The resolved next-hop of a BGP route is allowed to be another
> > BGP route.
> > (The standard, RFC and draft, seems to allow this.)
> >
> > I have only tried this on paper but it seems like it would work. So, my
> > question is, "did I miss something or is this a well-known
> > technique"? If it
> > a well-known technique then:
> >
> > 1) What are its advantages?
> > 2) What are its disadvantages?
> > 3) Does anyone actually deploy BGP this way?
> >
> > Thanks,
> > Ken Benstead

From: Randy Bush <[email-masked]>
To: "Martin, Christian" <[email-masked]>
Cc: "'Russ White'" <[email-masked]>, Ken Benstead <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 12:22:43 -0800
Sender: [email-masked]

> A BGP route can be resolved via another BGP route, so long as there is
> a recursion to a non-BGP route as the next-hop.

and, to carry it to one extreme, that latter might be a directly
connected interface.

randy

From: "Martin, Christian" <[email-masked]>
To: "'Russ White'" <[email-masked]>, Ken Benstead <[email-masked]>
Cc: [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 15:02:14 -0500
Sender: [email-masked]

A BGP route can be resolved via another BGP route, so long as there is a
recursion to a non-BGP route as the next-hop.

They can't be all BGP.  This causes a race-condition.

chris

> -----Original Message-----
> From: Russ White [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 9:28 AM
> To: Ken Benstead
> Cc: [email-masked]
> Subject: Re: BGP without an IGP
> 
> 
> 
> > 5) The resolved next-hop of a BGP route is allowed to be
> another BGP
> > route. (The standard, RFC and draft, seems to allow this.)
> 
> But I don't know that implementations allow this. Cisco doesn't.
> 
> :-)
> 
> Russ
> 
> 
> __________________________________
> [email-masked] CCIE <>< Grace Alone
> 
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Pedro Roque Marques'" <[email-masked]>, Russ White <[email-masked]>
Cc: Ken Benstead <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 13:57:24 -0500
Sender: [email-masked]

Pedro:
Oh boy, now we are talking about Confederations. That was a can of worms i
did 
not want to open. 

Ben

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 1:50 PM
To: Russ White
Cc: Ken Benstead; [email-masked]
Subject: Re: BGP without an IGP

Russ White writes:

> Okay--I just checked.... it looks like we do support this, though
> there are some issues with recursion. It isn't well known, and I
> don't think anyone would actually recommend it, at least partially
> due to the convergence times involved in ibgp.

Russ,
Do you want to imply that people should not use BGP confederations
with cisco routers or vice-versa ;-) ?

  Pedro.

[just pulling your leg]

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Randy Bush'" <[email-masked]>, "Abarbanel, Benjamin" <[email-masked]>
Cc: Russ White <[email-masked]>, Ken Benstead <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 13:54:01 -0500
Sender: [email-masked]

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 1:51 PM
To: Abarbanel, Benjamin
Cc: Russ White; Ken Benstead; [email-masked]
Subject: RE: BGP without an IGP

> How can one IBGP router advertise routes learned from a second IBGP router
> to another IBGP Peer?

they don't.  period.

>>> Therefore he has no reachability across the AS without IGP or Static
routes.

>>> Ben

From: Randy Bush <[email-masked]>
To: "Abarbanel, Benjamin" <[email-masked]>
Cc: Russ White <[email-masked]>, Ken Benstead <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 10:50:35 -0800
Sender: [email-masked]

> How can one IBGP router advertise routes learned from a second IBGP router
> to another IBGP Peer?

they don't.  period.

randy

Date: Thu, 28 Mar 2002 10:50:17 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Russ White <[email-masked]>
Cc: Ken Benstead <[email-masked]>, [email-masked]
Subject: Re: BGP without an IGP
Sender: [email-masked]

Russ White writes:

> Okay--I just checked.... it looks like we do support this, though
> there are some issues with recursion. It isn't well known, and I
> don't think anyone would actually recommend it, at least partially
> due to the convergence times involved in ibgp.

Russ,
Do you want to imply that people should not use BGP confederations
with cisco routers or vice-versa ;-) ?

  Pedro.

[just pulling your leg]

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Randy Bush'" <[email-masked]>, Russ White <[email-masked]>
Cc: Ken Benstead <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 13:40:51 -0500
Sender: [email-masked]

I think you guys are missing my point. Next Hop Self works for EBGP routes
injected 
into the AS as IBGP routes. But from what I understood Ken original topology
he was
only talking about reachability within the AS. Reachability between IBGP
peers that
are more than 1 hop away. 

How can one IBGP router advertise routes learned from a second IBGP router
to another 
IBGP Peer? Which is what I think is going on here?

Ben

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 1:32 PM
To: Russ White
Cc: Ken Benstead; [email-masked]
Subject: Re: BGP without an IGP

>>> 5) The resolved next-hop of a BGP route is allowed to be
>>> another BGP route. (The standard, RFC and draft, seems to
>>> allow this.)
> Okay--I just checked.... it looks like we do support this

that's good, or much of the operational internet would be broken
today and you would not be getting this message

randy

From: Randy Bush <[email-masked]>
To: Russ White <[email-masked]>
Cc: Ken Benstead <[email-masked]>, [email-masked]
Subject: Re: BGP without an IGP
Date: Thu, 28 Mar 2002 10:31:53 -0800
Sender: [email-masked]

>>> 5) The resolved next-hop of a BGP route is allowed to be
>>> another BGP route. (The standard, RFC and draft, seems to
>>> allow this.)
> Okay--I just checked.... it looks like we do support this

that's good, or much of the operational internet would be broken
today and you would not be getting this message

randy

Date: Thu, 28 Mar 2002 12:59:17 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Ken Benstead <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP without an IGP
Sender: [email-masked]

Okay--I just checked.... it looks like we do support this, though
there are some issues with recursion. It isn't well known, and I
don't think anyone would actually recommend it, at least
partially due to the convergence times involved in ibgp. 

:-)

Russ

On Thu, 28 Mar 2002, Russ White wrote:

> 
> > 5) The resolved next-hop of a BGP route is allowed to be
> > another BGP route. (The standard, RFC and draft, seems to
> > allow this.)
> 
> But I don't know that implementations allow this. Cisco doesn't.
> 
> :-)
> 
> Russ
> 
> 
> __________________________________
> [email-masked] CCIE <>< Grace Alone
> 
> 
> 

__________________________________
[email-masked] CCIE <>< Grace Alone

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Ken Benstead'" <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 12:04:04 -0500
Sender: [email-masked]

Ken,

I dont see how a 1 hop IBGP peering can propagate addresses that are
multi-hop away
with BGP protocol.

example:
--------
       
Case 1:
    R1 --- I1 --- I2 --- R3

    if R1 and R3 are IBGP routers and I1 and I2 are not. There is no way for
R1 to setup a TCP call to R3 without a static route in R1 and R3. 

Case 2:
       IBGP   IBGP   IBGP
    R1 --- I1 --- I2 --- R3

If I1 and I2 are IBGP routers they cannot prapagate routes learned from IBGP
routers
to other IBGP routers unless they are route reflectors, by BGP RFC rules. So
again
you have no reachability between R1 and R2. If you are talking of this, 

Case 3:

   R1 --- I1(RR) --- I2(RR) --- R2

   I1 and I2 are IBGP route reflectors.

   Then yes, you would not need static routes to make it work.

Regards,
Ben

Ben

-----Original Message-----
From: Ken Benstead [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 11:56 AM
To: [email-masked]
Subject: RE: BGP without an IGP

Hi Ben,

> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 11:14 AM
> To: 'Ken Benstead'; [email-masked]
> Subject: RE: BGP without an IGP
>
>
> Ken:
>
> You missed one important point.
>
> You need an IGP or equivalent next hop route in each IBGP router, in order
> to setup a IBGP connection that spans more than two adjacent routers. The
> only other route that can do this other than an IGP route is a
> static route.
> So your IBGP routers must all have static routes to establish the IBGP
> peering.

That's what I thought too but, if you work through a scenario, what happens
is that first only the one-hop peerings come up. Those peerings allow routes
to the networks that are two hops away to be exchanged which, in turn, allow
the two-hop peerings to come up. The two-hop peerings exchange routes that
are three-hops away and so on. Its a bootstrapping process that requires BGP
intermediate next-hops be resolved into BGP routes. That part seems to be
illegal given the responses so far.

>
> Also, are you going to filter 100,000 routes from entering the forwarding
> table of each IBGP router and use default routes for IBGP routers that are
> not Border AS routers? I am thinking of route reflectors in the
> core of your
> AS.
>

I haven't thought through the consequences yet. That's one of the reasons I
asked the question.

> Ben
>

Ken
> -----Original Message-----
> From: Ken Benstead [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 9:23 AM
> To: [email-masked]
> Subject: BGP without an IGP
>
>
> Hi Folks,
>
> It seems that BGP might be able to operate within an AS without an
> underlying IGP, (or static routes), if the following conditions are true:
>
> 1) BGP is present in every router.
> 2) The routers are in a full-mesh, or equivalent.
> 3) Loopback addresses are not used for BGP sessions.
> 4) Each IBGP peer forces the Next-Hop attribute to be its own
> address, e.g.
> Cisco's "next-hop-self" command.  (This is non-standard behavior but seems
> to be a common extension.)
> 5) The resolved next-hop of a BGP route is allowed to be another
> BGP route.
> (The standard, RFC and draft, seems to allow this.)
>
> I have only tried this on paper but it seems like it would work. So, my
> question is, "did I miss something or is this a well-known
> technique"? If it
> a well-known technique then:
>
> 1) What are its advantages?
> 2) What are its disadvantages?
> 3) Does anyone actually deploy BGP this way?
>
> Thanks,
> Ken Benstead

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 11:56:08 -0500
Importance: Normal
Sender: [email-masked]

Hi Ben,

> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 11:14 AM
> To: 'Ken Benstead'; [email-masked]
> Subject: RE: BGP without an IGP
>
>
> Ken:
>
> You missed one important point.
>
> You need an IGP or equivalent next hop route in each IBGP router, in order
> to setup a IBGP connection that spans more than two adjacent routers. The
> only other route that can do this other than an IGP route is a
> static route.
> So your IBGP routers must all have static routes to establish the IBGP
> peering.

That's what I thought too but, if you work through a scenario, what happens
is that first only the one-hop peerings come up. Those peerings allow routes
to the networks that are two hops away to be exchanged which, in turn, allow
the two-hop peerings to come up. The two-hop peerings exchange routes that
are three-hops away and so on. Its a bootstrapping process that requires BGP
intermediate next-hops be resolved into BGP routes. That part seems to be
illegal given the responses so far.

>
> Also, are you going to filter 100,000 routes from entering the forwarding
> table of each IBGP router and use default routes for IBGP routers that are
> not Border AS routers? I am thinking of route reflectors in the
> core of your
> AS.
>

I haven't thought through the consequences yet. That's one of the reasons I
asked the question.

> Ben
>

Ken
> -----Original Message-----
> From: Ken Benstead [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 9:23 AM
> To: [email-masked]
> Subject: BGP without an IGP
>
>
> Hi Folks,
>
> It seems that BGP might be able to operate within an AS without an
> underlying IGP, (or static routes), if the following conditions are true:
>
> 1) BGP is present in every router.
> 2) The routers are in a full-mesh, or equivalent.
> 3) Loopback addresses are not used for BGP sessions.
> 4) Each IBGP peer forces the Next-Hop attribute to be its own
> address, e.g.
> Cisco's "next-hop-self" command.  (This is non-standard behavior but seems
> to be a common extension.)
> 5) The resolved next-hop of a BGP route is allowed to be another
> BGP route.
> (The standard, RFC and draft, seems to allow this.)
>
> I have only tried this on paper but it seems like it would work. So, my
> question is, "did I miss something or is this a well-known
> technique"? If it
> a well-known technique then:
>
> 1) What are its advantages?
> 2) What are its disadvantages?
> 3) Does anyone actually deploy BGP this way?
>
> Thanks,
> Ken Benstead

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Ken Benstead'" <[email-masked]>, [email-masked]
Subject: RE: BGP without an IGP
Date: Thu, 28 Mar 2002 11:13:54 -0500
Sender: [email-masked]

Ken:

You missed one important point.

You need an IGP or equivalent next hop route in each IBGP router, in order
to setup a IBGP connection that spans more than two adjacent routers. The
only other route that can do this other than an IGP route is a static route.
So your IBGP routers must all have static routes to establish the IBGP
peering. 

Also, are you going to filter 100,000 routes from entering the forwarding
table of each IBGP router and use default routes for IBGP routers that are
not Border AS routers? I am thinking of route reflectors in the core of your
AS.

Ben

-----Original Message-----
From: Ken Benstead [mailto:[email-masked]]
Sent: Thursday, March 28, 2002 9:23 AM
To: [email-masked]
Subject: BGP without an IGP

Hi Folks,

It seems that BGP might be able to operate within an AS without an
underlying IGP, (or static routes), if the following conditions are true:

1) BGP is present in every router.
2) The routers are in a full-mesh, or equivalent.
3) Loopback addresses are not used for BGP sessions.
4) Each IBGP peer forces the Next-Hop attribute to be its own address, e.g.
Cisco's "next-hop-self" command.  (This is non-standard behavior but seems
to be a common extension.)
5) The resolved next-hop of a BGP route is allowed to be another BGP route.
(The standard, RFC and draft, seems to allow this.)

I have only tried this on paper but it seems like it would work. So, my
question is, "did I miss something or is this a well-known technique"? If it
a well-known technique then:

1) What are its advantages?
2) What are its disadvantages?
3) Does anyone actually deploy BGP this way?

Thanks,
Ken Benstead

Date: Thu, 28 Mar 2002 07:56:01 -0800 (PST)
From: Anand Bapat <[email-masked]>
Subject: exporting direct routes into BGP
To: [email-masked]
Sender: [email-masked]

--0-707380820-1017330961=:40048
Content-Type: text/plain; charset=us-ascii

All,  I have following configuration:     |  --R1 -- EBGP -- R2     |R1 has other direct connected routes as well. I havea export policy to export direct routes into BGP.

Question#1:What should I see at R2's BGP route table ( I mean should I see/32 address or /24 address at R2 ? ).

Question#2:

If I have a configured loopback address at R1 

( I mean a loopback address other than 127.0.0.1 )

and I have a policy to export direct routes into BGP

what should I see at R2 ( /32 or /24 address )Example:-------------At R1 I have following direct routes153.151.1.1/32155.153.1.1/32  <--- This will not be sent to R2 bacause it isdirectly connected to R2.

1.2.3.4/32 configured as loopback address at R1.

( this will be treated as direct route )At R1, I have a policy to export direct routes into

BGP.

Question:

What should I expect in R2's BGP route table?

153.151.1.1/32, 153.151.1.0/24, 1.2.3.4/32, 1.2.3.0/24OR only

153.151.1.1/32, 1.2.3.4/32

OR 

153.151.1.0/24, 1.2.3.0/24Thanks in advanceab

If yo are not working in US, you are missing something..
   -- Old Geek Saying..

---------------------------------
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
--0-707380820-1017330961=:40048
Content-Type: text/html; charset=us-ascii

<PRE>All,
  I have following configuration:
     |
  --R1 -- EBGP -- R2
     |
R1 has other direct connected routes as well. I have
a export policy to export direct routes into BGP.</PRE><PRE>
Question#1:
What should I see at R2's BGP route table ( I mean should I see
/32 address or /24 address at R2 ? ).</PRE><PRE>Question#2:</PRE><PRE>If I have a configured loopback address at R1 </PRE><PRE>( I mean a loopback address other than 127.0.0.1 )</PRE><PRE>and I have a policy to export direct routes into BGP</PRE><PRE>what should I see at R2 ( /32 or /24 address )

Example:
-------------
At R1 I have following direct routes

153.151.1.1/32
155.153.1.1/32  &lt;--- This will not be sent to R2 bacause it is
directly connected to R2.</PRE><PRE>1.2.3.4/32 configured as loopback address at R1.</PRE><PRE>( this will be treated as direct route )

At R1, I have a policy to export direct routes into</PRE><PRE>BGP.</PRE><PRE>Question:</PRE><PRE>What should I expect in R2's BGP route table?</PRE><PRE>153.151.1.1/32, 153.151.1.0/24, 1.2.3.4/32, 1.2.3.0/24

OR only</PRE><PRE>153.151.1.1/32, 1.2.3.4/32</PRE><PRE>OR </PRE><PRE>153.151.1.0/24, 1.2.3.0/24

Thanks in advance

ab</PRE><BR><BR>If yo are not working in US, you are missing something..<br>   -- Old Geek Saying..<p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="$rd_url/tag/http://movies.yahoo.com/">Yahoo! Movies</a> - coverage of the 74th Academy Awards®
--0-707380820-1017330961=:40048--

Date: Thu, 28 Mar 2002 09:27:36 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Ken Benstead <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP without an IGP
Sender: [email-masked]

> 5) The resolved next-hop of a BGP route is allowed to be
> another BGP route. (The standard, RFC and draft, seems to
> allow this.)

But I don't know that implementations allow this. Cisco doesn't.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: BGP without an IGP
Date: Thu, 28 Mar 2002 09:23:16 -0500
Importance: Normal
Sender: [email-masked]

Hi Folks,

It seems that BGP might be able to operate within an AS without an
underlying IGP, (or static routes), if the following conditions are true:

1) BGP is present in every router.
2) The routers are in a full-mesh, or equivalent.
3) Loopback addresses are not used for BGP sessions.
4) Each IBGP peer forces the Next-Hop attribute to be its own address, e.g.
Cisco's "next-hop-self" command.  (This is non-standard behavior but seems
to be a common extension.)
5) The resolved next-hop of a BGP route is allowed to be another BGP route.
(The standard, RFC and draft, seems to allow this.)

I have only tried this on paper but it seems like it would work. So, my
question is, "did I miss something or is this a well-known technique"? If it
a well-known technique then:

1) What are its advantages?
2) What are its disadvantages?
3) Does anyone actually deploy BGP this way?

Thanks,
Ken Benstead

Date: Wed, 27 Mar 2002 12:05:31 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: 2842
Sender: [email-masked]

Makes perfect sense.

Alex

Wednesday, March 27, 2002, 8:46:49 AM, Jeffrey Haas wrote:
> To be fair, zero-length shouldn't be the bugaboo.  It should be
> multiple capabilities with the same code _and the same data_.
> The zero-length case is just one example of this.

Date: Wed, 27 Mar 2002 11:55:31 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: V1 MIB issue - ATOMIC_AGGREGATE
Sender: [email-masked]

Folks,

We really need to nail this one to move this through last call.

In the v1 MIB, we have this object:

:bgp4PathAttrAtomicAggregate OBJECT-TYPE
:    SYNTAX     INTEGER {
:       lessSpecificRouteNotSelected(1),
:       lessSpecificRouteSelected(2)
:   }
:[...]
:    DESCRIPTION
:	"Whether or not a system has selected
:	 a less specific route without
:	 selecting a more specific route."

Please note two things:
1. The names are misleading.  In the RFC 1771 context, we talk about
   a less specific being selected when a more specific is NOT.
   Yet the names imply its the less specific being selected.
2. The criteria in the current draft of BGP for setting atomic 
   aggreate don't ONLY include the less specific and more specific
   test.

Our MIB advisors have told us we can't change the names of the
enumerations.  However, we can add as much clarifying text as we
want.  I would like to request the following things:

1. How does your implementation set this value when ATOMIC_AGGREATE
   is part of the path attributes?
2. What suggestions do you have for the language here.  Remember,
   we're not allowed to change the enumeration names.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 27 Mar 2002 11:46:49 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: 2842
Sender: [email-masked]

On Tue, Mar 26, 2002 at 03:51:55PM -0800, Alex Zinin wrote:
> I guess something along these lines might be appropriate (assuming
> that we want to discourage multiple copies of a zero-length cap):

To be fair, zero-length shouldn't be the bugaboo.  It should be
multiple capabilities with the same code _and the same data_.
The zero-length case is just one example of this.

> Alex Zinin

-- 
Jeff Haas 
NextHop Technologies

To: Alex Zinin <[email-masked]>
Cc: Pedro Roque Marques <[email-masked]>, Edward Crabbe <[email-masked]>, [email-masked]
Subject: Re: BGP4 -17 version 
Date: Tue, 26 Mar 2002 19:44:28 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Looks like Pedro is actually correct here.
> 
> Yakov, Ed, are we (Pedro and myself) missing
> something here? I think the intention is
> to say:
> 
>   MinRouteAdvInt <= i <= UpperBound

Pedro and you are correct.

Yakov.

> 
> Alex
> 
> >>> and/or withdrawal of unfeasible routes to some common set of >
> >>> destinations will be at least MinRouteAdvertisementInterval, > and
> >>> will also ensure a constant upper bound on the interval is >
> >>> acceptable.
> >>> 
> >>> The last sentence should be:
> >>> 
> >>> '..and will also ensure a constant lower bound on the the interval
> >>> is acceptable.'
> 
> >> Yes, you are correct. Thanks for pointing this out.
> 
> > The way i read it the original text is correct...
> 
> > i.e. the interval of time between two consecutive updates of the same
> > NLRI should have:
> 
> > a lower limit (which is MinAvertisement interval),
> > "an upper bound" (some unspecified value).
> 
> 
> >   Pedro.
> 
> 

Date: Tue, 26 Mar 2002 18:02:49 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Pedro Roque Marques <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Edward Crabbe <[email-masked]>, [email-masked]
Subject: Re: BGP4 -17 version
Sender: [email-masked]

Looks like Pedro is actually correct here.

Yakov, Ed, are we (Pedro and myself) missing
something here? I think the intention is
to say:

  MinRouteAdvInt <= i <= UpperBound

Alex

>>> and/or withdrawal of unfeasible routes to some common set of >
>>> destinations will be at least MinRouteAdvertisementInterval, > and
>>> will also ensure a constant upper bound on the interval is >
>>> acceptable.
>>> 
>>> The last sentence should be:
>>> 
>>> '..and will also ensure a constant lower bound on the the interval
>>> is acceptable.'

>> Yes, you are correct. Thanks for pointing this out.

> The way i read it the original text is correct...

> i.e. the interval of time between two consecutive updates of the same
> NLRI should have:

> a lower limit (which is MinAvertisement interval),
> "an upper bound" (some unspecified value).

>   Pedro.

Date: Tue, 26 Mar 2002 15:51:55 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: 2842
Sender: [email-masked]

Thinking more about this...

The reason I suggested to add text about non-zero length is
that multiple appearances of such capability do not cause
any problem at all (no values to chose from). However, this
presumed that the original text allowing _sending_ of multiple
instances would still be there and new text would be added to
address the receiver's side.

Additional consideration here is whether we should discourage
the BGP speakers from sending multiple copies of a zero-length
capability. I couldn't come up with a reason why we should not.
(Unless someone invents a mechanism where BGP speakers count
the instances and draw conclusions based on the total number
of them ;)

I guess something along these lines might be appropriate (assuming
that we want to discourage multiple copies of a zero-length cap):

   BGP speakers SHOULD NOT include more than one instance of
   a capability (as identified by its Capability Code) with zero
   Length field. Note however, that processing of multiple instances
   of such capability does not require special handling, as
   additional instances do not change the meaning of announced
   capability. BGP speakers MAY include more than one instance of
   a capability with non-zero Length field.

and here either:
                     ...Processing of these capability instances
   is specific to the Capability Code and MUST be described in the
   document introducing the new capability.

or:
                     ...Only the last instance of the capability
   should be taken into consideration, unless otherwise specified in
   the document introducing the new capability.
   
Thoughts are welcome.
   
-- 
Alex Zinin

Tuesday, March 26, 2002, 11:54:52 AM, Yakov Rekhter wrote:

>> Are we certain that there are no situations where we want capabilities
>> showing up redundantly with no data?

> There are (at least) two ways to answer your question:

> 1. If there is a need for the same capability to occur more than
> once, then this capability has to carry data.

> 2. Remove "and the value of the Capability Length field is non-zero"
> from the text I suggested.

> Any preferences ?

>> On Mon, Mar 25, 2002 at 05:15:52PM -0800, Yakov Rekhter wrote:
>> >     If a particular capability, as identified by its Capability Code,
>> >     occurs more than once within the Optional Parameter, and the
>> >     value of the Capability Length field is non-zero, then
>> >     handling this is specific to the Capability Code.
>> 
>> Minor tweak:
>> "then _the_ handling of _these capabilities_ are specific..."

> sure.

> Yakov.

Date: Tue, 26 Mar 2002 14:04:03 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: 2842 
Sender: [email-masked]

Yakov Rekhter writes:

>> Are we certain that there are no situations where we want
>> capabilities showing up redundantly with no data?

> There are (at least) two ways to answer your question:

> 1. If there is a need for the same capability to occur more than
> once, then this capability has to carry data.

> 2. Remove "and the value of the Capability Length field is non-zero"
> from the text I suggested.

> Any preferences ?

Number 1.
I don't think we want to allow any capability advertisement to convey
information by the number of times it is included in a message with no
data to acompany it...

It would just make it hard to debug/decode gratuitously... 

  Pedro.

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], Alex Zinin <[email-masked]>
Subject: Re: 2842 
Date: Tue, 26 Mar 2002 11:54:52 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

> Are we certain that there are no situations where we want capabilities
> showing up redundantly with no data?

There are (at least) two ways to answer your question:

1. If there is a need for the same capability to occur more than
once, then this capability has to carry data.

2. Remove "and the value of the Capability Length field is non-zero"
from the text I suggested.

Any preferences ?

> On Mon, Mar 25, 2002 at 05:15:52PM -0800, Yakov Rekhter wrote:
> >     If a particular capability, as identified by its Capability Code,
> >     occurs more than once within the Optional Parameter, and the
> >     value of the Capability Length field is non-zero, then
> >     handling this is specific to the Capability Code.
> 
> Minor tweak:
> "then _the_ handling of _these capabilities_ are specific..."

sure.

Yakov.

Date: Tue, 26 Mar 2002 14:39:27 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: BGP4 -17 version
Sender: [email-masked]

Looks fine to me....

:-)

Russ

On Mon, 25 Mar 2002, Yakov Rekhter wrote:

> Folks,
> 
> In view of the last paragraph in the attached, how about if 9.2.1.1
> be replaced with the following:
> 
>    9.2.1.1 Frequency of Route Advertisement
>    
>    The parameter MinRouteAdvertisementInterval determines the
>    minimum amount of time that must elapse between advertisement
>    and/or withdrawal of routes to a particular destination by a
>    BGP speaker to a peer. This rate limiting procedure applies on
>    a per-destination basis, although the value of
>    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> 
>    Two UPDATE messages sent by a BGP speaker to a peer that advertise
>    feasible routes and/or withdrawal of unfeasible routes to some
>    common set of destinations MUST be separated by at least
>    MinRouteAdvertisementInterval. Clearly, this can only be achieved
>    precisely by keeping a separate timer for each common set of
>    destinations. This would be unwarranted overhead.  Any technique
>    which ensures that the interval between two UPDATE messages sent
>    from a BGP speaker to a peer that advertise feasible routes
>    and/or withdrawal of unfeasible routes to some common set of
>    destinations will be at least MinRouteAdvertisementInterval,
>    and will also ensure a constant upper bound on the interval is
>    acceptable.
> 
>    Since fast convergence is needed within an autonomous system,
>    either (a) the MinRouteAdvertisementInterval used for internal
>    peers SHOULD be shorter than the MinRouteAdvertisementInterval
>    used for external peers, or (b) procedure describe in this
>    section SHOULD NOT apply for routes sent to internal peers.
> 
>    This procedure does not limit the rate of route selection, but
>    only the rate of route advertisement. If new routes are selected
>    multiple times while awaiting the expiration of
>    MinRouteAdvertisementInterval, the last route selected SHALL be
>    advertised at the end of MinRouteAdvertisementInterval.

__________________________________
[email-masked] CCIE <>< Grace Alone

Date: Tue, 26 Mar 2002 14:30:28 -0500
From: Jeffrey Haas <[email-masked]>
To: "Krishnan, Vijay G." <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP4 -17 version
Sender: [email-masked]

Vijay,

On Tue, Mar 26, 2002 at 12:12:21PM -0500, Krishnan, Vijay G. wrote:
> The Mib variables corresponding to these timers are defined as read-write
> with an integer range of (1..65535). I understand that these are indexed on
> a per-peer basis. Setting these variables to such large values doesn't make
> sense, unless you don't want to advertise routes to the peer. Is there any
> valid range for these intervals?

BTW, I agree.  Sandy pointed out the same issues too.
The real ceiling may vary wildly depending on implementations.
The spec must come to agreement and the MIB will follow.

Do you have suggestions for a ceiling value?

> Vijay

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 26 Mar 2002 13:56:23 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: BGP4 -17 version
Sender: [email-masked]

Looks fine to me, with the caveat of the last sentence, of
course.

:-)

Russ

On Mon, 25 Mar 2002, Yakov Rekhter wrote:

> Folks,
> 
> In view of the last paragraph in the attached, how about if 9.2.1.1
> be replaced with the following:
> 
>    9.2.1.1 Frequency of Route Advertisement
>    
>    The parameter MinRouteAdvertisementInterval determines the
>    minimum amount of time that must elapse between advertisement
>    and/or withdrawal of routes to a particular destination by a
>    BGP speaker to a peer. This rate limiting procedure applies on
>    a per-destination basis, although the value of
>    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> 
>    Two UPDATE messages sent by a BGP speaker to a peer that advertise
>    feasible routes and/or withdrawal of unfeasible routes to some
>    common set of destinations MUST be separated by at least
>    MinRouteAdvertisementInterval. Clearly, this can only be achieved
>    precisely by keeping a separate timer for each common set of
>    destinations. This would be unwarranted overhead.  Any technique
>    which ensures that the interval between two UPDATE messages sent
>    from a BGP speaker to a peer that advertise feasible routes
>    and/or withdrawal of unfeasible routes to some common set of
>    destinations will be at least MinRouteAdvertisementInterval,
>    and will also ensure a constant upper bound on the interval is
>    acceptable.
> 
>    Since fast convergence is needed within an autonomous system,
>    either (a) the MinRouteAdvertisementInterval used for internal
>    peers SHOULD be shorter than the MinRouteAdvertisementInterval
>    used for external peers, or (b) procedure describe in this
>    section SHOULD NOT apply for routes sent to internal peers.
> 
>    This procedure does not limit the rate of route selection, but
>    only the rate of route advertisement. If new routes are selected
>    multiple times while awaiting the expiration of
>    MinRouteAdvertisementInterval, the last route selected SHALL be
>    advertised at the end of MinRouteAdvertisementInterval.
>    
> 
> ------- Forwarded Message
> 
> Date:    Tue, 05 Mar 2002 10:50:02 -0800
> From:    Pedro Roque Marques <[email-masked]>
> To:      Alex Zinin <[email-masked]>
> cc:      <[email-masked]>
> Subject: Re: RFC Violation
> 
> Alex Zinin writes:
> 
> > Pedro,
> 
> >  I see your point. Note that when you are sending a WITHDRAWN, you
> > know it is a bad news.
> 
> Alex,
> A link up event will often cause a router to send withrawns as it
> changes it's best path from one that it's policy and/or ibgp flooding
> rules allow it to advertise to one that is rejected.
> 
> The inverse is true for a link down event...
> 
> I still maintain that it is not possible in BGP to distinguish if an
> update corresponds to a link up/down event... or what information you
> wish to send fast/slow.
> 
> I also believe that it is a major mistake to threat advertisements
> differently than withrawns, specially from a queuing/timing point of
> view. The only thing you are going to get out of that is weird
> blackholes and more instability...
> 
> AFAIK, no major vendor implements their advertisement
> rate-controller/queueing in a way as to threat updates and withrawns
> differently.
> 
>   Pedro.
> 
> ------- End of Forwarded Message
> 

__________________________________
[email-masked] CCIE <>< Grace Alone

Date: Tue, 26 Mar 2002 11:12:27 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Edward Crabbe <[email-masked]>, [email-masked]
Subject: Re: BGP4 -17 version 
Sender: [email-masked]

Yakov Rekhter writes:

> Ed,
>> > 9.2.1.1 Frequency of Route Advertisement > > The parameter
>> MinRouteAdvertisementInterval determines the > minimum amount of
>> time that must elapse between advertisement > and/or withdrawal of
>> routes to a particular destination by a > BGP speaker to a
>> peer. This rate limiting procedure applies on > a per-destination
>> basis, although the value of > MinRouteAdvertisementInterval is set
>> on a per BGP peer basis.  > > Two UPDATE messages sent by a BGP
>> speaker to a peer that advertise > feasible routes and/or
>> withdrawal of unfeasible routes to some > common set of
>> destinations MUST be separated by at least >
>> MinRouteAdvertisementInterval. Clearly, this can only be achieved >
>> precisely by keeping a separate timer for each common set of >
>> destinations. This would be unwarranted overhead.  Any technique >
>> which ensures that the interval between two UPDATE messages sent >
>> from a BGP speaker to a peer that advertise feasible routes >
>> and/or withdrawal of unfeasible routes to some common set of >
>> destinations will be at least MinRouteAdvertisementInterval, > and
>> will also ensure a constant upper bound on the interval is >
>> acceptable.
>> 
>> The last sentence should be:
>> 
>> '..and will also ensure a constant lower bound on the the interval
>> is acceptable.'

> Yes, you are correct. Thanks for pointing this out.

The way i read it the original text is correct...

i.e. the interval of time between two consecutive updates of the same
NLRI should have:

a lower limit (which is MinAvertisement interval),
"an upper bound" (some unspecified value).

  Pedro.

From: "Krishnan, Vijay G." <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>
Cc: [email-masked]
Subject: RE: BGP4 -17 version
Date: Tue, 26 Mar 2002 12:12:21 -0500
Sender: [email-masked]

Jeff,

The Mib variables corresponding to these timers are defined as read-write
with an integer range of (1..65535). I understand that these are indexed on
a per-peer basis. Setting these variables to such large values doesn't make
sense, unless you don't want to advertise routes to the peer. Is there any
valid range for these intervals?

thanks
Vijay

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 11:51 AM
To: Krishnan, Vijay G.
Cc: 'Yakov Rekhter'; [email-masked]
Subject: Re: BGP4 -17 version

On Tue, Mar 26, 2002 at 11:43:59AM -0500, Krishnan, Vijay G. wrote:
> What is the practical upper bound value of MinRouteAdvertisementInterval
and
> MinASOriginationInterval? Is there a range defined? Mib also doesn't
specify
> a range.

Vijay,

Currently, the interval is a timer that must (theoretically) go off
for a given prefix (with certain properties) before it can be
readvertised again.

Hopefully you don't mean you want a per-prefix table in the MIB that
shows the current interval for a given prefix.  Its doable, but ugly.

> Vijay

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 26 Mar 2002 11:51:12 -0500
From: Jeffrey Haas <[email-masked]>
To: "Krishnan, Vijay G." <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: Re: BGP4 -17 version
Sender: [email-masked]

On Tue, Mar 26, 2002 at 11:43:59AM -0500, Krishnan, Vijay G. wrote:
> What is the practical upper bound value of MinRouteAdvertisementInterval and
> MinASOriginationInterval? Is there a range defined? Mib also doesn't specify
> a range.

Vijay,

Currently, the interval is a timer that must (theoretically) go off
for a given prefix (with certain properties) before it can be
readvertised again.

Hopefully you don't mean you want a per-prefix table in the MIB that
shows the current interval for a given prefix.  Its doable, but ugly.

> Vijay

-- 
Jeff Haas 
NextHop Technologies

From: "Krishnan, Vijay G." <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: [email-masked]
Subject: RE: BGP4 -17 version 
Date: Tue, 26 Mar 2002 11:43:59 -0500
Sender: [email-masked]

Hi Yakov,

What is the practical upper bound value of MinRouteAdvertisementInterval and
MinASOriginationInterval? Is there a range defined? Mib also doesn't specify
a range.

thanks
Vijay

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Monday, March 25, 2002 9:39 PM
To: Edward Crabbe
Cc: [email-masked]
Subject: Re: BGP4 -17 version 

Ed,

> >    9.2.1.1 Frequency of Route Advertisement
> >    
> >    The parameter MinRouteAdvertisementInterval determines the
> >    minimum amount of time that must elapse between advertisement
> >    and/or withdrawal of routes to a particular destination by a
> >    BGP speaker to a peer. This rate limiting procedure applies on
> >    a per-destination basis, although the value of
> >    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> > 
> >    Two UPDATE messages sent by a BGP speaker to a peer that advertise
> >    feasible routes and/or withdrawal of unfeasible routes to some
> >    common set of destinations MUST be separated by at least
> >    MinRouteAdvertisementInterval. Clearly, this can only be achieved
> >    precisely by keeping a separate timer for each common set of
> >    destinations. This would be unwarranted overhead.  Any technique
> >    which ensures that the interval between two UPDATE messages sent
> >    from a BGP speaker to a peer that advertise feasible routes
> >    and/or withdrawal of unfeasible routes to some common set of
> >    destinations will be at least MinRouteAdvertisementInterval,
> >    and will also ensure a constant upper bound on the interval is
> >    acceptable.
> 
> The last sentence should be:
> 
> '..and will also ensure a constant lower bound on the
> the interval is acceptable.'

Yes, you are correct. Thanks for pointing this out.

Yakov.

Date: Tue, 26 Mar 2002 10:40:07 -0600
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>
Subject: Re: 2842
Sender: [email-masked]

A little bit of background here:

 A potentially problematic situation is where more than one
 instance of capability X is included in the Open message
 and the semantics of the values is not additive (e.g., the
 graceful restart timer). The question is which value to
 take.

 There are potentially two ways to address this problem:

  1. Go with the text Yakov proposed below and make sure
     _all_ specs introducing new capabilities have the rule
     (a hint to the authors ;).

  2. Have a default rule in 2842 (such as "ignore" all but
     the last instance) that can be overridden by a more
     specific document (such as 2858).

-- 
Alex Zinin

Monday, March 25, 2002, 7:15:52 PM, Yakov Rekhter wrote:

> [replying to myself...]

>> Folks,
>> 
>> During the IESG review Alex Zinin brought up an issue that the
>> the following text from the current spec is a bit underspecified:
>> 
>>    A particular capability, as identified by its Capability Code, may
>>    occur more than once within the Optional Parameter.
>> 
>> To address this I'd like to proposed to replace the above sentence
>> with the following:
>> 
>>    If a particular capability, as identified by its Capability Code,
>>    occurs more than once within the Optional Parameter, and the
>>    Length field of the Optional Parameter is non-zero, then
>>    handling this is specific to the Capability Code.

>     If a particular capability, as identified by its Capability Code,
>     occurs more than once within the Optional Parameter, and the
>     value of the Capability Length field is non-zero, then
>     handling this is specific to the Capability Code.

> Yakov.

Date: Tue, 26 Mar 2002 09:34:47 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], Alex Zinin <[email-masked]>
Subject: Re: 2842
Sender: [email-masked]

Are we certain that there are no situations where we want capabilities
showing up redundantly with no data?

On Mon, Mar 25, 2002 at 05:15:52PM -0800, Yakov Rekhter wrote:
>     If a particular capability, as identified by its Capability Code,
>     occurs more than once within the Optional Parameter, and the
>     value of the Capability Length field is non-zero, then
>     handling this is specific to the Capability Code.

Minor tweak:
"then _the_ handling of _these capabilities_ are specific..."

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

From: "Reddy, Sudhakar" <[email-masked]>
To: [email-masked]
Cc: "Reddy, Sudhakar" <[email-masked]>
Subject: Question on Confederations
Date: Mon, 25 Mar 2002 23:09:34 -0500
Sender: [email-masked]

Hi All,

One of the AS_PATH modification rule in the the section 6.1 of RFC3065 says
that:

   "b) When a given BGP speaker advertises the route to a BGP speaker
      located in a neighboring autonomous system that is a member of the
      local autonomous system confederation, then the advertising
      speaker shall update the AS_PATH attribute as follows:	

      	      2) if the first path segment of the AS_PATH is not of type
        	          AS_CONFED_SEQUENCE the local system shall prepend
a new path
                     segment of type AS_CONFED_SEQUENCE to the AS_PATH,
including
                     its own confederation identifier in that segment."

In this case should it include its own AS number insted of its own
confederation Identifier?

Thanks,
Sudhakar

----------------------------------------------------------------------------
-
R. Sudhakar Reddy                      mailto:[email-masked]

To: Edward Crabbe <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP4 -17 version 
Date: Mon, 25 Mar 2002 18:38:59 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Ed,

> >    9.2.1.1 Frequency of Route Advertisement
> >    
> >    The parameter MinRouteAdvertisementInterval determines the
> >    minimum amount of time that must elapse between advertisement
> >    and/or withdrawal of routes to a particular destination by a
> >    BGP speaker to a peer. This rate limiting procedure applies on
> >    a per-destination basis, although the value of
> >    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> > 
> >    Two UPDATE messages sent by a BGP speaker to a peer that advertise
> >    feasible routes and/or withdrawal of unfeasible routes to some
> >    common set of destinations MUST be separated by at least
> >    MinRouteAdvertisementInterval. Clearly, this can only be achieved
> >    precisely by keeping a separate timer for each common set of
> >    destinations. This would be unwarranted overhead.  Any technique
> >    which ensures that the interval between two UPDATE messages sent
> >    from a BGP speaker to a peer that advertise feasible routes
> >    and/or withdrawal of unfeasible routes to some common set of
> >    destinations will be at least MinRouteAdvertisementInterval,
> >    and will also ensure a constant upper bound on the interval is
> >    acceptable.
> 
> The last sentence should be:
> 
> '..and will also ensure a constant lower bound on the
> the interval is acceptable.'

Yes, you are correct. Thanks for pointing this out.

Yakov.

Date: Mon, 25 Mar 2002 18:12:26 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP4 -17 version
Sender: [email-masked]

>    9.2.1.1 Frequency of Route Advertisement
>    
>    The parameter MinRouteAdvertisementInterval determines the
>    minimum amount of time that must elapse between advertisement
>    and/or withdrawal of routes to a particular destination by a
>    BGP speaker to a peer. This rate limiting procedure applies on
>    a per-destination basis, although the value of
>    MinRouteAdvertisementInterval is set on a per BGP peer basis.
> 
>    Two UPDATE messages sent by a BGP speaker to a peer that advertise
>    feasible routes and/or withdrawal of unfeasible routes to some
>    common set of destinations MUST be separated by at least
>    MinRouteAdvertisementInterval. Clearly, this can only be achieved
>    precisely by keeping a separate timer for each common set of
>    destinations. This would be unwarranted overhead.  Any technique
>    which ensures that the interval between two UPDATE messages sent
>    from a BGP speaker to a peer that advertise feasible routes
>    and/or withdrawal of unfeasible routes to some common set of
>    destinations will be at least MinRouteAdvertisementInterval,
>    and will also ensure a constant upper bound on the interval is
>    acceptable.

The last sentence should be:

'..and will also ensure a constant lower bound on the
the interval is acceptable.'

	-ed

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], Alex Zinin <[email-masked]>
Subject: Re: 2842 
Date: Mon, 25 Mar 2002 17:15:52 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

[replying to myself...]

> Folks,
> 
> During the IESG review Alex Zinin brought up an issue that the
> the following text from the current spec is a bit underspecified:
> 
>    A particular capability, as identified by its Capability Code, may
>    occur more than once within the Optional Parameter.
> 
> To address this I'd like to proposed to replace the above sentence
> with the following:
> 
>    If a particular capability, as identified by its Capability Code,
>    occurs more than once within the Optional Parameter, and the
>    Length field of the Optional Parameter is non-zero, then
>    handling this is specific to the Capability Code.

    If a particular capability, as identified by its Capability Code,
    occurs more than once within the Optional Parameter, and the
    value of the Capability Length field is non-zero, then
    handling this is specific to the Capability Code.

Yakov.

To: [email-masked]
Cc: Alex Zinin <[email-masked]>
Subject: 2842
Date: Mon, 25 Mar 2002 17:03:50 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

During the IESG review Alex Zinin brought up an issue that the
the following text from the current spec is a bit underspecified:

   A particular capability, as identified by its Capability Code, may
   occur more than once within the Optional Parameter.

To address this I'd like to proposed to replace the above sentence
with the following:

   If a particular capability, as identified by its Capability Code,
   occurs more than once within the Optional Parameter, and the
   Length field of the Optional Parameter is non-zero, then
   handling this is specific to the Capability Code.

Yakov.

To: [email-masked]
Subject: BGP4 -17 version
Date: Mon, 25 Mar 2002 07:31:31 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

In view of the last paragraph in the attached, how about if 9.2.1.1
be replaced with the following:

   9.2.1.1 Frequency of Route Advertisement
   
   The parameter MinRouteAdvertisementInterval determines the
   minimum amount of time that must elapse between advertisement
   and/or withdrawal of routes to a particular destination by a
   BGP speaker to a peer. This rate limiting procedure applies on
   a per-destination basis, although the value of
   MinRouteAdvertisementInterval is set on a per BGP peer basis.

   Two UPDATE messages sent by a BGP speaker to a peer that advertise
   feasible routes and/or withdrawal of unfeasible routes to some
   common set of destinations MUST be separated by at least
   MinRouteAdvertisementInterval. Clearly, this can only be achieved
   precisely by keeping a separate timer for each common set of
   destinations. This would be unwarranted overhead.  Any technique
   which ensures that the interval between two UPDATE messages sent
   from a BGP speaker to a peer that advertise feasible routes
   and/or withdrawal of unfeasible routes to some common set of
   destinations will be at least MinRouteAdvertisementInterval,
   and will also ensure a constant upper bound on the interval is
   acceptable.

   Since fast convergence is needed within an autonomous system,
   either (a) the MinRouteAdvertisementInterval used for internal
   peers SHOULD be shorter than the MinRouteAdvertisementInterval
   used for external peers, or (b) procedure describe in this
   section SHOULD NOT apply for routes sent to internal peers.

   This procedure does not limit the rate of route selection, but
   only the rate of route advertisement. If new routes are selected
   multiple times while awaiting the expiration of
   MinRouteAdvertisementInterval, the last route selected SHALL be
   advertised at the end of MinRouteAdvertisementInterval.

------- Forwarded Message

Date:    Tue, 05 Mar 2002 10:50:02 -0800
From:    Pedro Roque Marques <[email-masked]>
To:      Alex Zinin <[email-masked]>
cc:      <[email-masked]>
Subject: Re: RFC Violation

Alex Zinin writes:

> Pedro,

>  I see your point. Note that when you are sending a WITHDRAWN, you
> know it is a bad news.

Alex,
A link up event will often cause a router to send withrawns as it
changes it's best path from one that it's policy and/or ibgp flooding
rules allow it to advertise to one that is rejected.

The inverse is true for a link down event...

I still maintain that it is not possible in BGP to distinguish if an
update corresponds to a link up/down event... or what information you
wish to send fast/slow.

I also believe that it is a major mistake to threat advertisements
differently than withrawns, specially from a queuing/timing point of
view. The only thing you are going to get out of that is weird
blackholes and more instability...

AFAIK, no major vendor implements their advertisement
rate-controller/queueing in a way as to threat updates and withrawns
differently.

  Pedro.

------- End of Forwarded Message

From: "Soo-Hyun Choi" <[email-masked]>
To: <[email-masked]>, "Susan Hares" <[email-masked]>
Cc: "yakov Rekhter" <[email-masked]>
Subject: Re: Slides from Dave Ward's presentation
Date: Mon, 25 Mar 2002 11:43:13 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_020C_01C1D3F2.3EE9CA60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

dear susan and yakov,

could we get the information regarding the idr draft status that we've
talked at the wg meeting?
(or can anyone get a chance to scratch down the idr draft status that we've
stared with the meeting?)

thanks in advance,
soo-hyun choi

  ----- Original Message -----
  From: Susan Hares
  To: [email-masked]
  Cc: yakov Rekhter
  Sent: Thursday, March 21, 2002 4:56 AM
  Subject: Slides from Dave Ward's presentation

  I've attached Dave Ward's presentation.

  Sue

----------------------------------------------------------------------------
--

------=_NextPart_000_020C_01C1D3F2.3EE9CA60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>dear susan and yakov,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>could we get the information regarding the idr draft =
status=20
that we've talked at the wg meeting?</FONT></DIV>
<DIV><FONT size=3D2>(or can anyone get a chance to scratch down the idr =
draft=20
status that we've stared with the meeting?)</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>thanks in advance,</FONT></DIV>
<DIV><FONT size=3D2>soo-hyun choi</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#44404;&#47548;">----- Original Message =
----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt &#44404;&#47548;; font-color: =
black"><B>From:</B> <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Susan =
Hares</A> </DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">yakov Rekhter</A> </DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>Sent:</B> Thursday, =
March 21, 2002 4:56 AM</DIV>
  <DIV style=3D"FONT: 10pt &#44404;&#47548;"><B>Subject:</B> Slides from =
Dave Ward's=20
  presentation</DIV>
  <DIV><BR></DIV><BR>I've attached Dave Ward's =
presentation.<BR><BR>Sue<BR><BR>
  <P>
  <HR>

  <P></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_020C_01C1D3F2.3EE9CA60--

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: [email-masked]
Subject: Multiple tuples of type AS_SEQUENCE ..?
Date: Sat, 23 Mar 2002 00:38:17 +0530
Sender: [email-masked]

hi 1

section 9.2.2.2
         - Multiple tuples of type AS_SEQUENCE with the same value may
         appear in the aggregated AS_PATH only when adjacent to another
         tuple of the same type and value.

           The above  point is added in the new draft aggregating  rules,
When i compare this  statement with 4 octet AS number  draft rfc feature, it
looks invalid. 
                 Say if have two  AS_TRANS no's  which are not adjacent in
multiple AS_SEQUENCE  tuples means, Should i  add the AS_TRANS no only
once..?   If so, then i will loose the whole  purpose of AS_SEQUENCE tuple,
or atleast this point  we should give exception for AS_TRANS numbers..?

              Removing multiple occurence of AS_TRANS  will be  legitimate
to do in AS_SET, but not in AS_SEQUENCE..?

Regards
Venu G.

                 

Date: Fri, 22 Mar 2002 13:36:47 -0500
From: Mathew Richardson <[email-masked]>
To: [email-masked]
Subject: Re: counting AS-path length
Sender: [email-masked]

> Jeffrey Haas <[email-masked]> [Thu, Mar 21, 2002 at 06:38:16PM -0500]:

<snip>

>9.2.2.2:
>: An implementation may choose any algorithm which conforms to these
>: rules. At a minimum a conformant implementation shall be able to
>: perform the following algorithm that meets all of the above
>: conditions:
>
>Change this to:
>An implementation may choose any algorithm which conforms to these rules.
>The aggregated AS_PATH SHOULD be generated such that the minimal
>number of path segments are required to encode the resulting AS_PATH.
>At a minimum....

<snip>

This wording seems slightly misleading to me.  In particular, I first
read it to mean that the generated AS_PATH SHOULD contain the minimal
number of segments... Not that the generated AS_PATH should not include
consecutive segments of identical types that _could_ have been merged
in to a single segment.

Consequently, I propose a different change.  Add the following step
to the algorithm:

 - for each pair of adjacent tuples in the aggregated AS_PATH, if both
 tuples have the same type, merge them together, as long as doing so
 will not cause a segment with length greater than 255 to be generated.

mrr

Date: Thu, 21 Mar 2002 18:38:16 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: counting AS-path length
Sender: [email-masked]

In a previous message, I had said:

> > If I were to choose between two options:
> > 
> >  1) state that TLVs should be max packed and do not require
> >     "merger" of adjacent sets for calculation, and
> 
> Based on our conversation offline, this seems to be the most reasonable
> thing to do.  Additionally, a field has been added to the v2MIB that
> shows the calculated length for route selection purposes.
> 
> Does anyone disagree that this recommendation should be added to the
> specification?

Yakov requested that I propose text.

I propose:
9.1.2.2.a:

: a) Remove from consideration all routes which are not tied for
:    having the smallest number of AS numbers present in their AS_PATH
:    attributes. Note, that when counting this number, an AS_SET counts
:    as 1, no matter how many ASs are in the set, and that, if the

Change this to: "each AS_SET counts as 1".  This strengthens the
wording a bit.

Additionally:

9.2.2.2:
: An implementation may choose any algorithm which conforms to these
: rules. At a minimum a conformant implementation shall be able to
: perform the following algorithm that meets all of the above
: conditions:

Change this to:
An implementation may choose any algorithm which conforms to these rules.
The aggregated AS_PATH SHOULD be generated such that the minimal
number of path segments are required to encode the resulting AS_PATH.
At a minimum....

I don't think we want to make this a MUST.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 20 Mar 2002 20:56:01 -0500
To: Brijesh Kumar <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: BGP over IPSEC tunnel
Cc: Susan Hares <[email-masked]>, [email-masked], yakov Rekhter <[email-masked]>
Sender: [email-masked]

Brijesh:

Our Routing ADs have asked the requirement question you asked.
As to why a standard for BGP over IP Sec?  If the standard allows
different pieces of equipment to inter-operate it is good.

At 03:53 PM 3/20/2002 -0800, Brijesh Kumar wrote:
>Hi Susan,
>
>I don't understand the need for draft because I can already run any routing
>protocol between my virtual routers including BGP over IPSEC tunnels (if
>someone decides to do it for whatever reason. I am not discussings why would
>like to use IPSEC in a peer to peer environment and like to screw the
>convergence of large number of BGP routes.). What is the point of this
>draft? Where is any value add? There are tons of applications running on
>TLS?

I would defer the answer of the tons of applications to Dave Ward.

>Are we trying to write RFCs/drafts about things for common sense usage for
>IPSEC/TLS/SSL?

Does common sense usage imply things which make a boxes
inter-operate in a network?  As Dave Ward stated, this document
can be generalized for all protocols running over IP Sec.

Please tune into the IP Routing Security BOF if you can.
Additional discussion of routing protocols and security
will be held there tommorrow.

Sue Hares

Date: Wed, 20 Mar 2002 14:56:01 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Slides from Dave Ward's presentation
Cc: yakov Rekhter <[email-masked]>
Sender: [email-masked]

--=====================_88600590==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

I've attached Dave Ward's presentation.

Sue
--=====================_88600590==_
Content-Type: application/pdf; name="ipsec_bgp_2002_03_20.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ipsec_bgp_2002_03_20.pdf"

--=====================_88600590==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_88600590==_--

Date: Wed, 20 Mar 2002 07:21:26 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: IBGP survey
Cc: yakov Rekhter <[email-masked]>
Sender: [email-masked]

IBGP and Persistent Route Oscillation

The Draft BGP Persistent Route Oscillation draft describes route 
oscillation occurring in networks today.   This draft can be obtained at:

http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt

In order to evaluate how significant a problem the route oscillation is, I 
would like to get input from network operators.   If you could take a few 
moments and fill out this survey, it would help in determining the severity 
of the problems.   Any information solicited by this survey will remain 
private.   Summaries of this information will be sent to the IDR working list.

Sue Hares

--------------------------

1) Contact information:

Name:
Company:
Position/Responsibility:
Email address:
Phone number:

2 What type of network do you run (select one of the choices)?

a) Enterprise network
b) Service provider Tier 1
c) Service provider Tier 2
d) Service provider - other
e) Exchange point
f) Specialized service provider
g) Other (please specify)

3) Have you seen persistent route oscillation in your network?
     What type of route oscillation?

	a) Experiencing Type I MED churn with Route Reflectors?
	b) Experiencing Type I MED churn with AS Confederations
	c) Experiencing Type II MED churn with 2 Tiers of Route Reflectors?
	d) Experiencing Type II MED church with AS Confederations?

     How did you detect the problem?
     What steps have you taken to fix this problem?

4) If you run IBGP, please answer the questions below.
(If you don't run IBGP, then the whole survey is irrelevant to you)

       a) How many IBGP peers in your network?  How many of routes are
          carried in IBGP?
       b) Do you use MED?  Are you transit for other Ass?
       c) Do you use Router Reflectors?  How many levels?
       d) Do you use AS confederations?  How many AS in confederations?
	
5) If you run EBGP,
How many EBGP peers do you have?  How many other
    	Autonomous Systems (ASs) do you peer with?  Do you use MED or AS
    	Confederations?

[If you don't run EBGP, then the whole survey is irrelevant to you)

Date: Wed, 20 Mar 2002 12:06:54 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Minutes from 3/20/01 - 1st draft
Cc: [email-masked]
Sender: [email-masked]

--=====================_78453129==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi all:

This is the first draft of the IDR working group minutes.
Please send correction and questions to me or the list.

Sue Hares

PS - I'll welcome volunteers to take minutes at the next IDR meeting.

=========
Minutes of the IDR meeting

1) Agenda bashing - nothing added
2) IDR document status attached [power point presentation]
3) BGP MIB v2
	
	- 2547 MIB work will be added
	- Discussion of the BGP-MIB v2 will go on the list

4) BGP Security

   a) BGP Security analysis [presentation will be sent later]

     BGP Security Protections (draft-murphy-bgp-protect-00.txt)
     BGP Security Vulnerabilities Analysis (draft-murphy-bgp-vuln-00.txt
	[see presentation

	2) see Sandy's presentation for details on individual comments
	
	Alex: Security analysis draft is outside of the working
	      charter. (Routing AD)
	Ran: Security analysis is certainly within the charter for
	      a working group.

	IDR working group mailing list will discuss the drafts and
	whether work on this draft is within the IDR charter.
	Alex (Routing AD) will also ask the IESG whether this
	subject is part of our scope.

    b) Securing BGPv4 using IPsec [draft-ward-bgp-ipsec-00.txt]

   	a) application/deployment doc and not protocol extension
	b) Could be discussed in is:
		a) Security policy working group
		b) IPS (security policy)
		c) IDR information RFC
	
	Question:
		1) section 2 - IKE is a "MUST" (an error)
		2) No encryption is not an issue to the security
	
	Alex Zinin (as Routing AD)states this is out of the charter for the
	working group.  We will need to revise the charter to include
	this draft.  The Routing ADs suggested that we await until
	we have the Routing Security BOF to discuss requirements on the list.

    c) TCP MD5 draft

	Key Requirements for the TCP MD5 Signature Option
	draft-ietf-idr-md5-keys-00.txt

       [No slides from Marcus, notes are rough]

	a) Most credible attack is "key determination" is brute force

	    Took the current architecture of processors and software to
	    see what reasonable.  The normal keys is a	
	    12-24 byte key length with "ascii" (most common used).
	
	    Recommendation: key: use HEX structure
			    change keys every 90 days

	b) IP Sec vs TCP MD5
		
	    Experience with public key infrastructures has
	    shown that a dynamic key infrastructure is difficult
	    to deploy.
	
	    If authentications is the only issue, use TCP MD5. If
            encryption and data security is important, IPSEC is the choice.

	Using IKE for dynamic Key management may be useful.
	Profile for TCP MD5 re-keying for BGP would look different than
	OSPF.

	c) TCP MD5 versus HMAC MD5 - if start today use HMAC MD5.

    4) BGP Integrity Check using IRR
	
       Concerns with the draft:
	a) Multi-origin AS are a normal situation and good,
	    so this portion of the draft should changed
	b) IRR can allow multiple origin per prefix
	c) Caching of the IRR Checks causes a problem
	   during start-up
--=====================_78453129==_
Content-Type: application/octet-stream; name="IDR-01.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IDR-01.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAhwAAAAAAAAAA
EAAAowAAAAEAAAD+////AAAAAIUAAACGAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
--=====================_78453129==_
Content-Type: application/octet-stream; name="v2mib-update-ietf53.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="v2mib-update-ietf53.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAATQAAAAAAAAAA
EAAAZQAAAAEAAAD+////AAAAAEwAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAA
--=====================_78453129==_
Content-Type: application/pdf; name="IETF54-idr-kengo.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IETF54-idr-kengo.pdf"

--=====================_78453129==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_78453129==_--

From: Bill Fenner <[email-masked]>
To: [email-masked]
Subject: Document Action: BGP Persistent Route Oscillation Condition to Informational
Date: Wed, 20 Mar 2002 07:38:06 -0800
Versions: dmail (solaris) 2.4/makemail 2.9b
Sender: [email-masked]

I suppose [email-masked] should be allowed to post to the
IDR list.

  Bill

----- Begin forwarded message:

From: The IESG <[email-masked]>
Subject: Document Action: BGP Persistent Route Oscillation Condition
         to Informational
Date: Sun, 10 Mar 2002 11:34:51 -0500
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board
    <[email-masked]>, [email-masked]

The IESG has approved the Internet-Draft 'BGP Persistent Route
Oscillation Condition' <draft-ietf-idr-route-oscillation-01.txt> as an
Informational RFC.  This document is the product of the Inter-Domain
Routing Working Group.  The IESG contact persons are Bill Fenner and
Randy Bush

----- End forwarded message:

Date: Wed, 20 Mar 2002 05:30:04 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Last Call on BGP MIB
Sender: [email-masked]

Folks:

This is to start the IDR WG Last call on

Definitions of Managed Objects
for the Fourth Version of Border Gateway Protocol (BGP-4)
[draft-ietf-idr-bgp4-mib-08.txt].

This draft is sometimes referred to as BGP-4 MIB V1.
This draft will be submitted to the IESG as
historical.

The Last call ends on 4/5.

Sue Hares

Date: Wed, 20 Mar 2002 10:12:02 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: MIB v2
Sender: [email-masked]

--=====================_71561449==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

MIB presentation
--=====================_71561449==_
Content-Type: application/octet-stream; name="v2mib-update-ietf53.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="v2mib-update-ietf53.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAATQAAAAAAAAAA
EAAAZQAAAAEAAAD+////AAAAAEwAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAA
--=====================_71561449==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_71561449==_--

Date: Wed, 20 Mar 2002 10:12:31 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Kengo's presentation
Sender: [email-masked]

--=====================_71590281==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_71590281==_
Content-Type: application/pdf; name="IETF54-idr-kengo.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IETF54-idr-kengo.pdf"

--=====================_71590281==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_71590281==_--

Date: Wed, 20 Mar 2002 10:01:00 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Working group slides
Sender: [email-masked]

--=====================_70899277==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Slides for IDR documents
--=====================_70899277==_
Content-Type: application/octet-stream; name="IDR-01.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IDR-01.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAjAAAAAAAAAAA
EAAArgAAAAEAAAD+////AAAAAIoAAACLAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
--=====================_70899277==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_70899277==_--

Date: Tue, 19 Mar 2002 17:45:34 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Agenda for IDR meeting at 9:00am on Wed
Cc: yakov Rekhter <[email-masked]>, [email-masked], alex Zinin <[email-masked]>
Sender: [email-masked]

IDR's working group is on Wed 3/20 at 9:00am - 11:30am

  1) Agenda bashing
  2) Status of drafts [15 minutes] [Sue Hares]
  3) BGP MIB v2 [15 minutes] [Jeff Haas]

  4) Security drafts:

    a) BGP Security [Sandy Murphy's drafts] [15 minutes]

	The following drafts are proposed for IDR drafts:

	BGP Security Protections (draft-murphy-bgp-protect-00.txt)
	BGP Security Vulnerabilities Analysis (draft-murphy-bgp-vuln-00.txt)

    b) IPSEC - Dave Ward's drafts [11 minutes]

	The following draft is proposed for IDR drafts:

	Securing BGPv4 using IPsec (draft-ward-bgp-ipsec-00.txt)

    c) Marcus Leech on TCP MD5 issues [10 minutes]	

  5) Kengo Nagahashi - BGP integrity Check
         [30 minutes]
	
	Kengo's draft is: 	
	Automatically BGP Integrity Check using IRR-DB
	(draft-kengo-bgp-integrity-check-00.txt)

  Sue Hares

PS - presentations will be sent to the list during the meeting

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: [email-masked]
Subject: Partial attribute setting, if transtive attribute added in the mi ddle
Date: Sat, 16 Mar 2002 22:33:00 +0530
Sender: [email-masked]

hi !

   rfc 1771 and  new draft section 5  says 
     "New transitive optional attributes may be attached to the path by the
     originator or by any other BGP speaker in the path. If they are not
     attached by the originator, the Partial bit in the Attribute Flags
     octet is set to 1."

               When a new  optional transtive is added in the middle of the
path and all of the followers in the path understands that 
 attribute,   the end reacher(BGP Speaker )  as such  he is not loosing any
of  the information  right..?   why we should we set the partial attribute
if  we add the optional  transtive attribute in the middle ..?

                 Take for exaxmple  AGGREGATOR and  COOMMUNITIES attribute,
if they are in the middle, the end reacher does not loose any information..?

              One more thing i want  clear  before to discuss this issue
...?    As per rfc   Partial attribute is set for any attribute means  
                           Is it mean only  when any of the middle of the
path speakers  does not understood   that attribute, or  it could  also be
the reason of adding optional transitive  in the middle of the path...?  

Regards & Thanks
Venu G.

  

      

Disclaimer:
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.

From: "Jake Khuon" <[email-masked]>
To: "Bruno Rijsman" <[email-masked]>
Cc: [email-masked]
Dcc: 
Subject: Re: IPv4 and IPv6 in same UPDATE 
Reply-To: [email-masked] (Jake Khuon)
Action: 
Expires: 
Date: Fri, 15 Mar 2002 07:09:09 -0800
Sender: [email-masked]

### On Fri, 15 Mar 2002 09:59:28 -0500, "Bruno Rijsman"
### <[email-masked]> casually decided to expound upon
### [email-masked], [email-masked] the following thoughts about
### "IPv4 and IPv6 in same UPDATE":

BR> Jerome> Is it legal to have in the same Update message IPv4 and
BR> Jerome> IV6 NLRIs?
BR> 
BR> Jake> If it is then it shouldn't be because I don't see how it would
BR> Jake> work.  The NEXT_HOP attribute would be either one of IPv4 or
BR> Jake> IPv6 depending on the update and you can only have one
BR> Jake> NEXT_HOP per update.
BR> 
BR> Actually, there can be two next-hops in the UPDATE: one old-fashioned
BR> next-hop attribute and one next-hop in the mp-reach-nlri attribute.

You're right.  I stand corrected.  I was concentrating too hard on the
MP_REACH_NLRI only.

--
/*===================[ Jake Khuon <[email-masked]> ]======================+
 | Packet Plumber, Network Engineers     /| / [~ [~ |) | | --------------- |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| N E T W O R K S |
 +=========================================================================*/

From: "Jake Khuon" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Dcc: 
Subject: Re: MP-BGP: IPv6 and IPv4 NLRI in the same update message 
Reply-To: [email-masked] (Jake Khuon)
Action: 
Expires: 
Date: Fri, 15 Mar 2002 06:31:01 -0800
Sender: [email-masked]

### On Fri, 15 Mar 2002 06:30:17 -0700, [email-masked] casually
### decided to expound upon [email-masked] the following thoughts about
### "MP-BGP: IPv6 and IPv4 NLRI in the same update message":

j> Is it legal to have in the same Update message IPv4 and IV6 NLRIs?

If it is then it shouldn't be because I don't see how it would work.  The
NEXT_HOP attribute would be either one of IPv4 or IPv6 depending on the
update and you can only have one NEXT_HOP per update.

--
/*===================[ Jake Khuon <[email-masked]> ]======================+
 | Packet Plumber, Network Engineers     /| / [~ [~ |) | | --------------- |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| N E T W O R K S |
 +=========================================================================*/

From: [email-masked]
To: [email-masked]
Subject: MP-BGP: IPv6 and IPv4 NLRI in the same update message
Date: Fri, 15 Mar 2002 06:30:17 -0700
Sender: [email-masked]

Hello,

Is it legal to have in the same Update message IPv4 and IV6 NLRIs?

Thanks,
Jerome

Date: Thu, 14 Mar 2002 21:45:47 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: "Khanna, Vinay" <[email-masked]>
Cc: [email-masked]
Subject: Overlapping aggregate rules
Sender: [email-masked]

Khanna, Vinay writes:

> Hi, I've a couple of doubts with respect to overlapping aggregate
> rules.

> 1) Can overlapping aggregate rules (say 10.0.0.0/8 & 10.1.0.0/16) be
> configured in a router? If yes, what is the usefulness of such a
> configuration?

> 2) Suppose if we allow such a configuration, then what will be the
> behaviour when we get a 'more specific' route (say 10.1.1.0/24) from
> a BGP peer? There are various alternatives possible a) Advertise
> both 10.0.0.0/8 & 10.1.0.0/16 with the same set of path
> attributes. Is it possible that the path attributes are different?
> b) Advertise the least-specific aggregate rule (ie. 10.0.0.0/8) c)
> Advertise the more-specific aggregate rule (ie. 10.1.0.0/16) What
> are the merits/demerits of these alternatives over one another?

A scenario where such configuration might be useful is if you have a
box connected to several levels of hirarchy... say a router that
connects to regions A, B and external peers.

You might want to advertise to region B the aggregate of region's A
routes and to external peers the aggregate of all...
And of course to region B you want to suppress all contributers of A's
aggregate but not of the total aggregate... while to the top level you
would want to suppress all contributers of the top level aggregate.

The path attribute rules are resonably straightforward, i
believe. Each aggregate should include in it's as-set the ases present
in the contributer routes.

It is probably not a very common configuration... but that might also
be related to the fact that it is usually a bit cumbersome to
configure in most products.

  Pedro.

From: "Khanna, Vinay" <[email-masked]>
To: [email-masked]
Subject: Overlapping aggregate rules
Date: Thu, 14 Mar 2002 23:51:50 -0500
Sender: [email-masked]

Hi,

I've a couple of doubts with respect to overlapping aggregate rules.

1) Can overlapping aggregate rules (say 10.0.0.0/8 & 10.1.0.0/16) be
configured in a router? If yes, what is the usefulness of such a
configuration?

2) Suppose if we allow such a configuration, then what will be the behaviour
when we get a 'more specific' route (say 10.1.1.0/24) from a BGP peer? There
are various alternatives possible
  a) Advertise both 10.0.0.0/8 & 10.1.0.0/16 with the same set of path
attributes. Is it possible that the path attributes are different?
  b) Advertise the least-specific aggregate rule (ie. 10.0.0.0/8)
  c) Advertise the more-specific aggregate rule (ie. 10.1.0.0/16)
What are the merits/demerits of these alternatives over one another?

TIA,
Vinay

To: [email-masked]
Subject: rough consensus on SAFI=3
Date: Thu, 14 Mar 2002 09:26:40 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Here are the results of the poll on the attached (sorry for the very 
late posting):

10 in favor of removing SAFI=3 from 2858bis
2 in favor of keeping SAFI=3 in 2858bis

With this in mind SAFI=3 will be removed from the next revision
of the draft.

Yakov.
------- Forwarded Message

Date:    Fri, 18 Jan 2002 13:24:07 -0800
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
cc:      [email-masked], [email-masked]
Subject: rough consensus on SAFI=3

Folks,

We need to get WG rough consensus on whether to remove SAFI=3 from
2858bis.

Folks who are in favor of removing SAFI=3 from 2858bis please
send an e-mail to [email-masked] saying "remove".

Folks you are in favor of keeping SAFI=3 in 2858bis please send
an e-mail to [email-masked] saying "keep".

The deadline for this is one week (Jan 25, 2002).

Sue&Yakov.

------- End of Forwarded Message

To: [email-masked]
Subject: processing order of reach/unreach in rfc2858bis
Date: Thu, 14 Mar 2002 06:27:25 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Here are the results of the poll on the attached:
Out of 8 responses we have:

    4 said Option 1 as the first choice
    3 said Option 2 as the first choice
    1 said Option 3 as the first choice
    6 said Option 3 as the second choice

With this in mind, the draft will incorporate Option 3.

Yakov.
------- Forwarded Message

Date:    Tue, 19 Feb 2002 16:26:49 -0800
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
cc:      Jeffrey Haas <[email-masked]>, [email-masked]
Subject: processing order of reach/unreach in rfc2858bis

Folks,

I see at least three options on how to deal with this:

Option 1:

   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.

Option 2:

   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.

Option 3:

   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.

Perhaps it is time to poll for a "rough consensus". So, please
send me an e-mail stating your first and second choices. The
deadline for this is March 6, 2002.

Yakov.

------- End of Forwarded Message

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: Enke Chen <[email-masked]>, "Venu Kumar G - CTD, Chennai." <[email-masked]>
Cc: [email-masked]
Subject: RE: 4 Byte AS no AGGREGATOR attribute ignoring. 
Date: Thu, 14 Mar 2002 11:15:55 +0530
Sender: [email-masked]

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 9:41 PM
To: Venu Kumar G - CTD, Chennai.
Cc: [email-masked]; [email-masked]
Subject: Re: 4 Byte AS no AGGREGATOR attribute ignoring. 

Hi, Venu:

> Message-ID: <D11B30C7348BD511A40700010283497B5648A6@GAYATRI>
> From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
> To: [email-masked]
> Subject: 4 Byte AS no AGGREGATOR attribute ignoring.
> Date: Wed, 13 Mar 2002 16:41:01 +0530
> 
>  Section  4.2.3  Last Paragraph of   4 octet As number.
> 
> "Simillaly  a NEW BGP speaker  should be  prepared to  receive the NEW_
> AGGREGATOR attribute from an OLD BGP speaker.  In that case, the
AGGREGATOR
> attribute  is ignored and the  NEW_AGGREGATOR  contains the exact
> information about  the aggregation node. "
> 
> "Simillaly  a NEW BGP speaker  should be  prepared to  receive the NEW_
> AGGREGATOR attribute from an OLD BGP speaker.  In that case, the
AGGREGATOR
> attribute  is ignored  only if it's AS no is   AS_TRANS  and the
> NEW_AGGREGATOR  contains the exact information about  the aggregation
node. 
> 
>       To give an example for this scenariao 
> 
>             4-byte ------------   2 byte ---------------- 4 byte
>               AS1                      AS2                        AS3
> 
>          In the above setup, assume the case where aggregation is done on
> the AS1   and then on the AS2  before to advetise the route  X  to AS3.
Now
> AS3 received X route  AGGREGATOR attribute is valid one, NEW_AGGREGATOR is
> invalid.

Enke> The NEW_AGGREGATOR attribute is an unknown attribute for AS2. Most
likely
Enke> the unknown attribute may not be preserved during aggregation. Even if
it
Enke> is, there does not seem to be any harm. The usefulness of the
AGGREGATOR
Enke> attribute is really very, very limited.

       NEW_AGGREGATOR attribute is optional transtive, So AS2 will be
passing all the transtive
attribute to other external speakers.   
       If we take the above example more detaily, X is aggregated entry
(x/14) added at  AS2.  Say now AS1 also has added an aggregated enty for
X/16, Now AS1 will send the update packet to AS2 with AGGREGATOR attribute
containing it's AS no as AS_TRANS and NEW_AGGREGATOR attribute contains the
exact  4 byte AS number.   Now AS2 is also doing the aggregation for same
route X route with less prefix, Here it will ignore all the AGGREGATOR
attributes of aggregating routes by adding new AGGREGATOR attribute, But
not NEW_AGGREGATOR attribute, the reason it is a transtive optional
attribute,  So it will add the same to the aggregating route which it sends
to AS3. (It is the same the case of  all transtive community  attributes of
aggregating routes  adding to aggregated route community path attribute).
 
       AS3 should only ignore the AGGREGATOR attribute, when AGGREGATOR
attribute AS no value is 
AS_TRANS.  If that is not the case it should ignore the NEW_AGGREGATOR
attribute, which is invalid attribute passed to AS3 from AS2.  

Regards
Venu G.

-- Enke

To: "Venu Kumar G - CTD, Chennai." <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: 4 Byte AS no AGGREGATOR attribute ignoring. 
Date: Wed, 13 Mar 2002 08:10:40 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Venu:

> Message-ID: <D11B30C7348BD511A40700010283497B5648A6@GAYATRI>
> From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
> To: [email-masked]
> Subject: 4 Byte AS no AGGREGATOR attribute ignoring.
> Date: Wed, 13 Mar 2002 16:41:01 +0530
> 
>  Section  4.2.3  Last Paragraph of   4 octet As number.
> 
> "Simillaly  a NEW BGP speaker  should be  prepared to  receive the NEW_
> AGGREGATOR attribute from an OLD BGP speaker.  In that case, the AGGREGATOR
> attribute  is ignored and the  NEW_AGGREGATOR  contains the exact
> information about  the aggregation node. "
> 
> "Simillaly  a NEW BGP speaker  should be  prepared to  receive the NEW_
> AGGREGATOR attribute from an OLD BGP speaker.  In that case, the AGGREGATOR
> attribute  is ignored  only if it's AS no is   AS_TRANS  and the
> NEW_AGGREGATOR  contains the exact information about  the aggregation node. 
> 
>       To give an example for this scenariao 
> 
>             4-byte ------------   2 byte ---------------- 4 byte
>               AS1                      AS2                        AS3
> 
>          In the above setup, assume the case where aggregation is done on
> the AS1   and then on the AS2  before to advetise the route  X  to AS3.  Now
> AS3 received X route  AGGREGATOR attribute is valid one, NEW_AGGREGATOR is
> invalid.

The NEW_AGGREGATOR attribute is an unknown attribute for AS2. Most likely
the unknown attribute may not be preserved during aggregation. Even if it
is, there does not seem to be any harm. The usefulness of the AGGREGATOR
attribute is really very, very limited.

-- Enke

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: [email-masked]
Subject: 4 Byte AS no AGGREGATOR attribute ignoring.
Date: Wed, 13 Mar 2002 16:41:01 +0530
Sender: [email-masked]

 Section  4.2.3  Last Paragraph of   4 octet As number.

"Simillaly  a NEW BGP speaker  should be  prepared to  receive the NEW_
AGGREGATOR attribute from an OLD BGP speaker.  In that case, the AGGREGATOR
attribute  is ignored and the  NEW_AGGREGATOR  contains the exact
information about  the aggregation node. "

"Simillaly  a NEW BGP speaker  should be  prepared to  receive the NEW_
AGGREGATOR attribute from an OLD BGP speaker.  In that case, the AGGREGATOR
attribute  is ignored  only if it's AS no is   AS_TRANS  and the
NEW_AGGREGATOR  contains the exact information about  the aggregation node. 

      To give an example for this scenariao 

            4-byte ------------   2 byte ---------------- 4 byte
              AS1                      AS2                        AS3

         In the above setup, assume the case where aggregation is done on
the AS1   and then on the AS2  before to advetise the route  X  to AS3.  Now
AS3 received X route  AGGREGATOR attribute is valid one, NEW_AGGREGATOR is
invalid.
 
regards
Venu G.

Disclaimer:
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.

From: "Ken Benstead" <[email-masked]>
To: "Bruno Rijsman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Oversight in answer
Date: Tue, 12 Mar 2002 14:19:41 -0500
Importance: Normal
Sender: [email-masked]

Hi Bruno,

Thanks again.

Are your answers captured in RFCs somewhere or are they common, but
unpublished, knowledge?

Ken

> -----Original Message-----
> From: Bruno Rijsman [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2002 11:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Oversight in answer
>
>
> Hi Ken,
>
> I just noticed an oversight in my answer:
>
> >It must accept both formats and it can freely choose which format it
> >uses for sending IPv4-unicast routes.
>
> should be
>
> It must accept both formats for received routes.
>
> If the peer advertised the MPE capability for any AF, it can
> freely choose
> which format it uses for sending IPv4-unicast routes to that peer.
>
> If the peer did not advertise the MPE capability for any AF, it
> must use the
> traditional (non MP-(UN)REACH) format for sending IPv4-unicast routes to
> that peer.
>
> PS - Most vendors I know always use the traditional format for
> IPv4 unicast
> routes.
>
> -- Bruno
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: RE: Route Refresh and Multiprotocol Extensions Questions
Date: Tue, 12 Mar 2002 11:13:50 -0500
Importance: Normal
Sender: [email-masked]

Bruno,
Thankyou for your prompt response. I didn't find the RFC's very clear on
these issues.
Ken
> -----Original Message-----
> From: Bruno Rijsman [mailto:[email-masked]]
> Sent: Monday, March 11, 2002 5:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject:
>
>
> Ken,
>
> Below I've listed what I think makes sense (I didn't check the letter
> of the drafts / RFCs for this).
>
> Ken> 1) Is it legal for a peer to indicate Route Refresh support but not
> Ken> Multiprotocol Extensions support in its Capabilities
> Ken> Advertisement, or must the two capabilities always be advertised
> Ken> together?
>
> Yes, it is legal to advertise Route Refresh only. A router that does
> so should react to a Route Refresh with AFI=IPv4 SAFI=Unicast and
> ignore all other route refresh messages (at most log a warning)
>
> Ken> 2) If it is legal for a peer to advertise Route Refresh support
> Ken> without MPE support is it safe to assume the peer supports Route
> Ken> Refresh for IPv4 Unicast (AFI/SAFI = 1/1)?
>
> Yes.
>
> Ken> 4) If a peer supports Capabilities Advertisement must it always
> Ken> advertise Multiprotocol support, even if it is only for IPv4
> Ken> Unicast?
>
> No. If MultiProtocol is not advertised it must be assumed the BGP
> speaker supports IPv4 unicast only.
>
> Ken> 3) If a peer advertises MPE support for IPV4 Unicast is it free to
> Ken> advertise routes using either the traditional UPDATE format or the
> Ken> MP_(UN)REACH_NLRI format, or must it only use the
> Ken> MP_(UN)REACH_NLRI format? (I assume it should accept both formats.)
>
> It must accept both formats and it can freely choose which format it
> uses for sending IPv4-unicast routes.
>
> -- Bruno
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: Route Refresh and Multiprotocol Extensions Questions
Date: Mon, 11 Mar 2002 17:35:36 -0500
Importance: Normal
Sender: [email-masked]

Hi Folks,
I have a few questions about Route Refresh and Multiprotocol Extensions.
Hopefully someone can set me straight.

1) Is it legal for a peer to indicate Route Refresh support but not
Multiprotocol Extensions support in its Capabilities Advertisement, or must
the two capabilities always be advertised together?

2) If it is legal for a peer to advertise Route Refresh support without MPE
support is it safe to assume the peer supports Route Refresh for IPv4
Unicast (AFI/SAFI = 1/1)?

4) If a peer supports Capabilities Advertisement must it always advertise
Multiprotocol support, even if it is only for IPv4 Unicast?

3) If a peer advertises MPE support for IPV4 Unicast is it free to advertise
routes using either the traditional UPDATE format or the MP_(UN)REACH_NLRI
format, or must it only use the MP_(UN)REACH_NLRI format? (I assume it
should accept both formats.)

Thanks
Ken Benstead

To: IDR mailing list <[email-masked]>
Subject: Site of Origin attribute
From: Kaarthik Sivakumar <[email-masked]>
Date: 11 Mar 2002 10:31:59 -0500
Lines: 12
Sender: [email-masked]

Hi folks

I have a question about the Site of Origin extended community
attribute for VPNs. How exactly is a Site of Origin attribute assigned
to a site? A vendor I have seen uses route-maps to do set this
attribute on routes coming from a peer (which is the site). Is this
just supposed to be defined by each vendor differently, as long as the
attribute is sent out in the packet and handled by the peers properly?

Thanks

Kaarthik

From: "Shah, VJ" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Need clarification on ORF ( Coperative Route Filter) and Dynamic  Capability 
Date: Mon, 11 Mar 2002 10:18:26 -0500
Sender: [email-masked]

With reference to drafts "draft-ietf-idr-dynamic-cap-01.txt and
"draft-ietf-idr-route-filter-05.txt", I have the following question:

Is dynamic capability supported for Cooperative Route Filters(ORF)?

If yes, It is not clear how to advertise or withdraw ORF capability for a
particular ORF Type in an address family using Dynamic capability. 

Consider the following example:

1) When BGP session is established, we advertise 

ORF capability 
	address family IPV4-Unicast 
		ORF Type: Prefix-List, Send/Receive: Both
            ORF Type: Extended-Community, Send/Receive: Both

2) User turns on ORF capability for Communities on the local BGP system

In this case, using dynamic capability, do we need to advertise all three
Types 

OR 

we advertise only the new type i.e Community Type.

3) Now, the user turns off ORF capability on the local BGP system for ORF
Type: Extended-Community

In this case, do we send a dynamic capability message withdrawing all the
ORF capabilities and then send another capability message advertising the
new set of ORF Types being supported.

OR

Send a Dynamic capability message removing only the Extended Community ORF
Type.  In this case, does the Send/Receive field in Capability data indicate
the mode being withdrawn.

Thanks,

VJ Shah

   

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.

To: "Rijsman, Bruno" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Link bandwidth extended community and 4-octet as-numbers 
Date: Sun, 10 Mar 2002 10:09:44 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Bruno,

> How does the link bandwidth extended community deal with 4-octet AS numbers?

it doesn't.

> The current draft text assumes that the local administrator field is 4
> octets but it is only 2 octets if 4-octet as-numbers are used.
> 
> Relevant quote from draft-ietf-idr-bgp-ext-communities-02:
> 
> 8. Link Bandwidth Community
> 
> [...]
> 
>    The bandwidth of the link is expressed as 4 octets in IEEE floating
>    point format, units being bytes per second. It is carried in the
>    Local Administrator sub-field of the Value Field.
> 
> 
> 
> ======================================= 
> This email message is for the sole use of the intended recipient (s) and may
> contain confidential and privileged information, including without
> limitation, Confidential and/or Proprietary Information belonging to
> Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.

To: "Rijsman, Bruno" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Mistake in extended communities draft? 
Date: Sun, 10 Mar 2002 10:08:29 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Bruno,

> draft-ietf-idr-bgp-ext-communities-02.txt says:
> 
> > The value of the Type field for the Route Target Community is 0x00 or 
> > 0x01. The value of the low-order octet of the extended type field
> > for this community is 0x02. 
> 
> shouldn't this be:
> 
> > The value of the Type field for the Route Target Community is 0x00, 
> > 0x01 or 0x02. The value of the low-order octet of the extended type field
> > for this community is 0x02. 
> 
> Same for route origin and any other extended community.

You are correct. Thanks for pointing this out. We'll fix it in the
next revision of the Internet Draft.

Yakov.

From: "Rijsman, Bruno" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Link bandwidth extended community and 4-octet as-numbers
Date: Fri, 8 Mar 2002 18:46:41 -0500 
Sender: [email-masked]

How does the link bandwidth extended community deal with 4-octet AS numbers?
The current draft text assumes that the local administrator field is 4
octets but it is only 2 octets if 4-octet as-numbers are used.

Relevant quote from draft-ietf-idr-bgp-ext-communities-02:

8. Link Bandwidth Community

[...]

   The bandwidth of the link is expressed as 4 octets in IEEE floating
   point format, units being bytes per second. It is carried in the
   Local Administrator sub-field of the Value Field.

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.

From: "Rijsman, Bruno" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Mistake in extended communities draft?
Date: Fri, 8 Mar 2002 17:03:48 -0500 
Sender: [email-masked]

draft-ietf-idr-bgp-ext-communities-02.txt says:

> The value of the Type field for the Route Target Community is 0x00 or 
> 0x01. The value of the low-order octet of the extended type field
> for this community is 0x02. 

shouldn't this be:

> The value of the Type field for the Route Target Community is 0x00, 
> 0x01 or 0x02. The value of the low-order octet of the extended type field
> for this community is 0x02. 

Same for route origin and any other extended community.

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.

From: "Jin Ko" <[email-masked]>
To: "'NetProtocols Engineer'" <[email-masked]>, <[email-masked]>
Subject: RE: bgp synchronization ...
Date: Thu, 7 Mar 2002 10:02:29 +0900
Importance: Normal
Sender: [email-masked]

AFAIK,  after receiving an update and before placing it into the local
routing table or advertising to its bgp peer.
Thus #2 is the answer.  I guess.

-jin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of NetProtocols Engineer
> Sent: Thursday, March 07, 2002 4:33 AM
> To: [email-masked]
> Subject: bgp synchronization ...
> 
> 
> A basic question about BGP:
> 
> Where exactly should the synchronization check be done:
> 1. when you receive an update?
> 2. when you are ready to put the route into your local-rib?
> 
> Thanks for your help.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email! 
http://mail.yahoo.com/

Date: Wed, 6 Mar 2002 11:32:48 -0800 (PST)
From: NetProtocols Engineer <[email-masked]>
Subject: bgp synchronization ...
To: [email-masked]
Sender: [email-masked]

A basic question about BGP:

Where exactly should the synchronization check be done:
1. when you receive an update?
2. when you are ready to put the route into your local-rib?

Thanks for your help.

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

Date: Tue, 5 Mar 2002 10:50:02 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RFC Violation
Sender: [email-masked]

Alex Zinin writes:

> Pedro,

>  I see your point. Note that when you are sending a WITHDRAWN, you
> know it is a bad news.

Alex,
A link up event will often cause a router to send withrawns as it
changes it's best path from one that it's policy and/or ibgp flooding
rules allow it to advertise to one that is rejected.

The inverse is true for a link down event...

I still maintain that it is not possible in BGP to distinguish if an
update corresponds to a link up/down event... or what information you
wish to send fast/slow.

I also believe that it is a major mistake to threat advertisements
differently than withrawns, specially from a queuing/timing point of
view. The only thing you are going to get out of that is weird
blackholes and more instability...

AFAIK, no major vendor implements their advertisement
rate-controller/queueing in a way as to threat updates and withrawns
differently.

  Pedro.

Date: Tue, 5 Mar 2002 10:29:06 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Pedro Roque Marques <[email-masked]>
Cc: BJ Premore <[email-masked]>, Mareline Sheldon <[email-masked]>, <[email-masked]>
Subject: Re: RFC Violation
Sender: [email-masked]

Pedro,

 I see your point. Note that when you are sending a WITHDRAWN,
 you know it is a bad news.

-- 
Alex Zinin

Monday, March 04, 2002, 2:12:25 PM, Pedro Roque Marques wrote:

> Alex Zinin writes:

>> Pedro,

>>> I wonder when was that change in the spec introduced

>> It's there in 1771, and just went to the new spec.

> Mea culpa then...

>>>  and what was the rational... it doesn't really reflect deployed
>>> implementations and imho it is the wrong thing to do.

>> The rational matches the "bad news travel fast, good news travel
>> slow" principle. If you believe this does not reflect the
>> implementations, let's see what people say and, if this is the case,
>> we should make it a "MAY" in the new spec.

> Alex,

> The following advertisement

> NLRI 10/8
> AS-PATH 1 I

> When received by a router of AS 1 this is taken an an implicit
> withrawn... is this good news or bad ?

> You may have the following scenario:

>         ibgp1

>                         ibgp3
>         ibgp2

> ibgp1 has an nlri with med 1
> ibgp2 has the same nlri with med 5

> On receipt of withrawn from ibgp1, ibgp2 will advertise it's
> information to ibgp3...

> is the withrawn good or bad news and how should i figure out which
> case it is ?

> BGP does not follow the same logic than for instance IGPs that report
> link up and link down... BGP advertises change sets on NLRI which do
> not have enought information for you to deduce if they resulted in a
> link up or down event (which is a feature)...

>>> In BGP there is no difference between a WITHRAWN and an
>>> UPDATE... the receipt of an WITHRAWN can result in an update and
>>> vice versa... It is the same information, just encoded in a
>>> different field. imho, whenever one threats them differently that
>>> is a bug...

>> RFC2439?

> Flap dampening deals not with how information is encoded but with
> present or absence of a route in the table...  in my first example of
> a poisoned update, if this is the last update dampening will treat it
> as a down event on the route...

>   Pedro.

Date: Mon, 4 Mar 2002 14:12:25 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Pedro Roque Marques <[email-masked]>, BJ Premore <[email-masked]>, Mareline Sheldon <[email-masked]>, <[email-masked]>
Subject: Re: RFC Violation
Sender: [email-masked]

Alex Zinin writes:

> Pedro,

>> I wonder when was that change in the spec introduced

> It's there in 1771, and just went to the new spec.

Mea culpa then...

>>  and what was the rational... it doesn't really reflect deployed
>> implementations and imho it is the wrong thing to do.

> The rational matches the "bad news travel fast, good news travel
> slow" principle. If you believe this does not reflect the
> implementations, let's see what people say and, if this is the case,
> we should make it a "MAY" in the new spec.

Alex,

The following advertisement

NLRI 10/8
AS-PATH 1 I

When received by a router of AS 1 this is taken an an implicit
withrawn... is this good news or bad ?

You may have the following scenario:

	ibgp1

			ibgp3
	ibgp2

ibgp1 has an nlri with med 1
ibgp2 has the same nlri with med 5

On receipt of withrawn from ibgp1, ibgp2 will advertise it's
information to ibgp3...

is the withrawn good or bad news and how should i figure out which
case it is ?

BGP does not follow the same logic than for instance IGPs that report
link up and link down... BGP advertises change sets on NLRI which do
not have enought information for you to deduce if they resulted in a
link up or down event (which is a feature)...

>> In BGP there is no difference between a WITHRAWN and an
>> UPDATE... the receipt of an WITHRAWN can result in an update and
>> vice versa... It is the same information, just encoded in a
>> different field. imho, whenever one threats them differently that
>> is a bug...

> RFC2439?

Flap dampening deals not with how information is encoded but with
present or absence of a route in the table...  in my first example of
a poisoned update, if this is the last update dampening will treat it
as a down event on the route...

  Pedro.

Date: Mon, 4 Mar 2002 13:25:57 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Pedro Roque Marques <[email-masked]>
Cc: BJ Premore <[email-masked]>, Mareline Sheldon <[email-masked]>, <[email-masked]>
Subject: Re: RFC Violation
Sender: [email-masked]

Pedro,

> I wonder when was that change in the spec introduced

It's there in 1771, and just went to the new spec.

>  and what was the
> rational... it doesn't really reflect deployed implementations and
> imho it is the wrong thing to do.

The rational matches the "bad news travel fast, good news travel
slow" principle. If you believe this does not reflect the
implementations, let's see what people say and, if this is the
case, we should make it a "MAY" in the new spec.

> In BGP there is no difference between a WITHRAWN and an UPDATE... the
> receipt of an WITHRAWN can result in an update and vice versa... It is
> the same information, just encoded in a different field. imho,
> whenever one threats them differently that is a bug...

RFC2439?

>>> If you must err... err on the side of stability of the network.

>> You probably mean the other way around, no?

> I mean that if you must make a guess make it so in favor of stability...

We're in sync here.

Alex

Date: Mon, 4 Mar 2002 13:06:51 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: BJ Premore <[email-masked]>, Mareline Sheldon <[email-masked]>, <[email-masked]>
Subject: Re: RFC Violation
Sender: [email-masked]

Alex Zinin writes:

> Pedro,

>> If you use min advertisement interval you should apply it to any
>> UPDATE of that NLRI to the peer being it a reachable or unreachable
>> NLRI.

> Is this a proposed change to the spec? draft-ietf-idr-bgp4-17.txt:

>     Since fast convergence is needed within an autonomous system,
> this procedure does not apply for routes received from other
> internal peers.  To avoid long-lived black holes, the procedure does
> not apply to the explicit withdrawal of unfeasible routes (that is,
> routes whose destinations (expressed as IP prefixes) are listed in
> the WITHDRAWN ROUTES field of an UPDATE message).

I wonder when was that change in the spec introduced and what was the
rational... it doesn't really reflect deployed implementations and
imho it is the wrong thing to do.

In BGP there is no difference between a WITHRAWN and an UPDATE... the
receipt of an WITHRAWN can result in an update and vice versa... It is
the same information, just encoded in a different field. imho,
whenever one threats them differently that is a bug...

>> That is the worse thing you can do to the network in this
>> situation. Min advertisemente interval is ment as a stabilization
>> feature on the network... the usual tradeoff of convengence speed
>> vs stability. You should not be using the min advertisement
>> interval as a reason to create an extra flap of the route... it
>> defeats the purpose completly.

>> If you must err... err on the side of stability of the network.

> You probably mean the other way around, no?

I mean that if you must make a guess make it so in favor of stability...

Convergence time is really a false god...

  Pedro.

Date: Mon, 4 Mar 2002 12:45:20 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Pedro Roque Marques <[email-masked]>
Cc: BJ Premore <[email-masked]>, Mareline Sheldon <[email-masked]>, <[email-masked]>
Subject: Re: RFC Violation
Sender: [email-masked]

Pedro,

> If you use min advertisement interval you should apply it to any
> UPDATE of that NLRI to the peer being it a reachable or unreachable NLRI.

Is this a proposed change to the spec? draft-ietf-idr-bgp4-17.txt:

    Since fast convergence is needed within an autonomous system, this
    procedure does not apply for routes received from other internal
    peers.  To avoid long-lived black holes, the procedure does not apply
    to the explicit withdrawal of unfeasible routes (that is, routes
    whose destinations (expressed as IP prefixes) are listed in the
    WITHDRAWN ROUTES field of an UPDATE message).

> That is the worse thing you can do to the network in this
> situation. Min advertisemente interval is ment as a stabilization
> feature on the network... the usual tradeoff of convengence speed vs
> stability. You should not be using the min advertisement interval as a
> reason to create an extra flap of the route... it defeats the purpose
> completly.

> If you must err... err on the side of stability of the network.

You probably mean the other way around, no?

Alex

Date: Mon, 4 Mar 2002 11:17:39 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: BJ Premore <[email-masked]>
Cc: Mareline Sheldon <[email-masked]>, [email-masked]
Subject: Re: RFC Violation
Sender: [email-masked]

BJ Premore writes:

>>>>>> "ms" == Mareline Sheldon <[email-masked]> writes:
ms> Then it means that my implementation MUST not send a withdraw
ms> message followed by an UPDATE message. Right?

> I encountered a closely related issue while implementing the BGP
> model in the SSFNet simulator (see ssfnet.org).  Suppose a BGP
> router B1 receives a withdrawal for route r1 to destination prefix
> p, and route r2 is chosen from the RIB to replace it.  According to
> the RFC, withdrawals to other peers should be sent immediately by B1
> for route r1.  However, what if the Minimum Route Advertisement
> Interval for peer B2 prevents an advertisement for r2 from being
> sent immediately?

If you use min advertisement interval you should apply it to any
UPDATE of that NLRI to the peer being it a reachable or unreachable NLRI.

>  An advertisement for r2 (which would serve as the
> implicit withdrawal of r1) cannot be sent to B2 until that timer
> expires.  To comply with the RFC (as I understand it), a withdrawal
> should be sent immediately, and then the new advertisement should be
> sent once the timer expires.

That is the worse thing you can do to the network in this
situation. Min advertisemente interval is ment as a stabilization
feature on the network... the usual tradeoff of convengence speed vs
stability. You should not be using the min advertisement interval as a
reason to create an extra flap of the route... it defeats the purpose
completly.

If you must err... err on the side of stability of the network.

>  However, this seems undesirable since
> it would appear to peer B2 that during the time between the
> withdrawal and the new advertisement, no route existed through B1
> for destination prefix p.

> Another option is to wait until the timer expires before sending any
> messages, and then send the advertisement for r2 (implying the
> withdrawal of r1). 

Yes. That is the correct aproach.

> Now, during the time when r2 was chosen to
> replace r1 and the time that the advertisement for r2 was actually
> sent, peer B2 would actually think it was still using r1 when it was
> in fact using r2.

Using a delay mechanism on route updates such as min advertisement
interval has that sort of consequences.

>  This is still not ideal since B2's policy
> configuration might actually have denied r2.

One more reason to threat bgp NLRI information (positive or negative
advertisements) just the same way...

  Pedro.

Date: Mon, 4 Mar 2002 13:49:00 -0500
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC Violation
From: BJ Premore <[email-masked]>
Organization: Dartmouth College Department of Computer Science
Sender: [email-masked]

>>>>> "ms" == Mareline Sheldon <[email-masked]> writes:

 ms> Then it means that my implementation MUST not send a
 ms> withdraw message followed by an UPDATE message. Right?

I encountered a closely related issue while implementing the BGP model
in the SSFNet simulator (see ssfnet.org).  Suppose a BGP router B1
receives a withdrawal for route r1 to destination prefix p, and route
r2 is chosen from the RIB to replace it.  According to the RFC,
withdrawals to other peers should be sent immediately by B1 for route
r1.  However, what if the Minimum Route Advertisement Interval for
peer B2 prevents an advertisement for r2 from being sent immediately?
An advertisement for r2 (which would serve as the implicit withdrawal
of r1) cannot be sent to B2 until that timer expires.  To comply with
the RFC (as I understand it), a withdrawal should be sent immediately,
and then the new advertisement should be sent once the timer expires.
However, this seems undesirable since it would appear to peer B2 that
during the time between the withdrawal and the new advertisement, no
route existed through B1 for destination prefix p.

Another option is to wait until the timer expires before sending any
messages, and then send the advertisement for r2 (implying the
withdrawal of r1).  Now, during the time when r2 was chosen to replace
r1 and the time that the advertisement for r2 was actually sent, peer
B2 would actually think it was still using r1 when it was in fact
using r2.  This is still not ideal since B2's policy configuration
might actually have denied r2.

I don't know if there are better ways to handle this than these two
options.

-BJ

BJ Premore -- [email-masked] -- http://www.cs.dartmouth.edu/~beej/
grad student, Computer Science Dept, Dartmouth College, Hanover, NH, USA

Date: Sat, 2 Mar 2002 23:06:10 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC Violation
Sender: [email-masked]

Mareline,

> Then it means that my implementation MUST not send a withdraw message followed by an UPDATE
> message. Right?

If you're looking for a reason to implement it the way the spec says,
then yes :)

Formally, use of requirement levels in 1771 was not normilized by 2119 (as
the numbers suggest). It seems to me that this part is more likely to be
treated as a SHOULD per 2119, specifically:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

i.e., you would still be interoperable with others if you didn't
follow the recommendation, but this would affect protocol convergence
and the ammount of work you put on your peers (think about transition
states your peers [and their peers] would go through).

Alex

Date: Sat, 2 Mar 2002 22:20:48 -0800 (PST)
From: Mareline Sheldon <[email-masked]>
Subject: Re: RFC Violation
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Alex,
Then it means that my implementation MUST not send a withdraw message followed by an UPDATE
message. Right?

Can the authors of the rfc and subsequent drafts be more explicit on this?

regards,
mareline s.

--- Alex Zinin <[email-masked]> wrote:
> 
> Mareline,
> 
>  I would be worried not about violation of the spec (though
>  shall is normally treated as a must), but rather about what
>  is the proper way of doing this. The answer here is send
>  the replacement route.
> 
>  BTW, looking at the text of the new spec
>  (draft-ietf-idr-bgp4-17.txt), here's what we have:
> 
> >    As part of Phase 3 of the route selection process, the BGP speaker
> >    has updated its Adj-RIBs-Out. All newly installed routes and all
> >    newly unfeasible routes for which there is no replacement route shall
> >    be advertised to its peers by means of an UPDATE message.
> 
>  ... I would rather have something more explicit about the issue
>  in subject of this thread.
> 
> -- 
> Alex Zinin
> 
> Saturday, March 02, 2002, 8:30:52 PM, Mareline Sheldon wrote:
> 
> > Deepak,
> > section 9.2.1 of rfc 1771 says that 
> > "When a BGP speaker receives an UPDATE message with a non-empty
> > WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
> > routes whose destinations was carried in this field (as IP prefixes).
> > The speaker shall take the following additional steps:
> 
> > 1) .. 
>       
> > 2) if the corresponding feasible route had been previously
> >       advertised, then:
> 
> >          i) if a new route is selected for advertisement that has the
> >          same Network Layer Reachability Information as the unfeasible
> >          routes, then the local BGP speaker shall advertise the replacement route"
> >                                             ^^^^^
> 
> > Note the "shall" in point (i). However what is confusing me is the fact that there is no
> > "must" here! I am still unclear on whether i shall be violating the protocol or not!
> 
> > can others help?
> 
> > regards,
> > mareline s.
> 
> > Deepak says:
> 
> >> Not really. Its same as if you have learned the second best route after some time. RFC
> 1771
> >>suggests to send an implicit withdrawl just to save the bandwidth but it doesn't forces
> you 
> >>to do so.
> >>  
> >> Deepak Srivastava,
> >> Communication Group,
> >> Infosys Technologies Ltd.
> 
> 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Sports - sign up for Fantasy Baseball
> > http://sports.yahoo.com
> 
> 

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Date: Sat, 2 Mar 2002 22:13:11 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Subject: MUST/SHOULD/MAY normalization in draft-ietf-idr-bgp4-17.txt
Sender: [email-masked]

 Has there been any discussion on doing <subject> to
 follow 2119? Lower and upper case versions are used
 interchangeably in the document both in the prose and
 in the real requirements definitions...

-- 
Alex Zinin

Date: Sat, 2 Mar 2002 22:08:20 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: RFC Violation
Sender: [email-masked]

Mareline,

 I would be worried not about violation of the spec (though
 shall is normally treated as a must), but rather about what
 is the proper way of doing this. The answer here is send
 the replacement route.

 BTW, looking at the text of the new spec
 (draft-ietf-idr-bgp4-17.txt), here's what we have:

>    As part of Phase 3 of the route selection process, the BGP speaker
>    has updated its Adj-RIBs-Out. All newly installed routes and all
>    newly unfeasible routes for which there is no replacement route shall
>    be advertised to its peers by means of an UPDATE message.

 ... I would rather have something more explicit about the issue
 in subject of this thread.

-- 
Alex Zinin

Saturday, March 02, 2002, 8:30:52 PM, Mareline Sheldon wrote:

> Deepak,
> section 9.2.1 of rfc 1771 says that 
> "When a BGP speaker receives an UPDATE message with a non-empty
> WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
> routes whose destinations was carried in this field (as IP prefixes).
> The speaker shall take the following additional steps:

> 1) .. 
      
> 2) if the corresponding feasible route had been previously
>       advertised, then:

>          i) if a new route is selected for advertisement that has the
>          same Network Layer Reachability Information as the unfeasible
>          routes, then the local BGP speaker shall advertise the replacement route"
>                                             ^^^^^

> Note the "shall" in point (i). However what is confusing me is the fact that there is no
> "must" here! I am still unclear on whether i shall be violating the protocol or not!

> can others help?

> regards,
> mareline s.

> Deepak says:

>> Not really. Its same as if you have learned the second best route after some time. RFC 1771
>>suggests to send an implicit withdrawl just to save the bandwidth but it doesn't forces you 
>>to do so.
>>  
>> Deepak Srivastava,
>> Communication Group,
>> Infosys Technologies Ltd.

> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - sign up for Fantasy Baseball
> http://sports.yahoo.com

Date: Sat, 2 Mar 2002 20:30:52 -0800 (PST)
From: Mareline Sheldon <[email-masked]>
Subject: RE: RFC Violation
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Deepak,
section 9.2.1 of rfc 1771 says that 
"When a BGP speaker receives an UPDATE message with a non-empty
WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
routes whose destinations was carried in this field (as IP prefixes).
The speaker shall take the following additional steps:

1) .. 
      
2) if the corresponding feasible route had been previously
      advertised, then:

         i) if a new route is selected for advertisement that has the
         same Network Layer Reachability Information as the unfeasible
         routes, then the local BGP speaker shall advertise the replacement route"
                                            ^^^^^

Note the "shall" in point (i). However what is confusing me is the fact that there is no
"must" here! I am still unclear on whether i shall be violating the protocol or not!

can others help?

regards,
mareline s.

Deepak says:

> Not really. Its same as if you have learned the second best route after some time. RFC 1771
>suggests to send an implicit withdrawl just to save the bandwidth but it doesn't forces you 
>to do so.
>  
> Deepak Srivastava,
> Communication Group,
> Infosys Technologies Ltd.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

content-class: urn:content-classes:message
Subject: RE: RFC Violation
Date: Sat, 2 Mar 2002 20:08:10 +0530
From: "deepak_srivastava" <[email-masked]>
To: "Mareline Sheldon" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Not really. Its same as if you have learned the second best route after some time. RFC 1771 suggests to send an implicit withdrawl just to save the bandwidth but it doesn't forces you to do so.
 
Deepak Srivastava,
Communication Group,
Infosys Technologies Ltd.

	-----Original Message----- 
	From: Mareline Sheldon [mailto:[email-masked]] 
	Sent: Sat 3/2/2002 12:39 PM 
	To: [email-masked] 
	Cc: 
	Subject: RFC Violation

	Hi,
	Say i have two routes to reach x.y.z.w/n. One of them
	is the best and i install it and announce this to my
	connected peers. Now if this route goes down and if i
	then send a withdraw message first to my peers and
	then later the second best route i have. Is this
	implementation violating the rfc?
	
	As i understand, the rfc says that when the best route
	goes down i must send an implicit withdraw to my peers
	stating the second best route i have.
	
	If i dont do this and i do it the former way, am i
	violating the rfc 1771?
	
	thanks and regards,
	mareline s.
	
	__________________________________________________
	Do You Yahoo!?
	Yahoo! Sports - sign up for Fantasy Baseball
	http://sports.yahoo.com

Date: Fri, 1 Mar 2002 23:09:55 -0800 (PST)
From: Mareline Sheldon <[email-masked]>
Subject: RFC Violation
To: [email-masked]
Sender: [email-masked]

Hi,
Say i have two routes to reach x.y.z.w/n. One of them
is the best and i install it and announce this to my
connected peers. Now if this route goes down and if i
then send a withdraw message first to my peers and
then later the second best route i have. Is this
implementation violating the rfc?

As i understand, the rfc says that when the best route
goes down i must send an implicit withdraw to my peers
stating the second best route i have.

If i dont do this and i do it the former way, am i
violating the rfc 1771?

thanks and regards,
mareline s.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com