[Idr] BGP Protocol Experience Draft (-04)

I just posted an update version of the BGP Protocol Experience
draft.  Not much changed, here's a diff from the -03 revision,
the new version (-04) should be available in the Internet-Drafts
repository RSN.

Not sure if it needs to relive WG LC or not..

-danny

< Expires: March 2004                           September 2003
---
 > Expires: November 2004                              May 2004
10c10
<             <draft-ietf-idr-bgp4-experience-protocol-03.txt>
---
 >             <draft-ietf-idr-bgp4-experience-protocol-04.txt>
45c45
<    Copyright (C) The Internet Society (2003). All Rights Reserved.
---
 >    Copyright (C) The Internet Society (2004). All Rights Reserved.
54c54
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
110c110
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
120c120
<    4. Implementations. . . . . . . . . . . . . . . . . . . . . . . .  
  5
---
 >    4. Implementation Information . . . . . . . . . . . . . . . . . .  
  5
129c129
<    8. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . .  
  9
---
 >    8. Local Preference . . . . . . . . . . . . . . . . . . . . . . .  
  9
135c135
<     13.1. Consideration of TCP Characteristics . . . . . . . . . . .  
13
---
 >     13.1. Consideration of TCP Characteristics . . . . . . . . . . .  
14
140c140
<     17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . .  
15
---
 >     17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . .  
16
142c142
<     17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . .  
16
---
 >     17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . .  
17
146c146
<     A Bit of History . . . . . . . . . . . . . . . . . . . . . . . .  
17
---
 >     A Bit of History . . . . . . . . . . . . . . . . . . . . . . . .  
18
166c166
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
222c222
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
243c243
< 4.  Implementations
---
 > 4.  Implementation Information
278c278
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
287c287
<    Confederations for BGP, and perhaps some mix of the two.  BGP Route
---
 >    Confederations for BGP, and often some mix of the two.  BGP Route
305c305
<    120,000 aggregate entries, representing several times that number 
of
---
 >    134,000 aggregate entries, representing several times that number 
of
307c307
<    provider core routers exceeds 2.5 million.  Native AS_PATH lengths
---
 >    provider core routers exceeds 2.5 million.  Native AS path lengths
309c309
<    more ASs exist.
---
 >    more autonomous systems exist.
334c334
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
341,342c341,342
<    is used as a metric by EBGP peers while BGP Local Preference is 
used
<    by IBGP peers.
---
 >    is used as a metric by EBGP peers (i.e., inter-domain) while Local
 >    Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
358c358
<    different ASs as well.
---
 >    different autonomous systems as well.
366,371c366,371
<    between multiple paths learned from a single AS, it can result in
<    potentially bad decisions when comparing MEDs between different
<    automomous systems.  This is most typically the case when the
<    autonomous systems use different mechanisms to derive IGP metrics,
<    BGP MEDs, or perhaps even use different IGP procotols with vastly
<    contrasting metric spaces.
---
 >    between multiple paths learned from a single adjacent AS, it can
 >    result in potentially bad decisions when comparing MEDs between
 >    different automomous systems.  This is most typically the case when
 >    the autonomous systems use different mechanisms to derive IGP
 >    metrics, BGP MEDs, or perhaps even use different IGP procotols with
 >    vastly contrasting metric spaces.
390c390
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
430a431,434
 >    Seemingly more intuitive references that fall outside the vegetable
 >    kingdom refer to cold potatoe routing as "best exit routing", and 
hot
 >    potatoe routing as "closest exit routing", though vegetable.
 >
437,440d440
<    be passed to its IBGP peers.  Although advertising MEDs to IBGP 
peers
<    is not a required behavior, it is a common default.  MEDs received
<    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
<    peers.
446c446
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
448a449,453
 >    be passed to its IBGP peers.  Although advertising MEDs to IBGP 
peers
 >    is not a required behavior, it is a common default.  MEDs received
 >    from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
 >    peers.
 >
459,462c464,467
<    An implementation MUST provide a mechanism that allows for MED to 
be
<    removed.  Previously, implementations did not consider a missing 
MED
<    value to be the same as a MED of zero.  No MED value should now be
<    equal to a value of zero.
---
 >    [BGP4] requires that an implementation must provide a mechanism 
that
 >    allows for MED to be removed.  Previously, implementations did not
 >    consider a missing MED value to be the same as a MED of zero.  
[BGP4]
 >    now requires that no MED value be equal to a value of zero.
464c469
<    Note that many implementations provide an mechanism to explicitly
---
 >    Note that many implementations provide a mechanism to explicitly
479c484
<    non-deterministic behavior, and as such, is often undesirable.
---
 >    non-deterministic behavior, and as such, may often be undesirable.
483c488
< 8.  LOCAL_PREF
---
 > 8.  Local Preference
492,496d496
<    default value of LOCAL-PREF to be assumed if none was provided.
<    Defaults of 0 or the maximum value each have range limitations, so 
a
<    common default would aid in the interoperation of multi-vendor
<    routers in the same AS (since LOCAL_PREF is a local administration
<    knob, there is no interoperability drawback across AS boundaries).
502c502
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
505,507c505,514
<    The LOCAL_PREF MUST be sent to IBGP Peers.  The LOCAL_PREF 
Attribute
<    MUST NOT be sent to EBGP Peers.  Although no default value for
<    LOCAL_PREF is defined, the common default value is 100.
---
 >    default value of LOCAL_PREF to be assumed if none was provided.
 >    Defaults of 0 or the maximum value each have range limitations, so 
a
 >    common default would aid in the interoperation of multi-vendor
 >    routers in the same AS (since LOCAL_PREF is a local administration
 >    attribute, there is no interoperability drawback across AS
 >    boundaries).
 >
 >    [BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not 
be
 >    sent to EBGP Peers.  Although no default value for LOCAL_PREF is
 >    defined, the common default value is 100.
526c533
<    possibility of carrying an optional vector corresponding to the AS-
---
 >    possibility of carrying an optional vector corresponding to the AS_
528,534c535,542
<    given route.  Cooperating ASs may then chose traffic based upon
<    comparison of "interesting" portions of this vector according to
<    routing policy.
<
<    While protecting a given ASs routing policy is of paramount 
concern,
<    avoiding extensive hand configuration of routing policies needs to 
be
<    examined more carefully in future BGP-like protocols.
---
 >    given route.  Cooperating autonomous systems may then chose traffic
 >    based upon comparison of "interesting" portions of this vector
 >    according to routing policy.
 >
 >    While protecting a given autonoumous systems routing policy is of
 >    paramount concern, avoiding extensive hand configuration of routing
 >    policies needs to be examined more carefully in future BGP-like
 >    protocols.
545,552d552
<    information to all other transit and border routers within that AS.
<    This is typically done by establishing internal BGP connections to
<    all transit and border routers in the local AS.
<
<    Note that the number of BGP peers that can be fully meshed depends 
on
<    a number of factors, to include number of prefixes in the routing
<    system, stability of the system, and perhaps most importantly,
<    implementation ifficiency.  As a result, although it's difficult to
558c558
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
561,562c561,570
<    define "a large number of peers", there is always some practical
<    limit.
---
 >    information to all other transit and border routers within that AS.
 >    This is typically done by establishing internal BGP connections to
 >    all transit and border routers in the local AS.
 >
 >    Note that the number of BGP peers that can be fully meshed depends 
on
 >    a number of factors, to include number of prefixes in the routing
 >    system, number of unique path, stability of the system, and perhaps
 >    most importantly, implementation efficiency.  As a result, although
 >    it's difficult to define "a large number of peers", there is always
 >    some practical limit.
582,583c590,591
<    Internet.  As the net has grown, the number of route changes per
<    second has increased.
---
 >    Internet.  As the Internet has grown, the frequency of route 
changes
 >    per second has increased.
600c608,616
<    manditory in RFC 2439.  A potential result of failure to consider
---
 >    mandatory in RFC 2439.  A potential result of failure to consider
 >
 >
 >
 > McPherson, Patel                                  Section 10.  [Page 
11]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
609,620c625,628
<
<
<
< McPherson, Patel                                  Section 10.  [Page 
11]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
<    changes to be announced are inefficiently packed.  As previously
<    discussed, announcing routing changes sharing common attributes in 
a
<    single BGP UPDATE message helps save considerable bandwidth and 
lower
<    processing overhead.
---
 >    changes to be announced are inefficiently packed.  As discussed in 
a
 >    later section, announcing routing changes sharing common attributes
 >    in a single BGP UPDATE message helps save considerable bandwidth 
and
 >    lower processing overhead.
656a665,672
 >
 >
 >
 > McPherson, Patel                                  Section 12.  [Page 
12]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
665,672d680
<
<
<
< McPherson, Patel                                  Section 12.  [Page 
12]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
712a721,728
 >
 >
 >
 > McPherson, Patel                                  Section 13.  [Page 
13]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
721,728d736
<
<
<
< McPherson, Patel                                Section 13.1.  [Page 
13]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
738,741c746,749
<    buffer can grow until memory is exhausted.  A BGP implementation 
must
<    send changes to all peers for which the TCP connection is not 
blocked
<    and must remember to send those changes to the remaining peers when
<    the connection becomes unblocked.
---
 >    buffer can grow until memory is exhausted.  A BGP implementation is
 >    required to send changes to all peers for which the TCP connection 
is
 >    not blocked and is required to remember to send those changes to 
the
 >    remaining peers when the connection becomes unblocked.
769,773d776
<    Implementers may find it useful to order path attributes according 
to
<    Type Code so that sets of attributes with identical semantics can 
be
<    more quickly identified.
<
<
776a780,782
 > McPherson, Patel                                  Section 14.  [Page 
14]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
778a785,787
 >    Implementers may find it useful to order path attributes according 
to
 >    Type Code so that sets of attributes with identical semantics can 
be
 >    more quickly identified.
780,782d788
< McPherson, Patel                                  Section 14.  [Page 
14]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
802c808,810
<    to BGP-4 should provide the version support on a per-peer basis.
---
 >    to BGP-4 should provide the version support on a per-peer basis.  
At
 >    the time of this writing all BGP speakers on the Internet are 
thought
 >    to be running BGP version 4.
822a831,840
 >
 >
 >
 >
 >
 > McPherson, Patel                                  Section 17.  [Page 
15]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
833,840d850
<
<
<
< McPherson, Patel                                Section 17.1.  [Page 
15]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
844a855,867
 >    It was naively assumed by many for some time that in order to 
inject
 >    a data segement or reset a TCP transport connection between two BGP
 >    peers an attacker must correctly guess the exact TCP sequence 
number
 >    (of course, in addition to source and destination ports and IP
 >    addresses).  However, it has recently been observed and openly
 >    discussed that the malicous data only needs to fall within the TCP
 >    receive window, which may be quite large, thereby significantly
 >    lowering the complexity of such an attack.
 >
 >    As such, it is recommended that the MD5 TCP Signature Option be
 >    employed to protect BGP from session resets and malicious data
 >    injection.
 >
867a891,896
 >
 > McPherson, Patel                                Section 17.2.  [Page 
16]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
888,896d916
<
<
<
<
< McPherson, Patel                                Section 17.3.  [Page 
16]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
924a945,952
 >
 >
 >
 > McPherson, Patel                                Section 17.5.  [Page 
17]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
946,952d973
<
<
< McPherson, Patel                                Section 17.6.  [Page 
17]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
979a1001,1008
 >
 >
 >
 > McPherson, Patel                                Section 17.6.  [Page 
18]
 > ^L
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
 >
 >
1004,1008d1032
< McPherson, Patel                                Section 17.6.  [Page 
18]
< ^L
< INTERNET-DRAFT             Expires: March 2004            September 
2003
<
<
1036,1059d1059
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
1062c1062
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1118c1118
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1139c1139,1140
<    [BGP4-ANALYSIS] Work in Progress.
---
 >    [BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in
 >               Progress.
1141c1142,1143
<    [BGP4-IMPL] Work in Progress.
---
 >    [BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work
 >               in Progress.
1146c1148
<    [SBGP]
---
 >    [SBGP]  "Secure BGP", Internet-Draft, Work in Progress.
1148c1150
<    [soBGP]
---
 >    [soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.
1170,1171d1171
<
<
1174c1174
< INTERNET-DRAFT             Expires: March 2004            September 
2003
---
 > INTERNET-DRAFT           Expires: November 2004                 May 
2004
1179c1179
<    Copyright (C) The Internet Society (2003). All Rights Reserved.
---
 >    Copyright (C) The Internet Society (2004). All Rights Reserved.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr