Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req

From: Lucy yong <[email-masked]>
Date: Sun, 4 Nov 2012 19:40:59 +0000

I support this draft but have some comments.

1) in section 4.3, Text: The latter scenario often means that requiring a dedicated
   link between the PEs, for the operation of the multi-homing mechanism, is not appealing from cost standpoint.

Comment: a dedicated link between PEs. will this link is in IGP link too? or private link.
May PE nodes that are multi-homed to a same CE be different ASes? If yes, state it out.

2) in section 4.6, the last paragraph should state a requirement for flow based load balance.

3) It should add one requirement in supporting Ethernet L2VPN across multi-ASes

4) As the draft mentioned, the new service interfaces are required for DC interconnection. If DC uses NVo3 in future, will these service interfaces are still necessary? Suggest giving some use cases where the new service interfaces are necessary in an appendix.

Cheers,
Lucy

> ------------------------------
> Date: Fri, 19 Oct 2012 23:34:53 +0100
> From: Giles Heron <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> 
> This email initiates an L2VPN WG Last Call for:
> 
> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01
> 
> please comment to the list as to the suitability of this draft for
> publication as a Standards Track RFC from the L2VPN WG.
> 
> this last call will close on Friday 2nd November.
> 
> Nabil & Giles

---

From: Giles Heron <[email-masked]>
Date: Sun, 4 Nov 2012 21:02:44 +0000

Thanks Lucy,

authors - I'd like to see you address Yuanlong and Lucy's comments.  Perhaps you can discuss face-to-face this week?

Once the comments have been addressed we can progress the draft further.

thanks.

Giles

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sun, 4 Nov 2012 22:53:30 +0100

>May PE nodes that are multi-homed to a same CE be different ASes? If yes,

WH> the dedicated link is not necessary but it depends on the design. We
better take it out
>2) in section 4.6, the last paragraph should state a requirement for flow

WH> are you saying the Mac based load-balancing is a MUST or are you
saying the MAC based load-balancing should be flow based
>
>3) It should add one requirement in supporting Ethernet L2VPN across
>multi-Ases

WH> agreed
>
>4) As the draft mentioned, the new service interfaces are required for DC
>interconnection. If DC uses NVo3 in future, will these service interfaces
>are still necessary? Suggest giving some use cases where the new service
>interfaces are necessary in an appendix.
WH> it depends on what use case we have in NVO3: is the NVE collocated
with the VM or is the NVE located at a TOR connected to a server.
Depending on the connectivity different solutions might be required and as
such we made the requirement general and not specific since there is
multiple solutions to this and this is a requirements draft rather than
solution draft. Use case should be covered in a separate doc.

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Nov 2012 02:39:14 +0000

Hi Wim,

Please see inline.

> -----Original Message-----
> From: Henderickx, Wim (Wim) [mailto:[email-masked]]
> Sent: Sunday, November 04, 2012 3:54 PM
> To: Lucy yong; [email-masked]
> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req
> 
> 
> 
> >1) in section 4.3, Text: The latter scenario often means that
> requiring a
> >dedicated
> >   link between the PEs, for the operation of the multi-homing
> mechanism,
> >is not appealing from cost standpoint.
> >
> >Comment: a dedicated link between PEs. will this link is in IGP link
> too?
> >or private link.
> >May PE nodes that are multi-homed to a same CE be different ASes? If
> yes,
> >state it out.
> 
[Lucy] My second question is if PE nodes that are multi-homed to a same CE may be in different ASes in latter case? Whether yes, or no, it should state it out.

> >
> >2) in section 4.6, the last paragraph should state a requirement for
> flow
> >based load balance.
> 
[Lucy] Text:   A solution MAY support multi-homed network with active/active MAC-
   based load balancing (i.e. different MAC addresses on a VLAN are
   reachable via different PEs).

In section 4.1, it describes options for flow-based load balancing, that should apply to here, right?
That means the same MAC address may occur on the different PEs too.

> solution draft. Use case should be covered in a separate doc.
[Lucy] It, I think, is more about cases between DC GW and WAN PE. For example, if NVO3 is used in DC, when we need VLAN aware bundle service interface? Could you give a example? I don't have a problem to make a general requirement, just want know where is the requirement coming from.
 
Lucy

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 5 Nov 2012 11:04:18 +0100

Lucy, in-line

On 05/11/12 03:39, "Lucy yong" <[email-masked]> wrote:

>[Lucy] My second question is if PE nodes that are multi-homed to a same
>CE may be in different ASes in latter case? Whether yes, or no, it should
>state it out.

WH2> this seems like an odd scenario
>That means the same MAC address may occur on the different PEs too.
WH2> yes
>[Lucy] It, I think, is more about cases between DC GW and WAN PE. For
>example, if NVO3 is used in DC, when we need VLAN aware bundle service
>interface? Could you give a example? I don't have a problem to make a
>general requirement, just want know where is the requirement coming from.
> 
>Lucy

WH2> the service interface we are talking about here is how the EVPN
service is modelled on the DC GW/WAN PE. There are multiple scenarios
which should be supported. The service interface here is an internal
modelling of the EVPN on the PE

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Nov 2012 16:09:22 +0000

snip
> WH2> this seems like an odd scenario
[Lucy] agree. 
> >In section 4.1, it describes options for flow-based load balancing,
> that
> >should apply to here, right?
> >> >4) As the draft mentioned, the new service interfaces are required
> for
> >> DC
> >> Depending on the connectivity different solutions might be required
> and
> >> as
[Lucy] OK. Maybe I did not follow the early requirement discussions. Where was this requirement coming from. MEF Services do not support such service interface. Was this from some operators in IETF? I just like to know a use case if possible.

Lucy

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 5 Nov 2012 17:14:32 +0100

-- Snip --

[Lucy] OK. Maybe I did not follow the early requirement discussions. Where
was this requirement coming from. MEF Services do not support such service
interface. Was this from some operators in IETF? I just like to know a use
case if possible.

WH> yes this is from operators of which some are on the co-author list.
The driver for this is more optimised and scalable implementations. MEF
might adopt this going fwd, so we should not make ourselves dependent on
MEF

-- Snip --

On 05/11/12 11:09, "Lucy yong" <[email-masked]> wrote:

>[Lucy] OK. Maybe I did not follow the early requirement discussions.
>Where was this requirement coming from. MEF Services do not support such
>service interface. Was this from some operators in IETF? I just like to
>know a use case if possible.
>
>Lucy
>> >> >
>> >> >Cheers,
>> >> >Lucy
>> >> >

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Nov 2012 20:58:27 +0000

Wim,

I agree that we (IETF) don't have make ourselves dependent on MEF. However, there are a lot of service providers in MEF to specify Ethernet services and service interfaces. Such service interface has not yet to bring on the table there. This may be because the people in two SDOs may be from different orgs..

Thanks,
Lucy

> Sent: Monday, November 05, 2012 10:15 AM
> Where
> >> >> multiple solutions to this and this is a requirements draft
> rather
> >> than

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 5 Nov 2012 22:00:11 +0100

Lucy, sure and this evolution into MEF is most likely to come, but I
believe it is a clear req for EVPN, so I believe we can close this point

On 05/11/12 15:58, "Lucy yong" <[email-masked]> wrote:

>Wim,
>
>I agree that we (IETF) don't have make ourselves dependent on MEF.
>However, there are a lot of service providers in MEF to specify Ethernet
>services and service interfaces. Such service interface has not yet to
>bring on the table there. This may be because the people in two SDOs may
>be from different orgs..
>
>Thanks,
>Lucy
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 18:26:53 +0000

Hi Yaunlong,

Thanks for your comments. Please refer to my reply in line ...

On 10/26/12 7:18 PM, "Jiangyuanlong" <[email-masked]> wrote:

>Hi authors of draft-ietf-l2vpn-evpn-req-01 and all,
>
>I had a review of this document, and believe that some issues still need
>to be resolved.
>
>Some technical comments:
>1. In Section 4.1, it says:
>   "....This being the case, the first requirement for
>   active/active multi-homing is the ability to accommodate flexible
>   flow-based load-balancing from the CE node based on L2, L3 and/or L4
>   header fields.
>
>   A solution MUST be capable of supporting flexible flow-based load
>   balancing from the CE as described above."
>   
>I am not sure the current E-VPN framework can support CE load-balancing
>based on L3 and/or L4 header fields. For example, if the frames with the
>same MAC address are load-balanced on multiple PEs in a multi-homed
>group, the remote PEs need to support sub-MAC flow-based forwarding,
>furthermore, BGP signaling also needs substantial extensions to support
>it. All these will pose a great challenge to EVPN.

This is a data-plane function and has nothing to do with the control-plane
BGP. Currently majority of LACP implementation do perform load balancing
among member links using L3 and/or L4 headers besides MAC addresses. On
the remote PE, when multiple adjacencies exist for the same MAC route, the
PE can hash based on L2/L3/L4 header to pick one of those adjacencies.
This also has nothing to do with the BGP control plane.

>
>2. At the end of Section 4.4, it says:
>"
>   A multi-homed group (also known as a multi-chassis LACP group) is a
>   group of PEs supporting a multi-homed CE.
>"
>and in Section 4.5, it says:
>"  In order to simplify service provisioning and activation, the multi-
>   homing mechanism SHOULD allow arbitrary grouping of PE nodes into
>   redundancy groups where each redundancy group represents all multi-
>   homed groups that share the same group of PEs. This is best explained
>   with an example: consider three PE nodes - PE1, PE2 and PE3.
>"
>It seems a formal definition of redundancy group is needed (IMO, "each
>redundancy group represents all multi-homed groups that share the same
>group of PEs" is a little confusing), and multi-homed group is also not
>clearly defined IMO (it seems a specific PE should be designated as DF in
>multi-homed group while redundancy group is just a set of PEs according
>to the EVPN framework).

I think the text is very clear regarding multi-homed group and redundancy
group and both of them are defined in the text. Section 4.4 defines
multi-homed group by saying: "A multi-homed group (also known as a
multi-chassis LACP group) is a group of PEs supporting a multi-homed CE"
and section 4.5 defines redundancy group by saying: "each redundancy group
represents all multi-
   homed groups that share the same group of Pes".

If you think the definitions can be made better, please provide the text.

> 
>   
>3. At the end of Section 6, it says:
>"  - Implementations SHOULD revert to using default values for
>   parameters as and where applicable.
>"
>It seems like a rule of thumb to use some default values for any
>implementation or protocol design, do we really need to list this as an
>EVPN requirement?

Yes.

>
>4. In Section 10, it says:
>"
>   A solution MUST be capable of supporting flexible VPN topologies that
>   are not constrained by the underlying mechanisms of the solution.
>"
>Not sure how can we determine the fulfillment of this mandatory
>requirement?

Hopefully after the discussion that we had on evpn-etree, it is now clear
on how to fulfill this requirement.

>
>5. In Section 11, it says:
>"
>   For scenarios where MAC learning is performed in data-plane, there
>   are no additional security aspects beyond those considered in
>   [RFC4761] and [RFC4762]. And for scenarios where MAC learning is
>   performed in control plane (via BGP), there are no additional
>   security aspects beyond those considered in [RFC4364].
>"
>However, there is no description of "MAC learning" in the requirement
>doc, so why it is discussed in the security section? It is proposed
>either we remove these discussions, or refer to draft-ietf-l2vpn-evpn in
>the first place (where it dwells in).

This requirement doc is supposed to cover both E-VPN and PBB-EVPN.
PBB-EVPN performs the MAC learning in data-plane.

>
>Some minor comments:
>1. Section 2, s/for e.g./e.g.,/
>2. At the end of Section 2, all the section numbers referred to are in
>disorder.
>3. Section 3, the Terminology section is in a mess, and re-formatting is
>needed.
>4. Section 4.1, s/IGP ECMP paths/ECMP paths/, as E-VPN may well cross
>multi-AS.
>5. Section 4.2, 
>	s/For instance/For instance,/
>6. Section 4.2, 
>	s/between those LSPs/among those LSPs/
>7. In Section 4.2, it says:
>   "Similarly if LDP is being used as the transport LSP protocol,
>   then the solution MUST be able to leverage LDP ECMP capabilities."
>1) s/transport LSP protocol/signaling protocol for transport LSPs/
>2) s/leverage LDP ECMP capabilities/leverage those LDP signaled equal
>cost LSPs/, since "LDP ECMP capabilities" are somewhat ambiguous.
>
>8. In Section 4.2, it says:
> "The solution MUST also be able to leverage work in the MPLS WG that is
>in
>   progress to improve the load balancing capabilities of the network
>   based on entropy labels." 						
>   It seems a reference to draft-ietf-mpls-entropy-label is needed.
>   
>9. In Section 4.3,
>  s/from cost standpoint/from a cost standpoint/
>  s/the pair of PEs/multiple PEs/ or s/multi-homed/dual-homed/
>  
>10. In Section 4.4,
>s/multi-chassis LACP group/multi-chassis LAG/, since LACP is only the
>control protocol for the LAG.

Agreed to all.

>
>11. Section 4.6,
>s/participate in the control/participate in the resiliency/, since G.8032
>is usually not regarded as a control protocol.

G.8032 is considered as control protocol.

>
>12. Section 5,
>1) What is the advantage of MP2MP LSP? Maybe an example or a reference
>could be provided to justify it.
>2) s/uncast/unicast/
>
>13. Section 6,
>1) s/MUST be maintained/MUST be maintained./
>2) s/on the access circuit/for the access circuit/

Agreed to all.

>
>14. Section 8,
>s/the attachment circuit or PE/an attachment circuit or a PE/

Changed to the attachment circuit or the PE.

>
>15. Section 9, it says:
>"   ...it is required to minimize the flooding of broadcast
>   frames outside the confines of a given site. Of particular interest
>   is periodic ARP traffic.
>"
>Why periodic ARP traffic is of particular interest? it seems to me just
>an example.

Because that can constitutes the majority of the flood traffic.

>
>16. Section 10, 
>s/with other roots/with roots/

Other roots is o.k.

>
>17. Section 13, 
>1) For [802.1Q], it seems IEEE Std 802.1Q-2011 is the latest revision.
>2) Two redundant references for [VPLS-MCAST] are included in this
>section, it is proposed that the 1st should be removed.

Done.

>Regards,
>Yuanlong

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 19:23:00 +0000

Wim, Lucy:

I think we are all set. Going through your emails, we can conclude the
following comment resolutions:

>May PE nodes that are multi-homed to a same CE be different ASes? If yes,

Resolution: no change to the text.
The draft states that having such a dedicated link (which is not an IGP
link) is not desirable and thus cannot be assumed that such link exist.

>2) in section 4.6, the last paragraph should state a requirement for flow

Resolution: Agreed, we add flow-based LB to the text.

>multi-ASes

Resolution: Agreed, we'll add that.

>interfaces are necessary in an appendix.

Resolution: No change, as clarified in the email thread.

Cheers,
Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 19:51:16 +0000

Revision to one of the resolution Š

>Resolution: Agreed, we add flow-based LB to the text.

Section 4.6 talks about dual-homed network and NOT dual-homed device. As
such, no application has been identified that requires flow-based load
balancing for multi-homed network! In other words, a network based on
802.1Q or G.8032 does not need flow-baesd LB.

Therefore, we will not add such requirement to section 4.6.

Cheers,
Ali

---

From: Lucy yong <[email-masked]>
Date: Wed, 14 Nov 2012 20:02:06 +0000

Hi Ali,

The last paragraph in section 4.6

   A solution MAY support multi-homed network with active/active MAC-
   based load balancing (i.e. different MAC addresses on a VLAN are
   reachable via different PEs).

Should the load balancing function depend on whether dual-homed network or dual homed device? IMO: it is not. We should not exclude that the packets with the same MAC address appear on the different PEs. But the paragraph seems exclude that. That is my point.

Regards,
Lucy

> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2012 1:51 PM
> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong;
> [email-masked]

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 20:09:33 +0000

Hi Lucy,

Yes, the load balancing function should depend on whether we are talking
about MHD or MHN. In case of MHD, LACP provides per-flow load balancing.
However, in case of MHN, 802.1Q expects load balancing on a per-VLAN basis
and G.8032 can expect load balancing on a per-MAC basis (for a given
VLAN). 

Cheers,
Ali

the paragraph intentionally excludes that as I cannot see of any
application that requires it

On 11/14/12 12:02 PM, "Lucy yong" <[email-masked]> wrote:

>Should the load balancing function depend on whether dual-homed network
>or dual homed device? IMO: it is not. We should not exclude that the
>packets with the same MAC address appear on the different PEs. But the
>paragraph seems exclude that. That is my point.
>
>Regards,
>Lucy
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 14 Nov 2012 20:18:36 +0000

Hi Ali,

> link) is not desirable and thus cannot be assumed that such link exist.
[Lucy] As Wim suggested, it is better to delete the following sentence in section 4.3 because it does not serve any requirement and brings a confusion.

   The latter scenario often means that requiring a dedicated
   link between the PEs, for the operation of the multi-homing mechanism, is not appealing from cost standpoint.

Should we explicitly say if PEs associated with a multi-homed setup have to be in the same IGP or not in different IGPs, i.e. different ASes? The following sentence implicitly state that.  
 
Furthermore, the IGP cost from remote PEs to the pair of PEs in the multi-homed setup
   cannot be assumed to be the same when those latter PEs are geo-
   redundant.

Regards,
Lucy
> >>> interface. Was this from some operators in IETF? I just like to
> know a
> >>> use
> >>> case if possible.
> >>>
> >>>
> >>> might adopt this going fwd, so we should not make ourselves
> dependent
> >>> on
> >>> MEF
> >>>
> >>> -- Snip --
> >>>
> >>> >> >[Lucy] My second question is if PE nodes that are multi-homed
> to a
> >>> >> same
> >>> >> >CE may be in different ASes in latter case? Whether yes, or no,
> it
> >>> >> should
> >>> >> >state it out.
> >>> >>
> >>> >> >> >2) in section 4.6, the last paragraph should state a
> requirement
> >>> >> for
> >>> >> >> flow
> >>> >> >> >based load balance.
> >>> >> >>
> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST or
> are
> >>> you
> >>> >> >> >3) It should add one requirement in supporting Ethernet
> L2VPN
> >>> >> across
> >>> >> >> >multi-Ases
> >>> >> >>
> >>> >> >> WH> agreed
> >>> >> >> >
> >>> >> >> >interconnection. If DC uses NVo3 in future, will these
> service
> >>> >> >> interfaces
> >>> >> >> >are still necessary? Suggest giving some use cases where the
> new
> >>> >> >> service
> >>> >> >> such we made the requirement general and not specific since
> there
> >>> is
> >>> >> >[Lucy] It, I think, is more about cases between DC GW and WAN
> PE.
> >>> For
> >>> >> >interface? Could you give a example? I don't have a problem to
> make
> >>> a
> >>> >> >general requirement, just want know where is the requirement
> coming
> >>> >> from.
> >>> >> >
> >>> >> >Lucy
> >>> >>
> >>> >Where was this requirement coming from. MEF Services do not
> support
> >>> such
> >>> >service interface. Was this from some operators in IETF? I just
> like
> >>> to
> >>> >> >> >> please comment to the list as to the suitability of this
> draft
> >>> >> for

---

From: Lucy yong <[email-masked]>
Date: Wed, 14 Nov 2012 20:29:07 +0000

Hi Ali,

I see your point. However, both 802.1Q and G.8032 do not support active-active multi-homed links. Now, I am confused with this requirement in section 4.6.

   A solution MUST also support multi-homed network with active/active
   VLAN-based load balancing (i.e. disjoint VLAN sets active on
   disparate PEs).

Where is the requirement coming from. It is not from 802.1Q and G.8032. I don't know how Ethernet network will handle it.

Lucy

> Sent: Wednesday, November 14, 2012 2:10 PM
> To: Lucy yong; Henderickx, Wim (Wim); [email-masked]

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 14 Nov 2012 22:05:05 +0100

indeed

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Nov 2012 21:13:30 +0000

Lucy,

There should not be a requirement that two or more PEs providing multi-homing to the same CE need to be in the same IGP.  This is too restrictive and totally unnecessary.

Irrespectively Yours,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lucy yong
> Sent: Wednesday, November 14, 2012 12:19 PM
> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); [email-masked]
> Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req
> 
> Hi Ali,
> 
> >
> [Lucy] As Wim suggested, it is better to delete the following sentence
> in section 4.3 because it does not serve any requirement and brings a
> confusion.
> 
> mechanism, is not appealing from cost standpoint.
> 
> Should we explicitly say if PEs associated with a multi-homed setup
> have to be in the same IGP or not in different IGPs, i.e. different
> ASes? The following sentence implicitly state that.
> 
> > >>bring on the table there. This may be because the people in two
> SDOs
> > may
> > >>be from different orgs..
> > >>
> > >>Thanks,
> > >>Lucy
> > >>
> > >>> was this requirement coming from. MEF Services do not support
> such
> > >>> like to
> > >>> The driver for this is more optimised and scalable
> implementations.
> > MEF
> > >>> >> >[Lucy] Text:   A solution MAY support multi-homed network
> with
> > >>> >> >active/active MAC-
> > >>> >> >   based load balancing (i.e. different MAC addresses on a
> > >>> >> >VLAN
> > are
> > >>> >> >That means the same MAC address may occur on the different
> PEs
> > too.
> > >>> >> WH2> yes
> > >>> >> >
> > >>> >> >> >
> > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware
> bundle
> > >>> service
> > >>> >> WH2> the service interface we are talking about here is how
> the
> > EVPN

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 21:25:07 +0000

On 11/14/12 12:18 PM, "Lucy yong" <[email-masked]> wrote:

>[Lucy] As Wim suggested, it is better to delete the following sentence in
>section 4.3 because it does not serve any requirement and brings a
>confusion.
>

I am adding the following two bullets, as further clarification, to sec.
4.3:

   A solution MUST support active/active multi-homing without the need
   for a dedicated control/data link among the PEs in the multi-homed
   group.

   A solution MUST NOT assume that the IGP cost from a remote PE to each
   of the PEs in the multi-homed group is the same.

Cheers,

Ali

>
>Should we explicitly say if PEs associated with a multi-homed setup have
>to be in the same IGP or not in different IGPs, i.e. different ASes? The
>following sentence implicitly state that.
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 14 Nov 2012 21:28:47 +0000

Hi Ali,

Snip:
 .
>    of the PEs in the multi-homed group is the same.
[Lucy] These two requirements are very clear to me. It is clean the confusion.

Cheers,
Lucy
> have
> >> >>services and service interfaces. Such service interface has not
> yet
> >> to
> >> >>> WH> yes this is from operators of which some are on the co-
> author
> >> list.
> >> >>> >> >> WH> it depends on what use case we have in NVO3: is the
> NVE
> >> >>> >> collocated

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Nov 2012 21:28:23 +0000

Ali,

I don't mean to hold things up but is your second bullet really necessary?

Irrespectively Yours,

John

> Of Ali Sajassi (sajassi)
> Sent: Wednesday, November 14, 2012 1:25 PM
> >> >>> such service interface. Was this from some operators in IETF? I
> >> >>> just like to
> >> know a
> >> >>> use
> >> >>> case if possible.
> >> >>>
> >> >>>
> >> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST
> >> >>> >> >> WH> or
> >> are
> >> >>> you
> >> >>> >> WH2> the

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 21:29:58 +0000

Hi Lucy,

When a G.8032 is dual-homed to a pair of PEs, you can have a scenario in
which different set of MAC addresses for the same VLAN are learned by each
of the PEs in the dual-homed group and thus the requirement in this
section.

Cheers,
Ali  

On 11/14/12 12:29 PM, "Lucy yong" <[email-masked]> wrote:

>Hi Ali,
>
>I see your point. However, both 802.1Q and G.8032 do not support
>active-active multi-homed links. Now, I am confused with this requirement
>in section 4.6.
>
>Where is the requirement coming from. It is not from 802.1Q and G.8032. I
>don't know how Ethernet network will handle it.
>
>Lucy
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 Nov 2012 21:32:08 +0000

It is a clarification :-)

Cheers,
Ali

---

From: Lucy yong <[email-masked]>
Date: Wed, 14 Nov 2012 21:44:46 +0000

Hi Ali,

What you say is that two PEs participate G.8032 enabled Ethernet Ring Protection or two bridges that participate a Ethernet Ring Protection connect to two PEs respectively. 

Lucy

> Sent: Wednesday, November 14, 2012 3:30 PM
> >> >> Section 4.6 talks about dual-homed network and NOT dual-homed
> device.
> >> >> As
> >> >> balancing for multi-homed network! In other words, a network
> based
> >> on

---

From: Lucy yong <[email-masked]>
Date: Thu, 15 Nov 2012 16:02:17 +0000

Hi John,

Regarding if EVPN allows two PEs in different ASes to be homed to the same CE, this is my original question on the last call of evpn req.. The current document does not make it clear. 

If this is the case, should we state that PEs that are homed to the same CE may be in the AS or different ASes in the document to make it clear?

Thanks,
Lucy

> Of John E Drake
> Sent: Wednesday, November 14, 2012 3:14 PM
> To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim);
> [email-masked]
> There should not be a requirement that two or more PEs providing multi-
> homing to the same CE need to be in the same IGP.  This is too
> restrictive and totally unnecessary.
> 
> Irrespectively Yours,
> 
> John
> 
> 
> > or
> > > >>> >> >> >4) As the draft mentioned, the new service interfaces
> are
> > > >>> required
> > > >>> >> for
> > > >>> >> >> DC
> > > >>> >> >> Depending on the connectivity different solutions might
> be
> > > >>> required
> > > >>> >> and
> > > >>> >> >> as

---

From: John E Drake <[email-masked]>
Date: Thu, 15 Nov 2012 17:15:42 +0000

Lucy,

I don't want to slow things down but I think such a statement would be extremely helpful.

Irrespectively Yours,

John

> From: Lucy yong [mailto:[email-masked]]
> Sent: Thursday, November 15, 2012 8:02 AM
> To: John E Drake; Ali Sajassi (sajassi); Henderickx, Wim (Wim);
> [email-masked]
> Regarding if EVPN allows two PEs in different ASes to be homed to the
> same CE, this is my original question on the last call of evpn req..
> The current document does not make it clear.
> 
> If this is the case, should we state that PEs that are homed to the
> same CE may be in the AS or different ASes in the document to make it
> clear?
> 
> Thanks,
> Lucy
> 
> > There should not be a requirement that two or more PEs providing
> > multi- homing to the same CE need to be in the same IGP.  This is too
> > > > >May PE nodes that are multi-homed to a same CE be different
> ASes?
> > If
> > > > yes,
> > > > >state it out.
> > > > >
> > > >
> > > in section 4.3 because it does not serve any requirement and brings
> > > a confusion.
> > >
> > > > >4) As the draft mentioned, the new service interfaces are
> > > > >required for
> > > > DC
> > > > >Lucy, sure and this evolution into MEF is most likely to come,
> > > > >but
> > I
> > > > >believe it is a clear req for EVPN, so I believe we can close
> > > > >this
> > > > point
> > > > >
> > > > >>> >> >> WH> are you saying the Mac based load-balancing is a
> > > > >>> >> >> WH> MUST
> > > or
> > > > are
> > > > >>> you
> > > > >>> >> >> with the VM or is the NVE located at a TOR connected to
> > > > >>> >> >> a
> > > > server.
> > > > >>> >> >> solution draft. Use case should be covered in a
> separate
> > > doc.
> > > > >>> >> >interface? Could you give a example? I don't have a
> > > > >>> >> >problem
> > > to
> > > > make
> > > > >>> a
> > > > >>> >> service is modelled on the DC GW/WAN PE. There are
> multiple
> > > > >>> scenarios
> > > > >>> >> which should be supported. The service interface here is
> an
> > > > internal
> > > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-
> req-
> > 01
> > > > >>> >> >> >>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 15 Nov 2012 17:40:45 +0000

Hi Lucy,

I had the former one in mind. However, as long as the RPL owner is in the
middle of the ring, both of the dual-homed PEs receives different set of
MAC addresses for a given VLAN.

Cheers,
Ali 

On 11/14/12 1:44 PM, "Lucy yong" <[email-masked]> wrote:

>Hi Ali,
>
>What you say is that two PEs participate G.8032 enabled Ethernet Ring
>Protection or two bridges that participate a Ethernet Ring Protection
>connect to two PEs respectively.
>
>Lucy
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 15 Nov 2012 17:48:02 +0000

All E-VPN attributes are transitive (including the ones uses for
multi-homing), so multi-homing can span across multiple ASes. I will add a
requirement in the multi-homing section to this effect.

Cheers,
Ali

---

From: Lucy yong <[email-masked]>
Date: Thu, 15 Nov 2012 17:50:34 +0000

Good! This is clear now.
Lucy

> Sent: Thursday, November 15, 2012 11:48 AM
> To: John E Drake; Lucy yong; Henderickx, Wim (Wim); [email-masked]
> >> > > > >Comment: a dedicated link between PEs. will this link is in
> IGP
> >> > link
> >> > > > too?
> >> > > > >or private link.
> >> > > > The draft states that having such a dedicated link (which is
> not
> >> > > > an IGP
> >> > > > link) is not desirable and thus cannot be assumed that such
> link
> >> > > exist.
> >> > > >
> >> > > Furthermore, the IGP cost from remote PEs to the pair of PEs in
> the
> >> > > multi-homed setup
> >> > > > >>I agree that we (IETF) don't have make ourselves dependent
> on
> >> MEF.
> >> > > > >>However, there are a lot of service providers in MEF to
> specify
> >> > > > Ethernet
> >> > > > >>> From: Henderickx, Wim (Wim)
> [mailto:wim.henderickx@alcatel-
> >> > > > lucent.com]
> >> > > > >>> >> >[Lucy] My second question is if PE nodes that are
> multi-
> >> > homed
> >> > > > to a
> >> > > > >>> >> same
> >> > > > >>> >> >CE may be in different ASes in latter case? Whether
> yes,
> >> > > > >>> >> >or no,
> >> > > > it
> >> > > > >>> >> should
> >> > > > >>> >> >state it out.
> >> > > > >>> >>
> >> > > > >>> >> >   based load balancing (i.e. different MAC addresses
> on
> >> a
> >> > > > >>> >> >VLAN
> >> > > > are
> >> > > > >>> >> >In section 4.1, it describes options for flow-based
> load
> >> > > > balancing,
> >> > > > >>> >> that
> >> > > > >>> >> >> such we made the requirement general and not
> specific
> >> > since
> >> > > > there
> >> > > > >>> is
> >> > > > >>> >> >> multiple solutions to this and this is a
> requirements
> >> > draft
> >> > > > >>> rather
> >> > > > >>> >> than
> >> > > > >>> >> >[Lucy] It, I think, is more about cases between DC GW
> and
> >> > WAN
> >> > > > PE.
> >> > > > >>> For
> >> > > > >>> >service interface. Was this from some operators in IETF?
> I
> >> > just
> >> > > > like
> >> > > > >>> to
> >> > > > >>> >> >> >> please comment to the list as to the suitability
> of
> >> > this
> >> > > > draft
> >> > > > >>> >> for
> >> > > > >>> >> >> >> publication as a Standards Track RFC from the
> L2VPN
> >> WG.
> >> > > > >>> >> >> >>

---

From: Lucy yong <[email-masked]>
Date: Thu, 15 Nov 2012 18:05:29 +0000

John,

I don't want to slow this down too. We just make sure the requirements are clear, which will be very helpful in the solution development.

Regards,
Lucy

> Sent: Thursday, November 15, 2012 11:16 AM

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 15 Nov 2012 18:09:53 +0000

Giles, Nabil:

I think all the comments regarding this last call have been resolved. I
have already incorporated them into the next rev. of the draft.

Regards,
Ali

On 11/4/12 1:02 PM, "Giles Heron" <[email-masked]> wrote:

>Thanks Lucy,
>
>authors - I'd like to see you address Yuanlong and Lucy's comments.
>Perhaps you can discuss face-to-face this week?
>
>>too? or private link.
>>yes, state it out.
>>flow based load balance.
>> 4) As the draft mentioned, the new service interfaces are required for
>>DC interconnection. If DC uses NVo3 in future, will these service
>>interfaces are still necessary? Suggest giving some use cases where the
>>new service interfaces are necessary in an appendix.
>> 
>> Cheers,
>> Lucy
>>