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

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

Hi Jingrong,

Sorry for the late response. Yes I think we’re converging more. In fact this applies equally to EVPN BUM as well.

Let me get back to this towards the end of the month - it’s been a bit hectic recently.

Jeffrey

Sent from my iPhone

On Nov 12, 2018, at 9:47 PM, Xiejingrong <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jeffrey,

I think we are converging on IP-lookup as an opinion to the operator, and the issue of this document is not technological.

Thanks for the through discussion and clarification.

We are very grateful if you can put together all these more generalized points, either you have pointed out or have not pointed out here.

Jingrong


From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Friday, November 09, 2018 12:39 PM
To: Xiejingrong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: New Version Notification for draft-xie-bier-mvpn-segmented-06.txt

Hi Jingrong,

Whether IP lookup is desired or not at the segmentation point can be argued and is up to the operator; the real issue of this document is that the problem and solution are not BIER specific so it should belong to BESS.

I’ve already given a few points on how to generalize it. I can help further by putting up a skeleton draft based on those points if you want.

Jeffrey

From: Xiejingrong <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 8, 2018 6:50 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: New Version Notification for draft-xie-bier-mvpn-segmented-06.txt


BIERers,

I missed some words on the left bier mic again.
the clear terms of bier tunnel and per flow explicit tracking is very important to decouple. think about that how to support CORE network using an IPMSI and one of METRO network using BIER, will you force the CORE to use per flow per tunnel? just think about that, without any juice. the current bier-mvpn is wrong to force a mapping of flow to a vpn label. it is definitely crazy to me. we can miss the very obvious decoupling of per tunnel and per flow.

don't be trapped into the pros cons 40/60 or 60/40 again. think about that. the very obvious scenario. the very direct feeling. the architecture of de coupling different things. think about that deeply.

--------------------------------------------------
Sent From WeLink
From:Jeffrey (Zhaohui) Zhang
To:Xiejingrong,[e-mail]<mailto:[e-mail]>,
Date:2018-11-08 11:21:18
Subject:RE: New Version Notification for draft-xie-bier-mvpn-segmented-06.txt

Hi Jingrong,

Please see zzh> below.

> -----Original Message-----
> From: Xiejingrong <[e-mail]<mailto:[e-mail]>>
> Sent: Saturday, October 27, 2018 8:59 AM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Xiejingrong
> > Sent: Tuesday, October 23, 2018 9:58 PM
> > To: [e-mail]<mailto:[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]<mailto:[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=