Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-07.txt

From: [email-masked]
Date: Wed, 16 Aug 2006 15:50:02 -0400

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-l2vpn-arp-mediation-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-l2vpn-arp-mediation-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

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

> 	Filename	: draft-ietf-l2vpn-arp-mediation-07.txt
...
> a routing protocol between them, as long as the routing protocol

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

---

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:
> 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: "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]
> Subject: Re: L2VPNs must not be IP(v4)-only
> 
> 
> Pekka,
>

---

From: Shane Amante <[email-masked]>
Date: Thu, 17 Aug 2006 17:14:03 -0600

Keith,

On Aug 17, 2006, at 9:27 AM, Keith Moore wrote:
> 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.

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.

-shane

> Keith

---

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 ]

> 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 fireFrom [email-masked] Fri Aug 18 11:09:04 2006
Date: Fri, 18 Aug 2006 01:15:42 -0400
From: Keith Moore <[email-masked]>
To: Shane Amante <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: 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 ]

> 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 walls (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: 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:
>>> This dleast a rudimentary understanding of most of 

Keith

---

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

Hi.

Regards,
Elwyn

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

raft is a work item of the Layer 2 Virtual Private Networks 
>>> Working Group of the IETF.
>>>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>

---

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

group that's not willing to learn about IPv6.  IPv6 is not a specialized

Keith

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 18 Aug 2006 08:55:01 -0700

Keith,

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.

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.  If there
is even a small handful of people who say that IPv6 is required, we'll
do it.  That was what happened at the last IETF.  Everyone's got enough
work to do to not have to chase down unnecessary extensions that will
take time to get right, but that will NEVER get deployed.

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.  We'll have IPX tunneled over IPv6, we'll have
SNA 3270 not just over IPv4, but also over IPv6, we'll have ...  If we
build it, they will come.

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.  It clearly rivals IPv6, at least in
terms of spread.  It is a fundamental building block in every major
carrier, yadda yadda, ...

Face it, there are too many protocols, and the world is getting more
specialized.  You keep up with your primary areas, and you have a
smattering (not an engineering understanding) of lots of other things.
I will now return to reading "IPv6 for dummies."  And I will not fault
you if you don't know whether you want to use the Sender Template method
for one-to-one detours or not.

-Vach