Subject: Graceful restart comment

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Apr 2002 12:00:08 -0400

One of the cirumstances that a graceful restart would be useful is
for a software upgrade where the box is really "gracefully" going down.
However, the graceful restart specification requires a TCP reset
to signal that the peer is going down and graceful restart is to
be applied.

Wouldn't it be cleaner if a NOTIFICATION with a particular subcode
is used for the case where the speaker is intentionally requesting
a graceful restart?

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 29 Apr 2002 09:55:02 -0700

Jeff,

> is used for the case where the speaker is intentionally requesting

The scenario you described above could be handled *without* a
NOTIFICATION with a particular subcode. With this in mind, what
are the *practical* benefits that a NOTIFICATION with a particular
subcode is going to bring ?

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Apr 2002 12:58:53 -0400

> subcode is going to bring ?

Strictly an operational benefit.  It would be nice for an operator
to know that the other side restarted because a human did it rather
than the box was crashing.

-- 
Jeff Haas 
NextHop Technologies

---

From: Enke Chen <[email-masked]>
Date: Mon, 29 Apr 2002 12:56:58 -0700

Hi, Jeffrey:

> Date: Mon, 29 Apr 2002 12:00:08 -0400
> From: Jeffrey Haas <[email-masked]>
> To: [email-masked]
> Subject: Graceful restart comment
> Message-ID: <[email-masked]>
> 

A NOTIFICATION message has traditionally meant the "non-graceful"
restart, and both the sender and the receiver of the message would
clear the related RIB. I do not think that we should change the
semantics of NOTIFICATION.

---------------------
6. BGP Error Handling

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent, and the BGP connection is closed. If no
   Error Subcode is specified, then a zero must be used.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed, the associated Adj-RIB-In has
   been cleared, and that all resources for that BGP connection have
   been deallocated. Entries in the Loc-RIB associated with the remote
   peer are marked as invalid. The fact that the routes have become
   invalid is passed to other BGP peers before the routes are deleted
   from the system.
---------------------

-- Enke

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 29 Apr 2002 13:12:04 -0700

I agree. The semantics of the NOTIFICATION message shouldnt be changed.
We seem to need a new message type, say an INFORMATIONAL message that
sends out information (notifies actually) to the peer, but doesnt 
necessarily cause a session reset.

-Gargi

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Apr 2002 16:26:59 -0400

> necessarily cause a session reset.

Other things this would be useful for is when packets are discarded
by an implementation where it is unnecessary to actually tear
down the peering session.  A good example is when a peer sends
you an MP_REACH_NLRI that you don't support, or you're going to
start ignoring a given AFI/SAFI because of errors in the PDU, but
are going to leave the peering session up.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 29 Apr 2002 13:58:04 -0700 (PDT)

Jeffrey Haas writes:

>> I agree. The semantics of the NOTIFICATION message shouldnt be
>> changed.  We seem to need a new message type, say an INFORMATIONAL
>> message that sends out information (notifies actually) to the peer,
>> but doesnt necessarily cause a session reset.

> by an implementation where it is unnecessary to actually tear down
> the peering session.  A good example is when a peer sends you an
> MP_REACH_NLRI that you don't support, or you're going to start
> ignoring a given AFI/SAFI because of errors in the PDU, but are
> going to leave the peering session up.

Jeff,
If you have errors in a PDU the best thing to do is to tear down the
session not to selectivly ignore bits... if you can't trust your peer
to format updates correctly then you can't trust any of the nlri that
it has sent you.

Accepting bad routing information is usually much harder to debug than
not accepting information...

I can't think of any scenario where it is reasonable to discard
packets from the neighbor while maintaining the session up... if your
neighbor is sending you packets for an NLRI that it hasn't negociated,
chances are that there is something else wrong with it.

The "be liberal in what you accept" principle is a very good idea when
we are talking about encoding formats but personally i don't think it
applies when your peer demonstrates that it's internal state is fubar.

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Apr 2002 17:22:31 -0400

> to format updates correctly then you can't trust any of the nlri that

Pedro,

Turn your wayback machine to the IDR list when we had the leaking
confederation segments incident killing parts of the Internet. :-)

The specific circumstances I have in mind are where we have a well-formed
packet, but the information is semantically incorrect, discard the
PDU.

> not accepting information...

Hence the reason for telling your peer that you're doing this.

Can you think of circumstances where your implementation will drop
an update where it doesn't drop the peering session?

> chances are that there is something else wrong with it.

RFC 2858, section 6, paragraph 1. :-)

Mind you, I don't really have a problem with the portion I just cited,
but implementing that without having dynamic capabilities nor 
some sort of informational pushback is asking for your OAM people to
put your head on a plate. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 29 Apr 2002 15:04:41 -0700 (PDT)

Jeffrey Haas writes:

>> If you have errors in a PDU the best thing to do is to tear down
>> the session not to selectivly ignore bits... if you can't trust
>> your peer to format updates correctly then you can't trust any of
>> the nlri that it has sent you.

> confederation segments incident killing parts of the Internet. :-)

There have been several incidents in the past related to information
that was propagated incorrectly and/or crashed the receivers... do you
mind providing a pointer to the specific incident that you want to
refer to... ? also in some of those incidents, the "rumor" explanation
tends to sometimes differ from reality.

> The specific circumstances I have in mind are where we have a
> well-formed packet, but the information is semantically incorrect,
> discard the PDU.

So, if you detect that your peer is sending you semantically incorrect
information shouldn't you discard all information that the peer sent
you ?

If the peer is leaking you bad attributes of some kind how do you know
which attributes to accept... ?

The tradeoff here is that while by droping the session one may be
rejecting NLRI that would otherwise have a valid path, by resseting it
one makes sure that you don't accept information that may poison other
valid routes. In pratice i believe that the worse incidents that we
have faced have been the ones related to poison information... thus my
preference to err on the side of reseting the session.

> an update where it doesn't drop the peering session?

Drop ? nope... not that i can't think of.

>> packets from the neighbor while maintaining the session up... if
>> your neighbor is sending you packets for an NLRI that it hasn't
>> negociated, chances are that there is something else wrong with it.

> RFC 2858, section 6, paragraph 1. :-)

Which suggests that one 'may' zap the other guy... imho, one should do
it if the routers support capability negociation.

> Mind you, I don't really have a problem with the portion I just
> cited, but implementing that without having dynamic capabilities

imho, dynamic capabilities introduce much more uncertainty (you can't
know for sure what is enabled on the session anymore) than what their
worth. At least i wouldn't expect people to be changing their NLRI
often enought that this feature will actually be worthwhile vs the
introduced complexity... i.e. imho it fails the KISS criteria.

> nor

imho, the best way to keep OAM people happy is to make things fail in
a detectable and most predictable way... having an information msg hit
the logs somewhere while you are propagating bogus information would
be an unfriendly thing to do.

There are no guarantees that indeed the draconian scenario that i'm
suggesting will happen...

However pesonally i'm very sceptic of the informational message
concept...

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Apr 2002 10:16:17 -0400

> tends to sometimes differ from reality.

IDR list, approximately last week of June 2001.  Subject of
"Re: RFC 3065, confeds.."

In this particular case, the rumor was "private as's were killing
peering sessions".  In reality, confederation AS segments were 
leaking outside of a confederation boundary due to someone's bug,
propagating across the entire Internet, and killing the peering
session of some implementations that chose to read the specification
as saying "if you're not a confederation peer, I should never see
confederation segments from you".

> information shouldn't you discard all information that the peer sent

In some cases, no.  The confed case above is one example.  Another
example would be an ORIGIN of value 4 or higher.

> which attributes to accept... ?

That is the challenge.

> preference to err on the side of reseting the session.

I would tend to agree with the exception of the fact that stuff
from "far away" that is propagated may kill your session with your
peer, just because they chose to propagate it.

Discarding bad PDU's blackholes some reachability for you.  Killing
your peering session blackholes it all.

> it if the routers support capability negociation.

If one doesn't support dynamic capabilities, one should probably
drop the entire peering session.  Otherwise you start discarding
routes and you may not know why - exactly the scenario you were
worried about.

> be an unfriendly thing to do.

The point is that one should discard the reachability that is questionable
and not propagate it.

> However pesonally i'm very sceptic of the informational message

The big motivator is the ability to tell your peer that they're
doing something you don't like without dropping the peering session.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Apr 2002 10:28:23 -0400

Enke,

> semantics of NOTIFICATION.

With all respect, closing the transport connection is far less graceful
and the BGP spec barely distinguishes between the two cases.
IIRC, the only distinction in the (original) FSM is transitions
in the Active state and also version negotiation.  Otherwise,
a transport connection close in the Established state is indistinguishable
from a NOTIFICATION.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 30 Apr 2002 10:28:23 -0400
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

Enke,

> semantics of NOTIFICATION.

With all respect, closing the transport connection is far less graceful
and the BGP spec barely distinguishes between the two cases.
IIRC, the only distinction in the (original) FSM is transitions
in the Active state and also version negotiation.  Otherwise,
a transport connection close in the Established state is indistinguishable
from a NOTIFICATION.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 30 Apr 2002 10:16:17 -0400
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

That is the challenge.

-- 
Jeff Haas 
NextHop Technologies

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-aspath-orf-01.txt
Date: Tue, 30 Apr 2002 07:15:52 -0400
Sender: [email-masked]

--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		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-01.txt
	Pages		: 
	Date		: 29-Apr-02
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-01.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-aspath-orf-01.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-aspath-orf-01.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-aspath-orf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-aspath-orf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Mon, 29 Apr 2002 15:04:41 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Gargi Nalawade <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

  Pedro.

Date: Mon, 29 Apr 2002 17:22:31 -0400
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Gargi Nalawade <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

Pedro,

-- 
Jeff Haas 
NextHop Technologies

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: Re: Graceful restart comment
Date: Mon, 29 Apr 2002 17:07:51 -0400
Sender: [email-masked]

Pedro> if your neighbor is sending you packets for an NLRI that
Pedro> it hasn't negociated, chances are that there is something
Pedro> else wrong with it.

However, keep in mind that if dynamic capability negotiation is used you 
must be prepared to receive (and ignore) an UPDATE for an address-family 
which you withdrew recently. This scenario can occur if a CAPABILITY message 
withdrawing the Multi-Protocol capability for an address-family and an 
UPDATE message for that same address family cross each other.

(I still agree with the more general point Pedro was making in his e-mail: 
don't trust a peer which is advertising bogus information to you).

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Date: Mon, 29 Apr 2002 13:58:04 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Gargi Nalawade <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

Jeff,

  Pedro.

Date: Mon, 29 Apr 2002 13:48:25 -0700
From: Gargi Nalawade <[email-masked]>
To: "Natale, Jonathan" <[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

"Natale, Jonathan" wrote:
> 
> Please excuse my ignorance, but is there an INFORMATIONAL msg type?  Type 6?

No there isnt one yet. But work in progress on introducing that.

> I though all notifications kill the session?

yes they do. And hence the need for the above, so a peer can be *notified*,
oops lets call it *informed*, without the session being reset.

-Gargi

> 
> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 4:27 PM
> To: Gargi Nalawade
> Cc: Enke Chen; [email-masked]
> Subject: Re: Graceful restart comment
> 

Date: Mon, 29 Apr 2002 16:26:59 -0400
From: Jeffrey Haas <[email-masked]>
To: Gargi Nalawade <[email-masked]>
Cc: Enke Chen <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 29 Apr 2002 13:12:04 -0700
From: Gargi Nalawade <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

-Gargi

> semantics of NOTIFICATION.

Date: Mon, 29 Apr 2002 15:57:18 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: cooperative route filtering questions and comments
Sender: [email-masked]

Yakov,

Thanks for all of the clarifications.  Looking forward to seeing
the next revision.

On Mon, Apr 29, 2002 at 12:49:34PM -0700, Yakov Rekhter wrote:
[...]

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Graceful restart comment 
Date: Mon, 29 Apr 2002 12:56:58 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

---------------------
6. BGP Error Handling

-- Enke

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: cooperative route filtering questions and comments 
Date: Mon, 29 Apr 2002 12:49:34 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> I'm reviewing the ORF documents and several questions have occured to me:
> 
> When you receive a given ORF, the action type may be ADD, REMOVE or
> REMOVE-ALL.  However, it is unstated whether or not an ADD is also
> an implicit replace.  Consider the following:

in the context of community-based ORFs ADD is also an implicit replace.

> The BGP Speaker receives an ADD with a match of PERMIT for a community
> ORF of community set C1 and then it later (but not necesarily immediately)
> followed by another ADD of PERMIT for the same C1 without an intervening
> REMOVE, are there now two C1's in the ORF list?

Just C1.
  
> Similarly, if one receives an ADD with a match of PERMIT for C1 and
> then receives an ADD with a many of DENY for C1, the behavior should
> be to PERMIT for C1, correct?  
> 
> However, if the behavior of ADD is to replace or ignore, then
> the second ADD of C1 as a DENY may result in either the PERMIT
> (sent first) to be replaced or the later DENY (sent second) to be ignored.

The result is DENY for C1.

> Thanks to the communities specification being ambiguous, we also have
> the issue of ordering and duplicate communities within a given ORF.
> If one receives an ADD for a community set C1 and then a REMOVE
> for C2 where the elements of C1 and C2 are the same but in a 
> different order, should the REMOVE still take place or should C2
> fail to match unless C2 was explicitly sent?

The REMOVE still takes place (as C1 and C2 are sets, and the order of 
elements within a set doesn't matter).

> I believe that this implies that the receiving BGP Speaker must
> store the exact ORF received for purposes of ORF list manipulation
> regardless of internal implementation.
> 
> The current ORF specification has room for a BGP Speaker to advertise
> both the cooperative route filtering capability and route refresh
> at the same time.  Since ORFs overload the RouteRefresh message
> type, this now means that a receiving speaker must now determine
> if the message is an ORF message or a plain RouteRefresh message
> from the length of the message.  A sentence in the specification
> that spells this out would be nice.

we'll add this to the next revision of the text.

> When one specifies REMOVE-ALL, this Action is encoded in the
> ORF along with a Match bit.  This seems to imply (currently)
> that one can do a REMOVE-ALL on all PERMITs and a REMOVE-ALL
> on DENYs separately.  I suspect that REMOVE-ALL was intended
> to reflect removing all ORFs of a particular type.  As such,
> it should be noted as ignoring the Match bit when being processed.

ditto.

> Would this also apply to an explicit REMOVE?  I.e., if ADD is
> not an replace operation, does a Speaker need to look for
> the Match bit when processing REMOVEs?

in the context of community-based ORFs ADD is a replace operation.

Yakov.

Date: Mon, 29 Apr 2002 13:05:29 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: cooperative route filtering questions and comments
Sender: [email-masked]

I'm reviewing the ORF documents and several questions have occured to me:

When you receive a given ORF, the action type may be ADD, REMOVE or
REMOVE-ALL.  However, it is unstated whether or not an ADD is also
an implicit replace.  Consider the following:

The BGP Speaker receives an ADD with a match of PERMIT for a community
ORF of community set C1 and then it later (but not necesarily immediately)
followed by another ADD of PERMIT for the same C1 without an intervening
REMOVE, are there now two C1's in the ORF list?

Similarly, if one receives an ADD with a match of PERMIT for C1 and
then receives an ADD with a many of DENY for C1, the behavior should
be to PERMIT for C1, correct?  

However, if the behavior of ADD is to replace or ignore, then
the second ADD of C1 as a DENY may result in either the PERMIT
(sent first) to be replaced or the later DENY (sent second) to be ignored.

Thanks to the communities specification being ambiguous, we also have
the issue of ordering and duplicate communities within a given ORF.
If one receives an ADD for a community set C1 and then a REMOVE
for C2 where the elements of C1 and C2 are the same but in a 
different order, should the REMOVE still take place or should C2
fail to match unless C2 was explicitly sent?

I believe that this implies that the receiving BGP Speaker must
store the exact ORF received for purposes of ORF list manipulation
regardless of internal implementation.

The current ORF specification has room for a BGP Speaker to advertise
both the cooperative route filtering capability and route refresh
at the same time.  Since ORFs overload the RouteRefresh message
type, this now means that a receiving speaker must now determine
if the message is an ORF message or a plain RouteRefresh message
from the length of the message.  A sentence in the specification
that spells this out would be nice.

When one specifies REMOVE-ALL, this Action is encoded in the
ORF along with a Match bit.  This seems to imply (currently)
that one can do a REMOVE-ALL on all PERMITs and a REMOVE-ALL
on DENYs separately.  I suspect that REMOVE-ALL was intended
to reflect removing all ORFs of a particular type.  As such,
it should be noted as ignoring the Match bit when being processed.

Would this also apply to an explicit REMOVE?  I.e., if ADD is
not an replace operation, does a Speaker need to look for
the Match bit when processing REMOVEs?

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 29 Apr 2002 12:58:53 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Graceful restart comment
Sender: [email-masked]

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Graceful restart comment 
Date: Mon, 29 Apr 2002 09:55:02 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

Yakov.

Date: Mon, 29 Apr 2002 12:00:08 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Graceful restart comment
Sender: [email-masked]

-- 
Jeff Haas 
NextHop Technologies

To: "[email-masked]'" <[email-masked]>
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: FW: BGP Route Reflection Question 
Date: Mon, 29 Apr 2002 08:20:36 -0600
Sender: [email-masked]

> If the configutration is valid and if some of the points you make
> about reflection and acceptance of routes by RR2 are taken into 
> consideration, then how will RRC3 recieve the routes generated by 
> RRC1.
> Going by your algorithm
> 1)RRC1 advertises its routes to RR1
> 2) RR1 attaches its CLUSTER_ID and reflects the route to client and
> non-client peers.
> 3) Since RR2 is in the same clutser (thus has the same CLUSTER_ID as
> RR1) RR2 drops the message.
> 4) Since RRC3 has peering only with RR2, RRC3 does not get the
> route.
> 
> This is not the desired behaviour as we would want both RR2 and 
> RRC3 to know about RRC1s routes.

I'd call this a broken design.  

RRC3 would either need to be a client of RR1 or there needs to be 
peering between clients within the cluster.

> If configured with the same CLUSTER_ID, no.  If configured
> with a different CLUSTER_ID, yes.
> 
> VIK>> 
>          1)If RR1 has peering with an EBGP peer X.
>          2) RR1 receives a route from X. RR1 reflects the 
>              route to it's client and non-client peers. Before 
>              advertising, RR1 adds its CLUSTER_ID.

Nope.  The route reflection attributes are ONLY added to 
"reflected routes".  EBGP learned and locally-sourced routes
wouldn't be considered "reflected routes".

>          3) RR2 receives the advertisement and drops it
>              because of the presence of its CLUSTER_ID.
>          4) RRC3 does not get the route because RR2 did not get it.

Nope, see above.

-danny

To: [email-masked]
Subject: 2858bis-02
Date: Mon, 29 Apr 2002 06:35:48 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The revised text adds "Obsoletes RFC2858" and also adds
"This document removes the definition of SAFI = 3." to Section 12.

Yakov.
------- Forwarded Message

Date:    Mon, 29 Apr 2002 07:53:06 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-02.txt

- --NextPart

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

	Title		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, R. Chandra, D. Katz, Y. Rekhter
	Filename	: draft-ietf-idr-rfc2858bis-02.txt
	Pages		: 10
	Date		: 26-Apr-02
	
Currently BGP-4 is capable of carrying routing information only for
IPv4. This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, etc...). The extensions are backward compatible - a router that
supports the extensions can interoperate with a router that doesn't
support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-rfc2858bis-02.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-rfc2858bis-02.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-rfc2858bis-02.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-02.txt
Date: Mon, 29 Apr 2002 07:53:06 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, R. Chandra, D. Katz, Y. Rekhter
	Filename	: draft-ietf-idr-rfc2858bis-02.txt
	Pages		: 10
	Date		: 26-Apr-02
	
Currently BGP-4 is capable of carrying routing information only for
IPv4. This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, etc...). The extensions are backward compatible - a router that
supports the extensions can interoperate with a router that doesn't
support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-02.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-rfc2858bis-02.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-rfc2858bis-02.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-rfc2858bis-02.txt

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

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

--OtherAccess--

--NextPart--

From: "Reddy, Vikram" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: FW: BGP Route Reflection Question 
Date: Mon, 29 Apr 2002 07:31:13 -0400
Sender: [email-masked]

Hi Danny,

Please see my response inline..

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Friday, April 26, 2002 9:33 AM
To: [email-masked]'
Subject: Re: FW: BGP Route Reflection Question 

> 1) Is the above topology of configuring redundant RRs only for 
> some of the RRCs valid?

Yes. 
VIK>>
	If the configutration is valid and if some of the points you make
about reflection
	and acceptance of routes by RR2 are taken into consideration,
	then how will RRC3 recieve the routes generated by RRC1.
	Going by your algorithm
	1)RRC1 advertises its routes to RR1
	2) RR1 attaches its CLUSTER_ID and reflects the route to client and
non-client peers.
	3) Since RR2 is in the same clutser (thus has the same CLUSTER_ID as
RR1) 
	   RR2 drops the message.
	4) Since RRC3 has peering only with RR2, RRC3 does not get the
route.

This is not the desired behaviour as we would want both RR2 and RRC3 to know
about RRC1s routes.

> 2) If you configure two RRs in a cluster for the purpose of 
> redundancy (say RR1 and RR2), should RR1 treat RR2 as any 
> other client peer(and vice-versa)?

No, they'd be Non-Client peers and SHOULD be configured with 
the same CLUSTER_ID value.

> 3) If RR1 receives a route from one of its client (say 
> RRC1) and it is the best route, should RR1 send this 
> route to RR2?

Yes, though it's considered a "reflected route" and should 
now contain CLUSTER_LIST/CLUSTER_ID, ORIGINATOR_ID, etc...

> 4) If so, should RR2 accept it? 

If configured with the same CLUSTER_ID, no.  If configured
with a different CLUSTER_ID, yes.

VIK>> 
         1)If RR1 has peering with an EBGP peer X.
         2) RR1 receives a route from X. RR1 reflects the 
             route to it's client and non-client peers. Before 
             advertising, RR1 adds its CLUSTER_ID.
         3) RR2 receives the advertisement and drops it
             because of the presence of its CLUSTER_ID.
         4) RRC3 does not get the route because RR2 did not get it.

So, EBGP routes learnt by RR1 will never reach RR2 and RRC3 and clearly
this id not the desired behaviour.
        
The same argument goes for routes originated by RR2.

> If RR2 accepts it, should it reflect it back to its clients? 

If RR2's CLUSTER_ID isn't contained in the CLUSTER_LIST, then
yes.

> If it does reflect it to its client some clients which have multiple
> peering sessions with the RRs (Ex RR2) will get the route twice, once 
> from RR1 and once from RR2.

Indeed, hence the use of the term "redundant".

> If it shouldn't reflect it, on what basis does RR2 decide that this
> is a reflected route and it should not reflect it further?

The CLUSTER_ID value contained in the CLUSTER_LIST.  

Also, some RR implementations don't reflect routes to routers whose 
ROUTER_ID value is equal to that of the ORIGINATOR_ID value.  
Others require that the client ignore/discard routes received from
a peer if the ORIGINATOR_ID contained in the route is equal to 
the local ROUTER_ID value.

-danny

>From the scenarios I explanied above, the method of RR2 not accepting
routes from RR1 because of the presence of the same CLUSTER_ID will not
work.

Regards,
Vikram 

> Thank you,
> Vikram.

To: [email-masked]
Subject: 2842bis-02
Date: Fri, 26 Apr 2002 08:06:59 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

As requested by the IESG, it includes "Obsolete RFC2842", 
and the diff section.

Yakov.
------- Forwarded Message

Date:    Fri, 26 Apr 2002 08:14:13 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2842bis-02.txt

- --NextPart

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

	Title		: Capabilities Advertisement with BGP-4
	Author(s)	: R. Chandra, J. Scudder
	Filename	: draft-ietf-idr-rfc2842bis-02.txt
	Pages		: 5
	Date		: 25-Apr-02
	
Currently BGP-4 requires that when a BGP speaker receives an OPEN
message with one or more unrecognized Optional Parameters, the
speaker must terminate BGP peering. This complicates introduction of
new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities,
that is expected to facilitate introduction of new capabilities in
BGP by providing graceful capability advertisement without requiring
that BGP peering be terminated.
This document obsoletes RFC2842.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2842bis-02.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-rfc2842bis-02.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-rfc2842bis-02.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-rfc2842bis-02.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: "[email-masked]'" <[email-masked]>
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: FW: BGP Route Reflection Question 
Date: Fri, 26 Apr 2002 08:32:55 -0600
Sender: [email-masked]

> 1) Is the above topology of configuring redundant RRs only for 
> some of the RRCs valid?

Yes. 

> 2) If you configure two RRs in a cluster for the purpose of 
> redundancy (say RR1 and RR2), should RR1 treat RR2 as any 
> other client peer(and vice-versa)?

No, they'd be Non-Client peers and SHOULD be configured with 
the same CLUSTER_ID value.

> 3) If RR1 receives a route from one of its client (say 
> RRC1) and it is the best route, should RR1 send this 
> route to RR2?

Yes, though it's considered a "reflected route" and should 
now contain CLUSTER_LIST/CLUSTER_ID, ORIGINATOR_ID, etc...

> 4) If so, should RR2 accept it? 

If configured with the same CLUSTER_ID, no.  If configured
with a different CLUSTER_ID, yes.

> If RR2 accepts it, should it reflect it back to its clients? 

If RR2's CLUSTER_ID isn't contained in the CLUSTER_LIST, then
yes.

> If it does reflect it to its client some clients which have multiple
> peering sessions with the RRs (Ex RR2) will get the route twice, once 
> from RR1 and once from RR2.

Indeed, hence the use of the term "redundant".

> If it shouldn't reflect it, on what basis does RR2 decide that this
> is a reflected route and it should not reflect it further?

The CLUSTER_ID value contained in the CLUSTER_LIST.  

Also, some RR implementations don't reflect routes to routers whose 
ROUTER_ID value is equal to that of the ORIGINATOR_ID value.  
Others require that the client ignore/discard routes received from
a peer if the ORIGINATOR_ID contained in the route is equal to 
the local ROUTER_ID value.

-danny

> Thank you,
> Vikram.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2842bis-02.txt
Date: Fri, 26 Apr 2002 08:14:13 -0400
Sender: [email-masked]

--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		: Capabilities Advertisement with BGP-4
	Author(s)	: R. Chandra, J. Scudder
	Filename	: draft-ietf-idr-rfc2842bis-02.txt
	Pages		: 5
	Date		: 25-Apr-02
	
Currently BGP-4 requires that when a BGP speaker receives an OPEN
message with one or more unrecognized Optional Parameters, the
speaker must terminate BGP peering. This complicates introduction of
new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities,
that is expected to facilitate introduction of new capabilities in
BGP by providing graceful capability advertisement without requiring
that BGP peering be terminated.
This document obsoletes RFC2842.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2842bis-02.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-rfc2842bis-02.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-rfc2842bis-02.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-rfc2842bis-02.txt

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

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

--OtherAccess--

--NextPart--

From: "Reddy, Vikram" <[email-masked]>
To: "'Krishnan, Vijay G.'" <[email-masked]>, "'Venu Kumar G - CTD, Chennai.'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: BGP Route Reflection Question
Date: Fri, 26 Apr 2002 07:39:20 -0400
Sender: [email-masked]

Hi,

I request one of the authors to clarify the point about the behaviour
of RRs in case of multiple redundant RRs in a cluster 
and remove the confusion about it.

>From what I am getting from what both Venu and Vijay have written, it
looks like there is a difference in the approach they are suggesting.

What Venu seems to say is (From an earlier mail he sent to the board and
also from some mail messages he sent to me privately) :

1)If RR1 sends a route to RR2 (originated by client), RR2 should
  not accept it because of the presence of ClusterID.
2)If RR1 originates a route, it will not add its cluter ID,
  and RR2 will accept and reflect this route to its clients,
  in which case the clients will receive multiple routes 
  (having same Path Attributes but from different peers)
  and will choose one of them.
   
What Vijay seems to be saying is:
If RR1 sends a route to RR2 (originated by client or originated by RR1)
RR1 will add its cluster ID in both the cases. Further RR2
should accept this route for itself because it was sent by a client
but should  not reflect it to its clients i.e the presence of its
cluster Id in a route sent by a client does not mean a loop but
it should be taken as a reflected route and should not be reflected
further.

IMHO: 
I request one of the authors to clarify this point and remove the confusion.

I, however think what Vijay says will work correctly in all cases.
There is one thing in the method Venu suggested that does not jell.
If RR1 has an EBGP peer with X and RR2 does not, then, following Venu's
method,
RR1 will add its clutser ID and RR2 will drop it. In this case RR2 will
never 
learn the EBGP routes learnt by RR1.
Venu had earlier mentioned in an E-mail to me that RR2 must also be
configured to 
have peering with X, but it is not mandatory to have symmetry for EBGP
peers.It can
only be enforced in case of clients and IBGP peers outside the cluster.

Vikram

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 11:48 PM
To: 'Venu Kumar G - CTD, Chennai.'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Venu,

"This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster."

RR1 should always send its cluster_id when advertising routes to the members
of its cluster, even if its an imported route. Since RR1 is advertising the
route to all the clients in the cluster, why should RR2 also do the same
thing? Am I missing something.

-Vijay

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:59 PM
To: Krishnan, Vijay G.; 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Here are the answers to your question based on my understanding of the RFC.
Hope someone in the mailing list would correct me if I am wrong.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

Vijay> Both the RRs should be talking (BGP peering) to all the clients. In
your diagram, if RR1 goes down, there is no peering between RR2 (redundant
RR) and RRC1.

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.
Yes I to accetpt, But their is exceptional case where RR needs to reflect
the routes,
when it receives a route from other RR's of same cluster without cluster_id
attribute.
This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster.

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

Vijay> Yes. 

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Vijay> RR2 should not reflect it. It knows that it is a reflected route from
the CLUSTER_ID.

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 3:41 AM
To: [email-masked]'
Subject: FW: BGP Route Reflection Question

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

From: "Ambar Paul" <[email-masked]>
To: <[email-masked]>
Subject: Question on tie-breaking
Date: Fri, 26 Apr 2002 14:34:29 +0530
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-9c02c613-58f7-11d6-a942-00b0d0d06be8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,
 I have question reg. Use of NO_EXPORT community in case of DP
tie-breaking. Suppose a router 'A' is connected to 'B','C', & 'D'. Both
B & C send same route for a destination to A. B sends with NO_EXPORT
community . Suppose after tie-breaking route send by B is better than
that of C. In that case which one A should forward to D and which route
should be there in A's KRT? Regds, 
Ambar

------=_NextPartTM-000-9c02c613-58f7-11d6-a942-00b0d0d06be8
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.

 ********************************************************************

------=_NextPartTM-000-9c02c613-58f7-11d6-a942-00b0d0d06be8--

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: "Krishnan, Vijay G." <[email-masked]>, "Venu Kumar G - CTD, Chennai." <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Subject: RE: BGP Route Reflection Question
Date: Fri, 26 Apr 2002 13:59:31 +0530
Sender: [email-masked]

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 11:48 PM
To: 'Venu Kumar G - CTD, Chennai.'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Venu,

"This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster."

Vijay>RR1 should always send its cluster_id when advertising routes to the
members
Vijay>of its cluster, even if its an imported route. Since RR1 is
advertising the
Vijay>route to all the clients in the cluster, why should RR2 also do the
same
Vijay> thing? Am I missing something.

Venu>  All ther router in AS should be consistent while advertising routes
to external ASs and at the same time knowing all routes of other routers in
the same AS.

      If you take the above example, When RR1 advertising it's imported
route to RR2 (which is  client of RR1), Anyway you will be adding  the
ORIGINATOR_ID attribute and second thing comes CLUSTER_ID attribute adding.

       Assume the case, if your adding  your own CLUSTER_ID,then how does
the RR2 knows about RR1's imported route. He silently discards RR1 imported
routes becz he finds his own CLUSTER_ID in the path attributes. So that's
reason  I feel you should not add the CLUSTER_ID attribute to path
attributes when RR1 importing routes advertising to all other clients
(including the Redundant RR's).

     RFC 2796 also very clear on this point, you should add the cluster_Id
only when your are reflecting the route to others received from  someone
else.
"When a RR reflects a route, it must prepend the local CLUSTER_ID to
the CLUSTER_LIST."
     	However,when a route is advertising to non-clients by RR it should
treat that route as reflecting route and should  add the CLUSTER_ID even if
the route is originated or imported by the own RR.

Regards
Venu G.

        

-Vijay

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:59 PM
To: Krishnan, Vijay G.; 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Here are the answers to your question based on my understanding of the RFC.
Hope someone in the mailing list would correct me if I am wrong.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

Vijay> Both the RRs should be talking (BGP peering) to all the clients. In
your diagram, if RR1 goes down, there is no peering between RR2 (redundant
RR) and RRC1.

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.
Yes I to accetpt, But their is exceptional case where RR needs to reflect
the routes,
when it receives a route from other RR's of same cluster without cluster_id
attribute.
This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster.

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

Vijay> Yes. 

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Vijay> RR2 should not reflect it. It knows that it is a reflected route from
the CLUSTER_ID.

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 3:41 AM
To: [email-masked]'
Subject: FW: BGP Route Reflection Question

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

Date: Thu, 25 Apr 2002 21:16:43 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: LC comments on draft-ietf-idr-bgp-ext-communities-03.txt
Sender: [email-masked]

Srihari, Dan, Yakov:

 Please find some comment on the draft below.

 A meta comment:

  please check all occurrences of must/should/may, make
  sure they are capitalized where used to express requirement
  levels, and include a reference to 2119.

 Other comments inline:
  
>                draft-ietf-idr-bgp-ext-communities-03.txt
...
>
> 2. Abstract
> 
>    This document describes an extension to BGP [BGP-4] which may be used
>    to provide flexible control over the distribution of routing
>    information.
> 

The rfc-ed will not like the citation in the abstract.

> 3. Introduction
> 
>    The Extended Community Attribute provides two important enhancements
>    over the existing BGP Community Attribute:
> 
>       - It provides an extended range, ensuring that communities can be
>         assigned for a plethora of uses, without fear of overlap.
> 
>       - The addition of a Type field provides structure for the
>         community space.
> 
>    The addition of structure allows the usage of policy based on the
>    application for which the community value will be used. For example,
>    one can filter out all communities of a particular type, or allow
>    only certain values for a particular type of community. It also
>    allows one to specify whether a particular community is transitive or
>    non-transitive across Autonomous system boundary. Without structure,
>    this can only be accomplished by explicitly enumerating all community
>    values which will be denied or allowed and passed to BGP speakers in
>    neighboring ASes based on the transitive property.
> 
> 
> 4. BGP Extended Communities Attribute
> 
>    The Extended Communities Attribute is a transitive optional BGP
>    attribute.  The attribute consists of a set of "extended
>    communities".  Each extended community is coded as an eight octet
>    value.  All routes with  the Extended Communities attribute belong to
>    the communities listed in the attribute.
> 
>    The Extended Communities Attribute has Type Code 16.
> 
>    Each Extended Community is encoded as an eight octet quantity, as
>    follows:

It might be helpful to include a format illustration here,
something like this maybe:

     The value of the Extended Communities Attribute is a series
     of eight octet Type and Value field groups, each encoding a specific
     Extended Community as shown below:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type high    |  Type low(*)  |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type high    |  Type low(*)  |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       *) Present for Extended types only, used for the Value field
          otherwise

>       - Type Field  : 1 or 2 octets
>       - Value Field : Remaining octets
> 
>       Type Field:
> 
>          Two classes of Type Field are introduced: Regular type and
>          Extended type.
> 
>          The size of Type Field for Regular types is 1 octet and the
>          size of the Type Field for Extended types is 2 octets.
> 
>          The value of the high-order octet will determine if its a
>          regular type or an extended type. The value of the high-order
> 
> 
> 
> Sangli, Tappan, Rekhter                                         [Page 2]
> 
> 
> 
> 
> 
> Internet Draft  draft-ietf-idr-bgp-ext-communities-03.txt     March 2002
> 
> 
>          octet of the Type Field defined as regular type (or extended
>          type) for a extended community MUST NOT be reused as the value
>          of the high-order octet of the Type Field defined as extended
>          type (or regular type). In other words, a new extended
>          community of regular type (extended type) should have unique
>          (and new) value for the high-order octet (high-order and low-
>          order octet).
> 
>          The high-order octet of the Type Field is as shown below:
> 
>             First bit (MSB)   : IANA authority bit
>                                 Value 0 : IANA assignable type
>                                 Value 1 : Vendor-specific types
> 
>             Second bit        : Transitive bit
>                                 Value 0 : The community is
>                                           Transitive across ASes
>                                 Value 1 : The community is
>                                           Non-Transitive across ASes
> 
>             Remaining 6 bits  : Indicates the structure of the
>                                 community

An IETF-style format for the field would be appreciated :)

Maybe a couple of words saying that the IANA bit does not
require special processing would be good.

>       Value Field:
> 
>          The encoding of the Value Field is dependent on the "type" of
>          the community as specified by the Type Field. The encoding of
>          the community for the transitive communities should be such
>          that it is unique globally (i.e.  across the Autonomous
>          Systems).

It is not clear what kind of implications the last sentence imposes
on the implementations from the _encoding_ perspective...

>       Two extended communities are declared equal only when entire 8
>       octets are equal.
>
>       The two members in the tuple <Type, Value> should be enumerated to
>       specify any community value. Based on the value of the Type field,
>       the remaining octets of the community should be interpreted.
>
> 5. New BGP Extended Community Types.
> 
>    This document introduces a few extended types and defines the Value
                                                              ^
                                                       "the format of"
>    Field for those types.

Probably some wording should be added here to say that the communities
below provide semantical "templates" that are used later for different
functions; each template type is identified by the high order byte
of the Ext Comm Type field, and the low order byte (sub-type) is used
to specify the function... or something along these lines

>       Type 0x00:

I think the type should have a meaningful name at
least to use it in the IANA registry.
Something like "Two-octet AS specific extended community"

>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x00. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value Field consists of two sub-fields:

Something like this would be great:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type High=0x00 |   Sub-Type    |    Global Administrator       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Local Administrator                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>
>             Global Administrator sub-field: 2 octets
> 
>                This sub-field contains an Autonomous System number
>                assigned by IANA.
> 
>             Local Administrator sub-field: 4 octets
> 
>                The organization identified by Autonomous System number
>                in the Global Administrator sub-field, can encode any

"the organization ... can encode". A little weird...

>                information in this sub-field.  The value and meaning of
>                the value encoded in this sub-field should be defined by
>                the sub-type of the community.

"The value... be defined by the sub-type"
probably the format is meant...

>       Type 0x01:

Same comment about name. Something like "IPv4 address specific
extended community"

> 
>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x01. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value field consists of two sub-fields.

ditto format

> 
>             Global Administrator sub-field: 4 octets
> 
>                This sub-field contains an IPv4 address assigned by IANA.
> 
>             Local Administrator sub-field: 2 octets
> 
>                The organization which has been assigned the IPv4 address
>                in the Global Administrator sub-field, can encode any

same comment

>
>                information in this sub-field.  The value and meaning of
>                this value encoded in this sub-field should be defined by
>                the sub-type of the community.

same comment about the value/format

>       Type 0x02:

Name as well: like "Four-octet AS specific..."?

> 
>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x02. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value Field consists of two sub-fields.

ditto format

>             Global Administrator sub-field: 4 octets
> 
>                This sub-field contains a 4-octets Autonomous System
>                number assigned by IANA.
> 
>             Local Administrator sub-field: 2 octets
> 
>                The organization identified by Autonomous System number
>                in the Global Administrator sub-field, can encode any
>                information in this sub-field.  The value and meaning of
>                the value encoded in this sub-field should be defined by
>                the sub-type of the community.

ditto comments above

>       Type 0x03:

Same comment about name here, "Opaque" ?

> 
>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x03. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value Field contains a 6 byte value of structure with sub-
>          fields.

What kind of sub-fields? Do we need this sentence here?

>          This is a generic community of extended type. The value of the
>          sub-type which should define the Value Field is to be assigned
>          by IANA.
>
...
> 
> 8. Link Bandwidth Community
> 
>    When a router receives a route from a directly connected external
>    neighbor (the external neighbor that is one IP hop away), and
>    advertises this route (via IBGP) to internal neighbors, as part of
>    this advertisement the router may carry the bandwidth of the link
>    that connects the router with the external neighbor. The bandwidth of
>    such a link is carried in the Link Bandwidth Community. The community
>    MAY be marked as non-transitive across the Autonomous system
>    boundary.
> 
>    If the community is marked as non-transitive, then the value of the
>    high-order octet of the extended Type Field is 0x40, otherwise it is
>    0x00.  The value of the low-order octet of the extended type field
>    for this community is 0x04.
> 
> 
> 
> 
> Sangli, Tappan, Rekhter                                         [Page 6]
> 
> 
> 
> 
> 
> Internet Draft  draft-ietf-idr-bgp-ext-communities-03.txt     March 2002
> 
> 
>    The value of the Global Administrator sub-field in the Value Field
>    MUST represent the Autonomous System of the router that attaches the
>    Link Bandwidth Community. When a router receives a route with the
>    community, the router may check the AS number in the Global
>    Administrator sub-field to see if its not the local AS and hence
>    ignore the information carried in the Link Bandwidth Community.
> 
>    The bandwidth of the link is expressed as 4 octets in IEEE floating
>    point format, units being bytes per second. It is carried in the
>    Local Administrator sub-field of the Value Field.

Is this supposed to be used in the path selection algo to choose
the best exit? If so, how do we make sure that routers that support
this and those that don't, do not make inconsistent decisions and
thus do not form permanent loops?

> 9. Operations
> 
>    A BGP speaker may use the Extended Communities attribute to control
>    which routing information it accepts, prefers or distributes to its
>    peers.

Do we need some words about consistent acceptance policy among
BGP speakers within the same AS?

>    A BGP speaker receiving a route that doesn't have the Extended
>    Communities attribute may append this attribute to the route when
>    propagating it to its peers.
> 
>    A BGP speaker receiving a route with the Extended Communities
>    attribute may modify this attribute according to the local policy.
> 
>    A BGP speaker should not propagate a non-transitive extended
>    community across the Autonomous system boundary.

What about the situation where a locally originated non-transitive
community is sent over an eBGP session?

>    A route may carry both the BGP Communities attribute  as defined in
>    [RFC1997]), and the Extended BGP Communities attribute. In this case
>    the BGP Communities attribute is handled as specified in [RFC1997],
>    and the Extended BGP Communities attribute is handled as specified in
>    this document.
> 
> 
> 10. IANA Considerations
> 
>    For the high-order octet of the Type Field, values 0x00 through 0x03
>    are assigned in this document and are defined as extended types. For
>    the combination of the high-order and low-order octets of the Type
>    Field values 0x0002-0x0004, 0x0102-0x0103, and 0x0202-0x0203 are
>    assigned in this document.
> 
>    The Type Field values 0x04-0x3f for regular types (0x0400-0x3fff when
>    expressed as extended types) are to be assigned by IANA, using the
>    "First Come First Served" policy defined in RFC 2434. The extended
>    type field values 0x0000-0x0001, 0x0005-0x00ff, 0x0100-0x0101,
>    0x0104-0x01ff, 0x0200-0x0201, 0x0204-0x02ff and 0x0300-0x03ff are to
> 
> 
> 
> Sangli, Tappan, Rekhter                                         [Page 7]
> 
> 
> 
> 
> 
> Internet Draft  draft-ietf-idr-bgp-ext-communities-03.txt     March 2002
> 
> 
>    be assigned by IANA, using the "First Come First Served" policy
>    defined in RFC 2434. Type values 0x80-0xbf for regular types
>    (0x8000-0xbfff when expressed as extended types) are vendor-specific
>    types, and values in this range are not to be assigned by IANA.

Couple of thoughts here...

It might be a good idea to reserve something for the IETF consensus
allocation to be on the safe side.

Also, the text above might not be transparent enough for IANA to
manage efficiently.

Maybe one could say that IANA is supposed to maintain one registry
for the high-order octet of the Type field, associate a
regular/extended attribute with each value, exclude the Transitive
bit from allocation, and make the following allocations according
to this document:

         Type     Reg/Ext   Description
     ----------------------------------------
            0x00    Ext     Name-for-type-00
            0x01    Ext     Name-for-type-01
            0x02    Ext     Name-for-type-02
            0x03    Ext     Name-for-type-03
       0x04-0x3F     -      unassigned
       0x80-0xBF     -      vendor specific

Then also say that for each extended type, a registry of sub-types
is maintained and give the initial assignment like this:
       
  Sub-types for type 0x00:

      Sub-type    Description
     --------------------------------------
      0x00-0x01   unassigned
           0x02   Route target community
           0x03   Route origin community
           0x04   Link bandwidth community
      0x05-0xFF   unassigned

Cheers,
Alex

From: "Krishnan, Vijay G." <[email-masked]>
To: "'Venu Kumar G - CTD, Chennai.'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: BGP Route Reflection Question
Date: Thu, 25 Apr 2002 14:17:48 -0400
Sender: [email-masked]

Venu,

"This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster."

RR1 should always send its cluster_id when advertising routes to the members
of its cluster, even if its an imported route. Since RR1 is advertising the
route to all the clients in the cluster, why should RR2 also do the same
thing? Am I missing something.

-Vijay

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:59 PM
To: Krishnan, Vijay G.; 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Here are the answers to your question based on my understanding of the RFC.
Hope someone in the mailing list would correct me if I am wrong.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

Vijay> Both the RRs should be talking (BGP peering) to all the clients. In
your diagram, if RR1 goes down, there is no peering between RR2 (redundant
RR) and RRC1.

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.
Yes I to accetpt, But their is exceptional case where RR needs to reflect
the routes,
when it receives a route from other RR's of same cluster without cluster_id
attribute.
This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster.

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

Vijay> Yes. 

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Vijay> RR2 should not reflect it. It knows that it is a reflected route from
the CLUSTER_ID.

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 3:41 AM
To: [email-masked]'
Subject: FW: BGP Route Reflection Question

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: "Krishnan, Vijay G." <[email-masked]>, "'Reddy, Vikram'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: BGP Route Reflection Question
Date: Thu, 25 Apr 2002 22:29:00 +0530
Sender: [email-masked]

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Here are the answers to your question based on my understanding of the RFC.
Hope someone in the mailing list would correct me if I am wrong.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

Vijay> Both the RRs should be talking (BGP peering) to all the clients. In
your diagram, if RR1 goes down, there is no peering between RR2 (redundant
RR) and RRC1.

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.
Yes I to accetpt, But their is exceptional case where RR needs to reflect
the routes,
when it receives a route from other RR's of same cluster without cluster_id
attribute.
This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster.

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

Vijay> Yes. 

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Vijay> RR2 should not reflect it. It knows that it is a reflected route from
the CLUSTER_ID.

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 3:41 AM
To: [email-masked]'
Subject: FW: BGP Route Reflection Question

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

From: "Krishnan, Vijay G." <[email-masked]>
To: "'Reddy, Vikram'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: BGP Route Reflection Question
Date: Thu, 25 Apr 2002 12:40:12 -0400
Sender: [email-masked]

Vikram,

Here are the answers to your question based on my understanding of the RFC.
Hope someone in the mailing list would correct me if I am wrong.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

Vijay> Both the RRs should be talking (BGP peering) to all the clients. In
your diagram, if RR1 goes down, there is no peering between RR2 (redundant
RR) and RRC1.

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

Vijay> Yes. 

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Vijay> RR2 should not reflect it. It knows that it is a reflected route from
the CLUSTER_ID.

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 3:41 AM
To: [email-masked]'
Subject: FW: BGP Route Reflection Question

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

From: "Reddy, Vikram" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: BGP Route Reflection Question
Date: Thu, 25 Apr 2002 03:41:24 -0400
Sender: [email-masked]

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

From: "Reddy, Vikram" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: BGP Route Reflection Question
Date: Thu, 25 Apr 2002 03:31:04 -0400
Sender: [email-masked]

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                            ------
	          | RR1 |-------------------------| RR2|
                       -------                            ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------         ---------                   ------
	          | RRC1 |      | RRC2|                  | RR2|
                       ---------        -----------
------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

Reply-To: <[email-masked]>
From: "Sridharj" <[email-masked]>
To: "bgp_Idr_Mailinglist (E-mail)" <[email-masked]>
Subject: ipv6 routing updates 
Date: Wed, 24 Apr 2002 10:07:39 +0530
Importance: Normal
Sender: [email-masked]

Hi ,
                                                                  ipv4 link
      ipv6 network ----- bgp
peaker  --------------------------------------- bgp neighbor ------   ipv4
network

Actually this is a trivial question but still I wanted to make sure  .
In the above scenario  even though the connection to neighbor is over ipv4
link  ,
1 ) Is it common that ipv6 routes are advertised to neighbor
2 ) Can the nexthop be a ipv6 prefix  whereas  NLRI contains  ipv4 prefixes
3)  Is it possible to have ipv4 prefixes and ipv6 prefixes in  then same
updates as part of NLRI .

thanks in advance

sridhara .J

senior software engineer
Future Software

www.futsoft.com

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

To: [email-masked]
Cc: Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>
Subject: draft-ietf-idr-rfc2842bis-01.txt
Date: Tue, 23 Apr 2002 09:03:07 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

draft-ietf-idr-rfc2842bis-01.txt reflects the comments
we received from the IESG.

Yakov.

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: [email-masked]
Subject: Graceful restart timer range
Date: Tue, 23 Apr 2002 10:21:00 +0530
Sender: [email-masked]

HI folks!

    Most of the deployed routers will take more than 3  minutes to restart,
Generaly we may configure Hold time at maximum of 3 minuutes(RFC sujjests 90
seconds only). So I hope Mostly Restart time will/may be greater than  Hold
time value.

    "In general the Restart Time SHOULD NOT be greater than the HOLDTIME
   carried in the OPEN " 
   
   How about changing the above statment to  like this..?  
    
   "In general the Restart Time MAY be greater than the HOLDTIME
   carried in the OPEN, but however it is sujjested to be lesser than 
   HOLDTIME carried in the OPEN " 

Regards
Venu G.

****************************************************
Meet us at Networld+Interop, Las Vegas, 7-9-May-2002
Booth# 3327, Embedded Networking Technologies Area
HCL Tech in Designers' Roundtable
<http://education.key3media.com:8080/interop/lv2002/education/FMPro?-DB=K3Se
ssions.fp5&-lay=webform&-format=session_detail.html&Session_ID=2678&-Find>
Tuesday, May 7, 2002, 10: 30 am - 11:30 am
Location: Pavilion 10 
www.hcltech.com <http://www.hcltech.com>
**********************************************
Disclaimer:
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: BGP-4 MIBv2 NLRI Table
Date: Mon, 22 Apr 2002 13:29:10 -0400
Importance: Normal
Sender: [email-masked]

Hi Folks,
I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the 
following index clause:

      INDEX {
            bgpM2PeerIndex,
            bgpM2NlriAfi,
            bgpM2NlriSafi,
            bgpM2NlriPrefixLen,
            bgpM2NlriPrefix,
            bgpM2NlriIndex
            }

Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix 
objects are the opposite order to what one might normally expect? 
For example, in the BGP-4 Received Path Attribute Table of 
RFC1657 the index clause is:

      INDEX { 	
            bgp4PathAttrIpAddrPrefix,
            bgp4PathAttrIpAddrPrefixLen,
            bgp4PathAttrPeer            
            }
                    
Thanks,
Ken Benstead

Date: Fri, 19 Apr 2002 11:32:31 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Re: exponentila backoff in idle state???
Cc: BGP mailing list <[email-masked]>, Gilles Geerts <[email-masked]>, Wim henderickx <[email-masked]>, Peter Reynders <[email-masked]>, [email-masked]
Sender: [email-masked]

Hans:

I am submitting an Internet draft on backoff based on the
bgp-4 state machine draft.  These drafts are being reviewed
by implementors to see if they match existing implementations.

Would you open to reviewing this draft as well
as the state machine draft I sent.   Please let me know
and I'll send the text.

By the end of the month, these documents will go to the working group.
So... get your comments in now.

Sue Hares

At 04:46 PM 4/19/2002 +0200, [email-masked] wrote:
>Hi,
>
>I have a question related to exponential backoff algorithm that is
>described in the BGP state machine for the state idle (RFC 1771, section
>8)
>
>According to the RFC, the system should use an exponentially growing
>timer (first 60s, then 120 sec,...) each time its decides for its own to
>leave the state idle.
>
>I have tried to invoke this situation by connecting routers (various
>types) to a test device. Using the test device I generate a TCP RST
>(i.e. forced clear of the TCP connection) to abnormally close the TCP
>connection.
>
>I noticed that the routers I have tested do not use the exponential
>backoff for this case.
>
>So my question would be:
>- is this part of the RFC still being used?
>- is this part of the RF  not applicable for the TCP  RST case.
>
>Any help is appreciated.
>
>
>Hans.

Date: Fri, 19 Apr 2002 11:17:05 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Last call on Graceful Restart
Cc: [email-masked]
Sender: [email-masked]

This message will start Working Group Last call on:

   Graceful Restart Mechanism for BGP
   draft-ietf-idr-restart-03.txt

   authors: Srihari R. Sangli (Procket Networks)
            Yakov Rekhter (Juniper Networks)
            Rex Fernando (Procket Networks)
            John G. Scudder (Cisco Systems)
            Enke Chen (Redback Networks

The Last call will end on 5/3/02.

Sue Hares

Date: Fri, 19 Apr 2002 10:52:00 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Last call on Extended Communities 
Cc: yakov Rekhter <[email-masked]>
Sender: [email-masked]

This note is to start Working Group last call on:

   BGP Extended Communities Attribute

  draft-ietf-idr-bgp-ext-communities-03.txt

This last call will go for 2 weeks, and will terminate
on 5/3.

Sue Hares

Date: Fri, 19 Apr 2002 16:46:09 +0200
From: [email-masked]
To: BGP mailing list <[email-masked]>
Cc: Gilles Geerts <[email-masked]>, Wim henderickx <[email-masked]>, Peter Reynders <[email-masked]>, [email-masked]
Subject: exponentila backoff in idle state???
Sender: [email-masked]

Hi,

I have a question related to exponential backoff algorithm that is
described in the BGP state machine for the state idle (RFC 1771, section
8)

According to the RFC, the system should use an exponentially growing
timer (first 60s, then 120 sec,...) each time its decides for its own to
leave the state idle.

I have tried to invoke this situation by connecting routers (various
types) to a test device. Using the test device I generate a TCP RST
(i.e. forced clear of the TCP connection) to abnormally close the TCP
connection.

I noticed that the routers I have tested do not use the exponential
backoff for this case.

So my question would be:
- is this part of the RFC still being used?
- is this part of the RF  not applicable for the TCP  RST case.

Any help is appreciated.

Hans.

Date: Thu, 18 Apr 2002 22:24:27 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-17 Draft Comments...
Sender: [email-masked]

> As with software, it is quite possible to, when attempting to
> modify a specification to correct some perceived problem, to
> introduce new ones. So, i think we should be quite
> conservative when changing the spec... sometimes inocent
> changes introduce backwards compatibility problems that end
> up being quite problematic in the field... and once the spec
> is modified one is kind of in a jam between what the spec
> says and interoperability.

Agreed.... Responses within.... :-)

> > 4.3
> 
> > The UPDATE message always includes the fixed-size BGP header, and
> > also includes the other fields as shown below (note, some of the
> > shown fields may not be present in every UPDATE message):
> 
> > I assume that the fixed length fields must always be included, or
> > there is not way to parse the update format. In light of this, it
> > might be better to change this to state: "....(note, some of the
> > shown variable length fields may not be present....)"
> 
> I think the original text is just fine...

But, just adding the words "variable length" makes it clearer
what fields we are talking about not being in the update. Reading
through the entire draft, you would know that, but it's easier to
read if it's clear here.

> > version number each supports. If an open attempt fails with an Error
> > Code OPEN Message Error, and an Error Subcode Unsupported Version
> > Number, then the BGP speaker has available the version number it
> > tried, the version number its peer tried, the version number passed
> > by its peer in the NOTIFICATION message, and the version numbers
> > that it supports.
> 
> > This sentence doesn't seem to make any sense.
> 
> Makes perfect sense to me... tells one to keep around the versions
> that where exchanged for diagnostics purposes...
> 
> > Maybe:
> 
> > If an open attempt fails bceause of a version number mismatch, then
> > the local BGP speaker should receive an Error Code OPEN Message
> > Error with an Error Subcode Unsupported Version Number. On receiving
> > this notification, the local BGP speaker should have available the
> > version number it tried, the version number its peer tried, and the
> > version numbers it supports.
> 
> Version negotiation is not being used at the moment... as far
> as i know nobody uses version < 4 anymore... so why change
> the document ?

Well, we might change versions in the future, so it would be nice
if this text were clear to someone just implementing. 

> >    To minimize the likelihood that the distribution of BGP messages
> > by a given BGP speaker will contain peaks, jitter should be applied
> > to the timers associated with MinASOriginationInterval, Keepalive,
> > and MinRouteAdvertisementInterval.
> 
> > Hmmm.... Maybe:
> 
> > "To minimize the likelihood that the distribution of BGP messages by
> > a given BGP speaker will cluster around a particular time, causing a
> > short term spike in traffic which could overwhelm the network or the
> > peer, ...."
> 
> I don't see a reason to make this change... the "peaks"
> argument above is good enought imho.

But what do you mean by "peaks?" That's just the word I was
trying to kill off, so as to provide a "more complete" or "more
correct" explanation.

:-)

Russ

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

Date: Thu, 18 Apr 2002 18:45:26 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: BGP-17 Draft Comments...
Sender: [email-masked]

Russ White writes:

> Alvaro and I spent some time going over draft 17, and came up with
> just a few comments, below. Some of them may overlap to some degree.

Russ,
Some comments on your comments bellow... and generic meta-comment not
directed at you in particular...

As with software, it is quite possible to, when attempting to modify a
specification to correct some perceived problem, to introduce new
ones. So, i think we should be quite conservative when changing the
spec... sometimes inocent changes introduce backwards compatibility
problems that end up being quite problematic in the field... and once
the spec is modified one is kind of in a jam between what the spec
says and interoperability.

> -----

> 4.3 UPDATE Message Format ...

> This section defines the encoding for announcing and withdrawing
> paths...saying things like:

>       Total Path Attribute Length:

>          This 2-octet unsigned integer indicates the total length of
> the Path Attributes field in octets. Its value must allow the length
> of the Network Layer Reachability field to be determined as
> specified below.

>          A value of 0 indicates that no Network Layer Reachability
> Information field is present in this UPDATE message.

> But rfc2858 (Multiprotocol Extensions for BGP-4) reads:

>    An UPDATE message that carries no NLRI, other than the one
> encoded in the MP_REACH_NLRI attribute, should not carry the
> NEXT_HOP attribute.  If such a message contains the NEXT_HOP
> attribute, the BGP speaker that receives the message should ignore
> this attribute.

> How can the Total Path Attribute Length be = 0 (to indicate no
> NLRI), but still carry other attributes?!?!

There is no incompatibility between the 2 statements...

An update containing only withrawls will have a 0 attribute
length... this message won't include MP_ attributes...

An update may include MP_{UN,}REACH attributes and no non-mp NLRI...

> Suggested new text - eliminate the second paragraph:

> ================ Total Path Attribute Length:

> This 2-octet unsigned integer indicates the total length of the Path
> Attributes field in octets. Its value must allow the length of the
> Network Layer Reachability field to be determined as specified
> below.  ================

This is incorrect imho... one can have attributes and no NLRI...

I don't think there is any reason to do any changes here...

>       Marker:

>          This 16-octet field contains a value that the receiver of
> the message can predict. If the Type of the message is OPEN, or if
> the OPEN message carries no Authentication Information (as an
> Optional Parameter), then the Marker must be all ones.  Otherwise,
> the value of the marker can be predicted by some a computation
> specified as part of the authentication mechanism (which is
> specified as part of the Authentication Information) used. The
> Marker can be used to detect loss of synchronization between a pair
> of BGP peers, and to authenticate incoming BGP messages.

> I would rewrite it to say:

> This 16-octet field contains a value that the receiver of the
> message can predict.  If the Type of the message is OPEN, or if no
> authentication mechanism (which is specified as part of the
> Authentication Information Optional Parameter in the OPEN message)
> is used, then the Marker must be all ones.  Otherwise, the value of
> the marker can be predicted by a computation specified as part of
> the authentication mechanism in use.  The Marker can be used to
> detect loss of synchronization between a pair of BGP peers, and to
> authenticate incoming BGP messages.

I prefer the original text as it makes it clear that if you do not use
authentication then the marker is all ones... since to my knowledge
the bgp authentication field is not used, the first phrase in the
original text makes it quite clear what to do.

> ----

> 4.3

> The UPDATE message always includes the fixed-size BGP header, and
> also includes the other fields as shown below (note, some of the
> shown fields may not be present in every UPDATE message):

> I assume that the fixed length fields must always be included, or
> there is not way to parse the update format. In light of this, it
> might be better to change this to state: "....(note, some of the
> shown variable length fields may not be present....)"

I think the original text is just fine...

> ----

> 7.

> version number each supports. If an open attempt fails with an Error
> Code OPEN Message Error, and an Error Subcode Unsupported Version
> Number, then the BGP speaker has available the version number it
> tried, the version number its peer tried, the version number passed
> by its peer in the NOTIFICATION message, and the version numbers
> that it supports.

> This sentence doesn't seem to make any sense.

Makes perfect sense to me... tells one to keep around the versions
that where exchanged for diagnostics purposes...

> Maybe:

> If an open attempt fails bceause of a version number mismatch, then
> the local BGP speaker should receive an Error Code OPEN Message
> Error with an Error Subcode Unsupported Version Number. On receiving
> this notification, the local BGP speaker should have available the
> version number it tried, the version number its peer tried, and the
> version numbers it supports.

Version negotiation is not being used at the moment... as far as i
know nobody uses version < 4 anymore... so why change the document ?

> 9.2.1.1

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

> Didn't we determine (on list) that this was true of unfeasible
> destinations as well?

I think that the only consensus on this issue is that there is no
consensus... this is one of those areas where each vendor just has to
apply it's own judgement, imho.

AFAIK no vendor follows the above recomendation anyway... with
different equipment exibiting different behaviours without causing
interoperability issues.

> ----

> 9.2.1.3 Jitter

>    To minimize the likelihood that the distribution of BGP messages
> by a given BGP speaker will contain peaks, jitter should be applied
> to the timers associated with MinASOriginationInterval, Keepalive,
> and MinRouteAdvertisementInterval.

> Hmmm.... Maybe:

> "To minimize the likelihood that the distribution of BGP messages by
> a given BGP speaker will cluster around a particular time, causing a
> short term spike in traffic which could overwhelm the network or the
> peer, ...."

I don't see a reason to make this change... the "peaks" argument above
is good enought imho.

  Pedro.

Date: Thu, 18 Apr 2002 21:12:43 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: [email-masked]
Subject: BGP-17 Draft Comments...
Sender: [email-masked]

Alvaro and I spent some time going over draft 17, and came up
with just a few comments, below. Some of them may overlap to some
degree.

:-)

Russ

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

-----

4.3 UPDATE Message Format
...

This section defines the encoding for announcing and withdrawing
paths...saying things like:

      Total Path Attribute Length:

         This 2-octet unsigned integer indicates the total length of the
         Path Attributes field in octets. Its value must allow the
         length of the Network Layer Reachability field to be determined
         as specified below.

         A value of 0 indicates that no Network Layer Reachability
         Information field is present in this UPDATE message.

But rfc2858 (Multiprotocol Extensions for BGP-4) reads:

   An UPDATE message that carries no NLRI, other than the one encoded in
   the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
   If such a message contains the NEXT_HOP attribute, the BGP speaker
   that receives the message should ignore this attribute.

How can the Total Path Attribute Length be = 0 (to indicate no NLRI), but
still carry other attributes?!?!

Suggested new text - eliminate the second paragraph:

================
Total Path Attribute Length:

This 2-octet unsigned integer indicates the total length of the Path
Attributes field in octets. Its value must allow the length of the Network
Layer Reachability field to be determined as specified below.
================

A reference should be made to rfc2858 for "alternate
advertisement/withdraw mechanisms".

>From [email-masked] Thu Apr 18 20:57:52 2002
Date: Fri, 29 Mar 2002 09:44:32 -0500 (EST)
From: Alvaro Retana <[email-masked]>
To: [email-masked]
Subject: Optional Parameters

         This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):

(1) Only one parameter is defined...

(2) If we want to reflect current implementations/deployment, shouldn't we
at least make reference to the other parameters??  Even if all the text is
not included, just a reference should be made...

----

      BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer.

But draft-ietf-idr-bgp-identifier-00.txt, which proposes an alternate
definition, is a WG document.  IMHO, we should incorporate the text from
draft-ietf-idr-bgp-identifier-00.txt in the spec.  In fact,
draft-ietf-idr-bgp-identifier-00.txt reads:

   Therefore it is concluded that the revisions proposed in this
   document do not introduce any backward compatibility issue with the
   current usage of the BGP Identifier.

----

      Hold Time:

         This 2-octet unsigned integer indicates the number of seconds
         that the sender proposes for the value of the Hold Timer. Upon
         receipt of an OPEN message, a BGP speaker MUST calculate the
         value of the Hold Timer by using the smaller of its configured
         Hold Time and the Hold Time received in the OPEN message. The
         Hold Time MUST be either zero or at least three seconds.  An
         implementation may reject connections on the basis of the Hold
         Time.  The calculated value indicates the maximum number of
         seconds that may elapse between the receipt of successive
         KEEPALIVE, and/or UPDATE messages by the sender.

"The Hold Time MUST be either zero or at least three seconds."  The text
doesn't explain (here, it does elsewhere) what happens if the Hold Time is
zero.  It is not straight forward beacuse the definition is "maximum
number of seconds that may elapse between the receipt of successive
KEEPALIVE, and/or UPDATE messages by the sender".

We should add at the end: "If the negotiated Hold time value is zero, then
the session never expires.

----

Appendix 1. Comparison with RFC1771

   There are numerous editorial changes (too many to list here).

   The following list the technical changes:

      Changes to reflect the usages of such features as TCP MD5 [10],
      BGP Route Reflectors [11], BGP Confederations [13], and BGP Route
      Refresh [12].

...but when the message types are defined, Route Refresh is left out:

      Type:

         This 1-octet unsigned integer indicates the type code of the
         message. The following type codes are defined:

                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

For completeness...and to reflect the current state, shouldn't type 5 be
included??  Route refresh is mentioned a couple of times.

----

      Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict. If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used. The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

I would rewrite it to say:

This 16-octet field contains a value that the receiver of the message can
predict.  If the Type of the message is OPEN, or if no authentication
mechanism (which is specified as part of the Authentication Information
Optional Parameter in the OPEN message) is used, then the Marker must be
all ones.  Otherwise, the value of the marker can be predicted by a
computation specified as part of the authentication mechanism in use.
The Marker can be used to detect loss of synchronization between a pair of
BGP peers, and to authenticate incoming BGP messages.

The part thats kindda confusing is which messages should carry all
ones...and then the part that reads:  "...predicted by some a
computation...".

----

4.3

The UPDATE message always includes the fixed-size BGP header, and also
includes the other fields as shown below (note, some of the shown
fields may not be present in every UPDATE message):

I assume that the fixed length fields must always be included, or
there is not way to parse the update format. In light of this, it
might be better to change this to state: "....(note, some of the shown
variable length fields may not be present....)"

----

7.

version number each supports. If an open attempt fails with an Error
Code OPEN Message Error, and an Error Subcode Unsupported Version
Number, then the BGP speaker has available the version number it
tried, the version number its peer tried, the version number passed
by its peer in the NOTIFICATION message, and the version numbers that
it supports.

This sentence doesn't seem to make any sense. Maybe:

If an open attempt fails bceause of a version number mismatch, then
the local BGP speaker should receive an Error Code OPEN Message Error
with an Error Subcode Unsupported Version Number. On receiving this
notification, the local BGP speaker should have available the version
number it tried, the version number its peer tried, and the version
numbers it supports.

page 32

----

9.2.1.1

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

Didn't we determine (on list) that this was true of unfeasible
destinations as well?

----

9.2.1.3 Jitter

   To minimize the likelihood that the distribution of BGP messages by a
   given BGP speaker will contain peaks, jitter should be applied to the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval.

Hmmm.... Maybe:

"To minimize the likelihood that the distribution of BGP messages by a
given BGP speaker will cluster around a particular time, causing a
short term spike in traffic which could overwhelm the network or the
peer, ...."

Date: Thu, 11 Apr 2002 14:47:24 -0400
To: Jeffrey Haas <[email-masked]>
From: Dan Tappan <[email-masked]>
Subject: Re: Additional extended communities clarification
Cc: [email-masked]
Sender: [email-masked]

At 12:16 PM 4/11/2002 -0400, Jeffrey Haas wrote:
>In section 5, "New BGP Extended Community Types" (new? they didn't exist
>before), we get 0x00 - 0x03.  Were these really intended to be restricted
>to transitive?  If not, perhaps labeling them as 0x00 and 0x40, etc.
>may be more appropriate.

I believe that the intent of the transitive bit was that it should be an 
orthogonal property of the community. So, any defined community "type" 
value would have a transitive and a non-transitive variant.

Unfortunately that's made the term "type" ambiguous as to whether it refers 
to the assigned value (with the transitive bit masked off) or the value in 
a packet. The intent of that paragraph was the former.
I think what happened was that all that text equating "type" to octets was 
written before the transitive bit was assigned.

We could either explicitly list transitive and non-transitive versions of 
each value, not only in section 5 but also in all the following sections, 
or we can come up with a different terms for the first 1 or 2 octets vs the 
assigned value. Maybe "Type field" vs "type-code"?

To: [email-masked]
Subject: clarification on multiple instances of capabilities
Date: Thu, 11 Apr 2002 09:38:55 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

In the absence of any objections by 4/17, I'll add the following 
two paragraphs to the draft:

   BGP speakers SHOULD NOT include more than one instance of a
   capability with the same Capability Code, Capability Length,
   and Capability Value.  Note however, that processing of multiple
   instances of such capability does not require special handling,
   as additional instances do not change the meaning of announced
   capability.

   BGP speakers MAY include more than one instance of a capability
   (as identified by the Capability Code) with non-zero Capability
   Length field, but with different Capability Value, and either
   the same or different Capability Length.  Processing of these
   capability instances is specific to the Capability Code and MUST
   be described in the document introducing the new capability.

These two paragraphs will be added to address the comments
brought up by Alex.

Yakov.

Date: Thu, 11 Apr 2002 12:16:03 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Additional extended communities clarification
Sender: [email-masked]

In section 5, "New BGP Extended Community Types" (new? they didn't exist 
before), we get 0x00 - 0x03.  Were these really intended to be restricted
to transitive?  If not, perhaps labeling them as 0x00 and 0x40, etc.
may be more appropriate.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 10 Apr 2002 17:31:42 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Dan Tappan <[email-masked]>, [email-masked]
Subject: Re: extended communities questions and observations
Sender: [email-masked]

On Wed, Apr 10, 2002 at 02:27:14PM -0700, Yakov Rekhter wrote:
> How about replacing in both Section 6 and 7:
> 
>    When the value of the Type field is 0x00 or 0x02, the value of the
>    Local Administrator sub-field in the Value Field MUST be unique
>    within the Autonomous system carried in the Global Administrator sub-
>    field.
> 
> with the following:
> 
>     When the value of the Type field is 0x00 or 0x02, the Local
>     Administrator sub-field contains a number from a numbering
>     space which is administered by the organization to which the
>     ASN carried in the Global Administrator subfield has been
>     assigned by an appropriate authority.
> 
>     When the value of the Type field is 0x01, the Local Administrator
>     sub-field contains a number from a numbering space which is
>     administered by the organization to which the IP address carried
>     in the Global Administrator subfield has been assigned by an
>     appropriate authority.

This would work.

It'd also be just as good to say (excerpted):

The Local
Administrator sub-field contains a number from a numbering
space which is administered by the organization to which the
Global Administrator subfield has been
assigned by an appropriate authority.

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: Dan Tappan <[email-masked]>, [email-masked]
Subject: Re: extended communities questions and observations 
Date: Wed, 10 Apr 2002 14:27:14 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> On Tue, Apr 09, 2002 at 03:50:28PM -0400, Dan Tappan wrote:
> > Are you concerned by the fact that AS 65534 is from the private space?
> 
> No.
> 
> > "in order for the community value to be unique the local administrator 
> > value must be uniquely assigned by the entity or entities allocating values
 
> > with a given global administrator value".
> > 
> > But it is really necessary to spell that out?
> 
> I would say yes, but ONLY if you're keeping the "uniqueness" paragraph
> for Route Origin and Target.  I'd be just as happy to have those
> paragraphs deleted.

How about replacing in both Section 6 and 7:

   When the value of the Type field is 0x00 or 0x02, the value of the
   Local Administrator sub-field in the Value Field MUST be unique
   within the Autonomous system carried in the Global Administrator sub-
   field.

with the following:

    When the value of the Type field is 0x00 or 0x02, the Local
    Administrator sub-field contains a number from a numbering
    space which is administered by the organization to which the
    ASN carried in the Global Administrator subfield has been
    assigned by an appropriate authority.

    When the value of the Type field is 0x01, the Local Administrator
    sub-field contains a number from a numbering space which is
    administered by the organization to which the IP address carried
    in the Global Administrator subfield has been assigned by an
    appropriate authority.

Yakov.

Date: Wed, 10 Apr 2002 12:11:35 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: 2842
Cc: Yakov Rekhter <[email-masked]>, Alex Zinin <[email-masked]>
Sender: [email-masked]

Following up to myself...

Jeff Haas pointed out to me that 2858 takes advantage of this bug in 
2842, so it's too late to stuff the genie back in the bottle.

Under the circumstances, I withdraw my comments.

--John

Date: Wed, 10 Apr 2002 11:45:43 -0400
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: 2842
Cc: [email-masked], Alex Zinin <[email-masked]>
Sender: [email-masked]

I've finally read through this whole thread.  Sorry for chiming in 
late.  Anyway, the original problem cited was:

At 5:03 PM -0800 3/25/02, Yakov Rekhter wrote:
>During the IESG review Alex Zinin brought up an issue that the
>the following text from the current spec is a bit underspecified:
>
>    A particular capability, as identified by its Capability Code, may
>    occur more than once within the Optional Parameter.

Let me start by saying that I cannot now imagine a good reason for 
the spec to say this.  In fact, let me speculate that we are arguing 
about a typo, and that the simplest fix is to add a single word:

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

Done, IMO.

Is there any real, practical reason for any of the "well you mostly 
shouldn't send multiple capabilities but then again you can if you 
really want to" texts that have been circulated?  Seems to be 
excessive specification and complexity for no payback.

Thanks,

--John

Date: Tue, 9 Apr 2002 17:43:51 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: 2842
Sender: [email-masked]

Yakov, Jeff

 [bringing this back to the list]

 For some reason, Jeff's message did not get to me...

 I think Jeff's proposed text actually changes the meaning,
 not just wording. Specifically "Processing of these capability
 instances" sounds like processing of those with the same
 type, length and value, which is not what Yakov's text
 says.
 
Alex

> Date:    Mon, 08 Apr 2002 11:25:15 EDT
> To:      Yakov Rekhter <[email-masked]>
> cc:      Alex Zinin <[email-masked]>, [email-masked]
> Subject: Re: 2842

> Suggested tweaks, largely removing some redundancies between the two
> paragraphs.

> On Sun, Apr 07, 2002 at 02:37:04PM -0700, Yakov Rekhter wrote:
>>    BGP speakers SHOULD NOT include more than one instance of a
>>    capability with the same Capability Code, Capability Length,
>>    and Capability Value.  Note however, that processing of multiple
>>    instances of such capability does not require special handling,
>>    as additional instances do not change the meaning of announced
>>    capability.

>>    BGP speakers MAY include more than one instance of a capability
>>    (as identified by the Capability Code) with non-zero Capability
>>    Length field, but with different Capability Value, and either
>>    the same or different Capability Length.  Processing of these
>>    capability instances is specific to the Capability Code and MUST
>>    be described in the document introducing the new capability.

> BGP speakers SHOULD NOT include more than one instance of a
> capability with the same Capability Code, Capability Length and
> Capability Value.  Additional instances of a capability code do not
> change the meaning of an announced capability.  Processing of these
> capability instances is specific to the Capabilility Code and MUST
> be described in the document introducing the new capability.

>> Yakov.

Date: Tue, 9 Apr 2002 16:57:12 -0400
From: Jeffrey Haas <[email-masked]>
To: Dan Tappan <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: extended communities questions and observations
Sender: [email-masked]

On Tue, Apr 09, 2002 at 03:50:28PM -0400, Dan Tappan wrote:
> Are you concerned by the fact that AS 65534 is from the private space?

No.

> "in order for the community value to be unique the local administrator 
> value must be uniquely assigned by the entity or entities allocating values 
> with a given global administrator value".
> 
> But it is really necessary to spell that out?

I would say yes, but ONLY if you're keeping the "uniqueness" paragraph
for Route Origin and Target.  I'd be just as happy to have those
paragraphs deleted.

BTW:
"Two extended communities are declared equal only when [the] entire
 8 octets are equal"

(note correction).

> I guess I'm not sure what 
> your concern is:
> - multiple assigners using the same GA value?
> - A single assigner failing to keep track of which LA values have been 
> assigned?
> 
> How is this different from any other number assignment problem- e.g. IP 
> addresses?
> 
> 
> 

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 9 Apr 2002 15:26:27 -0400
From: Jeffrey Haas <[email-masked]>
To: Dan Tappan <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: extended communities questions and observations
Sender: [email-masked]

On Tue, Apr 09, 2002 at 03:11:13PM -0400, Dan Tappan wrote:
> uniqueness
> 
> n : the quality of being one of a kind; "that singularity distinguished him 
> from all his companions" [syn: singularity]
> Source: WordNet ® 1.6, © 1997 Princeton University

Given this, consider a route target of type 0x00.  It has the
properties of an AS of 65534 and a Local Administrator value of 0xffffffff.
How is 0xffffffff unique within AS 65534?  

> "ensure that values for these particular extended communities can be 
> assigned in a distributed manner without fear of overlap"

Or perhaps, "The local administrator field must have a well defined
and consistant meaning throughout the domain defined by the global
administrator value"?

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 9 Apr 2002 14:52:37 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: extended communities questions and observations
Sender: [email-masked]

Yakov,

On Tue, Apr 09, 2002 at 11:02:43AM -0700, Yakov Rekhter wrote:
> The 'local administrator' field does not "address" any routers. It simply 
> provides a mechanism for guaranteeing uniqueness of the community. 

Again, what do you mean by "uniqueness"?
I think what you mean is implied by an earlier portion of the document:
"...ensuring that communities can be assigned for a plethora of
 uses, without fear of overlap."

Perhaps an example would clarify things.

[Aggregation]
> It is a matter of policy.

Could you note this in the document?

> > What about confederation boundaries?
> 
> My take on this would be to allow propagation across confed boundaries.

I would too.  Could you add this to the document?

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: extended communities questions and observations 
Date: Tue, 09 Apr 2002 11:02:43 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

Based on the discussion with the rest of the co-authors...

> Extended communities authors:
> 
> In both the route target and route origin communities, you have
> the following paragraph:
> 
> :    When the value of the Type field is 0x00 or 0x02, the value of the
> :    Local Administrator sub-field in the Value Field MUST be unique
> :    within the Autonomous system carried in the Global Administrator sub-
> :    field.
> 
> This probably should read "When the value of the high order octet of
> the Type field..."

Yes, this is correct. We'll fix it.

> In general, what property of uniqueness is meant here?
> 
> Consider the route target community.  The route target community is 
> defined as:
> 
> :    The Route Target Community identifies one or more routers that may
> :    receive a set of routes (that carry this Community) carried by BGP.
> 
> By this definition, one or more routers may be addressed by a given
> route target's local administrator field for a given AS in the global
> administrator field.  What is meant by "unique" in this context?

The 'local administrator' field does not "address" any routers. It simply 
provides a mechanism for guaranteeing uniqueness of the community. 

> The same question applies to the route origin community.

Ditto.

> 
> My archives (although potentially incomplete) show other people asking
> this question as well:  How should extended communities deal with
> aggregation?

It is a matter of policy.

> A good case can probably be made to disallow aggregation of
> routes with dissimilar route target and route origin sets.
> 
> I'm not certain it makes sense to ever include link bandwidth within
> an aggregate.

ditto.

> 
> Under operations:
> :    A BGP speaker should not propagate a non-transitive extended
> :    community across the Autonomous system boundary.
> 
> What about confederation boundaries?

My take on this would be to allow propagation across confed boundaries.

Yakov.

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: In favor of bit for "regular vs extended" type of extended community.
Date: Tue, 09 Apr 2002 11:28:24 -0400
Sender: [email-masked]

Jeffrey> It would greatly simplify things if we used a bit to
Jeffrey> distinguish regular vs. extended types.  This would
Jeffrey> clarify the spec and, I believe, can be made to be
Jeffrey> backwards compatable with the current one.
Jeffrey> [more...]

I am strongly in favor of the change suggested by Jeffrey.
If find the current form of the draft very confusing and
inconsistent and I think it would benefit greatly from
this change (assuming it can be done in a backwards compatible
way). We might want to call it the "value size bit" (to avoid
confusion caused by a term like "extended type extended community").

-- Bruno Rijsman

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

To: Alex Zinin <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: 2842 
Date: Tue, 09 Apr 2002 06:41:44 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Yakov,
> 
>  Provided that the WG agrees that this is the right text,
>  it would address my concerns.

Do you have any objections to the Jeff's modifications of my text ?

Yakov.

> 
> Alex
> 
> Sunday, April 7, 2002, 2:37:04 PM, Yakov Rekhter wrote:
> 
> > Alex,
> 
> >> Makes perfect sense.
> >> 
> >> Alex
> >> 
> >> Wednesday, March 27, 2002, 8:46:49 AM, Jeffrey Haas wrote:
> >> > To be fair, zero-length shouldn't be the bugaboo.  It should be
> >> > multiple capabilities with the same code _and the same data_.
> >> > The zero-length case is just one example of this.
> 
> > With this in mind, how about the following:
> 
> >    BGP speakers SHOULD NOT include more than one instance of a
> >    capability with the same Capability Code, Capability Length,
> >    and Capability Value.  Note however, that processing of multiple
> >    instances of such capability does not require special handling,
> >    as additional instances do not change the meaning of announced
> >    capability.
> 
> >    BGP speakers MAY include more than one instance of a capability
> >    (as identified by the Capability Code) with non-zero Capability
> >    Length field, but with different Capability Value, and either
> >    the same or different Capability Length.  Processing of these
> >    capability instances is specific to the Capability Code and MUST
> >    be described in the document introducing the new capability.
> 
> > Yakov.
> 

Date: Mon, 8 Apr 2002 18:16:45 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: 2842
Sender: [email-masked]

Yakov,

 Provided that the WG agrees that this is the right text,
 it would address my concerns.

Alex

Sunday, April 7, 2002, 2:37:04 PM, Yakov Rekhter wrote:

> Alex,

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

> With this in mind, how about the following:

>    BGP speakers SHOULD NOT include more than one instance of a
>    capability with the same Capability Code, Capability Length,
>    and Capability Value.  Note however, that processing of multiple
>    instances of such capability does not require special handling,
>    as additional instances do not change the meaning of announced
>    capability.

>    BGP speakers MAY include more than one instance of a capability
>    (as identified by the Capability Code) with non-zero Capability
>    Length field, but with different Capability Value, and either
>    the same or different Capability Length.  Processing of these
>    capability instances is specific to the Capability Code and MUST
>    be described in the document introducing the new capability.

> Yakov.

Date: Mon, 8 Apr 2002 19:12:33 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: extended communities - extended vs. regular types
Sender: [email-masked]

I've deliberately separated this from the previous questions
since this is more opinion than "how is this supposed to work?"

In the extended communities documentation, the distinction between
"regular" and "extended" types are confusing, especially when
attempting to avoid collisions in the regular vs extended space
when creating new ones.

It would greatly simplify things if we used a bit to distinguish
regular vs. extended types.  This would clarify the spec and,
I believe, can be made to be backwards compatable with the current one.

Thus:

Third bit: Extended bit:
     Value 0: The community is extended and the value field is of length 6.
     Value 1: The community is regular and the value field is of length 7.

The remaining 5 bits incicate the structure of the community.

In the case of extended types, I'd suggest referring the 5 bits
as "format" bits.  We have already defined 0-3.  This leaves 28
formats that can be assigned.  This would work for IANA and Vendor
assigned.

Continuing the extended type example, this leaves the next octet
of the extended type field to be the extended community type.
Three are currently defined: route target, route origin and
link bandwidth.

This would limit regular types to 32 IANA assigned values.
This may be unacceptable for the authors since there was presumably
a motivation to introduce the regular type.

All in all, this is a plea for some regularity in the packet formatting.

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 8 Apr 2002 18:20:36 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: extended communities questions and observations
Sender: [email-masked]

Extended communities authors:

In both the route target and route origin communities, you have
the following paragraph:

:    When the value of the Type field is 0x00 or 0x02, the value of the
:    Local Administrator sub-field in the Value Field MUST be unique
:    within the Autonomous system carried in the Global Administrator sub-
:    field.

This probably should read "When the value of the high order octet of
the Type field..."

In general, what property of uniqueness is meant here?

Consider the route target community.  The route target community is 
defined as:

:    The Route Target Community identifies one or more routers that may
:    receive a set of routes (that carry this Community) carried by BGP.

By this definition, one or more routers may be addressed by a given
route target's local administrator field for a given AS in the global
administrator field.  What is meant by "unique" in this context?

The same question applies to the route origin community.

My archives (although potentially incomplete) show other people asking
this question as well:  How should extended communities deal with
aggregation?

A good case can probably be made to disallow aggregation of
routes with dissimilar route target and route origin sets.

I'm not certain it makes sense to ever include link bandwidth within
an aggregate.

Under operations:
:    A BGP speaker should not propagate a non-transitive extended
:    community across the Autonomous system boundary.

What about confederation boundaries?

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 8 Apr 2002 11:25:15 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: 2842
Sender: [email-masked]

Suggested tweaks, largely removing some redundancies between the two
paragraphs.

On Sun, Apr 07, 2002 at 02:37:04PM -0700, Yakov Rekhter wrote:
>    BGP speakers SHOULD NOT include more than one instance of a
>    capability with the same Capability Code, Capability Length,
>    and Capability Value.  Note however, that processing of multiple
>    instances of such capability does not require special handling,
>    as additional instances do not change the meaning of announced
>    capability.

>    BGP speakers MAY include more than one instance of a capability
>    (as identified by the Capability Code) with non-zero Capability
>    Length field, but with different Capability Value, and either
>    the same or different Capability Length.  Processing of these
>    capability instances is specific to the Capability Code and MUST
>    be described in the document introducing the new capability.

BGP speakers SHOULD NOT include more than one instance of a
capability with the same Capability Code, Capability Length and
Capability Value.  Additional instances of a capability code do not
change the meaning of an announced capability.  Processing of these
capability instances is specific to the Capabilility Code and MUST
be described in the document introducing the new capability.

-- 
Jeff Haas 
NextHop Technologies

To: Alex Zinin <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: 2842 
Date: Sun, 07 Apr 2002 14:37:04 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

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

With this in mind, how about the following:

   BGP speakers SHOULD NOT include more than one instance of a
   capability with the same Capability Code, Capability Length,
   and Capability Value.  Note however, that processing of multiple
   instances of such capability does not require special handling,
   as additional instances do not change the meaning of announced
   capability.

   BGP speakers MAY include more than one instance of a capability
   (as identified by the Capability Code) with non-zero Capability
   Length field, but with different Capability Value, and either
   the same or different Capability Length.  Processing of these
   capability instances is specific to the Capability Code and MUST
   be described in the document introducing the new capability.

Yakov.

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: RE: FW: BGP without an IGP
Date: Fri, 5 Apr 2002 09:26:04 -0500
Importance: Normal
Sender: [email-masked]

Hi Ilan,

You wrote:

> Also it's  recommended  not to rely on BGP itself to establish another
> BGP connection.  In your case as Ben said, the route D will not be
> propagated to Router R1.

Once the R1-R2 and R2-R3 peerings are established, (and R1, R2 and R3 have
exchanged their directly connected networks), R1 and R3 will be able to
reach each other. For example, from R1's perspective, it can get to C.R3 via
B.R2 and B is directly connected, (recursive lookup). Similarly R3 can get
to B.R1 via C.R2 with C being directly connected. In the middle, B knows how
to get to both B.R1 and C.R3 as they are both directly connected. So R1 can
send packets to C.R3 and R3 can send packets to B.R1 and that will allow the
R1-R3 peering to be established. Now R3 can advertise D to R1 with C.R3 as
next-hop.
R1 can already get to C.R3 so it can now also get to D.

> Even in the case of R1-R2-R3, if the BGP sesson
> btw R2 and R3 goes down , the session between R1 and R2 will also go
> down and it will take longer time to converge.

I'm afraid I don't understand your point here. Can you elaborate?

Ken

> -----Original Message-----
> From: Ilankumaran N [mailto:[email-masked]]
> Sent: Friday, April 05, 2002 12:35 AM
> To: Ken Benstead
> Subject: Re: FW: BGP without an IGP
>
>
> Also it's  recommended  not to rely on BGP itself to establish another
> BGP connection.  In your case as Ben said, the route D will not be
> propagated to Router R1. Even in the case of R1-R2-R3, if the BGP sesson
> btw R2 and R3 goes down , the session between R1 and R2 will also go
> down and it will take longer time to converge.
>
>
> Rds,
> Ilan
>
> Ken Benstead wrote:
>
> >Forgot to send this to the list.
> >
> >>-----Original Message-----
> >>From: Ken Benstead [mailto:[email-masked]]
> >>Sent: Thursday, March 28, 2002 4:17 PM
> >>To: Abarbanel, Benjamin
> >>Subject: RE: BGP without an IGP
> >>
> >>
> >>Ben,
> >>
> >>I realized I messed up my example just before your message
> >>arrived. I broke the IBGP readvertisment rule.
> >>
> >>Below is what I should have said. As each peering comes up the
> >>routers only advertise their directly connected networks which, I
> >>think, does not violate the readvertisement rule. As each set of
> >>peerings come up they are able to advertise networks that are one
> >>hop further away and thus allow the next set of peerings to come up.
> >>
> >>Ken
> >>
> >>==================================================================
> >>===============
> >>
> >>Assume we have four routers running BGP with IBGP sessions configured
> >>between them and "next-hop-self" enabled on each session. Each router
> >>redistributes its directly connected networks into BGP.
> >>
> >>
> >>   -----R1---------R2---------R3---------R4-----
> >>  NET A     NET B      NET C      NET D     NET E
> >>
> >>
> >>The configured sessions are:
> >>
> >>	1-hop: B.R1 - B.R2    C.R2 - C.R3    D.R3 - D.R4
> >>      2-hop: B.R1 - C.R3    C.R2 - D.R4
> >>	3-hop: B.R1 - D.R4
> >>
> >>Initially only the one-hop sessions will come up. Each router
> >>will have the following routes.
> >>
> >>	  R1             R2             R3             R4
> >>  A via direct   B via direct   C via direct   D via direct
> >>  B via direct   C via direct   D via direct   E via direct
> >>  C via B.R2     A via B.R1     B via C.R2     C via D.R3
> >>                 D via C.R3     E via D.R4
> >>
> >>With these tables the two-hop sessions can come up resulting in
> a further
> >>exchange of routes. The result, after route selection, would be:
> >>
> >>	  R1             R2             R3             R4
> >>  A via direct   B via direct   C via direct   D via direct
> >>  B via direct   C via direct   D via direct   E via direct
> >>  C via B.R2     A via B.R1     B via C.R2     C via D.R3
> >>  D via C.R3     D via C.R3     E via D.R4     B via C.R2
> >>                 E via D.R4     A via B.R1
> >>
> >>Now the three-hop session can come up and exchange routes. You
> >>end up with:
> >>
> >>	  R1             R2             R3             R4
> >>  A via direct   B via direct   C via direct   D via direct
> >>  B via direct   C via direct   D via direct   E via direct
> >>  C via B.R2     A via B.R1     B via C.R2     C via D.R3
> >>  D via C.R3     D via C.R3     E via D.R4     B via C.R2
> >>  E via D.R4     E via D.R4     A via B.R1     A via B.R1
> >>
> >>This gives full reachability.
> >>
> >>
> >>
> >>
> >>
> >
>

To: "Bruno Rijsman" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Suggested new cease subcode: "connection collision" 
Date: Thu, 04 Apr 2002 10:35:06 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

I doubt that the suggested subcode would be of any use in reality.
AFAIK, sending notification for connection collision would reset the
session state to "IDLE" for most of depoyed routers.

-- Enke

> From: "Bruno Rijsman" <[email-masked]>
> To: [email-masked]
> Subject: Suggested new cease subcode: "connection collision"
> Date: Thu, 04 Apr 2002 13:20:31 -0500
> 
> I'd like to suggest another subcode for draft-ietf-idr-cease-subcode-00: 
> "connection collision" (as described in section 6.8 of 
> draft-ietf-idr-bgp4-17)
> 
> -- Bruno
> 
> 
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos: 
> http://photos.msn.com/support/worldwide.aspx
> 

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: Suggested new cease subcode: "connection collision"
Date: Thu, 04 Apr 2002 13:20:31 -0500
Sender: [email-masked]

I'd like to suggest another subcode for draft-ietf-idr-cease-subcode-00: 
"connection collision" (as described in section 6.8 of 
draft-ietf-idr-bgp4-17)

-- Bruno

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Date: Wed, 03 Apr 2002 17:09:29 -0500
To: [email-masked]
From: Sandy Murphy <[email-masked]>
Subject: slides from IETF
Cc: [email-masked]
Sender: [email-masked]

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

My slides don't seem to have made it to the list.  So here they are.

--Sandy

--=====================_33445411==_
Content-Type: application/octet-stream; name="BGPSecurityAnalysis.idr.Mar202002.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="BGPSecurityAnalysis.idr.Mar202002.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAXQEAAAAAAAAA
EAAAXwEAAAEAAAD+////AAAAAGUBAABmAQAAXgEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
9r2NZ2eNveKZvAeZvLwHB7y8B5m8vLwHmLy8BweZvLy8////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////7ZgYD1hYGGTtra8
traTtry2tra8tpO2tryTtry2vLa8vf//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////95mYGFgYGaNZkVFRUVFRUVFRURFPkVF
RUVFRWhERT9FREVo9P//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////+SZ2eutq683j1oRGdtP20+bj5uRUVnbUVnRGhEbmhEbmg/
Z2//////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////koyNvK62jfRgZ25u/0u2krxFk2hEk41FvO+TbpK8RG28RUVF////////////
////////////////AP8A/wD/AP8AAP8A////////////////////////////////////////////
////////////////////////////AP//////////////////////////////////////////////
/42NvLy8tpKNYGht9JJobrxuZ5NFP+9oRZIHaG67k268aERoRP//////////////////////////
/wD/AP8A/wD/AAD/AP//////////////////////////////////////////////////////////
/////////////wD///////////////////////////////////////////////+8tfH/vLW8Z2Bn
aI5uaGiSRWiNRWhuaERojmhok25ik2hFRW//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////7b09LyvjWdnRUU/REVFP0VERT9F
REU/RURFP0VERUVoRGj2////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////+94t68ko2uvL28vby9vL28vby9vL28vby9vL28vby9
vL3/////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////+9vLa2G///////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////wAAAAD/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////wD//wD/////AP//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////AAD/AAAAAAAAAAAA//8A//8A/wAAAAAAAAD/AAD/AP8AAAAAAAD/AAD//wAAAAAAAP8A
AAAAAP//////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////8A/wD/
AAD/AAD/AP//AAD/AAD/AP8AAP8A//8A/wD/AP8AAP8A//8A//8A//8A/wD/AP8A/wD/////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////8AAP8AAAAAAAAAAAD/AAAA
/wD/AAAAAAD/AP8AAP8A/wAAAAAAAP8AAP//AAAAAAAA/wAAAAAA////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////8A//////8AAP///wD/////
////AP////8A////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////AP////////8AAAD//////////wD/////AP//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////AP///wD//wD//wAA//8AAP///////wD//////////////////wD///8A////////////////
/////wD/////////AP//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////AAD/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////wAA////////AP//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////wAAAP8AAAAAAAD/AAAAAP//AAAA//8A////AP8AAAAA//8A/wAA
AAD//wD/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////wD/AP8AAP8A/wD/AAD//wD/AP//AP8AAAD/AP8AAP//AP8AAP8A//8AAP//////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////wD/
/wAAAAAAAP8AAAAA//8AAAD//wAA/wAA/wD/AAD//wAAAAAAAP8AAAD/////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////wD///////////////8A
////////////AP//AP////////////8A////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////AAD/////////////AP//////////AP//
//8A////////////AP//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////AAD/////////////////////////
//////8AAP//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////AP////////////////////////////////8A////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////8AAAAAAP////8AAAD//wAAAP//////AAAA////AAD//wAA
////AAAAAAD//wAAAAAA/wD//////wAAAP//AAAAAAD/AAAAAAD/AAAAAP///wAA//8AAAAAAP//
////////////////////////////////////////////////////////////////////////////
/////////////////wD///8A//8A////AP//AP///////wD//wD/AP///wD/////AP//AAD/////
AAD///8AAP//////AP///wD//wD//wAA/wD///8A/wAA/////wD//wD///8A////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////8AAAAAAP////8AAP8A/wAAAAD//////wAAAP//////////////////////
//8A/////////////////wD/////////////////AAD/////////////AP//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////+////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_33445411==_--

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: 2842 
Date: Wed, 03 Apr 2002 12:53:05 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Yakov:
A while back Bruno Rijsman suggested adding some error code/subcodes
to the "Dynamic Capability" draft, which seems to be a good idea and
we plan to include in the next revision.

If we need to have an update version for 2842, we could take the
opportunity to add one or more error subcodes for the Capability
Parameters as well.

-- Enke

> Message-Id: <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked], Alex Zinin <[email-masked]>
> Subject: Re: 2842 
> In-Reply-To: Your message of "Mon, 25 Mar 2002 17:03:50 PST."
>              <[email-masked]> 
> Date: Mon, 25 Mar 2002 17:15:52 -0800
> From: Yakov Rekhter <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> [replying to myself...]
> 
> > Folks,
> > 
> > During the IESG review Alex Zinin brought up an issue that the
> > the following text from the current spec is a bit underspecified:
> > 
> >    A particular capability, as identified by its Capability Code, may
> >    occur more than once within the Optional Parameter.
> > 
> > To address this I'd like to proposed to replace the above sentence
> > with the following:
> > 
> >    If a particular capability, as identified by its Capability Code,
> >    occurs more than once within the Optional Parameter, and the
> >    Length field of the Optional Parameter is non-zero, then
> >    handling this is specific to the Capability Code.
> 
>     If a particular capability, as identified by its Capability Code,
>     occurs more than once within the Optional Parameter, and the
>     value of the Capability Length field is non-zero, then
>     handling this is specific to the Capability Code.
> 
> Yakov.

Date: Tue, 2 Apr 2002 11:17:09 -0500
From: Jeffrey Haas <[email-masked]>
To: "Reddy, Sudhakar" <[email-masked]>, Bruno Rijsman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Question on Confederations
Sender: [email-masked]

Once upon a time, Danny McPherson was going to put out another RFC
fixing this.  However, he suggested there may be a few other items
in there that might need addressing.

Does anyone remember what those might be?

And yes, the RFC is broken as shown in recent e-mails.

-- 
Jeff Haas 
NextHop Technologies

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: Mistake in RFC 3065 ?
Date: Tue, 02 Apr 2002 10:57:41 -0500
Sender: [email-masked]

RFC 3065 section 6.1 contains the following fragment of text:

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

      1) if the first path segment of the AS_PATH is of type
         AS_CONFED_SEQUENCE, the local system shall prepend its own AS
         number as the last element of the sequence (put it in the
         leftmost position).

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

Shouldn't item 2) be changed to:

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

-- Bruno

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: [email-masked]
Subject: scope of ATOMIC AGGREGATOR attribute
Date: Mon, 1 Apr 2002 10:49:45 +0530 
Sender: [email-masked]

hi !
	
	Socpe of  ATOMIC AGGREGATOR setting is  only when overlapping routes
are received from same adj-rib-in peer during phase 1 process  or it also
includes  while sending aggregatted route to  external/internal  peers with
diffferent AS_PATH attributes of aggregating routes during phase 3 process.
         
          Some of the implemenations will set the ATOMIC AGGREGATOR during
the phase 3 process, But when i read the rfc section (9.2.2.2) it  does not
delineates clearly.

Regards & Thanks
Venu G.

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