Subject: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

From: Eric Gray <[email-masked]>
Date: Tue, 8 Oct 2013 14:37:52 +0000

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

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 8 Oct 2013 16:07:23 +0000

I agree with Eric's point of view and against adoption of this draft for the same reasons Eric stated below.

Do not support adoption of this draft.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, October 08, 2013 7:38 AM
To: [email-masked]
Subject: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High

mailing list.

to be pursued.

proposal.

and

--

Eric Gray

---

From: Zhenghewen <[email-masked]>
Date: Wed, 9 Oct 2013 09:58:12 +0800

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-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, October 08, 2013 10:38 PM
To: [email-masked]
Subject: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High

 

 

 

--
Eric Gray

---

From: Zhenghewen <[email-masked]>
Date: Fri, 11 Oct 2013 11:25:19 +0800

Hi, Eric,

                I have the same understanding with you about the behaviour of SARP, but I do not think that it is NAT, I think that it is more similar to Gateway.

                Let’s reuse your figure,

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

      [MAC-S] ------(?) (MAC-W)------(MAC-E) (?)------[MAC-D]

                         S-A                             S-B                           S-C

                Now, let’s assume that T-W is the gateway for ES-1 and T-E is the gateway for ES-2,

For traffic going West-to-East:

In the ARP model, T-W responds to an ARP request from ES-1 for IP-D with MAC-W.

In traditional IP routing model: 

o             ES-1 sends a frame with (D-MAC=MAC-W, S-MAC=MAC-S) to T-W;

o             T-W translate S-MAC=MAC-S to S-MAC=MAC-W,  translate D-MAC=MAC-W to D-MAC=MAC-E, and forwards the frame (otherwise as is) to T-E 

o             T-E translates D-MAC=MAC-E to D-MAC=MAC-D according to IP-D, and forwards the frame to  ES-2.

Now, do we think that the gateway T-W and T-E also provide MAC-NAT function?

I think that SARP use some mechanism like MAC-Gateway to hide hosts’ MAC address from outer data centers. It does not purely work via simple address mapping (for example, IP NAT or PNAT), it works with help IP-MAC host-route like the IP gateway, so I think it is not MAC-NAT.

Hewen

(In the first try to response your mail, the response is blocked by the IETF mail system because "Message body is too big: 52215 bytes with a limit of 40 KB ", so I have to retry after deleting some previous info; If IETF mail system finally let the first response go, please ignore it, sorry the duplicated mail)

From: Eric Gray [mailto:[email-masked]] 
Sent: Friday, October 11, 2013 12:26 AM
To: Zhenghewen; [email-masked]
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

Hewen,

                Please.  I did not object to this without having read the draft.  According to

what I read, this is not only MAC-NAT, but it is messy MAC-NAT.

                At the 50,000 foot level, the proposal uses a "proxy" that returns a different 

MAC address than that corresponding to the IP address of the destination.  The proxy

then replaces the destination MAC address (D-MAC) of Ethernet frames in transit with 

the MAC address that corresponds to the IP destination.  

                This D-MAC replacement is half of a MAC translation (or, as many folks would 

know it, MAC-NAT).  It is only "half" of a translation, because the current draft only 

requires translation of the D-MAC, leaving the source MAC address (S-MAC) as is – at 

least optionally, and at this proxy.

                Going down to the 10,000 foot level, the proposal attempts to mimic scaling

advantages of using a hierarchical backbone – using a flat (non-hierarchical) network

approach – based on an interesting (read complicated) asymmetrically-symmetric

form of MAC-NAT where an exchange between two IP destinations is forwarded

across the flat-backbone using two separate proxies where D-MAC replacement

(AKA – translation) takes place in each direction as the frame leaves the backbone

(i.e. – the D-MAC in each direction is translated by the remote proxy on the other

side of the mocked-up backbone).

                The same proxy (now on the near-side of the mocked up backbone) MAY 

(optionally in the current draft) translate the S-MAC of returning frames.  If this is

done, and the far-side proxy then translates the D-MAC of the same frame, you

have completed a full MAC-NAT at two separate locations in the network.

                If S-MAC translation is not done, there is a significant potential for causing

confusion to L2 networking components that learn forwarding information from

the S-MAC of in-transit frames, and host (or virtual machines) that learn ARP-cache 

information.  The draft assumes that this can be worked around by turning learning 

capabilities off – but this may not be possible.

                The details of the idea (as I understand them) can be pictorially represented 

as follows:

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

      [MAC-S] ------(?) (MAC-W)------(MAC-E) (?)------[MAC-D]

                         S-A                             S-B                           S-C

Where:

                (ES-1, ES-2) = End-Station (1, 2) 

                MAC-S is the MAC address of ES-1, the source of a subsequent frame to ES-2

                IP-S is the IP(v4/v6) address of ES-1

                MAC-D is the MAC address of ES-2, the destination for the above frame

                IP-D is the IP(v4/v6) address of ES-2

                (S-A, S-B, S-C) = Segments (A, B, C)

                MAC-W is the MAC address of T-W that is visible on S-B (the draft does not

                                say whether or not T-W has a different MAC address associated with

                                its interface onto S-A)

                MAC-E is the MAC address of T-E that is visible on S-B (the draft does not

                                say whether or not T-E has a different MAC address associated with

                                its interface onto S-C)

For traffic going West-to-East:

In the ARP model, T-W responds to an ARP request from ES-1 for IP-D with MAC-E

(which then becomes visible on S-A).

In the translation model: 

o             ES-1 sends a frame with (D-MAC=MAC-E, S-MAC=MAC-S);

o             T-W MAY translate S-MAC=MAC-S to S-MAC=MAC-W, if bridge-learning is used

                on S-B, and forwards the frame (otherwise as is) to T-E 

                (note that this is what it says, but IMO the S-MAC translation MUST occur);

o             T-W translates D-MAC=MAC-E to D-MAC=MAC-D, and forwards the frame to

                ES-2 (note that – at this point the frame MUST have S-MAC=MAC-W or ES-2 will

                replace the earlier ARP cache entry with one associating MAC-S with IP-S – and 

                this is not what the draft currently says [so it is essentially broken]).

The last step above requires looking further into the frame to peek at destination IP 

address IP-D, and then looking MAC-D up in its local (S-C) ARP cache.  

For traffic going East-to-West, behavior is analogous but reversed.

So, the draft does propose MAC-NAT – either partial, or complete (with partial being

worse than complete).

--

Eric

---

From: Zhenghewen <[email-masked]>
Date: Fri, 11 Oct 2013 13:45:18 +0800

Hi, Xiaohu,

               I just show how IP Gateway works, not show how SARP works. Eric already shows how SARP works, I do not want to repeat. You misunderstand my meanings, I just want to show how similar between IP Gateway and SARP.

                Please go through the thread. (I have to cut the previous mails because the mail size limitations from IETF)

Hewen

From: Xuxiaohu [mailto:[email-masked]] 
Sent: Friday, October 11, 2013 1:11 PM
To: Zhenghewen; 'Eric Gray'; [email-masked]
Subject: 答复: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

发件人: [email-masked] [mailto:[email-masked]] 代表 Zhenghewen
发送时间: 2013年10月11日 11:25
收件人: 'Eric Gray'; [email-masked]
主题: Re: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

Hi, Eric,

                Let’s reuse your figure,

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

                         S-A                             S-B                           S-C

[Xiaohu] I think you misunderstand the concept of SARP. ES-1 is expected to receive an ARP reply containing a mapping from IP-D to MAC-E, rather than a mapping from IP-D to MAC-W. Therefore, the following illustration is also wrong. 

Xiaohu

Hewen

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Oct 2013 07:19:12 +0000

Hi Hewen,

Sorry that I haven’t read the emails of this thread one by one.  As you said “T-W translate S-MAC=MAC-S to S-MAC=MAC-W,..” in your email, I had thought you were still talking about SARP or MAC-NAT because gateway routers don’t perform any MAC translation action at all, instead, they remove the old MAC header, then perform IP lookup and then add a new MAC header. In other words, there is no mapping or translation relationship between the old MACs and the new MACs. One big different between gateway router and MAC-NAT is the former performs IP routing table lookup while the latter performs MAC table lookup plus MAC rewriting (also called MAC NAT) for packet forwarding decision.

Best regards,
Xiaohu

发件人: Zhenghewen
发送时间: 2013年10月11日 13:45
收件人: Xuxiaohu; 'Eric Gray'; [email-masked]<mailto:[email-masked]>
主题: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

Hi, Xiaohu,

Hewen

From: Xuxiaohu [mailto:[email-masked]]
Sent: Friday, October 11, 2013 1:11 PM
To: Zhenghewen; 'Eric Gray'; [email-masked]<mailto:[email-masked]>
Subject: 答复: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Zhenghewen
发送时间: 2013年10月11日 11:25
收件人: 'Eric Gray'; [email-masked]<mailto:[email-masked]>
主题: Re: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

Hi, Eric,

        IP-S                                                                                         IP-D
        ES-1                        T-W                            T-E                      ES-2

Xiaohu

Hewen

From: Eric Gray [mailto:[email-masked]]
Sent: Friday, October 11, 2013 12:26 AM
To: Zhenghewen; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

---

From: Eric Gray <[email-masked]>
Date: Thu, 10 Oct 2013 16:25:30 +0000

Hewen,

        IP-S                                                                                         IP-D
        ES-1                        T-W                            T-E                      ES-2

Where:

--
Eric

From: Zhenghewen [mailto:[email-masked]]
Sent: Tuesday, October 08, 2013 9:58 PM
To: Eric Gray; [email-masked]
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High

Hi Eric,

Hewen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, October 08, 2013 10:38 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High

mailing list.

to be pursued.

proposal.

and

--

Eric Gray

---

From: Zhenghewen <[email-masked]>
Date: Fri, 11 Oct 2013 11:11:44 +0800

Hi, Eric,

                Let’s reuse your figure,

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

                         S-A                             S-B                           S-C

Hewen

Hewen,

as follows:

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

                         S-A                             S-B                           S-C

Where:

                                its interface onto S-A)

                                its interface onto S-C)

worse than complete).

--

Eric

Hi Eric,

Hewen

 

 

 

--
Eric Gray

---

From: Zhenghewen <[email-masked]>
Date: Fri, 11 Oct 2013 13:40:34 +0800

Hi, Xiaohu,

Hewen

 

Hi, Eric,

                Let’s reuse your figure,

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

                         S-A                             S-B                           S-C

Xiaohu

Hewen

 

Hewen,

as follows:

        IP-S                                                                                         IP-D

        ES-1                        T-W                            T-E                      ES-2

                         S-A                             S-B                           S-C

Where:

                                its interface onto S-A)

                                its interface onto S-C)

worse than complete).

--

Eric

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Oct 2013 13:25:11 +0000

Trying again with a "clipped tail" hopefully short enough to avoid the list
filter…

From: Eric Gray
Sent: Friday, October 11, 2013 9:21 AM
To: 'Zhenghewen'; [email-masked]
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

Hewen,

                The comparison to routing breaks down because – with routing –
MAC-S and MAC-W' (we need to add a – supposedly different – MAC for
the west side of T-W and the east side of T-E if we're discussing routing –
see the modified figure in your response below), are the only MAC
addresses that appear on S-A (in an IP-level exchange between IP-S and
IP-D).

                In this case, both ES-1 and T-W are Ethernet end-stations on S-A.
Hence this case is completely compatible with IEEE 802 architecture, and
no translation takes place.

                For case of the proposal, MAC-S and MAC-E appear on both S-A
and S-B, assuming T-E does a "symmetric" MAC "replacement" (to avoid
the term "translation" for a moment) – MAC-E <----> MAC-D.  If the S-MAC
on frames from MAC-D to MAC-S are not replaced (MAC-D --> MAC-E),
then MAC-D also appears on at least S-B (and probably S-A as well), with
both MAC-S, and MAC-E.

                Already we have one extra MAC address visible on at least S-B
(we have 3 instead of the original MAC-S and MAC-D).

                The same happens in the opposite direction.  This means yet
another extra MAC address (this time visible on at least S-B and very
likely on S-C as well).

                The minimal effect is that S-B "sees" MAC addresses it would
not see if T-W and T-E were either transparent bridges, or routers.  If
they were transparent bridges, only MAC-S and MAC-D would be seen
on S-A, S-B and S-C.  If they were routers, only MAC-S and MAC-W' are
visible on S-A, MAC-W and MAC-E on S-B, and MAC-E' and MAC-D on
S-C.

                This asymmetric appearance of MAC addresses (some in both
directions on some segments, some only in one direction on some
segments) breaks Ethernet Architecture, needlessly complicates host
interactions, and probably results in incompatibility with standard (IEEE
802.1Q) bridges.

                Since – in the proposal – it cannot be argued that either T-W or
T-E is an Ethernet end-station, and they each change the D-MAC (at
least) for frames going from one segment to another of the same LAN,
the "replacement" of MAC addresses is a translation.

                The proposal argues that the "extra MAC addresses" can be
ignored.  That does not mean they will be.

                So there are cases where the proposal might improve scaling,
and other cases where it definitely does not.  And cases where it has
potentially pathological impacts on Ethernet forwarding in each of the
3 segments involved in this simple example.

                And, since the two translators in this simple case are – in part
(at least) – layer two forwarding devices, the proposal cannot be
incompatible with existing (standards-based) L2 forwarding devices.

                Therefore, the proposal should not be adopted by the WG.

--
Eric

From: Zhenghewen [mailto:[email-masked]]
Sent: Thursday, October 10, 2013 11:12 PM
To: Eric Gray; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High

Hi, Eric,

        IP-S                                                                                                                      IP-D
        ES-1                                  T-W                                        T-E                             ES-2
      [MAC-S] ------(MAC-W') (MAC-W)------(MAC-E) (MAC-E')------[MAC-D]
                         S-A                             S-B                           S-C

Hewen

--- [SNIP] ---

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Oct 2013 17:16:49 +0000

Xiaohu,

                Hewen was trying to show that the behavior described in the draft is analogous
to the behavior of routing in a similar scenario.

                The analysis Hewen provided would be correct (in as far as it goes) if T-W and
T-E were routers.  Hewen's analysis is incomplete, and the analogy falls apart as a result.

                Both the picture I provided, and the analysis I included, in my earlier mail are
completely consistent with what you appear to agree the draft is saying, and Hewen
agreed about this as well.

--
Eric

From: Xuxiaohu [mailto:[email-masked]]
Sent: Friday, October 11, 2013 1:11 AM
To: Zhenghewen; Eric Gray; [email-masked]
Subject: 答复: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Importance: High

Hi, Eric,

        IP-S                                                                                         IP-D
        ES-1                        T-W                            T-E                      ES-2

Xiaohu

Hewen

Hewen,

        IP-S                                                                                         IP-D
        ES-1                        T-W                            T-E                      ES-2

Where:

--
Eric

---

From: Zhenghewen <[email-masked]>
Date: Sat, 12 Oct 2013 12:01:53 +0800

Hi, Eric,

                I agree that the proposal in the draft would introduce some change into traditional L2 switch or L3 Gateway, the change brings obvious benefits.

                As we discussed, the draft introduces some function like MAC-Gateway to separate/isolate layer 2 domain, the new function hides MAC addresses originated from local layer 2 domain as IP gateway, but it does not need to an IP address for the "gateway", an IP address for each VM as well relevant and careful plan and configurations while keeping the benefit 'a' layer 2 domain.

                I prefer to think that it acts as MAC-Gateway not MAC-NAT, it does not need complex configurations and mapping as IP NAT.

                I support the adoption because it provides a feasible and simple solution to solve MAC address scalability issue due to cloud data centre. 

Hewen

From: Eric Gray [mailto:[email-masked]] 
Sent: Friday, October 11, 2013 9:25 PM
To: Zhenghewen
Cc: [email-masked]
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp

filter…

From: Eric Gray 

Hewen,

IP-D).  

the term "translation" for a moment) – MAC-E ßà MAC-D.  If the S-MAC

on frames from MAC-D to MAC-S are not replaced (MAC-D à MAC-E),

both MAC-S, and MAC-E.

likely on S-C as well).

S-C.

802.1Q) bridges.

--

Eric

--- [SNIP] ---