Subject: [Bier] WGLC: draft-ietf-bier-php

From: Greg Shepherd <[email-masked]>
Date: Wed, 12 Aug 2020 20:31:01 -0700

Please read and respond to this thread. We had a WGLC for this draft previously, but had no response. Let’s do better. 

https://datatracker.ietf.org/doc/draft-ietf-bier-php/

Start of short LC timer. Respond by Aug 19.

- Shep
(Chairs)

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Mon, 17 Aug 2020 18:55:53 +0000

In support moving this draft forward,

Thx,

Ice.

Sent from my iPhone

On 13 Aug 2020, at 05:31, Greg Shepherd <[email-masked]> wrote:

Start of short LC timer. Respond by Aug 19..

- Shep
(Chairs)
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 17 Aug 2020 21:51:57 +0000

Useful, support

Thanks
Hooman

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Wednesday, August 12, 2020 11:31 PM
To: [email-masked]
Subject: [Bier] WGLC: draft-ietf-bier-php

- Shep
(Chairs)

---

From: <[email-masked]>
Date: Tue, 18 Aug 2020 08:35:50 +0800 (CST)

This draft is well written. 

Support the moving on of this draft.

Thanks,

Sandy

原始邮件

发件人：GregShepherd <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2020年08月13日 11:31
主 题 ：[Bier] WGLC: draft-ietf-bier-php

Start of short LC timer. Respond by Aug 19...

- Shep
(Chairs)

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 18 Aug 2020 14:35:55 +0000

Hi WG,
I support advance of this document.
It had addressed my comments previously, and the mechanism of PHP is useful for BIER deployment.

Thanks
Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, August 13, 2020 11:31 AM
To: [email-masked]
Subject: [Bier] WGLC: draft-ietf-bier-php

- Shep
(Chairs)

---

From: Suneesh Babu <[email-masked]>
Date: Tue, 18 Aug 2020 15:00:56 +0000

Yes. I support.

Regards,
Suneesh

From: BIER <[email-masked]> on behalf of "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tuesday, 18 August 2020 at 8:06 PM
To: Greg Shepherd <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

[External Email. Be cautious of content]

Hi WG,

Thanks
Jingrong

https://datatracker.ietf.org/doc/draft-ietf-bier-php/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-php/__;!!NEt6yMaO-gk!Rr-1aZEIaJOtj6u5eOj5-9b7hpCnCtLc6XL6NLo1zkudJIGxiSskgoYmPwAyYvA$>

- Shep
(Chairs)

Juniper Business Use Only

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 18 Aug 2020 09:55:42 -0700

Hi Greg S., et al.,
I've read the draft and support its publication. The document is
well-written and addresses the practical use case.

Several nits for the next update:
Abstract

   - AFAIK, references are not used in the Abstract, documents mentioned as
   text, e.g., RFC 6514 or RFC 7432.

In the text

   - s/BIER capable/BIER-capable/4
   - s/the preferred the choice/the preferred choice/
   - s/BIER incapable/BIER-incapable/7

The Security Considerations section might benefit from references to BIER
Architecture and "OSPF/ISIS/BGP extensions for BIER signaling" mentioned
there.

Regards,
Greg M

On Wed, Aug 12, 2020 at 8:31 PM Greg Shepherd <[email-masked]> wrote:

>
> Please read and respond to this thread. We had a WGLC for this draft
> previously, but had no response. Let’s do better.
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 19 Aug 2020 01:40:51 +0000

Yes, support !

Best Regards
Xuesong

- Shep
(Chairs)

---

From: Loa Andersson <[email-masked]>
Date: Wed, 19 Aug 2020 19:37:14 +0800

All,

yes, support.

I have one thought that possibly don't need to have an impact on
progressing this draft.

If you think of the p2mp forwarding tree in bier as a p2mp LSP,
it seems to me that the LSP setup by this draft ends on penultimate
node (which is kind of an oxymoron). The ultimate node is also the
node th do the PHP, which would make it UHP. If the LSP ends on a node
that is the ultimate node.

For example in MPLS the LSP ends on the ultimate node, while the
pen-ultimate node does the PHP.

It would also be interesting to know how PCE does this. Dhruv?

As I said, don't let thgis stop progressing this draft, but we
maybe should sit down and and come with a unified way of using
the concepts.

On 19/08/2020 09:40, Gengxuesong (Geng Xuesong) wrote:
> Yes, support !
> 
> Best Regards
> 
> Xuesong
> 
> *From:*BIER [mailto:[email-masked]] *On Behalf Of *Greg Shepherd
> *Sent:* Thursday, August 13, 2020 11:31 AM
> *To:* [email-masked]
> *Subject:* [Bier] WGLC: draft-ietf-bier-php
> 
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 19 Aug 2020 19:53:31 +0530

Hi Loa,

> It would also be interesting to know how PCE does this. Dhruv?

In my understanding, from the control plane point of view, the LSP
does not end on the penultimate node, the destination is the ultimate
node. While in the forwarding the bier header could be popped on the
penultimate node and packet sent to the ultimate node, but the LSP's
destination still is the ultimate node.

BTW in PCE P2MP documents, you would not find any reference to PHP.
>From the P2MP tree path computation point of view, the computation is
done till the ultimate node and it is up to the signaling to handle
PHP.

Thanks!
Dhruv

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 19 Aug 2020 16:07:45 +0000

Hi,

> In my understanding, from the control plane point of view, the LSP does not end on the penultimate node, the destination is the ultimate node. While in the forwarding the bier header could be popped on the penultimate node and packet sent to the ultimate node, but the LSP's destination still is the ultimate node.

That's how I see it as well. In BIER case, the penultimate node is a BFR, and the ultimate node is a BFER in control plane (in that it has BFR-id and participate in BIER signaling) though its penultimate node will pop the BIER header in the data plane.

Jeffrey

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Wednesday, August 19, 2020 10:24 AM
To: Loa Andersson <[email-masked]>
Cc: Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]; Greg Shepherd <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Hi Loa,

On Wed, Aug 19, 2020 at 5:07 PM Loa Andersson <[email-masked]> wrote:
> If you think of the p2mp forwarding tree in bier as a p2mp LSP, it 
> seems to me that the LSP setup by this draft ends on penultimate node 
> (which is kind of an oxymoron). The ultimate node is also the node th 
> do the PHP, which would make it UHP. If the LSP ends on a node that is 
> the ultimate node.
>

In my understanding, from the control plane point of view, the LSP does not end on the penultimate node, the destination is the ultimate node. While in the forwarding the bier header could be popped on the penultimate node and packet sent to the ultimate node, but the LSP's destination still is the ultimate node.

>From the P2MP tree path computation point of view, the computation is
done till the ultimate node and it is up to the signaling to handle PHP.

Thanks!
Dhruv

> As I said, don't let thgis stop progressing this draft, but we maybe 
> should sit down and and come with a unified way of using the concepts.
>
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
> > etf-bier-php/__;!!NEt6yMaO-gk!UBxdbv0B2SFGtXr2xVzNSjDXpbhg6p9WGswOPp
> > SndIsFhVWf0FSRu27sTq60eF-O$
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bi
> > er__;!!NEt6yMaO-gk!UBxdbv0B2SFGtXr2xVzNSjDXpbhg6p9WGswOPpSndIsFhVWf0
> > FSRu27sTlE8dlHC$
> >
>
> --
>

_______________________________________________
BIER mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!UBxdbv0B2SFGtXr2xVzNSjDXpbhg6p9WGswOPpSndIsFhVWf0FSRu27sTlE8dlHC$

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 19 Aug 2020 18:01:42 +0000

Support moving this document forward.

From: BIER <[email-masked]> on behalf of "IJsbrand Wijnands (iwijnand)" <iwijnand=[email-masked]>
Date: Monday, August 17, 2020 at 11:56 AM
To: Greg Shepherd <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Thx,

Ice.
Sent from my iPhone

- Shep
(Chairs)

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 Aug 2020 17:20:56 -0400

I support advancing this critical draft forward.  I agree that the PHP
feature traditionally used with MPLS and has been adopted by SR and now by
BIER for similar reasons of being able to pop the BIER header similar to
what is done with SR PHP concept and now extensible with BIER for Non-BRF
capable PE's.

BIER IPv6 is still being developed, however I think maybe BIERin6 could
take advantage of  PHP by popping the encapsulated L2 1/2 BIER shim for
"Non-BFR" capable PE.  I think for BIERv6 as the BIER header is encoded in
DOH it may be difficult to support PHP.

Thanks

Gyan

On Wed, Aug 19, 2020 at 2:01 PM Mankamana Mishra (mankamis) <mankamis=
[email-masked]> wrote:

> *From: *BIER <[email-masked]> on behalf of "IJsbrand Wijnands
> (iwijnand)" <iwijnand=[email-masked]>
> *Date: *Monday, August 17, 2020 at 11:56 AM
> *To: *Greg Shepherd <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Bier] WGLC: draft-ietf-bier-php
>
>
>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Loa Andersson <[email-masked]>
Date: Sat, 22 Aug 2020 13:57:03 +0800

Working Group,

I've had time to read the draft a bit more in detail.

I'm convinced that this will work, and support progressing the draft.

I still think there are some minor description details that could be
improved.

The draft says:

    One way to solve this problem is to use Penultimate Hop Popping (PHP)
    so that the upstream BFR can pop the BIER header and send the payload
    "natively" (note that the upstream BFR can be connected directly or
    indirectly via any type of tunnel to the PE).  This is similar to
    Multi-Protocol Label Switching (MPLS) PHP though it is the BIER
    header that is popped.

This indicate that this is a "per node" decision, while in MPLS it is a
per LSP decision.

I would think that it is possible for one node to be the penultimate
node for some traffic but not for other traffic, even though the traffic 
is sent to the same node, which can be both ultimate node, pen-ultimate
node or transit node.

      +-------+              +-------+          +-------+
      |       |              |       |          |       |
-a,b-+   A   +-----a',b-----+   B   +----a'----+  CPE1 |
      |       |              |       |          |       |
      +-------+              +---+---+          +-------+
                                 |
                                 b'
                                 |
                             +---+---+          +-------+
                             |       |          |       |
                             +   C   +----b'----+  CPE2 |
                             |       |          |       |
                             +---+---+          +-------+

Two streams comes in to A from the left (a and b).

A is the penultimate node for traffic to to CPE1 (a) so the BIER header
is popped.

A is not the  penultimate node for traffic to to CPE2 (b) so the BIER
header is popped.

Both a' and b is sent to B.

B forward a' natively to CPE1.

B is the penultimate node for traffic to to CPE2 (b) so the BIER header
is popped.

b' is forwarded to C and onto CPE2

Works just fine.

Question: If the PHP is a "per node decision" how is A stopped from 
doing PHP for b?

/Loa

On 22/08/2020 05:20, Gyan Mishra wrote:
> feature traditionally used with MPLS and has been adopted by SR and now 
> by BIER for similar reasons of being able to pop the BIER header similar 
> to what is done with SR PHP concept and now extensible with BIER for 
> Non-BRF capable PE's.
> 
> "Non-BFR" capable PE.  I think for BIERv6 as the BIER header is encoded 
> in DOH it may be difficult to support PHP.
> 
> Thanks
> 
> Gyan
> 
> On Wed, Aug 19, 2020 at 2:01 PM Mankamana Mishra (mankamis) 
> <mankamis=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Support moving this document forward. ____
> 
>     __ __
> 
>     *From: *BIER <[email-masked] <mailto:[email-masked]>>
>     on behalf of "IJsbrand Wijnands (iwijnand)"
>     <iwijnand=[email-masked]
>     <mailto:[email-masked]>>
>     *To: *Greg Shepherd <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [Bier] WGLC: draft-ietf-bier-php____
> 
>     __ __
> 
>     In support moving this draft forward, ____
> 
>     __ __
> 
>     Thx,____
> 
>     __ __
> 
>     Ice.____
> 
>     Sent from my iPhone____
> 
> 
> 
>     ____
> 
>         On 13 Aug 2020, at 05:31, Greg Shepherd <[email-masked]
>         <mailto:[email-masked]>> wrote:____
> 
> 
>         Please read and respond to this thread. We had a WGLC for this
>         draft previously, but had no response. Let’s do better. ____
> 
>         __ __
> 
>         https://datatracker.ietf.org/doc/draft-ietf-bier-php/____
> 
>         __ __
> 
>         Start of short LC timer. Respond by Aug 19..____
> 
>         __ __
> 
>         - Shep____
> 
>         (Chairs)____
> 
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/bier____
> 
>     [email-masked] <mailto:[email-masked]>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
> 
> 

--

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 24 Aug 2020 07:30:42 +0000

Hi Gyan,

Thanks for raising the PHP consideration in v6.

There is a thorough discussion in IETF community, especially 6man,  about Penultimate Segment Pop (PSP) ---- to Pop an EH when an IPv6 packet with EH reaches the node identified in the destination address [RFC8200 section 4].
This thorough discussion has led to a wide consensus among IETF community, and led to the progress of draft-ietf-spring-srv6-network-programming-17 to IETF last call.

So for BIERv6, I think the PSP can be very well supported to provide incremental deployment for Non-BIER-capable PEs.

Note, the whole DoH (not only the BIER option data) is popped/deleted when the BIERv6 packet is sent to the ultimate PE. Here is a diagram:

CE1----A----B----C----D----CE2

A is BFIR, D is Non-BFR router but acting as a BFER requesting PSP (signaling defined in draft-ietf-bier-php), and both B and C are BFRs (could be BFERs at the same time).

Packet from A to B: (IPv6 SA=A, DA=B) (DoH carrying BIER) (c-multicast packet).
Packet from B to C: (IPv6 SA=A, DA=C) (DoH carrying BIER) (c-multicast packet).
Packet from C to D: (IPv6 SA=A, DA=D) (c-multicast packet).

Thanks
Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Saturday, August 22, 2020 5:21 AM
To: Mankamana Mishra (mankamis) <mankamis=[email-masked]>
Cc: IJsbrand Wijnands (iwijnand) <iwijnand=[email-masked]>; Greg Shepherd <[email-masked]>; [email-masked]
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

I support advancing this critical draft forward.  I agree that the PHP feature traditionally used with MPLS and has been adopted by SR and now by BIER for similar reasons of being able to pop the BIER header similar to what is done with SR PHP concept and now extensible with BIER for Non-BRF capable PE's.

BIER IPv6 is still being developed, however I think maybe BIERin6 could take advantage of  PHP by popping the encapsulated L2 1/2 BIER shim for "Non-BFR" capable PE.  I think for BIERv6 as the BIER header is encoded in DOH it may be difficult to support PHP.

Thanks

Gyan

On Wed, Aug 19, 2020 at 2:01 PM Mankamana Mishra (mankamis) <mankamis=[email-masked]<mailto:[email-masked]>> wrote:
Support moving this document forward.

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of "IJsbrand Wijnands (iwijnand)" <iwijnand=[email-masked]<mailto:[email-masked]>>
Date: Monday, August 17, 2020 at 11:56 AM
To: Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Thx,

Ice.
Sent from my iPhone

On 13 Aug 2020, at 05:31, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

- Shep
(Chairs)
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 24 Aug 2020 15:16:02 +0000

Hi Loa,

Please see zzh> below.

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Loa Andersson
Sent: Saturday, August 22, 2020 1:57 AM
To: Gyan Mishra <[email-masked]>; Mankamana Mishra (mankamis) <mankamis=[email-masked]>
Cc: IJsbrand Wijnands (iwijnand) <iwijnand=[email-masked]>; Greg Shepherd <[email-masked]>; [email-masked]
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Working Group,

I still think there are some minor description details that could be improved.

The draft says:

This indicate that this is a "per node" decision, while in MPLS it is a per LSP decision.

Zzh> It’s a per node decision for all traffic to a particular “BFER” who does not really support BIER forwarding. PHP is not used when the BFERs do support BIER.

I would think that it is possible for one node to be the penultimate node for some traffic but not for other traffic, even though the traffic is sent to the same node, which can be both ultimate node, pen-ultimate node or transit node.

A is the penultimate node for traffic to to CPE1 (a) so the BIER header is popped.

A is not the  penultimate node for traffic to to CPE2 (b) so the BIER header is not popped.

Zzh> So the context is that B does support BIER. In that case, A won’t do PHP for B at all.

B is the penultimate node for traffic to to CPE2 (b) so the BIER header is popped.

Works just fine.

Question: If the PHP is a "per node decision" how is A stopped from doing PHP for b?

Zzh> Please see above :-)
Zzh> Thanks.
Zzh> Jeffrey

/Loa

On 22/08/2020 05:20, Gyan Mishra wrote:
> feature traditionally used with MPLS and has been adopted by SR and
> now by BIER for similar reasons of being able to pop the BIER header
> similar to what is done with SR PHP concept and now extensible with
> BIER for Non-BRF capable PE's.
>
> BIER IPv6 is still being developed, however I think maybe BIERin6
> could take advantage of  PHP by popping the encapsulated L2 1/2 BIER
> shim for "Non-BFR" capable PE.  I think for BIERv6 as the BIER header
> is encoded in DOH it may be difficult to support PHP.
>
> Thanks
>
> Gyan
>
>     *From: *BIER <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>
>     *To: *Greg Shepherd <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>
>     *Cc: *"[email-masked] <mailto:[email-masked]><mailto:[email-masked]%20<mailto:[email-masked]>>" <[email-masked]
>     <mailto:[email-masked]>>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> f-bier-php/______;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7Cnpq
> vfA3s4r-JLyE8pK0PVq2FrBGNX$
>
>         __ __
>

>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> ______;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLy
> E8pK0PVq8rXWgdg$
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK
> 0PVq9z6N_yR$
>
>
>
> --
>
> <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!W
> s4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK0PVqyDf-6DB$ >
>
> *Gyan Mishra*
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK
> 0PVq9z6N_yR$
>

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK0PVq9z6N_yR$

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 24 Aug 2020 17:50:25 +0000

Hi Loa, Greg,

I've submitted -06 to take care of your comments.

Thanks.
Jeffrey

Juniper Business Use Only
From: BIER <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, August 24, 2020 11:16 AM
To: Loa Andersson <[email-masked]>; Gyan Mishra <[email-masked]>; Mankamana Mishra (mankamis) <mankamis=[email-masked]>
Cc: IJsbrand Wijnands (iwijnand) <iwijnand=[email-masked]>; Greg Shepherd <[email-masked]>; [email-masked]
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Hi Loa,

Please see zzh> below.

-----Original Message-----
From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Loa Andersson
Sent: Saturday, August 22, 2020 1:57 AM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Mankamana Mishra (mankamis) <mankamis=[email-masked]<mailto:mankamis=[email-masked]>>
Cc: IJsbrand Wijnands (iwijnand) <iwijnand=[email-masked]<mailto:iwijnand=[email-masked]>>; Greg Shepherd <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Working Group,

The draft says:

Zzh> It's a per node decision for all traffic to a particular "BFER" who does not really support BIER forwarding. PHP is not used when the BFERs do support BIER.

Zzh> So the context is that B does support BIER. In that case, A won't do PHP for B at all.

Works just fine.

/Loa

On 22/08/2020 05:20, Gyan Mishra wrote:
>     *From: *BIER <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>     *To: *Greg Shepherd <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>     *Cc: *"[email-masked] <mailto:[email-masked]><mailto:[email-masked]%20%3cmailto:[email-masked]%3e>" <[email-masked]
>     <mailto:[email-masked]>>
>         draft previously, but had no response. Let's do better. ____
>
>         __ __
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-iet>

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>

--

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK0PVq9z6N_yR$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK0PVq9z6N_yR$>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 24 Aug 2020 11:19:21 -0700

Hi Jeffrey,
thank you for your kind consideration of my comments and addressing them.

Regards,
Greg

On Mon, Aug 24, 2020 at 10:50 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Loa, Greg,
>
>
>
> I’ve submitted -06 to take care of your comments.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of * Jeffrey (Zhaohui)
> Zhang
> *Sent:* Monday, August 24, 2020 11:16 AM
> *To:* Loa Andersson <[email-masked]>; Gyan Mishra <[email-masked]>;
> Mankamana Mishra (mankamis) <mankamis=[email-masked]>
> *Cc:* IJsbrand Wijnands (iwijnand) <iwijnand=[email-masked]>;
> Greg Shepherd <[email-masked]>; [email-masked]
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-php
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Loa,
>
>
>
> Please see zzh> below.
>
>
>
> Cc: IJsbrand Wijnands (iwijnand) <iwijnand=[email-masked]>;
> Greg Shepherd <[email-masked]>; [email-masked]
> Zzh> It’s a per node decision for all traffic to a particular “BFER” who
> does not really support BIER forwarding. PHP is not used when the BFERs do
> support BIER.
>
>
>
> I would think that it is possible for one node to be the penultimate node
> for some traffic but not for other traffic, even though the traffic is sent
> to the same node, which can be both ultimate node, pen-ultimate node or
> transit node.
>
>
>
> header is not popped.
> > <mailto:[email-masked] <[email-masked]>>> wrote:
>
> >
>
> >     <mailto:[email-masked] <[email-masked]>>>
>
> >     <mailto:[email-masked] <[email-masked]>>>
>
> >         <mailto:[email-masked] <[email-masked]>>> wrote:____
>
> >
>
> >
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-iet>
>
> >         [email-masked] <mailto:[email-masked] <[email-masked]>>
>
> >
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>
>
> >     [email-masked] <mailto:[email-masked] <[email-masked]>>
>
> >
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!Ws4otxDsuVKTsaEjyRKVYz-hcmmmGgDiE7CnpqvfA3s4r-JLyE8pK0PVq9z6N_yR$>
>
>
>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 24 Aug 2020 12:06:21 -0700

Thanks Jeffrey and Greg. Loa, please confirm when you can that this rev
addresses your concerns.

Shep
(chairs)

On Mon, Aug 24, 2020 at 10:50 AM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> I've had time to read the draft a bit more in detail..
>
>
>
> > I support advancing this critical draft forward..  I agree that the PHP
>
> <loa.pi.nu@gmail..com>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 26 Aug 2020 01:21:45 +0000

Hi,

Support.

Few comments below:

==> The below text appears to give an impression that the router is BIER incapable at both control plane and data plane. This either can be clarified or can include a terminology explaining what it is.

“A BIER-incapable router, if acting as a multicast flow overlay
   router, MUST signal its BIER information as specified in [RFC8401] or
   [RFC8444] or [I-D.ietf-bier-idr-extensions]”

==> Section 2.1.1.1 of RFC8296 states that PHP MUST NOT be applied to BIER-MPLS-Label. While the below statement mandates the signaling of Imp-Null (which is to enable PHP). So I think the draft should update RFC8296?.

“With MPLS encapsulation, the BIER-incapable multicast flow overlay
   router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set
   the Label field in BIER MPLS Encapsulation sub-sub-TLV to Implicit
   Null Label [RFC3032].”

Regards,
Nagendra

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Date: Wednesday, August 12, 2020 at 11:31 PM
To: "[email-masked]" <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-php

- Shep
(Chairs)

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 25 Aug 2020 23:12:38 -0400

Thanks Jingrong for the graphical depiction of BIERv6 PSP and how it would
work.

The pop/delete in MPLS or SR-MPLS construct with MPLS-BIER we have the BIER
 L2.5 shim to be popped so BIERin6 pop is similar to MPLS PHP as we have a
L2.5 shim to be popped similar to MPLS shim.

With BIERv6 native encoding in DOH was not sure how it would be popped.
Looking at it further the SRv6 construct its PSP POP/Delete very similar to
SRV6 SRH PSP pop.  Makes sense DOH PSP is similar to SRH PSP.

Yes I remember all the many threads on 6MAN and in flight eh insertion or
removal violation of RFC 8200 contentious debate.

I agree that PSP would be beneficial for supporting Non BFR capable PEs and
agree with the behavior makes sense that the entire DOH would get popped
removed.

Thanks

Gyan

On Mon, Aug 24, 2020 at 3:30 AM Xiejingrong (Jingrong) <
[email-masked]> wrote:

> There is a thorough discussion in IETF community, especially 6man,  about
> Penultimate Segment Pop (PSP) ---- to Pop an EH when an IPv6 packet with
>
> EH reaches the node identified in the destination address [RFC8200 section
> 4].
>
>
> This thorough discussion has led to a wide consensus among IETF community,
> and led to the progress of draft-ietf-spring-srv6-network-programming-17
>
> to IETF last call.
>
>
>
>
>
> So for BIERv6, I think the PSP can be very well supported to provide
> incremental deployment for Non-BIER-capable PEs.
>
>
>
>
>
>
> Note, the whole DoH (not only the BIER option data) is popped/deleted when
> the BIERv6 packet is sent to the ultimate PE. Here is a diagram:
>
>
>
>
>
> A is BFIR, D is Non-BFR router but acting as a BFER requesting PSP
> (signaling defined in draft-ietf-bier-php), and both B and C are BFRs
> (could be
>
> BFERs at the same time).
>
>
>
>
>
> *From:* BIER [mailto:[email-masked]]
>
> *On Behalf Of *Gyan Mishra
>
>
> *Sent:* Saturday, August 22, 2020 5:21 AM
>
>
> *To:* Mankamana Mishra (mankamis) <mankamis=[email-masked]>
>
>
> *From:*BIER <[email-masked]> on behalf of "IJsbrand Wijnands
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
> *Network Solutions Architect *
>
>
>
>
>
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --

*Gyan Mishra*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 26 Aug 2020 11:17:20 +0000

Hi Nagendra,

Thanks for your comments. Please see zzh> below.

Juniper Business Use Only
From: BIER <[email-masked]> On Behalf Of Nagendra Kumar Nainar (naikumar)
Sent: Tuesday, August 25, 2020 9:22 PM
To: Greg Shepherd <[email-masked]>; [email-masked]
Subject: Re: [Bier] WGLC: draft-ietf-bier-php

Hi,

Support.

Few comments below:

"A BIER-incapable router, if acting as a multicast flow overlay
   router, MUST signal its BIER information as specified in [RFC8401] or
   [RFC8444] or [I-D.ietf-bier-idr-extensions]"

Zzh> How about adding the following paragraph after the above paragraph?

   This implies that while the router is not capable of BIER forwarding,
   It is capable of BIER control plane signaling.

"With MPLS encapsulation, the BIER-incapable multicast flow overlay
   router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set
   the Label field in BIER MPLS Encapsulation sub-sub-TLV to Implicit
   Null Label [RFC3032]."

Zzh> The spirit of that text in 8296 is to say that the BIER label must not be PHP'ed *while keeping the BIER header*. We're talking about PHP the entire BIER header, so it should be ok.
Zzh> Thanks!
Zzh> Jeffrey

Regards,
Nagendra

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 12, 2020 at 11:31 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] WGLC: draft-ietf-bier-php

Please read and respond to this thread. We had a WGLC for this draft previously, but had no response. Let's do better.

https://datatracker.ietf.org/doc/draft-ietf-bier-php/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-php/__;!!NEt6yMaO-gk!X57YgScMQ6-UzHN2e-eSA0qNoCKChF6120YQDXdlETmDlz491I0Zs0W8wVo0fv-1$>

- Shep
(Chairs)

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 31 Aug 2020 08:18:11 -0700

Loa,

Can you please review Jeffrey's changes to confirm they address your
concerns? If so, then we can move this along.

Thanks,
Greg