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

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

Hi Jingrong,

Please see zzh> below.

> -----Original Message-----
> From: Xiejingrong <[e-mail]>
> Sent: Saturday, October 27, 2018 8:59 AM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]
> Subject: RE: New Version Notification for draft-xie-bier-mvpn-segmented-
> 06.txt
> 
> 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).

Zzh> Good that they already talked about it. It's clear that it is not a BIER specific issue (and equally applies to EVPN). Instead of writing a documents for every tunnel type, we can generalize it (see my summary in the previous email) - in fact, in this draft-xie-bier-mvpn-segmented there is really no BIER specific things (BIER encapsulation/decapsulation is no different from label push/pop that is used with IR).

> 
> 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.

Zzh> By forwarding state I was more referring to the "route -> nexthop" entries. You need an extra entry for each flow. The Bitstring info is part of the "nexthop".

> 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.

Zzh> That's another example of "generalization": BIER tunnel is no different from other tunnels.

> 
>    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]."

In this context, the GTM procedures in RFC7524 is basically triggering S-PMSI route based on received Leaf route. It applies to BIER as well, and can actually be applied to VRF. Yet another case of generalization.

> 
> [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.

I don't see why this is a concern in this context. If you care about the following:

   If a BFIR is compromised, it may impose a BIER encapsulation with all
   the bits in the BitString set; this would also result in a DoS
   attack.

It is applicable w/ or w/o segmentation.

Jeffrey

> 
>    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=