Subject: proxy: more comments on draft -18

From: Alex Zinin <[email-masked]>
Date: Sat, 30 Nov 2002 21:52:34 -0800

Comments from another rtg-dir reviewer.
May overlap with those already discussed--
didn't check latest threads.

Thanks.

-- 
Alex

Almost all of these are simple clarifications.

Section 1, page 5: IGP definition - it's not clear from this
definition whether IBGP would be considered an IGP?

Section 3, page 7, para 4: Does RFC 1772 still represent the *planned*
use of BGP?  Or the actual use?  Or something different from actual
use?

Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
seems obsolete.

Section 4.1, page 11 - Length is in network byte order.

Section 4.2, page 12 - "My autonomous system" and "Hold time" are in
network byte order.

Section 4.2, page 12 - Hold Time - what does a value of zero indicate?

Section 4.2, page 13 - BGP Identifier - network byte order?  
        "IP address" -> "IPv4 address"

        This section should probably comment on the globally
        routable/uniqueness requirements of BGP ID.

Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path
attributes"

Section 4.3, Page 14/15: all multi-byte length fields - network byte order

Section 4.3, Page 16 - two byte extended length is in network byte order.

Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address"
        Specify that this is 4 octets.
        Reference here to multi-protocol extensions for IPv6 nexthop?

        RFC 2283 is unclear whether NEXT_HOP should always be included
        when using multiprotocol extensions. Clarify this here?

Section 4.3, Page 17/18 - MED and LocalPref:  
        "non-negative" -> "unsigned" for consistency with elsewhere.
        (non-negative might imply values > 2^31 cannot be used).

Section 4.3, Page 18 - AGGREGATOR:  "IP address" -> "IPv4 address".

Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address"
        Prefix: "enough trailing bits to" -> "the minimum number of 
        trailing bits needed to"
 
Section 4.4, Page 20:  - "BGP does not use any TCP-based keep-alive
mechanism to determine if peers are reachable".  Is it worth noting
that TCP may still timeout the connection even if TCP keepalives are
turned off?
"
Section 4.4, Page 20:
KEEPALIVE message consists" -> "A KEEPALIVE message consists"

Section 5, Page 23: "The same attribute can not appear more than once
with the Path Attributes field...".  Does this mean the same attribute
type, or the same attribute type and value?

Section 5.1 "The usage of each BGP path attributes .." -> attribute

Section 5.1.3 "IP address" -> "IPv4 address"

"A BGP speaker must never advertise an address of a peer to that peer
as a NEXT_HOP, for a route that the speaker is originating."
  suggest replace this text with:
"A route originated by a BGP speaker must never be advertised to a
peer using an address of that peer as NEXT_HOP"

Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which
allows the MULTI_EXIT_DISC to be removed from a route."  Might want to
say that this is dangerous unless you received the route from an EBGP
peer? 

Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE message
that is received from an external peer, then this attribute MUST be
ignored by the receiving speaker, except for the case of BGP
Confederations [RF3065]."
 - "ignored" might be taken to mean that you don't process it for
   decision, but that you propagate it to internal peers.  I might
   write "silently removed" or something similar.

Section 5.1.5, para 2.  "set of AS" -> "set of ASs"

Section 5.1.7: "IP address" -> "IPv4 address"

Secton 6.2: note that Data field is in network byte order.

Section 6.2, para 5: "IP host address" -> "IPv4 host address"

Section 6.3, wrt NEXT_HOP: "IP address" -> "IPv4 address"

Section 6.3: wrt NEXT_HOP semantic correctness: should we check that a
NEXT_HOP is not a multicast or broadcast address?

Section 6.3, page 32, para 7:  "peer than sent" -> "peer that sent"

Section 6.3: "if any attribute appears more than once" - does this
mean the same attribute type, or the same attribute type and value?

Section 6.8 "Comparing BGP identifiers is done by treating them as
(4-octet-long) unsigned integers".  Need to convert to host byte order
before comparing.

Section 6.8, item 2:  "closes BGP connection" -> "closes the BGP connection"
"accepts BGP connection" -> "accepts the BGP connection".

Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it is
unclear for IBGP connections how to determine "the neighbor AS from
which the other IBGP speaker learned the route".  If this is really
the leftmost entry in the AS path (or the local AS if the path is
empty), the spec should explicitly say so.

Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
attribute is removed before..."  The first sentence is pretty nearly
incomprehensible.

Section 9.1.2.2 (d)
     "d) If at least one of the candidate routes was received from an
      external peer in a neighboring autonomous system, remove from con-
      sideration all routes which were received from internal peers."
For consistency with (c) and clarity, this might be reworded:
     "d) If any of the candidate routes was learned via EBGP, remove
     from consideration all routes which were learned by IBGP."

Section 9.1.2.2 (e)
     "cost (n) is better than cost (m)"
     Given the definition of cost, it might be clearer to say 
     "cost (n) is lower than cost (m)"

Section 9.1.2.2 (g)
     "neighbor address" has not been defined.

Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes of
     all routes to be aggregated should be ignored."  

     Perhaps "ignored" is ambiguous here, and it's not clear whether
     should is a SHOULD.  Suggest:

     "Any AGGREGATOR attributes from the routes to be aggregated MUST
     NOT be included in the aggregated route."

Section 9.3 - shouldn't this subsection be moved to the discussion of
Phase 1 or Phase 2 of the decision process?  Or at least move it
before Section 9.2.

Appendix E, para 2: IP precedence has been deprecated.  Delete this
paragraph, or replace with appropriate diffserv codepoint.

Security Considerations:
   "BGP supports the ability to authenticate BGP messages by using BGP
   authentication."
   This sentence should be removed, and the Authentication Information
   parameter has been deprecated.

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 01 Dec 2002 09:16:18 -0800

Alex,

> didn't check latest threads.

any suggestion on how to improve the definition to clarify
this issue would be appreciated.

> use of BGP?  Or the actual use?  Or something different from actual

Perhaps we should just take out references to 1772. 
  
> Section 3, page 8, para 3 - "The hosts executing..."  This paragraph

I'll take it out.

> Section 4.1, page 11 - Length is in network byte order.

all the encodings are in network byte order. This applies not just
to the BGP spec, but to other protocols as well. 
  
> Section 4.2, page 12 - Hold Time - what does a value of zero indicate?

if you read section 4.4 then you'll find that:

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.

>         "IP address" -> "IPv4 address"

I'll put at the beginning a sentence saying that in the context of
this document the term "IP address" means an IP Version 4 address.

> Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path

fixed.

>         Reference here to multi-protocol extensions for IPv6 nexthop?

no.

>         when using multiprotocol extensions. Clarify this here?

It is already clarified in 2283bis.

>         (non-negative might imply values > 2^31 cannot be used).

fixed.

>         Prefix: "enough trailing bits to" -> "the minimum number of 

fixed.

> that TCP may still timeout the connection even if TCP keepalives are

the text is fine as it is.

> KEEPALIVE message consists" -> "A KEEPALIVE message consists"

fixed.

> type, or the same attribute type and value?

the former (the same attribute type).
  
> Section 5.1 "The usage of each BGP path attributes .." -> attribute

fixed.

> peer using an address of that peer as NEXT_HOP"

fixed.

> say that this is dangerous unless you received the route from an EBGP

I think we should keep the text as is.

>    write "silently removed" or something similar.

I think the text is ok as is.

> Section 5.1.5, para 2.  "set of AS" -> "set of ASs"

fixed.

> NEXT_HOP is not a multicast or broadcast address?

I'll add to the definition of NEXT_HOP that it is a unicast address.
  
> Section 6.3, page 32, para 7:  "peer than sent" -> "peer that sent"

fixed.

> mean the same attribute type, or the same attribute type and value?

the former.

> (4-octet-long) unsigned integers".  Need to convert to host byte order

fixed.

> "accepts BGP connection" -> "accepts the BGP connection".

fixed.

> empty), the spec should explicitly say so.

fixed.

> attribute is removed before..."  The first sentence is pretty nearly

here is my attempt to clarify this:

  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
  route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 
  attribute may only be considered in the comparison of EBGP learned
  routes; the attribute is then removed, and then the remaining EBGP
  learned routes may be compared to the remaining IBGP learned routes,
  without considering the MULTI_EXIT_DISC attribute for those EBGP
  learned routes whose MULTI_EXIT_DISC attribute will be removed   
  before advertising these routes to IBGP.

Any further suggestions on how to improve this would be appreciated.

>      from consideration all routes which were learned by IBGP."

fixed.

>      "cost (n) is lower than cost (m)"

fixed.

>      "neighbor address" has not been defined.

I'll replace "neighbor address" with "peer address".

>      NOT be included in the aggregated route."

fixed.

> Phase 1 or Phase 2 of the decision process?  Or at least move it

I think it is fine where it is now.

> paragraph, or replace with appropriate diffserv codepoint.

deleted.

>    parameter has been deprecated.

Please see the recent e-mail exchange on the Security Considerations

Yakov.