Subject: [Bier] comments on draft-dhanaraj-bier-lsr-ethernet-extensions-00

From: <[email-masked]>
Date: Mon, 4 Mar 2019 14:48:45 +0800 (CST)

Hi authors,

I read this draft. From my side it is well-written.

I notice that this draft updates "RFC8296". It seems like this draft makes no change for RFC8296.

So if it is suitable that this draft updates "RFC8401" and "RFC8444" or there is no update for a specific RFC?

Thanks,

Sandy

---

From: Senthil Dhanaraj <[email-masked]>
Date: Tue, 5 Mar 2019 14:46:32 +0530

Hi Sandy,

Thanks for your comments.
This draft updates RFC8296-  is with respect to below statement from
RFC8296 - Section 2.2.1.1

In an MPLS network, since the BIFT-id is an MPLS label, its value may
be changed as a BIER packet goes from BFR to BFR.  In a non-MPLS
network, since the BIFT-id is domain-wide unique, it is not expected
to change as a BIER packet travels.

We wanted to allow using non-domain-wide-unique BIFT-id as well in
case of non-MPLS networks. Pls see, Section 1 of
draft-dhanaraj-bier-lsr-ethernet-extension.

[RFC8296] specifies a common BIER header format for both MPLS and
non-MPLS networks, though the first 20-bits of the BIER header
(referred as BIFT-id) is a "MPLS Label" in case of MPLS networks and
is a "domain-wide-unique-value" representing the combination of SD-
// refer-this
BSL-SI in case of non-MPLS networks.
[I-D.ietf-bier-non-mpls-bift-encoding
<https://tools.ietf.org/html/draft-dhanaraj-bier-lsr-ethernet-extensions-00#ref-I-D.ietf-bier-non-mpls-bift-encoding>]
specifies two optional ways of
statically assigning domain-wide-unique mapping between BIFT-IDs and
SD-BSL-SI combination.

However, BIER architecture [RFC8279
<https://tools.ietf.org/html/rfc8279>] does NOT require domain-wide-
// refer this
unique BIFT-IDs to be used (even for non-MPLS encapsulation).  As
discussed in [I-D.zzhang-bier-rift
<https://tools.ietf.org/html/draft-dhanaraj-bier-lsr-ethernet-extensions-00#ref-I-D.zzhang-bier-rift>],
the BIFT-ID in case of non-MPLS
encapsulation can also just be a local 20-bit opaque value and
signaled just like in MPLS case.

Thanks,

Senthil

---

From: <[email-masked]>
Date: Wed, 6 Mar 2019 10:32:04 +0800 (CST)

Hi Senthil,

Thank you for your respond!

I see! This draft actually update RFC8296. 

Should the section 2.2.1.1 be pointed out explicitly in this draft?

Sandy

原始邮件

发件人：SenthilDhanaraj <[email-masked]>
收件人：张征00007940;
抄送人：[email-masked] <[email-masked]>;Peter Psenak <[email-masked]>;Jeffrey (Zhaohui) Zhang <[email-masked]>;[email-masked] <[email-masked]>;Xiejingrong <[email-masked]>;BIER WG <[email-masked]>;
日 期 ：2019年03月05日 17:15
主 题 ：Re: [Bier] comments on draft-dhanaraj-bier-lsr-ethernet-extensions-00

Hi Sandy,
Thanks for your comments.
This draft updates RFC8296-  is with respect to below statement from RFC8296 - Section 2.2.1.1

In an MPLS network, since the BIFT-id is an MPLS label, its value may be changed as a BIER packet goes from BFR to BFR. In a non-MPLS network, since the BIFT-id is domain-wide unique, it is not expected to change as a BIER packet travels.
We wanted to allow using non-domain-wide-unique BIFT-id as well in case of non-MPLS networks. Pls see, Section 1 of draft-dhanaraj-bier-lsr-ethernet-extension.
[RFC8296] specifies a common BIER header format for both MPLS and non-MPLS networks, though the first 20-bits of the BIER header (referred as BIFT-id) is a "MPLS Label" in case of MPLS networks and is a "domain-wide-unique-value" representing the combination of SD- // refer-this BSL-SI in case of non-MPLS networks. [I-D.ietf-bier-non-mpls-bift-encoding] specifies two optional ways of statically assigning domain-wide-unique mapping between BIFT-IDs and SD-BSL-SI combination. 
However, BIER architecture [RFC8279] does NOT require domain-wide- // refer this unique BIFT-IDs to be used (even for non-MPLS encapsulation). As discussed in [I-D.zzhang-bier-rift], the BIFT-ID in case of non-MPLS encapsulation can also just be a local 20-bit opaque value and signaled just like in MPLS case. Thanks,Senthil

Hi authors,

Thanks,

Sandy