Subject: [Bier] FYI==>//RE: New Version Notification for draft-xie-bier-mvpn-mpls-p2mp-01.txt

From: Xiejingrong <[email-masked]>
Date: Wed, 21 Mar 2018 20:07:32 +0000

Hi BIER'ers,

I really mess up the presentation for this draft  in the IETF101 meeting this afternoon when I lost in  the pater text I had prepared. It may be  possible to receive a tweeter message "you are filed" tomorrow, so I post the 7 minutes paper text for the presentation slides (https://datatracker.ietf.org/doc/slides-101-bier-bier-mvpn-p2mp/) this evening, hoping the lost text in the meeting can  be found here.

Page2:
This page shows what's the problems of BIER transition.
Currently BIER offers a way of packet replication along unicast paths, and one of its benefit is fast convergence. 
However, when talking to some Service-Providers, they have two different concerns: Fast or even lossless switchover like Live-Live protection, and deployment on existing network with few upgrade of HardWare as possible.

Page3:
So the first problem is, <bier-mvpn> draft deliver a solution of MVPN using IGP BIER, on a generic many-to-many topology, and multicast replication is  along  with unicast path. However it can't support a multicast-specific path well, something common in  legacy ng-MVPN deployment.

Page4:
The second problem is, <bier-arch> RFC deliver a solution to support incapable Mid nodes. However it can't support deployment on a network with incapable Edge nodes, something common in legacy network. Two examples, the first is a Hub-spoken topology in Metro Network, and the second is a  Ring topology in backhaul network.

Page5: 
The  two problems seem to be well-known. We can see that many people have been concerning about them.

Page6:
So what's the alternatives  to the two problems?
For the  1st problem of  two disjoint trees, we may want to compute paths by some algorithm, and then what to do ? Just computing or Just build it ? This  draft is determined to just build it.
For the 2nd problem of incapable Edge nodes, are there any alternatives ? I haven't seen any, but this draft introduce some.

Page7:
This draft introduces 3 points for BIER transition.
The 1st one is a seamless transition mechanism from legacy ng-MVPN, by applying BIER-encapsulation in data-plane, while preserving  existing tree-building protocols.
The 2nd one is a seamless Live-Live protection, by re-using the pre-flow Entropy field as a per-flow sequence-number.
The 3rd one is a seamless deployment on networks with incapable Edge  nodes. This  is a result of deep exploring of BIER forwarding on a tree. This is  mentioned in <bier-arch> RFC but not explored. It can also support incapable Mid nodes, without using Ingress Replication, and without overloading a  single link.

Page 8:
This is whole picture. The most significant step is step 0, to use mLDP/RSVP-TE to build a tree with BIER information.
This is an underlay procedure, so mLDP/RSVP-TE are protocols for building BIER information, as well as for building the tree.

Page 9:
Then come to the data-plane. The packet is imposed with a  standard BIER MPLS encapsulation. 
The BIER-Label is a P2MP-label as well. And it will change hop-by-hop when forwarding.
The  BitString inside in packet will not change hop-by-hop when forwarding.
This will bring some extra simplification in data-plane, and lead to a better ability to handle incapable nodes ! [I lost here completely]

Page 10:
The underlay protocols for P2MP BIER include mLDP/RSVP-TE/PIM. To highlight, they all need configuration on edge only. And any of the protocols can go and run an errand to build the tree with BIER information.

Page 11:
Summary: 2 problems, 3 seamless points. In a word: combining BIER with P2MP, or run BIER on a tree!
The philosophy is simple: if you want any of the disjoint trees, then just build it !
And  the target scenario is BIER transition from ng-MVPN in brown-field deployment.
And the focus question since IETF100 is, it is a simplification or complication by introducing tree into BIER ?
In my opinion, from the view of BIER transition, it is a simplification to introduce tree into BIER.
Because if something important lost, like Live-Live, or some more complicate things are required, like HW upgrade or extra configuration, then it is backward and complicate to deploy.

Page 12:
In this page some common comments are listed. If any of them hit you, please point it out.

Something extra prepared for Q&A:
Comparing to ng-MVPN, the draft removes the per-flow states by using the standard BIER-encapsulation in data-plane. It will also have a better join latency without per-flow tree-building procedure.
We have talked to some SPs, they don't mind  some limited tree states. They pay more attention to the increasing benefits without many hardware update, or existing feature lose.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2018 12:39 PM
To: Mach Chen <[email-masked]>; Xiejingrong <[email-masked]>; Mike McBride <[email-masked]>; Liang Geng <[email-masked]>; 4c 67 <[email-masked]>
Subject: New Version Notification for draft-xie-bier-mvpn-mpls-p2mp-01.txt

A new version of I-D, draft-xie-bier-mvpn-mpls-p2mp-01.txt
has been successfully submitted by Jingrong Xie and posted to the IETF repository.

Name:		draft-xie-bier-mvpn-mpls-p2mp
Revision:	01
Title:		Multicast VPN Using MPLS P2MP and BIER
Document date:	2018-03-05
Group:		Individual Submission
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-xie-bier-mvpn-mpls-p2mp-01.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-bier-mvpn-mpls-p2mp/
Htmlized:       https://tools.ietf.org/html/draft-xie-bier-mvpn-mpls-p2mp-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-bier-mvpn-mpls-p2mp-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-xie-bier-mvpn-mpls-p2mp-01

Abstract:
   The MVPN specifications allow the use of several different kinds of
   P-tunnel technology, such as mLDP P2MP, RSVP-TE P2MP and PIM SSM.  It
   is common for such a P-tunnel having a multicast-specific path.  Bit
   Index Explicit Replication (BIER) is an architecture that provides
   optimal multicast forwarding without requiring intermediate routers
   to maintain any per-flow state by using a multicast-specific BIER
   header.

   [I-D.ietf-bier-mvpn] delivers a solution of MVPN using SPF based BIER
   defined in [RFC8279].  It can not, however, support a multicast-
   specific path well, something common in legacy MVPN deployment.
   [RFC8279] provides a solution to support mid nodes without BIER-
   capability.  It can not, however, support deployment on a network
   that has edge nodes without BIER-capability, which is common in some
   SP-networks.

   This document introduces a seamless transition mechanism from legacy
   MVPN to MVPN using P2MP based BIER while preserving existing features
   such as multicast-specific PATH and Live-Live protection.  It also
   introduces a seamless Live-Live protection mechanism by re-using the
   Entropy field of the BIER header, and two methods to deploy BIER when
   edge nodes and/or mid nodes don't have BIER-capability.

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