Subject: Re: New Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt

From: <[email-masked]>
Date: Mon, 2 Dec 2013 10:54:37 +0000

Hi everyone,

Please try to keep your email Subject line tidy enough !

(You could even go as far as selecting a useful topic line)

Thank you.

-Thomas, as WG co-chair

2013-11-29, Henderickx, Wim (Wim):
> You violate basic forwarding mechanisms: don’t decrement TTL for
> intra-subnet traffic and this is not in-line with NVO3 requirements.
> Discussion closed for me.
>
> On 29/11/13 10:03, "Xuxiaohu" <[email-masked]> wrote:
>
>>
>>
>>> -----邮件原件-----
>>> 发件人: Henderickx, Wim (Wim) [mailto:[email-masked]]
>>> 发送时间: 2013年11月29日 15:55
>>> 收件人: Xuxiaohu; [email-masked]
>>> 抄送: [email-masked]
>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复:
>>> New Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt
>>>
>>>
>>>
>>> On 29/11/13 07:56, "Xuxiaohu" <[email-masked]> wrote:
>>>
>>>>
>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: Henderickx, Wim (Wim)
>>> [mailto:[email-masked]]
>>>>> 发送时间: 2013年11月29日 12:59
>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>> 抄送: [email-masked]
>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New
>>> Version Notification
>>>>> for draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>
>>>>> I believe we have a disagreement here. The trace route is not
>>>>> providing the  output expected. If you define a solution you need to
>>>>> ensure the applications  behave in the way IP was designed and as such
>>>>> your solution is not compliant to  this.
>>>>
>>>> I have to emphasize that it's absolutely the expected output in the
>>>> case where the Proxy ARP [RFC1027] is deployed. Unless you are strongly
>>>> against the Proxy ARP technology itself which was actually designed at
>>>> most the same time when IP was initially designed...
>>> WH> I am not against this, but there are other ways of implementing it
>>> WH> as
>>> I mentioned it before and these solution do not have the issues which I
>>> outlined.
>>
>> But these solutions may have issues that you haven't outlined:) Different
>> approaches have their different target scenarios. That's the reason why
>> both Layer2 and Layer3 overlays are considered by the NVo3 WG.
>>
>>>>> If you like it or not, it is reality.
>>>>
>>>> No matter you like it or now, the approach of using the host routing
>>>> and the Proxy ARP to emulate an extended subnet has been increasingly
>>>> implemented by more and more vendors in their data center network
>>>> products. It's the reality.
>>> WH> this doesn’t mean that IETF need to adopt it, since it breaks a
>>> WH> number
>>> of things
>>
>> You'd better explicit list those things which would be broken. It would
>> be very helpful for the NVo3 WG.
>>
>>>> Xiaohu
>>>>
>>>>
>>>>
>>>>> On 29/11/13 02:35, "Xuxiaohu" <[email-masked]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> -----邮件原件-----
>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>> [mailto:[email-masked]]
>>>>>>> 发送时间: 2013年11月28日 18:46
>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>> 抄送: [email-masked]
>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New
>>>>> Version Notification for
>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>
>>>>>>> Please look at the VRF table instance in that example. The packet
>>>>>>> destined for  2.2.2.x is forwarded according to the default route
>>>>>>> advertised by PE-3.
>>>>>>>
>>>>>>> Since each PE acts as a default GW, there is no impact to the
>>>>>>> output of the trace  route for an IP address which is not within
>>>>>>> the same subnet as the trace-route  originator (IMO, this is the
>>>>>>> major usage of trace route).
>>>>>>> If you just want to try a trace route for an IP address which is
>>>>>>> within the same  subnet of the trace-route originator, there are
>>>>>>> just two more hops (i.e., ingress  PE and egress PE) in the output
>>>>>>> (see below), does it matter in practice?
>>>>>>>
>>>>>>> <Host_1>tracert 1.1.1.5
>>>>>>> traceroute to  1.1.1.5(1.1.1.5), max hops: 30 ,packet length:
>>>>>>> 40,press CTRL_C t  o break
>>>>>>> 1 1.1.1.1 40 ms  40 ms  50 ms
>>>>>>> 2 1.1.1.1 120 ms  80 ms  110 ms
>>>>>>> 3 1.1.1.5 140 ms  100 ms  90 ms
>>>>>>> <Host_1>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> WH> and this is what I meant with broken since the trace route is
>>>>>>> expecting 1 hop iso 3.
>>>>>>
>>>>>> It's no more a surprise once you have understood that the
>>>>>> intra-subnet traffic is forwarded at L3.
>>>>>>
>>>>>> As I have said before, there is no impact on the normal trace route
>>>>>> function. By the way, are you usually using the trace route command
>>>>>> rather than the PING command on one host to check the connectivity
>>>>>> to another host when these two hosts are actually within the same
>>> subnet?
>>>>>>
>>>>>>
>>>>>>> On 28/11/13 09:45, "Xuxiaohu" <[email-masked]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----邮件原件-----
>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>> [mailto:[email-masked]]
>>>>>>>>> 发送时间: 2013年11月28日 15:44
>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>> 抄送: [email-masked]
>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New Version
>>>>>>> Notification for
>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28/11/13 08:33, "Xuxiaohu" <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>> 发送时间: 2013年11月28日 14:13
>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>> 抄送: [email-masked]
>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: New Version
>>>>>>> Notification
>>>>>>>>> for
>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28/11/13 04:02, "Xuxiaohu" <[email-masked]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>> 发送时间: 2013年11月28日 1:53
>>>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>>>> 抄送: [email-masked]
>>>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: New Version
>>>>> Notification
>>>>>>> for
>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 27/11/13 09:12, "Xuxiaohu" <[email-masked]>
>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>>>> 发送时间: 2013年11月27日 14:14
>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>>>>>> 抄送: [email-masked]
>>>>>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: New Version
>>> Notification
>>>>> for
>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are changing the forwarding plane of a L3 service
>>>>>>>>>>>>>>> and as such this is not  implementable in merchant
>>>>>>>>>>>>>>> silicon so
>>>>> far.
>>>>>>>>>>>>>>> You need a flexible network processor  to do this and I
>>>>>>>>>>>>>>> am not sure about the performance implications.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Future merchant silicon could be adapted to support such
>>>>>>>>>>>>>> TTL handling requirement as long as Layer3 forwarding
>>>>>>>>>>>>>> for intra-subnet traffic is worthwhile in practice. In
>>>>>>>>>>>>>> addition, even with the existing L3 forwarding chips
>>>>>>>>>>>>>> which don't support that TTL handling requirement, the
>>>>>>>>>>>>>> Layer3 overlay could still be applicable to most
>>>>>>>>>>>>>> applications except a few ones where TTL is set to 1.
>>>>>>>>>>>>> WH> even with what you say you break basic applications
>>>>>>>>>>>>> WH> like trace route,
>>>>>>>>>>>>
>>>>>>>>>>>> No, it will not break the trace-route application. It has
>>>>>>>>>>>> been successfully verified in our implementation.
>>>>>>>>>>> WH> can you show an output. W/o the TTL handling your hops
>>>>>>>>>>> WH> will be
>>>>>>>>>>> incorrect
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In the example illustrated at Figure 4 of the draft, the trace
>>>>>>>>>> route output on Host A is as follows (note that 2.2.2.1 is a
>>>>>>>>>> vrf interface address of PE-3):
>>>>>>>>>>
>>>>>>>>>> [Host_1]tracert 2.2.2.1
>>>>>>>>>> traceroute to  2.2.2.1(2.2.2.1), max hops: 30 ,packet length:
>>>>>>>>>> 40,press CTRL_C t o break
>>>>>>>>>> 1 1.1.1.1 60 ms  50 ms  50 ms
>>>>>>>>>> 2 2.2.2.1 90 ms  60 ms  80 ms
>>>>>>>>>
>>>>>>>>> WH> figure 4 is addressing 1.1.1.x not 2.2.2.x and the output
>>>>>>>>> WH> should be
>>>>>>>>> from a intra-subnet
>>>>>>>>
>>>>>>>> Please look at the VRF table instance in that example. The packet
>>>>>>>> destined for 2.2.2.x is forwarded according to the default route
>>>>>>>> advertised by PE-3.
>>>>>>>>
>>>>>>>> Since each PE acts as a default GW, there is no impact to the
>>>>>>>> output of the trace route for an IP address which is not within
>>>>>>>> the same subnet as the trace-route originator (IMO, this is the
>>>>>>>> major usage of trace
>>>>>>> route).
>>>>>>>> If you just want to try a trace route for an IP address which is
>>>>>>>> within the same subnet of the trace-route originator, there are
>>>>>>>> just two more hops (i.e., ingress PE and egress PE) in the output
>>>>>>>> (see below), does it matter in practice?
>>>>>>>>
>>>>>>>> <Host_1>tracert 1.1.1.5
>>>>>>>> traceroute to  1.1.1.5(1.1.1.5), max hops: 30 ,packet length:
>>>>>>>> 40,press CTRL_C t o break
>>>>>>>> 1 1.1.1.1 40 ms  40 ms  50 ms
>>>>>>>> 2 1.1.1.1 120 ms  80 ms  110 ms
>>>>>>>> 3 1.1.1.5 140 ms  100 ms  90 ms
>>>>>>>> <Host_1>
>>>>>>>>
>>>>>>>>>>>>> etc. SO I don’t want to adopt it at all with such impact
>>>>>>>>>>>>> on the
>>>>>>>>> DP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So why I am against this draft is because it has a big
>>>>>>>>>>>>>>> impact on the data-plane.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does EVPN have no impact on the data-plane? Are you
>>>>>>>>>>>>>> against that draft as well due to its impact on the
>>> data plane?
>>>>>>>>>>>>> WH> not in its basic form
>>>>>>>>>>>>
>>>>>>>>>>>> However, the major selling-point of that technology (i.e.,
>>>>>>>>>>>> active-active
>>>>>>>>>>>> multi-homing) is lost in its basic form accordingly.
>>>>>>>>>>> WH> no its not
>>>>>>>>>>
>>>>>>>>>> If no change to the existing data plane, how to realize the
>>>>>>>>>> following split-horizon function?
>>>>>>>>>>
>>>>>>>>>> 9.3 Split Horizon
>>>>>>>>>>
>>>>>>>>>>    Consider a CE that is multi-homed to two or more PEs on an
>>>>>>> Ethernet
>>>>>>>>>>    segment ES1 operating in All-Active mode. If the CE sends a
>>>>>>>>>>    broadcast, unknown unicast, or multicast (BUM) packet to
>>>>>>>>>> one of
>>>>>>> the
>>>>>>>>>>    non-DF (Designated Forwarder) PEs, say PE1, then PE1 will
>>>>> forward
>>>>>>>>>>    that packet to all or subset of the other PEs in that EVPN
>>>>>>> instance
>>>>>>>>>>    including the DF PE for that Ethernet segment. In this case
>>>>>>>>>> the DF
>>>>>>>>> PE
>>>>>>>>>>    that the CE is multi-homed to MUST drop the packet and not
>>>>>>> forward
>>>>>>>>>>    back to the CE. This filtering is referred to as "split
>>>>> horizon"
>>>>>>>>>>    filtering in this document.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sajassi, et al.         Expires January 15, 2014
>>>>> [Page
>>>>>>>>> 17]
>>>>>>>>>>
>>>>>>>>>> INTERNET DRAFT        BGP MPLS Based Ethernet VPN
>>> July
>>>>>>> 15,
>>>>>>>>> 2013
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    In order to achieve this split horizon function, every BUM
>>>>> packet
>>>>>>>>>>    originating from a non-DF PE is encapsulated with an MPLS
>>>>>>>>>> label
>>>>>>> that
>>>>>>>>>>    identifies the Ethernet segment of origin (i.e. the segment
>>>>> from
>>>>>>>>>>    which the frame entered the EVPN network). This label is
>>>>>>> referred to
>>>>>>>>>>    as the ESI label, and MUST be distributed by all PEs when
>>>>>>> operating
>>>>>>>>>>    in All-Active multi-homing mode using the "Ethernet A-D
>>>>>>>>>> route per
>>>>>>>>>
>>>>>>>>> WH> when you use virtual chassis all works naturally and split
>>>>>>>>> WH> horizon is
>>>>>>>>> handled by the VC.
>>>>>>>>>>>>>>> The fundamental difference between the proposals is
>>>>>>>>>>>>>>> that you have on egress a  mapping in the label that
>>>>>>>>>>>>>>> determines the forwarding behaviour to be applied,
>>>>>>>>>>>>>>> rather than having to check src/dst IP matches + LPM
>>> lookups.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you still talking about L3 overlay service for
>>>>>>>>>>>>>> intra-subnet
>>>>>>>>>>>>> traffic?
>>>>>>>>>>>>> WH> I am talking about this draft
>>>>>>>>>>>>
>>>>>>>>>>>> If you are talking about the Virtual Subnet draft, then
>>>>>>>>>>>> your above argument is incorrect. The egress PE would
>>>>>>>>>>>> perform IP lookup in the corresponding VRF table.
>>>>>>>>>>> WH> I am talking about the fact when proper TTL handling has
>>>>>>>>>>> WH> to be
>>>>>>>>>>> applied, you need to determine whether or not to decrement
>>>>>>>>>>> the TTL and as  such you end up doing additional lookups to
>>>>> determine
>>>>> this.
>>>>>>>>>>> As such you will  impact performance.
>>>>>>>>>>
>>>>>>>>>> Have you seen performance degradation on your routers once an
>>>>>>>>>> ACL entry or uRPF check is enabled on interfaces?
>>>>>>>>>
>>>>>>>>> WH> urpf/ACL are handled naturally, but you create a new
>>>>>>>>> WH> pipeline and look
>>>>>>>>> at the operations you have to do to check the
>>>>>>>>> intra/inter-subnet forwarding.
>>>>>>>>> This is whats avoids to use merchant silicon and what impact
>>>>>>>>> performance.
>>>>>>>>>>
>>>>>>>>>> Xiaohu
>>>>>>>>>>
>>>>>>>>>>>> Xiaohu
>>>>>>>>>>>>
>>>>>>>>>>>>>> Xiaohu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 27/11/13 02:31, "Xuxiaohu" <[email-masked]>
>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Fine. In my draft, both intra-subnet and inter-subnet
>>>>>>>>>>>>>>>> IP traffic are forwarded at layer3 while in the draft
>>>>>>>>>>>>>>>> you mentioned below only inter-subnet traffic would
>>>>>>>>>>>>>>>> be forwarded at layer3. They are totally different
>>>>>>>>>>>>>>>> approaches and therefore it's meaningless to say
>>>>>>>>>>>>>>>> which one is easier
>>>>>>> or not.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Xiaohu
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 19:16
>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>>>>>>>> 抄送: [email-masked]
>>>>>>>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: New Version Notification for
>>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Lets debate the technical solutions iso blogs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 25/11/13 08:52, "Xuxiaohu" <[email-masked]>
>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I suggest you read the following blog post by
>>>>>>>>>>>>>>>>>> Yakov
>>>>>>>>>>>>>>>>>
>>>>>>>> (http://opencontrail.org/why-contrail-is-using-bgpmpls/).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 15:27
>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>>>>>>>>>> 抄送: [email-masked]
>>>>>>>>>>>>>>>>>>> 主题: Re: 答复: 答复: New Version Notification for
>>>>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There are easier ways to do this which don’t
>>>>>>>>>>>>>>>>>>> required data-plane changes.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-sajassi-l2vpn-e
>>>>>>>>>>>>>>>>>>> vpn
>>>>>>>>>>>>>>>>>>> -in
>>>>>>>>>>>>>>>>>>> ter
>>>>>>>>>>>>>>>>>>> -su
>>>>>>>>>>>>>>>>>>> bne
>>>>>>>>>>>>>>>>>>> t-f
>>>>>>>>>>>>>>>>>>> orw
>>>>>>>>>>>>>>>>>>> ard
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> g-02
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 25/11/13 07:40, "Xuxiaohu"
>>>>>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 14:29
>>>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>>>>>>>>>>>> 抄送:
>>>>>>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>>>>>>> 主题: Re: 答复: New Version Notification for
>>>>>>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is not about TTL 1, no TTL decrement
>>>>>>>>>>>>>>>>>>>>> should happen for intra-subnet  forwarding at
>>>>>>>>>>>>>>>>>>>>> all On top you need to modify the data-plane
>>>>>>>>>>>>>>>>>>>>> to achieve this, since it now needs to find
>>>>>>>>>>>>>>>>>>>>> out if it is intra or inter subnet where
>>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>> PE(s)  don’t have to do
>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sure, it needs some change to the
>>>>>>>>>>>>>>>>>>>> implementation of PE
>>>>>>>>>>>>> routers.
>>>>>>>>>>>>>>>>>>>> That's why we need a draft to specify the
>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 25/11/13 07:22, "Xuxiaohu"
>>>>>>>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Wim,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It said clearly "if the source and
>>>>>>>>>>>>>>>>>>>>>> destination addresses of a packet whose TTL
>>>>>>>>>>>>>>>>>>>>>> is set to 1 belong to the same extended
>>>>>>>>>>>>>>>>>>>>>> subnet, both ingress and egress PE routers
>>>>>>>>>>>>>>>>>>>>>> MUST NOT decrement the TTL of
>>>>>>> such
>>>>>>> packet."
>>>>>>>>>>>>>>>>>>>>>> Did you doubt that the PE routers could know
>>>>>>>>>>>>>>>>>>>>>> whether the source and destination address
>>>>>>>>>>>>>>>>>>>>>> belong to the same
>>>>>>>>>>>>>>>>> extended subnet?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Xiaohu
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim)
>>>>>>>>>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 14:08
>>>>>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email-masked]
>>>>>>>>>>>>>>>>>>>>>>> 抄送:
>>>>>>>>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>>>>>>>>> g
>>>>>>>>>>>>>>>>>>>>>>> 主题: Re: New Version Notification for
>>>>>>>>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On the TTL issue I believe this is not
>>>>>>>>>>>>>>>>>>>>>>> addressing the
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>> We can say don’t  decrement but when and
>>>>>>>>>>>>>>>>>>>>>>> how will the
>>>>>>>>>>>>>>>>>>>>>>> PE(s) do or
>>>>>>>>>>>>>>>>>>> don’t.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 25/11/13 03:22, "Xuxiaohu"
>>>>>>>>>>>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Major changes since the -01 version
>>> include:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 1) add a section about TTL consideration;
>>>>>>>>>>>>>>>>>>>>>>>> 2) remove the section of PE Router FIB
>>>>>>>>>>>>>>>>>>>>>>>> Reduction;
>>>>>>>>>>>>>>>>>>>>>>>> 3) remove the section of PE Router RIB
>>>>>>>>>>>>>>>>>>>>>>>> Reduction;
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Any further comments are welcome. BTW,
>>>>>>>>>>>>>>>>>>>>>>>> the removed sections as mentioned above
>>>>>>>>>>>>>>>>>>>>>>>> would be described in
>>>>>>>>>>>>> separate
>>>>>>>>>>>>> docs.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Best regards, Xiaohu
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -----邮件原件-----
>>>>>>>>>>>>>>>>>>>>>>>>> 发件人: [email-masked]
>>>>>>>>>>>>>>>>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 10:10
>>>>>>>>>>>>>>>>>>>>>>>>> 收件人: Brendan Fee; Susan Hares; Fan
>>>>>>>>>>>>>>>>>>>>>>>>> Yongbing; Xuxiaohu; Xuxiaohu; Christian
>>>>>>>>>>>>>>>>>>>>>>>>> Jacquenet; Truman Boyes; Yongbing Fan
>>>>>>>>>>>>>>>>>>>>>>>>> 主题: New Version Notification for
>>>>>>>>>>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A new version of I-D,
>>>>>>>>>>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt
>>>>>>>>>>>>>>>>>>>>>>>>> has been successfully submitted by
>>>>>>>>>>>>>>>>>>>>>>>>> Xiaohu Xu and posted to the IETF
>>> repository.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Filename:	
>>> draft-xu-l3vpn-virtual-subnet
>>>>>>>>>>>>>>>>>>>>>>>>> Revision:	 02
>>>>>>>>>>>>>>>>>>>>>>>>> Title:		 Virtual Subnet: A L3VPN-based
>>>>> Subnet
>>>>>>>>>>>>> Extension
>>>>>>>>>>>>>>>>>>> Solution
>>>>>>>>>>>>>>>>>>>>>>>>> Creation date:	 2013-11-25
>>>>>>>>>>>>>>>>>>>>>>>>> Group:		 Individual Submission
>>>>>>>>>>>>>>>>>>>>>>>>> Number of pages: 13
>>>>>>>>>>>>>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-x
>>>>>>>>>>>>>>>>>>>>>>> u-l
>>>>>>>>>>>>>>>>>>>>>>> 3vp
>>>>>>>>>>>>>>>>>>>>>>> n-v
>>>>>>>>>>>>>>>>>>>>>>> irt
>>>>>>>>>>>>>>>>>>>>>>> ual
>>>>>>>>>>>>>>>>>>>>>>> -su
>>>>>>>>>>>>>>>>>>>>>>> bne
>>>>>>>>>>>>>>>>>>>>>>> t-0
>>>>>>>>>>>>>>>>>>>>>>> 2.t
>>>>>>>>>>>>>>>>>>>>>>> xt
>>>>>>>>>>>>>>>>>>>>>>>>> Status:
>>>>>>>>>>>>>>>>>>>>>>>>> http://datatracker.ietf.org/doc/draft-xu
>>>>>>>>>>>>>>>>>>>>>>>>> -l3
>>>>>>>>>>>>>>>>>>>>>>>>> vpn
>>>>>>>>>>>>>>>>>>>>>>>>> -vi
>>>>>>>>>>>>>>>>>>>>>>>>> rtu
>>>>>>>>>>>>>>>>>>>>>>>>> al-
>>>>>>>>>>>>>>>>>>>>>>>>> sub
>>>>>>>>>>>>>>>>>>>>>>>>> net
>>>>>>>>>>>>>>>>>>>>>>>>> Htmlized:
>>>>>>>>>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-xu-l3vp
>>>>>>>>>>>>>>>>>>>>>>>>> n-v
>>>>>>>>>>>>>>>>>>>>>>>>> irt
>>>>>>>>>>>>>>>>>>>>>>>>> ual
>>>>>>>>>>>>>>>>>>>>>>>>> -su
>>>>>>>>>>>>>>>>>>>>>>>>> bne
>>>>>>>>>>>>>>>>>>>>>>>>> t-0
>>>>>>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>>>>>>> Diff:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-x
>>>>>>>>>>>>>>>>>>>>>>>>> u-l
>>>>>>>>>>>>>>>>>>>>>>>>> 3vp
>>>>>>>>>>>>>>>>>>>>>>>>> n-v
>>>>>>>>>>>>>>>>>>>>>>>>> irt
>>>>>>>>>>>>>>>>>>>>>>>>> ual
>>>>>>>>>>>>>>>>>>>>>>>>> -su
>>>>>>>>>>>>>>>>>>>>>>>>> bne
>>>>>>>>>>>>>>>>>>>>>>>>> t-0
>>>>>>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Abstract:
>>>>>>>>>>>>>>>>>>>>>>>>>     This document describes a Layer3
>>>>>>>>>>>>>>>>>>>>>>>>> Virtual Private Network
>>>>>>>>>>>>>>>>>>>>> (L3VPN)-
>>>>>>>>>>>>>>>>>>>>>>>>>     based subnet extension solution
>>>>>>>>>>>>>>>>>>>>>>>>> referred to as Virtual Subnet,
>>>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>>>>     can be used as a kind of Layer3
>>>>>>>>>>>>>>>>>>>>>>>>> network virtualization
>>>>>>>>>>>>>>>>>>> overlay
>>>>>>>>>>>>>>>>>>>>>>>>>     approach for data center
>>> interconnect.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Please note that it may take a couple
>>>>>>>>>>>>>>>>>>>>>>>>> of minutes from the time of submission
>>>>>>>>>>>>>>>>>>>>>>>>> until the htmlized version and diff are
>>>>>>>>>>>>>>>>>>>>>>>>> available at
>>>>>>> tools.ietf.org.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 11:39:09 +0000

Hi everyone,

I believe we may benefit from taking a step back. Let's not only look at 
TTL and traceroute (see my comment below on traceroute itself), and 
let's also try to distinguish between discussions that are useful to 
have here and discussions that may be more useful elsewhere.

First of all, it is obvious that this draft does not claim, nor 
achieves, an exact emulation of L2 connectivity. Even though TTL 
decrementing could be avoided (perhaps with a cost penalty on some 
platforms), other things will also happen differently from how things 
happen on a LAN: source MAC addresses will not be preserved, the 
possibility of addressing any IP packet to any host on the (emulated 
LAN) acting as a gateway, the possibility of doing broadcast and 
link-local multicast (that one would possibly be fixable), any dot-1p 
marking will be lost, and of course the possibility of using non-IP 
protocols.  This may break some applications.  But, to me this does not 
rule out such a solution, as soon as the limitations are understood and 
the solution is used in context where they do not raise issues.

Second, let's see what we need to discuss here in l3vpn. Wim, you are 
saying "this is not in-line with NVO3 requirements.".  To me, it seems 
that this solution deserves to be described, if only as a input for 
documenting in detail what will happen differently than from a LAN and 
specific cases of applications that will behave differently, or break, 
if this is used.

-Thomas

[ On traceroute, I would actually argue -- keeping in mind that 
traceroute is a troubleshooting tool -- that in the context of this 
approach, the output of traceroute will actually provide more 
information useful for troubleshooting, than what we would have with a 
bit-for-bit emulation of L2. Than can be seen as a benefit as well.  If 
we make a //, although a l3vpn is supposed to behave, from the VPN 
customer point of view, like one router  -- traceroute can actually 
provide some information on what happens between the PEs -- AFAIK this 
has never been considered like "breaking traceroute". ]

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 2 Dec 2013 14:18:08 +0000

Thomas, there is more applications that break when this solution is
deployed. HA systems e.g. My view is that the draft break a fundamental IP
behaviour it should not be adopted at all.

On 02/12/13 12:39, "[email-masked]" <[email-masked]>
wrote:

>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 3 Dec 2013 00:55:11 -0800

Wim,

> behaviour it should not be adopted at all.

Is the fundamental IP behavior that you are referring to the TTL decrement between two addresses on the same "subnet" ?
I believe you are wrong: to my knowledge proxy ARP is compliant with Host and Router requirement RFCs.

It is very hard for an application to use anything other than an IP service. First because it is difficult to code, second because some of the most popular platforms to deploy applications (e.g. AWS) do not support anything other than an IP service.

There may be environments where people feel the need to emulate a specific L2 technology; but applications that depend on L2 are always going to be in world of hurt since there are actually different L2 technologies in use. For instance a switched ethernet is different than a E-VPN based ethernet that does control plane based learning (i.e. unknown unicast is not forwarded); and the behavior is different from a hub based ethernet where all traffic is broadcasted.

  Pedro.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 3 Dec 2013 09:10:14 +0000

Pedro, I am not saying proxy ARP is not valid, but what I am telling that
a lot of applications break in such environment. The applications that
rely on this are reality and we should not break them.

On 03/12/13 09:55, "Pedro Roque Marques" <[email-masked]> wrote:

>Wim,
>
>On Dec 2, 2013, at 6:18 AM, Henderickx, Wim (Wim)
><[email-masked]> wrote:
>
>Is the fundamental IP behavior that you are referring to the TTL
>decrement between two addresses on the same "subnet" ?
>It is very hard for an application to use anything other than an IP
>service. First because it is difficult to code, second because some of
>the most popular platforms to deploy applications (e.g. AWS) do not
>support anything other than an IP service.
>
>There may be environments where people feel the need to emulate a
>specific L2 technology; but applications that depend on L2 are always
>going to be in world of hurt since there are actually different L2
>technologies in use. For instance a switched ethernet is different than a
>E-VPN based ethernet that does control plane based learning (i.e. unknown
>unicast is not forwarded); and the behavior is different from a hub based
>ethernet where all traffic is broadcasted.
>
>  Pedro.
>
>> 
>>>>>>>> against the Proxy ARP technology itself which was actually
>>>>>>>>designed
>>>>>>>> at

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Dec 2013 10:54:10 +0100

Hi Wim,

I think you are right that perhaps some Ethernet based applications may
break. But perhaps it is worth to observe that wast majority of other
applications may happily work on virtual subnet too.

So maybe rather then stopping adoption those who are worried about some
specific applications not working in any of today's L2 emulations to
document those in a draft.

For one it could be nice deployment guideline document to the operators and
for the second it may give hints to application developers to fix their
code :)

Best,
R.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 3 Dec 2013 12:03:36 +0000

Robert, I got surprised recently how many things break in such environment and this is why I am reluctant to standardise this work. I also don’t believe the people who have to fix the applications will even read this work.

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 3 December 2013 10:54
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Pedro Roque Marques <[email-masked]<mailto:[email-masked]>>, Thomas Morin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: on limitations of draft-xu-l3vpn-virtual-subnet

Hi Wim,

I think you are right that perhaps some Ethernet based applications may break. But perhaps it is worth to observe that wast majority of other applications may happily work on virtual subnet too.

So maybe rather then stopping adoption those who are worried about some specific applications not working in any of today's L2 emulations to document those in a draft.

For one it could be nice deployment guideline document to the operators and for the second it may give hints to application developers to fix their code :)

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Dec 2013 13:20:00 +0100

Hi Wim,

I am not questioning that things can break. I am just asking that it would
be great to document those stating specific reasons or given's app design
assumptions.

Cheers,
R.

On Tue, Dec 3, 2013 at 1:03 PM, Henderickx, Wim (Wim) <
[email-masked]> wrote:

>  Robert, I got surprised recently how many things break in such
> environment and this is why I am reluctant to standardise this work. I also
> don’t believe the people who have to fix the applications will even read
> this work.
>
>   From: Robert Raszuk <[email-masked]>
> To: Wim Henderickx <[email-masked]>
> Cc: Pedro Roque Marques <[email-masked]>, Thomas Morin <
> [email-masked]>, "[email-masked]" <[email-masked]>
>  For one it could be nice deployment guideline document to the operators
> and for the second it may give hints to application developers to fix their
> code :)
>
>  Best,
> R.
>
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 3 Dec 2013 13:13:16 +0000

Robert, I agree that it is useful  to document how to design an application in an IP only cloud environment. However this is a different document than the draft we are discussing here.

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 3 December 2013 13:20
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Morin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: on limitations of draft-xu-l3vpn-virtual-subnet

Hi Wim,

I am not questioning that things can break. I am just asking that it would be great to document those stating specific reasons or given's app design assumptions.

Cheers,
R.

On Tue, Dec 3, 2013 at 1:03 PM, Henderickx, Wim (Wim) <[email-masked]<mailto:[email-masked]>> wrote:
Robert, I got surprised recently how many things break in such environment and this is why I am reluctant to standardise this work. I also don’t believe the people who have to fix the applications will even read this work.

Hi Wim,

Best,
R.

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Dec 2013 07:54:48 -0800

> I believe you are wrong: to my knowledge proxy ARP is compliant with Host and Router requirement RFCs.

For IPv4, RFC1812 says that all 1's "limited broadcast"
(255.255.255.255) MUST NOT be forwarded. RFC2644 updates that RFC to say
that even subnet-directed broadcasts MUST NOT be forwarded (as
configured by default).

So by default, a router would never forward the broadcast for which the
proxy ARP would be an appropriate response. Which would mean that the
proxy would work only if already populated at the router; there would be
no means to forward the initial request if the cache were empty. So
proxy ARP would work if manually configured, but would be unreliable if
automatically populated if used on a router that spans two groups of
hosts on the same subnet.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Dec 2013 07:56:15 -0800

PS - it seems obvious to me that placing a router (an L3 IP forwarding
device) between two sets of hosts considered on the same "subnet" is broken.

What you want there is an L2 switch, not an L3 device.

Joe

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 3 Dec 2013 10:47:40 -0800

Joe,

On Dec 3, 2013, at 7:54 AM, Joe Touch <[email-masked]> wrote:

> proxy ARP would be an appropriate response.

yes.

> Which would mean that the
> proxy would work only if already populated at the router;

I don't follow. Lets assume i've a device that is an IP compliant router which has interface A and interface B.
The quote above means that it should not forward a packet address to 255.255.255.255 between link A and link B (or vice-versa). This has nothing no relationship to whether this device is capable of generating ARP requests or proxy ARP replies.

> there would be

Proxy ARP is unrelated to subnet broadcasts.

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Dec 2013 11:10:38 -0800

On 12/3/2013 10:47 AM, Pedro Roque Marques wrote:
> I don't follow. Lets assume i've a device that is an IP compliant
> router which has interface A and interface B.
> The quote above means that it should not forward a packet address to
> 255.255.255.255 between link A and link B (or vice-versa). This has
> nothing no relationship to whether this device is capable of generating
> ARP requests or proxy ARP replies.

ARP requests would never be forwarded across such a device. This means
that proxy ARP responses would either have to be manually configured or
learned by the actions of some other party. There's no opportunity to
have the proxy ARP be a short-cut for a relayed ARP - which limits the
cases where proxy ARP can be used.

> Proxy ARP is unrelated to subnet broadcasts.

See the example above; not always.

Joe

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 3 Dec 2013 11:30:58 -0800

Joe,

> What you want there is an L2 switch, not an L3 device.

It depends on who is "you"...

The vast majority of applications are not capable of accessing the L2 header of a packet; if "you" have applications that care about the L2 header and a specific L2 behavior then "you" must provide that model.

That is one of the issues that come up repeatedly around this topic. There are very different requirements between traditional/legacy data-centers deployments and "scale out" deployments. The most successful scale out deployments do not support L2 semantics. It is a tradeoff: not having to support ethernet emulation simplifies networking and it turns out there is a class of applications that don't care. That shouldn't prevent people from adding "an L2 switch" when serving the traditional market.

There where applications in the past that relied on an ethernet bus behavior and assumed that they could listen to unicast packets sent to any MAC. When switches where introduced they had to change to use unregistered MAC; on an L2 emulation that don't broadcast unknown unicast packets they will again have to change. Even the concept of what is an L2 service changes over time and applications that rely on side effects may be impacted... they are very few however. And it is often an accepted trade-off to not support these in new environments.

So perhaps instead of using terms like "broken", we can discuss what service model a given solution provides. And consider that given service models have advantages and drawbacks.

It is perfectly reasonable to ask the author of the draft that is being discussed to clarify what is the service model: what is the TTL treatment; the IP broadcast model, etc. You can then let the network operator decide what are their specific requirements.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 3 Dec 2013 11:37:21 -0800

On Dec 3, 2013, at 11:10 AM, Joe Touch <[email-masked]> wrote:

> learned by the actions of some other party.

That is incorrect.
The typical scenario where proxy arp is used the IP device has the knowledge of the subnets but not the host. ARP works just fine.

Example interface A: 10.0.0.0/25, interface B: 10.0.0.128/25.
Host configuration: 10.0.0/24

> There's no opportunity to

I'm sorry but whether the router knows how to resolve ARP is unrelated to the broadcast forward behavior. There is no circumstance where this is the same process.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Dec 2013 14:42:43 -0500

Robert, 

	Is documentation of problems the thrust of the document in question?

	--Tom

On Dec 3, 2013:7:20 AM, at 7:20 AM, Robert Raszuk <[email-masked]> wrote:

> On Tue, Dec 3, 2013 at 1:03 PM, Henderickx, Wim (Wim) <[email-masked]> wrote:
> Cc: Pedro Roque Marques <[email-masked]>, Thomas Morin <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Dec 2013 11:44:50 -0800

On 12/3/2013 11:30 AM, Pedro Roque Marques wrote:
> The vast majority of applications are not capable of accessing the 
> L2 header of a packet; if "you" have applications that care about the
> L2 header and a specific L2 behavior then "you" must provide that
> model.

The same is true for L3, though.

> That is one of the issues that come up repeatedly around this topic.
> There are very different requirements between traditional/legacy
> data-centers deployments and "scale out" deployments. The most
> successful scale out deployments do not support L2 semantics. It is a
> tradeoff: not having to support ethernet emulation simplifies networking
> and it turns out there is a class of applications that don't care. That
> shouldn't prevent people from adding "an L2 switch" when serving the
> traditional market.
> 
> There where applications in the past that relied on an ethernet bus
> behavior and assumed that they could listen to unicast packets sent to
> any MAC.

They ought to have been using a broadcast address if broadcast was desired.

> When switches where introduced they had to change to use
> unregistered MAC on an L2 emulation that don't broadcast unknown
> unicast packets they will again have to change.

Had they correctly used a broadcast address, it would have continued to
work.

> Even the concept of what
> is an L2 service changes over time and applications that rely on side
> effects may be impacted..

So far you've convinced me that if you don't understand the L2 you're
using, you can see inadvertent side-effects. However, if you do
understand the L2, things would have continued to work fine.

> they are very few however. And it is often an
> accepted trade-off to not support these in new environments.

An Ethernet that doesn't support broadcast addresses isn't Ethernet
anymore. If someone sells you something they claim is Ethernet and
broadcast addresses aren't supported, return it. But I don't see why we
should deal with this as a "new environment".

Yes, there are L2s that don't support broadcast, and many Internet
mechanisms don't react well to them (see RFC 3819 ).

> So perhaps instead of using terms like "broken", we can discuss what
> service model a given solution provides. And consider that given service
> models have advantages and drawbacks.

And some don't support Internet as L3 until there is support for some
sort of broadcast emulation (e.g., RFC 1577).

> It is perfectly reasonable to ask the author of the draft that is
> being discussed to clarify what is the service model: what is the TTL
> treatment; the IP broadcast model, etc. You can then let the network
> operator decide what are their specific requirements.

If it's an Internet L3 subnet, then see RFC 3819.

If that's not what you can support, then see RFC 1577 for suggestions on
how to emulate what's *required*.

No, I don't think changing the Internet models to support incomplete
solutions is a good idea for anyone.

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 4 Dec 2013 02:22:56 +0000

> -----邮件原件-----
> 发件人: L3VPN [mailto:[email-masked]] 代表 Joe Touch
> 发送时间: 2013年12月4日 3:45
> 收件人: Pedro Roque Marques
> 抄送: [email-masked]
> 主题: Re: on limitations of draft-xu-l3vpn-virtual-subnet
> 
> 
> 
> > tradeoff: not having to support ethernet emulation simplifies
> > networking and it turns out there is a class of applications that
> > don't care. That shouldn't prevent people from adding "an L2 switch"
> > when serving the traditional market.
> >
> > When switches where introduced they had to change to use unregistered
> > MAC on an L2 emulation that don't broadcast unknown unicast packets
> > they will again have to change.
> 
> Had they correctly used a broadcast address, it would have continued to work.
> 
> > Even the concept of what
> So far you've convinced me that if you don't understand the L2 you're using,
> you can see inadvertent side-effects. However, if you do understand the L2,
> things would have continued to work fine.
> 
> > they are very few however. And it is often an accepted trade-off to
> > not support these in new environments.
> 
> An Ethernet that doesn't support broadcast addresses isn't Ethernet anymore. If
> someone sells you something they claim is Ethernet and broadcast addresses
> aren't supported, return it. But I don't see why we should deal with this as a
> "new environment".
> 
> Yes, there are L2s that don't support broadcast, and many Internet mechanisms
> don't react well to them (see RFC 3819 ).
> 
> > service model a given solution provides. And consider that given
> > service models have advantages and drawbacks.
> 
> And some don't support Internet as L3 until there is support for some sort of
> broadcast emulation (e.g., RFC 1577).

Hi Joe,

This draft is not intended to emulate a subnet for the TRANSIT LAN which is used for interconnecting routers, instead, it's just intended to emulate a subnet for the EDGE LAN where a lot of end HOSTs belonging to the same subnet are connected to each other. BTW, it's just a special usage of the Proxy ARP mechanism [RFC1027]. 

> If it's an Internet L3 subnet, then see RFC 3819.

See the above statement.

> If that's not what you can support, then see RFC 1577 for suggestions on how to
> emulate what's *required*.

See the above statement.

> No, I don't think changing the Internet models to support incomplete solutions
> is a good idea for anyone.

As said before, this draft just describes a special usage of the Proxy ARP mechanism [RFC1027]. Therefore it DOESN'T change the Internet models at all. This special usage of the Proxy ARP is just to provide an optimal forwarding scheme for a certain target scenario where the subnet associated with the EDGE LAN need to be extended across multiple geographical dispersed locations). 

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 4 Dec 2013 02:35:30 +0000

> 发送时间: 2013年12月3日 23:55
> 收件人: Pedro Roque Marques; Henderickx, Wim (Wim)
> 抄送: Thomas Morin; [email-masked]
> > Is the fundamental IP behavior that you are referring to the TTL decrement
> between two addresses on the same "subnet" ?
> that even subnet-directed broadcasts MUST NOT be forwarded (as configured
> by default).
> 
> So by default, a router would never forward the broadcast for which the proxy
> ARP would be an appropriate response. Which would mean that the proxy
> would work only if already populated at the router; there would be no means to
> forward the initial request if the cache were empty. So proxy ARP would work if
> manually configured, but would be unreliable if automatically populated if used
> on a router that spans two groups of hosts on the same subnet.

Hi Joe,

From the above statement (e.g., " there would be no means to forward the initial request if the cache were empty"), it seems that the proxy ARP mechanism you meant is actually the ARP cache mechanism in which the real MAC of the target host is expected to be returned by the "ARP Proxy". In contrast, the ARP proxy mechanism used in this draft is strictly accordance with the definition of the Proxy ARP in RFC1027. That's to say, the ARP proxy would return its own MAC rather than the real MAC of the target host, which means there is no need for broadcasting the ARP requests across the virtual subnet.

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 4 Dec 2013 02:49:50 +0000

> 发送时间: 2013年12月4日 3:11
> >> (255.255.255.255) MUST NOT be forwarded. RFC2644 updates that RFC to
> >> say that even subnet-directed broadcasts MUST NOT be forwarded (as
> >> configured by default).
> >>
> >> So by default, a router would never forward the broadcast for which
> >> the proxy ARP would be an appropriate response.
> >
> > yes.
> >
> > nothing no relationship to whether this device is capable of
> > generating ARP requests or proxy ARP replies.
> 
> ARP requests would never be forwarded across such a device. This means that
> proxy ARP responses would either have to be manually configured or learned by
> the actions of some other party. There's no opportunity to have the proxy ARP
> be a short-cut for a relayed ARP - which limits the cases where proxy ARP can be
> used.

Hi Joe,

It seems that you have mistakenly taken the ARP proxy as the ARP cache since ARP requests have never been expected to be forwarded across such a device in the ARP proxy case.

Xiaohu

> >> proxy ARP would work if manually configured, but would be unreliable
> >> if automatically populated if used on a router that spans two groups
> >> of hosts on the same subnet.
> >