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

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Aug 2006 07:40:32 +0300 (EEST)

On Wed, 16 Aug 2006, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF.
>
> 	Title		: ARP Mediation for IP Interworking of Layer 2 VPN
> 	Author(s)	: H. Shah, et al.
> 	Filename	: draft-ietf-l2vpn-arp-mediation-07.txt
> 	Pages		: 21
> 	Date		: 2006-8-16
...
> The VPWS service [L2VPN-FRM] provides point-to-point connections
> between pairs of Customer Edge (CE) devices.  It does so by
> binding two Attachment Circuits (each connecting a CE device
> with a Provider Edge, PE, device) to a pseudowire (connecting
> the two PEs).  In general, the Attachment Circuits must be of
> the same technology (e.g., both Ethernet, both ATM), and the
> pseudowire must carry the frames of that technology.  However,
> if it is known that the frames' payload consists solely of IP
> datagrams, it is possible to provide a point-to-point connection
> in which the pseudowire connects Attachment Circuits of
> different technologies. This requires the PEs to perform a
> function known as "ARP Mediation". ARP Mediation refers to the
> process of resolving Layer 2 addresses when different resolution
> protocols are used on either Attachment Circuit. The methods
> described in this document are applicable even when the CEs run
> a routing protocol between them, as long as the routing protocol
> runs over IP.

The document says,

      10. IPV6 Considerations

      The support for IPV6 is not addressed in this draft and is for
      future study.

This needs to be addressed throughout the document.

The whole point of L2VPNs (IMHO) is that it's agnostic of what 
protocols users run above L2.  Users depend on a transparent L2 
service model and this model breaks that assumption.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Shane Amante <[email-masked]>
Date: Thu, 17 Aug 2006 07:28:46 -0600

Pekka,

This topic has come up in the past -- the last time I recall it being a 
significant issue was IETF 63 in Paris, France.  On multiple occasions 
since then we have asked for volunteers with IPv6 expertise to help 
complete the IPv6 bits of this I-D.  Unfortunately, we have gotten 
little to no response.   Do you wish to help out with this?  Or, can you 
provide a pointer to folks in the IPv6 world that can take a look at 
this doc and help out?

Thanks,

-shane

Pekka Savola wrote:
>> a routing protoFrom [email-masked] Thu Aug 17 11:16:19 2006
Date: Thu, 17 Aug 2006 07:28:46 -0600
From: Shane Amante <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: L2VPNs must not be IP(v4)-only

Pekka,

This topic has come up in the past -- the last time I recall it being a 
significant issue was IETF 63 in Paris, France.  On multiple occasions 
since then we have asked for volunteers with IPv6 expertise to help 
complete the IPv6 bits of this I-D.  Unfortunately, we have gotten 
little to no response.   Do you wish to help out with this?  Or, can you 
provide a pointer to folks in the IPv6 world that can take a look at 
this doc and help out?

Thanks,

-shane

Pekka Savola wrote:
> The whole point of L2VPNs (IMHO) is that it's agnostic of what protocols 
> users run above L2.  Users depend on a transparent L2 service model and 
> this model breaks that assumption.
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Aug 2006 11:27:41 -0400

IMHO, there's something fundamentally wrong with any IETF working
group that's not willing to learn about IPv6.  IPv6 is not a specialized
topic, it's the layer common to all parts of the emerging Internet.
And there's little point in standardizing anything new that only works
on IPv4.  I'd go so far as to say that any new protocol that doesn't
support IPv6 has significant "known technical omissions" that should 
make its approval as a Proposed Standard seriously in doubt.

Keith

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 17 Aug 2006 18:02:48 +0100

Hi.

Maybe I wasn't paying attention but I don't recall seeing messages about 
this on either the ipv6 or v6ops mailing list. I guess you may have 
asked around but I'm sure somebody in the wg's could have helped if a 
public request was made (especially the ndproxy authors).

Be that as it may, I agree with Pekka that this document should not 
proceed without the IPv6 case being addressed.  As regards what needs to 
be done, I guess that RFC4389 provides most of the information - note 
that RFC4389 is classified as experimental and there may be some 
discussion as to whether the same arguments that lead to this 
classification apply to the whole of the arp mediation draft.  Both any 
proposed IPv6 support and the existing IPv4 proposals MUST ensure that 
they have satisfactorily addressed the architectural issues in 
draft-thaler-intarea-multilink-subnet-issues-00.txt.

Regards,
Elwyn

Shane Amante wrote:
> Pekka,
>
> This topic has come up in the past -- the last time I recall it being 
> a significant issue was IETF 63 in Paris, France.  On multiple 
> occasions since then we have asked for volunteers with IPv6 expertise 
> to help complete the IPv6 bits of this I-D.  Unfortunately, we have 
> gotten little to no response.   Do you wish to help out with this?  
> Or, can you provide a pointer to folks in the IPv6 world that can take 
> a look at this doc and help out?
>
> Thanks,
>
> -shane
>
>
> Pekka Savola wrote:

---

From: Keith Moore <[email-masked]>
Date: Fri, 18 Aug 2006 01:15:42 -0400

[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

---

From: JFC Morfin <[email-masked]>
Date: Fri, 18 Aug 2006 10:41:32 +0200

Dear Keith,
thank your for this mail. I experienced the same problem as your TCP 
and IPv4/IPv6 example with linguistic issues and globalization 
upgrading to multilingualisation. BCP 47 should not be 
internationalization only. Except that in my case the non informed 
lobby is attempting market dominance, what is not the case for IPv4.

 From these examples I would add three remarks:

- it is not that easy to teach something you are yourself working on 
and when opposed for non technical reasons. We identified that the 
proposed IETF position was hurting the architectural principles we 
worked on for the users. This was not really important had it be a 
quickly forgotten RFC. Howerver, the IANA (and the IANA's future) was 
involved and that would badly teach the market. The lesson is that we 
should make a difference between documents for information, for 
standardisation, and for registration by the IANA (affecting 
technologies options for a long time - in this case still much more 
than the DNS or IPv6).

- overall consistency is not easy to reach in the way the IETF works, 
without a networking generalised model (such as the one I use for a 
long) with a maintained structured documentation along that model. 
For example, in your IPv6 area I spent days two years ago summarising 
the issue for the IPv6 TF for the reasons you quote, having experts 
reviewing it. I kept the feeling it was outdated when published, and 
that IPv6 was something confuse, changing, and bottom-up from a very 
limited set of non authoritative and sometimes conflicting visions. I 
am sure it is possible to say the same thing in a compact, crystal 
clear, and authoritative updated document (showing many not explored 
possibilities). At this stage I found no one having a full command of 
the whole IETF doctrine. When I read IAB texts on languages and 
multuilingualisation, I feel exactly the same way as you feel about 
IPv6 and some WGs.

- there is obviously an ethical issue in the way WGs work. If 
invention is involved it must start from an open minded clean sheet 
study of the issue. Not from the pre-position of some members. Also, 
BCP should be based upon a review of all the existing real practices or works.

I hoped the IAB mailing list on possible future architectures would 
permit to make some progress into the direction of a networking 
generalised model, in order to investigate further on the evolution 
of each of its components. This has not happened. IMHO, this shows 
the problem is with the IAB and the way the Charters are reviewed and 
respected. As long as the IESG does not ask first "does that I-D 
fulfils the intents of the WG-Charter" and the WG do not propose 
Charter changes when they feel necessary, we will have that kind of 
technical culture and overall consistency problem.

jfc

At 07:15 18/08/2006, Keith Moore wrote:
>>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.
>
>statement about IETF and the qualifications to do engineering in this space.
>
>principal participants in one of my working groups really didn't 
>know what IP was and only had the vaguest understanding of TCP.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 17 Aug 2006 11:15:35 -0400

Correct.

One addition: Giles Heron from Tellabs
is already working on IPv6 part of this draft.

/himanshu

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]]
> Sent: Thursday, August 17, 2006 9:29 AM
> To: Pekka Savola
> Cc: [email-masked]; [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 18 Aug 2006 13:37:33 -0400

> Despite its completeness in terms of different (IPv4) address resolution
> protocols, the primary purpose of the ARP mediation draft is to enable
> migration from frame relay to ethernet, specifically for customers with
> IP traffic.

IP traffic is not limited to IPv4.

> The engineering decision here is to determine if we are going to make
> this draft more complete for the future (IPv6) or not.  That wasn't a
> pressing stated need at the time of the creation of the work.

That would appear to indicate a flaw in the process you used.   

If the technology you are developing is inherently one that only needs
to be used only in legacy situations (e.g. use of ARP for election of v4
linklocal address, when v6 already has linklocal addresses), or one
that should never be used except in legacy situations (e.g. NAT as a
workaround for v4 address space shortages), then it makes sense to only
consider v4.  

Or if you're only trying to document a deployed protocol for a very
rare occasion where someone needs to implement it to talk to legacy
devices, or for purely academic purposes, then you should document the
actual use of  the protocol and refrain from trying to define how it
should work.  In such cases it would be silly to document use of the
protocol on IPv6 if it was never actually used with IPv6.

But if you're trying to standardize a protocol that tends to imply that
you believe it will be useful in the future.  And unless you believe
that the protocol has a very limited future, or unless the facility you
are trying to build is inherently IPv4-specific, it's hard to justify
limiting the protocol to IPv4.  

Offhand I don't see anything IPv4-specific about bridiging between two
dissimilar link layers.  On the contrary, it seems to me that the use of
the technology you are defining by an IPv4 network would be an 
impediment to allowing that network to support IPv6.  I think this is
called "built-in obsolescence" as well as a "known technical omission".

> If there
> is even a small handful of people who say that IPv6 is required, we'll
> do it. 

I think you have it backwards.  The burden should be on the WG to
explain why IPv6 support should not be a "MUST implement" part of the
technology.  Of course, if the WG can come up with a defensible reason
to not require IPv6, IESG should consider that reason.  But "we didn't
want to work that hard" is not a defensible reason.

> Since you aren't part of that history, it is easy for you to say you
> want an "IPv6 inside" label on everything.  Unfortunately, that's what
> the IPv6 line of thinking has been reduced to: if you mandate (from the
> IESG, no less), that IPv6 be forced into every IETF activity, then we
> will finally have IPv6.

IETF develops protocols that run on the Internet.  IPv6 is the
community consensus and industry accepted direction for the Internet to
overcome the address space limtiations of IPv4.  It's ridiculous to
expect IETF to standardize a new link layer technology that doesn't
support IPv6.  At best, it's out of scope for IETF to do so; at worst,
it's expecting IETF to favor one working group's whims over a community
consensus that took many years to forge.

> We'll have IPX tunneled over IPv6, we'll have
> SNA 3270 not just over IPv4, but also over IPv6, we'll have ... 

Not necessarily, because IETF doesn't burden itself with taking on
useless work. (well, not as a matter of institutional scope anyway...)
But if there's a need to define a standard for tunneling (say) IPX over
IPv4, there's probably a need to define a standard for tunneling it
over IPv6 also.

> 
> I know Mark is going to intervene at this point ... :-)
> 
> Going back to another point of yours, I find it deplorable (especially
> given the amount of MPLS deployed and to be deployed) how little other
> working groups know about MPLS.  

If MPLS touched every host and application in the Internet, I'd agree
with you.  Of course the reason we have separation of function between
protocols and layers is so that everyone doesn't have to concern
himself with every protocol used in the Internet.  But IP is the common
protocol - the thing that all Internet hosts, routers, apps, and
intermediaries have in common.  It's the waist of the hourglass, part
of the fundamental core.  So the comparison with MPLS is bogus.

And I would submit to you that your goal in defining L2VPN is to create
a technology that people - other than its implementors and the network
admins whose networks use it directly -  _don't_ have to be concerned
with.  Which implies that it needs to work as transparently as possible
and that it should not be a barrier to those networks supporting IPv6.

Keith