Subject: Re: Communities
From: Philip Smith <[email-masked]>
To: Katia Linker <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 26 Dec 2001 21:36:02 +1000

Several ISPs use RFC1998 as a basis for their policies. And take a look at 
http://www.as3257.net/html/communities.htm for an extensive example.

philip
--

At 11:44 25/12/2001 +0200, Katia Linker wrote:

>Hello, all !
>Regards the Community attribute. Can somebody give me a real life
>uses (examples) of the communities except the well-known ones
>(NO_EXPORT, NO_ADVERTIZE and NO_EXPORT_SUBCONFED).
>     Thanks in advance.
>        Katya

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Route Flap Dampening
Date: Wed, 26 Dec 2001 10:31:34 +0200
Sender: [email-masked]

Hello, all !
Regards Route Flap Dampening (RFC 2439)
is there some easier way to implement this
extension ? Why RFC describes so many
MIBs for configuration while cisco, for example,
uses a less number of them ?
I'll be glad to have some references regards
this extension.
    Thanks in advance.
        Katya 

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Communities
Date: Tue, 25 Dec 2001 11:44:06 +0200
Sender: [email-masked]

Hello, all !
Regards the Community attribute. Can somebody give me a real life
uses (examples) of the communities except the well-known ones
(NO_EXPORT, NO_ADVERTIZE and NO_EXPORT_SUBCONFED).
    Thanks in advance.
       Katya 

Date: Mon, 24 Dec 2001 23:35:21 +0530
From: Anand Kumar Goenka <[email-masked]>
Organization: Motorola India Electronics Ltd.
To: [email-masked]
Subject: ATOMIC AGGREGATE Doubts
Sender: [email-masked]

I have some basic doubts regarding "ATOMIC AGGREGATE" attribute of BGP
as
mentioned in RFC1771.

Consider a case where a BGP speaker receives following overlapping
routes from one of
it's peers as follows.
150.1.0.0/16 - Path A
150.1.1.0/24 - Path B
Local BGP speaker selects the less specific route (150.1.0.0/16) and
advertises it to it's
Peers with ATOMIC AGGREGATE attribute.

- Does the local BGP speaker adds the ATOMIC AGGREGATE in the Path
  Attribute of  the less specific route (150.1.0.0/16) and then store
that route in it's
  local-RIB or it does so only while advertising the route to it's peers
??

- What happens when the less specific routes (150.1.0.0/16)
   is withdrawn by the BGP peer  which had earlier advertised that route
to local BGP
   speaker ?? Does the local BGP speaker need to re-install the more
specific route
   (150.1.1.0/24) in the  local-RIB and advertised to it's peers ??
(this is assuming the
   local  BGP speaker maintains the both less & more specific route in
corresponding
   Adj-RIB-In)

- What happens when the more specific routes (150.1.1.0/24)
   is withdrawn by the BGP peer  which had earlier advertised that route
to local BGP
   speaker ?? Does the local BGP speaker need to re-advertise the less
specific route
   (150.1.0.0/16) to it's peers without the ATOMIC ATTRIBUTE attribute
??

A quick response will be helpful.

Thanks,
Anand Goenka.

Date: Fri, 21 Dec 2001 14:42:57 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Minutes from December '01
Cc: [email-masked]
Sender: [email-masked]

If anyone has further comments or questions on
the minutes from IDR, please let me know by 12/26.
I will be sending in the Minutes to the IETF secretary
at that time.

Sue Hares

To: Susan Hares <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AS-wide Unique BGP Identifier 
Date: Thu, 20 Dec 2001 16:55:53 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue,

> Date: Thu, 20 Dec 2001 19:28:37 -0500
> To: Enke Chen <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: AS-wide Unique BGP Identifier
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> X-ECS-MailScanner: Found to be clean
> 
> Enke:
> 
> A blow by blow comparison of the drafts.  As your
> draft is stated below, I do not see the value of widening
> the BGP Identifier value.   Perhaps you can enlightening
> me as to the purpose of this proposed BGP change versus
> the BCP proposal from the IP v6 area.

Please note that this draft does *not* widen the BGP Identifier field.
That is the whole point of the draft.

> 
> Your draft would make the IP v6 solution un-workable for IP v6 networks,
> and proposes no operational reason to support your change.

Actually the draft makes the BGP Identifier to be just 4-byte, and
independent of either IPv4 or IPv6.

Could you be more specific why the solution is un-workable for IPv6
network?   

-- Enke

Date: Thu, 20 Dec 2001 19:28:37 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: AS-wide Unique BGP Identifier
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Enke:

A blow by blow comparison of the drafts.  As your
draft is stated below, I do not see the value of widening
the BGP Identifier value.   Perhaps you can enlightening
me as to the purpose of this proposed BGP change versus
the BCP proposal from the IP v6 area.

Your draft would make the IP v6 solution un-workable for IP v6 networks,
and proposes no operational reason to support your change.

Sue Hares

>----------------------------------------------------------------------
>
>
>
>
>
>Network Working Group                                         Enke Chen
>Internet Draft                                               Jenny Yuan
>Expiration Date: June 2002                             Redback Networks
>
>
>                 AS-wide Unique BGP Identifier for BGP-4
>
>
>                     draft-chen-bgp-identifier-00.txt
>
>
>1. Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as ``work in progress.''
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.

Same boiler plate.

>2. Abstract
>
>    To deal with 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 does not introduce any backward compatibility issue.

Both documents deal with the BGP-Identifer.  Both suggest a 4 byte
octet is unsigned, non-zero integer.   The IP v6 suggests a globally
valid format for the IP v6 only address structure.

>3. Introduction
>
>    Currently the BGP Identifier of a BGP speaker is specified as a valid
>    IPv4 host address assigned to the BGP speaker [BGP-4].  In addition,
>    the deployed BGP code requires BGP speakers to be of distinct BGP
>    Identifiers in order to establish a BGP connection.
>
>    To deal with 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 does not introduce any backward compatibility issue.

Your draft does not specify why this relaxation should occur.  It
simply states that you want this draft to occur.  What purpose
does it serve to relax these requirements?   At least in the
BCP for IP v6 it states a reason.  It would be useful to
state a reason for the BGP Identifier change.

>4. Protocol Revisions
>
>    The revisions to the base BGP specification [BGP-4] include the
>    definition of the BGP Identifier and procedures for a BGP speaker
>    that supports the AS-wide Unique BGP Identifier

Again, I see no good reason to do expand this BGP into a AS-Wide
Identifier.  Why should we relax this BGP identifier?

>4.1. Definition of the BGP Identifier
>
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the BGP Identifier is specified as the following:
>
>      The BGP Identifier is a 4-octet unsigned, non-zero integer that
>      should be unique within an AS. The value of the BGP Identifier for
>      a BGP speaker is determined on startup and is the same for every
>      local interface and every BGP peer

Why should we use this methodology when it may impact the IP v6 solution
that Akira Kato and Bill Manning suggest?  The IP v6 next hop
can be global and local, global and in their Kato/Manning proposal
just local.

>4.2. Open Message Error Handling
>
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the OPEN message error handling related to the BGP Identifier is
>    modified as follows:
>
>      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 are we restricting this to just an internal peer?   What use
is just the internal peer portion of this?

>4.3. Connection Collision Resolution
>
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the procedures for connection collision resolution are extended as
>    follows to deal with the case in which the two BGP speakers share the
>    same BGP Identifier (thus it is only applicable to an external peer):
>
>      If the BGP Identifiers of the peers involved in the connection
>      collision are identical, then the connection initiated by the BGP
>      speaker with the larger AS number is preserved.

Either the original proposal for BGP Identifier or the IP v6 only identifier
does not place this extra check in the Connection collision work.
Why do you feel you need to add this extra check to the BGP processing?
What operational issue are you trying to solve?

>5. Remarks
>
>    It is noted that a BGP Identifier allocated based on [BGP-4] fits the
>    revised definition.
>
>    In case of BGP Confederation, the whole confederation is considered
>    as one AS for the purpose of supporting the AS-wide Unique BGP
>    Identifier.

Why does this restriction need to occur?  Why not use the
Class E address space for your identifier with the AS encoded?
Why do you need to restrict things to an AS-Wide BGP identifier?
What is the number of BGP peers that you are working on per AS?

>    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.

This provides an "flag" day approach where the IP v6 suggestion could
be used for the same impact with a Class E and be able to use the
Address field to replace this.   Implementations can accept or reject
Class E addresses.

>    In addition to the OPEN message, the BGP Identifier is currently also
>    used in the following areas:
>
>      o In the AGGREAGTOR attribute of a route where the combination of
>        a BGP Identifier and an AS number uniquely identifies the BGP
>        speaker that performs the route aggregation.

I believe you mean AGGREGATOR attribute at this point.

>      o In the Route Reflection (in lieu of the Cluster-id) within an
>        AS, where only the BGP Identifier of an internal neighbor may
>        be propagated in the route reflection related attributes.

Why do you indicate in lieu of the Cluster-id?  Again, the
same comment on the use of the Class E address space may not require
a flag day, just an implementation change.  The only issue that
the Class E address has concerns on is the number of Peers.
Are you looking at this problem?

>      o 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).

Hmm.  I'm having a bit of trouble parsing this sentence:  "in route selection,
where the BGP Identifier is not used in comparing a route from an internal
neighbor and external neighbor.   Why do you mention BGP Identifier?
Perhaps the sentence is incorrect.

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

Why is the flag day indication, not a backward compatibility issue?

>6. Security Considerations
>
>    This extension to BGP does not change the underlying security issues.

Actually by weaking the checks on the BGP identifier, you do weaken
the BGP security checks on the BGP peering seessions.

>7. Acknowledgments
>
>    [TBD]
>
>
>8. References
>
>    [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
>    draft-ietf-idr-bgp4-16.txt, November 2001.
>
>
>9. Author Information
>
>    Enke Chen
>    Redback Networks, Inc.
>    350 Holger Way
>    San Jose, CA 95134
>    e-mail: [email-masked]
>
>    Jenny Yuan
>    Redback Networks, Inc.
>    350 Holger Way
>    San Jose, CA 95134
>    e-mail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Chen & Yuan                                                     [Page 4]

To: Dorian Kim <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AS-wide Unique BGP Identifier 
Date: Thu, 20 Dec 2001 14:22:16 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Dorian:

> Date: Thu, 20 Dec 2001 17:08:38 -0500
> From: Dorian Kim <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Subject: Re: AS-wide Unique BGP Identifier
> Message-ID: <[email-masked]>
>
> Enke, would it be possible to explicitly clarify how this proporsal 
> would handle confederation peering sessions?

Here is the current text:

   In case of BGP Confederation, the whole confederation is considered
   as one AS for the purpose of supporting the AS-wide Unique BGP
   Identifier.

So the ID should be unique within the whole confederation (the same
as today). We can make it more explicit.

Thanks. -- Enke

Date: Thu, 20 Dec 2001 17:08:38 -0500
From: Dorian Kim <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AS-wide Unique BGP Identifier
Sender: [email-masked]

Enke, would it be possible to explicitly clarify how this proporsal 
would handle confederation peering sessions?

Thanks,

-dorian

To: Susan Hares <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AS-wide Unique BGP Identifier 
Date: Thu, 20 Dec 2001 14:08:25 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue,

> Date: Thu, 20 Dec 2001 16:08:51 -0500
> To: Enke Chen <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: AS-wide Unique BGP Identifier
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
> 
> Enke:
> 
> Why is this different than the Router-ID proposed by the
> Alian Durand?  It seems you are submitting a draft
> that overlays that draft.

They are very different. Please read the draft (or both).  -- Enke

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AS-wide Unique BGP Identifier 
Date: Thu, 20 Dec 2001 14:06:30 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Jeff:

> Date: Thu, 20 Dec 2001 16:29:12 -0500
> From: Jeffrey Haas <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Subject: Re: AS-wide Unique BGP Identifier
> Message-ID: <[email-masked]>
> 
> On Thu, Dec 20, 2001 at 12:25:19PM -0800, Enke Chen wrote:
> > 4.3. Connection Collision Resolution
> > 
> >    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
> >    the procedures for connection collision resolution are extended as
> >    follows to deal with the case in which the two BGP speakers share the
> >    same BGP Identifier (thus it is only applicable to an external peer):
> 
> Why would it only be applicable to an external peer?

Because the internal peers need to have unique BGP Identifiers in order
to bring up the session. So you do not run into this situation for IBGP.

> 
> >      If the BGP Identifiers of the peers involved in the connection
> >      collision are identical, then the connection initiated by the BGP
> >      speaker with the larger AS number is preserved.
> 
> So, if you are AS 1, and you try to peer with AS 2, and you have
> an internal peer with 1.1.1.1 as its ID and AS 2 has 1.1.1.1, you'll
> drop your peering session with your internal peer?

No, these are two different peers. However, if the router AS1 also has
ID 1.1.1.1, then it can not bring up an internal peer with another
rotuer that has ID 1.1.1.1.

> 
> > 5. Remarks
> > 
> >    It is noted that a BGP Identifier allocated based on [BGP-4] fits the
> >    revised definition.
> 
> And should note that "when possible, a globally routable IP address
> should be used as it assists debugging."

Sure, we can add some text. Thanks. -- Enke

> 
> 
> -- 
> Jeff Haas 
> NextHop Technologies

Date: Thu, 20 Dec 2001 16:29:12 -0500
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AS-wide Unique BGP Identifier
Sender: [email-masked]

On Thu, Dec 20, 2001 at 12:25:19PM -0800, Enke Chen wrote:
> 4.3. Connection Collision Resolution
> 
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the procedures for connection collision resolution are extended as
>    follows to deal with the case in which the two BGP speakers share the
>    same BGP Identifier (thus it is only applicable to an external peer):

Why would it only be applicable to an external peer?

>      If the BGP Identifiers of the peers involved in the connection
>      collision are identical, then the connection initiated by the BGP
>      speaker with the larger AS number is preserved.

So, if you are AS 1, and you try to peer with AS 2, and you have
an internal peer with 1.1.1.1 as its ID and AS 2 has 1.1.1.1, you'll
drop your peering session with your internal peer?

> 5. Remarks
> 
>    It is noted that a BGP Identifier allocated based on [BGP-4] fits the
>    revised definition.

And should note that "when possible, a globally routable IP address
should be used as it assists debugging."

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 20 Dec 2001 16:21:05 -0500
To: "Shah, Himanshu" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: RE: Working Group notes from 12/13/01 meeting
Cc: "'Susan Hares'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Please send the list of the recent drafts you have implemented
to me ([email-masked]).  I'll summarize to the list.

If you received source code to kick-start your implementation,
please let me know that as well.

Sue

At 10:08 AM 12/20/2001 -0500, Shah, Himanshu wrote:
>I believe you called out vendors to notify
>implementations of some of the recent drafts
>to escalate the draft status.
>
>Could you give a list and information on
>who to contact to?
>
>himanshu shah
>Tenor Networks
>
>

Date: Thu, 20 Dec 2001 16:08:51 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: AS-wide Unique BGP Identifier
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Enke:

Why is this different than the Router-ID proposed by the
Alian Durand?  It seems you are submitting a draft
that overlays that draft.

Sue Hares

At 12:25 PM 12/20/2001 -0800, Enke Chen wrote:
>Hi, folks:
>Happy Holidays !!!
>
>We have submitted the following Internet Draft (which may not be
>processed until Jan. 3 due to the holiday).
>
>Please let us know if you have any comments. -- Enke
>
>----------------------------------------------------------------------
>
>
>
>
>
>Network Working Group                                         Enke Chen
>Internet Draft                                               Jenny Yuan
>Expiration Date: June 2002                             Redback Networks
>
>
>                 AS-wide Unique BGP Identifier for BGP-4
>
>
>                     draft-chen-bgp-identifier-00.txt
>
>
>1. Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as ``work in progress.''
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>
>2. Abstract
>
>    To deal with 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 does not introduce any backward compatibility issue.
>
>
>
>
>
>
>
>
>
>
>Chen & Yuan                                                     [Page 1]
>
>
>
>
>
>Internet Draft      draft-chen-bgp-identifier-00.txt       December 2001
>
>
>3. Introduction
>
>    Currently the BGP Identifier of a BGP speaker is specified as a valid
>    IPv4 host address assigned to the BGP speaker [BGP-4].  In addition,
>    the deployed BGP code requires BGP speakers to be of distinct BGP
>    Identifiers in order to establish a BGP connection.
>
>    To deal with 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 does not introduce any backward compatibility issue.
>
>
>4. Protocol Revisions
>
>    The revisions to the base BGP specification [BGP-4] include the
>    definition of the BGP Identifier and procedures for a BGP speaker
>    that supports the AS-wide Unique BGP Identifier.
>
>
>4.1. Definition of the BGP Identifier
>
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the BGP Identifier is specified as the following:
>
>      The BGP Identifier is a 4-octet unsigned, non-zero integer that
>      should be unique within an AS. The value of the BGP Identifier for
>      a BGP speaker is determined on startup and is the same for every
>      local interface and every BGP peer.
>
>
>4.2. Open Message Error Handling
>
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the OPEN message error handling related to the BGP Identifier is
>    modified as follows:
>
>      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".
>
>
>
>
>
>
>
>
>Chen & Yuan                                                     [Page 2]
>
>
>
>
>
>Internet Draft      draft-chen-bgp-identifier-00.txt       December 2001
>
>
>4.3. Connection Collision Resolution
>
>    For a BGP speaker that supports the AS-wide Unique BGP Identifier,
>    the procedures for connection collision resolution are extended as
>    follows to deal with the case in which the two BGP speakers share the
>    same BGP Identifier (thus it is only applicable to an external peer):
>
>      If the BGP Identifiers of the peers involved in the connection
>      collision are identical, then the connection initiated by the BGP
>      speaker with the larger AS number is preserved.
>
>
>5. Remarks
>
>    It is noted that a BGP Identifier allocated based on [BGP-4] fits the
>    revised definition.
>
>    In case of BGP Confederation, the whole confederation is considered
>    as one AS for the purpose of supporting the AS-wide Unique BGP
>    Identifier.
>
>    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.
>
>    In addition to the OPEN message, the BGP Identifier is currently also
>    used in the following areas:
>
>      o In the AGGREAGTOR attribute of a route where the combination of
>        a BGP Identifier and an AS number uniquely identifies the BGP
>        speaker that performs the route aggregation.
>
>      o In the Route Reflection (in lieu of the Cluster-id) within an
>        AS, where only the BGP Identifier of an internal neighbor may
>        be propagated in the route reflection related attributes.
>
>      o 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).
>
>    Therefore it is concluded that the revisions proposed in this
>    document do not introduce any backward compatibility issue with the
>    current usage of the BGP Identifier.
>
>
>
>
>
>Chen & Yuan                                                     [Page 3]
>
>
>
>
>
>Internet Draft      draft-chen-bgp-identifier-00.txt       December 2001
>
>
>6. Security Considerations
>
>    This extension to BGP does not change the underlying security issues.
>
>
>7. Acknowledgments
>
>    [TBD]
>
>
>8. References
>
>    [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
>    draft-ietf-idr-bgp4-16.txt, November 2001.
>
>
>9. Author Information
>
>    Enke Chen
>    Redback Networks, Inc.
>    350 Holger Way
>    San Jose, CA 95134
>    e-mail: [email-masked]
>
>    Jenny Yuan
>    Redback Networks, Inc.
>    350 Holger Way
>    San Jose, CA 95134
>    e-mail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Chen & Yuan                                                     [Page 4]

To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: AS-wide Unique BGP Identifier
Date: Thu, 20 Dec 2001 12:25:19 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
Happy Holidays !!!

We have submitted the following Internet Draft (which may not be
processed until Jan. 3 due to the holiday).

Please let us know if you have any comments. -- Enke

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

Network Working Group                                         Enke Chen
Internet Draft                                               Jenny Yuan
Expiration Date: June 2002                             Redback Networks

                AS-wide Unique BGP Identifier for BGP-4

                    draft-chen-bgp-identifier-00.txt

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2. Abstract

   To deal with 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 does not introduce any backward compatibility issue.

Chen & Yuan                                                     [Page 1]

Internet Draft      draft-chen-bgp-identifier-00.txt       December 2001

3. Introduction

   Currently the BGP Identifier of a BGP speaker is specified as a valid
   IPv4 host address assigned to the BGP speaker [BGP-4].  In addition,
   the deployed BGP code requires BGP speakers to be of distinct BGP
   Identifiers in order to establish a BGP connection.

   To deal with 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 does not introduce any backward compatibility issue.

4. Protocol Revisions

   The revisions to the base BGP specification [BGP-4] include the
   definition of the BGP Identifier and procedures for a BGP speaker
   that supports the AS-wide Unique BGP Identifier.

4.1. Definition of the BGP Identifier

   For a BGP speaker that supports the AS-wide Unique BGP Identifier,
   the BGP Identifier is specified as the following:

     The BGP Identifier is a 4-octet unsigned, non-zero integer that
     should be unique within an AS. The value of the BGP Identifier for
     a BGP speaker is determined on startup and is the same for every
     local interface and every BGP peer.

4.2. Open Message Error Handling

   For a BGP speaker that supports the AS-wide Unique BGP Identifier,
   the OPEN message error handling related to the BGP Identifier is
   modified as follows:

     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".

Chen & Yuan                                                     [Page 2]

Internet Draft      draft-chen-bgp-identifier-00.txt       December 2001

4.3. Connection Collision Resolution

   For a BGP speaker that supports the AS-wide Unique BGP Identifier,
   the procedures for connection collision resolution are extended as
   follows to deal with the case in which the two BGP speakers share the
   same BGP Identifier (thus it is only applicable to an external peer):

     If the BGP Identifiers of the peers involved in the connection
     collision are identical, then the connection initiated by the BGP
     speaker with the larger AS number is preserved.

5. Remarks

   It is noted that a BGP Identifier allocated based on [BGP-4] fits the
   revised definition.

   In case of BGP Confederation, the whole confederation is considered
   as one AS for the purpose of supporting the AS-wide Unique BGP
   Identifier.

   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.

   In addition to the OPEN message, the BGP Identifier is currently also
   used in the following areas:

     o In the AGGREAGTOR attribute of a route where the combination of
       a BGP Identifier and an AS number uniquely identifies the BGP
       speaker that performs the route aggregation.

     o In the Route Reflection (in lieu of the Cluster-id) within an
       AS, where only the BGP Identifier of an internal neighbor may
       be propagated in the route reflection related attributes.

     o 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).

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

Chen & Yuan                                                     [Page 3]

Internet Draft      draft-chen-bgp-identifier-00.txt       December 2001

6. Security Considerations

   This extension to BGP does not change the underlying security issues.

7. Acknowledgments

   [TBD]

8. References

   [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
   draft-ietf-idr-bgp4-16.txt, November 2001.

9. Author Information

   Enke Chen
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA 95134
   e-mail: [email-masked]

   Jenny Yuan
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA 95134
   e-mail: [email-masked]

Chen & Yuan                                                     [Page 4]

Date: Thu, 20 Dec 2001 10:43:58 -0500
From: Jeffrey Haas <[email-masked]>
To: Katia Linker <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Route Reflection & AS confederation MIBs (attached)
Sender: [email-masked]

Apologies for replying to lists that I'm not on.

On Thu, Dec 20, 2001 at 05:06:46PM +0200, Katia Linker wrote:
> 
> Hello, all !
> Regards the Route reflection and AS confederation MIBs
> that I'm sending you, I would like to ask you some
> questions.

[...]

>                 <draft-richardson-bgp4-confed-mib-00.txt>

This draft has been abandoned in favor of the bgp4-mibv2 effort.
The mibv2 is still under development and everyone who is interested
in the effort is invited to join the focus group list for the MIB:

mailto: [email-masked]
message body: subscribe bgp-mib

The current mibv2 is available at:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-01.txt

The status of the MIBs was updated at IDR in Salt Lake City.  The powerpoint
slides are available at
http://www.nexthop.com/standards/ietf_proceedings/01dec/mib-update-01dec.ppt

A short version of the status is: We are done with the base
architecture of the mib layout.  The following things need to be
done:

1. Split out non-NLRI info from NLRI.  (labeled routes, etc.)
2. Add full configuration structure - the stuff that is there is
   very tenuous at the moment and will change a lot between -01 and -02.
3. Lots of cleanup.
4. Adding additional extension based tables.
5. Additional notifications and counters.

We are, ideally, trying to avoid cluttering the IDR list with the
guts of working on the MIB until -02.  At that point, we're hoping
that things will be stable enough to request that implementations
begin.

To answer your specific questions, the yet to be fisnished configuration
objects in the MIB are meant to cover the problems you cite.

We look forward to additional participants in the MIB work.

-- 
Jeff Haas 
NextHop Technologies

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:  Route Reflection & AS confederation MIBs (attached)
Date: Thu, 20 Dec 2001 17:06:46 +0200
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C18967.F151EF00
Content-Type: text/plain

Hello, all !
Regards the Route reflection and AS confederation MIBs
that I'm sending you, I would like to ask you some
questions.

1. bgpClusterId OBJECT-TYPE
	    SYNTAX	IpAddress
	    MAX-ACCESS	read-only
	    STATUS	current
	    DESCRIPTION
		    "The configured Cluster-ID of the local router. A value
		     of 0.0.0.0 indicates the absence of this value."
	    REFERENCE
		    "RFC 2796 - BGP Route Reflection"
	    ::= { bgpReflect 1 }
  If this scalar is read-only, then how can I configure it
  in case that there are few reflectors in the same cluster
  and cluster id is not the same as bgp id ?

2. bgpPeerIsReflectorClient OBJECT-TYPE
	    SYNTAX	INTEGER {
				nonClient(0),
				client(1),
				meshedClient(2)
			}
	    MAX-ACCESS	read-only
	    STATUS	current
	    DESCRIPTION
		    "This value indicates whether the given peer is a
reflector
		     client of this router, or not.  A value of nonClient
		     indicates that this peer is not a reflector client.  A
		     value of client indicates that this peer is a reflector
		     client that is not fully meshed with other reflector
		     clients.  A value of meshedClient indicates that the
		     peer is a reflector client and is fully meshed with all
		     other reflector clients."
	    REFERENCE
		    "RFC 2796 - BGP Route Reflection"
	    ::= { bgpPeerReflectEntry 1 }

    Again, if this field is read-only, then how can I configure it ?

The same questions are hold for the AS Confederation.

     Thanks in advance.
              Katya

------_=_NextPart_000_01C18967.F151EF00
Content-Type: text/plain;
	name="draft-richardson-bgp4-confed-mib-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-richardson-bgp4-confed-mib-00.txt"

=0A=
Network Working Group                                      M. =
Richardson=0A=
INTERNET DRAFT                                                 S. =
Wright=0A=
Expires August 2001					        S. Hares=0A=
								 NextHop=0A=
                                                           February =
2001=0A=
=0A=
=0A=
=0A=
                     Definitions of Managed Objects=0A=
=0A=
=0A=
                      for Confederations in Border=0A=
=0A=
=0A=
			Gateway Protocol (BGP-4)=0A=
=0A=
=0A=
                <draft-richardson-bgp4-confed-mib-00.txt>=0A=
=0A=
=0A=
=0A=
Status of this Memo=0A=
=0A=
=0A=
   This document is an Internet-Draft and is in full conformance =
with=0A=
   all provisions of Section 10 of RFC 2026.=0A=
=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups.  Note that=0A=
   other groups may also distribute working documents as Internet-=0A=
   Drafts.=0A=
=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six =
months=0A=
   and may be updated, replaced, or obsoleted by other documents at =
any=0A=
   time.  It is inappropriate to use Internet- Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.=0A=
=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
=0A=
=0A=
Copyright Notice=0A=
=0A=
=0A=
   Copyright (C) The Internet Society (1999). All Rights Reserved.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
   This memo is an extension to the SNMP MIB.  It specifies an IAB=0A=
   standards track protocol for the Internet community, and requests=0A=
   discussion and suggestions for improvements.  This memo extends=0A=
   the MIB defined in [BGP-MIB].=0A=
=0A=
=0A=
   Distribution of this memo is unlimited.  Please forward comments =
to=0A=
   [email-masked].=0A=
=0A=
=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
=0A=
   This memo defines extensions to the MIB defined in [BGP-MIB].  In=0A=
   particular, it describes managed objects based upon attributes =
defined=0A=
   in "Autonomous System Confederations for BGP" [RFC1965].=0A=
=0A=
=0A=
2. Overview=0A=
=0A=
=0A=
   These objects are used to control and manage a BGP-4 =
implementation=0A=
   that supports AS Confederations [RFC1965].=0A=
=0A=
   This MIB defines a system-wide scalar object, and extends one =
table=0A=
   defined in [BGP-MIB]:  the BGP Peer Table.=0A=
=0A=
   This MIB defines the following primary objects:=0A=
=0A=
    - bgpConfederationId { bgp 12 1 }=0A=
=0A=
      The locally configured Confederation ID Number.=0A=
=0A=
    - bgpPeerConfedTable { bgp 12 2 }=0A=
=0A=
      Whether each peer is in the same Confederation as the router.=0A=
=0A=
=0A=
3. Definitions=0A=
=0A=
=0A=
    BGP-CONFED-MIB DEFINITIONS ::=3D BEGIN=0A=
=0A=
=0A=
        IMPORTS=0A=
            MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,=0A=
            mib-2, =0A=
                FROM SNMPv2-SMI=0A=
            MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP=0A=
                FROM SNMPv2-CONF=0A=
	    TruthValue=0A=
		FROM SNMPv2-TC=0A=
	    bgp=0A=
		FROM BGP-MIB;=0A=
=0A=
        bgpConfed MODULE-IDENTITY=0A=
            LAST-UPDATED "200102230000Z"=0A=
            ORGANIZATION "IETF IDR Working Group"=0A=
            CONTACT-INFO "E-mail:  [email-masked]=0A=
=0A=
			  Mathew Richardson (Author)=0A=
			  E-mail: [email-masked]=0A=
			  Shane Wright (Author)=0A=
			  E-mail: [email-masked]=0A=
                          517 W. William Street=0A=
                          Ann Arbor, MI 48103-4943=0A=
                          Tel: +1 734 973-2200=0A=
                          Fax: +1 734 615-3241=0A=
=0A=
                          Susan Hares  (Editor)=0A=
                          517 W. William Street=0A=
                          Ann Arbor, MI 48103-4943=0A=
                          Tel: +1 734 973-2200=0A=
                          Fax: +1 734 615-3241=0A=
                          E-mail: [email-masked]"=0A=
=0A=
            REVISION    "200102230000Z"=0A=
            DESCRIPTION=0A=
		    "Extension of the MIB module for BGP-4 to include=0A=
		     about BGP Confederations."=0A=
	    REFERENCE=0A=
		    "RFC 1965 - Autonomous System Confederations for BGP"=0A=
		    "RFC 1771 - Border Gateway Protocol version 4 (BGP-4)"=0A=
		=0A=
            ::=3D { bgp 12 }=0A=
=0A=
=0A=
        bgpConfederationId OBJECT-TYPE=0A=
            SYNTAX     INTEGER (0..65535)=0A=
            MAX-ACCESS read-only=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
                    "The local Confederation Identification Number.  A =
value=0A=
		     of zero (0) indicates the absence of this value."=0A=
	    REFERENCE=0A=
		    "RFC 1965 - Autonomous System Confederations for BGP"=0A=
            ::=3D { bgpConfed 1 }=0A=
=0A=
=0A=
        bgpPeerConfedTable OBJECT-TYPE=0A=
            SYNTAX     SEQUENCE OF BgpPeerConfedEntry=0A=
            MAX-ACCESS not-accessible=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
                    "BGP Peer Confederation Table.  This table =
contains=0A=
		     information on whether a given peer is in the same=0A=
		     Confederation as the router."=0A=
            ::=3D { bgpConfed 2 }=0A=
=0A=
=0A=
        bgpPeerConfedEntry OBJECT-TYPE=0A=
            SYNTAX     BgpPeerConfedEntry=0A=
            MAX-ACCESS not-accessible=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
		    "Information on whether a given peer is in the same=0A=
		     Confederation as the router."=0A=
            AUGMENTS	{ bgpPeerEntry }=0A=
            ::=3D { bgpPeerConfedTable 1 }=0A=
=0A=
=0A=
        BgpPeerConfedEntry ::=3D SEQUENCE {=0A=
		bgpPeerInConfederation=0A=
			TruthValue=0A=
                }=0A=
=0A=
=0A=
	bgpPeerInConfederation OBJECT-TYPE=0A=
	    SYNTAX	TruthValue=0A=
	    MAX-ACCESS	read-only=0A=
	    STATUS	current=0A=
	    DESCRIPTION=0A=
		    "This value indicates whether the given peer is in our=0A=
		     confederation or not."=0A=
	    ::=3D { bgpPeerConfedEntry 1 }=0A=
=0A=
    END=0A=
=0A=
4. Intellectual Property=0A=
=0A=
=0A=
   The IETF takes no position regarding the validity or scope of any=0A=
   intellectual property or other rights that might be claimed to=0A=
   pertain to the implementation or use of the technology described =
in=0A=
   this document or the extent to which any license under such =
rights=0A=
   might or might not be available; neither does it represent that =
it=0A=
   has made any effort to identify any such rights.  Information on =
the=0A=
   IETF's procedures with respect to rights in standards-track and=0A=
   standards-related documentation can be found in BCP-11.  Copies =
of=0A=
   claims of rights made available for publication and any assurances =
of=0A=
   licenses to be made available, or the result of an attempt made =
to=0A=
   obtain a general license or permission for the use of such=0A=
   proprietary rights by implementors or users of this specification =
can=0A=
   be obtained from the IETF Secretariat.=0A=
=0A=
=0A=
=0A=
5. Acknowledgements=0A=
=0A=
=0A=
   The authors would like to thank the following individuals without=0A=
   whom this document would never have been possible:=0A=
=0A=
   J. Haas, NextHop Technologies=0A=
=0A=
=0A=
6. References=0A=
=0A=
   [BGP-MIB]  Hares, S.,  Haas, J., "Definitions of Managed Objects for =
the=0A=
       Fourth Version of Border Gateway Protocol (BGP-4)",=0A=
       draft-ietf-idr-bgp4-mib-05.txt, December 2001.=0A=
=0A=
   [RFC1965]  Traina, P.  "Autonomous System Confederations for =
BGP",=0A=
       RFC-1965, June 1996.=0A=
=0A=
=0A=
7. Security Considerations=0A=
=0A=
=0A=
   Security considerations are beyond the scope of this document.  =
See=0A=
   [BGP-MIB] for a more detailed discussion of the security =
implications=0A=
   of this document.=0A=
=0A=
=0A=
8. Authors' Address=0A=
=0A=
=0A=
   Mathew Richardson=0A=
   NextHop Technologies=0A=
   517 W. William=0A=
   Ann Arbor, MI 48103-4943=0A=
   Phone: +1 734 973-2200=0A=
   Fax:   +1 734 615-3241=0A=
   Email: [email-masked]=0A=
=0A=
   Shane Wright=0A=
   NextHop Technologies=0A=
   517 W. William=0A=
   Ann Arbor, MI 48103-4943=0A=
   Phone: +1 734 973-2200=0A=
   Fax:   +1 734 615-3241=0A=
   Email: [email-masked]=0A=
=0A=
   Susan Hares=0A=
   NextHop Technologies=0A=
   517 W. William=0A=
   Ann Arbor, MI 48103-4943=0A=
   Phone: +1 734 973-2200=0A=
   Fax:   +1 734 615-3241=0A=
   Email: [email-masked]=0A=
=0A=
=0A=
=0A=
9. Full Copyright Statement=0A=
=0A=
=0A=
   Copyright (C) The Internet Society (1999).  All Rights Reserved.=0A=
=0A=
=0A=
   This document and translations of it may be copied and furnished =
to=0A=
   others, and derivative works that comment on or otherwise explain =
it=0A=
   or assist in its implementation may be prepared, copied, =
published=0A=
   and distributed, in whole or in part, without restriction of any=0A=
   kind, provided that the above copyright notice and this paragraph =
are=0A=
   included on all such copies and derivative works.  However, this=0A=
   document itself may not be modified in any way, such as by =
removing=0A=
   the copyright notice or references to the Internet Society or =
other=0A=
   Internet organizations, except as needed for the purpose of=0A=
   developing Internet standards in which case the procedures for=0A=
   copyrights defined in the Internet Standards process must be=0A=
   followed, or as required to translate it into languages other =
than=0A=
   English.=0A=
=0A=
=0A=
   The limited permissions granted above are perpetual and will not =
be=0A=
   revoked by the Internet Society or its successors or assigns.=0A=
=0A=
=0A=
   This document and the information contained herein is provided on =
an=0A=
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING=0A=
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, =
INCLUDING=0A=
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A=
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A=
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
Expires August 2001=0A=

------_=_NextPart_000_01C18967.F151EF00
Content-Type: text/plain;
	name="draft-richardson-bgp4-reflect-mib-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-richardson-bgp4-reflect-mib-00.txt"

=0A=
Network Working Group                                      M. =
Richardson=0A=
INTERNET DRAFT                                                 S. =
Wright=0A=
Expires August 2001					        S. Hares=0A=
								 NextHop=0A=
                                                           February =
2001=0A=
=0A=
                                                             =0A=
=0A=
                     Definitions of Managed Objects=0A=
=0A=
=0A=
                     for Route Reflection in Border=0A=
=0A=
=0A=
			Gateway Protocol (BGP-4)=0A=
=0A=
=0A=
                <draft-richardson-bgp4-reflect-mib-00.txt>=0A=
=0A=
=0A=
=0A=
Status of this Memo=0A=
=0A=
=0A=
   This document is an Internet-Draft and is in full conformance =
with=0A=
   all provisions of Section 10 of RFC 2026.=0A=
=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups.  Note that=0A=
   other groups may also distribute working documents as Internet-=0A=
   Drafts.=0A=
=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six =
months=0A=
   and may be updated, replaced, or obsoleted by other documents at =
any=0A=
   time.  It is inappropriate to use Internet- Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.=0A=
=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
=0A=
=0A=
Copyright Notice=0A=
=0A=
=0A=
   Copyright (C) The Internet Society (1999). All Rights Reserved.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
   This memo is an extension to the SNMP MIB.  It specifies an IAB=0A=
   standards track protocol for the Internet community, and requests=0A=
   discussion and suggestions for improvements.  This memo extends=0A=
   the MIB defined in [BGP-MIB].=0A=
=0A=
=0A=
   Distribution of this memo is unlimited.  Please forward comments =
to=0A=
   [email-masked].=0A=
=0A=
=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
=0A=
   This memo defines extensions to the MIB defined in [BGP-MIB].  In=0A=
   particular, it describes managed objects based upon attributes =
defined=0A=
   in "BGP Route Reflective - An Alternative to Full Mesh IBGP" =
[RFC2796].=0A=
=0A=
=0A=
2. Overview=0A=
=0A=
=0A=
   These objects are used to control and manage a BGP-4 =
implementation=0A=
   that supports Route Reflection [RFC2796].=0A=
=0A=
   This MIB defines a system-wide scalar object, and extends two =
tables=0A=
   defined in [BGP-MIB]:  the BGP Peer Table, and the BGP-4 Received=0A=
   Path Attribute Table.=0A=
=0A=
    - bgpClusterId { bgp 11 1 }=0A=
=0A=
      The locally configured Cluster-ID.=0A=
=0A=
    - bgpPeerReflectTable { bgp 11 2 }=0A=
=0A=
      This table maintains information on whether each peer is =
configured=0A=
      as a reflector client of this router.=0A=
=0A=
    - bgp4ReflectTable { bgp 11 3 }=0A=
=0A=
      This table maintains information about the Route Reflection =
specific=0A=
      path attributes (Cluster List and Originator-ID) received with =
routes.=0A=
=0A=
=0A=
3. Definitions=0A=
=0A=
=0A=
    BGP4-REFLECT-MIB DEFINITIONS ::=3D BEGIN=0A=
=0A=
=0A=
        IMPORTS=0A=
            MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,=0A=
            IpAddress, mib-2=0A=
                FROM SNMPv2-SMI=0A=
            MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP=0A=
                FROM SNMPv2-CONF=0A=
	    TruthValue=0A=
		FROM SNMPv2-TC=0A=
	    bgp=0A=
		FROM BGP-MIB;=0A=
=0A=
        bgpReflect MODULE-IDENTITY=0A=
            LAST-UPDATED "200102230000Z"=0A=
            ORGANIZATION "IETF IDR Working Group"=0A=
            CONTACT-INFO "E-mail:  [email-masked]=0A=
=0A=
			  Mathew Richardson (Author)=0A=
			  E-mail: [email-masked]=0A=
			  Shane Wright (Author)=0A=
			  E-mail: [email-masked]=0A=
                          517 W. William Street=0A=
                          Ann Arbor, MI 48103-4943=0A=
                          Tel: +1 734 973-2200=0A=
                          Fax: +1 734 615-3241=0A=
=0A=
                          Susan Hares  (Editor)=0A=
                          517 W. William Street=0A=
                          Ann Arbor, MI 48103-4943=0A=
                          Tel: +1 734 973-2200=0A=
                          Fax: +1 734 615-3241=0A=
                          E-mail: [email-masked]"=0A=
=0A=
            REVISION    "200102230000Z"=0A=
            DESCRIPTION=0A=
                    "Extension of the MIB module for BGP-4 to =
include=0A=
		     information about attributes and characteristics defined=0A=
		     in BGP Route Reflection."=0A=
	    REFERENCE=0A=
		    "RFC 2796 - BGP Route Reflection"=0A=
            ::=3D { bgp 11 }=0A=
=0A=
=0A=
	bgpClusterId OBJECT-TYPE=0A=
	    SYNTAX	IpAddress=0A=
	    MAX-ACCESS	read-only=0A=
	    STATUS	current=0A=
	    DESCRIPTION=0A=
		    "The configured Cluster-ID of the local router. A value=0A=
		     of 0.0.0.0 indicates the absence of this value."=0A=
	    REFERENCE=0A=
		    "RFC 2796 - BGP Route Reflection"=0A=
	    ::=3D { bgpReflect 1 }=0A=
=0A=
=0A=
        bgpPeerReflectTable OBJECT-TYPE=0A=
            SYNTAX     SEQUENCE OF BgpPeerReflectEntry=0A=
            MAX-ACCESS not-accessible=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
		    "BGP Peer Reflect Table.  This table maintains information=0A=
		     about whether each peer is a Route Reflector."=0A=
	    REFERENCE=0A=
		    "RFC 2796 - BGP Route Reflection"=0A=
            ::=3D { bgpReflect 2 }=0A=
=0A=
=0A=
        bgpPeerReflectEntry OBJECT-TYPE=0A=
            SYNTAX     BgpPeerReflectEntry=0A=
            MAX-ACCESS not-accessible=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
		    "Peer related information pertaining to Route Reflection."=0A=
	    REFERENCE=0A=
		    "RFC 2796 - BGP Route Reflection"=0A=
            AUGMENTS	{ bgpPeerEntry }=0A=
            ::=3D { bgpPeerReflectTable 1 }=0A=
=0A=
=0A=
        BgpPeerReflectEntry ::=3D SEQUENCE {=0A=
		bgpPeerIsReflectorClient=0A=
			TruthValue=0A=
                }=0A=
=0A=
	bgpPeerIsReflectorClient OBJECT-TYPE=0A=
	    SYNTAX	INTEGER {=0A=
				nonClient(0),=0A=
				client(1),=0A=
				meshedClient(2)=0A=
			}=0A=
	    MAX-ACCESS	read-only=0A=
	    STATUS	current=0A=
	    DESCRIPTION=0A=
		    "This value indicates whether the given peer is a reflector=0A=
		     client of this router, or not.  A value of nonClient=0A=
		     indicates that this peer is not a reflector client.  A=0A=
		     value of client indicates that this peer is a reflector=0A=
		     client that is not fully meshed with other reflector=0A=
		     clients.  A value of meshedClient indicates that the=0A=
		     peer is a reflector client and is fully meshed with all=0A=
		     other reflector clients."=0A=
	    REFERENCE=0A=
		    "RFC 2796 - BGP Route Reflection"=0A=
	    ::=3D { bgpPeerReflectEntry 1 }=0A=
=0A=
        bgp4ReflectTable OBJECT-TYPE=0A=
            SYNTAX     SEQUENCE OF Bgp4ReflectEntry=0A=
            MAX-ACCESS not-accessible=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
		    "BGP Reflect Table.  This table contains the route=0A=
		     reflection specific path attributes received with a=0A=
		     given route."=0A=
	    REFERENCE=0A=
		    "RFC 2796 - BGP Route Reflection"=0A=
            ::=3D { bgpReflect 3 }=0A=
=0A=
=0A=
        bgp4ReflectEntry OBJECT-TYPE=0A=
            SYNTAX     Bgp4ReflectEntry=0A=
            MAX-ACCESS not-accessible=0A=
            STATUS     current=0A=
            DESCRIPTION=0A=
		    "Information about the route reflection specific path=0A=
		     attributes received with a given route."=0A=
	    AUGMENTS	{ bgp4PathAttrTable }=0A=
	    ::=3D { bgp4ReflectTable 1 }=0A=
=0A=
=0A=
        Bgp4ReflectEntry ::=3D SEQUENCE {=0A=
	    bgp4PathAttrOriginatorId=0A=
		 IpAddress,=0A=
	    bgp4PathAttrClusterList=0A=
		 OCTET STRING,=0A=
        }=0A=
=0A=
=0A=
	bgp4PathAttrOriginatorId OBJECT-TYPE=0A=
	    SYNTAX	IpAddress=0A=
	    MAX-ACCESS	read-only=0A=
	    STATUS	current=0A=
	    DESCRIPTION=0A=
		    "The Originator-ID identifying the router that initially=0A=
		     advertised this destination to a Route Reflector.  A=0A=
		     value of 0.0.0.0 indicates the absence of this attribute.=0A=
		     This attribute is defined in [RFC2796]."=0A=
	    ::=3D { bgp4ReflectEntry 1 }=0A=
=0A=
	bgp4PathAttrClusterList OBJECT-TYPE=0A=
	    SYNTAX	OCTET STRING (SIZE(0..4096))=0A=
	    MAX-ACCESS	read-only=0A=
	    STATUS	current=0A=
	    DESCRIPTION=0A=
		    "A sequence of four octet long values representing the=0A=
		     reflection path that the route has passed.  Each four=0A=
		     octet long value represents the ID of a cluster that=0A=
		     the route has traversed.  A length of zero (0) indicates=0A=
		     the absence of this attribute.  This attribute is defined=0A=
		     in [RFC2796]."=0A=
	    ::=3D { bgp4ReflectEntry 2 }=0A=
=0A=
    END=0A=
=0A=
4. Intellectual Property=0A=
=0A=
=0A=
   The IETF takes no position regarding the validity or scope of any=0A=
   intellectual property or other rights that might be claimed to=0A=
   pertain to the implementation or use of the technology described =
in=0A=
   this document or the extent to which any license under such =
rights=0A=
   might or might not be available; neither does it represent that =
it=0A=
   has made any effort to identify any such rights.  Information on =
the=0A=
   IETF's procedures with respect to rights in standards-track and=0A=
   standards-related documentation can be found in BCP-11.  Copies =
of=0A=
   claims of rights made available for publication and any assurances =
of=0A=
   licenses to be made available, or the result of an attempt made =
to=0A=
   obtain a general license or permission for the use of such=0A=
   proprietary rights by implementors or users of this specification =
can=0A=
   be obtained from the IETF Secretariat.=0A=
=0A=
=0A=
=0A=
5. Acknowledgements=0A=
=0A=
=0A=
   The authorse would like to thank the following individuals =
without=0A=
   whom this document would never have been possible:=0A=
=0A=
   J. Haas, NextHop Technologies=0A=
=0A=
=0A=
6. References=0A=
=0A=
   [BGP-MIB]  Hares, S.,  Haas, J., "Definitions of Managed Objects for =
the=0A=
       Fourth Version of Border Gateway Protocol (BGP-4)",=0A=
       draft-ietf-idr-bgp4-mib-05.txt, December 2001.=0A=
=0A=
   [RFC2796]  Bates, T.,  Chandra, R., "BGP Route Reflection - An =
Alternative=0A=
       to Full Mesh IBGP", RFC-2796, April 2000.=0A=
=0A=
=0A=
7. Security Considerations=0A=
=0A=
=0A=
   Security considerations are beyond the scope of this document.  =
See=0A=
   [BGP-MIB] for a more detailed discussion of the security =
implications=0A=
   of this document.=0A=
=0A=
=0A=
8. Authors' Address=0A=
=0A=
=0A=
   Mathew Richardson=0A=
   NextHop Technologies=0A=
   517 W. William=0A=
   Ann Arbor, MI 48103-4943=0A=
   Phone: +1 734 973-2200=0A=
   Fax:   +1 734 615-3241=0A=
   Email: [email-masked]=0A=
=0A=
   Shane Wright=0A=
   NextHop Technologies=0A=
   517 W. William=0A=
   Ann Arbor, MI 48103-4943=0A=
   Phone: +1 734 973-2200=0A=
   Fax:   +1 734 615-3241=0A=
   Email: [email-masked]=0A=
=0A=
   Susan Hares=0A=
   NextHop Technologies=0A=
   517 W. William=0A=
   Ann Arbor, MI 48103-4943=0A=
   Phone: +1 734 973-2200=0A=
   Fax:   +1 734 615-3241=0A=
   Email: [email-masked]=0A=
=0A=
=0A=
=0A=
9. Full Copyright Statement=0A=
=0A=
=0A=
   Copyright (C) The Internet Society (1999).  All Rights Reserved.=0A=
=0A=
=0A=
   This document and translations of it may be copied and furnished =
to=0A=
   others, and derivative works that comment on or otherwise explain =
it=0A=
   or assist in its implementation may be prepared, copied, =
published=0A=
   and distributed, in whole or in part, without restriction of any=0A=
   kind, provided that the above copyright notice and this paragraph =
are=0A=
   included on all such copies and derivative works.  However, this=0A=
   document itself may not be modified in any way, such as by =
removing=0A=
   the copyright notice or references to the Internet Society or =
other=0A=
   Internet organizations, except as needed for the purpose of=0A=
   developing Internet standards in which case the procedures for=0A=
   copyrights defined in the Internet Standards process must be=0A=
   followed, or as required to translate it into languages other =
than=0A=
   English.=0A=
=0A=
=0A=
   The limited permissions granted above are perpetual and will not =
be=0A=
   revoked by the Internet Society or its successors or assigns.=0A=
=0A=
=0A=
   This document and the information contained herein is provided on =
an=0A=
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING=0A=
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, =
INCLUDING=0A=
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A=
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A=
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
Expires August 2001=0A=

------_=_NextPart_000_01C18967.F151EF00--

From: "Shah, Himanshu" <[email-masked]>
To: "'Susan Hares'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Working Group notes from 12/13/01 meeting
Date: Thu, 20 Dec 2001 10:08:49 -0500
Sender: [email-masked]

I believe you called out vendors to notify
implementations of some of the recent drafts
to escalate the draft status.

Could you give a list and information on 
who to contact to?

himanshu shah
Tenor Networks

Date: Thu, 20 Dec 2001 09:47:44 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Working Group notes from 12/13/01 meeting
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Here's a reference to the "Krawczyk's talk of Wed" that is referenced
on one slide of the Rogaway talk:

paper: (extended version of the Krawczyk paper I gave you already)
http://www.research.ibm.com/security/bck2.ps

talk: (from RSA Data Security Conference 96)
http://www.research.ibm.com/security/rsaconf.ps

--Sandy

Date: Thu, 20 Dec 2001 09:36:35 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Working Group notes from 12/13/01 meeting
Cc: [email-masked], [email-masked]
Sender: [email-masked]

According to the crypto folk down the hall, here are some sites that
talk about the general vulnerability of prefix (hash[key,message]),
suffix (hash[message,key]) and even envelope (hash[key1,message,key2])
techniques, particularly compared to nested keyed crypto-hash
techniques (twistycombination[hash,key,message]).

Rogaway's talk at the 96 RSA Data Security Conference:  
http://www.cs.ucdavis.edu/~rogaway/talks/mac-survey-19jan96.ps

Gene Tsudik's paper on Keyed-MD4/5:

http://citeseer.nj.nec.com/tsudik92message.html

Bert Preneel and Paul Van Oorschot's evaluation of Tsudik's approach,
demonstrating the weaknesses of keyed-MD4/5 for the prefix, suffix, and
envelope methods:

http://citeseer.nj.nec.com/preneel95mdxmac.html

and more about the envelope method:

http://citeseer.nj.nec.com/16659.html

Bellare/Canetti/Krawczyk HMAC paper that references Preneel/Oorschot, but
goes beyond by inventing NMACs and HMACs:

http://citeseer.nj.nec.com/bellare96keying.html

Hope this helps :-) (you'll see why the smiley when you look at the papers).

--Sandy

P.S.  Slide 22 of the Rogaway talk gives a summary table.

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: One comment on 9.1.2.2 Breaking Ties, draft-16 
Date: Wed, 19 Dec 2001 14:14:38 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Yakov,
Another similar case, when there are parallel sessions between two
routers, the algorithm may not terminate as the BGP Identifier
would be the same.

-- Enke

> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: One comment on 9.1.2.2 Breaking Ties, draft-16
> Date: Wed, 19 Dec 2001 14:00:41 -0800
> From: Enke Chen <[email-masked]>
> Message-Id: <[email-masked]>
> 
> Hi, Yakov:
> Just noticed that the algorithm described in this section may not
> yield deterministic result in case of route reflection as the BGP
> Identifier could be the same for two paths.
> 
> Could you add one more step:
> 
>  g) Prefer the route received from the lowest neighbor address.
> 
> This would also reflect the deployed code.
> 
> Thanks.  -- Enke
> 

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: One comment on 9.1.2.2 Breaking Ties, draft-16
Date: Wed, 19 Dec 2001 14:00:41 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Yakov:
Just noticed that the algorithm described in this section may not
yield deterministic result in case of route reflection as the BGP
Identifier could be the same for two paths.

Could you add one more step:

 g) Prefer the route received from the lowest neighbor address.

This would also reflect the deployed code.

Thanks.  -- Enke

Date: Tue, 18 Dec 2001 16:42:36 -0500
To: RJ Atkinson <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Working Group notes from 12/13/01 meeting
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Ran:

Sandy's comment was that MD5 algorithm has some known
vulnerabilities.   (Sandy - Can send additional
information on the MD5 problems and/or a web site
with that information?)

If people object to these vulnerabilities in the MD5
protection, doesn't IP SEC with AH/ESP provide
less risk?   Ran - I'd love to hear the pro's and con's from
you on the list.

As to confidentiality,  I do not believe this was discussed
at the meeting.    There are sites using IP Sec for confidentiality
due to a business relationship (JIT ordering or other such time
based ordering issues).  However, this was not the point of the
discussion on the MD5 versus IP Sec.

Sue

At 12:52 PM 12/18/2001 -0500, RJ Atkinson wrote:

>         I don't see any advantage in using AH/ESP to protect
>BGP sessions as compared with using the TCP MD5 option.  The
>TCP MD5 option covers the TCP header, which is probably the
>critical portion (e.g. protects against forged RSTs as well
>as forged BGP data) in this situation.  I don't see a need
>for confidentiality at all in BGP in commercial environments.
>
>         Maybe I've missed something here, in which case maybe
>someone could throw me a clue.
>
>Ran
>[email-masked]

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Route Reflection
Date: Tue, 18 Dec 2001 19:49:09 +0200
Sender: [email-masked]

> Hi, all !
> Regards MIB for route reflection. There is an augments to the Peers table
> which is "Is reflector client" field, where about every peer I can
> configure
> non-client, client or meshed-client.
> My question is: when my router is reflector it's easy to configure about
> every
> peer is it a client or non-client. But what happens when my router is not
> a reflector,
> what should I configure about its peers ?
> And what does it mean "meshed client" ?
>     Thanks in advance.
>         Katya

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Capability advertisement in BGP
Date: Tue, 18 Dec 2001 19:43:18 +0200
Sender: [email-masked]

> Hello, all !
> I have a question regards Capabilities Advertisement (RFC 2842).
> Should I send as a capability optional parameters in Open message
> the following extensions:
> 1. Route Reflection
> 2. Route Flap Dampening
> 3. AS Confederations
> 4. Communities Attribute
>    Thanks in advance
>           Katya

Date: Tue, 18 Dec 2001 12:25:14 -0500
To: [email-masked], [email-masked] (Christopher W. Richardson), [email-masked], [email-masked], jeffrey Haas <[email-masked]>, Akira Kato <[email-masked]>, [email-masked]
From: Susan Hares <[email-masked]>
Subject: Working Group notes from 12/13/01 meeting
Sender: [email-masked]

--=====================_5727465==_
Content-Type: multipart/alternative;
	boundary="=====================_5727485==_.ALT"

--=====================_5727485==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

IDR Minutes 3:30pm to 5:30pm on 12/13/01 in Salt Lake City

Agenda:

1) Charter
2) Base Documents
         3) IP v6 issues on Base Documents
         4) Security Issues with BGP

Actions out of the meeting:
1) Charter reviewed
             2)  Sandy Murphy=92s will submit the security vulnerabilities=
 as=20
a working group document.

Discussion:

1) Charter

  Charter comments? Read & send comments to mail list.  One error was noted:
  Graceful Restart is missing.   This will be corrected in the charter this=
=20
week.

  No comments were received from the meeting.

2) Base Documents:

   -16  has been out on the mail list.
   -17 will include FSM & new appendix B.

    The clean-up of mib draft to match IETF MIB will go for
    last call in Jan for historical  [draft-ietf-idr-bgp4-mib-08.txt].

    Sue Hares covered differences from -15 to current and
    diff between current and 1771; slides to be posted.   No discussion
    in the meeting.

3) IP v6 issues around MP BGP for IP v6 deployment (RFC 2545)
a)      Router-id for IP v6 only BGP

       Alain Durand & Francis Dupont presented the router-id draft for
       BCP.   The router- id draft was sent to the mail list during the week=
 of
       IETF.    A IP v6 only router needs a unique router-id for BGP=20
peer.   Since the IP v6
       only address is 128 bits long, the 32 bit encoded address must use=20
other encoding.
       This draft proposes using the Class E space for the 32 bit address.

       The draft is a BCP because the 4 bytes may be too small in the=
 future.

      No opinions were listed in the working group.   The authors will=20
suggest that the
      Router-id draft be made a BCP.   Last call on the BCP will be made in=
=20
late December.
b)      RFC 2858  changes with the BGP4+ Peering Using IPv6 Link-local=
 Address
                (draft-kato-bgp-ipv6-link-local-00.txt)

     [3:50pm  3:55pm]

  RFC 2545 suggests that the IP v6 code uses either:
-       Global or
           -   Global and Link Local

      For peering at exchange points, Bill Manning and Akira Kato found=20
this to be
      wasteful of IP v6 addreses.   Therefore, in this draft
      Bill Manning and Akira Kato suggest that this list should also=20
include:
-       link local + interface address

      In RFC 2545 section 3:  nexthop,  the kato-bgp-ipv6-link-local draft=
=20
suggests that
      the BGP peer filling in:
a)      Global or global + link-local
The global address is filled in and ignored by the receiver if it is not=20
valid.
The link local address is then accepted and replaces the global address.

             Or,
b)  Specify the neighbor by link-local address
Current API for IP v6 requires all link-local addresses to have a link=20
local address and an interfaces inside the implementation.

This draft is both a BCP and suggests changes to the 2545 draft (2545bis)=20
and provides
BCP text.   This draft will be sent to the IDR mailing list with these=20
comments.

Implementation status is that there are two implementations that=
 inter-operate.

      Question:  1) Which global address should be placed in the next hop?
                     Answer: random is not a good idea, it should be user=20
configurable.
                 2) Which global address in the next hop?
                      Answer: Random not good idea.  Make it user=
 configurable

4)  MIBs (3:57 pm)

   Draft mib-8 replaces RFC 1657; pretty much done; publishing as=
 informational
   Problem with security section.   Last call will be done on the list in=20
January.

   2nd version of MIB to match current bgp draft and all additional BGP=
 drafts:
Draft-ietf-idr-bgp4-mibv2-01.

         There is a focus group working on BGP MIBs.   Anyone can join this=
=20
group,
         At:
                 [email-masked]
                 subscribe BGP-MIB

MIB needs to have further changes to accommodate the MP Extensions and=20
AFI/SAFI changes.

    Goal: have everything done by Minneapolis IETF and send to general list

    Questions: 1) ppvpn MIB has a bunch of BGP info in it =85 can that be=20
leveraged?
         Answer: yes, we're trying to not duplicate and reuse as much as=20
possible.

  4) Document status  see powerpoint presentations.

  5) BGP Security Issues 4:10
      a) Context from mail list:
         3 issues w/routers:
           Router access: ssh vs. telnet
           Router links: tcp/ip - tcp md5 vs. IPSec
           Securing routing information
         5 issues w/handling security in BGP information (sent out on mail=
=20
list)

       b)  Sandy Murphy - BGP Security Analysis 4:15  [See presentation]
          BGP protocol vulnerabilitieis

          Questions on Security
               1)(Sue Hares) How many people use AS sets?
        Answer: no hands;
        Cengiz Alaettinoglu  - there are less than 100 sets in the routing=
=20
tables]
        Jeff Haas:  You don't see the sets because most vendors choose a=20
common prefix
                    of common leading ASes.
                2)(Sandy Murphy) Are there any factual errors?  Should this=
=20
be a WG item?
         Should this be in 2 drafts?

            Discussion:

       Cengiz: In most schemes you still need to know as is author. to adv.
prefix, and this isn't part of BGP ... it must come out of band. Unless
such a new out of band system is created, then IRR is the only real=20
solution today.

       Sandy: IRR is the natural place to put this, which means we need to=
=20
get the IRR
used more.

                 3) (Bill Fenner)        Do we need a draft for using IPSeC=
=20
with BGP?
                         a. Bill Fenner will check with the IESG to see if=
=20
we need a profile draft
                 b. Sue Hares and Dave Ward will work on IP sec draft with=
 BGP
                 c. An applicability statement is a good place to talk=20
about MD5 versus IP sec

            4)  (Bill Fenner) Say there are 15k as-paths in the routing=
 table;
                 the router has to check signatures  on 15k as-paths/origin=
=20
pairs?]

         Sandy: the processing requirement for a full feed on start-up is=20
enormous;
         perhaps just start using paths until calculations are done]

Working Group vote on:
This document should describe the current vulnerabilities and BCP, and
possibly a second draft about things we need to build.   Sandy will
submit this as a working group draft.

   Motion accepted by the working group and the document will be accepted=20
as a working group
   document.

4:43 call for blue sheets; meeting adjourned.

--=====================_5727485==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<br>
<font face=3D"Courier New, Courier">IDR Minutes 3:30pm to 5:30pm on
12/13/01 in Salt Lake City<br>
<br>
<b>Agenda:<br>
<br>
</b>1) Charter<br>
2) Base Documents<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3) IP v6 issues on Base
Documents<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4) Security Issues with
BGP&nbsp; <br>
<br>
Actions out of the meeting:</font>
<dl>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>1) </font><font face=3D"Courier New, Courier">Charter reviewed=20
</font>
</dl>
</dl><font face=3D"Times New Roman, Times" size=3D4>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2)&nbsp; </font><font face=3D"Courier New, Courier">Sandy Murphy=92s will
submit the security vulnerabilities as a working group document.<br>
<br>
<b>Discussion:<br>
<br>
</b>1) Charter<br>
<br>
&nbsp;Charter comments? Read &amp; send comments to mail list.&nbsp; One
error was noted:<br>
&nbsp;Graceful Restart is missing.&nbsp;&nbsp; This will be corrected in
the charter this week. <br>
<br>
&nbsp;No comments were received from the meeting. <br>
<br>
2) Base Documents:<br>
<br>
&nbsp; -16&nbsp; has been out on the mail list.<br>
&nbsp; -17 will include FSM &amp; new appendix B.&nbsp; <br>
<br>
&nbsp;&nbsp; The clean-up of mib draft to match IETF MIB will go for
<br>
&nbsp;&nbsp; last call in Jan for historical&nbsp;
[draft-ietf-idr-bgp4-mib-08.txt].<br>
<br>
&nbsp;&nbsp; Sue Hares covered differences from -15 to current and<br>
&nbsp;&nbsp; diff between current and 1771; slides to be
posted.&nbsp;&nbsp; No discussion<br>
&nbsp;&nbsp; in the meeting. <br>
<br>
3) IP v6 issues around MP BGP for IP v6 deployment (RFC 2545)<br>
</font>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>a)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font=
 face=3D"Courier New, Courier">Router-id
for IP v6 only BGP<br>
<br>

</dl>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alain Durand &amp; Francis Dupont
presented the router-id draft for <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BCP.&nbsp;&nbsp; The router- id draft was
sent to the mail list during the week of<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IETF.&nbsp;&nbsp;&nbsp; A IP v6 only
router needs a unique router-id for BGP peer.&nbsp;&nbsp; Since the IP v6
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; only address is 128 bits long, the 32 bit
encoded address must use other encoding.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This draft proposes using the Class E
space for the 32 bit address.&nbsp; <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The draft is a BCP because the 4 bytes may
be too small in the future. <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; No opinions were listed in the working
group.&nbsp;&nbsp; The authors will suggest that the <br>
&nbsp;&nbsp;&nbsp;&nbsp; Router-id draft be made a BCP.&nbsp;&nbsp; Last
call on the BCP will be made in late December. <br>
</font>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>b)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font=
 face=3D"Courier New, Courier">RFC
2858&nbsp; changes with the BGP4+ Peering Using IPv6 Link-local
Address</font>
</dl>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
(draft-kato-bgp-ipv6-link-local-00.txt)<br>
<br>
&nbsp;&nbsp;&nbsp; [3:50pm&nbsp; 3:55pm]<br>
&nbsp;&nbsp; <br>
&nbsp;RFC 2545 suggests that the IP v6 code uses either:
<dl>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>Global
or
</dl>
</dl><font face=3D"Times New Roman, Times" size=3D4><x-tab>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
-&nbsp;&nbsp; </font>Global and Link Local<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; For peering at exchange points, Bill Manning and
Akira Kato found this to be <br>
&nbsp;&nbsp;&nbsp;&nbsp; wasteful of IP v6 addreses.&nbsp;&nbsp;
Therefore, in this draft <br>
&nbsp;&nbsp;&nbsp;&nbsp; Bill Manning and Akira Kato suggest that this
list should also include:
<dl>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>link
local + interface address<br>
<br>

</dl>
</dl>&nbsp;&nbsp;&nbsp;&nbsp; In RFC 2545 section 3:&nbsp; nexthop,&nbsp;
the kato-bgp-ipv6-link-local draft suggests that<br>
&nbsp;&nbsp;&nbsp;&nbsp; the BGP peer filling in:
<dl>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>a)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>Global or
global + link-local=20
<dd>The global address is filled in and ignored by the receiver if it is
not valid.
<dd>The link local address is then accepted and replaces the global
address.&nbsp; <br>
<br>

</dl>
</dl>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Or, <br>

<dl>
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>b)&nbsp; </font>Specify the neighbor by link-local address
<dd>Current API for IP v6 requires all link-local addresses to have a
link local address and an interfaces inside the implementation.<br>
<br>

</dl>
</dl>This draft is both a BCP and suggests changes to the 2545 draft
(2545bis) and provides<br>
BCP text.&nbsp;&nbsp; This draft will be sent to the IDR mailing list
with these comments.<br>
<br>
Implementation status is that there are two implementations that
inter-operate.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; Question:&nbsp; 1) Which global address should
be placed in the next hop?<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;
Answer: random is not a good idea, it should be user configurable.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
2) Which global address in the next hop?<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
Answer: Random not good idea.&nbsp; Make it user configurable<br>
<br>
4)&nbsp; MIBs (3:57 pm)<br>
<br>
&nbsp; Draft mib-8 replaces RFC 1657; pretty much done; publishing as
informational<br>
&nbsp; Problem with security section.&nbsp;&nbsp; Last call will be done
on the list in January.<br>
<br>
&nbsp; 2<font size=3D1><sup>nd</sup></font> version of MIB to match current
bgp draft and all additional BGP drafts:<br>
Draft-ietf-idr-bgp4-mibv2-01.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There is a focus group working
on BGP MIBs.&nbsp;&nbsp; Anyone can join this group,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; At:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font=
 color=3D"#0000FF"><u>[email-masked]<br>
</u></font><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x=
-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>subscribe
BGP-MIB<br>
<br>
MIB needs to have further changes to accommodate the MP Extensions and
AFI/SAFI changes.<br>
<br>
<br>
&nbsp;&nbsp; Goal: have everything done by Minneapolis IETF and send to
general list <br>
<br>
<br>
&nbsp;&nbsp; Questions: 1) ppvpn MIB has a bunch of BGP info in it =85 can
that be leveraged?<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Answer: yes, we're trying to
not duplicate and reuse as much as possible.<br>
<br>
&nbsp;4) Document status&nbsp; see powerpoint presentations.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
&nbsp;5) BGP Security Issues 4:10<br>
&nbsp;&nbsp;&nbsp;&nbsp; a) Context from mail list:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>3 issues
w/routers:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Router access: ssh
vs. telnet <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Router links:
tcp/ip - tcp md5 vs. IPSec<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Securing routing
information<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>5 issues
w/handling security in BGP information (sent out on mail list)<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b)&nbsp; Sandy Murphy - BGP Security
Analysis 4:15&nbsp; [See presentation]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BGP protocol
vulnerabilitieis<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Questions on
Security&nbsp;=20
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;
1)</font>(Sue Hares) How many people use AS sets?
</dl>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Answer: no hands;<i> <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cengiz Alaettinoglu</i>&nbsp; -
there are less than 100 sets in the routing tables]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jeff Haas:&nbsp; You don't see the
sets because most vendors choose a common prefix <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
of common leading ASes.<br>

<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
2)</font>(Sandy Murphy) Are there any factual errors?&nbsp; Should this
be a WG item?=20
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Should this be in 2
drafts? <br>
<br>

</dl>&nbsp;&nbsp;&nbsp;
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp; Discussion: <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cengiz: In most schemes you still need to
know as is author. to adv.=20
<dl>
<dd>prefix, and this isn't part of BGP ... it must come out of band.
Unless
<dl>
<dd>such a new out of band system is created, then IRR is the only real
solution today.<br>
<br>
<br>
<br>

</dl>
</dl>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sandy: IRR is the natural place to
put this, which means we need to get the IRR=20
<dl>
<dd>used more.<br>
<br>
<font face=3D"Times New Roman, Times" size=3D4>
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
3) (Bill Fenner)
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>Do we
need a draft for using IPSeC with BGP?
<dl><font face=3D"Times New Roman, Times" size=3D4>
<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a.
</font>Bill Fenner will check with the IESG to see if we need a profile
draft
</dl>
</dl><font face=3D"Times New Roman, Times" size=3D4><x-tab>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;</x-tab>b.
</font>Sue Hares and Dave Ward will work on IP sec draft with BGP<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face=3D"Times New=
 Roman, Times" size=3D4>c.
</font>An applicability statement is a good place to talk about MD5
versus IP sec<br>
<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;
4)&nbsp; (Bill Fenner) Say there are 15k as-paths in the routing table;
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>the
router has to check signatures&nbsp; on 15k as-paths/origin pairs?]<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sandy: the processing
requirement for a full feed on start-up is enormous;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; perhaps just start using paths
until calculations are done]<br>
<br>
Working Group vote on: <br>

<dl>
<dd>This document should describe the current vulnerabilities and BCP,
and=20
<dd>possibly a second draft about things we need to build.&nbsp;&nbsp;
Sandy will=20
<dd>submit this as a working group draft.<br>
<br>

</dl>&nbsp; Motion accepted by the working group and the document will be
accepted as a working group&nbsp;&nbsp;&nbsp; <br>
&nbsp; document. <br>
<br>
4:43 call for blue sheets; meeting adjourned.<br>
<br>
</html>

--=====================_5727485==_.ALT--

--=====================_5727465==_
Content-Type: application/msword; name="IDR-minutes-12-13.doc";
 x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IDR-minutes-12-13.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASQAAAAAAAAAA
EAAASwAAAAEAAAD+////AAAAAEgAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_5727465==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_5727465==_--

Date: Mon, 17 Dec 2001 14:45:58 -0500
From: Jeffrey Haas <[email-masked]>
To: Francis Dupont <[email-masked]>
Cc: Barry Friedman <[email-masked]>, Pekka Savola <[email-masked]>, Alain Durand <[email-masked]>, [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 11:40:08PM +0100, Francis Dupont wrote:
> => the issue about bigger router IDs is this cannot be done without
> changing the OPEN message format so it seems to be long term (:-)...

We must retain the format of the OPEN and NOTIFY messages for
backwards compatability.  

Whether we abandon backwards compatability or not is a different
question.

On Fri, Dec 14, 2001 at 12:22:20AM +0100, Francis Dupont wrote:
> => not easily: the identifier has to be split and the capability
> to be processed before the (partial!) identifier checked for collision.
> The simplest way is to change the BGP version but there are good reasons
> to wait before seriously propose that (:-)...

Or a mechanism roughly like this:
o Each side that wants to negotiate a extra-long Identifier sends
  a well-known value (0.0.0.0?) to each side with a capability
  noting the "extra long identifier" capability.
o Dynamic capability update is used (PPP-like) to finish things.

Obviously this would involve changing the fsm.  We also need to
decide what to do about fields that actually use the identifier.

Having the full address in the packet is a Nice Thing from an
operational perspective.  It avoids having to guess who did
something, whether that something is a reflector client,
an aggregator, etc.  It also means you expose things to the outside
world.

But this also means we get into arguments as to leaking inappropriate
ipv6 address scopes - i.e. don't leak site local to global peers.

One could thus argue that using something that simply has "local"
meaning is probably the right long term answer.

> [email-masked]

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 15:02:20 -0800
From: Barry Friedman <[email-masked]>
To: Francis Dupont <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, Barry Friedman <[email-masked]>, Pekka Savola <[email-masked]>, Alain Durand <[email-masked]>, [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

Francis Dupont [[email-masked]] wrote:
>  In your previous mail you wrote:
> 
>    IMO, we want to go to bigger router IDs and keep using actual
>    routable addresses for their values.  We can't do that now
>    and need something to deal with TODAY.  The draft addresses that.
>    
>    The current draft may prove to be sufficient over the long term.
>    
> => the issue about bigger router IDs is this cannot be done without
> changing the OPEN message format so it seems to be long term (:-)...
> 

Could be done via capabilities as with 4 bytes AS#?

Regards,
Barry

-- 
Barry Friedman      mailto:[email-masked]
Cisco Systems Inc.  phone:408-526-8284

Date: Thu, 13 Dec 2001 16:42:59 -0500
From: Jeffrey Haas <[email-masked]>
To: Barry Friedman <[email-masked]>
Cc: Pekka Savola <[email-masked]>, Alain Durand <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 12:17:37PM -0800, Barry Friedman wrote:
> Sorry to be dense, but how is it transitional? It seems to be a
> solution for systems without any ipv4 addresses. What replaces this
> in the long run?

True - in order to be transitional, it has to have something to 
transition to.

IMO, we want to go to bigger router IDs and keep using actual
routable addresses for their values.  We can't do that now
and need something to deal with TODAY.  The draft addresses that.

The current draft may prove to be sufficient over the long term.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 13:27:48 -0800
From: Barry Friedman <[email-masked]>
To: "John A. Tamplin" <[email-masked]>
Cc: Barry Friedman <[email-masked]>, [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

Hi John,

John A. Tamplin [[email-masked]] wrote:
> On Thu, 13 Dec 2001, Barry Friedman wrote:
> 
> > Thanks for the clarification. Agreed that the AS# solves the issue of
> > getting unique ID's. My other comment was that you could have a bigger
> > range of assignable ID's if you remove the 0xf.
> 
> But then you could have conflict with globally routable IPv4 addresses.
> The point of the leading 0xF is to avoid that conflict by having the 
> resulting number be in class E address space.

Right, makes sense to me now. :-)

Thanks,
Barry

-- 
Barry Friedman      mailto:[email-masked]
Cisco Systems Inc.  phone:408-526-8284

Date: Thu, 13 Dec 2001 13:23:15 -0800
To: Barry Friedman <[email-masked]>
From: Alain Durand <[email-masked]>
Subject: Re: router ID for IPv6 only BGP speaker
Cc: Barry Friedman <[email-masked]>, Jeffrey Haas <[email-masked]>, Pekka Savola <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 12:56 PM 12/13/2001 -0800, Barry Friedman wrote:
>Alain,
>
>Thanks for the clarification. Agreed that the AS# solves the issue of
>getting unique ID's. My other comment was that you could have a bigger
>range of assignable ID's if you remove the 0xf.

Yes, you'll have a larger range, but then you might collide with other 
IPv4-address derived RouterID.
This is a trade-off.

         - Alain.

Date: Thu, 13 Dec 2001 13:13:51 -0800
To: Jeffrey Haas <[email-masked]>, Pekka Savola <[email-masked]>, Francis Dupont <[email-masked]>
From: Alain Durand <[email-masked]>
Subject: Re: router ID for IPv6 only BGP speaker
Cc: [email-masked]
Sender: [email-masked]

At 01:39 PM 12/13/2001 -0500, Jeffrey Haas wrote:

>The section in question:
>
>       BGP Identifier:
>
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP speaker.  The
>          value of the BGP Identifier is determined on startup and is the
>          same for every local interface and every BGP peer.
>
>To the best of my knowledge, its impossible to assign class E
>addresses to any interface.

Then this text clearly needs to be changed in the -16 draft.

         - Alain.

Date: Thu, 13 Dec 2001 12:56:30 -0800
From: Barry Friedman <[email-masked]>
To: Alain Durand <[email-masked]>
Cc: Barry Friedman <[email-masked]>, Jeffrey Haas <[email-masked]>, Pekka Savola <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

Alain,

Thanks for the clarification. Agreed that the AS# solves the issue of
getting unique ID's. My other comment was that you could have a bigger
range of assignable ID's if you remove the 0xf.

Thanks,
Barry

Alain Durand [[email-masked]] wrote:
> At 10:19 AM 12/13/2001 -0800, Barry Friedman wrote:
> >I agree with Jeffrey. So can the 0xf and AS# be removed from
> >this? The 0xf means you just have 4 fewer bits to play with
> >and the AS# would seem to cause difficulties if someone wants
> >to use a 4 octet AS#. Also, the limit of 4096 ID's might be too
> >small. :-)
> 
> The problem is that the routerID is not "just a number"
> It needs to be unique in between peers
> B --- A --- C
> If A peers with B and C, then all 3 routerIDs will have to be differents.
> B --- A --- C --- D
> If D peers with C only, then B and D router ID do not need to be different, 
> but if
> B --- A --- C --- D
>          |________|
> D peers with also wtih A, then B and D needs to have different router ID...
> 
> SO, even globably unique routerID is not absolutely necessary, it
> makes things much simpler.  The suggested text provide a simple way
> to create an ID with those properties in the absence of a globally
> unique IPv4 address.  - Alain.

-- 
Barry Friedman      mailto:[email-masked]
Cisco Systems Inc.  phone:408-526-8284

Date: Thu, 13 Dec 2001 12:17:37 -0800
From: Barry Friedman <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Barry Friedman <[email-masked]>, Pekka Savola <[email-masked]>, Alain Durand <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

Jeffrey Haas [[email-masked]] wrote:
> On Thu, Dec 13, 2001 at 10:19:43AM -0800, Barry Friedman wrote:
> > I agree with Jeffrey. So can the 0xf and AS# be removed from
> > this? The 0xf means you just have 4 fewer bits to play with
> > and the AS# would seem to cause difficulties if someone wants
> > to use a 4 octet AS#. Also, the limit of 4096 ID's might be too
> > small. :-)
> 
> As the ID notes, its a transitional mechanism and thus probably
> appropriate.

Sorry to be dense, but how is it transitional? It seems to be a
solution for systems without any ipv4 addresses. What replaces this
in the long run?

> A better questions is are we willing to relax the base specification?

Sounds reasonable to me. The spec says BGP identifier has to be
a syntactically correct IP host address. Maybe instead it should just
specify the scoping requirements for the identifier, and recommend
ipv4 address when available?

Thanks,
Barry

-- 
Barry Friedman      mailto:[email-masked]
Cisco Systems Inc.

Date: Thu, 13 Dec 2001 14:28:21 -0500
From: Jeffrey Haas <[email-masked]>
To: Alain Durand <[email-masked]>
Cc: Barry Friedman <[email-masked]>, Pekka Savola <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 10:41:59AM -0800, Alain Durand wrote:
> The problem is that the routerID is not "just a number"
> It needs to be unique in between peers

Thats not sufficient.  Route reflection makes use of the
BGP Identifier.

Unique within an AS and additionally the border routers
of the AS must also peer with routers that have router-id's
distinct from the border-router's BGP IDentifiers.

This _does_ mean there can be duplication, but to avoid needless
collisions, some structure should be present.  The requirement
(for v4 peers) of a globally routable IP address satisifies
this need as does the proposed structured ipv6 transition 
mechanism.

One potential "solution" to something in the future (bgp-5?)
would be to make BGP Identifier/as tuples the item of comparison
rather than just the Identifer.  I think this would only affect
route reflectors.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 13:42:17 -0500
From: Jeffrey Haas <[email-masked]>
To: Barry Friedman <[email-masked]>
Cc: Pekka Savola <[email-masked]>, Alain Durand <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 10:19:43AM -0800, Barry Friedman wrote:
> I agree with Jeffrey. So can the 0xf and AS# be removed from
> this? The 0xf means you just have 4 fewer bits to play with
> and the AS# would seem to cause difficulties if someone wants
> to use a 4 octet AS#. Also, the limit of 4096 ID's might be too
> small. :-)

As the ID notes, its a transitional mechanism and thus probably
appropriate.

A better questions is are we willing to relax the base specification?

> Barry

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 13:39:55 -0500
From: Jeffrey Haas <[email-masked]>
To: Pekka Savola <[email-masked]>, Francis Dupont <[email-masked]>
Cc: Alain Durand <[email-masked]>, [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 08:10:48PM +0200, Pekka Savola wrote:
> On Thu, 13 Dec 2001, Jeffrey Haas wrote:
> > The current BGP specificiation insists that the BGP Identifier
> > be a semantically correct IPv6 address.  Class E addresses don't fit
> > that category. :-)
> 
> Hmm, it would be nice to see a semantically correct 32-bit IPv6 address..

My typo. :-P

The section in question:

      BGP Identifier:

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

To the best of my knowledge, its impossible to assign class E
addresses to any interface.

> The point here is that when a Joe Random Router sees a number it cannot
> make it into human readable unless it knows _what the human wants to see_.  
> BGP Id. could very well be an IPv4 address or one defined by a
> transtionary mechanism, the computer does not know.
> 
> Therefore, IMO, this comment does not apply that well, and it would be 
> nice to have it in a format where the human can read it too.. but just 
> nice, it's not a requirement IMO.

To given an example, BGP communities are essentially 32 bit numbers.
Convention leads us to interpret them as 2 site bit numbers.
Cisco, for example, will let you key them in either as a 32 bit
integer or in the AA:NN format.  To get it to display in the AA:NN
format, you have to turn a knob.

What I'm recommending is that in the presence of the proposed BCP,
a knob be added to allow interpretation of the BGP Identifier
in the BCP format for display or configuration purposes.

IMO, you could just look at it as a dotted quad and most people
would be happy.  Including the MIBs. :-)

On Thu, Dec 13, 2001 at 07:11:16PM +0100, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    The current BGP specificiation insists that the BGP Identifier
>    be a semantically correct IPv6 address.  Class E addresses don't fit
>    that category. :-)
>    
> => this is no more true:
>  - ID -16 doesn't insist

See the above paste from the spec.  

>  - MIBv2 says this is just an identifier.

MIBv2 says this for a good reason. :-)
But MIBv2 still needs work, and this thread is part of it.

> => so we agree! BTW are there some implementations which verify
> that the Identifier is a regular IPv4 address ?

The UNH interoperability tests do this.  Others have noted
the 0.0.0.0 problem.

> => IMHO to be globally unique is not very important because Indentifiers
> are used in constrainted scopes, but it is a fine property (don't
> need to check for collisions).

The BGP Identifiers of peers adjacent to your AS Border routers
should be distinct from those within your AS.  But I think that
may be the only other requirement.  

> [email-masked]

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 10:41:59 -0800
To: Barry Friedman <[email-masked]>, Jeffrey Haas <[email-masked]>
From: Alain Durand <[email-masked]>
Subject: Re: router ID for IPv6 only BGP speaker
Cc: Pekka Savola <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 10:19 AM 12/13/2001 -0800, Barry Friedman wrote:
>I agree with Jeffrey. So can the 0xf and AS# be removed from
>this? The 0xf means you just have 4 fewer bits to play with
>and the AS# would seem to cause difficulties if someone wants
>to use a 4 octet AS#. Also, the limit of 4096 ID's might be too
>small. :-)

The problem is that the routerID is not "just a number"
It needs to be unique in between peers
B --- A --- C
If A peers with B and C, then all 3 routerIDs will have to be differents.
B --- A --- C --- D
If D peers with C only, then B and D router ID do not need to be different, 
but if
B --- A --- C --- D
         |________|
D peers with also wtih A, then B and D needs to have different router ID...

SO, even globably unique routerID is not absolutely necessary, it makes things
much simpler.
The suggested text provide a simple way to create an ID with those properties
in the absence of a globally unique IPv4 address.

         - Alain.

Date: Thu, 13 Dec 2001 10:19:43 -0800
From: Barry Friedman <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Pekka Savola <[email-masked]>, Alain Durand <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

I agree with Jeffrey. So can the 0xf and AS# be removed from
this? The 0xf means you just have 4 fewer bits to play with
and the AS# would seem to cause difficulties if someone wants
to use a 4 octet AS#. Also, the limit of 4096 ID's might be too
small. :-)

Barry

Jeffrey Haas [[email-masked]] wrote:
> On Thu, Dec 13, 2001 at 07:26:20PM +0200, Pekka Savola wrote:
> > A router that is dual stack doesn't know, however, how this should be 
> > printed -- is it an IPv4 or IPv6 router-id?
> 
> The current BGP specificiation insists that the BGP Identifier
> be a semantically correct IPv6 address.  Class E addresses don't fit
> that category. :-)
> 
> > One could hardcode it to check for class E addresses, but IMO that might 
> > be a bad idea.
> 
> IMO, the Identifier is Just A Number.  IMO, the current spec should
> be relaxed to recommend that, for a v4 speaker, that the Identifier
> be an assigned ipv4 address, preferably a globally routable one.
> In the case of v6, the transitional mechanism is a good start.
> 
> But in either case, it should be treated as Just A Number.  So
> long as it satisfies the properties that a BGP Identifier requires
> in an AS, its not terribly important what it is, excepting
> perhaps 0.0.0.0 and 255.255.255.255, and maybe not even then.
> 
> > Pekka Savola                 "Tell me of difficulties surmounted,
> 
> -- 
> Jeff Haas 
> NextHop Technologies

-- 
Barry Friedman      mailto:[email-masked]
Cisco Systems Inc

To: [email-masked]
Cc: [email-masked]
Subject: Re: router-id discussion
Date: Thu, 13 Dec 2001 10:03:11 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Looks like we are going in circles on this topic. I have included
some email discussions from 9 month ago.

IMO, the router-id is just a number which only needs to be unique
within an AS. We just need to formalize this notion a little bit.

-- Enke

------- Forwarded Message

To: Randy Bush <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: For Alain Durand 
In-Reply-To: Message from Randy Bush <[email-masked]> 
   of "Thu, 22 Mar 2001 09:49:55 CST." <[email-masked]> 
Date: Sat, 24 Mar 2001 15:23:58 -0800
From: Enke Chen <[email-masked]>
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk

Randy,

> From: Randy Bush <[email-masked]>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> To: Susan Hares <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Fwd:  For Alain Durand
> References: <[email-masked]>
> Message-Id: <[email-masked]>
> Date: Thu, 22 Mar 2001 09:49:55 -0600
> Sender: [email-masked]
> Precedence: bulk
> 
> why is it necessary to expand the size of the router id?  does it need to be
> an ip address, or is it just an id?

It is really just an id. Some ISPs simply assign the id's sequentially like
1, 2, 3 ... on their networks. This id itself does not need to be globally
unique. What needs to be unique is the pair <asn, router-id>. This part may
not be clear in the spec..  How about we do this:

     o clarify this uniqueness.
     o add some text in the collision resolution portion to favor the one
       with large AS number when the router-id's are equal.

I do not see any need to expand this field. It seems to be wastful and
introduces unnecessary complexity.

- -- Enke

------- End of Forwarded Message

Date: Thu, 13 Dec 2001 12:51:31 -0500
From: Jeffrey Haas <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: Alain Durand <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 07:26:20PM +0200, Pekka Savola wrote:
> A router that is dual stack doesn't know, however, how this should be 
> printed -- is it an IPv4 or IPv6 router-id?

The current BGP specificiation insists that the BGP Identifier
be a semantically correct IPv6 address.  Class E addresses don't fit
that category. :-)

> One could hardcode it to check for class E addresses, but IMO that might 
> be a bad idea.

IMO, the Identifier is Just A Number.  IMO, the current spec should
be relaxed to recommend that, for a v4 speaker, that the Identifier
be an assigned ipv4 address, preferably a globally routable one.
In the case of v6, the transitional mechanism is a good start.

But in either case, it should be treated as Just A Number.  So
long as it satisfies the properties that a BGP Identifier requires
in an AS, its not terribly important what it is, excepting
perhaps 0.0.0.0 and 255.255.255.255, and maybe not even then.

> Pekka Savola                 "Tell me of difficulties surmounted,

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 12:33:06 -0500
From: Greg Hankins <[email-masked]>
To: [email-masked]
Subject: Re: BGP Security Analysis
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Nov 21, 2001 at 04:39:25PM -0500, [email-masked] wrote:
>Some of you may remember a draft I wrote starting a couple of years ago
>that talked about the vulnerabilities in BGP and desribed several possible
>security solutions and their costs.  That draft went through four versions
>and was presented at some of the idr meetings.

Interesting and well-written.  I put some thought into this topic a while 
ago and would like to offer two additional points.

1. The first thing I started to look at was the behavior of each vendor's
   IP stack and BGP implementation.  It would be fairly trivial to detect
   which router vendor is deployed using nmap to do OS fingerprinting.
   On top of that, each vendor's BGP implementation has subtle differences
   that may leave it vulnerable to BGP fingerprinting and race conditions.
   For example, vendor X does not accept a connection from peer S if it
   has not been configured.  But vendor Y accepts and then closes the
   connection from peer S if is has not been configured.  This can easily
   be mapped by just telneting to port 179.

2. The most important thing I'd like to add is that you should consider
   another category of damage, which is an actual protocol attack against
   the router causing BGP or the router to crash.  In this case, valid BGP
   messages can be crafted in a malicious way that could create problems.
   For example, what would happen if a peer sent an AS_PATH with 1000
   paths, 500 communities, or 300 cluster IDs?  I'm sure there would be
   interesting results.  Or, what would happen if someone sent invalid
   messages.  Most vendors probably have implemented parameter checking,
   but it may be possible to cause some overflows with invalid messages.
   At the very least, it would definitely cause a session flap.

   Although this would certainly cause some of the effects you mention,
   I think it is beneficial to explicitly state this.

Regards,
Greg

-- 
Greg Hankins <[email-masked]> | Riverstone Networks, Inc.
Corporate Systems Engineering             | 5200 Great America Parkway
http://www.riverstonenet.com/             | Santa Clara, CA 95054
+1 404 434 0355                           | +1 408 878 6500

Date: Thu, 13 Dec 2001 12:15:29 -0500
From: Jeffrey Haas <[email-masked]>
To: Alain Durand <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked], [email-masked]
Subject: Re: router ID for IPv6 only BGP speaker
Sender: [email-masked]

On Thu, Dec 13, 2001 at 08:37:30AM -0800, Alain Durand wrote:
> I'll ask the question this afternoon in the wg: "how important is it to 
> have a human readable router-ID?"

Computers are very good at making machine readable into human readable. :-)

>          - Alain.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 13 Dec 2001 08:37:30 -0800
To: Pekka Savola <[email-masked]>, <[email-masked]>
From: Alain Durand <[email-masked]>
Subject: Re: router ID for IPv6 only BGP speaker
Cc: <[email-masked]>
Sender: [email-masked]

At 10:07 AM 12/13/2001 +0200, Pekka Savola wrote:
>Hi,
>
>Using class E seems IMO a good approach.
>
>A few points.
>
>1) When you see a router ID E1000000, how many would think "Aha! this is
>router 0 from AS1000", not from AS4096 as it really is?

If you print things in Hex, You're suppose to understand how to read Hex.

>2) A note about 32-bit AS numbers (this to be reviwed if that approach is
>adopted) might be appropriate.

Yes, I agree, we need a note to say something about that.

>3) IMO, we should perhaps reserve 8 bits for class E "identifier".  This
>way, if the router-id is printed in dotted-quad form, it's easier to
>calculate the originating AS in the head from the middle two numbers.
>
>If 8 bits is not enough to enumerate all v6-routers in an AS, the number
>space could be expanded so that when all are exhausted, you're free to
>select the next class E identifier; that is:
>
>normal case:
>
>8bit 16bit 8bit
>0xF0 [ASN] [local]
>
>when you've used your local bits, you could use like:
>
>0xF1 [ASN] [local]
>
>etc.
>
>I'm not sure if having a more "human-understandable" form of router-id
>representation is worth it, though?
>
>For now, as BCP, it might even be very well enough to just define 8 bits
>for local and that's it.

I'll ask the question this afternoon in the wg: "how important is it to 
have a human readable router-ID?"

         - Alain.

Date: Wed, 12 Dec 2001 22:19:03 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Re: IDR notes
Cc: Susan Hares <[email-masked]>
Sender: [email-masked]

>>The agenda for IDR is:
>>
>>         IDR charter
>>         IDR Document Changes (Base draft)
>>         IDR MIBs

             IP v6 router-id BCP

>>         IDR Security Risk analysis

I missed adding this point to the agenda.   The presentation
went out on the list first.

Alain --- thanks for catching this.

Sue

Date: Wed, 12 Dec 2001 21:55:57 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Router-id presentation -
Sender: [email-masked]

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

I missed sending the router id presentation earlier today.

Sue Hares
--=====================_15429556==_
Content-Type: application/octet-stream; name="RouterID1.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="RouterID1.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAADQAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////FgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAD+/////v///w8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAD+/////v//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_15429556==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_15429556==_--

Date: Wed, 12 Dec 2001 16:20:44 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: IDR notes
Cc: [email-masked], jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]

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

The agenda for IDR is:

	IDR charter
	IDR Document Changes (Base draft)
	IDR MIBs
	IDR Security Risk analysis

The following power point files give the 1st three presentations for
IDR for Thursday.   IDR Security risk analysis will be sent
out tommorrow.

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

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAkwAAAAAAAAAA
EAAAtAAAAAEAAAD+////AAAAAJEAAACSAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
--=====================_29063080==_
Content-Type: application/octet-stream; name="mib-update-ietf52.ppt";
 x-mac-type="534C4433"; x-mac-creator="50505433"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="mib-update-ietf52.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAATwAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAE4AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
--=====================_29063080==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_29063080==_--

From: Vivek Menezes <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: bgp restart draft
Date: Tue, 11 Dec 2001 20:55:14 -0800
Sender: [email-masked]

in the Restart Flags section in section 5 of the restart draft it would be
better if we added

" when the receiving system has not restarted and it receives the restart
flag with the bit not set it should not wait for the end-of-rib marker 
from the speaker before advertising routing information to the speaker" or
"if a system doesnt restart it should ignore the restart flag for the
purpose of advertising routes"

I think its better if we made it clear.

Also the restart time in seconds could be changed to a 28 bit time in
milliseconds.

Cheers, vivek.

Date: Tue, 11 Dec 2001 09:21:11 -0800
To: [email-masked]
From: Alain Durand <[email-masked]>
Subject: router ID for IPv6 only BGP speaker
Sender: [email-masked]

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

>Date: Sun, 09 Dec 2001 13:22:43 -0800
>To: [email-masked]
>From: Alain Durand <[email-masked]>
>Subject: router ID for IPv6 only BGP speaker
>
>Hi,
>
>Here is a slightly updated text of the router ID for IPv6 only draft.
>There will be a (short) presentation in IDR this week.
>Main change is we remove the suggestion to use 128 bit routerID
>and we fixed the format by using class E addresses.
>
>This draft is candidate for BCP status.
>
>Text included.
>
>         - Alain.

--=====================_4385816==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="routerid-01.txt"

Internet Engineering Task Force=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Francis Dupont
INTERNET DRAFT=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ENST=
 Bretagne
Expires in June 2002=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alain Durand
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 SUN Microsystems
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0  December 5. 2000

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 BGP4 router ID for IPv6 only=
 routers

=A0=A0=A0=A0=A0=A0=A0=A0 <draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt>

Status of this Memo
=A0=A0=20
=A0=A0 This document is an Internet Draft and is in full conformance with
=A0=A0 all provisions of Section 10 of RFC 2026.

=A0=A0 This document is an Internet-Draft.=A0 Internet-Drafts are working
=A0=A0 documents of the Internet Engineering Task Force (IETF), its
=A0=A0 areas, and its working groups.=A0 Note that other groups may also
=A0=A0 distribute working documents as Internet-Drafts.

=A0=A0 Internet-Drafts are draft documents valid for a maximum of six
=A0=A0 months and may be updated, replaced, or obsoleted by other
=A0=A0 documents at any time.=A0 It is inappropriate to use Internet-
=A0=A0 Drafts as reference material or to cite them other than as
=A0=A0 "work in progress."

=A0=A0 The list of current Internet Drafts can be accessed at
=A0=A0 http://www.ietf.org/ietf/1id-abstracts.txt

=A0=A0 The list of Internet-Draft Shadow Directories can be accessed at
=A0=A0 http://www.ietf.org/shadow.html.

=A0=A0 Distribution of this memo is unlimited.

Abstract

=A0=A0 BGP4 [1] uses a 32 bit field to identify router (the so called
   "router-IDs"). In IPv4 domain, an IPv4 address of the router
   is typically used in this field.
   In an IPv6 routing domain, routers may very well not have any IPv4
   Addresses. This document provides a simple way to form a globally
   Unique ID in such a case.

1. Introduction

   BGP4 [1] extension for IPv6 are defined in [2] and [3].
   However, BGP4 uses a 32 bit field known as the router ID.
   This router ID is used in:

=A0=A0 BGP4 [1] uses the router ID as an identifier in:
- BGP Identifier in OPEN messages (local use)
- AGGREGATOR (optional transitive) attributes
=A0=A0=A0 - ORIGINATOR_ID (optional non-transitive) attributes [4]
=A0=A0=A0 - CLUSTER_LIST (optional non-transitive) attributes [4]

   The AGGREGATOR attributes contain an Autonomous
   System (AS) number with the IP address of the BGP speaker
   that formed the aggregate route. It is the only transitive,
   (i.e. non local) use of the router ID.

   The router ID should be somehow unique and BGP implementations
   should provide a way to manually set it. This field typically
   contains one of the IPv4 addresses of the BGP4 speaker.
   In an IPv6 domain, some router may have IPv4 addresses,
   and some other may very well not have any. On those routers,
   one can not assigned random values to the router ID, as it could
   conflict with the router ID derived from an IPv4 addresses on
   another dual stack router.

   This document specifies a simple way to construct a somehow
   globally unique 32 bit router ID.

2. Solution

   In the absence of a globally unique IPv4 address on the router,
   the 32 bit routing ID is constructed with:

=A0=A0=A0 - 4 bits set to one (as for an old reserved class E IPv4 address),

=A0=A0=A0 - 16 bits set to the AS number (a global AS number
=A0=A0=A0=A0=A0 SHOULD be used if the router ID can be seen outside the=
 routing
=A0=A0=A0=A0=A0 domain).

=A0=A0=A0 - 12 bits manually allocated within the domain. This allows for=
 4096
      different router IDs in each routing domain.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1 1 1=
 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0 +-------+-------------------------------+-----------------------+
=A0=A0 |=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 |=A0 0xF=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 AS=A0 Number=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 |=A0 Locally allocated=A0=A0=A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=20
=A0=A0 +-------+-------------------------------+-----------------------+

3. Security Considerations

=A0=A0 The usage of fake IPv4 address of this form minimizes accidental
=A0=A0 or deliberate confusions (ie. same router ID for two different
=A0=A0 BGP speakers).

4. References

=A0=A0 [1] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
=A0=A0=A0=A0=A0=A0 RFC 1771, March 1995.

=A0=A0 [2] T. Bates, Y. Rekhter, R. Chandra, D. Katz, "Multiprotocol
=A0=A0=A0=A0=A0=A0 Extensions for BGP-4", RFC 2858, June 2000.

=A0=A0 [3] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol Extensions
=A0=A0=A0=A0=A0=A0 for IPv6 Inter-Domain Routing", RFC 2545, March 1999.

=A0=A0 [4] T. Bates, R. Chandra, E. Chen, "BGP Route Reflection -
=A0=A0=A0=A0=A0=A0 An Alternative to Full Mesh IBGP", RFC 2796, April 2000.

5. Author's Address

=A0=A0 Francis Dupont
=A0=A0 ENST Bretagne
=A0=A0 Campus de Rennes
=A0=A0 2, rue de la Chataigneraie
=A0=A0 BP 78
=A0=A0 35512 Cesson-Sevigne Cedex
=A0=A0 FRANCE
=A0=A0 Fax: +33 2 99 12 70 30
=A0=A0 EMail: [email-masked]

=A0=A0 Alain Durand
=A0=A0 SUN Microsystems, Inc
=A0=A0 901 San Antonio Road
=A0=A0 MPK17-202
=A0=A0 Palo Alto, CA 94303-4900
=A0=A0 USA
=A0=A0 EMail: [email-masked]

Expire in 6 months (June 6, 2002)

--=====================_4385816==_--

Date: Mon, 10 Dec 2001 22:22:56 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Optional Agenda items - Security issues
Sender: [email-masked]

On Thu, Dec 06, 2001 at 07:33:48AM -0500, [email-masked] wrote:
> Just signing the origination is one of the techniques mentioned in the
> draft.  Of course, it leaves you with other vulnerabilitites from bogus
> AS-PATHS.  The other techniques give more protection at higher cost.

Agreed.  However, the cost in processor to verify the signatures
may be excessive.  "How high is too high?"

Has anyone actually done a risk analysis to determine where we
get our biggest bang for the buck?

> --Sandy

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 6 Dec 2001 13:59:49 -0800
From: Barry Friedman <[email-masked]>
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Multiple Instances of BGP
Sender: [email-masked]

Hi Mareline,

The local-as knob might be what you're looking for:

http://www.cisco.com/warp/public/459/39.html

Regards,
Barry

Mareline Sheldon [[email-masked]] wrote:
> Hi All,
> It is said that the feature to put a BGP router in two different autonomous
> systems finds its use when an ISP is migrating from one AS to the another. I
> am at a loss to understand as to how can this be useful ?
> 
> I was unable to find any help/reference material on CISCO's site ..
> 
> Is anybody aware of any links ??
> 
> regards,
> 
> mareline s.

-- 
Barry Friedman      mailto:[email-masked]
Code Dependent      phone:408-526-8284
Cisco Systems Inc.  "I don't necessarily agree with everything I say."
                         -- Marshall McLuhan 

Date: Thu, 6 Dec 2001 13:58:39 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Tian Fang <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Selecting the best route to advertise ?
Sender: [email-masked]

Tian,

	Check the archives;  this has come up several times on
the list.  

IMO:
	A good router vendor would offer hooks for both:

	1> Advertise despite inactive status of route

	2> Advertise only if BGP route is used in FIB or if 
	   exact match in FIB from protocol with higher relative
           protocol preference matches BGP routes NH.

On Thu, 6 Dec 2001, Tian Fang wrote:

> Hi all,
> 
> I have a question for selection the best route to advertise.
> 
> Let's say a router gets two routes for the same destination from eBGP and
> another protocol (OSPF for instance). If the preference for OSPF routes is
> better than that of BGP routes. The route from OSPF will be installed in the
> FIB. Without redistribute OSPF route into BGP, which route should be
> advertised to other BGP peers, or none of them?
> 
> 1. With advertising the BGP route, the router sends some route which it
> doesn't use.
> 2. With advertising the OSPF route, it is wrong, because no redistribution
> has been done.
> 3. With advertising none route, user will be confused if just investigating
> the BGP configuration.
> 
> So what way should be followed in the implementation?
> 
> Regards,
> Tian Fang
> 

Date: Thu, 6 Dec 2001 16:08:11 -0500 (EST)
From: [email-masked]
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Multiple Instances of BGP
Sender: [email-masked]

> Hi All,
> It is said that the feature to put a BGP router in two different autonomous
> systems finds its use when an ISP is migrating from one AS to the another. I
> am at a loss to understand as to how can this be useful ?
> 
> I was unable to find any help/reference material on CISCO's site ..

peer-as is your friend.

Alex

Date: Thu, 6 Dec 2001 13:48:48 -0500
From: Jeffrey Haas <[email-masked]>
To: Tian Fang <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Selecting the best route to advertise ?
Sender: [email-masked]

>From section 9.1.3 for draft-ietf-idr-bgp4-16:
:   All routes in the Loc-RIB shall be processed into Adj-RIBs-Out
:   according to configured policy. This policy may exclude a route in
:   the Loc-RIB from being installed in a particular Adj-RIB-Out.  A
:   route shall not be installed in the Adj-Rib-Out unless the
:   destination and NEXT_HOP described by this route may be forwarded
:   appropriately by the Routing Table

On Thu, Dec 06, 2001 at 12:34:39PM -0500, Tian Fang wrote:
> Let's say a router gets two routes for the same destination from eBGP and
> another protocol (OSPF for instance). If the preference for OSPF routes is
> better than that of BGP routes. The route from OSPF will be installed in the
> FIB. Without redistribute OSPF route into BGP, which route should be
> advertised to other BGP peers, or none of them?
> 
> 1. With advertising the BGP route, the router sends some route which it
> doesn't use.

Which may not be a problem so long as the forwarding path is identical.

> 2. With advertising the OSPF route, it is wrong, because no redistribution
> has been done.

If you've advertised it (originated it), you've redistributed it into
your BGP.

> 3. With advertising none route, user will be confused if just investigating
> the BGP configuration.

Both implicit and explicit aggregation will cause apparent
forwarding abnormalities from the view outside of the AS.

> So what way should be followed in the implementation?

Its left as an implementation detail. :-)

This is also a network design issue.  If you're getting a prefix
in your IGP covered by your BGP, you should probably be originating
the reachability anyway.  You had better hope that you're not
accepting BGP routes for your AS/confederation from outside your
AS/confederation.  If you're redistributing your IGP into your BGP,
you should probably make sure that you only do it at border routers.

> Tian Fang

-- 
Jeff Haas 
NextHop Technologies

From: Tian Fang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Selecting the best route to advertise ?
Date: Thu, 6 Dec 2001 12:34:39 -0500 
Sender: [email-masked]

Hi all,

I have a question for selection the best route to advertise.

Let's say a router gets two routes for the same destination from eBGP and
another protocol (OSPF for instance). If the preference for OSPF routes is
better than that of BGP routes. The route from OSPF will be installed in the
FIB. Without redistribute OSPF route into BGP, which route should be
advertised to other BGP peers, or none of them?

1. With advertising the BGP route, the router sends some route which it
doesn't use.
2. With advertising the OSPF route, it is wrong, because no redistribution
has been done.
3. With advertising none route, user will be confused if just investigating
the BGP configuration.

So what way should be followed in the implementation?

Regards,
Tian Fang

Date: Thu, 06 Dec 2001 10:08:35 -0500
To: David Meyer <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Cc: Susan Hares <[email-masked]>, Russ White <[email-masked]>, Tony Barber <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I've got 7 for and 3 for later.
We'll hold it at the end of the meeting.  We'll post slides
for this talk prior to the talk so you can re-evaluate
your Thursday pm schedule.

Sue

At 04:25 PM 12/5/2001 -0800, David Meyer wrote:
> >> >I think I'd rather have some time to look it over and think
> >> >through the issues before discussing this at the working
> >> >group. So, I'd say present it the next one in march.
>
>I agree with Russ on this one.
>
>Dave
>

From: "Mareline Sheldon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Multiple Instances of BGP
Date: Thu, 6 Dec 2001 19:55:41 +0530
Sender: [email-masked]

Hi All,
It is said that the feature to put a BGP router in two different autonomous
systems finds its use when an ISP is migrating from one AS to the another. I
am at a loss to understand as to how can this be useful ?

I was unable to find any help/reference material on CISCO's site ..

Is anybody aware of any links ??

regards,

mareline s.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Thu, 06 Dec 2001 09:12:43 -0500
To: Alex Zinin <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Cc: Susan Hares <[email-masked]>, Russ White <[email-masked]>, Tony Barber <[email-masked]>, [email-masked], <[email-masked]>
Sender: [email-masked]

Alex:

Will publish.   We'll get the slides and post by Tuesday.

Sue

At 08:23 PM 12/5/2001 -0800, Alex Zinin wrote:

>Susan,
>
>  As long as the slides and the minutes are submitted
>  to the IETF secretariat (which hasn't been the case,
>  btw), and the in-room discussion is followed up on
>  the mailing list to make sure those who can't attend
>  this time are still in sync, I vote to present.
>
>--
>Alex Zinin
>
>Wednesday, December 05, 2001, 4:22:41 PM, Susan Hares wrote:
>
> > It's 3 to present now.  2 to defer to March.
>
> > Any other votes?  Please vote now.
>
> > Sue
>
> > At 07:11 PM 12/5/2001 -0500, Russ White wrote:
>
> >>I think I'd rather have some time to look it over and think
> >>through the issues before discussing this at the working
> >>group. So, I'd say present it the next one in march.
> >>
> >>Russ
> >>
> >>On Wed, 5 Dec 2001, Susan Hares wrote:
> >>
> >> >
> >> > I'll take you as 1 vote for the presentation.
> >> > Does anyone else want to see the presentation?
> >> >
> >> > Please speak up today!!
> >> >
> >> > Sue
> >> >
> >> > At 05:50 PM 12/5/2001 +0000, Tony Barber wrote:
> >> > >I think it is worth revisiting Sue, within my organisation we are 
> seeing a
> >> > >customer driven requirement for it.
> >> > >
> >> > >
> >> > >At 12:34 PM 05/12/01 -0500, Susan Hares wrote:
> >> > > >
> >> > > >Sandy Murphy re-issued the following draft:
> >> > > >
> >> > > >  Network Working Group Sandra Murphy
> >> > > >  INTERNET DRAFT NAI Labs
> >> > > >  draft-ietf-murphy-bgp-secr-04.txt November 2001
> >> > > >
> >> > > >Sandy states that:
> >> > > >
> >> > > >For several reasons (promises to a couple of IESG people and others,
> >> > > >the recent CERT report mentioning increasing concern about routing
> >> > > >protocols attacks, the IAB BGP architecture report's security
> >> > > >considerations section, etc.), I've decided to try to resurrect this
> >> > > >work.
> >> > > >
> >> > > >Is anyone interested in seeing this presentation at the IDR meeting?
> >> > > >Would anyone like to see it after with some new implementations 
> details
> >> > > >in 3 months?
> >> > > >
> >> > > >Please chime if you wish to see this work.  A silence will be taken
> >> > > >as a "no" vote.
> >> > > >
> >> > > >Just to warm up any discussion, security of BGP has 3 issues:
> >> > > >
> >> > > >       1) router security - SSH instead of telnet
> >> > > >       2) Link security - TCP MD5 or IP Sec with TCP
> >> > > >        3) BGP protocol security - as sandy starts out.
> >> > > >
> >> > > >There have been 5 problems with BGP Security in the past, and
> >> > > >with MPBGP usage we add a 6 problem:
> >> > > >
> >> > > >       1) Scaling
> >> > > >
> >> > > >               Security based on an NLRI causes lots of overhead
> >> > > >               in the protocol.   It is best done when you pack
> >> > > >               1 NLRI per packet.
> >> > > >
> >> > > >       2) aggregation of routes creates security problems
> >> > > >
> >> > > >               This is aggregation of NRLIs and AS paths to 
> sequences.
> >> > > >
> >> > > >       3) The "Start-up" problem exists if "Certificates" must be
> >> > > >           queried as new updates are created or out
> >> > > >
> >> > > >               You can store certificates for routes (nlri, ASpaths)
> >> > > >               on a disk if you know about them before hand.
> >> > > >
> >> > > >               DNS or another mechanism that goes across the network
> >> > > >               has a start-up problem.
> >> > > >
> >> > > >               Some algorithms let you have two states of data:
> >> > > >               pre-security and post-security.   After you set-up
> >> > > >               the initial routes learned, you start overwriting
> >> original
> >> > > >               non-secure routes with secure routes.
> >> > > >
> >> > > >       4) Certificate passing scheme must be set-up
> >> > > >
> >> > > >       5) Addition of Communities and Deletion also causes 
> problems in
> >> > > >               securing the network.
> >> > > >
> >> > > >       6) MPBGP issues of security IP v4 data which can be in the
> >> > > >               nlri and the MPBGP portion.
> >> > > >
> >> > > >
> >> > > >Any work, should be looked at in terms of defining risks and solving
> >> > > >these overall problems.
> >> > > >
> >> > > >Please chime in if you want to continue this discussion on the 
> IDR list.
> >> > > >
> >> > > >
> >> > > >Sue Hares
> >> > > >
> >> > > >
> >> >
> >> >
> >>
> >>_____________________________
> >>[email-masked] <>< Grace Alone

Date: Thu, 6 Dec 2001 07:33:48 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Optional Agenda items - Security issues
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>      4) Certificate passing scheme must be set-up

The SBGP project originally wanted to include the certificates in the BGP
exchange.  They decided that was a lot of duplicate info and that it would
be better to download a bunch of certs each day as part of startup activity.
(I'm cc-ing them to make sure I'm not totally misstating here.)

>IMO, the operational community would mostly be happy with
>"is As-foo allowed to originate this prefix?"  This would address
>a large swath of the immediate operational issues.

Just signing the origination is one of the techniques mentioned in the
draft.  Of course, it leaves you with other vulnerabilitites from bogus
AS-PATHS.  The other techniques give more protection at higher cost.

--Sandy

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>
Subject: BGP on a Distributed Architecture
Date: Thu, 6 Dec 2001 12:17:22 +0530
Organization: Samsung India Operations
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0391_01C17E4F.F5385370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,
My previous mail had an attachment which was not properly formatted. 
Resending it.

Regards,
Manav Bhatia

"C is not a big language, and is not well served by a big book." -- K&R2

------=_NextPart_000_0391_01C17E4F.F5385370
Content-Type: application/msword;
	name="bgp_distribution.doc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="bgp_distribution.doc"

Hi,

A network element is composed of numerous logically separated entities =
that cooperate to provide a given functionality (such as a routing or IP =
switching) and yet appear as a normal integrated network element to =
external entities. Two primary types of network element components =
exist: control-plane components and forwarding-plane components (ASIC). =
A standard set of mechanisms for connecting these components would =
provide increased scalability and allow the control and forwarding =
planes to evolve independently thus promoting faster innovation.

Going a step further, we conglomerate these various network elements and =
put them on an Ethernet to form a truly integrated network element [read =
as, terabit router] composed of multiple packet processing engines =
interconnected to form a logical whole.
[Ref to the figure below]

-------------------------------------------------------------------------=
----
|   --------------------------------        =
------------------------------- |     |   | NE1                          =
|        |  NE2                        | |    |   |            =
-------------------------------------------              | |      |   |  =
            |               |        |             |               | |   =
  |   |        -------------         |        |       -------------      =
   | |    |   |        |    CE     |         |        |       |    CE    =
 |         | |     |   |        -------------         |        |       =
-------------         | |     |   |          /        \          |       =
 |           /     \           | |     |   |         /          \        =
 |        |          /       \          | |     |   |        /           =
 \        |        |         /         \         | |     |   |       /   =
           \       |        |  ---------     ---------    | |     |   |  =
-----------     ----------- |        |  |  FE    |    |  FE   |    | |   =
  |   |  |   FE    |     |    FE   | |        |  ----------    --------- =
   | |     |   |  -----------     ----------- |        |    | | |        =
 | | |      | |     |   |    | | | |         | | | |   |        |    | | =
|         | | |      | |     |   |    | | | |         | | | |   |        =
|    | | |         | | |      | |     |   |    | | | |         | | | |   =
|        ------------------------------- |     |   =
--------------------------------             | | |         | | |        =
|      |        | | | |         | | | |                 | | |         | =
| |        |    =
|------------------------------------------------------------------------=
----
         | | | |         | | | |                 | | |	     | | |
         ^                                         ^
         |                                         |
        BGP                                       BGP

NE Network element
CE Control element=20
FE Forwarding element

Traditional routers implement routing protocols on a centralized =
processor, which has visibility to all the interfaces associated with =
the router. Such a system differs from a traditional router in a sense =
that both the control and data processing are distributed across the =
different processors.

Suppose we are running BGP on one of the interfaces of one network =
element [a.k.a. router]. Whatever routes it learns must be advertised to =
all the remaining network elements. This can be done via some =
redistribution mechanism within the router. The problem comes in when we =
are running BGP on another interface belonging to some other NE (Say 2 =
in our case). Now whatever routes NE1 learns, must be passed along to =
NE2 with *ALL* its attributes so that it can run its decision process =
and come up with the optimal routes. The same holds true for NE1. It =
must have all the routes along with the complete attributes from NE2 so =
that it can run its decision process. Once they have a consistent table, =
the routes can be leaked into the remaining network elements [routers]. =
This problem aggravates when we have network elements [routers] of the =
order of O (1000)

What are the options left with us to ensure that the BGP tables across =
the NEs remain synchronized.

(1) We cant have each router peering up with the other router to form a =
full IBGP mesh as this would lead to scalability issues.
(2) We can have a central server to which all BGP learnt routes are =
sent. There it runs its decision process and there propagates those =
selected routes to every other router. This creates a single point of =
failure. Moreover, with the full BGP routing table being injected there =
is going to be a considerable load on the designated router/processor.
(3) We can have hierarchical route reflectors within the router but it =
is also not scalable. Secondly, there would be a lot of complexities =
involved in the selection of server and the clients, etc.
(4) Hack the BGP protocol and making it TCP independent, broadcasting =
all the BGP packets within the consolidated router for within this =
integrated networking element all routers running BGP are peers. =
Reliability is at stake (which we don't ever bother with TCP!).=20

Is there any thought in the IDR working group on standardizing such =
distributed BGP route computations?

Regards,
Manav Bhatia

------=_NextPart_000_0391_01C17E4F.F5385370--

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>
Subject: Distributed BGP computations
Date: Thu, 6 Dec 2001 11:24:44 +0530
Organization: Samsung India Operations
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0352_01C17E48.9B000760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,
Since the mail had a figure in it i have sent it as an attachment.

Regards,
Manav

------=_NextPart_000_0352_01C17E48.9B000760
Content-Type: text/plain;
	name="bgp_distribution.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="bgp_distribution.txt"

Hi,

A network element is composed of numerous logically separated entities =
that cooperate to provide a given functionality (such as a routing or IP =
switching) and yet appear as a normal integrated network element to =
external entities. Two primary types of network element components =
exist: control-plane components and forwarding-plane components (ASIC). =
A standard set of mechanisms for connecting these components would =
provide increased scalability and allow the control and forwarding =
planes to evolve independently thus promoting faster innovation.

Going a step further, we conglomerate these various network elements and =
put them on an ethernet to form a truly integerated network element =
[read as, terrabit router] composed of multiple packet processing =
engines interconnected to form a logical whole.
[Ref to the figure below]

-------------------------------------------------------------------------=
---------------
|         --------------------------------        =
-------------------------------      |
|         | NE1                          |        |  NE2                 =
       |      |
|         |            -------------------------------------------       =
       |      |
|         |              |               |        |             |        =
       |      |
|         |        -------------         |        |       -------------  =
       |      |
|         |        |    CE     |         |        |       |    CE     |  =
       |      |
|         |        -------------         |        |       -------------  =
       |      |
|         |          /        \          |        |           /     \    =
       |      |
|         |         /          \         |        |          /       \   =
       |      |
|         |        /            \        |        |         /         \  =
       |      |
|         |       /              \       |        |  ---------     =
---------    |      |
|         |  -----------     ----------- |        |  |  FE    |    |  FE =
  |    |      |
|         |  |   FE    |     |    FE   | |        |  ----------    =
---------    |      |
|         |  -----------     ----------- |        |    | | |         | | =
|      |      |
|         |    | | | |         | | | |   |        |    | | |         | | =
|      |      |
|         |    | | | |         | | | |   |        |    | | |         | | =
|      |      |
|         |    | | | |         | | | |   |        =
--------------------------------     |
|         --------------------------------             | | |         | | =
|             |
|              | | | |         | | | |                 | | |         | | =
|             |
-------------------------------------------------------------------------=
---------------
               | | | |         | | | |                 | | |	     | | |

               ^                                         ^
               |                                         |
              BGP                                       BGP

NE Network element
CE Control element=20
FE Forwarding element

Suppose we are running BGP on one of the interfaces of one network =
element [aka router]. Whatever routes it learns must be advertised to =
all the remaining network elements. This can be done via some =
redistribution mechanism within the router. The problem comes in when we =
are running BGP on another interface belonging to some other NE (Say 2 =
in our case). Now whatever routes NE1 learns, must be passed along to =
NE2 with *ALL* its attributes so that it can run its decision process =
and come up with the optimal routes. The same holds true for NE1. It =
must have all the routes along with the complete attributes from NE2 so =
that it can run its decision process. Once they have a consistent table, =
the routes can be leaked into the remaining network elements [routers]. =
This problem aggravates when we have network elements [routers] of the =
order of O(1000)

What are the options left with us to ensure that the BGP tables across =
the NEs remain synchronized.

(1) We cant have each router peering up with the other router to form a =
full IBGP mesh as this would lead to scalability issues.
(2) We can have a central server to which all BGP learnt routes are =
sent. There is runs its decision process and there propagates those =
selected routes to every other router. This creates a single point of =
failure. Moreover, with the full BGP routing table being injected there  =
is going to be a considerable load on the designated router/processor.
(3) We can have hierarchical route reflectors within the router but it =
is also not scalable. Secondly, there would be a lot of complexities =
involved in the selection of server and the clients, etc.
(4) Hack the BGP protocol and making it TCP independent, broadcasting =
all the BGP packets within the consolidated router for within this =
integrated networking element all routers running BGP are peers. =
Reliability is at stake (which we dont ever bother with TCP!).=20

Is there any thought in the IDR working group on standardizing such =
distributed BGP route computations ?

Regards,
Manav Bhatia

------=_NextPart_000_0352_01C17E48.9B000760--

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Wed, 5 Dec 2001 20:23:26 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: Russ White <[email-masked]>, Tony Barber <[email-masked]>, [email-masked], <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Sender: [email-masked]

Susan,

 As long as the slides and the minutes are submitted
 to the IETF secretariat (which hasn't been the case,
 btw), and the in-room discussion is followed up on
 the mailing list to make sure those who can't attend
 this time are still in sync, I vote to present.

-- 
Alex Zinin

Wednesday, December 05, 2001, 4:22:41 PM, Susan Hares wrote:

> It's 3 to present now.  2 to defer to March.

> Any other votes?  Please vote now.

> Sue

> At 07:11 PM 12/5/2001 -0500, Russ White wrote:

>>I think I'd rather have some time to look it over and think
>>through the issues before discussing this at the working
>>group. So, I'd say present it the next one in march.
>>
>>Russ
>>
>>On Wed, 5 Dec 2001, Susan Hares wrote:
>>
>> >
>> > I'll take you as 1 vote for the presentation.
>> > Does anyone else want to see the presentation?
>> >
>> > Please speak up today!!
>> >
>> > Sue
>> >
>> > At 05:50 PM 12/5/2001 +0000, Tony Barber wrote:
>> > >I think it is worth revisiting Sue, within my organisation we are seeing a
>> > >customer driven requirement for it.
>> > >
>> > >
>> > >At 12:34 PM 05/12/01 -0500, Susan Hares wrote:
>> > > >
>> > > >Sandy Murphy re-issued the following draft:
>> > > >
>> > > >  Network Working Group Sandra Murphy
>> > > >  INTERNET DRAFT NAI Labs
>> > > >  draft-ietf-murphy-bgp-secr-04.txt November 2001
>> > > >
>> > > >Sandy states that:
>> > > >
>> > > >For several reasons (promises to a couple of IESG people and others,
>> > > >the recent CERT report mentioning increasing concern about routing
>> > > >protocols attacks, the IAB BGP architecture report's security
>> > > >considerations section, etc.), I've decided to try to resurrect this
>> > > >work.
>> > > >
>> > > >Is anyone interested in seeing this presentation at the IDR meeting?
>> > > >Would anyone like to see it after with some new implementations details
>> > > >in 3 months?
>> > > >
>> > > >Please chime if you wish to see this work.  A silence will be taken
>> > > >as a "no" vote.
>> > > >
>> > > >Just to warm up any discussion, security of BGP has 3 issues:
>> > > >
>> > > >       1) router security - SSH instead of telnet
>> > > >       2) Link security - TCP MD5 or IP Sec with TCP
>> > > >        3) BGP protocol security - as sandy starts out.
>> > > >
>> > > >There have been 5 problems with BGP Security in the past, and
>> > > >with MPBGP usage we add a 6 problem:
>> > > >
>> > > >       1) Scaling
>> > > >
>> > > >               Security based on an NLRI causes lots of overhead
>> > > >               in the protocol.   It is best done when you pack
>> > > >               1 NLRI per packet.
>> > > >
>> > > >       2) aggregation of routes creates security problems
>> > > >
>> > > >               This is aggregation of NRLIs and AS paths to sequences.
>> > > >
>> > > >       3) The "Start-up" problem exists if "Certificates" must be
>> > > >           queried as new updates are created or out
>> > > >
>> > > >               You can store certificates for routes (nlri, ASpaths)
>> > > >               on a disk if you know about them before hand.
>> > > >
>> > > >               DNS or another mechanism that goes across the network
>> > > >               has a start-up problem.
>> > > >
>> > > >               Some algorithms let you have two states of data:
>> > > >               pre-security and post-security.   After you set-up
>> > > >               the initial routes learned, you start overwriting 
>> original
>> > > >               non-secure routes with secure routes.
>> > > >
>> > > >       4) Certificate passing scheme must be set-up
>> > > >
>> > > >       5) Addition of Communities and Deletion also causes problems in
>> > > >               securing the network.
>> > > >
>> > > >       6) MPBGP issues of security IP v4 data which can be in the
>> > > >               nlri and the MPBGP portion.
>> > > >
>> > > >
>> > > >Any work, should be looked at in terms of defining risks and solving
>> > > >these overall problems.
>> > > >
>> > > >Please chime in if you want to continue this discussion on the IDR list.
>> > > >
>> > > >
>> > > >Sue Hares
>> > > >
>> > > >
>> >
>> >
>>
>>_____________________________
>>[email-masked] <>< Grace Alone

Date: Wed, 05 Dec 2001 19:32:35 -0500
To: "Mareline Sheldon" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: BGP Testing
Cc: <[email-masked]>
Sender: [email-masked]

Marine:

There are multiple Testing vendors.   Try requesting a list
from NANOG.  University of New Hampshire has an interoperability lab.

Sue Hares

At 07:41 PM 12/3/2001 +0530, Mareline Sheldon wrote:
>Hi,
>I am to test the BGP functionality of a code i've been working on. Is there
>any site which gives a comprehensive list of all the tests to perform on the
>BGP protocol.
>
>Thanks,
>Mareline
>
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com

Date: Wed, 05 Dec 2001 19:22:41 -0500
To: Russ White <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Cc: Susan Hares <[email-masked]>, Tony Barber <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

It's 3 to present now.  2 to defer to March.

Any other votes?  Please vote now.

Sue

At 07:11 PM 12/5/2001 -0500, Russ White wrote:

>I think I'd rather have some time to look it over and think
>through the issues before discussing this at the working
>group. So, I'd say present it the next one in march.
>
>Russ
>
>On Wed, 5 Dec 2001, Susan Hares wrote:
>
> >
> > I'll take you as 1 vote for the presentation.
> > Does anyone else want to see the presentation?
> >
> > Please speak up today!!
> >
> > Sue
> >
> > At 05:50 PM 12/5/2001 +0000, Tony Barber wrote:
> > >I think it is worth revisiting Sue, within my organisation we are seeing a
> > >customer driven requirement for it.
> > >
> > >
> > >At 12:34 PM 05/12/01 -0500, Susan Hares wrote:
> > > >
> > > >Sandy Murphy re-issued the following draft:
> > > >
> > > >  Network Working Group Sandra Murphy
> > > >  INTERNET DRAFT NAI Labs
> > > >  draft-ietf-murphy-bgp-secr-04.txt November 2001
> > > >
> > > >Sandy states that:
> > > >
> > > >For several reasons (promises to a couple of IESG people and others,
> > > >the recent CERT report mentioning increasing concern about routing
> > > >protocols attacks, the IAB BGP architecture report's security
> > > >considerations section, etc.), I've decided to try to resurrect this
> > > >work.
> > > >
> > > >Is anyone interested in seeing this presentation at the IDR meeting?
> > > >Would anyone like to see it after with some new implementations details
> > > >in 3 months?
> > > >
> > > >Please chime if you wish to see this work.  A silence will be taken
> > > >as a "no" vote.
> > > >
> > > >Just to warm up any discussion, security of BGP has 3 issues:
> > > >
> > > >       1) router security - SSH instead of telnet
> > > >       2) Link security - TCP MD5 or IP Sec with TCP
> > > >        3) BGP protocol security - as sandy starts out.
> > > >
> > > >There have been 5 problems with BGP Security in the past, and
> > > >with MPBGP usage we add a 6 problem:
> > > >
> > > >       1) Scaling
> > > >
> > > >               Security based on an NLRI causes lots of overhead
> > > >               in the protocol.   It is best done when you pack
> > > >               1 NLRI per packet.
> > > >
> > > >       2) aggregation of routes creates security problems
> > > >
> > > >               This is aggregation of NRLIs and AS paths to sequences.
> > > >
> > > >       3) The "Start-up" problem exists if "Certificates" must be
> > > >           queried as new updates are created or out
> > > >
> > > >               You can store certificates for routes (nlri, ASpaths)
> > > >               on a disk if you know about them before hand.
> > > >
> > > >               DNS or another mechanism that goes across the network
> > > >               has a start-up problem.
> > > >
> > > >               Some algorithms let you have two states of data:
> > > >               pre-security and post-security.   After you set-up
> > > >               the initial routes learned, you start overwriting 
> original
> > > >               non-secure routes with secure routes.
> > > >
> > > >       4) Certificate passing scheme must be set-up
> > > >
> > > >       5) Addition of Communities and Deletion also causes problems in
> > > >               securing the network.
> > > >
> > > >       6) MPBGP issues of security IP v4 data which can be in the
> > > >               nlri and the MPBGP portion.
> > > >
> > > >
> > > >Any work, should be looked at in terms of defining risks and solving
> > > >these overall problems.
> > > >
> > > >Please chime in if you want to continue this discussion on the IDR list.
> > > >
> > > >
> > > >Sue Hares
> > > >
> > > >
> >
> >
>
>_____________________________
>[email-masked] <>< Grace Alone

Date: Wed, 05 Dec 2001 19:21:51 -0500
To: Igor Lasic <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Cc: Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

This is the 3rd Please do.. I think i'm getting a trend here.

Sue

At 06:51 PM 12/5/2001 -0500, Igor Lasic wrote:

>I think this is definitely a worthwhile subject. Please count my vote as
>   YES.
>
>Igor
>
>Susan Hares writes:
>  >
>  > I'll take you as 1 vote for the presentation.
>  > Does anyone else want to see the presentation?
>  >
>  > Please speak up today!!
>  >
>  > Sue
>  >
>  > At 05:50 PM 12/5/2001 +0000, Tony Barber wrote:
>  > >I think it is worth revisiting Sue, within my organisation we are 
> seeing a
>  > >customer driven requirement for it.
>  > >
>  > >
>  > >At 12:34 PM 05/12/01 -0500, Susan Hares wrote:
>  > > >
>  > > >Sandy Murphy re-issued the following draft:
>  > > >
>  > > >  Network Working Group Sandra Murphy
>  > > >  INTERNET DRAFT NAI Labs
>  > > >  draft-ietf-murphy-bgp-secr-04.txt November 2001
>  > > >
>  > > >Sandy states that:
>  > > >
>  > > >For several reasons (promises to a couple of IESG people and others,
>  > > >the recent CERT report mentioning increasing concern about routing
>  > > >protocols attacks, the IAB BGP architecture report's security
>  > > >considerations section, etc.), I've decided to try to resurrect this
>  > > >work.
>  > > >
>  > > >Is anyone interested in seeing this presentation at the IDR meeting?
>  > > >Would anyone like to see it after with some new implementations details
>  > > >in 3 months?
>  > > >
>  > > >Please chime if you wish to see this work.  A silence will be taken
>  > > >as a "no" vote.
>  > > >
>  > > >Just to warm up any discussion, security of BGP has 3 issues:
>  > > >
>  > > >       1) router security - SSH instead of telnet
>  > > >       2) Link security - TCP MD5 or IP Sec with TCP
>  > > >        3) BGP protocol security - as sandy starts out.
>  > > >
>  > > >There have been 5 problems with BGP Security in the past, and
>  > > >with MPBGP usage we add a 6 problem:
>  > > >
>  > > >       1) Scaling
>  > > >
>  > > >               Security based on an NLRI causes lots of overhead
>  > > >               in the protocol.   It is best done when you pack
>  > > >               1 NLRI per packet.
>  > > >
>  > > >       2) aggregation of routes creates security problems
>  > > >
>  > > >               This is aggregation of NRLIs and AS paths to sequences.
>  > > >
>  > > >       3) The "Start-up" problem exists if "Certificates" must be
>  > > >           queried as new updates are created or out
>  > > >
>  > > >               You can store certificates for routes (nlri, ASpaths)
>  > > >               on a disk if you know about them before hand.
>  > > >
>  > > >               DNS or another mechanism that goes across the network
>  > > >               has a start-up problem.
>  > > >
>  > > >               Some algorithms let you have two states of data:
>  > > >               pre-security and post-security.   After you set-up
>  > > >               the initial routes learned, you start overwriting 
> original
>  > > >               non-secure routes with secure routes.
>  > > >
>  > > >       4) Certificate passing scheme must be set-up
>  > > >
>  > > >       5) Addition of Communities and Deletion also causes problems in
>  > > >               securing the network.
>  > > >
>  > > >       6) MPBGP issues of security IP v4 data which can be in the
>  > > >               nlri and the MPBGP portion.
>  > > >
>  > > >
>  > > >Any work, should be looked at in terms of defining risks and solving
>  > > >these overall problems.
>  > > >
>  > > >Please chime in if you want to continue this discussion on the IDR 
> list.
>  > > >
>  > > >
>  > > >Sue Hares
>  > > >
>  > > >
>  >

Date: Wed, 5 Dec 2001 19:11:25 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Tony Barber <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Optional Agenda items - Security issues
Sender: [email-masked]

I think I'd rather have some time to look it over and think
through the issues before discussing this at the working
group. So, I'd say present it the next one in march.

Russ

On Wed, 5 Dec 2001, Susan Hares wrote:

> 
> I'll take you as 1 vote for the presentation.
> Does anyone else want to see the presentation?
> 
> Please speak up today!!
> 
> Sue
> 
> At 05:50 PM 12/5/2001 +0000, Tony Barber wrote:
> >I think it is worth revisiting Sue, within my organisation we are seeing a
> >customer driven requirement for it.
> >
> >
> >At 12:34 PM 05/12/01 -0500, Susan Hares wrote:
> > >
> > >Sandy Murphy re-issued the following draft:
> > >
> > >  Network Working Group Sandra Murphy
> > >  INTERNET DRAFT NAI Labs
> > >  draft-ietf-murphy-bgp-secr-04.txt November 2001
> > >
> > >Sandy states that:
> > >
> > >For several reasons (promises to a couple of IESG people and others,
> > >the recent CERT report mentioning increasing concern about routing
> > >protocols attacks, the IAB BGP architecture report's security
> > >considerations section, etc.), I've decided to try to resurrect this
> > >work.
> > >
> > >Is anyone interested in seeing this presentation at the IDR meeting?
> > >Would anyone like to see it after with some new implementations details
> > >in 3 months?
> > >
> > >Please chime if you wish to see this work.  A silence will be taken
> > >as a "no" vote.
> > >
> > >Just to warm up any discussion, security of BGP has 3 issues:
> > >
> > >       1) router security - SSH instead of telnet
> > >       2) Link security - TCP MD5 or IP Sec with TCP
> > >        3) BGP protocol security - as sandy starts out.
> > >
> > >There have been 5 problems with BGP Security in the past, and
> > >with MPBGP usage we add a 6 problem:
> > >
> > >       1) Scaling
> > >
> > >               Security based on an NLRI causes lots of overhead
> > >               in the protocol.   It is best done when you pack
> > >               1 NLRI per packet.
> > >
> > >       2) aggregation of routes creates security problems
> > >
> > >               This is aggregation of NRLIs and AS paths to sequences.
> > >
> > >       3) The "Start-up" problem exists if "Certificates" must be
> > >           queried as new updates are created or out
> > >
> > >               You can store certificates for routes (nlri, ASpaths)
> > >               on a disk if you know about them before hand.
> > >
> > >               DNS or another mechanism that goes across the network
> > >               has a start-up problem.
> > >
> > >               Some algorithms let you have two states of data:
> > >               pre-security and post-security.   After you set-up
> > >               the initial routes learned, you start overwriting original
> > >               non-secure routes with secure routes.
> > >
> > >       4) Certificate passing scheme must be set-up
> > >
> > >       5) Addition of Communities and Deletion also causes problems in
> > >               securing the network.
> > >
> > >       6) MPBGP issues of security IP v4 data which can be in the
> > >               nlri and the MPBGP portion.
> > >
> > >
> > >Any work, should be looked at in terms of defining risks and solving
> > >these overall problems.
> > >
> > >Please chime in if you want to continue this discussion on the IDR list.
> > >
> > >
> > >Sue Hares
> > >
> > >
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Wed, 05 Dec 2001 17:57:41 -0500
To: Tony Barber <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I'll take you as 1 vote for the presentation.
Does anyone else want to see the presentation?

Please speak up today!!

Sue

At 05:50 PM 12/5/2001 +0000, Tony Barber wrote:
>I think it is worth revisiting Sue, within my organisation we are seeing a
>customer driven requirement for it.
>
>
>At 12:34 PM 05/12/01 -0500, Susan Hares wrote:
> >
> >Sandy Murphy re-issued the following draft:
> >
> >  Network Working Group Sandra Murphy
> >  INTERNET DRAFT NAI Labs
> >  draft-ietf-murphy-bgp-secr-04.txt November 2001
> >
> >Sandy states that:
> >
> >For several reasons (promises to a couple of IESG people and others,
> >the recent CERT report mentioning increasing concern about routing
> >protocols attacks, the IAB BGP architecture report's security
> >considerations section, etc.), I've decided to try to resurrect this
> >work.
> >
> >Is anyone interested in seeing this presentation at the IDR meeting?
> >Would anyone like to see it after with some new implementations details
> >in 3 months?
> >
> >Please chime if you wish to see this work.  A silence will be taken
> >as a "no" vote.
> >
> >Just to warm up any discussion, security of BGP has 3 issues:
> >
> >       1) router security - SSH instead of telnet
> >       2) Link security - TCP MD5 or IP Sec with TCP
> >        3) BGP protocol security - as sandy starts out.
> >
> >There have been 5 problems with BGP Security in the past, and
> >with MPBGP usage we add a 6 problem:
> >
> >       1) Scaling
> >
> >               Security based on an NLRI causes lots of overhead
> >               in the protocol.   It is best done when you pack
> >               1 NLRI per packet.
> >
> >       2) aggregation of routes creates security problems
> >
> >               This is aggregation of NRLIs and AS paths to sequences.
> >
> >       3) The "Start-up" problem exists if "Certificates" must be
> >           queried as new updates are created or out
> >
> >               You can store certificates for routes (nlri, ASpaths)
> >               on a disk if you know about them before hand.
> >
> >               DNS or another mechanism that goes across the network
> >               has a start-up problem.
> >
> >               Some algorithms let you have two states of data:
> >               pre-security and post-security.   After you set-up
> >               the initial routes learned, you start overwriting original
> >               non-secure routes with secure routes.
> >
> >       4) Certificate passing scheme must be set-up
> >
> >       5) Addition of Communities and Deletion also causes problems in
> >               securing the network.
> >
> >       6) MPBGP issues of security IP v4 data which can be in the
> >               nlri and the MPBGP portion.
> >
> >
> >Any work, should be looked at in terms of defining risks and solving
> >these overall problems.
> >
> >Please chime in if you want to continue this discussion on the IDR list.
> >
> >
> >Sue Hares
> >
> >

Date: Wed, 05 Dec 2001 18:09:05 -0500
To: Jeffrey Haas <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Current agenda and optional topics?
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked], yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff:

At 12:27 PM 12/5/2001 -0500, Jeffrey Haas wrote:
>On Wed, Dec 05, 2001 at 12:04:05PM -0500, Susan Hares wrote:
> > Summary of Working Group Drafts for reference:
>
>[...]
>
> > 2) Definitions of Managed Objects for the Fourth Version of Border
> >     Gateway Protocol (BGP-4) (64264 bytes)
> >    [draft-ietf-idr-bgp4-mib-08.txt] [standards track]
>
>This is no longer on the standards track per the WG.  It will be
>published as an informational rfc to document historical practice.
>mibv2 should be on the standard's track since it will reflect
>current protocol practices.

Thanks for the note.  We'll put the correct mib on historical
practices.

>Agenda comments:

>It would be nice to see some public discussion on dealing with
>error conditions gracefully.  I offer as an example the ambiguity
>in the BGP Confederations document where some implementations
>propagated confederation segments outside of confederation boundaries
>and caused BGP implementations to drop their peering sessions.
>
>Various vendors have differing workaround for this particular problem.
>The general problem, handling things gracefully, should be addressed
>by the protocol.

Is there anyone interested in this topic for this IETF?
Jeff - you should prepare a presentation just in case
people are interested.

Sue Hares

Date: Wed, 5 Dec 2001 13:58:39 -0500
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked], yakov Rekhter <[email-masked]>, [email-masked], [email-masked], randy Bush <[email-masked]>
Subject: Re: Optional Agenda items - Security issues
Sender: [email-masked]

[N.B.: I'm going to talk about the issues here without necessarily
advocating that they should be solved or solved in a pariticular
fashion.  I just want to express some opinions on the issues at hand.]

On Wed, Dec 05, 2001 at 12:34:19PM -0500, Susan Hares wrote:
> 	1) Scaling
> 
> 		Security based on an NLRI causes lots of overhead
> 		in the protocol.   It is best done when you pack
> 	        1 NLRI per packet.

We already understand that packing BGP PDU's reduces the overhead
of the protocol immensely.  Without atomic collections of NLRI that
could be passed end to end (goodbye policy), you can't pack
more than one NLRI in a BGP PDU and sign it usefully.

> 	2) aggregation of routes creates security problems
> 
> 		This is aggregation of NRLIs and AS paths to sequences.

[assuming explicitly synthesized aggregates]
Security-wise, carrying the aggregated components along with the
newly originated aggregate is enough to address this.
But you're aggregating to reduce the state in the system....

> 	3) The "Start-up" problem exists if "Certificates" must be
> 	    queried as new updates are created or out
[...]
> 	4) Certificate passing scheme must be set-up

There's also the issue of reaching critical resources if intermediate
paths are not signed.  

If I'm trying to get to the DNS root-servers and I have no paths 
to those servers that are fully validated...

> 	5) Addition of Communities and Deletion also causes problems in
> 		securing the network.

Community usage tends to be someone adds a community to suggest
to the community target (the LHS of the community) to do "something".
The party who added it should be known and the community signed.
Potentially, the group of communities appended by the given entity
should be signed.

> 	6) MPBGP issues of security IP v4 data which can be in the
> 		nlri and the MPBGP portion.

IMO, the BGP PDU is poorly suited to properly apply 
cryptographic signature-based security.

7) Implicit aggregation: The ATOMIC_AGGREGATE path attribute was
intended to signal when implicit aggregation is being done.
Said aggregation may lead to a loss of path information.  No one
that I'm aware of does this fully.  

The BGP specification's text for ATOMIC_AGGREGATE also is incomplete
in my opinion as to the situations where we could signal loss
of path information.

For security/policy purposes, one may wish to know that the route
that has been received will actually traverse the path advertised.
One can't even tell that usefully in the current Internet now -
our documented signalling mechanism is incompletely implemented at
best.

---

IMO, the operational community would mostly be happy with
"is As-foo allowed to originate this prefix?"  This would address
a large swath of the immediate operational issues.

This can be addressed by having the IRR registries in synch with
reality and correlated against the RIR's (rps-auth).  The resulting
route: objects could be stored in a relatively small policy filter.
Some custom code could make this type of filter very fast.

Almost everything beyond that becomes policy leaking - people
not following the policies they say they have.  This leads
to unexpected routing and its related problems, but is not
necessarily the biggest security issue.

> Any work, should be looked at in terms of defining risks and solving
> these overall problems.
> 
> Please chime in if you want to continue this discussion on the IDR list.
> 
> 
> Sue Hares
> 
> 

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 05 Dec 2001 12:34:19 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Optional Agenda items - Security issues
Cc: yakov Rekhter <[email-masked]>, [email-masked], [email-masked], randy Bush <[email-masked]>
Sender: [email-masked]

Sandy Murphy re-issued the following draft:

  Network Working Group Sandra Murphy
  INTERNET DRAFT NAI Labs
  draft-ietf-murphy-bgp-secr-04.txt November 2001

Sandy states that:

For several reasons (promises to a couple of IESG people and others,
the recent CERT report mentioning increasing concern about routing
protocols attacks, the IAB BGP architecture report's security
considerations section, etc.), I've decided to try to resurrect this
work.

Is anyone interested in seeing this presentation at the IDR meeting?
Would anyone like to see it after with some new implementations details
in 3 months?

Please chime if you wish to see this work.  A silence will be taken
as a "no" vote.

Just to warm up any discussion, security of BGP has 3 issues:

	1) router security - SSH instead of telnet
	2) Link security - TCP MD5 or IP Sec with TCP
        3) BGP protocol security - as sandy starts out.

There have been 5 problems with BGP Security in the past, and
with MPBGP usage we add a 6 problem:

	1) Scaling

		Security based on an NLRI causes lots of overhead
		in the protocol.   It is best done when you pack
	        1 NLRI per packet.

	2) aggregation of routes creates security problems

		This is aggregation of NRLIs and AS paths to sequences.

	3) The "Start-up" problem exists if "Certificates" must be
	    queried as new updates are created or out

		You can store certificates for routes (nlri, ASpaths)
		on a disk if you know about them before hand.

		DNS or another mechanism that goes across the network
		has a start-up problem.

		Some algorithms let you have two states of data:
		pre-security and post-security.   After you set-up
		the initial routes learned, you start overwriting original
		non-secure routes with secure routes.

	4) Certificate passing scheme must be set-up

	5) Addition of Communities and Deletion also causes problems in
		securing the network.

	6) MPBGP issues of security IP v4 data which can be in the
		nlri and the MPBGP portion.

Any work, should be looked at in terms of defining risks and solving
these overall problems.

Please chime in if you want to continue this discussion on the IDR list.

Sue Hares

Date: Wed, 5 Dec 2001 12:27:04 -0500
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked], [email-masked], yakov Rekhter <[email-masked]>
Subject: Re: Current agenda and optional topics?
Sender: [email-masked]

On Wed, Dec 05, 2001 at 12:04:05PM -0500, Susan Hares wrote:
> Summary of Working Group Drafts for reference:

[...]

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

This is no longer on the standards track per the WG.  It will be
published as an informational rfc to document historical practice.
mibv2 should be on the standard's track since it will reflect
current protocol practices.

Agenda comments:
It would be nice to see some public discussion on dealing with
error conditions gracefully.  I offer as an example the ambiguity
in the BGP Confederations document where some implementations
propagated confederation segments outside of confederation boundaries
and caused BGP implementations to drop their peering sessions.

Various vendors have differing workaround for this particular problem.
The general problem, handling things gracefully, should be addressed
by the protocol.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 05 Dec 2001 12:04:05 -0500
To: [email-masked], [email-masked]
From: Susan Hares <[email-masked]>
Subject: Current agenda and optional topics?
Cc: [email-masked], yakov Rekhter <[email-masked]>
Sender: [email-masked]

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

The current IDR agenda for Thursday 12/13/01 at 15:30pm - 17:30pm.

          1) IDR charter   [10 minutes]
          2) IDR Document update  [20 minutes]

               a) draft-ietf-idr-16.txt review
               b) draft-ietf-idr-17.txt will include clarifications
                   to FSM text in

         3) IDR MIBs  [20 minutes]
               a) draft-ietf-idr-bgp4-mib-08.txt

               b) version 2 of the MIB
                  draft-ietf-idr-bgp4-mibv2-01.txt  (-02 is pending)

         4) Update on IDR working group drafts  [10 minutes]
               a) Drafts set to the IESG

                 draft-ietf-idr-route-oscillation-00.txt

               b) Status of all IDR Drafts
                  (see summary below)

     Total time: 45 minutes

Potential Discussions:

The following topics have been suggested, but we are looking for
working group feedback on the relevance of the topic.

      1) IDR security draft -
      2) Multicast AFI/SAFI

Please send your comments to the mailing list on these topics.

Sue Hares
[email-masked]

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

Summary of Working Group Drafts for reference:

1) Border Gateway Protocol 4 (BGP-4) [draft-ietf-idr-bgp4-16.txt]

idr-bgp4-17.txt will include FSM changes from Sue. Estimated
to send to working group within month.

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

  3) Cooperative Route Filtering Capability for BGP-4
         [draft-ietf-idr-route-filter-04.txt] [November 2001 submitted] 
[standards track]

          Note: The FSM changes in the IDR draft will need to be
                       considered in this draft.

  4) Graceful Restart Mechanism for BGP
     [draft-ietf-idr-restart-01.txt] [January 2002] [standards track]

         Note: The FSM changes in the IDR draft will need to be
                       considered in this draft.

   5) BGP support for four-octet AS number space
    [draft-ietf-idr-as4bytes-04.txt March 2002] [Standards track]

         Note: Awaiting implementations

   6) BGP Persistent Route Oscillation Condition (36048 bytes)
[draft-ietf-idr-route-oscillation-00.txt March 2001] [Informational]

         Sent to IESG for review

   7) BGP Extended Communities Attribute (14880 bytes)
  draft-ietf-idr-bgp-ext-communities-02.txt [March 2002] [Standard track]

This document will wait for more implementations and then send
to proposed standard.

  8) Aspath Based Outbound Route Filter for BGP-4 (10382 bytes)
         draft-ietf-idr-aspath-orf-00.txt

This draft will await more implementation
         and then go to standards track.

   9) Definitions of Managed Objects for the Fourth Version of Border Gateway
   Protocol (BGP-4),Second Version (83645 bytes) [standards track]
           Draft-ietf-idr-bgp-mibv2-01.txt

         An 02.txt version will be discussed at IDR.

  10) Dynamic Capability for BGP-4 (7370 bytes)
  draft-ietf-idr-dynamic-cap-00.txt [February 2002] [Standards track]

         Note: The FSM changes in the IDR draft will need to be
                       considered in this draft.

  11) Subcodes for BGP Cease Notification Message (6138 bytes)

   draft-ietf-idr-cease-subcode-00.txt [April 2002] [standard track]

         Note: The FSM changes in the IDR draft will need to be
               considered in this draft.

--=====================_16187596==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
The current IDR agenda for Thursday 12/13/01 at 15:30pm - 17:30pm.<br>
<br>
<font face="Courier New, Courier"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
1) IDR charter&nbsp;&nbsp; [10 minutes]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> 2) IDR Document update&nbsp; [20 minutes]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) draft-ietf-idr-16.txt review<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) draft-ietf-idr-17.txt will include clarifications<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to FSM text in <br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>3) IDR MIBs&nbsp; [20 minutes]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) draft-ietf-idr-bgp4-mib-08.txt <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) version 2 of the MIB<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> draft-ietf-idr-bgp4-mibv2-01.txt&nbsp; (-02 is pending)<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>4) Update on IDR working group drafts&nbsp; [10 minutes]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) Drafts set to the IESG <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Courier New, Courier">draft-ietf-idr-route-oscillation-00.txt <br>
</font><font face="Courier New, Courier"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) Status of all IDR Drafts<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> (see summary below)<br>
&nbsp; <br>
&nbsp;&nbsp;&nbsp; Total time: 45 minutes<br>
<br>
<br>
Potential Discussions:<br>
<br>
The following topics have been suggested, but we are looking for<br>
working group feedback on the relevance of the topic.&nbsp; <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; 1) IDR security draft - <br>
&nbsp;&nbsp;&nbsp;&nbsp; 2) Multicast AFI/SAFI <br>
<br>
Please send your comments to the mailing list on these topics.<br>
<br>
Sue Hares<br>
[email-masked]<br>
<br>
<br>
------------------------------------------------<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
<br>
Summary of Working Group Drafts for reference:<br>
<br>
<br>
<br>
</font><font face="Courier New, Courier">1) Border Gateway Protocol 4 (BGP-4) [draft-ietf-idr-bgp4-16.txt]<br>
<br>
idr-bgp4-17.txt will include FSM changes from Sue. Estimated<br>
to send to working group within month.<br>
<br>
2) Definitions of Managed Objects for the Fourth Version of Border<br>
&nbsp;&nbsp; Gateway Protocol (BGP-4) (64264 bytes)<br>
&nbsp; [draft-ietf-idr-bgp4-mib-08.txt] [standards track]<br>
<br>
&nbsp;3) Cooperative Route Filtering Capability for BGP-4&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [draft-ietf-idr-route-filter-04.txt] [November 2001 submitted] [standards track]<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> Note: The FSM changes in the IDR draft will need to be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; considered in this draft.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
&nbsp;4) Graceful Restart Mechanism for BGP <br>
&nbsp;&nbsp;&nbsp; [draft-ietf-idr-restart-01.txt] [January 2002] [standards track]<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Note: The FSM changes in the IDR draft will need to be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; considered in this draft.<br>
&nbsp;<br>
&nbsp; 5) BGP support for four-octet AS number space <br>
&nbsp;&nbsp; [draft-ietf-idr-as4bytes-04.txt March 2002] [Standards track]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Note: Awaiting implementations<br>
&nbsp;<br>
&nbsp; 6) BGP Persistent Route Oscillation Condition (36048 bytes)<br>
[draft-ietf-idr-route-oscillation-00.txt March 2001] [Informational]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Sent to IESG for review<br>
<br>
&nbsp; 7) BGP Extended Communities Attribute (14880 bytes)<br>
&nbsp;draft-ietf-idr-bgp-ext-communities-02.txt [March 2002] [Standard track]<br>
<br>
This document will wait for more implementations and then send<br>
to proposed standard.<br>
<br>
&nbsp;8) Aspath Based Outbound Route Filter for BGP-4 (10382 bytes)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>draft-ietf-idr-aspath-orf-00.txt<br>
<br>
This draft will await more implementation<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>and then go to standards track.<br>
<br>
&nbsp; 9) Definitions of Managed Objects for the Fourth Version of Border Gateway<br>
&nbsp; Protocol (BGP-4),Second Version (83645 bytes) [standards track]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Draft-ietf-idr-bgp-mibv2-01.txt<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>An 02.txt version will be discussed at IDR. <br>
<br>
&nbsp;10) Dynamic Capability for BGP-4 (7370 bytes)<br>
&nbsp;draft-ietf-idr-dynamic-cap-00.txt [February 2002] [Standards track]<br>
<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Note: The FSM changes in the IDR draft will need to be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; considered in this draft.<br>
<br>
&nbsp;11) Subcodes for BGP Cease Notification Message (6138 bytes)<br>
<br>
&nbsp; draft-ietf-idr-cease-subcode-00.txt [April 2002] [standard track]<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: The FSM changes in the IDR draft will need to be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; considered in this draft.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><br>
</html>

--=====================_16187596==_.ALT--

Date: Wed, 05 Dec 2001 10:12:17 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: FSM update of IDR draft - Appendix B format
Sender: [email-masked]

I've not received any additional comments from the working group by 12/4/01.
We will be updating the idr draft with a Schedule B format that
matches the format sent to the list.

This format will be included in draft-ietf-idr-17.txt.

Sue Hares

From: "Ashutosh Gore" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Question on extended communities
Date: Mon, 3 Dec 2001 11:48:21 -0800
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C17C33.76969180
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

All the types of extended communities have 6 bytes length for
the value field with total size of 8 bytes.

Can one define variable length vendor specific extended community
or propose such community?
In this case, length (2bytes)  would follow the type field.

Thanks,
Ashutosh

------_=_NextPart_001_01C17C33.76969180
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>Question on extended communities</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hello,</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">All the types of extended communities have 6 bytes length for</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">the value field with total size of 8 bytes.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Can one define variable length vendor specific extended community</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">or propose such community?</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">In this case, length (2bytes)&nbsp; would follow the type field.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Thanks,</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Ashutosh</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C17C33.76969180--

From: "Mareline Sheldon" <[email-masked]>
To: <[email-masked]>
Subject: BGP Testing
Date: Mon, 3 Dec 2001 19:41:11 +0530
Sender: [email-masked]

Hi,
I am to test the BGP functionality of a code i've been working on. Is there
any site which gives a comprehensive list of all the tests to perform on the
BGP protocol.

Thanks,
Mareline

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: Capability advertisement in BGP
Date: Mon, 3 Dec 2001 10:40:33 +0200 
Sender: [email-masked]

Hello, all !
I have a question regards Capabilities Advertisement (RFC 2842).
Should I send as a capability optional parameters in Open message
the following extensions:
1. Route Reflection
2. Route Flap Dampening
3. AS Confederations
4. Communities Attribute
   Thanks in advance
          Katya