Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Date: Mon, 1 Mar 2004 06:42:23 +0200 (EET)
List-Id: Inter-Domain Routing <idr.ietf.org>

FWIW, I do ot believe my re-opening this issue -- has been addressed.

In short, there are very valid operational requirements why BGP should 
consider route of any protocol, not just BGP, as active.  (This is the 
problem with point-to-point and loopback addresses.)

I can also raise this issue at IETF LC, or later at IESG review time,
of course.

My first message below.
====
Date: Tue, 7 Oct 2003 22:56:30 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: issue 11.2: active route, again [Re: comments on idr-bgp4-20]

Hi again,

[clipping the quote down]

On Tue, 30 Sep 2003, Yakov Rekhter wrote:
[...]
> From draft-ietf-idr-bgp-issues-01.txt:
> 
>    After some additional discussion (in the "issue 11.2" thread), we
>    have come to a consensus on this text:
>    
>    In the context of this document we assume that a BGP speaker
>    advertises to its peers only those routes that it itself uses (in
>    this context a BGP speaker is said to "use" a BGP route if it is the 
>    most preferred BGP route and is used in forwarding). All other cases
>    are outside the scope of this document.
>    
>    This issue is at consensus.
> 
> So, the text in the spec represents consensus of the WG. Also note
> the last sentence in the above paragraph.

I've looked at the several threads in the archives, which do not seem to 
address the relevant points at all.

So, I think the issue needs to be reconsidered.

For example, consider a scenario of three routers in two ASs:

 rtr1 |      | rtr2 --- rtr3
 AS1  | ---- | AS2      AS2
 -----'      '-----

rtr3 is configured to advertise prefix 1.0.0.0/8 using BGP.  It has an
IBGP session to rtr2, where it will advertise it.  The AS2 also has an 
IGP, which includes only the loopbacks and point-to-point addresses of the 
AS.

IBGP also includes the loopback addresses and point-to-point addresses.
AS2 also wants to advertise the loopback addresses and PtP's to AS1 using
specific communities marked at the routers.  (There are multiple reasons
advertising loopbacks/ptps such is desirable.. for example, our network
employs private AS numbers and eBGP sessions and this is vital.)

Now, rtr2 advertises the prefix 1.0.0.0/8 just fine using eBGP to rtr1, 
but the loopback addresses and PtP's won't get advertised because the IGP 
is more preferred, and for BGP's perspective, the BGP routes are not 
"active".

Workarounds to this issue exist:
 - use an implementation-specific clause like "advertise-inactive", 
breaking the spec, to advertise them anyway, or
 - redistribute the IGP routes to BGP at the border router rtr2, losing 
communities etc. markings of iBGP in the process.  Ugly.

What I'm arguing here that there seem to be very clear operational reasons
why the "BGP route must be used for forwarding" is very counterproductive
and we should fix/clarify the spec to have a more useful definition for
it.

Are there any killer arguments why this is *NOT* a good idea?
======

---------- Forwarded message ----------
Date: Thu, 9 Oct 2003 19:36:49 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route,
     again [Re: comments on idr-bgp4-20]

On Wed, 8 Oct 2003, Pedro Roque Marques wrote:
> Pekka Savola writes:
> > On Tue, 7 Oct 2003, Pedro Roque Marques wrote:
> >> Pekka Savola writes: > Are there any killer arguments why this is
> >> *NOT* a good idea?
> >> 
> >> The main objective of BGP is to make sure that there are no routing
> >> or forwarding loops. When BGP advertises a route that is not in the
> >> forwarding table those guarantees disapear.
> 
> > The route to the same prefix (and in this case, the same nexthop as
> > well) _is_ in the forwarding table.
> 
> - BGP shouldn't be required to understand which next-hops other
> protocols use.

Who said it would have to?  All it has to do it to look at the forwarding 
table, which it must be able to do anyway.

> - Given that it typically doesn, and actually typically a route w/
> another protocol as a different next-hop, there is no way to guarantee
> that you will not have routing/forwarding loops.

I think the practice has shown this does not occur.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Susan Hares" <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG
Sender: [email-masked]
Date: Mon, 1 Mar 2004 13:16:14 +0900

For information, the following two documents are not in the IETF draft
repository--

> 6) BGP 4 Implementation Report             draft-ietf-idr-bgp-implementation-00.txt
> 7) BGP-4 V1 MIB implementation report      draft-ietf-idr-bgp-mibagent-survey-01.txt

--we'll have to wait until they are available before we can put them in the
bundle and start the IETF LC on the whole group.

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Subject: [Idr] Reminder
Sender: [email-masked]
Date: Sun, 29 Feb 2004 21:54:53 -0500

IDR agenda is **not** posted on the ietf web site.
Please refer to the following web site: 

www.ndzh.com/idr

It has today's agenda.  Follow along or ask questions.

If you want to reach me directly on IM - try 
suehares on AOL during the meeting.

Sue

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Subject: [Idr] FW: Here's the bundle for BGP to go to the IESG
Sender: [email-masked]
Date: Sun, 29 Feb 2004 21:20:13 -0500

At last:

We've submitted the following bundle of 
IDR drafts to the IESG, and are looking forward
to taking new charter items.

Sue and Yakov 

-----Original Message-----
From: Susan Hares 
Sent: Sunday, February 29, 2004 9:01 PM
To: 'Alex Zinin'; Yakov Rekhter
Cc: Bill Fenner
Subject: Here's the bundle for BGP to go to the IESG

Alex: 

The following drafts are a part of the bundle
that needs to go forward:

1) BGP-4 draft-23        	draft-ietf-idr-bgp4-23.txt
2) BGP-4 V1 MIB          	draft-ietf-idr-bgp4-mib-13.txt
3) BGP-4 Protocol Analysis    draft-ietf-idr-bgp-analysis-04.txt
4) BGP Security Vulnerabilities Analysis   draft-ietf-idr-bgp-vuln-00.txt
5) Experience with the BGP-4 Protocol      draft-ietf-idr-bgp4-experience-protocol-03.txt
6) BGP 4 Implementation Report             draft-ietf-idr-bgp-implementation-00.txt
7) BGP-4 V1 MIB implementation report      draft-ietf-idr-bgp-mibagent-survey-01.txt

Sue Hares 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0  routes
Sender: [email-masked]
Date: Sun, 29 Feb 2004 08:21:20 +0200 (EET)

After some off-list iteration, a revamped version of the possible text 
could be:

In certain common deployment scenarios, the next-hop addresses are
supposed to be valid only if resolved via routes of a specific type
(e.g., IGP, connected or local).  There are likely less specific
routes from other sources (e.g., static or BGP) which may resolve the
next-hops as well, but such resolvability typically leads to problems
when the less specific route actually can't be used to reach the
next-hop, and the BGP routes are not invalidated even though their
next-hop is, for all intents and purposes, unroutable.  Therefore, it
is advisable that the implementations allow the operator to specify
which routes should yield a positive result if they covered the the
next-hop.

.. thoughts?  This doesn't have any MAY/SHOULD etc. terminology, at 
least yet -- maybe it should.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pekka Savola <[email-masked]>
To: [email-masked]
cc: "John G. Scudder" <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 
Sender: [email-masked]
Date: Sun, 29 Feb 2004 07:31:33 +0200 (EET)

On Sat, 28 Feb 2004, Curtis Villamizar wrote:
> If the next hop is covered by a discard route it is considered
> unresolvable.  I'm not sure I understand why this is a problem.

No; it's still "resolvable" -- and that's the exact problem here.

> Is there something I'm missing?  Is there actually a legitimate reason
> that you would install a discard route that covered either your BGP
> peer's address or some address that your BGP peer would decide to use
> as a next hop?  Do people normally install discard routes covering
> their IBGP peer's addresses?  [That last one was a bit of a rhetorical
> question].

Discard aggregates, yes -- for example, to originate BGP default 
routes, or to originate a superblock of your addresses.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Yakov Rekhter <[email-masked]>
cc: [email-masked], Pedro Roque Marques <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Sat, 28 Feb 2004 19:25:17 -0500

In message <[email-masked]>, Yakov Rekhter writes
:
> Curtis,
> 
> [clipped...]
>  
> > Pedro,
> > 
> > If you have separate timers for route origination/advertisement and
> > up/down and the best solution is to set them all the same then it is
> > possible to set them all the same.
> > 
> > If you specify that they must be the same and that doesn't turn out to
> > be the best way to do things you are stuck.
> > 
> > Its clear that there isn't agreement on the best solution, so for the
> > time being flexibility is needed.
> 
> One point to keep in mind is that since we are moving the spec to
> a Draft Standard, a *necessary* condition for relaxing the spec to 
> support the flexibility you mentioned above would be more than
> one implementation that supports such flexibility.
> 
> Yakov.

Maybe not if it is a SHOULD and we are acknoledging the work in
Signcomm that indicates that slow propogation of withdraw is bad.
Existing implementations are conforming and there are no
interoperability problems with a timer that can be set to more than
one value.

I understand that you don't want to change the spec.  Again.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Yakov Rekhter <[email-masked]>
cc: [email-masked], Pedro Roque Marques <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Sat, 28 Feb 2004 20:11:45 -0500

In message <[email-masked]>, Yakov Rekhter writes
:
> Curtis,
> 
> > > [clipped...]
> > >  
> > > > Pedro,
> > > > 
> > > > If you have separate timers for route origination/advertisement and
> > > > up/down and the best solution is to set them all the same then it is
> > > > possible to set them all the same.
> > > > 
> > > > If you specify that they must be the same and that doesn't turn out to
> > > > be the best way to do things you are stuck.
> > > > 
> > > > Its clear that there isn't agreement on the best solution, so for the
> > > > time being flexibility is needed.
> > > 
> > > One point to keep in mind is that since we are moving the spec to
> > > a Draft Standard, a *necessary* condition for relaxing the spec to 
> > > support the flexibility you mentioned above would be more than
> > > one implementation that supports such flexibility.
> > > 
> > > Yakov.
> > 
> > 
> > Maybe not if it is a SHOULD and we are acknoledging the work in
> > Signcomm that indicates that slow propogation of withdraw is bad.
> > Existing implementations are conforming and there are no
> > interoperability problems with a timer that can be set to more than
> > one value.
> 
> rfc1264 is quite clear on this topic:
> 
>    4) There must be evidence that all features of the protocol have
>       been tested, running between at least two implementations. 
>   
> Note that the above quote does not distinguish between SHOULD
> and MUST features.
> 
> > I understand that you don't want to change the spec.  Again.
> 
> I have no problem with changing the spec, as long as the change
> reflects what is implemented and deployed. 
> 
> Yakov.

Yakov,

The NSS gated BGP at least at one time had a shorter withdraw than
advertise timer.  Both were configurable - all you had to do is
recompile.  :-)

If you have an NSS in your basement we could try to prove
interoperability.  If you need some spaes, I have some RS960 cards or
maybe Mark Knopper can dig one up (literally).  Or we could ask the
Smithsonian if we could borrow theirs for interoperability testing of
a particular feature.  :-)

Or maybe we could leave the spec as is.  Tough call.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
cc: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Sat, 28 Feb 2004 16:34:42 -0800

Curtis,

> > [clipped...]
> >  
> > > Pedro,
> > > 
> > > If you have separate timers for route origination/advertisement and
> > > up/down and the best solution is to set them all the same then it is
> > > possible to set them all the same.
> > > 
> > > If you specify that they must be the same and that doesn't turn out to
> > > be the best way to do things you are stuck.
> > > 
> > > Its clear that there isn't agreement on the best solution, so for the
> > > time being flexibility is needed.
> > 
> > One point to keep in mind is that since we are moving the spec to
> > a Draft Standard, a *necessary* condition for relaxing the spec to 
> > support the flexibility you mentioned above would be more than
> > one implementation that supports such flexibility.
> > 
> > Yakov.
> 
> 
> Maybe not if it is a SHOULD and we are acknoledging the work in
> Signcomm that indicates that slow propogation of withdraw is bad.
> Existing implementations are conforming and there are no
> interoperability problems with a timer that can be set to more than
> one value.

rfc1264 is quite clear on this topic:

   4) There must be evidence that all features of the protocol have
      been tested, running between at least two implementations. 
  
Note that the above quote does not distinguish between SHOULD
and MUST features.

> I understand that you don't want to change the spec.  Again.

I have no problem with changing the spec, as long as the change
reflects what is implemented and deployed. 

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
cc: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Sat, 28 Feb 2004 16:09:24 -0800

Curtis,

[clipped...]
 
> Pedro,
> 
> If you have separate timers for route origination/advertisement and
> up/down and the best solution is to set them all the same then it is
> possible to set them all the same.
> 
> If you specify that they must be the same and that doesn't turn out to
> be the best way to do things you are stuck.
> 
> Its clear that there isn't agreement on the best solution, so for the
> time being flexibility is needed.

One point to keep in mind is that since we are moving the spec to
a Draft Standard, a *necessary* condition for relaxing the spec to 
support the flexibility you mentioned above would be more than
one implementation that supports such flexibility.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Parantap Lahiri <[email-masked]>
cc: "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Sat, 28 Feb 2004 13:24:07 -0500

In message <[email-masked]>, Parantap Lahiri writes
:
> The problem Pekka is describing is definitely a very valid problem which
> exists. I am not sure though if the fix is in some design modifications or
> in fixing the spec itself. 
> 
> The ways to fix it by design modification would be ...
> 
> The router R1 in question resets the BGP next-hop to some secondary loopback
> address which is different from the primary loopback (part of the prefix/16)
> and the secondary loopback address range is only in IGP as discrete /32s,
> this problem might be mitigated. Though it's going to load the IGP with a
> new set of IP prefixes and may be problematic in some situations since some
> IGP protocols have limited capability to carry large number of IP prefixes. 
> 
> The other way to solve it might be a vendor implemented knob, where a
> particular address range (like prefix/16) is never considered while doing
> BGP next hop resolution. Though, I am not sure if this knob would be a part
> of the spec.
> 
> -Parantap

I'm not sure what that has to do with discard routes unless you are
talking about generating an aggregate and the next hop falling into
the unused portion of the aggregate.  If you allow the next hop to
resolved to the unused portion of an aggregated, your implementation
is simply broken.  You can't forward on a aggregate you generate, you
can only forward on the components that make up the aggregate and if
you miss this distinction in your BGP implementation, that is just an
implementation mistake.

If OTOH, some other router did the aggregation and sent the aggregate
into the IGP or IBGP, then the problem is not one that needs to be
fixed in the spec.  If allowing BGP learned routes to resolve BGP next
hops, which is commonly configured, another knob that can be added is
to exclude routes in which the aggregator is in the same AS.  If that
was not sufficient you'd need a knob to exclude specific prefixes.
This is clearly outside of the BGP spec.  It seems to me to be more a
case of adding configuration knobs to cover up the problems caused by
misconfiguration.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Pekka Savola <[email-masked]>
cc: "John G. Scudder" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Sat, 28 Feb 2004 13:05:38 -0500

In message <[email-masked]>, Pekka Savola 
writes:
> 
>    By default, the route resolvability check typically fails if there 
>    exists any less specific route to the next-hop, e.g., if it is 
>    covered by a default discard or an aggregate route.  Therefore, it 
>    SHOULD be configurable which routes are used to check whether the 
>    next-hops are resolvable.  For example, one might want to use only 
>    local, "connected" and IGP routes, or one might want to remove 
>    discard routes from consideration.

If the next hop is covered by a discard route it is considered
unresolvable.  I'm not sure I understand why this is a problem.

I used to be involved in operating a large ISP or two and I can't
remember any instance in which we (intentionally or otherwise)
installed a discard route that covered one of our BGP peers.  If we
did install such a route, that route would have cause so much trouble
that it got removed within minutes and the person that added it would
probably not want to make that fact widely known.

Is there something I'm missing?  Is there actually a legitimate reason
that you would install a discard route that covered either your BGP
peer's address or some address that your BGP peer would decide to use
as a next hop?  Do people normally install discard routes covering
their IBGP peer's addresses?  [That last one was a bit of a rhetorical
question].

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
To: "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>
Cc: [email-masked]
Importance: Normal
Sender: [email-masked]
Date: Fri, 27 Feb 2004 15:26:56 -0500

The problem Pekka is describing is definitely a very valid problem which
exists. I am not sure though if the fix is in some design modifications or
in fixing the spec itself. 

The ways to fix it by design modification would be ...

The router R1 in question resets the BGP next-hop to some secondary loopback
address which is different from the primary loopback (part of the prefix/16)
and the secondary loopback address range is only in IGP as discrete /32s,
this problem might be mitigated. Though it's going to load the IGP with a
new set of IP prefixes and may be problematic in some situations since some
IGP protocols have limited capability to carry large number of IP prefixes. 

The other way to solve it might be a vendor implemented knob, where a
particular address range (like prefix/16) is never considered while doing
BGP next hop resolution. Though, I am not sure if this knob would be a part
of the spec.

-Parantap

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pekka
Savola
Sent: Friday, February 27, 2004 3:01 PM
To: John G. Scudder
Cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

On Fri, 27 Feb 2004, John G. Scudder wrote:
> >.. the problem is that unless you have full routing table in every
> >router, and no default discard/aggregate routes/etc., this works. 
> >Otherwise when your IBGP neighbor goes down, the BGP routes learned
> >from that neighbor stay in the BGP table until the BGP session is
> >reset after 90 seconds or so.  Instead, the routes should immediately
> >be removed from BGP when the loopback address is removed from the IGP.
> 
> I agree with your final sentence; however, I 
> don't understand the other parts of that 
> paragraph, nor how your proposed text would help 
> it.  

Ok.  Let me try to clarify the situation.  Assume router R1 in the AS 
has some a route, route_r1, which it sends to every iBGP router.  
Router R1 goes down.  OSPF notices that R1 has gone down, as its 
loopback address has been removed from OSPF.

Assume that a core router or two in the AS has been set up with a 
couple of "null0" routes, for the purposes of aggregation, or default 
route redistribution, e.g., "prefix/16" or "0/0".

Assume that the nexthop of route_r1 matches these null0 routes.

Now, all other routers in the AS keep route_r1 in their routing table 
as long as the BGP session stays up (some 90 seconds or so), because 
its nexthop, the loopback address of R1 -- while no longer available 
with OSPF, is still recursively resolvable through either one of the 
null0 routes.

This causes a major problem.  This implies that for BGP to function
properly, the loopback or point-to-point addresses MUST NOT have any 
less-specific routes which could be considered unresolvable if the 
main route itself is removed from IGP.

> In fact, I don't think there is a problem in 
> the spec as it stands with IBGP routes which 
> resolve to a loopback -- these are covered by 
> 9.1.2.1(1).  

When the loopback address is removed from OSPF, the next best route is 
the static default discard route (or something like that) -- which is 
an interface route.

> As others have mentioned, if a route 
> resolves to null0 or the like, this is presumably 
> the result of deliberate configuration and 
> certainly not something we want to preclude in 
> the spec.

Yep, this causes a problem with the DDoS mitigation method described 
earlier, so I'm not sure what the right fix is.

However, it clearly seems to call for a requirement to be able to 
specify, somehow, which routes should be used when considering 
resolvability (e.g., just connected and IGP routes, ...).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Pedro Roque Marques <[email-masked]>
cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Fri, 27 Feb 2004 02:22:57 -0500

In message <[email-masked]>, Pedro Roque Mar
ques writes:
> Curtis Villamizar writes:
> 
> > If withdraws propogate faster first the unfeasible AS paths are
> > removed, then the feasible ones start propogating.  The result is
> > some withdraw followed by add but much less AS path change in the
> > presence of cycles.
> 
> The point in which we differ is that you equate withdraws and updates
> w/ unfeasible and feasible paths. I don't believe one can make that
> assumption.
> 
> For a given AS, if you have as input an withdraw that can result in an
> update being generated or vice-versa, depending on the policy.
> 
> You can have a link up event result in withdrawns being generated, and
> a link down event result in updates. In other words the addition of
> feasible paths, can result via policy, in withdrawls.
> 
> > Providing separate timers allows us to defer the question of which
> > is preferable.
> 
> Providing separate timers, imho, will just further confuse the issue
> :-). It has already been showen that there is no single choice of MRAI
> timer that is appropriate for all situations. Now you propose an
> additional one. That is two parameters nobody knows what the optimal
> setting should be.
> 
> Furthermore, i believe that, due to the meshed nature of internet
> connectivity, using different delays may increase the duration of
> transients.
> 
> Lets say that you start w/ a current path through as3 and
> you have a link up event (a) that brings up a prefered path.
> 
> 	      as 3
> 	      |
> 	--a-> as 1 --> as 4
>           
> 	--a-> as 2 --> as 4 
> 
> If a is a peer route for as 1 but a customer route for as 2, then by
> propagating the withdrawl faster you are increasing the transient time
> and causing increase connectivity to create a blackhole for as4.
> 
> imho, currently there is only one good known value for MRAI for both
> updates and withdrawls, and that is 0. Let BGP speakers propagate
> updates as fast as they can, taking into account that BGP itself
> already has embedded flow control mechanisms that allow a receiver to
> pace a sender appropriatly.
> 
> Unfortunatly, even that setting (0) has its drawbacks. One is that
> values should probably be consistent within an as, and there are very
> different interpretations of MRAI between different vendors. The
> second is that in case of MED oscillations, MRAI helps reduce the
> ammount of churn.  
> 
> regards,
>   Pedro.

Pedro,

If you have separate timers for route origination/advertisement and
up/down and the best solution is to set them all the same then it is
possible to set them all the same.

If you specify that they must be the same and that doesn't turn out to
be the best way to do things you are stuck.

Its clear that there isn't agreement on the best solution, so for the
time being flexibility is needed.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "John G. Scudder" <[email-masked]>
cc: Pekka Savola <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Fri, 27 Feb 2004 14:36:28 -0500

In message <p0602040ebc6536bf8c68@[192.168.42.3]>, "John G. Scudder" writes:
> Pekka,
> 
> I'm confused -- to my eye, the spec change you propose:
> 
> At 9:01 AM +0200 2/27/04, Pekka Savola wrote:
> >Hi,
> >
> >We analyzed one source of operational BGP problems and noticed a
> >problem which should be made explicit in the BGP specification.
> >
> >In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1:
> >
> >       2. Routes referencing interfaces (with or without intermediate
> >       addresses) are considered resolvable if the state of the refer-
> >       enced interface is up and IP processing is enabled on this inter-
> >       face.
> >
> >I propose adding something like:
> >
> >             For the purposes of this check, the routes for which
> >       packets are discarded by the router (i.e., "null" or "discard"
> >       routes) SHOULD be considered unresolvable.
> 
> Doesn't correspond to the problem you describe:
> 
> >.. the problem is that unless you have full routing table in every
> >router, and no default discard/aggregate routes/etc., this works. 
> >Otherwise when your IBGP neighbor goes down, the BGP routes learned
> >from that neighbor stay in the BGP table until the BGP session is
> >reset after 90 seconds or so.  Instead, the routes should immediately
> >be removed from BGP when the loopback address is removed from the IGP.
> 
> I agree with your final sentence; however, I 
> don't understand the other parts of that 
> paragraph, nor how your proposed text would help 
> it.  In fact, I don't think there is a problem in 
> the spec as it stands with IBGP routes which 
> resolve to a loopback -- these are covered by 
> 9.1.2.1(1).  As others have mentioned, if a route 
> resolves to null0 or the like, this is presumably 
> the result of deliberate configuration and 
> certainly not something we want to preclude in 
> the spec.
> 
> Maybe you could expand further on what you think the problem is.
> 
> --John
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr

You can never advertise a discard route to a BGP peer which makes
sense but the text in 9.1.2.1 doesn't deal with advertisement.

If you have a discard route, you probably put it there for a reason
and therefore you don't want to exclude that router from the decision
process.  It doesn't really come into play in this decision.  The
discard route would override the best BGP route.  It would often be a
more specific route, maybe a /32.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
cc: [email-masked], Pedro Roque Marques <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Fri, 27 Feb 2004 11:10:09 -0500

In message <[email-masked]>, Robert Raszuk writes:
> Curtis,
> 
> > Where this matters is if there is a cycle:
> > 
> >     AS1  --  AS2  --  AS3  -- AS4  --  AS5  -- ASn  -- back to AS1
> 
> I am glad there seems to be an agreement that providing two timers may 
> matter in the long chain of ASes.
> 
> I also therefor assume that there is an agreement that within single AS 
> or even short chain of 1-3 ASes connected to each other the most 
> practical would be not to introduce two delays one for updates/implicit 
> withdraws and the other for updates with only unreachable routes.
> 
> While maybe in the case you mentioned indeed there could be some 
> benefits but I think correctly setting those timers in an uniform way 
> across all of those ASes is just not possible to be achieved in practice.
> 
> It also seems that different settings in each AS (some of them maybe due 
> to errors) may produce much worse outcome that not using any timer at 
> all. Therefor unless we come up with some auto-tuning way I am not sure 
> if we should treat pure withdraws any different then implicit withdraws 
> or reachability information.
> 
> Rgs,
> R.

Robert,

What I'm saying is we know cases where the impact would be dramatic
and the Craig and Ahba and other Sigcomm papers on BGP performance
show plenty of evidence that these cases quite commonly occur on the
network.

Until the research/standards/operators/vendor community *decides* what
is truly the best way to provide these timers, setting the same for up
and down or different, we should provide the flexibility in the spec
and should provide the flexibility in implementations.

Evidence points to significant benefits to separate timers but that's
not the main issue.  The issue is providing sufficient flexibility
such that if this is beneficial the spec doesn't preclude it.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
cc: Pekka Savola <[email-masked]>, Pedro Roque Marques <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Fri, 27 Feb 2004 13:43:28 -0500

In message <[email-masked]>, Robert Raszuk writes:
> 
> http://www.securite.org/presentations/secip/BHAMS2001-SecIP-v105-full.ppt

Robert,

This file is in some sort of strange proprietary format.  Was that a
mistake?  :-)

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pekka Savola <[email-masked]>
To: "John G. Scudder" <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0  routes
Sender: [email-masked]
Date: Sat, 28 Feb 2004 08:41:33 +0200 (EET)

On Fri, 27 Feb 2004, John G. Scudder wrote:
> >specify, somehow, which routes should be used when considering
> >resolvability (e.g., just connected and IGP routes, ...).
> 
> GateD 3.5.x used to require exactly that.  In my experience this 
> "feature" was by far the single biggest source of operational pain 
> and confusion when using GateD BGP.

Probably yes, if it's the default, and not understood by the users.

> Also, consider that this proposes that the router operator go to some 
> trouble to consider and configure which routes can and can't be used 
> for resolution.  

Any larger network operator already has this kind of consistent 
design: e.g., all the routes are in your IGP, and if they aren't 
that's an error condition which must be fixed.

> That work could (IMO) equally be put into designing 
> their routing such that their infrastructure loopbacks aren't covered 
> by an aggregate.  This has the merit of being something that can be 
> done today with no further spec or implementation work.

The only way to achieve this sensibly would be using some kind of 
private addresses between the iBGP sessions which is IMHO a bad idea 
-- it adds routes to IGP, and you really shouldn't have to be doing 
that in any case.

> More elaborate solutions could certainly be contemplated but I'm not 
> sure they're worth the pain.

IMHO, as this is an obviously a real operational problem, it should be 
mentioned in the BGP spec, at least in some length.  For example, in 
9.1.2.1:

   By default, the route resolvability check typically fails if there 
   exists any less specific route to the next-hop, e.g., if it is 
   covered by a default discard or an aggregate route.  Therefore, it 
   SHOULD be configurable which routes are used to check whether the 
   next-hops are resolvable.  For example, one might want to use only 
   local, "connected" and IGP routes, or one might want to remove 
   discard routes from consideration.

Would something like that make sense?

FWIW, I'm considering whether to start writing a BCP/Info draft on how
to improve your IGP/BGP convergence/stability, and which pitfalls
(like this one!)  to avoid, but that's beyond the scope of this WG. If
anyone has strong feelings whether would be a good or bad idea, send
them to me off-list.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Martin, Christian" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>, "'Pekka Savola'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0   routes
Sender: [email-masked]
Date: Fri, 27 Feb 2004 19:02:05 -0500

John, Pekka,

>Also, consider that this proposes that the router operator go to some 
>trouble to consider and configure which routes can and can't be used 
>for resolution.  That work could (IMO) equally be put into designing 
>their routing such that their infrastructure loopbacks aren't covered 
>by an aggregate.  

I would also argue that it is at best improbable that a loopback is NOT
covered by an aggregate, as usually these addresses are announced for (at a
minimum) ICMP message sources outside the domain.

I must agree that this is out of spec and better suited to a subsequent
applicability statement, or perhaps handled in GROW.  Better yet, let's
leave it to the vendors to implement as a knob.  John, Robert - are you
listening?  ;)

Chris

>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Pekka Savola <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0  routes
Cc: [email-masked]
Sender: [email-masked]
Date: Fri, 27 Feb 2004 15:15:50 -0500

At 10:00 PM +0200 2/27/04, Pekka Savola wrote:
>Ok.  Let me try to clarify the situation.

[thanks, that's clear]

>However, it clearly seems to call for a requirement to be able to
>specify, somehow, which routes should be used when considering
>resolvability (e.g., just connected and IGP routes, ...).

GateD 3.5.x used to require exactly that.  In my experience this 
"feature" was by far the single biggest source of operational pain 
and confusion when using GateD BGP.

Also, consider that this proposes that the router operator go to some 
trouble to consider and configure which routes can and can't be used 
for resolution.  That work could (IMO) equally be put into designing 
their routing such that their infrastructure loopbacks aren't covered 
by an aggregate.  This has the merit of being something that can be 
done today with no further spec or implementation work.

More elaborate solutions could certainly be contemplated but I'm not 
sure they're worth the pain.

--John

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Pekka Savola <[email-masked]>
CC: "John G. Scudder" <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 27 Feb 2004 12:13:57 -0800

Thx Pekka,

 > Assume that the nexthop of route_r1 matches these null0 routes.

Now your issue is clear ;). But it seems to that this is just an 
implementation issue not the spec issue.

Further one operator may need to resolve via a summary route covering 
loopback while someone else may not wish to do so and always INVALIDATE 
all BGP routes when their /32 next hops are removed from IGP. I don't 
think we can put anywhere in the spec a hard line that BGP next hops 
must be valid only if their /32s are in the RIB :).

I don't think any spec update is required. At most simple few lines of 
code in the vendor of your choice ;-).

Cheers,
R.

 > Pekka Savola wrote:
 >
> On Fri, 27 Feb 2004, John G. Scudder wrote:
> 
>>>.. the problem is that unless you have full routing table in every
>>>router, and no default discard/aggregate routes/etc., this works. 
>>>Otherwise when your IBGP neighbor goes down, the BGP routes learned
>>
>>>from that neighbor stay in the BGP table until the BGP session is
>>
>>>reset after 90 seconds or so.  Instead, the routes should immediately
>>>be removed from BGP when the loopback address is removed from the IGP.
>>
>>I agree with your final sentence; however, I 
>>don't understand the other parts of that 
>>paragraph, nor how your proposed text would help 
>>it.  
> 
> 
> Ok.  Let me try to clarify the situation.  Assume router R1 in the AS 
> has some a route, route_r1, which it sends to every iBGP router.  
> Router R1 goes down.  OSPF notices that R1 has gone down, as its 
> loopback address has been removed from OSPF.
> 
> Assume that a core router or two in the AS has been set up with a 
> couple of "null0" routes, for the purposes of aggregation, or default 
> route redistribution, e.g., "prefix/16" or "0/0".
> 
> Assume that the nexthop of route_r1 matches these null0 routes.
> 
> Now, all other routers in the AS keep route_r1 in their routing table 
> as long as the BGP session stays up (some 90 seconds or so), because 
> its nexthop, the loopback address of R1 -- while no longer available 
> with OSPF, is still recursively resolvable through either one of the 
> null0 routes.
> 
> This causes a major problem.  This implies that for BGP to function
> properly, the loopback or point-to-point addresses MUST NOT have any 
> less-specific routes which could be considered unresolvable if the 
> main route itself is removed from IGP.
> 
> 
>>In fact, I don't think there is a problem in 
>>the spec as it stands with IBGP routes which 
>>resolve to a loopback -- these are covered by 
>>9.1.2.1(1).  
> 
> 
> When the loopback address is removed from OSPF, the next best route is 
> the static default discard route (or something like that) -- which is 
> an interface route.
> 
> 
>>As others have mentioned, if a route 
>>resolves to null0 or the like, this is presumably 
>>the result of deliberate configuration and 
>>certainly not something we want to preclude in 
>>the spec.
> 
> 
> Yep, this causes a problem with the DDoS mitigation method described 
> earlier, so I'm not sure what the right fix is.
> 
> However, it clearly seems to call for a requirement to be able to 
> specify, somehow, which routes should be used when considering 
> resolvability (e.g., just connected and IGP routes, ...).
> 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pekka Savola <[email-masked]>
To: "John G. Scudder" <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 27 Feb 2004 22:00:52 +0200 (EET)

On Fri, 27 Feb 2004, John G. Scudder wrote:
> >.. the problem is that unless you have full routing table in every
> >router, and no default discard/aggregate routes/etc., this works. 
> >Otherwise when your IBGP neighbor goes down, the BGP routes learned
> >from that neighbor stay in the BGP table until the BGP session is
> >reset after 90 seconds or so.  Instead, the routes should immediately
> >be removed from BGP when the loopback address is removed from the IGP.
> 
> I agree with your final sentence; however, I 
> don't understand the other parts of that 
> paragraph, nor how your proposed text would help 
> it.  

Ok.  Let me try to clarify the situation.  Assume router R1 in the AS 
has some a route, route_r1, which it sends to every iBGP router.  
Router R1 goes down.  OSPF notices that R1 has gone down, as its 
loopback address has been removed from OSPF.

Assume that a core router or two in the AS has been set up with a 
couple of "null0" routes, for the purposes of aggregation, or default 
route redistribution, e.g., "prefix/16" or "0/0".

Assume that the nexthop of route_r1 matches these null0 routes.

Now, all other routers in the AS keep route_r1 in their routing table 
as long as the BGP session stays up (some 90 seconds or so), because 
its nexthop, the loopback address of R1 -- while no longer available 
with OSPF, is still recursively resolvable through either one of the 
null0 routes.

This causes a major problem.  This implies that for BGP to function
properly, the loopback or point-to-point addresses MUST NOT have any 
less-specific routes which could be considered unresolvable if the 
main route itself is removed from IGP.

> In fact, I don't think there is a problem in 
> the spec as it stands with IBGP routes which 
> resolve to a loopback -- these are covered by 
> 9.1.2.1(1).  

When the loopback address is removed from OSPF, the next best route is 
the static default discard route (or something like that) -- which is 
an interface route.

> As others have mentioned, if a route 
> resolves to null0 or the like, this is presumably 
> the result of deliberate configuration and 
> certainly not something we want to preclude in 
> the spec.

Yep, this causes a problem with the DDoS mitigation method described 
earlier, so I'm not sure what the right fix is.

However, it clearly seems to call for a requirement to be able to 
specify, somehow, which routes should be used when considering 
resolvability (e.g., just connected and IGP routes, ...).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Pekka Savola <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Cc: [email-masked]
Sender: [email-masked]
Date: Fri, 27 Feb 2004 13:10:07 -0500

Pekka,

I'm confused -- to my eye, the spec change you propose:

At 9:01 AM +0200 2/27/04, Pekka Savola wrote:
>Hi,
>
>We analyzed one source of operational BGP problems and noticed a
>problem which should be made explicit in the BGP specification.
>
>In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1:
>
>       2. Routes referencing interfaces (with or without intermediate
>       addresses) are considered resolvable if the state of the refer-
>       enced interface is up and IP processing is enabled on this inter-
>       face.
>
>I propose adding something like:
>
>             For the purposes of this check, the routes for which
>       packets are discarded by the router (i.e., "null" or "discard"
>       routes) SHOULD be considered unresolvable.

Doesn't correspond to the problem you describe:

>.. the problem is that unless you have full routing table in every
>router, and no default discard/aggregate routes/etc., this works. 
>Otherwise when your IBGP neighbor goes down, the BGP routes learned
>from that neighbor stay in the BGP table until the BGP session is
>reset after 90 seconds or so.  Instead, the routes should immediately
>be removed from BGP when the loopback address is removed from the IGP.

I agree with your final sentence; however, I 
don't understand the other parts of that 
paragraph, nor how your proposed text would help 
it.  In fact, I don't think there is a problem in 
the spec as it stands with IBGP routes which 
resolve to a loopback -- these are covered by 
9.1.2.1(1).  As others have mentioned, if a route 
resolves to null0 or the like, this is presumably 
the result of deliberate configuration and 
certainly not something we want to preclude in 
the spec.

Maybe you could expand further on what you think the problem is.

--John

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [Idr] RE: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm
Sender: [email-masked]
Date: Fri, 27 Feb 2004 08:46:42 -0500

I think it would be a useful
addition to the discussion.

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Friday, February 27, 2004 3:16 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm

Sue-

> 6) BGP Assignment of AFI/SAFI address [10 minutes]

>         Document: draft-hares-bgp-assign-afisafi-00.txt (ietf) (-01 on web site) 
>         Author: Susan Hares

I'm wondering if we should also discuss allocation of BGP attribute codes and
suggested procedures in draft-kompella-zinin-early-allocation-00.txt.

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Susan Hares" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: [Idr] Re: Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm
Sender: [email-masked]
Date: Fri, 27 Feb 2004 17:15:53 +0900

Sue-

> 6) BGP Assignment of AFI/SAFI address [10 minutes]

>         Document: draft-hares-bgp-assign-afisafi-00.txt (ietf) (-01 on web site) 
>         Author: Susan Hares

I'm wondering if we should also discuss allocation of BGP attribute codes and
suggested procedures in draft-kompella-zinin-early-allocation-00.txt.

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
CC: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer
Sender: [email-masked]
Date: Fri, 27 Feb 2004 02:54:49 -0800

Curtis,

> Where this matters is if there is a cycle:
> 
>     AS1  --  AS2  --  AS3  -- AS4  --  AS5  -- ASn  -- back to AS1

I am glad there seems to be an agreement that providing two timers may 
matter in the long chain of ASes.

I also therefor assume that there is an agreement that within single AS 
or even short chain of 1-3 ASes connected to each other the most 
practical would be not to introduce two delays one for updates/implicit 
withdraws and the other for updates with only unreachable routes.

While maybe in the case you mentioned indeed there could be some 
benefits but I think correctly setting those timers in an uniform way 
across all of those ASes is just not possible to be achieved in practice.

It also seems that different settings in each AS (some of them maybe due 
to errors) may produce much worse outcome that not using any timer at 
all. Therefor unless we come up with some auto-tuning way I am not sure 
if we should treat pure withdraws any different then implicit withdraws 
or reachability information.

Rgs,
R.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Pekka Savola <[email-masked]>
CC: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 27 Feb 2004 02:33:31 -0800

Pekka,

The case I believe Pedro is describing is nicely documented in the 
following slide on pages 30 & 31:

http://www.securite.org/presentations/secip/BHAMS2001-SecIP-v105-full.ppt

Those are pretty common DDoS protection techniques for the lack of 
better and more granular tools to filter attacks yet deployed in the 
networks.

It would be therefor not right to consider route as not resolvable if it 
resolves to "null" route on any BGP speaker.

Cheers,
R.

 > Pekka Savola wrote:
 >
> On Thu, 26 Feb 2004, Pedro Roque Marques wrote:
> 
>>>            For the purposes of this check, the routes for which
>>>packets are discarded by the router (i.e., "null" or "discard"
>>>routes) SHOULD be considered unresolvable.
>>
>>That would break all the instances where people intentionally use a
>>nexthop that resolves to a discard route to drop traffic. e.g. /32s
>>that are advertised w/ a drop community.
> 
> 
> I'm not really familiar with the different discard route propagation
> techniques, so bear with me..
> 
> The BGP speaker receiving a prefix which points to discard address
> would fail only if the discard nexthop was in the receiving BGP
> speaker, correct?  Otherwise, the router would not know it is a
> discard route (even though it'll be discarded by some other box).
> 
> That is, is BGP used to advertise routes, whose next-hop is a discard
> address, to those BGP speakers which have configured the address as
> discard?
> 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pekka Savola <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 27 Feb 2004 09:46:29 +0200 (EET)

On Thu, 26 Feb 2004, Pedro Roque Marques wrote:
> >             For the purposes of this check, the routes for which
> > packets are discarded by the router (i.e., "null" or "discard"
> > routes) SHOULD be considered unresolvable.
> 
> That would break all the instances where people intentionally use a
> nexthop that resolves to a discard route to drop traffic. e.g. /32s
> that are advertised w/ a drop community.

I'm not really familiar with the different discard route propagation
techniques, so bear with me..

The BGP speaker receiving a prefix which points to discard address
would fail only if the discard nexthop was in the receiving BGP
speaker, correct?  Otherwise, the router would not know it is a
discard route (even though it'll be discarded by some other box).

That is, is BGP used to advertise routes, whose next-hop is a discard
address, to those BGP speakers which have configured the address as
discard?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Thu, 26 Feb 2004 23:11:21 -0800 (PST)

Pekka Savola writes:

> I propose adding something like:

>             For the purposes of this check, the routes for which
> packets are discarded by the router (i.e., "null" or "discard"
> routes) SHOULD be considered unresolvable.

That would break all the instances where people intentionally use a
nexthop that resolves to a discard route to drop traffic. e.g. /32s
that are advertised w/ a drop community.

I don't believe this proposal is feasible.

  Pedro. 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 27 Feb 2004 09:01:28 +0200 (EET)

Hi,

We analyzed one source of operational BGP problems and noticed a 
problem which should be made explicit in the BGP specification.

In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1:

      2. Routes referencing interfaces (with or without intermediate
      addresses) are considered resolvable if the state of the refer-
      enced interface is up and IP processing is enabled on this inter-
      face.

I propose adding something like:

            For the purposes of this check, the routes for which 
      packets are discarded by the router (i.e., "null" or "discard" 
      routes) SHOULD be considered unresolvable.

.. the problem is that unless you have full routing table in every
router, and no default discard/aggregate routes/etc., this works.  
Otherwise when your IBGP neighbor goes down, the BGP routes learned
from that neighbor stay in the BGP table until the BGP session is
reset after 90 seconds or so.  Instead, the routes should immediately
be removed from BGP when the loopback address is removed from the IGP.

I would argue even for stronger statement than SHOULD, but that would
invalidate existing implementations.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pedro Roque Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
Sender: [email-masked]
Date: Thu, 26 Feb 2004 22:50:11 -0800 (PST)

Curtis Villamizar writes:

> If withdraws propogate faster first the unfeasible AS paths are
> removed, then the feasible ones start propogating.  The result is
> some withdraw followed by add but much less AS path change in the
> presence of cycles.

The point in which we differ is that you equate withdraws and updates
w/ unfeasible and feasible paths. I don't believe one can make that
assumption.

For a given AS, if you have as input an withdraw that can result in an
update being generated or vice-versa, depending on the policy.

You can have a link up event result in withdrawns being generated, and
a link down event result in updates. In other words the addition of
feasible paths, can result via policy, in withdrawls.

> Providing separate timers allows us to defer the question of which
> is preferable.

Providing separate timers, imho, will just further confuse the issue
:-). It has already been showen that there is no single choice of MRAI
timer that is appropriate for all situations. Now you propose an
additional one. That is two parameters nobody knows what the optimal
setting should be.

Furthermore, i believe that, due to the meshed nature of internet
connectivity, using different delays may increase the duration of
transients.

Lets say that you start w/ a current path through as3 and
you have a link up event (a) that brings up a prefered path.

	      as 3
	      |
	--a-> as 1 --> as 4
          
	--a-> as 2 --> as 4 

If a is a peer route for as 1 but a customer route for as 2, then by
propagating the withdrawl faster you are increasing the transient time
and causing increase connectivity to create a blackhole for as4.

imho, currently there is only one good known value for MRAI for both
updates and withdrawls, and that is 0. Let BGP speakers propagate
updates as fast as they can, taking into account that BGP itself
already has embedded flow control mechanisms that allow a receiver to
pace a sender appropriatly.

Unfortunatly, even that setting (0) has its drawbacks. One is that
values should probably be consistent within an as, and there are very
different interpretations of MRAI between different vendors. The
second is that in case of MED oscillations, MRAI helps reduce the
ammount of churn.  

regards,
  Pedro.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Pedro Roque Marques <[email-masked]>
cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Fri, 27 Feb 2004 00:25:12 -0500

In message <[email-masked]>, Pedro Roque Mar
ques writes:
> Curtis Villamizar writes:
> 
> 
> > As a matter of best practice it seems to be accepted that the
> > withdraw timer should be less than the advertise timer so withdraws
> > propogate faster than AS path changes.  Whether the withdraw timer
> > has to be zero is an open question.
> 
> I disagree w/ that conclusion...
> 
> Take the following network diagram
> 
>                 +--------+
>  customer1 ---  | as 1   |  -- customer2
>      |          |        |
>      |          |        |
>    peer1   ---  |        |  -- peer2
>                 +--------+
> 
> 
> case 1)
> assume customer1 advertises 10.0.1/24, that is also advertised to you
> by peer1.
> 
> An withrawn of the prefix because of failure of the ebgp session
> between customer1 and as1 will result in:
>   - an update to customer2 w/ aspath "peer1 customer1".
>   - an withdrawl to peer2.

An update to customer2 with a different AS path is a route change and
would occur more slowly.

The faster withdraw would mean that you'd tell customer2 you had no
route, then tell customer2 the best router was through peer1.

Where this matters is if there is a cycle:

    AS1  --  AS2  --  AS3  -- AS4  --  AS5  -- ASn  -- back to AS1

with other AS connected to each of the AS in this cycle, perhaps
forming other cycles.  If AS3 announced a route and then withdrew it,
about half way around the cycle a router would get a withdraw and
advertise around the other way that it had a route from that
direction.  For example, if ASn preferred the route via AS5 then if
AS1 withdrew its router, ASn would advertise the alternate.

This gets real ugly when there are multiple cycles adjacent to each
other as is the case in a well meshed set of AS such as the Internet.

If withdraws propogate faster first the unfeasible AS paths are
removed, then the feasible ones start propogating.  The result is some
withdraw followed by add but much less AS path change in the presence
of cycles.

> case 2)
> Now assume that 10.0.1/24 path is only advertised by customer1 w/
> as-path "customer1 10 10 10" and that peer1 sends you an advertisement
> w/ "peer1 10" for the same prefix. This will result in:
>   - an update to customer2
>   - an withrawl to peer2.
> 
> i.e. an update can be transformed in an withdrawl and vice-versa.
> 
> imho, in BGP updates and withdrawls both constitute reachability
> information, that although encoded in different ways should be
> propagated acording to the same rules, in terms of delays.
> 
> cheers,
>   Pedro.

Providing separate timers allows us to defer the question of which is
preferable.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pedro Roque Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
Sender: [email-masked]
Date: Thu, 26 Feb 2004 19:01:56 -0800 (PST)

Curtis Villamizar writes:

> As a matter of best practice it seems to be accepted that the
> withdraw timer should be less than the advertise timer so withdraws
> propogate faster than AS path changes.  Whether the withdraw timer
> has to be zero is an open question.

I disagree w/ that conclusion...

Take the following network diagram

		+--------+
 customer1 ---	| as 1   |  -- customer2
     |          |        |
     |          |        |
   peer1   ---  |        |  -- peer2
                +--------+

case 1)
assume customer1 advertises 10.0.1/24, that is also advertised to you
by peer1.

An withrawn of the prefix because of failure of the ebgp session
between customer1 and as1 will result in:
  - an update to customer2 w/ aspath "peer1 customer1".
  - an withdrawl to peer2.

case 2)
Now assume that 10.0.1/24 path is only advertised by customer1 w/
as-path "customer1 10 10 10" and that peer1 sends you an advertisement
w/ "peer1 10" for the same prefix. This will result in:
  - an update to customer2
  - an withrawl to peer2.

i.e. an update can be transformed in an withdrawl and vice-versa.

imho, in BGP updates and withdrawls both constitute reachability
information, that although encoded in different ways should be
propagated acording to the same rules, in terms of delays.

cheers,
  Pedro.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: BGP Guru <[email-masked]>
cc: Jeffrey Haas <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Tue, 24 Feb 2004 20:59:37 -0500

In message <[email-masked]>, BGP Guru w
rites:
>  --- Jeffrey Haas <[email-masked]> wrote: 
> > On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru
> > wrote:
> > > Could anyone please clarify why we need two timers
> > for
> > > Route-Advertisement?
> > 
> > Originating your own routes is governed by the MAOI
> > timer.
> > Propagating someone else's routes is governed by the
> > MRAI timer.
> > 
> > This also made me look for something which appears
> > to not be there
> > any longer.
> > 
> > Draft -17 and before had unfeasible NLRI propagate
> > immediately.
> > Draft -18 and later changed this to have unfeasable
> > nlri governed
> > by the timers.
> > 
> > I thought Craig and Abha had determined this was a
> > Bad Thing?
> > 
> 
> I do not think that holding back route-withdrawals by
> timer intervals is a "bad thing" at all. I suppose
> that this opinion is due to the thought that there
> might be black-holing of data traffic. But if you
> consider the "big picture" of entire network, one can
> vividly see how beneficial this really is. A simple
> example would be, if one enters a CLI command which is
> implemented to reset a peering session, and that peer
> has announced a million prefixes, it would definitely
> not be wise to withdraw all those prefixes from the
> other 500 peers because the peering will anyways be
> back within say 15-20sec or so. This would save us
> from sending a millions of withdrawals and
> re-advertising millions again because of a temporary
> glitch. Infact there may not be any data being
> black-holed at all. Im totally for keeping this the
> way draft-18 and later suggest.

Regardless of what Craig and Abha thought was best for the Internet,
routers exist which allow a configurable withdraw timer.  It is
possible to set the timer to zero if the timer is implemented.  It is
not possible to set it non-zero if it is not implemented.  Whatever
the setting, there are no interoperability problems but failing to
withdraw a route can cause loss of traffic for the duration of the
timer.  

As a matter of best practice it seems to be accepted that the withdraw
timer should be less than the advertise timer so withdraws propogate
faster than AS path changes.  Whether the withdraw timer has to be
zero is an open question.

This leads to a problem in the draft.  There is one MRAI timer in the
draft that applies to either withdraw or advertise.  Withdraws should
be fast and advertisements can be slower.  There should at least be
two timers specified.

IMHO - Implementations MUST support an advertise timer.
Implementations MAY send withdraws immediately but SHOULD support a
separate withdraw timer.  Implementations MAY use the advertise timer
with withdraws but SHOULD keep the two timers separate.

No one has argued (to my knowledge) that the originate and advertise
timers should not be implemented.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: BGP Guru <[email-masked]>
cc: Jeffrey Haas <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Tue, 24 Feb 2004 20:38:15 -0500

In message <[email-masked]>, BGP Guru w
rites:
> Jeff,
> 
> Thanks for your response. I have a further query on
> this:
> 
> > Originating your own routes is governed by the MAOI
> > timer.
> 
> What does "own" here refer to? Does "own" refer to
> 'Local Router/Box' or does it refer to 'Local AS'. And
> if it is 'Local AS' how can we segregate
> advertisements received from IBGP peers which are
> generated by the IBGP peers themselves and those that
> are originated from outside our AS and advertised by
> IBGP peer?
> 
> > Propagating someone else's routes is governed by the
> > MRAI timer.
> > 
> 
> As continuation of the above query, "someone else's" -
> does it refer to other IBGP peers or those originating
> strictly from outside the AS? And how is the
> distinction supposed to be made?
> 
> Thanks,
> 
> Guru

Lets start with the table of contents.  Note the presence of a section
entitled "Originating BGP routes".  Find that section.  Read the one
paragraph.  It contains a definition of "Originating BGP routes".  It
means distilling stuff from your own AS and sending it to other
routers.

Now find "Routes: Advertisement and Storage" in the table of contents.
It has 4 paragraphs, three of which are one or two sentences.  A brief
definitition of route advertisement is there and it is clear from the
definitions and from usage in the document that it means passing a
route to other BGP speakers.

Just to shed some light on common practices, if a route is learned
from the IGP you wouldn't send it to IBGP peers.  If it is local (ie:
direct connected) and not advertised into the IGP then you could use
IBGP.  If it was local and also advertised into the IGP you wouldn't
normally advertise into IBGP unless you had some special need like you
wanted to attach BGP communities to it.

In the section "Frequency of Route Advertisement" it says: 

   the procedure describe in this section 
   SHOULD NOT apply for routes sent to internal peers.

So there is part of your answer for IBGP.

Look at the one paragraph in "Frequency of Route Origination" and
the one paragraph in "Originating BGP routes" in it should be clear
what "originating" means and that there is a timer on that operation.

So when you "originate" a route you send it to everyone except as
restricted by configured policy.  You apply the MAOI for originating
and when that is satisfied you can send to everyone at once unless
further constrained by the MRAI timer.  The MRAI doesn't apply to IBGP
so it could only apply to your EBGP peerings.  

Note that if other routers in the IGP are using the same MRAI setting
(configured the same) a locally originated route should leave the AS
from all peerings (where configured policy allows) at about the same
time.  If they are not configured with the same timer either the
operator had a reason or the operator messed up.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [Idr] Agenda for Idr on 3/1/04 - 15:30pm - 17:30pm
Sender: [email-masked]
Date: Thu, 26 Feb 2004 11:12:06 -0500

Agenda for IDR

1)  Document status  [5 minutes]

2)  Implementation Reports and FSM issues for 
	current drafts [10 minutes]

	document: None,  presentation only 
	Sue Hares

3)  BGP Peer Restart Backoff Mechanisms [10 minutes] 
	Sue Hares
	
	document: draft-hares-bgp-backoff-02.txt
	Author: Susan Hares 

4) Deterministic Route Redistribution into BGP [10 minutes]
	Enke Chen

     document: draft-chen-bgp-redist-00.txt
     Authors: Jenny Yuan, Enke Chen

5) BGP based auto-discovery  [Sue Hares, P. Unbehagen] [10 minutes] 

	document: draft-hlmu-l2vpn-bgp-discovery-00.txt
	authors: P. Unbehagen,  P. Muley,   V. Radoaca,  Sue Hares 
		Wei Lou

6) BGP Assignment of AFI/SAFI address [10 minutes] 

	Document: draft-hares-bgp-assign-afisafi-00.txt (ietf) (-01 on web site) 
	Author: Susan Hares

7) Charter Discussion [20 minutes] 

	Thanks to all implementors who send in reports on the
	the base specification, we will be opening the charter. 
	This section of the meeting will discuss what items will
	be added to the charter.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer
Sender: [email-masked]
Date: Thu, 26 Feb 2004 09:36:57 -0500

On Tue, Feb 24, 2004 at 08:59:37PM -0500, Curtis Villamizar wrote:
> As a matter of best practice it seems to be accepted that the withdraw
> timer should be less than the advertise timer so withdraws propogate
> faster than AS path changes.

Right.  You immediately point out the problem we now have from the
current draft:

> This leads to a problem in the draft.  There is one MRAI timer in the
> draft that applies to either withdraw or advertise.  Withdraws should
> be fast and advertisements can be slower.  There should at least be
> two timers specified.

Similarly, MAOI may need something similar, although one can argue
that since this is the originating AS as opposed to a transit AS
that the issue is much less severe.

Unfortunately, we're rather far into last call and this will probably
not be addressed.  

We're probably to the point where someone should probably do a draft
that contains known issues with BGP. :-)

> No one has argued (to my knowledge) that the originate and advertise
> timers should not be implemented.

Although some would argue that these timers have been poorly implemented
and we have relied on WRD in it's place.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: =?iso-8859-1?q?BGP=20Guru?= <[email-masked]>
Subject: Re: [Idr] Question on MinASOrig Timer
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]
Date: Wed, 25 Feb 2004 00:13:25 +0000 (GMT)

 --- Jeffrey Haas <[email-masked]> wrote: 
> On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru
> wrote:
> > Could anyone please clarify why we need two timers
> for
> > Route-Advertisement?
> 
> Originating your own routes is governed by the MAOI
> timer.
> Propagating someone else's routes is governed by the
> MRAI timer.
> 
> This also made me look for something which appears
> to not be there
> any longer.
> 
> Draft -17 and before had unfeasible NLRI propagate
> immediately.
> Draft -18 and later changed this to have unfeasable
> nlri governed
> by the timers.
> 
> I thought Craig and Abha had determined this was a
> Bad Thing?
> 

I do not think that holding back route-withdrawals by
timer intervals is a "bad thing" at all. I suppose
that this opinion is due to the thought that there
might be black-holing of data traffic. But if you
consider the "big picture" of entire network, one can
vividly see how beneficial this really is. A simple
example would be, if one enters a CLI command which is
implemented to reset a peering session, and that peer
has announced a million prefixes, it would definitely
not be wise to withdraw all those prefixes from the
other 500 peers because the peering will anyways be
back within say 15-20sec or so. This would save us
from sending a millions of withdrawals and
re-advertising millions again because of a temporary
glitch. Infact there may not be any data being
black-holed at all. Im totally for keeping this the
way draft-18 and later suggest.

> -- 
> Jeff Haas 
> NextHop Technologies
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr 

	

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: =?iso-8859-1?q?BGP=20Guru?= <[email-masked]>
Subject: Re: [Idr] Question on MinASOrig Timer
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]
Date: Tue, 24 Feb 2004 23:52:23 +0000 (GMT)

Jeff,

Thanks for your response. I have a further query on
this:

> Originating your own routes is governed by the MAOI
> timer.

What does "own" here refer to? Does "own" refer to
'Local Router/Box' or does it refer to 'Local AS'. And
if it is 'Local AS' how can we segregate
advertisements received from IBGP peers which are
generated by the IBGP peers themselves and those that
are originated from outside our AS and advertised by
IBGP peer?

> Propagating someone else's routes is governed by the
> MRAI timer.
> 

As continuation of the above query, "someone else's" -
does it refer to other IBGP peers or those originating
strictly from outside the AS? And how is the
distinction supposed to be made?

Thanks,

Guru

 --- Jeffrey Haas <[email-masked]> wrote: 
> On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru
> wrote:
> > Could anyone please clarify why we need two timers
> for
> > Route-Advertisement?
> 
> Originating your own routes is governed by the MAOI
> timer.
> Propagating someone else's routes is governed by the
> MRAI timer.
> 
> This also made me look for something which appears
> to not be there
> any longer.
> 
> Draft -17 and before had unfeasible NLRI propagate
> immediately.
> Draft -18 and later changed this to have unfeasable
> nlri governed
> by the timers.
> 
> I thought Craig and Abha had determined this was a
> Bad Thing?
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr 

	

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Andrew Lange <[email-masked]>
To: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue with text in 9.1.4
Sender: [email-masked]
Date: Mon, 23 Feb 2004 09:22:37 -0800

I would prefer the second option (reword the text) for two reasons: 1) The 
implementation report does not cover all implementations, so the 
aggregation behavior can still be present in the field.  2) Since both 
methods of Loc-RIB installation would result in the same forwarding 
behavior to outside routers, we shouldn't preclude vendors from 
implementing route aggregation if they choose.

Andrew

--On Sunday, February 22, 2004 12:13 PM -0800 Yakov Rekhter 
<[email-masked]> wrote:

> Folks,
>
> From 9.1.4:
>
>    If a BGP speaker receives overlapping routes, the Decision Process
>    MUST consider both routes based on the configured acceptance policy.
>    If both a less and a more specific route are accepted, then the Deci-
>    sion Process MUST either install in Loc-RIB both the less and the
>    more specific routes or it MUST aggregate the two routes and install
>    in Loc-RIB the aggregated route, provided that both routes have the
>    same value of the NEXT_HOP attribute.
>
> The problem with the above text is that based on the information
> provided by the vendors who participated in the implementation
> survey we do not have enough implementations that implement what
> is specified in the second part of the last sentence above ("it
> MUST aggregate the two routes and install in Loc-RIB the aggregated
> route, provided that both routes have the same value of the NEXT_HOP
> attribute").
>
> There are (at least) two ways to address this:
>
> Option 1: remove the second part of the sentence. The resulting text
> will be as follows:
>
>    If a BGP speaker receives overlapping routes, the Decision Process
>    MUST consider both routes based on the configured acceptance policy.
>    If both a less and a more specific route are accepted, then the Deci-
>    sion Process MUST install in Loc-RIB both the less and the
>    more specific routes.
>
> Option 2: reword the sentence. The resulting text will be as follows:
>
>    If a BGP speaker receives overlapping routes, the Decision Process
>    MUST consider both routes based on the configured acceptance policy.
>    If both a less and a more specific route are accepted, then the Deci-
>    sion Process MUST install in Loc-RIB either both the less and the
>    more specific routes or aggregate the two routes and install
>    in Loc-RIB the aggregated route, provided that both routes have the
>    same value of the NEXT_HOP attribute.
>
> Please let me know if you have any preferences (or you have some
> other option to suggest).
>
> Yakov.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Cc: [email-masked]
From: Benjamin Black <[email-masked]>
Subject: Re: [Idr] Question on MinASOrig Timer
To: BGP Guru <[email-masked]>
Sender: [email-masked]
Date: Sun, 22 Feb 2004 21:19:59 -0800

Sorry, misread the question.  Disregard my response.

On Feb 22, 2004, at 8:58 PM, BGP Guru wrote:

>
>
> Section 9.2.1.2 of BGP draft-23 states:
>
> 9.2.1.2 Frequency of Route Origination
>
>    The parameter MinASOriginationIntervalTimer
>    determines the minimum amount of time that must
>    elapse between successive advertisements of
>    UPDATE messages that report changes within the
>    advertising BGP speaker's own autonomous systems.
>
> Could anyone please clarify why we need two timers for
> Route-Advertisement? There is already
> "MinRouteAdvertisementInterval" which limits the
> frequency of generation of UPDATEs. I donot understand
> the role of "MinSASOriginationInterval" timer. How are
> these two timers serving different purposes?
>
>
>
>
> 	
> 	
> 		
> ___________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping"
> your friends today! Download Messenger Now
> http://uk.messenger.yahoo.com/download/index.html
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
>
>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Jeffrey Haas <[email-masked]>
To: BGP Guru <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer
Sender: [email-masked]
Date: Mon, 23 Feb 2004 09:24:49 -0500

On Mon, Feb 23, 2004 at 04:58:04AM +0000, BGP Guru wrote:
> Could anyone please clarify why we need two timers for
> Route-Advertisement?

Originating your own routes is governed by the MAOI timer.
Propagating someone else's routes is governed by the MRAI timer.

This also made me look for something which appears to not be there
any longer.

Draft -17 and before had unfeasible NLRI propagate immediately.
Draft -18 and later changed this to have unfeasable nlri governed
by the timers.

I thought Craig and Abha had determined this was a Bad Thing?

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: =?iso-8859-1?q?BGP=20Guru?= <[email-masked]>
To: [email-masked]
Subject: [Idr] Question on MinASOrig Timer
Sender: [email-masked]
Date: Mon, 23 Feb 2004 04:58:04 +0000 (GMT)

Section 9.2.1.2 of BGP draft-23 states:

9.2.1.2 Frequency of Route Origination

   The parameter MinASOriginationIntervalTimer
   determines the minimum amount of time that must
   elapse between successive advertisements of
   UPDATE messages that report changes within the
   advertising BGP speaker's own autonomous systems.

Could anyone please clarify why we need two timers for
Route-Advertisement? There is already
"MinRouteAdvertisementInterval" which limits the
frequency of generation of UPDATEs. I donot understand
the role of "MinSASOriginationInterval" timer. How are
these two timers serving different purposes?

	

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] issue with text in 9.1.4
Sender: [email-masked]
Date: Sun, 22 Feb 2004 12:13:50 -0800

Folks,

>From 9.1.4:

   If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the Deci-
   sion Process MUST either install in Loc-RIB both the less and the
   more specific routes or it MUST aggregate the two routes and install
   in Loc-RIB the aggregated route, provided that both routes have the
   same value of the NEXT_HOP attribute.

The problem with the above text is that based on the information
provided by the vendors who participated in the implementation
survey we do not have enough implementations that implement what
is specified in the second part of the last sentence above ("it
MUST aggregate the two routes and install in Loc-RIB the aggregated
route, provided that both routes have the same value of the NEXT_HOP
attribute").

There are (at least) two ways to address this:

Option 1: remove the second part of the sentence. The resulting text
will be as follows:

   If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the Deci-
   sion Process MUST install in Loc-RIB both the less and the
   more specific routes.

Option 2: reword the sentence. The resulting text will be as follows:

   If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the Deci-
   sion Process MUST install in Loc-RIB either both the less and the
   more specific routes or aggregate the two routes and install
   in Loc-RIB the aggregated route, provided that both routes have the
   same value of the NEXT_HOP attribute.

Please let me know if you have any preferences (or you have some
other option to suggest).

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] (non-normative) text in Appendix F
Sender: [email-masked]
Date: Sun, 22 Feb 2004 11:56:49 -0800

Folks,

Since Appendix F deals with implementation *recommendations* it
should not have any normative text. Therefore I'd like to replace
all normative "SHOULD", "MUST", etc... with non-normative "should",
"must", etc...

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Jeffrey Haas <[email-masked]>
To: Sharon Chisholm <[email-masked]>, "Wayne F. Tackabury" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] draft-ietf-idr-bgp4-mibv2-04.txt General Review Comments
Sender: [email-masked]
Date: Thu, 12 Feb 2004 15:27:48 -0500

On Wed, Feb 11, 2004 at 12:03:19PM -0500, Sharon Chisholm wrote:
> 1. I think much of the discussion around extensibility should be revisited,

This is one of the things I intended to do some cleanout during my next
break to work on the MIB.

The feedback is good though.

> 2. The organization of objects is somewhat unusual, especially when it comes
> to Notifications and Conformance. See Appendix D of the MIB review
> guidelines for the recommended design pattern. 

Conformance is definitely one item that has suffered throughout the
MIBs since the texts I've had available to me to explain them were
less than complete on that area.  I think the v1MIB has educated
me enough to make a better attempt on the v2MIB in the next release.
This last issue was simply to get the v2MIB back in circulation since
it had expired and yet integrate some of the known changes.

As for the MIB layout, this is definitely doable and will mostly
require adding another level of hierarchy in the objects portion of
the MIB.  This is yet another case where I shouldn't have trusted
the original BGP MIB as a guideline for organization.

> 3. The MIB is fairly large and from my understanding there is still a lot
> more stuff that will likely go in it. I think it might be worthwhile to ask
> ourselves two questions to ensure we are on the right track with respect to
> what we need to define
> 	A. Do we really expect people to configure BGP using SNMP, or can
> get away with a monitoring MIB, plus potentially some read-write objects for
> status and other forms of non-row-creating read-write objects?

A slightly better question is even if we *do* want configuration to
be part of the MIB, should it go in this document, or should we
define a separate document for the configuration?

In previous discussions, Wayne and I had decided that the monolithic
document was probably the best option until the general structure of
the MIB was reasonably well set and then we could re-address the issue.

>       B. Are we reporting what we should be reporting or simply what can be
> reported?

This has been one of the items of contention.

The base v1MIB provides access to the "BGP routing table", more 
specifically the Ribs.  As BGP has evolved, the stuff that is stored
in this abstract database has expanded and is the one item that
is likely to continue expanding with the protocol.

If we delete the ability to retrieve the RIBs from the MIB, the 
vast majority of the readable objects from the MIB disappear.

If we keep this in, we should provide the ability to get to as
much information as possible.

It can be easily argued (and has been by many parties) that SNMP
is simply The Wrong Tool for getting at the routing table.  However,
until we have consensus, we can't get rid of it.

> 4. There are a number parts of the document that read more like wg charter
> discussion or editor's note. These need to eventually be replaced with text
> that assumes that the audience of the document is people who are looking at
> implementing the MIB.

Much of the administrative text is in need of updating.  Wayne did
a wonderful job in the initial versions and we can now update it.

On Wed, Feb 11, 2004 at 02:21:19PM -0500, Wayne F. Tackabury wrote:
> work on it a lot back then :), thanks for the attention.  You've done a 
> great job of articulating issues that I've been aware are hanging out there 
> and I'm surprised we haven't had to confront yet.

That's what we get when we push on one version of the MIB at a time. :-)

At this point I don't believe I'll have the opportunity to issue a
-05 prior to IETF, but will issue one soon thereafter.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Sanjay S. Rao" <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson IPI 
To: [email-masked]
Subject: [Idr] Graceful Restart question
Sender: [email-masked]
Date: Mon, 09 Feb 2004 12:18:05 -0500

Hi,

   I have a question regarding "Graceful Restart" for BGP (http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt):

In section 7.1 the draft says:

   "To put an upper bound on the amount of time a router defers its route
   selection, an implementation MUST support a (configurable) timer that
   imposes this upper bound."

What is the recommendation if that "configurable timer" time-out. Should the connection with the 
peer be closed or should the route selection begin as if end of RIB marker was received from all the peers ? 

Is it recommended to put this same upper bound when waiting for End of RIB marker even for normal connection
establishment (not restarting or receiving speakers' case).  

Thanks
Sanjay S. Rao

-- 
Sanjay S. Rao
Protocols Group           	   Ericsson IP Infrastructure 
                                   Rockville, MD
========================================================================
Phone                              240-314-3611
eMail                              [email-masked]

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-mibagent-survey-00.txt
Sender: [email-masked]
Date: Wed, 11 Feb 2004 15:51:08 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP MIB V1 implementation survey
	Author(s)	: S. Hares
	Filename	: draft-ietf-idr-bgp-mibagent-survey-00.txt
	Pages		: 38
	Date		: 2004-2-11
	
This document provides of survey of BGP-4 RFC 1657 MIB agent 
   implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-mibagent-survey-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-mibagent-survey-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Sanjay S. Rao" <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson IPI 
To: idr <[email-masked]>
Subject: [Idr] Graceful Restart question
Sender: [email-masked]
Date: Mon, 09 Feb 2004 17:03:52 -0500

Hi,

  I have a question regarding "Graceful Restart" for BGP 
(http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt):

In section 7.1 the draft says:

  "To put an upper bound on the amount of time a router defers its route
  selection, an implementation MUST support a (configurable) timer that
  imposes this upper bound."

What is the recommendation if that "configurable timer" time-out. Should 
the connection with the peer be closed or should the route selection 
begin as if end of RIB marker was received from all the peers ?

Is it recommended to put this same upper bound when waiting for End of 
RIB marker even for normal connection
establishment (not restarting or receiving speakers' case). 

Thanks
Sanjay S. Rao

-- 
Sanjay S. Rao
Protocols Group           	   Ericsson IP Infrastructure
========================================================================
Phone                              240-314-3611
eMail                              [email-masked]

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Enke Chen <[email-masked]>
cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] draft-chen-bgp-redist-00.txt 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Tue, 10 Feb 2004 12:31:20 -0500

In message <[email-masked]>, Enke Chen writes:
> Hi, folks:
> Here is a new draft that was just posted. Please let us know
> if you have any comments.
> 
> Thanks.  -- Enke

Enke,

There is one problem with this.  There is no such thing as admin
distance in the BGP spec itself or in any routing protocol.  This just
seems to be a feature that (almost?) everyone has implemented but has
no protocol spec.  Do we need a base spec for this that defines what
admin distance is?  [If there is such a thing, then never mind.]
Maybe you could rename this draft so that "Administrative Distance"
was part of the title and you define what it is and how it is used
(which is essentially done in intro, though being very brief),
including the rule you've proposed.

Curtis

> ------- Forwarded Message
> 
> Message-Id: <[email-masked]>
> To: IETF-Announce: ;
> From: [email-masked]
> Reply-To: [email-masked]
> Subject: I-D ACTION:draft-chen-bgp-redist-00.txt
> Date: Mon, 09 Feb 2004 16:09:07 -0500
> 
> - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directorie
> s.
> 
> 
> 	Title		: Deterministic Route Redistribution into BGP
> 	Author(s)	: E. Chen
> 	Filename	: draft-chen-bgp-redist-00.txt
> 	Pages		: 5
> 	Date		: 2004-2-9
> 	
> In this document we propose an enhancement to the BGP route selection
>    algorithm that would make the interaction of redistributed routes and
>    other BGP routes deterministic, thus facilitating the deployment of
>    various routing requirements. The proposed enhancement is backward
>    compatible.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-chen-bgp-redist-00.txt
> 
> ------- End of Forwarded Message
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: "Wayne F. Tackabury" <[email-masked]>
Subject: Re: [Idr] draft-ietf-idr-bgp4-mibv2-04.txt General Review Comments
Sender: [email-masked]
Date: Wed, 11 Feb 2004 14:21:19 -0500

Sharon:

As someone who hasn't worked on the document in over two years but sure did 
work on it a lot back then :), thanks for the attention.  You've done a 
great job of articulating issues that I've been aware are hanging out there 
and I'm surprised we haven't had to confront yet.

At 12:03 PM 2/11/2004 -0500, Sharon Chisholm wrote:
>         A. Do we really expect people to configure BGP using SNMP, or can
>get away with a monitoring MIB, plus potentially some read-write objects for
>status and other forms of non-row-creating read-write objects?

That was certainly an explicit goal at the time we started this 
effort.  Lacking this objective, to be honest, I wonder if much of the 
justification for an complete new "BGP MIB Version" melts away, as opposed 
to simply a RFC 1657 ++ extensibility mechanism.

As for my take, my own views on the importance of MIB configuration 
capabilities and its being essential to even the continued relevance of 
SNMP has been published elsewhere and I won't take it up here. :)

>       B. Are we reporting what we should be reporting or simply what can be
>reported?

There's a filter of operational relevance that Jeff and I have been hoping 
will be applied in the wg discussion of the MIB.

>5. There are a number of points in the document where things are being
>explained where it is not clear to me whether the document is meant to be
>explaining basically how SNMP & MIBs work, or is trying to describe
>something else.

To cover this and your last point, when this was first published, a number 
of MIB documents were taking hits inside and outside of the IETF community 
for being impossibly abstract and lacking sufficient background and 
*particularly* usage examples to be useful by nonacademic operational 
personnel.  Jeff and I were getting a lot of input to be very broad in the 
level of introductory material necessary to illustrate intended 
usage.  Much like the sheer number of monitoring objects, to be candid, we 
intentionally overdid it to see just how far we overdid it.  Now, I'm all 
for segregating boilerplate and intro as opposed to specific discussion, 
but just keep the original intent in mind before throwing out the baby with 
the bathwater, as it were.

I've been lurking a bit here, but your comments were thoughtful enough that 
I just wanted to provide these few points of historical illustration in 
response.

Regards,
Wayne

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Subject: [Idr] draft-ietf-idr-bgp4-mibv2-04.txt General Review Comments
Sender: [email-masked]
Date: Wed, 11 Feb 2004 12:03:19 -0500

Hi

I usually just send my more obscure review comments to directly to Jeff, but
I thought some of these might benefit from a bit of discussion so I'm
sending them to the list. MIB boilerplate, review guidelines and other
resources can be found on the OPS page
	http://www.ops.ietf.org/

1. I think much of the discussion around extensibility should be revisited,
potentially for the method that is being used, but certainly for how it is
explained. I think part of the problem is some ambiguity in the discussion
between MIB extensions and BPG protocol extensions. It should be clear that
they are independent concepts as well as it needs to be clear at any given
time which is being discussed. It's fine to define a relationship or working
method between the two, but first they need to be understood independently.

In general I would say there are three types of MIB extensibility
	A. Updating a MIB
      B. Updating a textual convention in IANA 
      C. Defining a new MIB that defines an extension
It seems like this draft is doing A by the fact that it is defining objects
for the various BGP extensions that have come along, but there is discussion
about B & C although it's not clear to me what exactly is being done in this
ID to support those. There is discussion about basing the OID value of
future protocol extensions objects on the on RFC number of the protocol
extension, but my understanding was that this idea was scraped, a decision I
agree with. 

2. The organization of objects is somewhat unusual, especially when it comes
to Notifications and Conformance. See Appendix D of the MIB review
guidelines for the recommended design pattern. 

3. The MIB is fairly large and from my understanding there is still a lot
more stuff that will likely go in it. I think it might be worthwhile to ask
ourselves two questions to ensure we are on the right track with respect to
what we need to define
	A. Do we really expect people to configure BGP using SNMP, or can
get away with a monitoring MIB, plus potentially some read-write objects for
status and other forms of non-row-creating read-write objects?
      B. Are we reporting what we should be reporting or simply what can be
reported?

4. There are a number parts of the document that read more like wg charter
discussion or editor's note. These need to eventually be replaced with text
that assumes that the audience of the document is people who are looking at
implementing the MIB.

5. There are a number of points in the document where things are being
explained where it is not clear to me whether the document is meant to be
explaining basically how SNMP & MIBs work, or is trying to describe
something else. To make this more obvious, I would suggest letting the MIB
boilerplate explain the basics of SNMP and then assume this in the rest of
the discussion. If you feel it adds value to explain some generic SNMP and
MIB aspect, perhaps including reference to the SNMP specification will make
it clear that is what you are doing or otherwise make it clear that you are
not inventing something new in the MIB.

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Enke Chen <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Idr] draft-chen-bgp-redist-00.txt
Sender: [email-masked]
Date: Tue, 10 Feb 2004 13:09:58 -0800

Enke, Curtis-

>> Enke,
>> 
>> There is one problem with this.  There is no such thing as admin
>> distance in the BGP spec itself or in any routing protocol.  This just
>> seems to be a feature that (almost?) everyone has implemented but has
>> no protocol spec.  Do we need a base spec for this that defines what
>> admin distance is?  [If there is such a thing, then never mind.]
>>
>> Maybe you could rename this draft so that "Administrative Distance"
>> was part of the title and you define what it is and how it is used
>> (which is essentially done in intro, though being very brief),
>> including the rule you've proposed.

> Thanks for these suggestions. We will re-title the draft, and expand
> on the "admin distance" in the next revision.

Regarding the admin distance, RFC 1812 (Router Reqs) talks about
ranking routing info sources and a priority mechanism for choosing
routes from different routing processes in section 7. One could build
on top of this if needed.

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Idr] draft-chen-bgp-redist-00.txt 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Tue, 10 Feb 2004 12:11:01 -0800

Hi, Curtis:

> Message-Id: <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked], [email-masked]
> Reply-To: [email-masked]
> Subject: Re: [Idr] draft-chen-bgp-redist-00.txt 
> In-reply-to: Your message of "Mon, 09 Feb 2004 14:21:43 PST."
>              <[email-masked]> 
> Date: Tue, 10 Feb 2004 12:31:20 -0500
> From: Curtis Villamizar <[email-masked]>
> 
> 
> In message <[email-masked]>, Enke Chen writes:
> > Hi, folks:
> > Here is a new draft that was just posted. Please let us know
> > if you have any comments.
> > 
> > Thanks.  -- Enke
> 
> 
> 
> Enke,
> 
> There is one problem with this.  There is no such thing as admin
> distance in the BGP spec itself or in any routing protocol.  This just
> seems to be a feature that (almost?) everyone has implemented but has
> no protocol spec.  Do we need a base spec for this that defines what
> admin distance is?  [If there is such a thing, then never mind.]
>
> Maybe you could rename this draft so that "Administrative Distance"
> was part of the title and you define what it is and how it is used
> (which is essentially done in intro, though being very brief),
> including the rule you've proposed.

Thanks for these suggestions. We will re-title the draft, and expand
on the "admin distance" in the next revision.

-- Enke

> 
> Curtis
> 
> 
> 
> > ------- Forwarded Message
> > 
> > Message-Id: <[email-masked]>
> > To: IETF-Announce: ;
> > From: [email-masked]
> > Reply-To: [email-masked]
> > Subject: I-D ACTION:draft-chen-bgp-redist-00.txt
> > Date: Mon, 09 Feb 2004 16:09:07 -0500
> > 
> > - --NextPart
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directorie
> > s.
> > 
> > 
> > 	Title		: Deterministic Route Redistribution into BGP
> > 	Author(s)	: E. Chen
> > 	Filename	: draft-chen-bgp-redist-00.txt
> > 	Pages		: 5
> > 	Date		: 2004-2-9
> > 	
> > In this document we propose an enhancement to the BGP route selection
> >    algorithm that would make the interaction of redistributed routes and
> >    other BGP routes deterministic, thus facilitating the deployment of
> >    various routing requirements. The proposed enhancement is backward
> >    compatible.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-chen-bgp-redist-00.txt
> > 
> > ------- End of Forwarded Message
> > 
> > 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] Graceful Restart question ..
Cc: idr <[email-masked]>
Sender: [email-masked]
Date: Tue, 10 Feb 2004 09:17:39 -0500

At 5:10 PM -0500 2/9/04, Sanjay S. Rao wrote:
>What is the recommendation if that "configurable timer" time-out. 
>Should the connection with the peer be closed or should the route 
>selection begin as if end of RIB marker was received from all the 
>peers ?

The latter.

>Is it recommended to put this same upper bound when waiting for End 
>of RIB marker even for normal connection
>establishment (not restarting or receiving speakers' case).

Some upper bound, in any case.

We can add a small clarification to these in a future revision.

--John

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Cc: [email-masked], [email-masked]
From: Enke Chen <[email-masked]>
Subject: [Idr] draft-chen-bgp-redist-00.txt
Sender: [email-masked]
Date: Mon, 09 Feb 2004 14:21:43 -0800

Hi, folks:
Here is a new draft that was just posted. Please let us know
if you have any comments.

Thanks.  -- Enke

------- Forwarded Message

Message-Id: <[email-masked]>
To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-redist-00.txt
Date: Mon, 09 Feb 2004 16:09:07 -0500

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Deterministic Route Redistribution into BGP
	Author(s)	: E. Chen
	Filename	: draft-chen-bgp-redist-00.txt
	Pages		: 5
	Date		: 2004-2-9
	
In this document we propose an enhancement to the BGP route selection
   algorithm that would make the interaction of redistributed routes and
   other BGP routes deterministic, thus facilitating the deployment of
   various routing requirements. The proposed enhancement is backward
   compatible.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-redist-00.txt

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Sanjay S. Rao" <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson IPI 
To: idr <[email-masked]>
Subject: [Idr] Graceful Restart question ..
Sender: [email-masked]
Date: Mon, 09 Feb 2004 17:10:09 -0500

Hi,

 I have a question regarding "Graceful Restart" for BGP 
(http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt):

In section 7.1 the draft says:

 "To put an upper bound on the amount of time a router defers its route
 selection, an implementation MUST support a (configurable) timer that
 imposes this upper bound."

What is the recommendation if that "configurable timer" time-out. Should 
the connection with the peer be closed or should the route selection 
begin as if end of RIB marker was received from all the peers ?

Is it recommended to put this same upper bound when waiting for End of 
RIB marker even for normal connection
establishment (not restarting or receiving speakers' case).

Thanks
Sanjay S. Rao

-- 
Sanjay S. Rao
Protocols Group           	   Ericsson IP Infrastructure
========================================================================
Phone                              240-314-3611
eMail                              [email-masked]

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: David Meyer <[email-masked]>
CC: [email-masked], [email-masked]
Subject: [Idr] Re: problem with the allocation policy
Sender: [email-masked]
Date: Fri, 6 Feb 2004 21:40:49 -0800

Dave,

>>> Do you mean what initiates the IANA action or whether the IANA
>>> need to perform any checks before doing that?

>         Well, I guess it says that the WG chair will instruct the
>         IANA to make the allocation, i.e., the IANA doesn't have
>         any responsibility other than to maintain the
>         registry (but see below; what part of the regsitry do we
>         (IETF) have to replicate to make this work?)

Correct.

>>> The idea is that the IANA simply performs what's requested by
>>> the chairs and/or authors (with AD approval) who keep track
>>> of when allocations need to be deprecated and dealloacted.

>         Does this mean that we will be keeping our own registry
>         consisting of the various allocations, their owners, the
>         relevant WG chairs, and the timeouts?

IANA already maintains status and the document name for each
entry. If we add a timestamp, would it be enough data?

Thanks,

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: David Meyer <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [Idr] Re: problem with the allocation policy
Sender: [email-masked]
Date: Fri, 6 Feb 2004 13:41:40 -0800

On Fri, Feb 06, 2004 at 11:24:06AM -0800, Alex Zinin wrote:
>> Dave,
>> 
>> <hat = co-author>
>> 
>> >         Folks,
>> 
>> >         While I understand the need for such a policy (that much
>> >         seems to have been demonstrated), I have a few comments
>> >         on this draft:
>> 
>> >         (i).    Request (Section 3.1)
>> 
>> >                 Section 3.1 outlines a sequence of actions that
>> >                 result in "temporary" IANA allocation. A couple
>> >                 of points here. First, there seems to be a step
>> >                 missing between action 4) and 5):
>> 
>> >>>    4) If so, with the approval of the Area Director(s), the WG chairs
>> >>>       request IANA to make an early allocation.
>> >>> 
>> >>>    5) IANA makes an allocation from the appropriate registry, marking it
>> >>>       as "temporary", valid for a period of one year from the date of
>> >>>       allocation.
>> 
>> >                 namely, how does the IANA decide that it SHOULD
>> >                 make the allocation? 4) talks about making a
>> >                 request, 5) instructs the IANA to make the
>> >                 allocation. That is, what criteria does the IANA
>> >                 use to execute step 5)?
>> 
>> Do you mean what initiates the IANA action or whether the IANA
>> need to perform any checks before doing that?

	Well, I guess it says that the WG chair will instruct the
	IANA to make the allocation, i.e., the IANA doesn't have
	any responsibility other than to maintain the
	registry (but see below; what part of the regsitry do we
	(IETF) have to replicate to make this work?)

>> Initiation of action would be an e-mail from the WG chairs, then
>> Ack'ed by the ADs (e.g., as we do for WG milestone updates)
>> 
>> As for the checks, I would expect IANA to verify conditions 2.a,
>> and 2.b (simply existence of the documentation and a confirmation
>> from the WG chair, again Ack'ed by ADs, that it's adequate), plus
>> confirmation from the chairs that conditions c and d are met.

	Gotcha.

>> 
>> >                 The second issue here is whether the IANA can
>> >                 actually time out an allocation (i.e., do they
>> >                 really have a notion of "temporary"; even though
>> >                 section 3.3 states that the don't need to; who
>> >                 does, and how to the revoke the allocation,
>> >                 etc).
>> 
>> Section 3.3 has this para that talks about it:
>> 
>>    If a follow-up request is not made, or the document fails to progress
>>    to a Standards Track RFC, the WG chairs are responsible for informing
>>    IANA that the code points are to be marked "deprecated" (and are not
>>    to be allocated); the WG chairs are further responsible for informing
>>    IANA when the deprecated code points can be completely de-allocated
>>    (i.e., made available for new allocations).
>> 
>> > The reason I as is that in my role as IANA
>> >                 technical adviser for multicast address
>> >                 assignment, we have the option to make
>> >                 allocations temporary (see RFC 3171), but the
>> >                 IANA can't really execute against that (that is,
>> >                 is seems they have no way of timing anything out;
>> >                 even if that mechanism existed, it doesn't seem
>> >                 that they have the next step, namely, a way to
>> >                 recover the allocation). I suppose this is a
>> >                 long-winded way of saying the "temporary tag"
>> >                 seems (in my experience with the IANA) at best
>> >                 operationally hypothetical.
>> 
>> The idea is that the IANA simply performs what's requested by
>> the chairs and/or authors (with AD approval) who keep track
>> of when allocations need to be deprecated and dealloacted.

	Does this mean that we will be keeping our own registry
	consisting of the various allocations, their owners, the
	relevant WG chairs, and the timeouts?

>> >         (ii).   One weakness with the  RFC 2434 subject matter
>> >                 expert approach is that more and more, people
>> >                 just don't care (that is, if you have an
>> >                 application that you can get to enough people
>> >                 that uses some code point that should be IANA
>> >                 assigned, e.g., a port or something), what do you
>> >                 care about what the IANA says (they can't stop
>> >                 you from using it, and if it gets into enough
>> >                 code, well, you get the point; suffice it to say
>> >                 that this happens).
>> 
>> >                 In any event, the "pre-RFC deadlock" described
>> >                 below seems to be just the case which will lead
>> >                 to commercial interests overcoming the
>> >                 process(es) you are trying to put in place, and
>> >                 you'll wind up with either the situation
>> >                 described above ("who cares what the IANA says"),
>> >                 or a land-grab for spaces of interest (knowing
>> >                 that the IANA can't really time out the
>> >                 allocations).
>> 
>> The way I look at it is IANA provides us with the function that we
>> (the community) need. If folks don't care about IANA or don't
>> understand it's needed, no amount of process can help here. On the
>> other hand, poor process(es) may discourage use of IANA, which I think
>> is the case with the "Standards Action" policy together with the STD
>> requirements in RTG area.

	The latter is part of what I think is causing the
	behavior I described (although in the cases I've seen, I
	don't think any amount of process effeciency would have
	helped, sadly).

>> Do you think that the processes proposed in the draft a) don't help
>> the problem at all, b) make it worse, c) create a new one, d)
>> something else?
>> 
>> >         (iii).  Section 2 d) is too vague
>> 
>> >                 "There is sufficient interest in early (pre-RFC)
>> >                 implementation and deployment in the community." 
>> 
>> >                 e.g., how is "sufficient" defined (or for that matter,
>> >                 what is a "community")? So my concern here is
>> >                 that this section is too loosely worded, and as
>> >                 such will open up the IANA to all kinds of early
>> >                 allocation requests. For example, if/when this
>> >                 becomes BCP, will it be possible to claim
>> >                 "sufficient interest" (whatever that is) and use
>> >                 that to circumvent "normal" allocation
>> >                 procedures (noting that the IANA will not be
>> >                 able to evaluate what constitutes "sufficient
>> >                 interest"). 
>> 
>> You are absolutely right--whether interest is sufficient or not is a
>> judgement call, just like the notion of a rough consensus.
>> 
>> 
>> >         (iv).   Section 3.2. (Follow-up)
>> 
>> >                 This seems to be granting WG chairs the authority
>> >                 to revoke a prior early allocation?
>> 
>> Right, based on the info from/discussion in the WG.
>>                 
>> >                 "It is the responsibility of the document authors
>> >                 and the Working Group chairs to review changes in
>> >                 the document, and especially in the
>> >                 specifications of the code points for which early
>> >                 allocation was requested to ensure that the
>> >                 changes are backwards compatible."
>> 
>> >                 Further, this section seems to create the
>> >                 mechanism for someone to cause some code point to
>> >                 be deprecated (just aruge that a change is
>> >                 required but not backwards compatiable).
>> 
>> The assumption is that by the time a temporary allocation is done,
>> condition 2.c has been met and major changes to the technology are
>> not required. Of course, it's a judgement call again, and there
>> will be mistakes, and situations where we do need to make changes
>> and they may as well be not backwards compatible. In this case,
>> using the old typecode may be risky.

	Gotcha.

	Thanks,

	Dave

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: David Meyer <[email-masked]>
CC: [email-masked], [email-masked]
Subject: [Idr] Re: problem with the allocation policy
Sender: [email-masked]
Date: Fri, 6 Feb 2004 11:24:06 -0800

Dave,

<hat = co-author>

>         Folks,

>         While I understand the need for such a policy (that much
>         seems to have been demonstrated), I have a few comments
>         on this draft:

>         (i).    Request (Section 3.1)

>                 Section 3.1 outlines a sequence of actions that
>                 result in "temporary" IANA allocation. A couple
>                 of points here. First, there seems to be a step
>                 missing between action 4) and 5):

>>>    4) If so, with the approval of the Area Director(s), the WG chairs
>>>       request IANA to make an early allocation.
>>> 
>>>    5) IANA makes an allocation from the appropriate registry, marking it
>>>       as "temporary", valid for a period of one year from the date of
>>>       allocation.

>                 namely, how does the IANA decide that it SHOULD
>                 make the allocation? 4) talks about making a
>                 request, 5) instructs the IANA to make the
>                 allocation. That is, what criteria does the IANA
>                 use to execute step 5)?

Do you mean what initiates the IANA action or whether the IANA
need to perform any checks before doing that?

Initiation of action would be an e-mail from the WG chairs, then
Ack'ed by the ADs (e.g., as we do for WG milestone updates)

As for the checks, I would expect IANA to verify conditions 2.a,
and 2.b (simply existence of the documentation and a confirmation
from the WG chair, again Ack'ed by ADs, that it's adequate), plus
confirmation from the chairs that conditions c and d are met.

>                 The second issue here is whether the IANA can
>                 actually time out an allocation (i.e., do they
>                 really have a notion of "temporary"; even though
>                 section 3.3 states that the don't need to; who
>                 does, and how to the revoke the allocation,
>                 etc).

Section 3.3 has this para that talks about it:

   If a follow-up request is not made, or the document fails to progress
   to a Standards Track RFC, the WG chairs are responsible for informing
   IANA that the code points are to be marked "deprecated" (and are not
   to be allocated); the WG chairs are further responsible for informing
   IANA when the deprecated code points can be completely de-allocated
   (i.e., made available for new allocations).

> The reason I as is that in my role as IANA
>                 technical adviser for multicast address
>                 assignment, we have the option to make
>                 allocations temporary (see RFC 3171), but the
>                 IANA can't really execute against that (that is,
>                 is seems they have no way of timing anything out;
>                 even if that mechanism existed, it doesn't seem
>                 that they have the next step, namely, a way to
>                 recover the allocation). I suppose this is a
>                 long-winded way of saying the "temporary tag"
>                 seems (in my experience with the IANA) at best
>                 operationally hypothetical.

The idea is that the IANA simply performs what's requested by
the chairs and/or authors (with AD approval) who keep track
of when allocations need to be deprecated and dealloacted.

>         (ii).   One weakness with the  RFC 2434 subject matter
>                 expert approach is that more and more, people
>                 just don't care (that is, if you have an
>                 application that you can get to enough people
>                 that uses some code point that should be IANA
>                 assigned, e.g., a port or something), what do you
>                 care about what the IANA says (they can't stop
>                 you from using it, and if it gets into enough
>                 code, well, you get the point; suffice it to say
>                 that this happens).

>                 In any event, the "pre-RFC deadlock" described
>                 below seems to be just the case which will lead
>                 to commercial interests overcoming the
>                 process(es) you are trying to put in place, and
>                 you'll wind up with either the situation
>                 described above ("who cares what the IANA says"),
>                 or a land-grab for spaces of interest (knowing
>                 that the IANA can't really time out the
>                 allocations).

The way I look at it is IANA provides us with the function that we
(the community) need. If folks don't care about IANA or don't
understand it's needed, no amount of process can help here. On the
other hand, poor process(es) may discourage use of IANA, which I think
is the case with the "Standards Action" policy together with the STD
requirements in RTG area.

Do you think that the processes proposed in the draft a) don't help
the problem at all, b) make it worse, c) create a new one, d)
something else?

>         (iii).  Section 2 d) is too vague

>                 "There is sufficient interest in early (pre-RFC)
>                 implementation and deployment in the community." 

>                 e.g., how is "sufficient" defined (or for that matter,
>                 what is a "community")? So my concern here is
>                 that this section is too loosely worded, and as
>                 such will open up the IANA to all kinds of early
>                 allocation requests. For example, if/when this
>                 becomes BCP, will it be possible to claim
>                 "sufficient interest" (whatever that is) and use
>                 that to circumvent "normal" allocation
>                 procedures (noting that the IANA will not be
>                 able to evaluate what constitutes "sufficient
>                 interest"). 

You are absolutely right--whether interest is sufficient or not is a
judgement call, just like the notion of a rough consensus.

>         (iv).   Section 3.2. (Follow-up)

>                 This seems to be granting WG chairs the authority
>                 to revoke a prior early allocation?

Right, based on the info from/discussion in the WG.
                
>                 "It is the responsibility of the document authors
>                 and the Working Group chairs to review changes in
>                 the document, and especially in the
>                 specifications of the code points for which early
>                 allocation was requested to ensure that the
>                 changes are backwards compatible."

>                 Further, this section seems to create the
>                 mechanism for someone to cause some code point to
>                 be deprecated (just aruge that a change is
>                 required but not backwards compatiable).

The assumption is that by the time a temporary allocation is done,
condition 2.c has been met and major changes to the technology are
not required. Of course, it's a judgement call again, and there
will be mistakes, and situations where we do need to make changes
and they may as well be not backwards compatible. In this case,
using the old typecode may be risky.

>         Just a couple of observations.

Thanks, Dave.

Alex

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: David Meyer <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: [Idr] Re: problem with the allocation policy
Sender: [email-masked]
Date: Fri, 6 Feb 2004 08:07:36 -0800

	Folks,

	While I understand the need for such a policy (that much
	seems to have been demonstrated), I have a few comments
	on this draft:

	(i).	Request (Section 3.1)

		Section 3.1 outlines a sequence of actions that
		result in "temporary" IANA allocation. A couple
		of points here. First, there seems to be a step
		missing between action 4) and 5):

>>    4) If so, with the approval of the Area Director(s), the WG chairs
>>       request IANA to make an early allocation.
>> 
>>    5) IANA makes an allocation from the appropriate registry, marking it
>>       as "temporary", valid for a period of one year from the date of
>>       allocation.

		namely, how does the IANA decide that it SHOULD
		make the allocation? 4) talks about making a
		request, 5) instructs the IANA to make the
		allocation. That is, what criteria does the IANA
		use to execute step 5)?

		The second issue here is whether the IANA can
		actually time out an allocation (i.e., do they
		really have a notion of "temporary"; even though
		section 3.3 states that the don't need to; who
		does, and how to the revoke the allocation,
		etc). The reason I as is that in my role as IANA
		technical adviser for multicast address
		assignment, we have the option to make
		allocations temporary (see RFC 3171), but the
		IANA can't really execute against that (that is,
		is seems they have no way of timing anything out;
		even if that mechanism existed, it doesn't seem
		that they have the next step, namely, a way to
		recover the allocation). I suppose this is a
		long-winded way of saying the "temporary tag"
		seems (in my experience with the IANA) at best
		operationally hypothetical. 

	(ii).	One weakness with the  RFC 2434 subject matter
		expert approach is that more and more, people
		just don't care (that is, if you have an
		application that you can get to enough people
		that uses some code point that should be IANA
		assigned, e.g., a port or something), what do you
		care about what the IANA says (they can't stop
		you from using it, and if it gets into enough
		code, well, you get the point; suffice it to say
		that this happens).

		In any event, the "pre-RFC deadlock" described
		below seems to be just the case which will lead
		to commercial interests overcoming the
		process(es) you are trying to put in place, and
		you'll wind up with either the situation
		described above ("who cares what the IANA says"),
		or a land-grab for spaces of interest (knowing
		that the IANA can't really time out the
		allocations). 

	(iii).	Section 2 d) is too vague

		"There is sufficient interest in early (pre-RFC)
		implementation and deployment in the community." 

		e.g., how is "sufficient" defined (or for that matter,
		what is a "community")? So my concern here is
		that this section is too loosely worded, and as
		such will open up the IANA to all kinds of early
		allocation requests. For example, if/when this
		becomes BCP, will it be possible to claim
		"sufficient interest" (whatever that is) and use
		that to circumvent "normal" allocation
		procedures (noting that the IANA will not be
		able to evaluate what constitutes "sufficient
		interest"). 

	(iv).   Section 3.2. (Follow-up)

		This seems to be granting WG chairs the authority
		to revoke a prior early allocation? 
		
		"It is the responsibility of the document authors
		and the Working Group chairs to review changes in
		the document, and especially in the
		specifications of the code points for which early
		allocation was requested to ensure that the
		changes are backwards compatible."

		Further, this section seems to create the
		mechanism for someone to cause some code point to
		be deprecated (just aruge that a change is
		required but not backwards compatiable).

	Just a couple of observations.

	Dave

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] Re: problem with the allocation policy
Sender: [email-masked]
Date: Thu, 05 Feb 2004 17:38:53 -0800

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>

Folks,

In thinking about possible (potential) alternatives
please look at the attached.

Yakov.

------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <[email-masked]>
Content-Description: forwarded message

Delivery-Date: Thu Feb  5 13:14:39 2004
To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-kompella-zinin-early-allocation-00.txt
Date: Thu, 05 Feb 2004 15:42:32 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Early IANA Allocation of Standards Track Codepoints
	Author(s)	: K. Kompella
	Filename	: draft-kompella-zinin-early-allocation-00.txt
	Pages		: 7
	Date		: 2004-2-5
	
This memo discusses earlier allocation of code points by IANA as a
   remedy to the problem created by the 'Standards Action' IANA policy
   for protocols where, by the IETF process, implementation and
   deployment experience is desired or required prior to publication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kompella-zinin-early-allocation-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kompella-zinin-early-allocation-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-kompella-zinin-early-allocation-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-kompella-zinin-early-allocation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

------- =_aaaaaaaaaa0--

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [Idr] BGP-4 implementations - Urgent need input
Sender: [email-masked]
Date: Thu, 5 Feb 2004 07:59:38 -0500

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3EBE7.E94DC064
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Help!  I'm trying to get new work items
added to the charter.   We are almost there but
I need your help to complete this by Friday
so I can submit the reports as Internet Drafts.=20

Progress:
	1) We got 3 implementation reports=20
             (Cisco, Laurel, and NextHop).

	2) We got 3 MIB implementations:
	   (Cisco, NextHop, Redback).

	3) Reports are written

Problem:
=20
I need two more things to complete the=20
implementation report:=20

	1) a quick note from anyone who
	  implements BGP-4 according to draft-23
	  the draft telling me:

	   a)who they interoperate with
	   b)if you didn't fill out the survey if
	     the length of the survey (259 questions)
           was the problem
=09

	2) A note from anyone with a BGP-4 MIB who implements
	   the following information.   If you do, and could
	   fill out the attached MIB report, and send me a=20
	   snmpwalk of this portion of the MIB that would really=20
	   help!!

    (N)        bgpPathAttrPeer
    (N)        bgpPathAttrDestNetwork
    (N)        bgpPathAttrOrigin
    (N)        bgpPathAttrASPath
    (N)        bgpPathAttrNextHop
    (N)        bgpPathAttrInterASMetric
	  =20
Please help!  Send me a note today if you
think you can.

Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My thanks to the following people:

a big thanks to Alvaro Retano who wrote up the=20
spread sheet and questions for the implementation report.
Sharon Chisholm (our resident MIB expert) wrote up
the questions for the BGP MIB implementation report.

BGP-4 Implementation report folks
-----------------------------------------
1) Alvaro Retano -Cisco (and anyone who helped him)
2) Ardas Cilingiroglu and Manish Vora at Laurel networks,
3) Bill Siadak, Matt Richardson, and Shane Wright at NextHop.

BGP-4 MIB implementation report
-------------------------------
1) Enke Chen, Jenny at Redback=20
2) Divya Mukundan , Russ White, and anyone that helped them
    at Cisco.
3) Jeff Haas at NextHop=20

 <<bgp mib checklist1.txt>>=20

------_=_NextPart_001_01C3EBE7.E94DC064
Content-Type: text/plain;
	name="bgp mib checklist1.txt"
Content-Description: bgp mib checklist1.txt
Content-Disposition: attachment;
	filename="bgp mib checklist1.txt"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C3EBE7.E94DC064--

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] problem with the allocation policy
Sender: [email-masked]
Date: Tue, 03 Feb 2004 17:02:33 -0800

Folks,

This is to bring to your attention a problem with the allocation
policy that is specified in the current BGP spec.

>From the IANA Considerations section of the current BGP spec:

   All new BGP message types, Path Attributes Type codes, Message
   Header Error subcodes, OPEN Message Error subcodes, and UPDATE
   Message Error subcodes MUST only be made using the Standards Action
   process defined in [RFC2434].

>From rfc2434:

   Standards Action - Values are assigned only for Standards Track
       RFCs approved by the IESG.

The problem with the Standards Action policy is that it makes
impossible to assign a value when a document is just an Internet
Draft. Yet in the routing area to advance an Internet Draft to even
a Proposed Standard requires more than one (interoperable)
implementation as a prerequisite for the advancement. Which means
that it is necessary to assign a value when the document is still
an Internet Draft, prior to the approval by the IESG.

So, the bottom line is that the Standards Action policy, as *currently*
specified in rfc2434, is unsuitable (and not just for IDR, but for
any WG in the Routing Area).

Yakov.

P.S. In fact, any policy that requires an RFC for the assigment is
likely to be unsuitable (not just for IDR, but for any WG in the
Routing Area).

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr