Subject: RE: proxy: more comments on draft -18

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Mon, 2 Dec 2002 17:23:28 +0530

Hello,

    My comments are inline.

> > 
> > Section 1, page 5: IGP definition - it's not clear from this
> > definition whether IBGP would be considered an IGP?
> 
> any suggestion on how to improve the definition to clarify
> this issue would be appreciated.

   IBGP is not a protocol, so is such a clarification really required ?

   If it will make things clearer for readers, however, how about a simple
clarification along the lines of:

   The usage of BGP to distribute routing information within an AS does not
fall under this definition of 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?
> 
> Perhaps we should just take out references to 1772. 

  My opinion is this should stay, because it does act as pointer to useful
information on this topic.

>
> > Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
> > seems obsolete.
> 
> I'll take it out.

    Don't some route optimization vendors sell boxes that operate on this
basis ?

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

  Do you think it is useful to state once at the beginning of the document
that all fields are considered to be in network order ?

> 
> >  
> > 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?
> 
> the text is fine as it is.

  I concur.

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

  How about this:

%   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
%   route into IBGP, then comparison based on the MULT_EXIT_DISC
%   attribute may (MUST?) be performed only among the EBGP learned routes.
%   This comparison MUST be performed before the removal of the
%   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
%   be removed from those EBGP routes where such removal is required and
%   which are still eligible. This is followed by comparison with IBGP
%   learned routes.

    I think this reflects our objectives, which is:

    a) If MED is to be removed, compare EBGP routes based on the MED

    b) Then remove the MED

    c) Then do comparison with IBGP routes

> 
> > 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.
> 
> I think it is fine where it is now.

  I concur.

Siva
([email-masked])

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 02 Dec 2002 06:54:34 -0800

Siva,

>    IBGP is not a protocol, so is such a clarification really required ?

Just to add, a reader possessing a thorough understanding of
foundations of this work, including IP routing, and the referenced
documents wouldn't consider IBGP as an IGP.

> information on this topic.

It will stay, but just in the reference section.

> that all fields are considered to be in network order ?

I'll do this for the next revision.

>     c) Then do comparison with IBGP routes

If nobody would propose anything better, then I'll use your text in
the next revision.

> > I think it is fine where it is now.

Thanks for your comments.

Yakov.

---

From: Mathew Richardson <[email-masked]>
Date: Mon, 2 Dec 2002 12:23:46 -0500

> Yakov Rekhter <[email-masked]> [Mon, Dec 02, 2002 at 06:54:34AM -0800]:
>Siva,

<snip>

>If nobody would propose anything better, then I'll use your text in

<snip>

I've always thought (perhaps erroneously) that the reason support for
removing MEDs was included in the spec was to allow an AS to choose to
ignore MEDs.  If it is desirable to allow an AS to choose to ignore MEDs,
and this was the motivation for supporting the removal of MEDs, then I
propose:

	If a MULTI_EXIT_DISC attribute will be removed before re-
	advertising a route into IBGP, then the attribute SHALL be
	considered missing when performing comparisons based on the
	MULTI_EXIT_DISC attribute of a route.

mrr

---

From: [email-masked]
Date: Mon, 2 Dec 2002 15:28:45 -0800

> If nobody would propose anything better, then I'll use your text in

How about:

If a router is configured to remove a MUTLI_EXIT_DISC attribute from
a route learned from EBGP, before readvertising it into IBGP the
router MUST compare the route with other EBGP-learned routes before
removing the MULTI_EXIT_DISC.  Once this comparison is complete, 
the MED may be removed, and any remaining routes can be compared with 
IBGP routes to determine the best route.

Andrew