Can't find Bob's original email !
So I'll respond to this part.
> On Thu, 31 Jan 2002, Bob Hinden wrote:
> > Another approach is add text to make it clear that when
> there are multiple
> > administrative domains involved that the preferences can
> only be compared
> > it they are
On Thu, 31 Jan 2002, Bob Hinden wrote:
> Another approach is add text to make it clear that when there are multiple
> administrative domains involved that the preferences can only be compared
> it they are being set in the same manner. I don't think there is any
> simple automatic way of doing
Hesham,
Another approach is add text to make it clear that when there are multiple
administrative domains involved that the preferences can only be compared
it they are being set in the same manner. I don't think there is any
simple automatic way of doing this (and I think we would want to av
Bob,
> >=> My 2 cents on the preference values:
> >It's not only that there is only 3 values, but
> >that these values may be used across different
> >administrative domains (multihomed hosts). They
> >need to be consistently defined so 'good' in
> >ISP X domain is roughly the same as
Hesham,
>=> My 2 cents on the preference values:
>It's not only that there is only 3 values, but
>that these values may be used across different
>administrative domains (multihomed hosts). They
>need to be consistently defined so 'good' in
>ISP X domain is roughly the same as 'good'
>in ISP Y's d
In your previous mail you wrote:
Is it just the absense of such a knob to the administator that is lacking?
=> the knob.
Or is there a need to have a rich set of preferences? (RFC 1256 has 256
different values vs. router preferences has only 3 values).
=> no, I believe we can live
> Is it just the absense of such a knob to the administator
> that is lacking?
> Or is there a need to have a rich set of preferences? (RFC
> 1256 has 256
> different values vs. router preferences has only 3 values).
=> My 2 cents on the preference values:
It's not only that there is
> I have no doubts that router vendors will ship router preferences. That's
> not what I'm concerned with. I'm concerned that host implementors implement
> it, or that they don't implement load sharing. That is, a host that simply
> picks one default router, and sticks with it as long as it i
On Fri, 25 Jan 2002, Robert Elz wrote:
> I have no doubts that router vendors will ship router preferences. That's
> not what I'm concerned with. I'm concerned that host implementors implement
> it, or that they don't implement load sharing. That is, a host that simply
> picks one default rou
Date:Tue, 22 Jan 2002 17:02:47 -0800
From:Bob Hinden <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I think there are two cases. One is where there are two routers that
| provide equivalent service. The other is where the are two or more routers
| tha
In your previous mail you wrote:
1) Requirement level of SHOULD would make existing implementations
non-compliant.
2) Relationship of this change to Neighbor Discovery and Default Router
Preferences draft. Should they be combined?
=> what we asked is not really a combinais
Date:Mon, 21 Jan 2002 17:22:08 -0800
From:Bob Hinden <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The reason why the conclusion of the w.g. in Salt Lake City was to keep the
| documents separate is that this document is changing the base behavior of
|
> Bob Hinden wrote:
> There is considerable current practice that disputes this. The
> specific case that this draft addresses (host to router traffic)
> is very widely deployed using protocols such as VRRP and Cisco's
> HSRP. The advantage of distributing the load over multiple
> routers is tha
Instead of trying to reply each email I will attempt to summarize and
respond to the comments in the last set of email.
1) Requirement level of SHOULD would make existing implementations
non-compliant.
I believe that the definition of SHOULD (see RFC2119) allows for alternate
behavior if ther
14 matches
Mail list logo
