[bess] IETF 109, call for slots

[Mankamana Mishra (mankamis)]

All,
Final agenda for IETF 109 is sent, please send me slot request if you want any. 
 We would be meeting on Thursday of IETF week.

https://datatracker.ietf.org/meeting/109/agenda.html


16:00-18:00
Thursday Session III
Room 5
rtg
bess
BGP Enabled ServiceS



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

[bess] bess - Requested session has been scheduled for IETF 109

["IETF Secretariat"]

Dear Mankamana Mishra,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


bess Session 1 (2:00 requested)
Thursday, 19 November 2020, Session III 1600-1800
Room Name: Room 5 size: 505
-


iCalendar: https://datatracker.ietf.org/meeting/109/sessions/bess.ics

Request Information:


-
Working Group Name: BGP Enabled ServiceS
Area Name: Routing Area
Session Requester: Mankamana Mishra


Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 Chair Conflict: idr nvo3
 Technology Overlap: spring sfc mpls pim bier pals
 Key Participant Conflict: i2rs





People who must be present:
  Matthew Bocci
  Martin Vigoureux
  Stephane Litkowski
  Mankamana Prasad Mishra

Resources Requested:

Special Requests:
  
-


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

[bess] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11

[Daniel Migault via Datatracker]

Reviewer: Daniel Migault
Review result: Has Nits

Hi, 


I reviewed this document as part of the Security Directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These comments were
written primarily for the benefit of the Security Area Directors.  Document
authors, document editors, and WG chairs should treat these comments just like
any other IETF Last Call comments.  Please note also that my expertise in BGP is
limited, so feel free to take these comments with a pitch of salt.  

Review Results: Has Nits

Please find my comments below. 

Yours, 
Daniel


  Multicast VPN Fast Upstream Failover
 draft-ietf-bess-mvpn-fast-failover-11

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.


Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer. 




1.  Introduction

   In the context of multicast in BGP/MPLS VPNs, it is desirable to
   provide mechanisms allowing fast recovery of connectivity on
   different types of failures.  This document addresses failures of
   elements in the provider network that are upstream of PEs connected
   to VPN sites with receivers.


Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.  My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.  Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled. 



   Section 3 describes local procedures allowing an egress PE (a PE
   connected to a receiver site) to take into account the status of
   P-tunnels to determine the Upstream Multicast Hop (UMH) for a given
   (C-S, C-G).  This method does not provide a "fast failover" solution

I understand the limitation is due to
BGP convergence. 


   when used alone, but can be used together with the mechanism
   described in Section 4 for a "fast failover" solution.

   Section 4 describes protocol extensions that can speed up failover by
   not requiring any multicast VPN routing message exchange at recovery
   time.

   Moreover, section 5 describes a "hot leaf standby" mechanism, that
   uses a combination of these two mechanisms.  This approach has
   similarities with the solution described in [RFC7431] to improve
   failover times when PIM routing is used in a network given some
   topology and metric constraints.


[...]

3.1.1.  mVPN Tunnel Root Tracking

   A condition to consider that the status of a P-tunnel is up is that
   the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
   is reachable through unicast routing tables.  In this case, the
   downstream PE can immediately update its UMH when the reachability
   condition changes.

   That is similar to BGP next-hop tracking for VPN routes, except that
   the address considered is not the BGP next-hop address, but the root
   address in the x-PMSI Tunnel attribute.

   If BGP next-hop tracking is done for VPN routes and the root address
   of a given tunnel happens to be the same as the next-hop address in
   the BGP A-D Route advertising the tunnel, then checking, in unicast
   routing tables, whether the tunnel root is reachable, will be
   unnecessary duplication and thus will not bring any specific benefit.


It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.  I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down. 



[...]

3.1.6.  BFD Discriminator Attribute

   P-tunnel status may be derived from the status of a multipoint BFD
   session [RFC8562] whose discriminator is advertised along with an
   x-PMSI A-D Route.

   This document defines the format and ways of using a new BGP