Re: L2VPNs must not be IP(v4)-only

[followup to a reply that wasn't cc'ed to the IETF list, but I think 
it's relevant for the broader audience ]
> Two of the fundamental tenets of education is: a) a willingness to 
> learn; and, more importantly, b) a willingness to teach/lead/show 
> others.  No one in the L2VPN WG has expressed an unwillingness to learn 
> about IPv6; instead, no one within the WG (modulo Giles; thanks Giles!), 
> or elsewhere, has expressed a willingness to lead the group in 
> developing the requisite features required to support IPv6 wrt ARP-MED.  
> Unfortunately, your impudent message has not demonstrated a willingness 
> to help lead the group wrt IPv6 support, leaving us no further ahead 
> than where we were before.  It would be much more productive if you 
> could help contribute to the solution, rather than cast broad criticism 
> against the WG.
My message was not directed specifically to L2VPN.  Really it was a 
statement about IETF and the qualifications to do engineering in this 
space.
Several years ago when I was an AD I was shocked to find that the 
principal participants in one of my working groups really didn't know 
what IP was and only had the vaguest understanding of TCP.  They didn't 
know about the limitations of remote procedure calls or the 
idiosyncrasies of slow-start and congestion control; they didn't know 
anything about security or scalability.  Based on this lack of 
knowledge, they had somehow decided that it was okay to run all of their 
traffic over HTTP, using a remote procedure call paradigm, to use port 
80 as a default port, to not have any authentication in their protocol 
and to expect network administrators to filter traffic for their 
protocol at firewalls (because in their minds nobody would ever want to 
use their protocol across administrative domains, nothing wrong with 
using IP addresses as authentication tokens, and no reason why a network 
admin wouldn't want to enumerate every one of the devices running this 
protocol and block each one's address individually).  In other words, 
they were completely (and aggressively) clueless about the field of 
endeavor they had adopted - and furthermore they thought it was someone 
else's job to teach them how to do the engineering that they had agreed 
to do.  Frankly, I found this unacceptable, and I still do.
I'm not accusing L2VPN of being that bad or anywhere nearly that bad.  I 
am not familiar with the work that you've done and don't expect to take 
the time to review it.  But the fact that you didn't consider IPv6 in 
your initial design certainly raises a red flag (didn't this come up in 
the problem definition phase?), as does the apparent expectation that 
IPv6 experts should help you design that part of the protocol.  If I 
were still an AD I would be making a mental note that your documents 
should receive extra scrutiny during review, as such statements cast 
doubt on the group's competency.  On the other hand if the group had 
said to IESG, well before Last Call, "we understand that IPv6 is 
important, and we have this draft spec for how to do L2VPN for IPv6, 
based on our imperfect understanding of the IPv6 and RD/ND protocols, 
and we have some questions about whether we did it right, and we want 
someone to check it for sanity before we invest too much into it", I'd 
be thinking that the group really had its act together.
IETF is not an educational organization, it is an engineering 
organization.  Among the fundamental aspects of the discipline of 
engineering are ability to define requirements, perform analysis, read 
component specifications, synthesize designs, and predict the behavior 
of those designs.  When I went to school to learn electrical engineering 
I wasn't given a tremendous amount of help in how to use specific 
components like transistors or transformers; rather I was taught how to 
do circuit analysis, and given circuits that modeled the behavior of 
those components.  I was then expected to use circuit analysis skills to 
model how a more complex circuit using those components would function, 
and finally, to design circuits according to certain specifications and 
using those components.  Similar processes were used by my friends in 
other engineering disciplines, and I don't see why network protocol 
engineers should not at least attempt to analyze the effects of using 
combinations of network protocols and to predict the behavior of new 
combinations of network protocols.
In this case, there are specifications for IPv6 and router/neighbor 
discovery that are freely available for anyone to read.  Perhaps they're 
not basic reading material for just anyone, but they are not overly 
complex.  I don't see why people who are qualified to be IETF 
participants shouldn't be able to read and understand them and at least 
tentatively base designs on them.  There might be some aspects of the v6 
protocols that are hard to understand, but surely it is easier to find 
IPv6 experts to answer specific questions than to find IPv6 experts who 
are willing to conduct tutorials.  Again, there might be some aspects of 
the design that make L2 tunneling difficult, leading to a difficult 
design choice - but surely such choices can be identified, and surely it 
is easier to get IPv6 experts to answer questions about specific design 
decisions than to get IPv6 experts to design the IPv6 portion of your 
protocol for you.
Maybe in industry the usual practice is to hire an expert in a topic 
rather than to have someone already on board to apply basic engineering 
skills to a new problem domain.  That might be a faster way of getting 
something done, to jump ahead of the learning curve.  But it's also hard 
to make good compromises between different considerations if the people 
involved don't have at least a rudimentary understanding of most of 
those considerations.  So as applied to L2VPN - basically I think that 
the principals behind the L2VPN design need to learn enough about IPv6 
and RD/ND to have at least a rough idea of what needs to happen to make 
it work, even if you find an IPv6 expert who has a more precise idea. 
Because at some point you're probably going to find a case where a 
compromise is needed and without some shared understanding you aren't 
going to be able to see what kind of compromise is a good one.
Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf