[bess] I-D Action: draft-ietf-bess-mvpn-fast-failover-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Multicast VPN fast upstream failover
Authors : Thomas Morin
  Robert Kebler
  Greg Mirsky
Filename: draft-ietf-bess-mvpn-fast-failover-04.txt
Pages   : 19
Date: 2018-11-06

Abstract:
   This document defines multicast VPN extensions and procedures that
   allow fast failover for upstream failures, by allowing downstream PEs
   to take into account the status of Provider-Tunnels (P-tunnels) when
   selecting the upstream PE for a VPN multicast flow, and extending BGP
   MVPN routing so that a C-multicast route can be advertised toward a
   standby upstream PE.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-fast-failover-04
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-fast-failover-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-fast-failover-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Proposed updates to address comments to draft-ietf-bess-mvpn-fast-failover

[Greg Mirsky]

Hi Ali,
thank you for taking the time to review and respond during this busy time,
much appreciated. I will upload the updated version of the draft shortly.

Regards,
Greg

On Wed, Nov 7, 2018 at 11:43 AM Ali Sajassi (sajassi) 
wrote:

>
>
> Hi Greg,
>
>
>
> The changes look good. Thanks for taking care of my comments.
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *Greg Mirsky 
> *Date: *Tuesday, October 30, 2018 at 7:50 AM
> *To: *Cisco Employee , BESS , "
> bess-cha...@ietf.org" 
> *Subject: *Proposed updates to address comments to
> draft-ietf-bess-mvpn-fast-failover
>
>
>
> Dear Ali,
>
> my sincere apologies for being so terribly late to address your comments
> at the BESS WG meeting in Montreal. Below are the updates I propose:
>
> OLD TEXT:
>
>   Then The Downstream PE MAY
>
>initiate a switchover of the traffic from the Primary Upstream PE to
>
>the Standby Upstream PE.
>
> NEW TEXT:
>
>   Then The Downstream PE MAY
>
>initiate a switchover of the traffic from the Primary Upstream PE to
>
>the Standby Upstream PE only if the Standby Upstream PE deemed
>
>available.  The dedicated p2mp BFD session MAY monitor the state of
>
>the Standby Upstream PE.
>
>
>
> OLD TEXT:
>
>Whenever the state of the BFD session changes to Down the Provider
>
>Tunnel will be considered down, and the downstream PE will switch to
>
>the backup Provider Tunnel.
>
> NEW TEXT:
>
>Whenever the state of the BFD session changes to Down the Provider
>
>Tunnel will be considered down, and the downstream PE MAY switch to
>
>the backup Provider Tunnel only if the backup Provider Tunnel deemed
>
>available.  The dedicated p2mp BFD session MAY monitor the state of
>
>the backup Provider Tunnel.
>
>
>
> Attached please find diff to highlight the update and the new version of
> the draft.
>
>
>
> Kind regards,
>
> Greg
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Proposed updates to address comments to draft-ietf-bess-mvpn-fast-failover

[Ali Sajassi (sajassi)]

Hi Greg,

The changes look good. Thanks for taking care of my comments.

Cheers,
Ali

From: Greg Mirsky 
Date: Tuesday, October 30, 2018 at 7:50 AM
To: Cisco Employee , BESS , 
"bess-cha...@ietf.org" 
Subject: Proposed updates to address comments to 
draft-ietf-bess-mvpn-fast-failover

Dear Ali,
my sincere apologies for being so terribly late to address your comments at the 
BESS WG meeting in Montreal. Below are the updates I propose:
OLD TEXT:
  Then The Downstream PE MAY
   initiate a switchover of the traffic from the Primary Upstream PE to
   the Standby Upstream PE.
NEW TEXT:
  Then The Downstream PE MAY
   initiate a switchover of the traffic from the Primary Upstream PE to
   the Standby Upstream PE only if the Standby Upstream PE deemed
   available.  The dedicated p2mp BFD session MAY monitor the state of
   the Standby Upstream PE.

OLD TEXT:
   Whenever the state of the BFD session changes to Down the Provider
   Tunnel will be considered down, and the downstream PE will switch to
   the backup Provider Tunnel.
NEW TEXT:
   Whenever the state of the BFD session changes to Down the Provider
   Tunnel will be considered down, and the downstream PE MAY switch to
   the backup Provider Tunnel only if the backup Provider Tunnel deemed
   available.  The dedicated p2mp BFD session MAY monitor the state of
   the backup Provider Tunnel.

Attached please find diff to highlight the update and the new version of the 
draft.

Kind regards,
Greg
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03

[John E Drake]

Patrice,

I think it is much cleaner to treat the attachment of a set of L2GW PEs to an 
L2 network as a set of individual ESes, one per L2GW PE, as Jorge suggests.  
This is because a remote PE accesses different parts of the L2 network through 
different L2GW PEs;  i.e., to a remote PE the connectivity looks like different 
sets of destinations associated with different ESes.

Yours Irrespectively,

John


> -Original Message-
> From: BESS  On Behalf Of Patrice Brissette
> (pbrisset)
> Sent: Monday, November 5, 2018 7:49 PM
> To: Rabadan, Jorge (Nokia - US/Mountain View)
> ; bess@ietf.org; draft-brissette-bess-evpn-
> l2gw-proto.auth...@ietf.org
> Subject: Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03
> 
> Hi Jorge,
> 
> Please see my comments below ... 
> 
> Regards,
> 
> Patrice Brissette, Principal Engineer
> Cisco Systems
> Help us track your SP SR/EVPN Customer Opportunity/Status by filling these
> forms: Segment Routing  3A__app.smartsheet.com_b_form_185833ace35b4894b324dfb8afbd2060
> =DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0=UkHEfjNPy44C3HNNU8QiEPpRGRJ6_gabZewtSN-cmqQ=> / EVPN
>  3A__app.smartsheet.com_b_form_136bd5c3a22641bf92316523e79d6f22
> =DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0=cwPTHa9AP_hSi_jkXTbFtTcE1lujDqRDYXOaUWuUM7U=>
> 
> 
> 
> On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)"
>  wrote:
> 
> Dear authors,
> 
> Some comments about this draft:
> 
> 1- the draft uses some 'non-standard' terminology. Could you use RFC7432
> terminology please? An example of 'non-standard' term is EVLAG.
>  Will do
> 
> 2- the draft proposes a solution for something that works today without
> the need of a multi-homed Ethernet Segment or any new procedures:
> - There are already EVPN deployments that use STP/G.8032 access rings.
> - The two EVPN PEs that close the ring can participate of the ring 
> protocol,
> therefore the received mac flush messages will withdraw the required
> MAC/IP routes.
> - Since the remote PEs will forward normally based on their MAC FIB
> (populated by MAC/IP routes), there is no need to specify a new "Single Flow
> Active" forwarding mode. This is normal MAC based forwarding. Why do we
> need to create a new mode?? Can you please explain?
> - Besides, by adding a bit in the ESI-label ext community different than 
> the
> single-active bit, you make the solution non-backwards compatible.
> 
>  I'm not sure why you are mentioning the draft is NOT backward
> compatible. You need to explain that one. May I should add "remote PE not
> support single-flow-active bit may ignore this mode"
>  It is true you can support ring using single-homed and you are
> welcome to do so. However, there are important drawbacks. For example,
> how do you achieve ARP and MAC sync?
> 
> 
> 3- Section 6 - why do you define yet another extended community for mac
> flush, when we already have one? (RFC7623)
> 
>  It is true that we can reuse the MAC mobility from RFC7623. Note
> taken
> 
> 4- there is some value in the proposal though - the mass withdrawal (per-
> BD or per-ES) as opposed to per-MAC withdrawal may speed up
> convergence. Here is an alternative solution that can achieve the same thing
> and it's backwards compatible with RFC7432:
> 
> On the L2GWs:
> a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be auto-
> derived easily as type 3/4 and be made unique in the network.
> b) Since the ES is defined in a single PE, the ES routes will be filtered 
> by the
> RR (use RTC) and won't ever reach other PEs. Alternatively you can disable
> the ES routes.
> c) This L2GW ES will be single-active mode (although it does not matter
> much).
> d) Since the ES is not shared across the L2GWs, each L2GW will always be
> DF for all the local VLANs.
> e) Each L2GW will send AD per-ES and per-EVI routes for its ESI.
> f) When the L2GW receives a mac-flush notification (STP TCN, G.8032
> mac-flush, TLDP MAC withdrawal etc.), the L2GW sends an update of the AD
> per-EVI route with the MAC Mobility extended community and a higher
> sequence number - note that we borrow this well-known mac flush
> procedure from RFC7623, only for AD per-EVI routes.
> 
>  As we demonstrated yesterday, there many cases where single-
> active or all-active are simply not working. Relying on single-homed is not
> sufficient even with an ESI. I already gave the example of ARP/MAC sync.
> 
> 
> On the remote PEs:
> g) The MACs will be learned against the ESIs, but there will only be one
> next-hop per ES. No aliasing or no backup. And RFC7432-compatible.
> h) Upon receiving an AD per-EVI update 

Re: [bess] draft-ietf-bess-service-chaining

[Henderickx, Wim (Nokia - BE/Antwerp)]

Stuart thanks, we also support this but wanted to ensure some things that are 
obvious to some people are not for others and hence I believe we have a duty in 
IETF to make people aware about these things. Thx

From: Stuart Mackie 
Date: Tuesday, 6 November 2018 at 19:41
To: "Henderickx, Wim (Nokia - BE/Antwerp)" , 
"draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: draft-ietf-bess-service-chaining

Hi Wim,

Stephane had alerted me to these comments you made a while ago, but which I 
missed at the time. Sorry for the delay in getting back to you.

*   The doc is much focused on the VRF constructions and architecture, but in 
some use cases we need to program the SF, which is not always clear and we 
should be a bit more explicit about it in the draft
SM> Agreed that programming the SF will almost always be required, but there 
isn’t any standard way of doing this. I can add a comment to that effect.
*   If a SF is L2 vs L3 we need to program the static NH and IP@ a bit 
different and we should clarify this
SM> I don’t think there is any difference for L3 routes  between L2 and L3 SFs 
– at a service egress the next hop is the forwarder where the next service is 
running with a label that identifies the ingress interface. There is a 
difference in that the VRF has to add an Ethernet header before sending into an 
L2 SF, which for non-transparent would be that of the ingress SF interface 
(known from when the SF was instantiated). For an L2 transparent service, the 
ingress VRF would put the MAC address of the egress forwarder (which since they 
can all be the same, would be the simplest), and then the egress forwarder 
rewrites the L2 destination if forwarding out of the service chain. I’ll add 
some detail on this.
*   A question I have is if in this architecture a SFF could be shared using 
the same interface/sub-interface with other service chains or not. Based on 
this it would also be good to document the things the SFC architecture allows 
and are supported or not with this proposal.
SM> Sharing can be done for transparent L2 SFs, where VLANs can be used to 
identify which virtual network a packet came from (already supported in 
Contrail), and for L3 SFs could potentially be supported using next-table 
policies in VRFs (similar to floating IP addresses). However, that depends on 
service chains being tied to subnets, which isn’t the scenario that is usually 
discussed in mobility applications where the chosen service chain is based on 
subscriber/application. I can add a couple of sentences on this.

Regards

Stuart
-914 886 2534

From: "Henderickx, Wim (Nokia - BE/Antwerp)" 
Date: Monday, November 5, 2018 at 2:17 AM
To: "draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
Subject: draft-ietf-bess-service-chaining
Resent-From: 
Resent-To: , , , 
, , 
Resent-Date: Monday, November 5, 2018 at 2:17 AM

Attached were my comments which I sent at the time which were not addressed so 
far in the doc.
Would be good if we can incorporate them before WG last call

https://www.ietf.org/mail-archive/web/bess/current/msg00791.html

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-ietf-bess-service-chaining

[Stuart Mackie]

Hi Wim,

Stephane had alerted me to these comments you made a while ago, but which I 
missed at the time. Sorry for the delay in getting back to you.

*   The doc is much focused on the VRF constructions and architecture, but in 
some use cases we need to program the SF, which is not always clear and we 
should be a bit more explicit about it in the draft
SM> Agreed that programming the SF will almost always be required, but there 
isn’t any standard way of doing this. I can add a comment to that effect.
*   If a SF is L2 vs L3 we need to program the static NH and IP@ a bit 
different and we should clarify this
SM> I don’t think there is any difference for L3 routes  between L2 and L3 SFs 
– at a service egress the next hop is the forwarder where the next service is 
running with a label that identifies the ingress interface. There is a 
difference in that the VRF has to add an Ethernet header before sending into an 
L2 SF, which for non-transparent would be that of the ingress SF interface 
(known from when the SF was instantiated). For an L2 transparent service, the 
ingress VRF would put the MAC address of the egress forwarder (which since they 
can all be the same, would be the simplest), and then the egress forwarder 
rewrites the L2 destination if forwarding out of the service chain. I’ll add 
some detail on this.
*   A question I have is if in this architecture a SFF could be shared using 
the same interface/sub-interface with other service chains or not. Based on 
this it would also be good to document the things the SFC architecture allows 
and are supported or not with this proposal.
SM> Sharing can be done for transparent L2 SFs, where VLANs can be used to 
identify which virtual network a packet came from (already supported in 
Contrail), and for L3 SFs could potentially be supported using next-table 
policies in VRFs (similar to floating IP addresses). However, that depends on 
service chains being tied to subnets, which isn’t the scenario that is usually 
discussed in mobility applications where the chosen service chain is based on 
subscriber/application. I can add a couple of sentences on this.

Regards

Stuart
-914 886 2534

From: "Henderickx, Wim (Nokia - BE/Antwerp)" 
Date: Monday, November 5, 2018 at 2:17 AM
To: "draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
Subject: draft-ietf-bess-service-chaining
Resent-From: 
Resent-To: , , , 
, , 
Resent-Date: Monday, November 5, 2018 at 2:17 AM

Attached were my comments which I sent at the time which were not addressed so 
far in the doc.
Would be good if we can incorporate them before WG last call

https://www.ietf.org/mail-archive/web/bess/current/msg00791.html

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Donald,

-Original Message-
From: Donald Eastlake 
Date: Tuesday, November 6, 2018 at 6:59 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org" , 
"draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 

Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01

Hi Jorge,

On Mon, Nov 5, 2018 at 9:12 PM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Donald,
>
> Thank you for this.
> For the second question, I get from your answer that you will keep both 
encapsulations for the time being?

Well, once a draft is posted, it can't be changed, so the currently
posted -01 won't change but the -02 version that is being worked on
and is not yet posted eliminates the alternative encapsulation.

[JORGE] :-) of course. I misunderstood your answer. Sounds good then. Thank you!

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thanks.
> Jorge
>
>
> -Original Message-
> From: Donald Eastlake 
> Date: Monday, November 5, 2018 at 8:48 PM
> To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
> Cc: "bess@ietf.org" , 
"draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 

> Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01
>
> Hi Jorge,
>
> On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
> View)  wrote:
> >
> > Dear authors,
> >
> > I couldn’t make it to the BESS meeting, so my apologies if some of 
these things have been discussed.
> >
> > Some comments/questions:
>
> Thanks for sending comments.
>
> > - In the last IETF, I suggested the use of BGP and the BGP-BFD 
attribute to exchange discriminators, as in section 3.1.6 of 
draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
not in the new version. This would allow the signaling of the discriminators 
along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
etc. without the burden of having to support the EVPN LSP-ping draft.
>
> There is a draft version -02 in the works intended to include
> distribution of BFD discriminators in BGP but this revision was not
> completed to the agreement of the authors in time to posted before
> this meeting.
>
> > - The draft describes an encapsulation and an alternative 
encapsulation. Is the intend to keep both? Wouldn't be better to leave only one 
to ease implementations and interoperability?
>
> Currently, the candidate version -02 draft dispenses with with the
> alternative encapsulation.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  d3e...@gmail.com
>
> > Thank you.
> > Jorge
>
>


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Donald Eastlake]

Hi Jorge,

On Mon, Nov 5, 2018 at 9:12 PM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Donald,
>
> Thank you for this.
> For the second question, I get from your answer that you will keep both 
> encapsulations for the time being?

Well, once a draft is posted, it can't be changed, so the currently
posted -01 won't change but the -02 version that is being worked on
and is not yet posted eliminates the alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thanks.
> Jorge
>
>
> -Original Message-
> From: Donald Eastlake 
> Date: Monday, November 5, 2018 at 8:48 PM
> To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
> Cc: "bess@ietf.org" , 
> "draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 
> 
> Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01
>
> Hi Jorge,
>
> On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
> View)  wrote:
> >
> > Dear authors,
> >
> > I couldn’t make it to the BESS meeting, so my apologies if some of 
> these things have been discussed.
> >
> > Some comments/questions:
>
> Thanks for sending comments.
>
> > - In the last IETF, I suggested the use of BGP and the BGP-BFD 
> attribute to exchange discriminators, as in section 3.1.6 of 
> draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
> not in the new version. This would allow the signaling of the discriminators 
> along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
> etc. without the burden of having to support the EVPN LSP-ping draft.
>
> There is a draft version -02 in the works intended to include
> distribution of BFD discriminators in BGP but this revision was not
> completed to the agreement of the authors in time to posted before
> this meeting.
>
> > - The draft describes an encapsulation and an alternative 
> encapsulation. Is the intend to keep both? Wouldn't be better to leave only 
> one to ease implementations and interoperability?
>
> Currently, the candidate version -02 draft dispenses with with the
> alternative encapsulation.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  d3e...@gmail.com
>
> > Thank you.
> > Jorge
>
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess