Subject: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Jul 2019 12:37:06 -0700

Please send agenda items with title, draft, speaker name, and requested
time to this thread.

Thanks,
Shep
(chairs)

---

From: Chonggang Wang <[email-masked]>
Date: Mon, 8 Jul 2019 20:31:13 +0000

Dear Chairs,

On behalf of the authors, we would like to request a time slot to present the following I-D, where the use cases have been expanded according to the comments received from IETF 104.

Title: Applicability of BIER Multicast Overlay for Adaptive Streaming Services

Draft: draft-ietf-bier-multicast-http-response-01

Speaker Name:  Dirk Trossen

Requested Time: 10 minutes

Thanks,

CG

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Monday, July 8, 2019 3:37 PM
To: BIER WG <[email-masked]>
Subject: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Please send agenda items with title, draft, speaker name, and requested time to this thread.

Thanks,
Shep
(chairs)

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 14:04:53 -0700

Hi Greg and Tony,
in his AD review of draft-ietf-bier-pmmm-oam, Alvaro had asked questions
that require WG consideration. I'll be glad to prepare slides. Would you
prefer it to be a separate presentation or part of WG Status update?

Regards,
Greg

On Mon, Jul 8, 2019 at 12:37 PM Greg Shepherd <[email-masked]> wrote:

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Jul 2019 14:23:35 -0700

Let's make it a slot. 10min?

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 14:37:12 -0700

Works for me.

Regards,
Greg

---

From: Xiejingrong <[email-masked]>
Date: Tue, 9 Jul 2019 01:29:58 +0000

We’d like to request 35-40 minutes for the presentation of the following BIERv6 drafts.  I will be the speaker (may have some adjustment before the session).

BIERv6 Encapsulation  //  draft-xie-bier-ipv6-encapsulation-02, 15min
BIERv6 via IS-IS  //  draft-xie-bier-ipv6-isis-extension-00  10min
MVPN using BIERv6  //  draft-xie-bier-ipv6-mvpn-01            5min
Inter-domain Multicast Deployment using BIERv6  //  draft-geng-bier-ipv6-inter-domain-00  10min

Thanks
Jingrong on behalf of the authors

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Tuesday, July 09, 2019 3:37 AM
To: BIER WG <[email-masked]>
Subject: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Thanks,
Shep
(chairs)

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Jul 2019 02:44:02 +0000

Adding the WG, Sorry hit reply only

Regards

Hooman

From: Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Monday, July 8, 2019 3:54 PM
To: [email-masked]
Subject: RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hello

10 min for mldp signaling over bier new version of it with tLDP.

Also where are we with the last call on bier-pim-signaling? I have not got any more comments and did not see a last call on it.

Regards

Hooman

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Shepherd
Sent: Monday, July 8, 2019 3:37 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Thanks,
Shep
(chairs)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Jul 2019 10:14:42 -0700

Hi

I would like 10 minutes for draft-ietf-bier-mld-02.txt. Presenter is myself.

My opinion previously was that this was ready for WGLC, and I think
that was the agreement the last meeting. However, I would like to
discuss one issue and potential change to the draft.

Thanks,
Stig

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 12 Jul 2019 08:41:00 -0700

Jingrong,

This is a significant amount of IPv6 content to present when we're still
discussing the new use-cases draft from last meeting. Let's get the
use-cases draft on the agenda with adequate discussion time. If interest
and time allow, we can dig into each of these as applicable. If we have
enough time we can hit them all, I just want to focus the discussion from
where we left off in Prague.

Any opinions from the WG?

Shep

On Mon, Jul 8, 2019 at 6:32 PM Xiejingrong <[email-masked]> wrote:

> We’d like to request 35-40 minutes for the presentation of the following
> BIERv6 drafts.  I will be the speaker (may have some adjustment before the
> session).
>
>
>
> Inter-domain Multicast Deployment using BIERv6  //
> draft-geng-bier-ipv6-inter-domain-00  10min
>
>
>
> Thanks
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Greg Shepherd
> *Sent:* Tuesday, July 09, 2019 3:37 AM
> *To:* BIER WG <[email-masked]>
> *Subject:* [Bier] BIER WG, Call For Agenda, Montreal IETF 105
>
>
>

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 12 Jul 2019 08:43:09 -0700

Right. And it's in my queue. I chose to leak out 2 at a time to not
overwhelm the WG. The results were the same - very little responders.. So
we're going to address this in the WG. We nee engagement, and we need doc
Shepherds to step up ASAP.

Thanks,
Shep
(Chairs)

On Wed, Jul 10, 2019 at 10:14 AM Stig Venaas <[email-masked]> wrote:

> > Also where are we with the last call on bier-pim-signaling? I have not
> got any more comments and did not see a last call on it.
> >
> >
> >
> > Regards
> >
> >
> >
> > Hooman
> >
> >
> >
> >
> >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 12 Jul 2019 20:53:10 +0000

Hi Jingrong, Liang,

I have some questions and comments on two of the drafts.

draft-xie-bier-ipv6-encapsulation-02

-       Use of BIER multicast address FF0X::AB37 does not seem right to me. For example, on a LAN you can’t multicast BIER packets to multiple downstream BFRs – individual copies (with different BitString) must be unicast to those downstream BFRs.
-       Assuming that we agree that a unicast DA address must be used. What’s the rational of “Source Address field in the IPv6 header MUST be a routable IPv6 unicast address of the BFIR in any case”? Since the IPv6 header is only the outer encapsulation to get a packet from BFR1 to BFR2, why would you want to put the BFIR’s address in the outer encapsulation? If you could make both SA/DA of the IPv6 header to be the original SA/DA of the payload it may make some sense, but obviously you can’t do that.
-       With the above, I don’t see a real difference between this proposal and draft-zhang-bier-bierin6-03 – it’s just whether the BIER header is in the destination option or in the “payload” part of the IPv6 packet. Can you explain the pros and cons of two?

draft-geng-bier-ipv6-inter-domain-00

-       Can you elaborate the following?
   Note: Use of the IPv6 address configured on PE1 to identify an MVPN
   instance can eliminate the need for BFR-id configuration on PE1x,
   which otherwise has to be configured from the space of a sub-domain.
-       For the “peering multicast”, how many BIER sub-domain do you have?
-       What’s the real difference between “hierarchical multicast” and “peering multicast”, once you take away the color and MVPN aspects that I believe are orthogonal here?
-       What’s the significance of “inter-domain” here, that requires this new draft?
-       What’s the uniqueness of IPv6 here?

Thanks!
Jeffrey

From: BIER <[email-masked]> On Behalf Of Xiejingrong
Sent: Monday, July 8, 2019 9:30 PM
To: [email-masked]; BIER WG <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Thanks

Thanks,
Shep
(chairs)

Juniper Business Use Only

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 00:24:27 +0000

Hi Greg,

That's good to put the bierv6-requirements draft in the agenda. thank you!
I assume Mike will present this draft but didn't see his shown so far in the list. I can be backup of this draft presentation anyway.

But can you please put the bierv6 drafts in the agenda ? Otherwise they may lose chance to discuss  even there is still time.

Also I remember from the past discussion that, it may be time to talk about both the requirements and the proposals as Toerless said. Otherwise there may be a perfect requirement draft without the right solution .

Thanks
Jingrong
发件人：Greg Shepherd <[email-masked]>
收件人：Xiejingrong <[email-masked]>
抄 送：BIER WG <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-07-12 23:41:19
主 题：Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Jingrong,

This is a significant amount of IPv6 content to present when we're still discussing the new use-cases draft from last meeting. Let's get the use-cases draft on the agenda with adequate discussion time. If interest and time allow, we can dig into each of these as applicable. If we have enough time we can hit them all, I just want to focus the discussion from where we left off in Prague.

Shep

On Mon, Jul 8, 2019 at 6:32 PM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:
We’d like to request 35-40 minutes for the presentation of the following BIERv6 drafts.  I will be the speaker (may have some adjustment before the session).

Thanks

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Shepherd
Sent: Tuesday, July 09, 2019 3:37 AM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Thanks,
Shep
(chairs)

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 01:23:34 +0000

Thanks for the comments very much.
Meanful and helpful.
Please see my comments in line below.
发件人：Jeffrey (Zhaohui) Zhang <[email-masked]>
收件人：Xiejingrong <[email-masked]>;[email-masked] <[email-masked]>;BIER WG <[email-masked]>
抄 送：[email-masked]' <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-07-13 04:53:22
主 题：RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hi Jingrong, Liang,

  *   Use of BIER multicast address FF0X::AB37 does not seem right to me. For example, on a LAN you can’t multicast BIER packets to multiple downstream BFRs – individual copies (with different BitString) must be unicast to those downstreamiBIER-MPLSMPLS domain domain segmented
  *   a nnI PP[XJR] Absolutely! The use of multicast DA can't support some very common usecases that may be assumed as Architecture of BIER. I agree with you to assume using a unicast DA. I will update the draft this way in next version.
  *
  *   Assuming that we agree that a unicast DA address must be used. What’s the rational of “Source Address field in the IPv6 header MUST be a routable IPv6 unicast address of the BFIR in any case”? Since the IPv6 header is only the outer encapsulation to get a packet from BFR1 to BFR2, why would you want to put the BFIR’s address in the outer encapsulation? If you could make both SA/DA of the IPv6 header to be the original SA/DA of the payload it may make some sense, but obviously you can’t do that.
  *   [XJR] Yes, use of the address of the BFIR and keep it unchange when a packet fly through the BFRs is a key of the proposal. I think there is already examples of Source rooting that keep the source address unchange while change the DA in the fly. I would understand the BIER technology as a Multicast source routing!
  *
  *   With the above, I don’t see a real difference between this proposal and draft-zhang-bier-bierin6-03 – it’s just whether the BIER header is in the destination option or in the “payload” part of the IPv6 packet. Can you explain the pros and cons of two?
  *   [XJR]  there are more similarities since I (and you may also agree) want to use unicast DA only. but the difference is mainly two: one is use the address of BFIR without change in the fly as above point. one is use of a BIER specific ipv6 address in DA, which preceding any of the possible EHs and assume being the most efficient for fast path and most less impact on exist IPv6 functions.

  *   Can you elaborate the following?

  *   For the “peering multicast”, how many BIER sub-domain do you have?
  *   [XJR] haven't evaluate that so far.I initiate this idea when I found a recent rfc8313 and thought of the tenant spanning multiple DCs. Also I assume the multicast as a service draft for this case.
  *
  *   What’s the real difference between “hierarchical multicast” and “peering multicast”, once you take away the color and MVPN aspects that I believe are orthogonal here?
  *   [XJR] the hierarchical one is a P2MP case like IPTV in service provider. The peering one is an MP2MP case where the multicast source may be more unpredictable.
  *
  *   What’s the significance of “inter-domain” here, that requires this new draft?
  *   [XJR] there is still no inter-domain BIER underlay construction, which I would think comparable to the so called non-segmented mvpn solution. It is the idea in my mind since the first presentation in ietf102 to deploy inter-domain BIER underlay. Also impressed by the points of multicast as a service you proposed.
  *
  *   What’s the uniqueness of IPv6 here?
  *   [XJR] I found it difficult to construct the inter-domain BIFTs since the BIER-MPLS label is dynamic. Use of a static SRGB label as BIER-MPLS of a BR(border router) is waste ful, while use the SRGB for the entire domain seems not welcome in ietf102.
  *   Thanks.
  *   Jingrong.

Thanks!
Jeffrey

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 01:37:46 +0000

Sorry there are some incorrect text inserted in wrong places.
Also I am not sure if the word 'meanful' is correct after I check in the dictionary.
Pls ignore these nits in the mail.
The comments are alright.

Thanks
Jingrong
发件人：Xiejingrong <[email-masked]>
收件人：Jeffrey (Zhaohui) Zhang <[email-masked]>;[email-masked] <[email-masked]>;BIER WG <[email-masked]>
抄 送：[email-masked]' <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-07-13 09:23:35
主 题：RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hi Jingrong, Liang,

  *   Use of BIER multicast address FF0X::AB37 does not seem right to me. For example, on a LAN you can’t multicast BIER packets to multiple downstream BFRs – individual copies (with different BitString) must be unicast to those downstreams.
  *   [XJR] Absolutely! The use of multicast DA can't support some very common usecases that may be assumed as Architecture of BIER. I agree with you to assume using a unicast DA. I will update the draft this way in next version.
  *
  *   Assuming that we agree that a unicast DA address must be used. What’s the rational of “Source Address field in the IPv6 header MUST be a routable IPv6 unicast address of the BFIR in any case”? Since the IPv6 header is only the outer encapsulation to get a packet from BFR1 to BFR2, why would you want to put the BFIR’s address in the outer encapsulation? If you could make both SA/DA of the IPv6 header to be the original SA/DA of the payload it may make some sense, but obviously you can’t do that.
  *   [XJR] Yes, use of the address of the BFIR and keep it unchange when a packet fly through the BFRs is a key of the proposal. I think there is already examples of Source rooting that keep the source address unchange while change the DA in the fly. I would understand the BIER technology as a Multicast source routing!
  *
  *   With the above, I don’t see a real difference between this proposal and draft-zhang-bier-bierin6-03 – it’s just whether the BIER header is in the destination option or in the “payload” part of the IPv6 packet. Can you explain the pros and cons of two?
  *   [XJR] there are more similarities since I (and you may also agree) want to use unicast DA only. but the difference is mainly two: one is use the address of BFIR without change in the fly as above point. one is use of a BIER specific ipv6 address in DA, which preceding any of the possible EHs and assume being the most efficient for fast path and most less impact on exist IPv6 functions.

Thanks!
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 13 Jul 2019 02:32:25 +0000

Hi Jingrong,

Juniper Business Use Only
From: BIER <[email-masked]> On Behalf Of Xiejingrong
Sent: Friday, July 12, 2019 9:38 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Zzh> No worries. I take it you meant “meaningful”. More below.

Thanks
Jingrong
发件人：Xiejingrong <[email-masked]<mailto:[email-masked]>>
收件人：Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;BIER WG <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]' <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>
时间：2019-07-13 09:23:35
主 题：RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Thanks for the comments very much.
Meanful and helpful.
Please see my comments in line below.
发件人：Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
收件人：Xiejingrong <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;BIER WG <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]' <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>
时间：2019-07-13 04:53:22
主 题：RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hi Jingrong, Liang,
I have some questions and comments on two of the drafts.
draft-xie-bier-ipv6-encapsulation-02
·        Use of BIER multicast address FF0X::AB37 does not seem right to me. For example, on a LAN you can’t multicast BIER packets to multiple downstream BFRs – individual copies (with different BitString) must be unicast to those downstreams.
·        [XJR] Absolutely! The use of multicast DA can't support some very common usecases that may be assumed as Architecture of BIER. I agree with you to assume using a unicast DA. I will update the draft this way in next version.
·
·        Assuming that we agree that a unicast DA address must be used. What’s the rational of “Source Address field in the IPv6 header MUST be a routable IPv6 unicast address of the BFIR in any case”? Since the IPv6 header is only the outer encapsulation to get a packet from BFR1 to BFR2, why would you want to put the BFIR’s address in the outer encapsulation? If you could make both SA/DA of the IPv6 header to be the original SA/DA of the payload it may make some sense, but obviously you can’t do that.
·        [XJR] Yes, use of the address of the BFIR and keep it unchange when a packet fly through the BFRs is a key of the proposal. I think there is already examples of Source rooting that keep the source address unchange while change the DA in the fly. I would understand the BIER technology as a Multicast source routing!
Zzh> First of all, BIER is not source routing, even though BIER is the best multicast solution for SR because it does not have per-flow/tunnel/tree state in the core (yet BIER is independent of SR). Source routing means the source (router) determines the path of the packets. BIER is not like that. The BitString only specifies the set of BFERs.
Zzh> As I pointed out, the IPv6 header is only to get the packet from BFR1 (vs. BFIR) to BFR2 (whether they’re directly connected or not) – one-hop or multi-hop tunneling, so it makes sense to use the BFR1’s address as SA.
Zzh> Having said that, if you could convince everyone that the BFIR’s address should be used, then draft-zhang-bier-bierin6-03 could do the same.
·        With the above, I don’t see a real difference between this proposal and draft-zhang-bier-bierin6-03 – it’s just whether the BIER header is in the destination option or in the “payload” part of the IPv6 packet. Can you explain the pros and cons of two?
·        [XJR] there are more similarities since I (and you may also agree) want to use unicast DA only. but the difference is mainly two: one is use the address of BFIR without change in the fly as above point. one is use of a BIER specific ipv6 address in DA, which preceding any of the possible EHs and assume being the most efficient for fast path and most less impact on exist IPv6 functions.
Zzh> If you use unicast DA, what’s the BIER specific IPv6 address to use? How would it work for multi-hop tunnel? Why would that be most efficient and least impact existing IPv6 functions? To me using NH=BIER would be the most straightforward and least impactful to existing IPv6 functions.
Zzh> If I could ask a rhetorical question – would you put TCP or UDP header in an IPv6 Destination Option hdr?

draft-geng-bier-ipv6-inter-domain-00
·        Can you elaborate the following?
Note: Use of the IPv6 address configured on PE1 to identify an MVPN
instance can eliminate the need for BFR-id configuration on PE1x,
which otherwise has to be configured from the space of a sub-domain.
·        For the “peering multicast”, how many BIER sub-domain do you have?
·        [XJR] haven't evaluate that so far.I initiate this idea when I found a recent rfc8313 and thought of the tenant spanning multiple DCs. Also I assume the multicast as a service draft for this case.
·        Zzh> If I understand it correctly, the draft seems to assume only a single sub-domain.
·
·        What’s the real difference between “hierarchical multicast” and “peering multicast”, once you take away the color and MVPN aspects that I believe are orthogonal here?
·        [XJR] the hierarchical one is a P2MP case like IPTV in service provider. The peering one is an MP2MP case where the multicast source may be more unpredictable.
Zzh> From BIER point of view, there is no difference, right?
·
·        What’s the significance of “inter-domain” here, that requires this new draft?
·        [XJR] there is still no inter-domain BIER underlay construction, which I would think comparable to the so called non-segmented mvpn solution. It is the idea in my mind since the first presentation in ietf102 to deploy inter-domain BIER underlay. Also impressed by the points of multicast as a service you proposed.
Zzh> The reason I asked that question is that, in this single sub-domain scenario, there is really nothing new wrt inter-domain. You can use IGP signaling, BGP signaling, draft-zwzw-bier-prefix-redistribute, and draft-zzhang-bier-multicast-as-a-service procedures together to signal and build BIFTs. You can of course use static configuration, but that also applies to intra-domain and does not seem to warrant a specific spec for “inter-domain”.
·        What’s the uniqueness of IPv6 here?
·        [XJR] I found it difficult to construct the inter-domain BIFTs since the BIER-MPLS label is dynamic. Use of a static SRGB label as BIER-MPLS of a BR(border router) is waste ful, while use the SRGB for the entire domain seems not welcome in ietf102.
Zzh> I don’t follow. BIER label is indeed completely local and dynamic, but whether it is intra or inter-domain is irrelevant? Not sure why SRGB was brought up here.
Zzh> Besides, how does IPv6 solve this problem? You still have BIFT-ID, which could be dynamic just like MPLS label or could be hardcoded but that can work without IPv6 as well.
Zzh> Jeffrey
·        Thanks.
·        Jingrong.

Thanks!
Jeffrey
From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong
To: [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 03:24:23 +0000

Hi Jeffrey,
Please see my comments inline below marked as [XJR2].
________________________________
发件人: Jeffrey (Zhaohui) Zhang [[email-masked]]
发送时间: 2019年7月13日 10:32
收件人: Xiejingrong; [email-masked]; BIER WG
抄送: [email-masked]'; [email-masked]; [email-masked]; [email-masked]
主题: RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hi Jingrong,

Thanks
Jingrong

Hi Jingrong, Liang,
I have some questions and comments on two of the drafts.
draft-xie-bier-ipv6-encapsulation-02
·        Use of BIER multicast address FF0X::AB37 does not seem right to me. For example, on a LAN you can’t multicast BIER packets to multiple downstream BFRs – individual copies (with different BitString) must be unicast to those downstreams.
·        [XJR] Absolutely! The use of multicast DA can't support some very common usecases that may be assumed as Architecture of BIER. I agree with you to assume using a unicast DA. I will update the draft this way in next version.
·
·        Assuming that we agree that a unicast DA address must be used. What’s the rational of “Source Address field in the IPv6 header MUST be a routable IPv6 unicast address of the BFIR in any case”? Since the IPv6 header is only the outer encapsulation to get a packet from BFR1 to BFR2, why would you want to put the BFIR’s address in the outer encapsulation? If you could make both SA/DA of the IPv6 header to be the original SA/DA of the payload it may make some sense, but obviously you can’t do that.
·        [XJR] Yes, use of the address of the BFIR and keep it unchange when a packet fly through the BFRs is a key of the proposal. I think there is already examples of Source rooting that keep the source address unchange while change the DA in the fly. I would understand the BIER technology as a Multicast source routing!
Zzh> First of all, BIER is not source routing, even though BIER is the best multicast solution for SR because it does not have per-flow/tunnel/tree state in the core (yet BIER is independent of SR). Source routing means the source (router) determines the path of the packets. BIER is not like that. The BitString only specifies the set of BFERs.
[XJR2] Yes. source routing is specifying the path, while the BIER specifies the BFERs(target routers). But they both specify multiple things (Paths or BFERs) in the source.
What I really mean is that, there is already examples to keep the Source Address unchanged while Dest Address changes on the fly of a packet.
Zzh> As I pointed out, the IPv6 header is only to get the packet from BFR1 (vs. BFIR) to BFR2 (whether they’re directly connected or not) – one-hop or multi-hop tunneling, so it makes sense to use the BFR1’s address as SA.
[XJR2] I would prefer the unchanging of Source Address as a type of "Uniform" mode of MPLS, not the "Pipe" mode of MPLS. It may still be a kind of "tunneling", but is from the BFIR to BFERs, not segmented tunnels, say a tunnel from BFR A to BFR B, and then another tunnel from BFR B to BFR C. Also in the proposal, the TTL will decrease even on a Non-BFR router between BFR A and BFR B.
Zzh> Having said that, if you could convince everyone that the BFIR’s address should be used, then draft-zhang-bier-bierin6-03 could do the same.
[XJR2] Yes I insist on the use of BFIR's address being used. Bierin6 may also use this way, but I am not sure since there is no such exapmles. BIERv6 on the other hand has such examples since Routing Header is also a kind of EH and is assumed to be part of the network-layer(L3) behavior, and uses the same "Function specific IPv6 DA".
·        With the above, I don’t see a real difference between this proposal and draft-zhang-bier-bierin6-03 – it’s just whether the BIER header is in the destination option or in the “payload” part of the IPv6 packet. Can you explain the pros and cons of two?
·        [XJR] there are more similarities since I (and you may also agree) want to use unicast DA only. but the difference is mainly two: one is use the address of BFIR without change in the fly as above point. one is use of a BIER specific ipv6 address in DA, which preceding any of the possible EHs and assume being the most efficient for fast path and most less impact on exist IPv6 functions.
Zzh> If you use unicast DA, what’s the BIER specific IPv6 address to use?
[XJR2] to do a "BIER specific forwarding" while doing less impact on existing IPv6 functions. Here is an example for an incoming packet(don't expect if it is a bad packet).
Result = FIB Lookup
switch (Result):
  case Local-Interface-Address:
    send to CPU
  case Non-Local-Interface-Address routable:
    forwarding it
  case BIER-specific-Address
    do BIER forwarding if packet is the good pattern.
    drop packet if packet is not the good pattern.
end-of-switch.
The first 2 cases won't be impact, or have very little impact. Because of the switch-handling can be optimized.

How would it work for multi-hop tunnel?
[XJR2] This BIER specific IPv6 address is well visual to an operator, and it can be easier to configure this address in the other side of a multi-hop endpoint.

Why would that be most efficient and least impact existing IPv6 functions?
[XJR2] See above pseudo-code which I think is the most efficient and least impact.

To me using NH=BIER would be the most straightforward and least impactful to existing IPv6 functions.

Zzh> If I could ask a rhetorical question – would you put TCP or UDP header in an IPv6 Destination Option hdr?
[XJR2] TCP/UDP header is indicated by the last NH. Well I guess your concern is that, using BIER-specific still don't optimize the forwarding when considering there is possible any kind of EHs and Upper-layer Nextheaders. I will explain this in another mail to avoid lost of this mail.

·         [XJR2] Yes, also use a single sub-domain for multicast deployment.

·        What’s the real difference between “hierarchical multicast” and “peering multicast”, once you take away the color and MVPN aspects that I believe are orthogonal here?
·        [XJR] the hierarchical one is a P2MP case like IPTV in service provider. The peering one is an MP2MP case where the multicast source may be more unpredictable.
Zzh> From BIER point of view, there is no difference, right?
[XJR2] I can answer this later in another mail.
·
·        What’s the significance of “inter-domain” here, that requires this new draft?
·        [XJR] there is still no inter-domain BIER underlay construction, which I would think comparable to the so called non-segmented mvpn solution. It is the idea in my mind since the first presentation in ietf102 to deploy inter-domain BIER underlay. Also impressed by the points of multicast as a service you proposed.
Zzh> The reason I asked that question is that, in this single sub-domain scenario, there is really nothing new wrt inter-domain. You can use IGP signaling, BGP signaling, draft-zwzw-bier-prefix-redistribute, and draft-zzhang-bier-multicast-as-a-service procedures together to signal and build BIFTs. You can of course use static configuration, but that also applies to intra-domain and does not seem to warrant a specific spec for “inter-domain”.
[XJR2] I will use another mail too. But I can quickly figure out now one point different: in our proposal, the routers (if exist) in between PE1x and BR1 won't have to run IGP/BGP to setup the BIFT to BR1.
·        What’s the uniqueness of IPv6 here?
·        [XJR] I found it difficult to construct the inter-domain BIFTs since the BIER-MPLS label is dynamic. Use of a static SRGB label as BIER-MPLS of a BR(border router) is waste ful, while use the SRGB for the entire domain seems not welcome in ietf102.
Zzh> I don’t follow. BIER label is indeed completely local and dynamic, but whether it is intra or inter-domain is irrelevant? Not sure why SRGB was brought up here.
Zzh> Besides, how does IPv6 solve this problem? You still have BIFT-ID, which could be dynamic just like MPLS label or could be hardcoded but that can work without IPv6 as well.
[XJR2] I will use another mail too.

Zzh> Jeffrey
·        Thanks.
·        Jingrong.

Thanks!
Jeffrey

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 04:19:27 +0000

I clean the mail. Please see the [XJR2], and [XJR2a]:

Hi Jingrong, Liang,

[XJR2a] inside the branch of "BIER-specific-address" case, it can be further optimized for BIER forwarding or necessary processing like ICMPv6. Other undesired packet is simply dropped (very similar to an "IPv6 DA specific" ACL).

·        What’s the real difference between “hierarchical multicast” and “peering multicast”, once you take away the color and MVPN aspects that I believe are orthogonal here?
·        [XJR] the hierarchical one is a P2MP case like IPTV in service provider. The peering one is an MP2MP case where the multicast source may be more unpredictable.
Zzh> From BIER point of view, there is no difference, right?
[XJR2] I can answer this later in another mail.
[XJR2a] From BIER point of view, there is still some difference.
In current BIER Architecture, BIFT is constructed per the tuple of <SD/BSL/SI>.
In the above Color case, BIFT is constructed per the tuple of <Color/SD/BSL/SI>.
There may be some consideration of supporting multiple encapsulation in one <SD/BSL>, then the BIFT may be constructed per the tuple of <SD/BSL/Encap/SI>.
Note the multicast overlay need to steering a flow to <Color/SD/BSL/SI> instead of <SD/BSL/SI>.
·
·        What’s the significance of “inter-domain” here, that requires this new draft?
·        [XJR] there is still no inter-domain BIER underlay construction, which I would think comparable to the so called non-segmented mvpn solution. It is the idea in my mind since the first presentation in ietf102 to deploy inter-domain BIER underlay. Also impressed by the points of multicast as a service you proposed.
Zzh> The reason I asked that question is that, in this single sub-domain scenario, there is really nothing new wrt inter-domain. You can use IGP signaling, BGP signaling, draft-zwzw-bier-prefix-redistribute, and draft-zzhang-bier-multicast-as-a-service procedures together to signal and build BIFTs. You can of course use static configuration, but that also applies to intra-domain and does not seem to warrant a specific spec for “inter-domain”.
[XJR2] I will use another mail too. But I can quickly figure out now one point different: in our proposal, the routers (if exist) in between PE1x and BR1 won't have to run IGP/BGP to setup the BIFT to BR1.
[XJR2a] static-configuration is not desired in intra-domain case since there is so automated IGP deployment.
For Inter-domain case (mainly about inter-AS case as this document examples), static-configuration can be used, and I am used to understand things clearly by using static-configuration first.
I will try to learn and understand how the dynamic protocol as proposed above can be used for inter-domain.

·        What’s the uniqueness of IPv6 here?
·        [XJR] I found it difficult to construct the inter-domain BIFTs since the BIER-MPLS label is dynamic. Use of a static SRGB label as BIER-MPLS of a BR(border router) is waste ful, while use the SRGB for the entire domain seems not welcome in ietf102.
Zzh> I don’t follow. BIER label is indeed completely local and dynamic, but whether it is intra or inter-domain is irrelevant? Not sure why SRGB was brought up here.
Zzh> Besides, how does IPv6 solve this problem? You still have BIFT-ID, which could be dynamic just like MPLS label or could be hardcoded but that can work without IPv6 as well.
[XJR2] I will use another mail too.
[XJR2a] AS above, I am used to understand things quickly by using static-configuration first once possible. So SRGB is a thing I could thought of to use for static-configuration.
The dynamic BIFT-ID is difficult for static-configuration. This document assume the 'SD-BSL-SI' auto-generation of BIFT-ID is used consistently in all BFRs, and there are text in the document.
Thanks
Jingrong

Zzh> Jeffrey
·        Thanks.
·        Jingrong.

Thanks!
Jeffrey

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 16 Jul 2019 09:17:28 -0700

Stig,

Hooman suggested that draft-hb-bier-mldp-signaling-over-bier was
replacing draft-ietf-bier-mld,
but there's no replacement status in data-tracker, and you asked to
present. What's your take?

Thanks,
Greg

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 16 Jul 2019 19:12:06 +0000

Hi Greg

I do apologies if I was not clear and for any confusion

IN your previous email the title was [[Bier] Call for adoption: draft-hj-bier-ldp-signaling]

What I was suggesting it that this draft has been replaced with [draft-hb-bier-mldp-signaling-over-bier] that uses RFC 7060 as per agreement with Ice and Jeffrey

I did not make any comments on draft-ietf-bier-mld

Please let me know if this clears up the situation, if not lets have a quick call.

Regards

Hooman

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Tuesday, July 16, 2019 12:17 PM
To: Stig Venaas <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Stig,

Hooman suggested that draft-hb-bier-mldp-signaling-over-bier was replacing draft-ietf-bier-mld, but there's no replacement status in data-tracker, and you asked to present. What's your take?

Thanks,
Greg

On Wed, Jul 10, 2019 at 10:14 AM Stig Venaas <[email-masked]<mailto:[email-masked]>> wrote:
Hi

I would like 10 minutes for draft-ietf-bier-mld-02.txt. Presenter is myself..

Thanks,
Stig

On Tue, Jul 9, 2019 at 7:44 PM Bidgoli, Hooman (Nokia - CA/Ottawa)
<[email-masked]<mailto:[email-masked]>> wrote:
> To: gjshep@gmail..com<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 16 Jul 2019 12:40:48 -0700

Thanks, that makes more sense. :)

On Tue, Jul 16, 2019 at 12:12 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> What I was suggesting it that this draft has been replaced with [draft-hb-bier-mldp-signaling-over-bier]
> that uses RFC 7060 as per agreement with Ice and Jeffrey
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Greg Shepherd
> *Sent:* Tuesday, July 16, 2019 12:17 PM
> *To:* Stig Venaas <[email-masked]>
> *Cc:* BIER WG <[email-masked]>
> *Subject:* Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105
>
>
>
> Stig,
>
>
>
> replacing draft-ietf-bier-mld, but there's no replacement status in
> data-tracker, and you asked to present. What's your take?
>
>
>
> Thanks,
>
> Greg
>
>
>
> > To: gjshep@gmail..com <[email-masked]>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 16 Jul 2019 12:59:15 -0700

I just uploaded the first draft agenda. Here it is for your review (below).
Please send corrects here, and slides to me directly (unicast to this gmail
address).

IETF 105, Montreal
BIER WG Agenda

WG Status Update 15mins, chairs
draft-zzhang-bier-tether-02, 15 minutes, Jeffrey Zhang
draft-hb-bier-mldp-signaling-over-bier, 10 mins Hooman Bidgoli
draft-ietf-bier-multicast-http-response-01, 10 mins, Dirk Trossen
draft-ietf-bier-pmmm-oam 10min, Greg Mirsky
draft-ietf-bier-te-arch 10min, Toerless Eckert
draft-ietf-bier-mld-02, 10min, Stig Venaas
draft-ietf-bier-ipv6-requirements, 10min, Mike McBride
- additional drafts to be discussed if room decides, based on the above
- requirements draft.
  draft-xie-bier-ipv6-encapsulation-02
  draft-xie-bier-ipv6-isis-extension-00
  draft-xie-bier-ipv6-mvpn-01
  draft-geng-bier-ipv6-inter-domain-00

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 17 Jul 2019 08:08:48 -0700

Just updated the agenda:

IETF 105, Montreal
BIER WG Agenda

draft-zhang-bier-bierin6-03
 draft-zhang-bier-source-protection-00, 15min, Sandy Zhang
draft-ietf-bier-ipv6-requirements, 15min, Mike McBride

On Tue, Jul 16, 2019 at 12:59 PM Greg Shepherd <[email-masked]> wrote:

> I just uploaded the first draft agenda. Here it is for your review
> (below). Please send corrects here, and slides to me directly (unicast to
> this gmail address).
>
> IETF 105, Montreal
> BIER WG Agenda
>

---

From: Xiejingrong <[email-masked]>
Date: Wed, 17 Jul 2019 22:29:42 +0000

Hi
There are only 5 minutes left for my 4 drafts (which I had required for time slot very early).
I don't think that's good.
A better way in my opinion is that, each topic need some work begin on the list and shorten the time on the session.

Thanks
Jingrong

________________________________
From: BIER [[email-masked]] on behalf of Greg Shepherd [[email-masked]]
Sent: Wednesday, July 17, 2019 23:08
To: BIER WG
Subject: Re: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Just updated the agenda:

IETF 105, Montreal
BIER WG Agenda

On Tue, Jul 16, 2019 at 12:59 PM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
I just uploaded the first draft agenda. Here it is for your review (below). Please send corrects here, and slides to me directly (unicast to this gmail address).

IETF 105, Montreal
BIER WG Agenda

On Mon, Jul 8, 2019 at 12:37 PM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
Please send agenda items with title, draft, speaker name, and requested time to this thread.

Thanks,
Shep
(chairs)

---

From: Xiejingrong <[email-masked]>
Date: Thu, 18 Jul 2019 11:33:00 +0000

Hi Jeffrey,
I haven't seen your reply since this.
Are all questions clear to you ?

Thanks
Jingrong
________________________________
From: Xiejingrong
Sent: Saturday, July 13, 2019 12:19
To: Jeffrey (Zhaohui) Zhang; [email-masked]; BIER WG
Cc: [email-masked]'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Bier] BIER WG, Call For Agenda, Montreal IETF 105

Hi Jingrong, Liang,

Zzh> Jeffrey
·        Thanks.
·        Jingrong.

Thanks!
Jeffrey