On 20/12/2017 11:27, Khaled Omar wrote:
Hi Robert,
It is true, i'll address these questions and will replace the
existing text with a clear introduction about a comparison between
KRP and BGP and between NEP and other IGPs so it can provide a
brief description about the drafts.
Will be appreciated if you read the full drafts and have a
technical discussion if you are interested.
I'm really sorry, but not really. Alas, I'm not one of the routing
experts that you are looking for!
I've given some quick comments form my cursory review:
- It seems that the IPv10 draft has already been discussed/dismissed
so I've not spent time on that one.
KRP draft:
- (Not technical) Naming the protocol after yourself is probably
not doing yourself any favours, sorry, but it makes you come across
as arrogant or naive.
- I don't agree that this is solving a real problem.
- How is this solution superior to standard hierarchical addressing
in IPv4/v6?
- This isn't just a routing protocol, but also has its own
forwarding plane. Normally, I would suggest splitting the two of
these up, and perhaps reuse one of the existing forwarding planes.
- This draft seems to be incredible short, and doesn't seem to
describe a fully thought out solution.
NEP draft:
- I have no idea what problem this is trying to solve.
- Why can't OSPF, ISIS, or one of the other IGPs be used instead?
- This draft seems to be incredible short, and doesn't seem to
describe a full solution.
But I suspect that Stephane's comment, although direct, is probably
to the point. From my limitation knowledge of routing protocols,
then I do not think that the drafts that you are proposing introduce
significant new ideas that the routing protocol experts haven't
thought of before. Possibly folks might spend more time on these
drafts if it was clear that you are an expert in routing protocols,
but alas that is not how the existing drafts come across.
To give a comparative example, at the last IETF there was a BOF on
DC routing with 2 main solutions presented, and (IIRC) 3 other
solutions. All of these 5 competing solutions seemed to be backed
by experts in their field (most of whom I recognized from attending
previous IETFs).
I was particularly impressed by Tony's presentation on RIFT (a
proposed brand new DC routing protocol). His presentation made it
clear on what problem was being solved, why he considered that a new
protocol is appropriate, and what advantages a new protocol has.
Added to that, I had met Tony in person and he came across as
someone whom clearly knows what he is talking about, he has produced
10 RFCs spanning 17+ years , has 15 active drafts, etc. The draft
is also backed by other people that I know/respect (one of them
representing an ISP).
Hence may I also suggest that you try and get involved helping in
some of the WGs that specialize in the existing protocols first,
before you try and convince everyone that they are doing it all
wrong and you have thought of a better solution.
Kind regards,
Rob
-------- Original Message --------
Subject: Re: When the IETF can discuss drafts seriously?
From: Robert Wilton
To: Khaled Omar
CC: ietf ,rtgwg
Hi Khaled,
As a relative newcomer to IETF, I can perhaps give two
(hopefully
positive) suggestions (sorry, none of which is
technical):
(1) From taking a very quick look at your drafts, it
may be helpful to
have three sections at the top of the drafts that
answer these 3
questions (before you describe the new protocols):
i) What is the problem that the draft is solving?
ii) Why the problem cannot be cleanly solved with
existing
protocols/technology (which would normally be much
cheaper than
designing a new protocol)?
iii) How does the new protocol/technology solves the
problem?
I.e. I think that you need to first convince the
community that there is
a problem to be solved, before they will invest their
time looking at a
solution.
(2) In my brief experience, it is as important to
build consensus, as it
is to write good clear drafts. E.g. attend IETF, meet
the key folks in
the WGs (e.g. WG chairs and the main/frequent
presenters in the WGs),
present your ideas (but again, for a presentation, I
would focus on just
the 3 questions above), try and get other individuals
in different
companies/organizations that align with your approach
(and who would be
willing to put their name on your draft(s)). If you
have vendors
implementing these protocols, and ISPs deploying them,
then that is also
a big help. If you can show that you have a deep
technical
understanding of the existing protocols that you
intend to replace,
along with any limitations that they have, then that
will also help.
But at the moment, from a very quick look at your
drafts, it is unclear
to me why we need another new version of the IP
protocol, need to
replace BGP with a new EGP and design a new IGP. I
suspect that the
cost to the industry to develop, standardize, and roll
out these new
protocols (including new forwarding ASICs, etc) would
end up being in
the billions of dollars. So I'm afraid that you need
to find an
extremely compelling reason as to why this is
required, and hence why
folk should invest their limited time in these
protocols.
I hope that this feedback is helpful.
Kind regards,
Rob
On 19/12/2017 20:46, Khaled Omar wrote:
> Hi all,
>
> I noticed that the IETF participants gives only
negative comments regarding the submitted IDs, that is
good in some cases if it is true, but to ignore the
positive side and the added values on every draft is
something that should be changed, I always aim to find
a true technical discussion on the mailing list to add
something new or to correct something wrong with
confidence.
>
> It's been long time on the rtgwg mailing list and
didn't have any technical discussion or comments for
KRP and NEP or even an official review.
>
> I believe that the IETF participants can show
alot from their expertise to add, modify, or delete
something from an existing draft.
>
> Of course there are all kind of people at the
IETF and some of them may be interested and can make a
decision.
>
> Thanks,
>
> Khaled
> _______________________________________________
> rtgwg mailing list
> rtgwg@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/rtgwg
> .
>
|