Re: [Bier] New Version Notification for draft-xie-bier-mvpn-segmented-06.txt

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jingrong,

Please see my comments below.

A general comment is that this problem is not specific to BIER. Even if it's just ingress replication, we'd also need IP lookup if we're not using per-flow labels for segmentation points to do label switching. The only difference between BIER and IR is that IR does not require S-PMSI routes (as the label can be carried in auto-triggered Leaf AD routes); If it's P2MP tunnels, we also need S-PMSI route to advertise per-PMSI labels unless we do IP lookup.

Therefore, I don't think this solution should be targeted at BIER. A simple BESS document could be written, covering the following generic points:

- The labels in I-PMSI routes could lead to label switching into next segment, or could lead to IP lookup in a local VRF. This is purely a local decision based on whether you want to do ip lookup or not.
- The labels in S-PMSI routes (if those routes are sent), if different from the label in a corresponding I-PMSI, lead to label switching into next segment. 
- Leaf A-D routes trigger corresponding (s/*,g) routes in VRFs, if ip lookup is desired/required
- Upstream PE/ABR uses the label advertised in the matching x-PMSI routes (BIER/P2MP) or Leaf AD routes (IR) to send traffic
 
As I pointed out before, doing IP lookup is not really better than per-flow/PMSI based label switching with respect to FIB size and forwarding performance. To do IP lookup you need to maintain (s,g) routes in different VRFs (for comparison you only need labels in the default/master instance if you do label switching). One can argue that this is actually less efficient - you need to first do a label lookup to determine the VRF, and then do an IP lookup. Using IP lookup requires more forwarding state, and more forwarding cycles; the only saving you get is the elimination of control plane S-PMSI routes that distribute per-flow labels (and the corresponding delay). If that is super important, sure you can do IP lookup but the following text should be updated to point out pros and cons:

   In conclusion, the pattern of forwarding packets on segmentation
   points only by lookup of MPLS label mapped from multicast flow(s) is
   significantly unnecessary when BIER is introduced.  Instead, doing a
   per-flow lookup of IP header on segmentation points is more efficient
   and consolidated.

Comments about some specific text:

   o  Getting a much better multicast join latency by eliminating the
      round trip interaction of S-PMSI AD routes and Leaf AD routes.
      Especially, the S-PMSI A-D routes may need a data-driven procedure
      to trigger, and make the multicast join latency even worse.

The S-PMSI routes could be triggered by leaf A-D routes (section 7.2.2.1 RFC 7524) instead of data driven.
Additionally, a way to reduce latency w/o requiring ip lookup is to use I-PMSI initially for a short period of time.

   o  Consolidated forwarding procedure of IP lookup for every BIER
      Overlay functioning routers, such as BFIR, BFER, segmentation
      point BFR, and segmentation point BFR with BFER function.

This consolidation is not really necessary. Indeed an implementation likely will support both label switching and ip lookup, but it does not mean ip lookup is the preferred way on a segmentation point.

Jeffrey

> -----Original Message-----
> From: BIER <[e-mail]> On Behalf Of Xiejingrong
> Sent: Tuesday, October 23, 2018 9:58 PM
> To: [e-mail]
> Subject: Re: [Bier] New Version Notification for draft-xie-bier-mvpn-
> segmented-06.txt
> 
> Hi BIER WG,
> 
> This draft was updated greatly in the past days, and I feel it is clear now.
> It is a little long, so a discussion on mic may be not enough if it is not read
> through.
> Welcome very much for your feedback/inputs on this on the maillist.
> Thank you very much.
> 
> My log about this draft:
> ---- the term 'BIER tunnel', 'P2MP tunnel' and 'BGP-MVPN FEC'.
> ---- tunnel sticking can be between any two of mLDP/RSVP-TE/IR/BIER.
> ---- e2e sticked tunnel can be bound to one or many 'BGP-MVPN FEC(s)' from
> some IngressPE and VRF, and Ingress PE can decide to use which sticked tunnel
> for which flow(s).
> ---- the per-tunnel sticking of upstream tunnel and downstream tunnels, and
> the per-flow IP lookup for downstream BIER encapsulation (BitString), are
> separated/decoupled.
> 
> Jingrong
> 
> -----Original Message-----
> A new version of I-D, draft-xie-bier-mvpn-segmented-06.txt
> has been successfully submitted by Jingrong Xie and posted to the IETF
> repository.
> 
> Name:		draft-xie-bier-mvpn-segmented
> Revision:	06
> Title:		Segmented MVPN Using IP Lookup for BIER
> Document date:	2018-10-22
> Group:		Individual Submission
> Pages:		17
> URL:            https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dxie-2Dbier-2Dmvpn-
> 2Dsegmented-2D06.txt&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=aL92z5vmARBlhRcqrvU6Kwz1q5z4TsFK8qNHRyai1lc&s=_u1HyrykoE799w1
> pjHLMlVFl39BqS3QcSI2ifj15WEM&e=
> Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dxie-2Dbier-2Dmvpn-
> 2Dsegmented_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=aL92z5vmARBlhRcqrvU6Kwz1q5z4TsFK8qNHRyai1lc&s=PEN0sOb4ROpfTJ9-
> rRPuBOViEjS2v3mCvXkttYALG4o&e=
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dxie-2Dbier-2Dmvpn-2Dsegmented-
> 2D06&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=aL92z5vmARBlhRcqrvU6Kwz1q5z4TsFK8qNHRyai1lc&s=lCVRhdEuZwZXblwJ
> mBdPKkH4GIQM4PDVRRuIiKw4Ju8&e=
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dxie-2Dbier-2Dmvpn-
> 2Dsegmented&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=aL92z5vmARBlhRcqrvU6Kwz1q5z4TsFK8qNHRyai1lc&s=gbhCl0sGTUhaL2qG
> 9dKQnIqdjbHDWbhqrxfYGwitON4&e=
> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dxie-2Dbier-2Dmvpn-
> 2Dsegmented-2D06&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=aL92z5vmARBlhRcqrvU6Kwz1q5z4TsFK8qNHRyai1lc&s=miQxM2C8rvh6wm
> qVNaxpqPO6yjgfVTjFmfkPZdT4-go&e=
> 
> Abstract:
>    This document specifies an alternative of the control plane and data
>    plane procedures that allow segmented MVPN using the more efficient
>    LIR-pF explicit-tracking when BIER is used as the upstream or
>    downstream or both segments.  It requires a segmentation point BFR
>    doing an IP header lookup, which is common for the forwarding
>    procedure on BFER, or the forwarding procedure on ABR with local VPN
>    CEs connected.  This document updates [I-D.ietf-bier-mvpn].
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=HAkYuh63rsuhr6Scbf
> h0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=aL92z5vmARBlhRcqrvU6Kwz1q5z4TsFK8qNHRyai1lc&s=AdJYxmU8rM5KwV
> pemxMtSZVaPU4ryXOePtnaqFuO7dw&e=