Subject: Re: Issue 19) Security Considerations

From: Curtis Villamizar <[email-masked]>
Date: Thu, 03 Apr 2003 09:36:06 -0500

In message <[email-masked]>, "Joris Dobbelsteen" 
writes:
> Eric,
> 
> I would agree on it as it is, just a minor opinion:
> 
> The BGP draft might at:
>  Security Considerations
>    The authentication mechanism that an implementation
>    of BGP MUST support is specified in [RFC2385]. The
>    authentication provided by this mechanism could be
>    done on a per peer basis.
> 
> emphasize this only provide minimal security.
> "In cases where a BGP implementation accepts connections
> from unconfigured hosts, the use of IPSEC AH would couter
> these threats as well as replay attacks and would permit
> key agreement and roll-over.  If routing data confiden-
> tiality were desired, IPSEC ESP would provide that service."
> [draft-murphy-bgp-vuln-02.txt]
> 
> VERY minor notice to the vuln-draft:
> IPSec ESP would effectively defeat packet filters, as this
> hides port numbers.
> 
> - Joris

Joris,

Quite frankly I'm outraged at such comments.  Only by looking at
theoretical security issues and ignoring reality (not that the two
don't highly but imperfectly overlap) can you come to the conclusion
that IPSEC is needed and in its current form is viable as a security
solution for BGP.

I think its about time we injected some reality into
draft-murphy-bgp-vuln-02.txt.

I've added a practical considerations section.  I stuck it in as 4.2.

Comments are welcome, particularly comments from people actually
running BGP networks or building BGP routers used by ISPs.

I did not mention advanced filtering works-in-progress or proposals
such as BTSH or dynamic 4-tuple EBGP filtering since these are not yet
implemented or deployed afaik.  [aside: I strongly believe that BTSH
will prove to be a viable to protect EBGP and a preferable replacement
for current filtering which some older TTM (time-to-market) line cards
still in use are unable to support.]

I should also note that the filtering best practices are far from
universally deployed and in some cases are difficult to fully deploy
due to residual use of TTM line cards unable to support filtering.

Note that IPSEC with port numbers exposed would be a viable security
solution.  It would still be a greater computational burden than
TCP-MD5 and still might be less preferred by ISPs for that reason for
some architectures.  This change to IPSEC would at least yield two
viable options and might encourage implementation and deployment of
IPSEC as a security solution for BGP.

Curtis

--- draft-murphy-bgp-vuln-02.txt	Wed Mar  5 21:00:00 2003
+++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
@@ -149,6 +149,7 @@
 3.2.2.2 Timer events ..............................................   16
 4 Security Considerations .........................................   16
 4.1 Residual Risk .................................................   16
+4.2 Practical Considerations ......................................   16
 5 References ......................................................   17
 6 Author's Address ................................................   18
 
@@ -901,6 +902,79 @@
 Filtering is in use near some customer attachment points, but is not
 effective near the Internet center.  The other mechanisms are still
 controversial and are not yet in common use.
+
+4.2 Practical Considerations
+
+The primary usage of BGP is as a means to provide reachability
+information to Autonomous Systems (AS) and to distribute external
+reachability internally within an AS.  BGP is the routing protocol
+used to distribute global routing information in the Internet.  BGP is
+therefore used by all major Internet Service Providers (ISP) and many
+smaller providers and other organizations.  
+
+The role which BGP plays in the Internet puts BGP implementations in
+unique conditions and places unique security requirements on BGP.  BGP
+is operated over interprovider interfaces in which traffic levels push
+the state of the art in specialized packet forwarding hardware and
+exceed the performace capabilities of hardware implementation of
+decryption by many decimal orders of magnitude.  
+
+ISP networks must be and are under tight control.  The only viable
+means to protect the network elements from Denial of Service (DoS)
+attacks under such conditions are packet based filtering techniques
+based on relatively simple inspections of packets.
+
+To protect Internal BGP (IBGP) sessions, filters are applied at all
+borders to an ISP network which remove all traffic destined for
+addresses of network elements internal addresses (typically contained
+within a single prefix) and the BGP port number (179).  Packets from
+within an ISP are not forwarded from an internal interface to the BGP
+speaker's address on which External BGP (EBGP) sessions are supported,
+or to a peer's EBGP address if the BGP port number is found.  With
+appropriate consideration in router design, in the event of failure of
+a BGP peer to provide the equivalent filtering the risk of compromise
+can be limited to the peering session on which filtering is not
+performed by the peer or the interface or line card on which the
+peering is supported.  There is substantial motivation and little
+effort for ISPs to maintain such filters.
+
+Being composed entirely of specialized network equipment, under strict
+control of the ISP, the ISP network is not subject to attacks from
+within than enterprise networks are with more generalized computing
+systems and staff less carefully trained in the area of secure
+procedures.  Monitoring of traffic from within requires either
+compromise of relatively physically secure and carefully administered
+network elements or monitoring physical media.  Injection of traffic
+requires either compromise of network elements or intercept and
+replacement of traffic on physical media.
+
+The difficulty of compromise of network elements and of undetected
+tapping into physical media carrying extremely high volumes of traffic
+is much greater than the difficulty of injecting sufficient traffic
+from outside a network to effect a DoS attack.  As a result, the
+ability to packet filter on the basis of port numbers far exceeds the
+need to cryptographic strength in encapsulation.
+
+These practical considerations yield the situation in which TCP-MD5,
+though cryptographic weak, far better serves ISP security needs than
+the cryptographicly much stronger IPSEC which makes packet filtering
+infeasible.
+
+Use of BGP in smaller networks yields similar requirements.  The
+capability of a single workstation with high speed interface to
+generate false traffic far exceeds the capability of software based
+decryption or appropriately priced cryptographic hardware.  From a
+practical standpoint, these networks are also better served by
+appropriate administrative care, filtering, and TCP-MD5 than by IPSEC.
+
+This situation is likely to persist unless either cryptographic
+hardware becomes many orders of magnitude faster and cheaper or IPSEC
+supports an ability to leave IP port numbers exposed.  This
+requirement has been made known to the IPSEC WG.
+
+Until such time as IPSEC is modified, there is little choice but to
+mandate TCP-MD5 implementation and recommend TCP-MD5 usage for BGP and
+discourage IPSEC usage for BGP.
 
 5.  References

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Mon, 14 Apr 2003 23:32:56 +0200

Curtis, it was not my intension to upset you in any way. Still it looks
like I successed doing that....... Any way, we do need some feedback
from practical deployments.

My personal consideration would be not to put it in a chapter 4.2 but
get it throughout the entire draft.

Packet filters provide the good protection for IBGP sessions. These are
harder/impractical for EBGP(?).
Internal attacks and hacks on the network channels are not considered
practical.

IPSec is not recommended because at least three reasons:
TCP-MD5 is already widely implemented and deployed.
Complication in network management, because packet filters need to be
adapted for IPSec traffic (port 500 - IKE).
IPSec has higher processing demands that TCP-MD5 does, lowing the
barrier for a successful DoS attack. Hardware IPSec implementations are
considered impractical, due to the cost or performance.

This brings up your statement that IPSec covers the ports. This is not
true, when encryption (ESP) is not used. The use of intigrity (AH)
will not hide the ports, it works sorta TCP-MD5, if you want...
I also did never consider using ESP, since it was not desired and it
would be the way to 'promote' DoS attacks.
Unfortunally I don't have any insight on IPSec hardware, maybe some else
can give some insight on this.

I suppose this closes the IPSec/TCP-MD5 issue, leaving TCP-MD5 to the 
current best option.

Still this leaves EBGP open for consideration.

The use of BGP TTL Security Hack (BTSH) might be a very simple and
effective way of protecting the external routers from attacks,
especially DoS attacks. Malicious data can be prevented using TCP-MD5.
The disadvantage is that it is not deployed widely, but only requires
routers to send there traffic with an initial TTL of 255. I don't
know if this is currently possible to archieve: whether current
implementations can be set to send with an initial TTL of 255. It is
not needed for both end-points to support BTSH, although desired.
<draft-gill-btsh-01.txt>

I couldn't find any information about dynamic 4-tuple filtering
(google turns up BGP dynamic capabilities), unfortunally.

So what else can be done to prevent a EBGP session from attacks,
especially DoS attacks? Data insertion/manipulations can be guarded
against using TCP-MD5 (or similar).

- Joris

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Curtis Villamizar
>Sent: Thursday, 3 April 2003 16:36
>To: Joris Dobbelsteen
>Cc: 'IDR WG (E-mail)'
>Subject: Re: Issue 19) Security Considerations 
>
>> [snip]
> 3.2.2.2 Timer events 
>..............................................   16
> 4 Security Considerations 
>.........................................   16
> 4.1 Residual Risk 
>.................................................   16
>......................................   16
> 5 References 
>......................................................   17
> 6 Author's Address 
>................................................   18
> 
>@@ -901,6 +902,79 @@
>+procedures.  ...

For me personally, the above sentence is a little hard to understand.
You mean that ???
The Internal BGP routers (or specialized network equipment) that is under
strict control of the ISP is not subject to attacks, other than those that
are common in enterprise networks. These networks have staff that is
less carefully trained in the area of security procedures.

>+ ...........  Monitoring of traffic from within requires either

See above, using intigrity only (AH), leaves TCP (not IP) port numbers
readable for everyone. This security is rather an IPSec configuration
option.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Apr 2003 12:40:23 -0400

Curtis wrote in a previous message:

> +++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
[...]

This looks like it has good merit.  Shouldn't we add this to the document?
(Well, not "we" since Sandy is authoring it, but it seems like a good idea.)

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 30 Apr 2003 12:40:23 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

Curtis wrote in a previous message:

> +++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
[...]

This looks like it has good merit.  Shouldn't we add this to the document?
(Well, not "we" since Sandy is authoring it, but it seems like a good idea.)

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 28 Apr 2003 08:46:31 +0530
From: Manav Bhatia <[email-masked]>
Subject: draft-mcpherson-bgp4-expereince-00.txt
To: [email-masked]
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hi Danny,
Some comments.

Going with what the introduction of the draft says that this document
"describes additional knowledge and understanding gained in the time
between when the protocol was made a Draft Standard and when it was
submitted for Standard".

>
>    Possible applications of BGP in the Internet are documented in [RFC
>    1772].
>
>    The BGP protocol was developed by the IDR Working Group of the
>    Internet Engineering Task Force. This Working Group had a mailing
>    list, [email-masked], where discussions of protocol features and

I think it'll be "has" :-)

>    operation are held. The IDR Working Group meets regularly during the
>    Internet Engineering Task Force meetings.  Reports of these meetings
>    are published in the IETF's Proceedings.

[snip]

>
> 8.  Internal BGP In Large Autonomous Systems

[snip]

>    BGP "Route Reflector" extensions has been defined in RFC 1966 to
>    alleviate the the need for "full mesh" IBGP.

Basically defined in 1966 and then updated in 2796.

Confederations? Though you did mention them in the section 5 - this seems
to be a better place for them!

> 9.  Internet Dynamics

We can also mention "BGP Route Flap Damping" [RFC 2439] here.

[snip]

> 14.  AS_SET Sorting
>
>
>    AS_SETs are commonly used in BGP route aggregation. They reduce the
>    size of AS_PATH information by listing AS numbers only once
>    regardless of any number of times it might appear in process of
>    aggregation. AS_SETs are usually sorted in increasing order to
>    facilitate efficient lookups of AS numbers within them. This
>    optimization is entirely optional.

I think that we can also mention that using AS_SET with the aggregate can
cause some route instabilities due to the fact that changes in the
attribute of the individual routes being summarized translate into changes
of the aggregate itself, causing the aggregate to be constantly withdrawn
and updated.

Do we need to mention Complex AS_PATH aggregation?

Regards,
Manav

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-mcpherson-bgp4-expereince-00.txt
Date: Fri, 25 Apr 2003 07:42:26 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-mcpherson-bgp4-expereince-00.txt
	Pages		: 19
	Date		: 2003-4-24
	
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for 'the second report', as
described in Section 6.0 of RFC 1264.  In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcpherson-bgp4-expereince-00.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-mcpherson-bgp4-expereince-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcpherson-bgp4-expereince-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Thu, 24 Apr 2003 09:52:53 -0400 (EDT)
From: Daniel Walton <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP ECMP 
Sender: [email-masked]

                       ________________      iBGP       ______________
                       |     RR       |-----------------| non-Client |
                       |  4.0.4.43    |     (IGP : 235) | 4.0.0.106  |
                       |______________|                 |____________|
                              |                               \
                              | iBGP                           \
                              | (IGP : 60)                      \
                              |                               AS : 5646
                       _______|________                       MED: 1000
                       |    Client    |
                       |   4.0.0.10   |
                       |______________|
                         /         \
                  eBGP  /           \ eBGP
                       /             \
                      /               \
                eBGP-1                 eBGP-2
             AS  : 5696              AS  : 5646
             MED : 1000              MED : 10000
             Rid : 209.54.136.8      Rid : 207.112.244.49

Assumptions:
- * indicates the bestpath
- deterministic-med is configured

Step 1 - init state
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5696    1000    E       0       209.54.136.8
                *5646   10000   E       0       207.112.244.49
RR              -       -       -       -       -
non-Client      *5646   1000    E       0       -

Step 2 - Client and non-Client advertise bestpaths to RR
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5696    1000    E       0       209.54.136.8
                *5646   10000   E       0       207.112.244.49
RR              5646    10000   I       60      207.112.244.49
                *5646   1000    I       235     -
non-Client      *5646   1000    E       0       -

Step 3 - RR advertises bestpath to Client
       - Client selects eBGP-1 path as best
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5646    1000    I       295     -
                5646    10000   E       0       207.112.244.49
                *5696   1000    E       0       209.54.136.8
RR              5646    10000   I       60      207.112.244.49
                *5646   1000    I       235     -
non-Client      *5646   1000    E       0       -

Step 4 - RR selects eBGP-1 path as best
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5646    1000    I       295     -
                5646    10000   E       0       207.112.244.49
                *5696   1000    E       0       209.54.136.8
RR              *5696   1000    I       60      209.54.136.8
                5646    1000    I       235     -
non-Client      *5646   1000    E       0       -

Step 5 - RR withdraws his previous advertisement of 5646, MED 1000
       - Client is left with two external paths.  If he changes bestpath
         based on router-id then we will be back to step 2 (RR will know
         about eBGP-2 from Client and 5646, MED 1000 from non-client) and
         we are in MED oscillation.  If he prefers to keep his
         current bestpath then we do not oscillate.
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5646    10000   E       0       207.112.244.49
                5696    1000    E       0       209.54.136.8
RR              *5696   1000    I       60      209.54.136.8
                5646    1000    I       235     -
non-Client      *5646   1000    E       0       -

One point of confusion here is that the docs say we prefer the older external
path. A more accurate description is that we won't make the bestpath change if
we are comparing two external paths and make it to the router-id step in the
decision process.

Call it non-deterministic if you want but it solves MED churn in this scenario
and I have never heard a customer complain.  If they decide to start
complaining, we have a knob they can turn to enforce the router-id check.

Daniel

On Wed, 23 Apr 2003, Pedro Roque Marques wrote:

> Daniel Walton writes:
>
> Daniel,
> I don't think your message really addresses my question.
>
> > MED oscillation happens in this topology when we change our bestpath
> > based only on a difference in router-id.
>
> That is not acurate... MED oscillation happens when you have a
> circular dependency. The "oldest external" rule will, in 50% of the
> cases, on the previous example yield the same result as if you would
> select these paths based router-id. i.e. whenever the 'oldest
> external' is the lowest router-id the result is the exact same.
>
> Thus i don't think you can claim that this solves the problem that you
> mention. Although you may claim to make it less likely... at the
> expense of making it even less predictable.
>
> >  It is easy to stop the
> > oscillation here by preferring the 'oldest external' instead of
> > making a bestpath change over a router-id change which is fairly
> > arbitrary.  If only the other variations of MED churn where this
> > easy to solve :)
>
> I don't understand how the 'oldest external' rule as currently
> documented by cisco stops oscillation.
>
> It would be great if you could provide more details to substantiate
> this claim.
>
> > There is a knob to enforce the router-id comparison step if the user
> > desires.
>
> We are discussing what the 'oldest external' rule buys you and
> potential disadvantages. I'm trying to understand the
> implications...
>
> thanks,
>   Pedro.
>

Date: Thu, 24 Apr 2003 08:41:38 -0400 (EDT)
From: Daniel Walton <[email-masked]>
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-walton-bgp-add-paths-01.txt
Sender: [email-masked]

My bad, I thought we included a section on possible solutions but in the end we
put in "It should be stated that protocol enhancements regarding this problem
must be pursued.  Imposing network design requirements, such as those outlined
above, are clearly an unreasonable long-term solution.  Problems such as this
should not occur under 'default' protocol configurations."

One possible solution for MED churn is to advertise your bestpath per
neighbor-AS in addition to your bestpath.  For the topo in 3.1, Rc and Rd would
need to advertise the AS 200/MED 0 path to Re in order to stop the oscillation.
There is still work to be done to determine when you should/should not advertise
extra paths in order to prevent MED churn but not carry lots of extra paths for
nothing.

Daniel

On Wed, 23 Apr 2003, Mareline Sheldon wrote:

> Dan,
>
> >
> > > 2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
> > > indicates that the path associated with the NLRI has been selected by the
> > > BGP speaker for installation into its FIB. If set to zero, then the path is
> > > not selected. Why would we ever want to advertise a path which has not been
> > > selected by BGP? If it is to withdraw a previously advertised path then a
> > > better approach would be to send it in the WITHDRAW field.
> > >
> >
> > To solve MED churn, see RFC 3345
>
> How does advertising a path which is not being used by BGP solve the MED churn. I could not
> find anything in RFC 3345 which talks of this.
>
> Regards,
> Mareline S.
>
>
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-02.txt
Date: Thu, 24 Apr 2003 07:31:45 -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		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-02.txt
	Pages		: 19
	Date		: 2003-4-23
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 23 Apr 2003 22:56:02 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: Re: draft-walton-bgp-add-paths-01.txt
To: Daniel Walton <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Dan,

> 
> > 2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
> > indicates that the path associated with the NLRI has been selected by the
> > BGP speaker for installation into its FIB. If set to zero, then the path is
> > not selected. Why would we ever want to advertise a path which has not been
> > selected by BGP? If it is to withdraw a previously advertised path then a
> > better approach would be to send it in the WITHDRAW field.
> >
> 
> To solve MED churn, see RFC 3345

How does advertising a path which is not being used by BGP solve the MED churn. I could not
find anything in RFC 3345 which talks of this.

Regards,
Mareline S.

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

Date: Wed, 23 Apr 2003 14:10:47 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Daniel Walton <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP ECMP 
Sender: [email-masked]

Daniel Walton writes:

Daniel,
I don't think your message really addresses my question.

> MED oscillation happens in this topology when we change our bestpath
> based only on a difference in router-id.

That is not acurate... MED oscillation happens when you have a
circular dependency. The "oldest external" rule will, in 50% of the
cases, on the previous example yield the same result as if you would
select these paths based router-id. i.e. whenever the 'oldest
external' is the lowest router-id the result is the exact same.

Thus i don't think you can claim that this solves the problem that you
mention. Although you may claim to make it less likely... at the
expense of making it even less predictable.

>  It is easy to stop the
> oscillation here by preferring the 'oldest external' instead of
> making a bestpath change over a router-id change which is fairly
> arbitrary.  If only the other variations of MED churn where this
> easy to solve :)

I don't understand how the 'oldest external' rule as currently
documented by cisco stops oscillation.

It would be great if you could provide more details to substantiate
this claim.

> There is a knob to enforce the router-id comparison step if the user
> desires.

We are discussing what the 'oldest external' rule buys you and
potential disadvantages. I'm trying to understand the
implications...

thanks,
  Pedro.

Date: Wed, 23 Apr 2003 16:24:54 -0400 (EDT)
From: Daniel Walton <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP ECMP 
Sender: [email-masked]

On Wed, 23 Apr 2003, Pedro Roque Marques wrote:

> Daniel Walton writes:
>
> Daniel,
>
> > 9. The BGP scanner which runs once in a minute (which explains the
> > periodicity in maeeast router) validates the nexthop and calculates
> > the bestpath. At this stage, eBGP-2 is picked up as best due to
> > lower router-id.
>
> If i understand your text correctly, it is at this stage that the new
> rule of using the "oldest" of the external routes comes into play.
>
> But it would seem to me that you have 50-50 chance that the oldest
> route is the same as the lowest router-id, thus causing a loop again.
>

MED oscillation happens in this topology when we change our bestpath based only
on a difference in router-id.  It is easy to stop the oscillation here by
preferring the 'oldest external' instead of making a bestpath change over a
router-id change which is fairly arbitrary.  If only the other variations of MED
churn where this easy to solve :)

There is a knob to enforce the router-id comparison step if the user desires.

Daniel

> It seems to me that introducing this non-deterministic step wouldn't
> fix the MED oscillation problem... it just makes it non-deterministic
> when the problem will occur. Which is not necessarly a feature...
>
> regards,
>   Pedro.
>

Date: Wed, 23 Apr 2003 10:51:38 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Daniel Walton <[email-masked]>
Cc: <[email-masked]>
Subject: Re: BGP ECMP 
Sender: [email-masked]

Daniel Walton writes:

Daniel,

> 9. The BGP scanner which runs once in a minute (which explains the
> periodicity in maeeast router) validates the nexthop and calculates
> the bestpath. At this stage, eBGP-2 is picked up as best due to
> lower router-id.

If i understand your text correctly, it is at this stage that the new
rule of using the "oldest" of the external routes comes into play.

But it would seem to me that you have 50-50 chance that the oldest
route is the same as the lowest router-id, thus causing a loop again.

It seems to me that introducing this non-deterministic step wouldn't
fix the MED oscillation problem... it just makes it non-deterministic
when the problem will occur. Which is not necessarly a feature...

regards,
  Pedro.

Date: Wed, 23 Apr 2003 11:40:28 -0400 (EDT)
From: Daniel Walton <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, Russ White <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: BGP ECMP 
Sender: [email-masked]

On Tue, 22 Apr 2003, Pedro Roque Marques wrote:

> Daniel Walton writes:
>
> >> The last step in the route selection being either router-id based
> >> or first come based is called deterministic or non-deterministic.
> >> The spec calls for deterministic selection.  If you have a route
> >> flap and the stable route is the least preferred, then
> >> deterministic selection causes a lot of route change.  The obvious
> >> answer is to damp the route flap.
>
> > Changing bestpath based on router-id can cause MED churn in some
> > topologies.
>
> >> Some providers insist on using the non-deterministic route
> >> selection (first route to arrive is preferred) then wonder why they
> >> occasionally get a few persistant route loops.
>
> > Do you have an example of when this will loop?
>
> It is not clear to me if you folks are talking about the same thing...
>
> There are two non deterministic steps in cisco's path selection as
> publicly documented(1):
> a) non-"bgp deterministic med"
> b) Step 10 (of the public algorithm) "When both paths are external,
> prefer the path that was received first".
>
> The first can only be described as a bug and can indeed lead to
> routing loops as it has been found in the field. The latter cannot
> cause routing loops as far as i can see. Selection between external
> paths can be considered a local matter.
>
> What i'm not clear about is how this rule, as documented, avoids MED
> oscillation. Would you mind giving an example ?
>
> (1) http://www.cisco.com/warp/public/459/25.shtml

This is from several years ago, before we knew what MED oscillation was:

                       ________________      iBGP       ______________
                       |     RR       |-----------------| non-Client |
                       |  4.0.4.43    |     (IGP : 235) | 4.0.0.106  |
                       |______________|                 |____________|
                              |                               \
                              | iBGP                           \
                              | (IGP : 60)                      \
                              |                               AS : 5646
                       _______|________                       MED: 1000
                       |    Client    |
                       |   4.0.0.10   |
                       |______________|
                         /         \
                  eBGP  /           \ eBGP
                       /             \
                      /               \
                eBGP-1                 eBGP-2
             AS  : 5696              AS  : 5646
             MED : 1000              MED : 10000
             Rid : 209.54.136.8      Rid : 207.112.244.49

1. Client selects eBGP-2 (MED 10000) due to router-id as the bestpath
initially. (MED is not comparable since neighboring-AS are different).

2. Client advertises this path to RR.

3. RR has 2 iBGP paths, one from non-client and another from client. It
selects the one from non-client (MED being lower).

4. RR reflects the bestpath (MED 1000) to client.

5. Client now has 3 paths, 2 eBGP and 1 iBGP. It selects eBGP-1 (MED 1000)
since iBGP path wins over eBGP-2 on MED, eBGP-1 wins over iBGP since we
prefer external over internal.

6. Client now advertises the current bestpath (MED 1000)  to RR.

7. RR which has 2 iBGP paths picks up the path from Client based on the IGP
distance as best. It poisons the route to client.

8. Client which receives the withdraw from RR silently discards it since
the iBGP path was not the current best. We calculate the bestpath only when
current bestpath is withdrawn.

9. The BGP scanner which runs once in a minute (which explains the
periodicity in maeeast router) validates the nexthop and calculates the
bestpath. At this stage, eBGP-2 is picked up as best due to lower
router-id.

10. Client advertises the new bestpath to RR and cycles again...

Daniel

Date: Wed, 23 Apr 2003 08:37:07 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: BGP ECMP
To: Russ White <[email-masked]>
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Russ,

> It's based on the local bestpath decision--the older route, or the better
> router id, if you're straight by the spec. What you normally do is to
> exclude some portion of the bestpath algorithm, usually just the router
id,
> to determine "equal cost" paths.

Right.

But the point is that you're still advertising only one best route to your
other peers (based on the age of the route/router ID/etc) while you may
yourself be injecting multiple entries in your FIB. It is possible
(especially in IBGP) to think of a scenario where if you advertise multiple
routes to your peer then it may be in a position to use them for its own
forwarding.

This becomes more of an issue when deploying RRs as they will be connected
to a lot of IBGP peers and it might be recieving multiple "equal cost" BGP
routes (which it might insert in its FIB) while it would be advertising
only the *best* one out and thus depriving the other peers to use those
multiple routes for load balancing.

Regards,
Manav

To: Daniel Walton <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, Russ White <[email-masked]>, Manav Bhatia <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP ECMP 
Date: Tue, 22 Apr 2003 22:33:46 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Dan
iel Walton writes:
> On Tue, 22 Apr 2003, Curtis Villamizar wrote:
> 
> 
> > Some providers insist on using the non-deterministic route selection (first
> > route to arrive is preferred) then wonder why they occasionally get a few
> > persistant route loops.
> 
> Do you have an example of when this will loop?
> 
> Daniel

You are right.  It is the non-deterministic-med that can loop.

The deterministic next hop only affects where traffic goes in the
normal everything up situation.

Curtis

Date: Tue, 22 Apr 2003 16:20:12 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Daniel Walton <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, Russ White <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: BGP ECMP 
Sender: [email-masked]

Daniel Walton writes:

>> The last step in the route selection being either router-id based
>> or first come based is called deterministic or non-deterministic.
>> The spec calls for deterministic selection.  If you have a route
>> flap and the stable route is the least preferred, then
>> deterministic selection causes a lot of route change.  The obvious
>> answer is to damp the route flap.

> Changing bestpath based on router-id can cause MED churn in some
> topologies.

>> Some providers insist on using the non-deterministic route
>> selection (first route to arrive is preferred) then wonder why they
>> occasionally get a few persistant route loops.

> Do you have an example of when this will loop?

It is not clear to me if you folks are talking about the same thing...

There are two non deterministic steps in cisco's path selection as
publicly documented(1):
a) non-"bgp deterministic med"
b) Step 10 (of the public algorithm) "When both paths are external,
prefer the path that was received first".

The first can only be described as a bug and can indeed lead to
routing loops as it has been found in the field. The latter cannot
cause routing loops as far as i can see. Selection between external
paths can be considered a local matter.

What i'm not clear about is how this rule, as documented, avoids MED
oscillation. Would you mind giving an example ?

(1) http://www.cisco.com/warp/public/459/25.shtml

  Pedro.

Date: Tue, 22 Apr 2003 17:03:19 -0400 (EDT)
From: Daniel Walton <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-walton-bgp-add-paths-01.txt
Sender: [email-masked]

On Tue, 22 Apr 2003, Manav Bhatia wrote:

> Hello,
> Some comments on the above stated draft to start with.
>
> 1. The length of the Identifier has been kept as 2 octets. Are we anticipating
> 2^16 ECMP BGP routes? I think we can use the remaining bits from the Flags to
> make our IP prefixes unique. Even if we want some space reserved for future
> extensions we don't need to keep 2 octets for making the prefix unique!
>

ack, we'll take a look at this

> 2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
> indicates that the path associated with the NLRI has been selected by the
> BGP speaker for installation into its FIB. If set to zero, then the path is
> not selected. Why would we ever want to advertise a path which has not been
> selected by BGP? If it is to withdraw a previously advertised path then a
> better approach would be to send it in the WITHDRAW field.
>

To solve MED churn, see RFC 3345

> 3. What happens when a router has already advertised some ECMP routes and
> it later receives a new ECMP BGP route. How does it advertise this one to
> its neighbors? The problem is that it would have advertised its last ECMP
> BGP route with the Lastbit set (which indicates that the particular path is
> the last one in the UPDATE message for that prefix). To now advertise this
> new path does it readvertise all the paths to that prefix OR does it just
> advertise the new path information with Bestpath bit set, FirstPath bit
> unset and LastBit set/unset (I don't know!)
>
> This seems to be ambiguous in the draft and can be worked upon.
>

Right now the plan is to remove the Lastpath section from the draft.  There are
to many cases where it causes problems.

> 4. The draft does not mention the changes required in the Decision Process.
> How does a router decide that the two BGP routes that it has are of the
> same cost?
>

hmm, so if a peer advertises me two paths with the same attributes the bestpath
decision needs a way to declare one better than the other since both paths have
the same router-id.  We can add something stating that the add-path ID can be
used as a tie-breaker in this scenario.

> 5. The Flags and the Identifier fields have been explained thrice in
> sections 2.2.1, 2.2.2. and 2.2.3. I think we can manage with just one.
>

This will be cleaned up in the next revision.

Thanks
Daniel

Date: Tue, 22 Apr 2003 16:43:43 -0400 (EDT)
From: Daniel Walton <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Cc: Russ White <[email-masked]>, Manav Bhatia <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: BGP ECMP 
Sender: [email-masked]

On Tue, 22 Apr 2003, Curtis Villamizar wrote:

>
> In message <Pine.WNT.4.53.0304221349461.528@russpc>, Russ White writes:
> >
> > > > Before I comment on some your questions posted I think it is worth to
> > > > keep in mind that until now most of those implementations you may be
> > > > refering to treat multipath as a local to the box feature. As far as
> > > > advertisements to i/eBGP peers only best path is advertised as usual.
> > >
> > > What is taken as the *best* path?
> > >
> > > Say both the routes have equal AS-path lengths, LPs, etc. So which one is
> > > advertised to the downstream peers? Won't the second advertisement (if
> > > both are sent) be taken as an implict withdraw by the other peers? I thus
> > > dont think its an issue local to the box implementing multi-path.
> >
> > It's based on the local bestpath decision--the older route, or the better
> > router id, if you're straight by the spec. What you normally do is to
> > exclude some portion of the bestpath algorithm, usually just the router id,
> > to determine "equal cost" paths.
>
> The last step in the route selection being either router-id based or
> first come based is called deterministic or non-deterministic.  The
> spec calls for deterministic selection.  If you have a route flap and
> the stable route is the least preferred, then deterministic selection
> causes a lot of route change.  The obvious answer is to damp the route
> flap.

Changing bestpath based on router-id can cause MED churn in some topologies.

> Some providers insist on using the non-deterministic route selection (first
> route to arrive is preferred) then wonder why they occasionally get a few
> persistant route loops.

Do you have an example of when this will loop?

Daniel

> The deterministic selection is free of persistant route loops.
> Non-deterministic selection is not free of persistant route loops and
> that is why it is a MUST in the spec.  Some providers ask for it,
> therefore non-deterministic selection is an option on most routers.
>
> > > > Hence there is no obvious interoperability problems in mutlipath as
> > > > such.
> > >
> > > I see an obvious interoperability issue because the routes which are used
> > > and advertised by this particular router directly affects the other
> > > routers (downstream).
> >
> > A downstream router will have no idea an upstream router is doing
> > multipath. The advertisements it receives will be the same either way.
> >
> > :-)
>
> Right.
>
> > Russ
>
> Curtis
>

To: Russ White <[email-masked]>
Cc: Manav Bhatia <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP ECMP 
Date: Tue, 22 Apr 2003 15:44:50 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <Pine.WNT.4.53.0304221349461.528@russpc>, Russ White writes:
> 
> > > Before I comment on some your questions posted I think it is worth to
> > > keep in mind that until now most of those implementations you may be
> > > refering to treat multipath as a local to the box feature. As far as
> > > advertisements to i/eBGP peers only best path is advertised as usual.
> >
> > What is taken as the *best* path?
> >
> > Say both the routes have equal AS-path lengths, LPs, etc. So which one is
> > advertised to the downstream peers? Won't the second advertisement (if
> > both are sent) be taken as an implict withdraw by the other peers? I thus
> > dont think its an issue local to the box implementing multi-path.
> 
> It's based on the local bestpath decision--the older route, or the better
> router id, if you're straight by the spec. What you normally do is to
> exclude some portion of the bestpath algorithm, usually just the router id,
> to determine "equal cost" paths.

The last step in the route selection being either router-id based or
first come based is called deterministic or non-deterministic.  The
spec calls for deterministic selection.  If you have a route flap and
the stable route is the least preferred, then deterministic selection
causes a lot of route change.  The obvious answer is to damp the route
flap.  Some providers insist on using the non-deterministic route
selection (first route to arrive is preferred) then wonder why they
occasionally get a few persistant route loops.

The deterministic selection is free of persistant route loops.
Non-deterministic selection is not free of persistant route loops and
that is why it is a MUST in the spec.  Some providers ask for it,
therefore non-deterministic selection is an option on most routers.

> > > Hence there is no obvious interoperability problems in mutlipath as
> > > such.
> >
> > I see an obvious interoperability issue because the routes which are used
> > and advertised by this particular router directly affects the other
> > routers (downstream).
> 
> A downstream router will have no idea an upstream router is doing
> multipath. The advertisements it receives will be the same either way.
> 
> :-)

Right.

> Russ

Curtis

Date: Tue, 22 Apr 2003 13:52:49 -0400 (Eastern Daylight Time)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP ECMP
Sender: [email-masked]

> > Before I comment on some your questions posted I think it is worth to
> > keep in mind that until now most of those implementations you may be
> > refering to treat multipath as a local to the box feature. As far as
> > advertisements to i/eBGP peers only best path is advertised as usual.
>
> What is taken as the *best* path?
>
> Say both the routes have equal AS-path lengths, LPs, etc. So which one is
> advertised to the downstream peers? Won't the second advertisement (if
> both are sent) be taken as an implict withdraw by the other peers? I thus
> dont think its an issue local to the box implementing multi-path.

It's based on the local bestpath decision--the older route, or the better
router id, if you're straight by the spec. What you normally do is to
exclude some portion of the bestpath algorithm, usually just the router id,
to determine "equal cost" paths.

> > Hence there is no obvious interoperability problems in mutlipath as
> > such.
>
> I see an obvious interoperability issue because the routes which are used
> and advertised by this particular router directly affects the other
> routers (downstream).

A downstream router will have no idea an upstream router is doing
multipath. The advertisements it receives will be the same either way.

:-)

Russ

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-01.txt
Date: Tue, 22 Apr 2003 07:39:56 -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		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-01.txt
	Pages		: 19
	Date		: 2003-4-21
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 22 Apr 2003 10:09:23 +0530
From: Manav Bhatia <[email-masked]>
Subject: draft-walton-bgp-add-paths-01.txt
To: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hello,
Some comments on the above stated draft to start with.

1. The length of the Identifier has been kept as 2 octets. Are we
anticipating 2^16 ECMP BGP routes? I think we can use the remaining bits
from the Flags to make our IP prefixes unique. Even if we want some space
reserved for future extensions we don't need to keep 2 octets for making
the
prefix unique!

2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
indicates that the path associated with the NLRI has been selected by the
BGP speaker for installation into its FIB. If set to zero, then the path is
not selected. Why would we ever want to advertise a path which has not been
selected by BGP? If it is to withdraw a previously advertised path then a
better approach would be to send it in the WITHDRAW field.

3. What happens when a router has already advertised some ECMP routes and
it later receives a new ECMP BGP route. How does it advertise this one to
its neighbors? The problem is that it would have advertised its last ECMP
BGP route with the Lastbit set (which indicates that the particular path is
the last one in the UPDATE message for that prefix). To now advertise this
new path does it readvertise all the paths to that prefix OR does it just
advertise the new path information with Bestpath bit set, FirstPath bit
unset and LastBit set/unset (I don't know!)

This seems to be ambiguous in the draft and can be worked upon.

4. The draft does not mention the changes required in the Decision Process.
How does a router decide that the two BGP routes that it has are of the
same cost?

5. The Flags and the Identifier fields have been explained thrice in
sections 2.2.1, 2.2.2. and 2.2.3. I think we can manage with just one.

Regards,
Manav

----
Senior Software Engineer
Samsung India Software Operations
Bangalore - 560 001
+91-80-5550555/6 (1120)

Date: Mon, 21 Apr 2003 12:15:24 -0700 (PDT)
From: Shankar Vemulapalli <[email-masked]>
To: Christian Kaas-Petersen <[email-masked]>
Cc: [email-masked]
Subject: Re: VPN encoding
Sender: [email-masked]

The only other comment that I can add is that these drafts will
get their own RFC # [if they get OKed] and will obsolete the older ones.

/Shankar

At 9:37am 04/08/03 +0200, Christian Kaas-Petersen wrote:
> RFC2547bis is not an RFC, but a draft. This draft can be found on
> www.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-03.txt.
>
> Christian
>
> Tim Griffin wrote:
>
> >"bis" means "twice" in latin.  in portuguese, it can be shouted after
> >a performance and means "encore"
> >
> >Mareline Sheldon wrote:
> >
> >>Shankar,
> >>I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
> >>what is this?
> >>
> >>Thanks,
> >>Mareline S.
> >>
> >>--- Shankar Ananthanarayanan Kambat <[email-masked]> wrote:
> >>
> >>>Second version of original spec with updated sections
> >>>
> >>>- Shankar K A
> >>>
> >>>
> >>>From: Mareline Sheldon [mailto:[email-masked]]
> >>>Sent: Monday, April 07, 2003 10:46 AM
> >>>To: [email-masked]
> >>>Subject: RE: VPN encoding
> >>>
> >>>
> >>>Hello,
> >>>Thanks a lot for the info Vijay!
> >>>
> >>>Can anybody please explain me what the "bis" in RFC 2547bis stands for?
> >>>
> >>>I have come across this term "bis" on a number of occasions and i am
> >>>never able to understand
> >>>what it truly means.
> >>>
> >>>Can anybody please shed some light on that?
> >>>
> >>>Thanks,
> >>>Mareline S.
> >>>
> >>>----- Original Message -----
> >>>From: "Krishnan, Vijay G." <[email-masked]>
> >>>To: "'Mareline Sheldon'" <[email-masked]>; <[email-masked]>
> >>>Sent: Saturday, April 05, 2003 2:56 AM
> >>>Subject: RE: VPN encoding
> >>>
> >>>
> >>>>Mareline,
> >>>>
> >>>>Encoding of label in BGP updates - RFC3107
> >>>>Encoding Route Distnguisher - RFC2547bis draft
> >>>>
> >>>>-Vijay
> >>>>
> >>>>
> >>>
> >>>__________________________________________________
> >>>Do you Yahoo!?
> >>>Yahoo! Tax Center - File online, calculators, forms, and more
> >>>http://tax.yahoo.com
> >>>
> >>>>**************************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.
> >>>
> >>>****************************************************************************************
> >>>
> >>__________________________________________________
> >>Do you Yahoo!?
> >>Yahoo! Tax Center - File online, calculators, forms, and more
> >>http://tax.yahoo.com
> >>
>
>

Date: Mon, 21 Apr 2003 19:00:17 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: BGP ECMP
To: [email-masked]
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hi Robert,
I have not yet gone through the walton draft and am thus not in a position
to comment on that (will go through it in some time). Meanwhile I have some
comments inlined.

> Before I comment on some your questions posted I think it is worth to
> keep in mind that until now most of those implementations you may be
> refering to treat multipath as a local to the box feature. As far as
> advertisements to i/eBGP peers only best path is advertised as usual.

What is taken as the *best* path?

Say both the routes have equal AS-path lengths, LPs, etc. So which one is
advertised to the downstream peers? Won't the second advertisement (if both
are sent) be taken as an implict withdraw by the other peers? I thus dont
think its an issue local to the box implementing multi-path.

> Hence there is no obvious interoperability problems in mutlipath as
> such.

I see an obvious interoperability issue because the routes which are used
and advertised by this particular router directly affects the other routers
(downstream). Moreover i need a mechanism to formally announce BGP ECMP
routes to the other peers.

OR am i missing something.

> What may be possibly needed to achive multipath in a few BGP deployment
> scenarios is a way to receive more then one path for a given net. In

Exactly.

> ipv4 AF those usually will be lost on reflectors. One possible way to
> address that issue is presented in: draft-walton-bgp-add-paths-01.txt,
> but I think there indeed could be more work needed on this ground.

I have yet to go through this.

>
> > There are a lot of open issues which need to be resolved.
> >
> > - Till what stage should the decision process be run for selecting ECMP
BGP
> > routes. Till their IGP costs?
>
> Notice that IGP cost is important for IBGP multipath, but for a change
> can be With no risk ignored for networks running mpls or any other
> flavour of bgp free core.

I couldnt get you.

>
> > - What should the next hop for these ECMP BGP routes be kept as?
>
> As we advertise the best one anyway next hop is not changed. Even
> advertising multiple paths (or just multiple next hops for multipaths)
> those should remain unchanged.

Right. But we need to formalize it.

Then there can be some issues when RRs are deployed.

Thanks,
Manav

Date: Mon, 21 Apr 2003 15:13:45 +0200
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP ECMP
Sender: [email-masked]

Hi Manav,

> Some vendors seem to allow multiple BGP routes to be installed in the
> Loc-RIB for doing load balancing.  I was not able to find any IETF/non IETF
> draft/standard which talks about this and am interested in pursuing this.

Before I comment on some your questions posted I think it is worth to
keep in mind that until now most of those implementations you may be
refering to treat multipath as a local to the box feature. As far as
advertisements to i/eBGP peers only best path is advertised as usual.
Hence there is no obvious interoperability problems in mutlipath as
such. 

What may be possibly needed to achive multipath in a few BGP deployment
scenarios is a way to receive more then one path for a given net. In
ipv4 AF those usually will be lost on reflectors. One possible way to
address that issue is presented in: draft-walton-bgp-add-paths-01.txt,
but I think there indeed could be more work needed on this ground. 

> There are a lot of open issues which need to be resolved.
> 
> - Till what stage should the decision process be run for selecting ECMP BGP
> routes. Till their IGP costs? 

Notice that IGP cost is important for IBGP multipath, but for a change
can be With no risk ignored for networks running mpls or any other
flavour of bgp free core.

> - What should the next hop for these ECMP BGP routes be kept as?

As we advertise the best one anyway next hop is not changed. Even
advertising multiple paths (or just multiple next hops for multipaths)
those should remain unchanged. 

> - We need to exercise some caution as the packets here (unlike as in IGPs)
> can go outside the AS and therefore cause huge differences in delay/cost
> over "n" available paths.

Sure. I am aware that some implementations allow ebgp multipath over any
paths with different AS-PATHs, some may offer ignoring AS_PATHs only by
non-transit providers. In any case this is again local decision.

> - We need to come out with an interoperable scheme between different
> vendors.

If you mean for passing mutliple paths via RRs - I agree. Just for
selection of mutlipath candidates on a given box - I am not sure.
 
R.

Date: Mon, 21 Apr 2003 16:05:57 +0530
From: Manav Bhatia <[email-masked]>
Subject: BGP ECMP
To: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hello,
Some vendors seem to allow multiple BGP routes to be installed in the
Loc-RIB for doing load balancing.  I was not able to find any IETF/non IETF
draft/standard which talks about this and am interested in pursuing this.

There are a lot of open issues which need to be resolved.

- Till what stage should the decision process be run for selecting ECMP BGP
routes. Till their IGP costs? Till the point where we compare the router
IDs, etc. We need to come up with a deterministic behavior to decide how
and what BGP routes will be considered equal.
- What should the next hop for these ECMP BGP routes be kept as?
- How to advertise these multiple routes to other BGP peers, etc?
- We need to exercise some caution as the packets here (unlike as in IGPs)
can go outside the AS and therefore cause huge differences in delay/cost
over "n" available paths.
- We need to come out with an interoperable scheme between different
vendors.

This is just a tentative list of issues which we need to ponder into.

Will the IDR community be interested in working over this?

Thanks,
Manav
----
Senior Software Engineer
Samsung India Software Operations
Bangalore - 560 001
+91-80-5550555/6 (1120)

From: "Joris Dobbelsteen" <[email-masked]>
To: "'IDR WG (E-mail)'" <[email-masked]>
Subject: RE: Issue 19) Security Considerations 
Date: Mon, 14 Apr 2003 23:32:56 +0200
Importance: Normal
Sender: [email-masked]

- Joris

>+discourage IPSEC usage for BGP.

content-class: urn:content-classes:message
Subject: Minutes of the IDR working meeting at IETF 56
Date: Mon, 14 Apr 2003 01:15:20 -0400
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Wednesday, March 19 1530-1730
=============================

CHAIRS: Sue Hares ([email-masked])
	Yakov Rekhter ([email-masked])

The following was the agenda for the IDR meeting
on 3/19/2003. 

AGENDA:

 1530-1545 Administrivia (Yakov Rekhter, Sue Hares)

            Agenda Bashing
            Minutes
            Blue Sheets
            WG Document Status 

 15:45-16:10 Flexible BGP Communities (Andrew Lange)

    http://www.ietf.org/internet-drafts/draft-lange-flexible-bgp-communities-00.txt

 16:10-16:25 BGP Security Vulnerabilities Analysis (Sandy Murphy)

    http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt

===========

   1) Administrivia:

	WG document status: 
	
	The Base BGP protocol specification is complete.  The editor's thanks
	go to Andrew Lange.  
		draft-ietf-idr-bgp4-19.txt has incorporated all the comments
		we have received. draft-ietf-idr-bgp4-20.txt includes a few
		more editorial changes.

		We have completed last call the document.  The resulting document
		will be forwarded to IESG.

	This document goes with a package of documents that detail the 
	BGP4: 
		1) draft-ietf-idr-bgp4-20.txt 
		2) draft-ietf-idr-bgp4-mib-10.txt (version 1 MIB)
		3) BGP security analysis 
			draft-murphy-bgp-vuln-02.txt which will be re-issued as
			draft-ietf-idr-bgp4-vuln-01.txt

	The draft-ietf-idr-bgp4-mib-10.txt will be issued lasted call
	on the mail list which ends on 3/24.

	The BGP security analysis document needs to be reviewed and comments
	sent ASAP. 

	And a group of reports for the IESG: 
		1)  BGP-4 Protocol Analysis (Dave Meyer, Keyur Patel)
		2) Experience with the BGP-4 Protocol 
		    (Danny McPherson, Keyur Patel) 

		3) BGP implementation report 
		    (Alvaro Retano) 

	Will be uploaded as idr documents.  Please comment on
	these documents.

B) 15:46 -16:10 Flexible BGP communities

	Andrew Lange gave a presentation on BGP communities in
		BGP Flexible Communities.ppt

	A discussion ensued afterward containing the following points:
	
	a) Should this specification supercede the base communities,
	   the Extended communities or should this document only include
	   communities not specified in these two drafts?

	    Several people (Enke Chen, Yakov Rekhter) felt that it imposed
	    a deployment burden if the draft superceded these two document.
	    Additional discussion of this point

	b) Should this work continue.  
	    Several people felt this work was useful. Additional feedback
	    was given to the author.  Additional discussion will continue
	    on the list. 

c) 16:10-16:25 BGP Security Vulnerabilities Analysis (Sandy Murphy)

    http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt

    Sandy present the slides idr.vulnerabilities.ppt
    After the presentation, a discussion about the drat continued with 
    the following points:

	a) The use of unconfigured peers in the base draft.
	b) The use of TTL as an alternative security mechanisms for
	   unconfigured peers,

	c) Do we include failure scenarios where a BGP
 	   Speaker doesn't send info it was supposed to send.  
	     eg not sending a WITHDRAW

	d) We need to make sure the draft is clear that there
 	   are two types of attacks:
             1) Spoofs/session interrupts/disruptive attacks.
             2) Poison info attacks (sending malicious info)

    On Unconfigured peers (point a), the discussion centered around
    re-opening the issue of unconfigured peers.  The majority of the
    working group did not want to re-open the issue.  The general
    consensus was that an explanation for unconfigured peers be added
    to the experience draft.  

    On item b, the use of TTL as a security issue, Yakov pointed out
    that the TTL document is not even a working group document.  We
    are progressing BGP (in 3 documents base, mib, security document)
    on what is.  Sandy Murphy pointed out that TTL doesn't work
    with EBGP multi-hop.  Vijay agreed with Sandy, but indicated that
    TTL works for most cases.  Sandy pointed out that security analysis
    are required to look security in all cases.  The TTL document
    is new work and will not be discussed until the Routing ADs lift
    the hold on new work.

    On item c, the consensus was to leave this out because it
    contains no information.  There is no way to differentiate between a bug
    in an implementation and an attack for these "attacks of omission".

    On item d, Sandy Murphy indicated that it was included in the draft.
    Comments are welcomed to clarify the text.

To: "Krishnan, Vijay G." <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-bgp-identifier-02.txt 
Date: Tue, 08 Apr 2003 11:16:13 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Vijay:

> Message-ID: <[email-masked]>
> From: "Krishnan, Vijay G." <[email-masked]>
> To: "'Enke Chen'" <[email-masked]>
> Cc: [email-masked]
> Subject: RE: draft-ietf-idr-bgp-identifier-02.txt 
> Date: Tue, 8 Apr 2003 11:37:32 -0400 
> 
> Hi Enke,
> 
> >Please see the following text in the Remarks Section of the draft:
> >
> >   A BGP speaker that supports the AS-wide Unique BGP Identifier can not
> >   share a BGP Identifier with its external neighbor until the remote
> >   BGP speaker is upgraded with software that supports the proposed
> >   revisions.
> 
> Is there be a way of knowing whether the peer supports AS-wide unique ID? I
> didn't see any new capability in the draft. 

BGP capability is good at dealing with optinal features. However, it does not
seem to help in this case as the BGP identifier is mandatory:

     - For an existing BGP speaker that has a globally unique identifier,
       there is no issue.

     - For an ipv6-only speaker, if the identifier is the same as that
       of the remote speaker, the session will not be up until the software
       is upgraded (regarless of whether a new capability is introduced).

Regards,

-- Enke

Date: Tue, 8 Apr 2003 11:52:48 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Attention implementors of draft-ietf-idr-bgp4-mib-10
Sender: [email-masked]

As part of working group last call, we are going to need an implementation
report.  If you could contact me so we can at least get parties
lined up for this, it would be handy.

As part of working group last call, the OPS folks pointed out a 
potentially worrisome issue:

Two previously documented traps, bgpEstablished and bgpBackwardTransition
were changed from the RFC 1657 definition to include in its OBJECTS
clause the bgpPeerRemoteAddr object.  This is apparently not kosher
since the INDEX of the two documented objects includes the information
included in that particular object.  

Removing the bgpPeerRemoteAddr object appears to be the correct
answer, however it potentially will affect deployed implementations
that implement the BGP traps.

I am working with the OPS folks to determine what our proper course
of action should be.  

If you have implemented these traps, please contact me so I can help
direct your concerns.  Given the operational consequences of these
objects, I would like to keep this as smooth as possible.

-- 
Jeff Haas 
NextHop Technologies

From: "Krishnan, Vijay G." <[email-masked]>
To: "'Enke Chen'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-idr-bgp-identifier-02.txt 
Date: Tue, 8 Apr 2003 11:37:32 -0400 
Sender: [email-masked]

Hi Enke,

>Please see the following text in the Remarks Section of the draft:
>
>   A BGP speaker that supports the AS-wide Unique BGP Identifier can not
>   share a BGP Identifier with its external neighbor until the remote
>   BGP speaker is upgraded with software that supports the proposed
>   revisions.

Is there be a way of knowing whether the peer supports AS-wide unique ID? I
didn't see any new capability in the draft. 

regards
Vijay

Date: Tue, 8 Apr 2003 09:45:30 -0400
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: MIB V2: PathAttrIndex
Sender: [email-masked]

Pedro,

On Mon, Apr 07, 2003 at 04:22:18PM -0700, Pedro Roque Marques wrote:
> It isn't clear...

I'll work with you offline to clean this up a bit.
However, suggestions on-list are always welcome.

> Specially because some of the tables refer to "received" attributes
> and "advertised" attributes.
> 
> When policy is in use a given route (the tuple <routing-table-id, prefix,
> prefixlen, source router-id>) can point to:
> 
>  - a received set of attributes.
>  - a current set of attributes
>  - a set of attributes per advertised peer.
> 
> So in order for your idea to work, i believe you need to do have the
> following mapping:
> 
>  - route 4-tuple -> Loc-Rib attribute set index.
>  - route 4-tuple -> Rib-in attribute set index.
>  - <routing-table-id, prefix, prefixlen, peer> -> Rib-out attribute
> set index.

I believe that particular table can already accomodate these mappings.  
Essentially, this is just a path attributes database.  You can place
entries for the received, used and advertised path attributes in
here.  The wording in the DESCRIPTIONs is clearly incorrect though.

For example, I'm sure you're noting:
    bgpM2PathAttrTable OBJECT-TYPE
        DESCRIPTION
            "Provides per advertised network-prefix attribute data,
             as advertised over a peering session."

> While the implementations i know of do keep information internally in
> an attribute database it is not always easy to make that index
> externally availiable.
> 
> i.e. afaik it will be required to create a mapping of external index
> -> internal db entry.

Right.  Some sort of index will need to be maintained to map from
an advertised ID to the internal data structure.  Do we consider this
overhead to be excessive?

> One must make sure that this element is not reused immediatly... the
> internal index is often reused immediatly

Exactly.

> The idea is valid... however there is some overhead involved and i
> believe you don't have the mappings necessary to support it.

I think the tables have the appropriate information, however the 
DESCRIPTIONs need work.  If I'm missing something, could you point
out a specific example?

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 08 Apr 2003 09:37:28 +0200
From: Christian Kaas-Petersen <[email-masked]>
To: [email-masked]
Subject: Re: VPN encoding
Sender: [email-masked]

RFC2547bis is not an RFC, but a draft. This draft can be found on
www.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-03.txt.

Christian

Tim Griffin wrote:

>"bis" means "twice" in latin.  in portuguese, it can be shouted after 
>a performance and means "encore"  
>
>Mareline Sheldon wrote:
>
>>Shankar,
>>I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
>>what is this?
>>
>>Thanks,
>>Mareline S.
>>
>>--- Shankar Ananthanarayanan Kambat <[email-masked]> wrote:
>>
>>>Second version of original spec with updated sections
>>>
>>>- Shankar K A
>>>
>>>
>>>From: Mareline Sheldon [mailto:[email-masked]]
>>>Sent: Monday, April 07, 2003 10:46 AM
>>>To: [email-masked]
>>>Subject: RE: VPN encoding
>>>
>>>
>>>Hello,
>>>Thanks a lot for the info Vijay!
>>>
>>>Can anybody please explain me what the "bis" in RFC 2547bis stands for?
>>>
>>>I have come across this term "bis" on a number of occasions and i am
>>>never able to understand
>>>what it truly means.
>>>
>>>Can anybody please shed some light on that?
>>>
>>>Thanks,
>>>Mareline S.
>>>
>>>----- Original Message -----
>>>From: "Krishnan, Vijay G." <[email-masked]>
>>>To: "'Mareline Sheldon'" <[email-masked]>; <[email-masked]>
>>>Sent: Saturday, April 05, 2003 2:56 AM
>>>Subject: RE: VPN encoding
>>>
>>>
>>>>Mareline,
>>>>
>>>>Encoding of label in BGP updates - RFC3107
>>>>Encoding Route Distnguisher - RFC2547bis draft
>>>>
>>>>-Vijay
>>>>
>>>>
>>>
>>>__________________________________________________
>>>Do you Yahoo!?
>>>Yahoo! Tax Center - File online, calculators, forms, and more
>>>http://tax.yahoo.com
>>>
>>>>**************************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.
>>>
>>>****************************************************************************************
>>>
>>__________________________________________________
>>Do you Yahoo!?
>>Yahoo! Tax Center - File online, calculators, forms, and more
>>http://tax.yahoo.com
>>

To: Manav Bhatia <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-bgp-identifier-02.txt 
Date: Mon, 07 Apr 2003 21:38:20 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Manav:

> Date: Tue, 08 Apr 2003 08:31:07 +0530
> From: Manav Bhatia <[email-masked]>
> Subject: Re: draft-ietf-idr-bgp-identifier-02.txt
> To: [email-masked]
> Cc: [email-masked]
> Reply-To: Manav Bhatia <[email-masked]>
> Message-id: <[email-masked]>
> 
> Hi Jenny,
> Thanks for the comments. Please look inline.
> 
> > > - why is this restriction placed only for the internal peers. What if i
> > > receive an OPEN message from an external peer with the same BGP ID as
> mine?
> >
> > This draft relaxes the "uniqueness" requirement for a BGP Identifier
> > so that the BGP Identifiers only needs to be unque inside its own AS.
> > It's ok to receive the same BGP ID from an external peer as long as
> > both BGP speaker support the AS-wide Unique BGP Identifier.
> 
> Hmmm .. it means that i may have some problems if my peer doesnt implement
> this draft and i try to peer with another one which does and if both happen
> to share the same BGP ID.

Please see the following text in the Remarks Section of the draft:

   A BGP speaker that supports the AS-wide Unique BGP Identifier can not
   share a BGP Identifier with its external neighbor until the remote
   BGP speaker is upgraded with software that supports the proposed
   revisions.

> 
> Additionally, are you sure that this draft does not raise any security
> concerns [sec 6] because you are relaxing the checks on BGP ID?

No, we do not see any security issue.

> 
> > > Can it be re-phrased. I got lost! :-)
> >
> > This is not a re-phrase, just my attempt to explain the paragraph: ;-)
> >
> > In the route selection process:
> >
> > . since the BGP Identifier is not used to compare a route received from
> >   an internal neighbor and a route from an external neighbor, therefore,
> >   it's ok to have BGP Identifier unique only with the AS.
> >
> > . if two routes are received from BGP speakers with identical BGP
> Identifier,
> >   the neighbor with lower IP address is prefered. Again, there should not
> >   be a problem having only AS-wide BGP Identifier.
> 
> This makes it a lot better. Can it be put this way in the draft.

We will try to make the text clearer in the next revision.

Regards,

-- Enke

Date: Tue, 08 Apr 2003 08:31:07 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: draft-ietf-idr-bgp-identifier-02.txt
To: [email-masked]
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hi Jenny,
Thanks for the comments. Please look inline.

> > - why is this restriction placed only for the internal peers. What if i
> > receive an OPEN message from an external peer with the same BGP ID as
mine?
>
> This draft relaxes the "uniqueness" requirement for a BGP Identifier
> so that the BGP Identifiers only needs to be unque inside its own AS.
> It's ok to receive the same BGP ID from an external peer as long as
> both BGP speaker support the AS-wide Unique BGP Identifier.

Hmmm .. it means that i may have some problems if my peer doesnt implement
this draft and i try to peer with another one which does and if both happen
to share the same BGP ID.

Additionally, are you sure that this draft does not raise any security
concerns [sec 6] because you are relaxing the checks on BGP ID?

> > Can it be re-phrased. I got lost! :-)
>
> This is not a re-phrase, just my attempt to explain the paragraph: ;-)
>
> In the route selection process:
>
> . since the BGP Identifier is not used to compare a route received from
>   an internal neighbor and a route from an external neighbor, therefore,
>   it's ok to have BGP Identifier unique only with the AS.
>
> . if two routes are received from BGP speakers with identical BGP
Identifier,
>   the neighbor with lower IP address is prefered. Again, there should not
>   be a problem having only AS-wide BGP Identifier.

This makes it a lot better. Can it be put this way in the draft.

Thanks,
Manav

Date: Mon, 7 Apr 2003 16:22:18 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: MIB V2: PathAttrIndex
Sender: [email-masked]

Jeff,

> On Thu, Apr 03, 2003 at 06:52:55PM -0800, Pedro Roque Marques wrote:
> >     bgpM2PathAttrIndex OBJECT-TYPE

[...]

> > If i understand correctly, the intent here is to create an index that
> > can replace the full "key" on an NLRI.
> 
> In the original bgp mib, we have the following:
>         bgp4PathAttrEntry OBJECT-TYPE
>             SYNTAX     Bgp4PathAttrEntry
>             MAX-ACCESS not-accessible
>             STATUS     current
>             DESCRIPTION
>                     "Information about a path to a network."
>             INDEX { bgp4PathAttrIpAddrPrefix,
>                     bgp4PathAttrIpAddrPrefixLen,
>                     bgp4PathAttrPeer            }
>             ::= { bgp4PathAttrTable 1 }
> 
> The sequence that then follows contains all bgp-4 (rfc 1771) defined
> path attributes.
> 
> When you do a table walk, this is an amazing amount of repeated
> information in some cases, especially if you just want the prefixes.
> 
> In the v2MIB, we simply take path attributes out and refer to their
> existance in a separate table.
> 
> > However managing and assigning
> > this index is imho a very large overhead.
> 
> I had hoped not.
> 
> > Perhaps i'm being dense,
> 
> Or just as likely, the wording isn't clear.

It isn't clear...

Specially because some of the tables refer to "received" attributes
and "advertised" attributes.

When policy is in use a given route (the tuple <routing-table-id, prefix,
prefixlen, source router-id>) can point to:

 - a received set of attributes.
 - a current set of attributes
 - a set of attributes per advertised peer.

So in order for your idea to work, i believe you need to do have the
following mapping:

 - route 4-tuple -> Loc-Rib attribute set index.
 - route 4-tuple -> Rib-in attribute set index.
 - <routing-table-id, prefix, prefixlen, peer> -> Rib-out attribute
set index.

> The general thought is that any path attributes set that is received
> by a BGP speaker generally must be stored as a complete entity by the
> application in some internal form - essentially a path attributes database.
> The individual components may be stored in different fashions to
> allow for sharing of common sets of items for space-saving purposes, but
> you still need to have the original path attribute set available.
> 
> Thus, this index is simply a unique value for a given path attribute
> set within your implementation.  

OK.

> 
> I had *hoped* that this method was common enough in various implementations
> to make this something that greatly eases implementation of the
> table by utilizing a pre-existing internal data structure index.  If
> this isn't the case, then these tables need serious re-working.

While the implementations i know of do keep information internally in
an attribute database it is not always easy to make that index
externally availiable.

i.e. afaik it will be required to create a mapping of external index
-> internal db entry.

> As for the re-usability, you should be able to re-use it, but you ideally
> will need to wait "long enough" to satisfy outstanding queries.  Something
> about this timeliness should probably be mentioned in the mib.

One must make sure that this element is not reused immediatly... the
internal index is often reused immediatly

> 
> As the PathAttrIndex is used simply for grouping path attributes
> (essentially to point into a grouping of path attributes in your path
> attributes database), hopefully this isn't true.  However, as I've stated
> above, there is the base assumption that most implementations have some
> mechanism to pre-group sets of path attributes together in the database
> as they have been received.  If this is true, then indexing may add
> some overhead, but hopefully not a horrible amount.
> 

The idea is valid... however there is some overhead involved and i
believe you don't have the mappings necessary to support it.

  Pedro.

Date: Mon, 07 Apr 2003 15:51:49 -0400
From: Tim Griffin <[email-masked]>
Organization: AT&T Labs Research
To: Mareline Sheldon <[email-masked]>
Cc: Shankar Ananthanarayanan Kambat <[email-masked]>, [email-masked]
Subject: Re: VPN encoding
Sender: [email-masked]

"bis" means "twice" in latin.  in portuguese, it can be shouted after 
a performance and means "encore"  

Mareline Sheldon wrote:
> 
> Shankar,
> I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
> what is this?
> 
> Thanks,
> Mareline S.
> 
> --- Shankar Ananthanarayanan Kambat <[email-masked]> wrote:
> > Second version of original spec with updated sections
> >
> > - Shankar K A
> >
> >
> > From: Mareline Sheldon [mailto:[email-masked]]
> > Sent: Monday, April 07, 2003 10:46 AM
> > To: [email-masked]
> > Subject: RE: VPN encoding
> >
> >
> > Hello,
> > Thanks a lot for the info Vijay!
> >
> > Can anybody please explain me what the "bis" in RFC 2547bis stands for?
> >
> > I have come across this term "bis" on a number of occasions and i am
> > never able to understand
> > what it truly means.
> >
> > Can anybody please shed some light on that?
> >
> > Thanks,
> > Mareline S.
> >
> > ----- Original Message -----
> > From: "Krishnan, Vijay G." <[email-masked]>
> > To: "'Mareline Sheldon'" <[email-masked]>; <[email-masked]>
> > Sent: Saturday, April 05, 2003 2:56 AM
> > Subject: RE: VPN encoding
> >
> >
> > > Mareline,
> > >
> > > Encoding of label in BGP updates - RFC3107
> > > Encoding Route Distnguisher - RFC2547bis draft
> > >
> > > -Vijay
> > >
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> > > **************************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.
> >
> > ****************************************************************************************
> >
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com

Date: Mon, 07 Apr 2003 19:08:58 +0530
From: Manav Bhatia <[email-masked]>
Subject: draft-ietf-idr-bgp-identifier-02.txt
To: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hi,
1> Section 4.2. Open Message Error  Handling states that
'If the BGP Identifier field of the OPEN message is zero, or if
 it is the same as the BGP Identifier of the local BGP speaker
 and the message is from an internal peer, then the Error Subcode
 is set to "Bad BGP Identifier"'

- why is this restriction placed only for the internal peers. What if i
receive an OPEN message from an external peer with the same BGP ID as mine?

2> Typo in section 5.
AGGREAGTOR needs to be replaced with AGGREGATOR

3> A paragraph in section 5 states
"In the route selection, where the BGP Identifier is not used
in comparing a route from an internal neighbor and a route from
an external neighbor. In addition, routes from BGP speakers with
identical BGP Identifiers have been dealt with (e.g., parallel
BGP sessions between two BGP speakers)"

Can it be re-phrased. I got lost! :-)

Regards,
Manav

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-02.txt
Date: Mon, 07 Apr 2003 07:09:47 -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		: AS-wide Unique BGP Identifier for BGP-4
	Author(s)	: E. Chen, J. Yuan
	Filename	: draft-ietf-idr-bgp-identifier-02.txt
	Pages		: 4
	Date		: 2003-4-4
	
To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue.

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

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

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

--OtherAccess--

--NextPart--

Date: Sun, 6 Apr 2003 22:43:34 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: RE: VPN encoding
To: Shankar Ananthanarayanan Kambat <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Shankar,
I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
what is this?

Thanks,
Mareline S.

--- Shankar Ananthanarayanan Kambat <[email-masked]> wrote:
> Second version of original spec with updated sections
> 
> - Shankar K A
> 
> 
> From: Mareline Sheldon [mailto:[email-masked]] 
> Sent: Monday, April 07, 2003 10:46 AM
> To: [email-masked]
> Subject: RE: VPN encoding
> 
> 
> Hello,
> Thanks a lot for the info Vijay!
> 
> Can anybody please explain me what the "bis" in RFC 2547bis stands for?
> 
> I have come across this term "bis" on a number of occasions and i am
> never able to understand
> what it truly means.
> 
> Can anybody please shed some light on that?
> 
> Thanks,
> Mareline S.
> 
> ----- Original Message ----- 
> From: "Krishnan, Vijay G." <[email-masked]>
> To: "'Mareline Sheldon'" <[email-masked]>; <[email-masked]>
> Sent: Saturday, April 05, 2003 2:56 AM
> Subject: RE: VPN encoding
> 
> 
> > Mareline,
> > 
> > Encoding of label in BGP updates - RFC3107
> > Encoding Route Distnguisher - RFC2547bis draft
> > 
> > -Vijay
> > 
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
> > **************************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.
> 
> ****************************************************************************************
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

content-class: urn:content-classes:message
Subject: RE: VPN encoding
Date: Mon, 7 Apr 2003 11:04:52 +0530
From: "Shankar Ananthanarayanan Kambat" <[email-masked]>
To: "Mareline Sheldon" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-ac5aa6c9-4ae4-4e54-95ce-1720522f1050
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Second version of original spec with updated sections

- Shankar K A

-----Original Message-----
From: Mareline Sheldon [mailto:[email-masked]]=20
Sent: Monday, April 07, 2003 10:46 AM
To: [email-masked]
Subject: RE: VPN encoding

Hello,
Thanks a lot for the info Vijay!

Can anybody please explain me what the "bis" in RFC 2547bis stands for?

I have come across this term "bis" on a number of occasions and i am
never able to understand
what it truly means.

Can anybody please shed some light on that?

Thanks,
Mareline S.

----- Original Message -----=20
From: "Krishnan, Vijay G." <[email-masked]>
To: "'Mareline Sheldon'" <[email-masked]>; <[email-masked]>
Sent: Saturday, April 05, 2003 2:56 AM
Subject: RE: VPN encoding

> Mareline,
>=20
> Encoding of label in BGP updates - RFC3107
> Encoding Route Distnguisher - RFC2547bis draft
>=20
> -Vijay
>=20
>=20

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

------=_NextPartTM-000-ac5aa6c9-4ae4-4e54-95ce-1720522f1050
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-ac5aa6c9-4ae4-4e54-95ce-1720522f1050--

Date: Sun, 6 Apr 2003 22:16:03 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: RE: VPN encoding
To: [email-masked]
Sender: [email-masked]

Hello,
Thanks a lot for the info Vijay!

Can anybody please explain me what the "bis" in RFC 2547bis stands for?

I have come across this term "bis" on a number of occasions and i am never able to understand
what it truly means.

Can anybody please shed some light on that?

Thanks,
Mareline S.

----- Original Message ----- 
From: "Krishnan, Vijay G." <[email-masked]>
To: "'Mareline Sheldon'" <[email-masked]>; <[email-masked]>
Sent: Saturday, April 05, 2003 2:56 AM
Subject: RE: VPN encoding

> Mareline,
> 
> Encoding of label in BGP updates - RFC3107
> Encoding Route Distnguisher - RFC2547bis draft
> 
> -Vijay
> 
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

From: "Krishnan, Vijay G." <[email-masked]>
To: "'Mareline Sheldon'" <[email-masked]>, [email-masked]
Subject: RE: VPN encoding
Date: Fri, 4 Apr 2003 16:26:00 -0500 
Sender: [email-masked]

Mareline,

Encoding of label in BGP updates - RFC3107
Encoding Route Distnguisher - RFC2547bis draft

-Vijay

-----Original Message-----
From: Mareline Sheldon [mailto:[email-masked]]
Sent: Friday, April 04, 2003 10:46 AM
To: [email-masked]
Subject: VPN encoding

Hello,
Which IETF draft/RFC explains how the MPLS/VPN information is to be encoded
inside the BGP
UPDATE message? I was unable to find this information.

What i want to know is basically which standard tells an implementor how to
put the MPLS
label, then the Route distinguisher, etc.

Any pointers in this will be really really appreciated !!!

Thanks,
Mareline S.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

Date: Fri, 4 Apr 2003 11:45:37 -0500
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: MIB V2: PathAttrIndex
Sender: [email-masked]

Pedro,

On Thu, Apr 03, 2003 at 06:52:55PM -0800, Pedro Roque Marques wrote:
>     bgpM2PathAttrIndex OBJECT-TYPE
>         SYNTAX     Unsigned32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION
>             "This value is a unique index for the per-NLRI entry
>              in the bgpM2PeerAttrTable.  It is assigned by the
>              agent at the point of creation of the bgpM2PeerAttrTable
>              row entry.  While its value is guaranteed to be unique
>              at any time, it is otherwise opaque to the management
>              application with respect to its value or the contiguity
>              of bgpM2PeerAttrIndex row instance values across rows
>              of the bgpM2PeerAttrTable.  It is used to provide an
>              index structure for other tables whose data is logically
>              per-peer, per-NLRI."
>         ::= { bgpM2NlriEntry 8 }
> 
>   I'm assuming that in the context above:
>   s/bgpM2PeerAttrTable/bgpM2NlriTable/

My typo.  Thanks for pointing it out.

> If i understand correctly, the intent here is to create an index that
> can replace the full "key" on an NLRI.

In the original bgp mib, we have the following:
        bgp4PathAttrEntry OBJECT-TYPE
            SYNTAX     Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION
                    "Information about a path to a network."
            INDEX { bgp4PathAttrIpAddrPrefix,
                    bgp4PathAttrIpAddrPrefixLen,
                    bgp4PathAttrPeer            }
            ::= { bgp4PathAttrTable 1 }

The sequence that then follows contains all bgp-4 (rfc 1771) defined
path attributes.

When you do a table walk, this is an amazing amount of repeated
information in some cases, especially if you just want the prefixes.

In the v2MIB, we simply take path attributes out and refer to their
existance in a separate table.

> However managing and assigning
> this index is imho a very large overhead.

I had hoped not.

> Perhaps i'm being dense,

Or just as likely, the wording isn't clear.

> but it seems to me that the overhead is
> non-trivial. Each path on any table needs to have an index, and that
> index cannot be reused when the route is deleted... meaning that one
> needs to have a mechanism to reverse lookup this index to path
> mapping.

The general idea is this.
Please take note of the following tables:
    bgpM2PathAttrTable,
    bgpM2AsPathTable,
    bgpM2PathAttrUnknownTable,
    bgpM2PathAttrOriginatorIdTable,
    bgpM2PathAttrClusterTable,
    bgpM2PathAttrCommTable,
    bgpM2PathAttrExtCommTable,
    bgpM2LinkLocalNextHopTable,

All use the bgpM2PathAttrIndex.

The general thought is that any path attributes set that is received
by a BGP speaker generally must be stored as a complete entity by the
application in some internal form - essentially a path attributes database.
The individual components may be stored in different fashions to
allow for sharing of common sets of items for space-saving purposes, but
you still need to have the original path attribute set available.

Thus, this index is simply a unique value for a given path attribute
set within your implementation.  

I had *hoped* that this method was common enough in various implementations
to make this something that greatly eases implementation of the
table by utilizing a pre-existing internal data structure index.  If
this isn't the case, then these tables need serious re-working.

If the idea happens to match your internal implementation and the above
wording needs tweaking, I would welcome suggestions with open arms.

As for the re-usability, you should be able to re-use it, but you ideally
will need to wait "long enough" to satisfy outstanding queries.  Something
about this timeliness should probably be mentioned in the mib.

> I would seem to me that the tradeof is to make
> <instance, prefix, lenght, peer-index> key for all the other tables
> that use this index. correct ?

As the PathAttrIndex is used simply for grouping path attributes
(essentially to point into a grouping of path attributes in your path
attributes database), hopefully this isn't true.  However, as I've stated
above, there is the base assumption that most implementations have some
mechanism to pre-group sets of path attributes together in the database
as they have been received.  If this is true, then indexing may add
some overhead, but hopefully not a horrible amount.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 4 Apr 2003 07:46:18 -0800 (PST)
From: Mareline Sheldon <[email-masked]>
Subject: VPN encoding
To: [email-masked]
Sender: [email-masked]

Hello,
Which IETF draft/RFC explains how the MPLS/VPN information is to be encoded inside the BGP
UPDATE message? I was unable to find this information.

What i want to know is basically which standard tells an implementor how to put the MPLS
label, then the Route distinguisher, etc.

Any pointers in this will be really really appreciated !!!

Thanks,
Mareline S.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

Date: Thu, 3 Apr 2003 18:52:55 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: MIB V2: PathAttrIndex
Sender: [email-masked]

Jeff,
You define...

    bgpM2PathAttrIndex OBJECT-TYPE
        SYNTAX     Unsigned32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
            "This value is a unique index for the per-NLRI entry
             in the bgpM2PeerAttrTable.  It is assigned by the
             agent at the point of creation of the bgpM2PeerAttrTable
             row entry.  While its value is guaranteed to be unique
             at any time, it is otherwise opaque to the management
             application with respect to its value or the contiguity
             of bgpM2PeerAttrIndex row instance values across rows
             of the bgpM2PeerAttrTable.  It is used to provide an
             index structure for other tables whose data is logically
             per-peer, per-NLRI."
        ::= { bgpM2NlriEntry 8 }

  I'm assuming that in the context above:
  s/bgpM2PeerAttrTable/bgpM2NlriTable/

If i understand correctly, the intent here is to create an index that
can replace the full "key" on an NLRI.  However managing and assigning
this index is imho a very large overhead.

Perhaps i'm being dense, but it seems to me that the overhead is
non-trivial. Each path on any table needs to have an index, and that
index cannot be reused when the route is deleted... meaning that one
needs to have a mechanism to reverse lookup this index to path
mapping.

I would seem to me that the tradeof is to make
<instance, prefix, lenght, peer-index> key for all the other tables
that use this index. correct ?

I believe i'd rather go for this second option.

  Pedro.

To: "Joris Dobbelsteen" <[email-masked]>
Cc: "'IDR WG (E-mail)'" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Thu, 03 Apr 2003 09:36:06 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Joris,

Curtis

@@ -901,6 +902,79 @@
 
 5.  References

Date: Thu, 3 Apr 2003 00:06:41 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: slides from IETF idr meeting
Cc: [email-masked]
Sender: [email-masked]

Turns out that the idr list has a filter that catches base64 encoded
files and that's what happened to my messages.

So my slides from this IETF can be retrieved from ftp.tislabs.com
in /pub/rpsec/Vulnerabilitiesupdate.idr.19Mar2003.ppt

--Sandy

Date: Wed, 2 Apr 2003 10:08:44 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-20.txt
Sender: [email-masked]

IDR folk,

On Tue, Apr 01, 2003 at 07:30:59AM -0800, Yakov Rekhter wrote:
>    The data structures and FSM described in this document are conceptual
>    and do not have to be implemented precisely as described here, as long
>    as the implementations support the described functionality and their
>    externally visible behavior is the same.

As I am about to begin further work on the BGP MIBv2, the above statement
has consequences for the MIB.  If the model is purely conceptual,
do we still want to track the various flags in the MIB for the FSM?
We currently track states.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 1 Apr 2003 11:30:16 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: context for talk and previous messages
Cc: [email-masked]
Sender: [email-masked]

I sent two messages to the list yesterday, the first containing my slides
and the second containing a correction of a typo in the first.  Only the
second made it to the list, so that message was pretty cryptic.

I tried again today, but it's been over an hour and still nothing on the list.

I suspect that "big" (200K) messages are getting shunted aside for human
oversight, and the human overseer is swamped.

So, just for context of my second message, here's the text part of my
first message that the second message corrects:

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

Here are the slides that I presented at the idr meeting.

Sue told me that she thought that some people did not have context for my 
talk.  I thought Sue suggested my slides from the Minneapolis meeting had 
that context, but those slides are focused on status and updates.  So, for 
those who need some background, here is the recent history of the 
discussions of the draft.

Dec 01 discussion of draft-ietf-murphy-bgp-secr-04.txt
    (decided to split that draft into two)
    www.ietf.org/proceedings/01dec/slides/idr-3/index.html
Mar 02 discussion of draft-murphy-bgp-vuln-00.txt (the vulnerabilities
    half of the ..-bgp-secr draft)
    http://www.merit.edu/mail.archives/idr/2002-04/msg00004.html
    (unfortunately, slides did not make it to the proceedings)
Jul 02 mentioned in status of documents, but no presentation
Nov 02 discussion of security, but no presentation
    (draft-murphy-bgp-protect-01.txt submitted, date change only)
(***  this is the line with the typo  - my message that made it to the list 
corrected ***
  ***  this to read "draft-murphy-bgp-vuln-01.txt"                   ***)
Mar 03 status report on changes in draft draft-murphy-bgp-vuln-02.txt
    (changes needed to bring into line with FSM)
    slides attached to this message

--Sandy 

To: [email-masked]
Subject: draft-ietf-idr-bgp4-20.txt
Date: Tue, 01 Apr 2003 07:30:59 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The -20 version contains several (minor) editorial fixes. In addition
to the editorial fixes it contains the following in the FSM section
(the text was proposed by the Routing ADs):

   The data structures and FSM described in this document are conceptual
   and do not have to be implemented precisely as described here, as long
   as the implementations support the described functionality and their
   externally visible behavior is the same.

Yakov.
------- Forwarded Message

Date:    Tue, 01 Apr 2003 06:49:45 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-20.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		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-20.txt
	Pages		: 86
	Date		: 2003-3-31
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco
l.

The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses.  This informa-
tion is sufficient to construct a graph of AS connectivity from which
routing loops may be pruned and some policy decisions at the AS level
may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.

Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy deci-
sions that can (and can not) be enforced using BGP. BGP can support
only the policies conforming to the destination-based forwarding
paradigm.

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

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-20.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-bgp4-20.txt
Date: Tue, 01 Apr 2003 06:49:45 -0500
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		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-20.txt
	Pages		: 86
	Date		: 2003-3-31
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses.  This informa-
tion is sufficient to construct a graph of AS connectivity from which
routing loops may be pruned and some policy decisions at the AS level
may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.

Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy deci-
sions that can (and can not) be enforced using BGP. BGP can support
only the policies conforming to the destination-based forwarding
paradigm.

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

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

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

--OtherAccess--

--NextPart--