[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grow: Re: WGLC for Operation of Anycast Services (draft-ietf-grow-anycast-02.txt)
I think thats fair enough.
Though I think you misunderstand the meaning of the end of discussion in your
summary at the bottom of this message; the text you quote in the last message
does not address the dispute over "node selection". I didn't respond because it
is plain that Joe and I are are not making progress, so I made no further
response. Joe only restated what he said before. I could only restate what I
had already restated:
It is plain to me that no IP protocol stack performs "node selection", and that
the descriptions of "node selection" are incorrect. IP protocol stacks perform
"next hop" selection, as described in RFC 1812, as I stated several times.
Plainly Joe doesn't think so, inspite of the authoritatives sources quoted.
The effect of this language is to conceal or obscure the issue of non-parallel
links leading to different anycast hosts which subsequently cannot maintain the
necessary state for TCP or for PMTUD retransmissions. These problems were
described in RFC1546 and are not overcome by this Anycast Extension, except in
severely limited circumstances.
And there remain other issues: For example, Joe doesn't express any experience
with PPLB over diverse paths, yet asserts that it inexplicably performs
differently than PPLB over parallel links. But we agree and he acknowledges
that TCP performance impact is minor on parallel links. I pointed out all paths
to unicast addresses are parallel. Only the introduction of the Anycast
Extension makes them not-parallel and then only to the Anycast hosts. As RFC1546
noted, this is OK so long as no state is required on the Anycasted host. The
Anycast Extension draft basically gives one the incorrect impression that state
can be maintained through some BGP configuration, even though that remains
impossible unless severe restrictions are imposed on PPLB, and on any future
fast load-splitting technology, or even future fast route-updating technology.
And no one reported direct experiences of "severe" TCP performance impact, nor
did anyone report direct experience that "TCP would break", which to me means
"fail" over diverse paths. On the contrary, as I pointed out, the performance
impact is negligible, TCP doesn't break in any case. There is experience with
diverse paths. For example, there is no evidence of "severe" problems with
multipath BGP on diverse paths. There is no evidence of "pathological topology",
as asserted in the draft. While I agree that there is a minor TCP performance
consideration, it is important to note that performance of TCP is not the only
consideration in network design. PPLB on diverse paths significantly improves
UDP (e.g. streaming audio, video, VOIP) performance and response to network
failures.
Can consenting networks make the Anycast Extension work? They could, _if_ they
are willing to give up certain things such as PPLB and don't have Cisco GSR
Engine-2 systems, etc. However, they need to coordinate, and they ought to be
aware of what they are trading off. [BTW, I note here again that when Nanog was
queried regarding the degree to which PPLB was used at present, Nanog posters
asserted confidently and without dispute that the Cisco GSR didn't do PPLB and
_architecturally_couldn't_do_ PPLB. Not only was this completely false, but in
fact Cisco recommends either PPLB on every interface, or PPLB on no interfaces
(technical note on GSR E-2) PPLB on parallel links, eg 2 OC3s instead of an OC12
or 2 OC12's in place of OC48, is fairly common. The Nanog mis-information was
quite disturbing, since it altered and falsely weakened arguments made against
the Anycast Extension in other forums.]
To be perfectly clear: Of the eight issues I raised, I concede two:
#5 I agree that the reference to ISC-TN-2004-1 is OK in a BCP (my issue #5).
#7 On the issue of the usage of term "PPLB", (my issue #7) I agree that my
original concern was addressed for that issue: I agree with the assertion that
PPLB is a subset of "load-splitting", and that the draft's use of the term
"PPLB" instead of "load-splitting" is acceptable.
The other 6 issues were not adequately addressed, in my view. I think they
still remain issues. When the RFC issues, these will remain as criticisms.
Whether these criticisms eventually discredit the RFC in the same way that some
RFC2991 assertions have been discredited, remains to be seen. But the WG
decision has been made, so lets move the process forward. Whether there is wide
support or indifference is hard to tell. But the Chairs see a consensus, and
I'm not disputing their judgement.
Rather, my interest now is to record that there were objections raised at the
time. I'm willing to acknowledge that these objections were a minority view.
I appreciate your attention to the accuracy of the record.
--Dean
On Thu, 1 Dec 2005, Geoff Huston wrote:
> Thank you for your note
>
> You are correct in noting that there was a set of postings on the 4th
> through the 7th November on this topic, and to keep the record accurate,
> these postings in the last call period can be found at:
>
> http://darkwing.uoregon.edu/~llynch/grow/msg00426.html
> http://darkwing.uoregon.edu/~llynch/grow/msg00427.html
> http://darkwing.uoregon.edu/~llynch/grow/msg00428.html
> http://darkwing.uoregon.edu/~llynch/grow/msg00430.html
> http://darkwing.uoregon.edu/~llynch/grow/msg00431.html
> http://darkwing.uoregon.edu/~llynch/grow/msg00432.html
> http://darkwing.uoregon.edu/~llynch/grow/msg00433.html
>
> To quote from the final message in this thread:
>
> "I think you are being over-literal, and judging from the response (or
> non-response) of others I think your objections to this turn of phrase are
> not widely shared.
>
> Note that the process we are participating in is one of rough consensus and
> not universal agreement "
>
> I have seen no further working group postings on this draft during this
> last call period, and no observed working group consensus to create another
> revision of this draft.
>
> Thanks for noting this,
>
> regards,
>
> Geoff
>
>
>
>
> At 09:00 AM 1/12/2005, Dean Anderson wrote:
> >On Tue, 22 Nov 2005, Geoff Huston wrote:
> >
> > > Folks,
> > >
> > > The WG Last Call for this draft to be passed to the ADs for AD and IESG
> > > review has now been completed, and there have been no postings in response
> > > to this last Call during the comment period.
> >
> >Actually, there were postings during the comment period, against the draft.
> >Apparently, you ignored them, and perhaps the postings did represent a
> >minority
> >view, but I think you should keept the record straight and note that there
> >were
> >postings against this draft.
> >
> > --Dean
> >
> > >
> > > Dave and I will not pass this document across to the AD with a request to
> > > publish this WG draft as an informational RFC
> > >
> > > regards,
> > >
> > > Geoff & Dave
> > >
> > >
> > >
> > >
> > > At 04:47 AM 5/11/2005, Geoff Huston wrote:
> > > >Folks
> > > >
> > > > This note starts the WG Last Call for comments on
> > > > draft-ietf-grow-anycast-02.txt, "Operation of Anycast Services".
> > > >
> > > > It can be found at:
> > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-anycast-02.txt
> > > >
> > > > Please review the document carefully, and send your
> > > > feedback to the GROW list. Please also indicate whether or
> > > > not you believe that this document is ready to go to the
> > > > IESG.
> > > >
> > > > This Last Call will end on 19 Nov 2005 at 0800 AEDT
> > > > (UTC+11).
> > > >
> > > > Thanks,
> > > >
> > > > Geoff & Dave
> > >
> > >
> > > _________________________________________________________________
> > > web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
> > > web archive: http://darkwing.uoregon.edu/~llynch/grow/
> > >
> > >
> >
> >--
> >Av8 Internet Prepared to pay a premium for better service?
> >www.av8.net faster, more reliable, better service
> >617 344 9000
> >
> >
> >_________________________________________________________________
> >web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
> >web archive: http://darkwing.uoregon.edu/~llynch/grow/
>
>
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/