Subject: Re: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 28 Apr 2019 17:41:30 +0000

Hi Senthil,

Looks like that I did not reply to this email.

Since there is no real difference between an mpls label and an opaque 20-bit BIFT-ID (other than one uses mpls forwarding infrastructure and the other does not), I agree that reserve space [0-15] is a good idea to keep the two in sync.

Jeffrey

Juniper Internal
From: Senthil Dhanaraj <[email-masked]>
Sent: Thursday, January 31, 2019 4:39 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Xiejingrong <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

Hi Jeffrey,

I meant that "reserved special purpose BIFT-id" could also be used for cases like PHP.
This way, we may avoid having to add new sub-TLV's like "PHP sub-sub-TLV".

Keeping PHP case aside, In general, Do you think we should reserve a space [0 - 15] as special purpose BIFT-id's?

Thanks,
Senthil

On Wed, Jan 30, 2019 at 9:29 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
For the specific case of PHP, it does not use a special BIFT-ID to signal PHP (especially when you consider the fact that we're talking about "BIFT-ID"). The php draft says:

   A BIER incapable router, if acting as a multicast flow overlay
   router, MUST signal its BIER information as specified in [RFC8401<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8401&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=N_OTgZiZr2c6GaNIafdyf5kQ8zK4jBPSgKonPyjdJBE&s=sOU2zHHHLHfCiNpA0iy1ILFQPIPfKVmyvr_Hf-IEtcA&e=>] or
   [I-D.ietf-bier-ospf-bier-extensions] or [I-D.ietf-bier-idr-
   extensions], with a PHP sub-sub-TLV included in the BIER sub-TLV
   attached to the BIER incapable router's BIER prefix to request BIER
   PHP from other BFRs.  The sub-sub-TLV's type is TBD, and the length
   is 0.

   With MPLS encapsulation, the BIER incapable multicast flow overlay
   router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set
   the Label Range Base in BIER MPLS Encapsulation sub-sub-TLV to
   Implicit Null Label [RFC3032<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3032&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=N_OTgZiZr2c6GaNIafdyf5kQ8zK4jBPSgKonPyjdJBE&s=yTKr1Q5Qg2oczBEXNXpPmI1XxKzgirvheMi5wxlpdf0&e=>].

Jeffrey

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Senthil Dhanaraj
Sent: Wednesday, January 30, 2019 1:02 AM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

Hi Xiejingrong,

RFC8296 do not reserve any BIFT-id's (for non-mpls networks) to be used for special purposes.

But yes, it might be a good idea to reserve a BIFT-id range to be used for special purposes in non-MPLS networks.
One use case i can think of is PHP (use special values like Implicit NULL, Explicit NULL label in MPLS) which could be applied to non-MPLS networks as well like BIER over Ethernet.

BIER'ers, kindly shoot your opinion !

Thanks,
Senthil

On Wed, Jan 30, 2019 at 7:54 AM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:
Hi  Senthil
I have one comment/question:
Section 1, is BIFT-id 1/2/3/4/5/6 been allowed in non-mpls case?

In MPLS encapsulation, value 0 to 15 is reserved and should not be allowed as BIER label I guess.

Thanks
Jingrong

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Senthil Dhanaraj
Sent: Tuesday, January 29, 2019 10:04 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

Hi Folks,

Renamed draft-dhanaraj-bier-isis-non-mpls-extensions to  draft-dhanaraj-bier-lsr-ethernet-extensions

Major updates:
1) Added packet format details for OSPFv2 as well
2) Updated text to better explain the signalling of BIFT-id's
3) Renamed "non-mpls" to "ethernet" as this specific draft covers only "BIER over Ethernet".

Thanks,
Senthil

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 28 Apr 2019 11:07:10 -0700

Nope, it's not. Add a sub-TLV to signal the capacity rather than giving
special meanings to values in flat addressing space ...

--- tony

On Sun, Apr 28, 2019 at 10:41 AM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> Since there is no real difference between an mpls label and an opaque
> 20-bit BIFT-ID (other than one uses mpls forwarding infrastructure and the
> other does not), I agree that reserve space [0-15] is a good idea to keep
> the two in sync.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Internal
>
> *From:* Senthil Dhanaraj <[email-masked]>
> *Sent:* Thursday, January 31, 2019 4:39 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* Xiejingrong <[email-masked]>; BIER WG <[email-masked]>
> *Subject:* Re: [Bier] Fwd: New Version Notification for
> draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt
>
>
>
> Hi Jeffrey,
>
>
>
> On Wed, Jan 30, 2019 at 9:29 PM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
> For the specific case of PHP, it does not use a special BIFT-ID to signal
> PHP (especially when you consider the fact that we’re talking about
> “BIFT-ID”). The php draft says:
>
>
>
>    router, MUST signal its BIER information as specified in [RFC8401
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8401&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=N_OTgZiZr2c6GaNIafdyf5kQ8zK4jBPSgKonPyjdJBE&s=sOU2zHHHLHfCiNpA0iy1ILFQPIPfKVmyvr_Hf-IEtcA&e=>]
> or
>
>    Implicit Null Label [RFC3032
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3032&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=N_OTgZiZr2c6GaNIafdyf5kQ8zK4jBPSgKonPyjdJBE&s=yTKr1Q5Qg2oczBEXNXpPmI1XxKzgirvheMi5wxlpdf0&e=>
> ].
>
>
>
>
>
> Jeffrey
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Senthil
> Dhanaraj
> *Sent:* Wednesday, January 30, 2019 1:02 AM
> *To:* Xiejingrong <[email-masked]>
> *Cc:* BIER WG <[email-masked]>
> *Subject:* Re: [Bier] Fwd: New Version Notification for
> draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt
>
>
>
> Hi Xiejingrong,
>
>
>
> One use case i can think of is PHP (use special values like Implicit NULL,
> Explicit NULL label in MPLS) which could be applied to non-MPLS networks as
> well like BIER over Ethernet.
>
>
>
> On Wed, Jan 30, 2019 at 7:54 AM Xiejingrong <[email-masked]>
> wrote:
>
> Hi  Senthil
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Senthil
> Dhanaraj
> *Sent:* Tuesday, January 29, 2019 10:04 PM
> *To:* BIER WG <[email-masked]>
> *Subject:* [Bier] Fwd: New Version Notification for
> draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt
>
>
>
> Hi Folks,
>
>
>
> Renamed draft-dhanaraj-bier-isis-non-mpls-extensions to
> draft-dhanaraj-bier-lsr-ethernet-extensions
>
>
>
> Major updates:
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 28 Apr 2019 18:32:00 +0000

Hi Tony,

The context is "Keeping PHP case aside" :-)

Jeffrey

Juniper Internal
From: Tony Przygienda <[email-masked]>
Sent: Sunday, April 28, 2019 2:07 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Senthil Dhanaraj <[email-masked]>; Xiejingrong <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

Nope, it's not. Add a sub-TLV to signal the capacity rather than giving special meanings to values in flat addressing space ....

--- tony

On Sun, Apr 28, 2019 at 10:41 AM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>> wrote:
Hi Senthil,

Jeffrey

Juniper Internal
From: Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 31, 2019 4:39 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Xiejingrong <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

Hi Jeffrey,

Thanks,
Senthil

Jeffrey

Hi Xiejingrong,

Thanks,
Senthil

Thanks
Jingrong

Hi Folks,

Major updates:

Thanks,
Senthil
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=WIVOmBke2a8-y1DN7JQk7zsU0MufWRSN-h_5B5fM95o&s=L_UEgdJMLF3eo23S6S-52jNUL1dGj3NnKdrLJEDOJ1g&e=>

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 28 Apr 2019 11:47:11 -0700

Ok, thanks for push back ;-) I re-read the thread ;and kind of see what
you're aiming at but correct me if I got it wrong. Since MPLS labels [0-15]
are special purpose you'd like to carve out the same for the non-MPLS case?

So then, yes, I'm agnostic to that (I don't see how you can use that for
PHP, you have to use the correct BIFT-ID for the PHP hop and then after
that there is no BIFT-ID but maybe I miss something) except I would not
formulate that as anything along the lines of "synchronizing" the space,
there is nothing to synchronize, MPLS lablels are MPLS lables, non-MPLS
BIFT-ids are something else albeit they look bit-wise the same. Anything
else is a non distributio medii fallacy ...

On Sun, Apr 28, 2019 at 11:32 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Tony,
>
>
>
> The context is “Keeping PHP case aside” :-)
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Internal
>
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Sunday, April 28, 2019 2:07 PM
> *Cc:* Senthil Dhanaraj <[email-masked]>; Xiejingrong <
> [email-masked]>; BIER WG <[email-masked]>
> special meanings to values in flat addressing space ....
>
>
>
> --- tony
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=WIVOmBke2a8-y1DN7JQk7zsU0MufWRSN-h_5B5fM95o&s=L_UEgdJMLF3eo23S6S-52jNUL1dGj3NnKdrLJEDOJ1g&e=>
>
>

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Mon, 29 Apr 2019 06:16:28 +0000

I agree with Tony, reserving the 0-15 from non-MPLS seems wrong to me.

Sent from my iPhone

On 28 Apr 2019, at 20:48, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

Ok, thanks for push back ;-) I re-read the thread ;and kind of see what you're aiming at but correct me if I got it wrong. Since MPLS labels [0-15] are special purpose you'd like to carve out the same for the non-MPLS case?

So then, yes, I'm agnostic to that (I don't see how you can use that for PHP, you have to use the correct BIFT-ID for the PHP hop and then after that there is no BIFT-ID but maybe I miss something) except I would not formulate that as anything along the lines of "synchronizing" the space, there is nothing to synchronize, MPLS lablels are MPLS lables, non-MPLS BIFT-ids are something else albeit they look bit-wise the same. Anything else is a non distributio medii fallacy ...

On Sun, Apr 28, 2019 at 11:32 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,

Jeffrey

Juniper Internal
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, April 28, 2019 2:07 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>; Xiejingrong <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Fwd: New Version Notification for draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt

--- tony

Jeffrey

Juniper Internal

Hi Jeffrey,

Thanks,
Senthil

On Wed, Jan 30, 2019 at 9:29 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
For the specific case of PHP, it does not use a special BIFT-ID to signal PHP (especially when you consider the fact that we’re talking about “BIFT-ID”). The php draft says:

Jeffrey

Hi Xiejingrong,

Thanks,
Senthil

Thanks
Jingrong

Hi Folks,

Major updates:

Thanks,
Senthil