Subject: Re: Issue 18

From: Curtis Villamizar <[email-masked]>
Date: Sat, 01 Feb 2003 18:09:53 -0500

In message <[email-masked]>, [email-masked]
s.net writes:
> Although I don't want to extend the time this issue is still open, I have 
> to agree with mrr here.  The text, as it stands is not as clear as 
> the text mrr is proposing, or the text I proposed a while back.  Of the
> two alternates, I prefer mrr's text, since it states more clearly that
> the comparison is optional.  
> 
> Is there any compelling reason NOT to go with one of these two?
> 
> >  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> >  route into IBGP, then if MULTI_EXIT_DISC comparisons are performed
>                     ^^^^^^^  "and if" better?
> >  during tie-breaking, the routes that will have their MULTI_EXIT_DISC
> >  attributes removed before readvertisement in IGBP MUST be treated
> >  as having been received without a MULTI_EXIT_DISC attribute.
> 
> 
> or
> 
> >  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> >  route into IBGP, then comparison based on the received MULTI_EXIT_DISC
> >  attribute MAY still be performed.  If an implementation chooses to
> >  perform this comparison, then the comparison MUST be performed only
> >  among EBGP learned routes, and it MUST be performed before the removal
> >  of the MULTI_EXIT_DISC attribute.
> 
> Andrew

The second one is wrong.  The second sentence should start with "If an
implementation chooses to remove MULTI_EXIT_DISC".  Replace "perform
this comparison" with "remove MULTI_EXIT_DISC" in the second sentence,
it then becomes redundant.  Since the comparison is optional, the "and
it MUST be performed before the removal ..."  could be interpreted as
an ambiguity (is it optional or not).

   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
   route into IBGP, then comparison based on the received EBGP
   MULTI_EXIT_DISC attribute MAY still be performed.  If an
   implementation chooses to remove MULTI_EXIT_DISC, then the optional
   comparison on MULTI_EXIT_DISC if performed at all MUST be performed
   only among EBGP learned routes.  The best EBGP learned route may
   then be compared with IBGP learned routes after the removal of the
   MULTI_EXIT_DISC attribute.  If MULTI_EXIT_DISC is removed from a
   subset of EBGP learned routes and the selected "best" EBGP learned
   route will not have MULTI_EXIT_DISC removed, then the
   MULTI_EXIT_DISC must be used in the comparison with IBGP learned
   routes.  For IBGP learned routes the MULTI_EXIT_DISC MUST be used
   in route comparisons which reach this step in the decision process.

I think all cases are covered.  I think the above is unambiguous.  If
we must change it, might as well make it completely unambiguous
preferably without becoming cumbersome or overly wordy.

Curtis

---

From: Mathew Richardson <[email-masked]>
Date: Mon, 3 Feb 2003 11:50:07 -0500

> Curtis Villamizar <[email-masked]> [Sat, Feb 01, 2003 at 06:09:53PM -0500]:
>

<snip>

>> >  of the MULTI_EXIT_DISC attribute.

<snip>

>an ambiguity (is it optional or not).

I disagree, but that doesn't matter since I'm fine with your proposed
text below.  In fact, I prefer it because it clarifies the handling
of the comparison between EBGP and IBGP learned routes in the presence
of MULTI_EXIT_DISC stripping.

>   in route comparisons which reach this step in the decision process.

<snip>

mrr

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 03 Feb 2003 12:11:55 -0500

<snip>

> of MULTI_EXIT_DISC stripping.

OK.

> >   in route comparisons which reach this step in the decision process.

If there is no disagreement about changing our prior near consensus,
then we have no real change in the intent but some additional
clarification and may have converted "not quite concensus" to full
concensus.  Full consensus is good if that's what we have.

Curtis

ps - I wonder if there is any "most modified paragraph" in bgp4 where
the meaning was not changed just the wording.  It would have to be
somewhere in route selection or the state machine.  No Cc to the list
please - if it gets started it could be a lengthy thread.  :-)

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 05 Feb 2003 06:10:37 -0800

Curtis,

> concensus.  Full consensus is good if that's what we have.

Your text will be incorporated into the next release of the draft.

Yakov.