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
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
> .
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
