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

[Xiejingrong <[e-mail]>]

Hi Jeffrey,

Thank you very much for the helpful comments. 
There are some very interesting topic I want to discuss with you BIER men.
See my opinions inline below marked with [XJR].

Jingrong.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]] 
Sent: Thursday, October 25, 2018 10:07 PM
To: Xiejingrong <[e-mail]>; [e-mail]
Subject: RE: New Version Notification for draft-xie-bier-mvpn-segmented-06.txt

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.

[XJR]: IP lookup for {ingress replication + GTM case} has been described in RFC7988/RFC7524 ('IP processing' in there), so this draft is BIER specific case. Moreover, this draft is an update of <draft-ietf-bier-mvpn>, which uses Label lookup and LIR explicit-tracking for segmented mvpn, and mainly focus on BIER-BIER segmented MVPN ( I think). 

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
[XJR]: Thanks for the remind of more generic points. Maybe we can borrow some very useful words from the RFC7988/7524. For example, [The procedures for such disaggregation require IP processing on the ingress ABRs] from RFC7524 is very suitable for BIER too, which need a disaggregation (through BIER encapsulation for per-flow) further from a per-tunnel/un-optimized BIER tunnel. Also this can make the whole BIER/MLDP/RSVP/IR for MVPN/GTM consolidate. 


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:
[XJR]: Again thanks for the remind on the emphasis the comparison of IP lookup and Label lookup. I think the 'forwarding cycles', 'the FIB size', is the significant thing need to be mentioned. And make the 'pros and cons' more clear.
For the 'forwarding state', one example maybe from N to N+1 in number. For example, in BIER-BIER segmented case, or IPMSI P2MP-BIER segmented case, or BIER-IPMSI P2MP segmented case, the IP lookup will need one 'forwarding state' of Label (to find the PseudoVRF), and N 'forwarding state' of per-flow IP (to find the BitString).
In some other cases, maybe from N to N+M.
In the worst cases, maybe from N to N+N. 
So again, words from RFC7524 is very suitable for this: "if the ingress area uses wildcard S-PMSI, then the backbone area also SHOULD use wildcard S-PMSI for global table multicast, or the ingress ABRs MUST be able to disaggregate traffic carried over the wildcard S-PMSI onto the backbone area (S,G) or (*,G) S-PMSIs."
So the same is suitable for BIER case: if ingress area use P2MP wildcard S-PMSI, and egress area use BIER, and the user want to leverage the BIER without flooding, then ABRs MUST do IP lookup.

   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.
[XJR]: We use the word *may* to say this is a possible case. We have considered the possibility of C-multicast routes triggered, or any (S,G) state triggered S-PMSI route. 
Thank you again for the introducing of another case. 
The RFC7988 is also a big help to understand. "Note that joining an unadvertised IR P-tunnel is only possible when using the "global table multicast" procedures of [RFC7524]."

[XJR]: Running BIER on a 'I-PMSI' manner w/o IP lookup is a good topic I want to discuss.
I found a word 'compromised' in the Security section of RFC8279. Do we want to do such a 'compromise' for a BIER deployment ? 
I prefer personally not to use a 'compromised' manner for BIER from the impl side, and I would like to call this an 'S-PMSI only' replication, but unfortunately the 'S-PMSI only' has been used by RFC6625 for control-plane.
I'd like very much to learn more about your opinions from the BIER WG. @ALL.

   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.
[XJR]: This consolidation is useful to say that, an IP lookup following an upstream VpnLabel lookup is not an *new* requirement of implementation (especially in data-plane). I am happy to change the word too.

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=