Re: [Bier] draft-xie-bier-ipv6-mvpn question:

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

Jingrong,

Please see zzh> below.


Juniper Business Use Only

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]> 
Sent: Thursday, September 10, 2020 3:41 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: draft-xie-bier-ipv6-mvpn question: 

[External Email. Be cautious of content]


Hi Jeffrey,
Appreciate sincerely for raising discussions about the draft.
Please see my response inline below marked with [xjr]

Thanks
Jingrong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Thursday, September 10, 2020 4:36 AM
To: Xiejingrong (Jingrong) <[e-mail]>; BIER WG <[e-mail]>
Subject: draft-xie-bier-ipv6-mvpn question:

Hi Jingrong,

The draft says that the x-PMSI routes carry the following:

   o  Route MUST also carry an BGP Prefix SID attribute with an SRv6 L3
      Service TLV carrying an Src.DTx IPv6 address uniquely identifying
      the MVPN instance.

So this is supposedly to be the counter part of an upstream assigned label - in fact both the context (ingress PE) and upstream label are encoded into the same source address.
[xjr] Yes, very precisely. The source address is very similar to the upstream label and its context.

Section 6.1 talks about encapsulation but does not talk about decapsulation. Supposedly the Src.DTx, instead of destination address is used to identify the VRF table for the next lookup.
[xjr] General consideration is to set this Source-address lookup as default behavior for c-multicast packet decapsulation, and provide some configuration knob to change that.

Since the (Ingress PE, VPN) combination could be huge as described in section 2.1 of draft-ietf-bess-mvpn-evpn-aggregation-label addressed, how is the scaling addressed?
[xjr] Yes, draft-ietf-bess-mvpn-evpn-aggregation-label presents a scaling problem (as below text copied from the document).
   Suppose an MVPN or EVPN deployment has 1001 PEs, each hosting 1000
   VPN/BDs.  Each ingress PE has to assign 1000 labels, and each egress
   PE has to be prepared to interpret 1000 labels from each of the
   ingress PEs.
This scaling problem is common to MVPN/EVPN, and this draft has the same scaling problem too.
One point to mention, some MVPN service may not want a full-meshed MP2MP model, but an asymmetrical P2MP model with small number of "Sender sites" and large number of "Receiver sites" [RFC6513 section 2.3].
This scaling problem can be relieved in such case.

Zzh> While this draft is about MVPN (though you did talk about VNI below), there is no reason to have a different solution for EVPN, in which case every PE could be a BFIR.

Presumably the same concept of "DCB label" can be used - encoded into the function portion of the source address - in that case that should be advertised as part of the label field of PTA, and it must be made clear that only the function portion of the source address is used for lookup, and every PE must agree which part of the addresses is the function portion.
[xjr] Good idea to apply the "DCB label" solution to solve the problem!
To advertise such indication from Ingress PE to Egress PE is a good way to keep alignment between them.
It can also detect possible confliction (for example, Ingress PE support this method but Egress PE doesn't).
Use configuration knob independently on Ingress PE and Egress PE may also be reasonable ?

Zzh> Whether by signaling or by configuration, the key point is that the egress must carve out the same function portion of the source address for lookup. My understanding is that the locater/function/argument portions are not fixed.

Besides, would you think it necessary to extend the "DCB label" to 24bit to cover the VNI length ?

Zzh> This is already covered in RFC8365:

   For
   the balance of this memo, the above MPLS label fields will be
   referred to as the VNI field. The VNI field is used for both local
   and global VNIs, and for either case the entire 24-bit field is used
   to encode the VNI value.

------------------------------

   In case of inter-AS scenario, BIERv6 packets may travel through
   unicast to a Boarder Router (BR), and then replicate in a single
   intra-AS BIERv6 domain.  How such non-segmented BIERv6 scenario can
   be supported is outside the scope of this document.
Can you elaborate the above scenario (BIERv6 packets unicast to BR and then replicated)? Is it a scenario that must be supported?
[xjr] The above scenario is covered in <draft-geng-bier-ipv6-inter-domain>, so it is not covered in this document, as this document mainly focuses on the "BGP-MVPN" protocol extension.
[xjr] It's an optional scenario I think.
Zzh> If you're referring to the "peering" model in that draft, which is very controversy, it's better to not mention it here at all. That entire draft should be adequately discussed before other drafts start referring to it.

   How segmented MVPN, for example, between BIERv6 and BIERv6, or
   between BIERv6 and Ingress Replication(IR) in Non-MPLS IPv6 networks,
   is outside the scope of this document.
When/where would the above two scenarios (non-segmented and segmented) be covered?

[xjr] A simple non-segmented inter-AS consideration (using some configuration for inter-AS BIFT construction) is covered in <draft-geng-bier-ipv6-inter-domain>.
Seems to me that there is no much "BGP-MVPN" protocol extension needed for non-segmented MVPN, and the main challenge is the underlay inter-AS BIFT construction.

Zzh> I agree the BIFT construction is not the concern of this document - whether segmentation is used or not - and we don't even need to list BIFT construction as "out of scope" (this is referring to the non-segmentation case earlier).

<draft-zzhang-bier-multicast-as-a-service-01> is an example using BGP for inter-AS BIER information advertisement and BIFT construction for non-segmented inter-AS deployment.
[xjr] Haven't considered segmented MVPN in detail yet, Will come back if I have any further thoughts.
Zzh> So the segmentation is not "out of the scope" (otherwise there is no complete solution) - it should be "for further study" or "provided in future revisions".
Zzh> Thanks.
Zzh> Jeffrey

Thanks.
Jeffrey

Juniper Business Use Only