Hi Eric,
I think that essentially the draft provides a method as MAC
hiding used in L2VPN, it is feasible and harmless. IMHO, it is not about MAC
NAT in my understanding.
Hewen
From: [email protected] [mailto:[email protected]] On Behalf Of
Eric Gray
Sent: Tuesday, October 08, 2013 10:38 PM
To: [email protected]
Subject: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High
I tried sending this mail earlier, but do not see it in the mail archive a day
later. So, I am
sending it again. Apologies if anyone receives this message twice.
I do not support adoption of this draft.
There are a number of technical issues with the proposals in this draft,
however the biggest reason why this work should not be adopted by the
Int-Area WG (or any WG in the IETF) is that it proposes fundamental
changes to forwarding in Ethernet, hence it is likely to impact Ethernet
Architecture and - if it were to be undertaken at all - should be undertaken
by folks in the organization with the most knowledge about Ethernet
Architecture - i.e. - IEEE 802.
The fact is that MAC NAT is viewed by many (if not most) of the experts,
in the topic area, as a hideously bad idea that they have no wish to work
on, is not justification to bring this work to an IETF working group.
The issue with impact on Ethernet Architecture is neither presumed, nor
theoretical. A number of related issues have already been raised on the
mailing list.
Among these are issues with compatibility with Ethernet measurement
and monitoring, dependence in the forwarding plane of a specific IPv(4/6)
address associated with a destination MAC address, and a few subtle
variations on these issues.
Doubtless many others would be discovered over time if this work were
to be pursued.
Hence a discussion about ways to fix these problems as they come up is
based on an assumption that there MUST be some extreme value to be
realized in the long term that justifies creation of an arbitrary number of
hacks to "fix" each new issue as it is discovered.
As has already been said in recent discussion, there is no obvious value in
the proposed approach - particularly in view of existing solutions that do
not have compatibility issues - that would begin to justify pursuing this
proposal.
Given this, is there any reasonable justification for trying to identify
and
address the technical issues with this proposal, until we have objective
evidence that the proposal addresses a real problem for which there is
not already an existing solution?
--
Eric Gray
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
