Subject: [mpls] Working Group Adoption Poll (WGAP) on draft-mirsky-mpls-p2mp-bfd

From: Loa Andersson <[email-masked]>
Date: Tue, 14 Dec 2021 06:36:23 +0800

Working Group,

This is to start a two week poll on adopting
  draft-mirsky-mpls-p2mp-bfd
as a MPLS working group document.

Though "two weeks" brings all the way into the holiday season. so it 
will be a bit longer.

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is no IPRs disclosure against this document.

The authors have all stated on the MPLS wg mailing list that they are
unaware of any IPRs that relates to this document.

The working group adoption poll ends January 4, 2022.

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 13 Dec 2021 17:31:30 -0800

Yes/support (as the co-author).

This document provides specifications also essential for the work conducted
by the BIER and SPRING WGs.

Regards,
Greg

---

From: Italo Busi <[email-masked]>
Date: Fri, 17 Dec 2021 10:12:59 +0000

Hi Loa, all,

I have read the draft during the MPLS-RT review and I support its adoption as WG document

Italo

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: lunedì 13 dicembre 2021 23:36
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] Working Group Adoption Poll (WGAP) on draft-mirsky-mpls-
> p2mp-bfd
> 
> Working Group,
> 
> Though "two weeks" brings all the way into the holiday season. so it will be a
> bit longer.
> 
> Please send your comments (support/not support) to the mpls working group
> mailing list ([email-masked]). Please give a technical motivation for your
> support/not support, especially if you think that the document should not be
> adopted as a working group document.
> 
> The authors have all stated on the MPLS wg mailing list that they are unaware
> of any IPRs that relates to this document.
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 20 Dec 2021 09:47:10 +0000

Hi group,

Support adoption.

Best
Xuesong

> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, December 14, 2021 6:36 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] Working Group Adoption Poll (WGAP) on
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 22 Dec 2021 03:14:39 +0000

Hi Loa, 

I've read this document and support its adoption. 

I have one comment which could be resolved either before or after the adoption.

Section 3.2 describes the Non-IP Encapsulation of Multipoint BFD, in which a new ACH channel type is defined, and it says a Source Address TLV MUST immediately follow a BFD control message. 

I'd suggest to provide a figure of the packet format of non-IP Multipoint BFD encapsulation. And one related question is: is the source address TLV considered as part of the Multipoint BFD packet or not?

Best regards,
Jie

> group mailing list ([email-masked]). Please give a technical motivation for your

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Dec 2021 22:37:20 -0500

Hi Loa,

I support WG Adoption as Co-Author.

This draft provides a procedural improvement to RFC 8562 BFD for P2MP networks
and BFD for P2MP networks with active tails and applicability to SR P2MP
policy over SR-MPLS data plane.

This draft details the applicability solutions for in-band bootstrap
of BFD session
utilizes LSP ping in BFD Demand mode  to detect localized defects via
bootstrap of multipoint tail target FEC for P2MP LSP.

Also provides out of band solution to bootstrap multipoint BFD session on a
tail utilizing using BGP BFD attribute RFC 9026 using RFC 8563 updated
procedure for active tails with unsolicited notification with P2MP LSP.

This draft provides a significant improvement for operators in BFD detection
of MVPN P2MP LSP data plane failures applicable to stateless multicast with
SR P2MP policy and BIER.

Kind Regards

Gyan

On Tue, Dec 21, 2021 at 10:15 PM Dongjie (Jimmy) <jie.dong=
[email-masked]> wrote:

> Section 3.2 describes the Non-IP Encapsulation of Multipoint BFD, in which
> a new ACH channel type is defined, and it says a Source Address TLV MUST
> immediately follow a BFD control message.
>
> I'd suggest to provide a figure of the packet format of non-IP Multipoint
> BFD encapsulation. And one related question is: is the source address TLV
> considered as part of the Multipoint BFD packet or not?
>
> Best regards,
> Jie
>
> will be a
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Yangfan(Fan,IP Standards)" <[email-masked]>
Date: Wed, 22 Dec 2021 08:49:02 +0000

Hi MPLS,

The draft draft-mirsky-mpls-p2mp-bfd provides a useful mechanism to detect failures along P2MP MPLS LSPs. Thus, I support the adoption. 
In addition, I have the same question on the TLV which Jimmy pointed out, as BFD doesn't define any optional TLV in ctrl packet format. It would be good to clarify it in future revisions.

Regards,
Fan 

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, December 22, 2021 11:15 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Working Group Adoption Poll (WGAP) on draft-mirsky-mpls-p2mp-bfd

Hi Loa, 

Best regards,
Jie

> group mailing list ([email-masked]). Please give a technical motivation 
> for your support/not support, especially if you think that the 
> document should not be adopted as a working group document.
>

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Wed, 22 Dec 2021 18:08:39 +0900 (KST)

Hi, all.

I support the WG adoption of this draft.

Best regards,

Jeong-dong

-----Original Message-----
From:  "Loa Andersson" <[email-masked]>
To:     "[email-masked]" <[email-masked]>; 
Cc:      <[email-masked]>;  "[email-masked]" <[email-masked]>; 
Sent:  2021-12-14 (화) 07:37:09 (UTC+09:00)
Subject: [mpls] Working Group Adoption Poll (WGAP) on draft-mirsky-mpls-p2mp-bfd

Working Group,

/Loa

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Dec 2021 10:05:30 -0800

Hi Jie,
thank you for your kind words and suggestions. Will work on adding the
figure to the draft. In case of the Non-IP encapsulation of Multipoint BFD,
the Source Address TLV is considered as part of the message on the message
on the new Generalized Associated Channel Type (Multipoint BFD Session).
That message includes BFD Control message and the Source Address TLV. We'll
display these =lements in the new figure.

Happy Holidays to All!

Kind regards,
Greg

On Tue, Dec 21, 2021 at 7:14 PM Dongjie (Jimmy) <[email-masked]> wrote:

> for your

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Dec 2021 17:00:04 -0800

Hi Jie,
following on your suggestion, I've added the figure in the working version.
I greatly appreciate it if you can check the attached diff and let me know
if I've got your idea right.

Regards,
Greg

On Wed, Dec 22, 2021 at 10:05 AM Greg Mirsky <[email-masked]> wrote:

>> Section 3.2 describes the Non-IP Encapsulation of Multipoint BFD, in
>> which a new ACH channel type is defined, and it says a Source Address TLV
>> MUST immediately follow a BFD control message.
>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 28 Dec 2021 02:02:18 +0000

Hi Greg,

Thanks for the quick update, the figure looks good.

I noticed that the type of the Source Address TLV is set to 0, which aligns with the type defined in the “G-ACh Advertisement Protocol TLV Registry”  in RFC 7212. While since this draft introduces a new channel type, does this mean a new registry for the TLVs under this new channel type is needed, or they can share the same registry?

Best regards,
Jie

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, December 23, 2021 9:00 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Working Group Adoption Poll (WGAP) on draft-mirsky-mpls-p2mp-bfd

Hi Jie,
following on your suggestion, I've added the figure in the working version. I greatly appreciate it if you can check the attached diff and let me know if I've got your idea right.

Regards,
Greg

On Wed, Dec 22, 2021 at 10:05 AM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jie,
thank you for your kind words and suggestions. Will work on adding the figure to the draft. In case of the Non-IP encapsulation of Multipoint BFD, the Source Address TLV is considered as part of the message on the message on the new Generalized Associated Channel Type (Multipoint BFD Session). That message includes BFD Control message and the Source Address TLV. We'll display these =lements in the new figure.

Happy Holidays to All!

Kind regards,
Greg

On Tue, Dec 21, 2021 at 7:14 PM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

Best regards,
Jie

> From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loa Andersson
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> group mailing list ([email-masked]<mailto:[email-masked]>). Please give a technical motivation for your
> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Dec 2021 18:34:10 -0800

Hi Jie,
thank you for the feedback. Please find my notes in-line below under the
GIM>> tag.

Regards,
Greg

> Thanks for the quick update, the figure looks good.
GIM>> Thanks! Will wait for Loa to guide us on when to upload the new
version.

>
>
> I noticed that the type of the Source Address TLV is set to 0, which
> aligns with the type defined in the “G-ACh Advertisement Protocol TLV
> Registry”  in RFC 7212. While since this draft introduces a new channel
> type, does this mean a new registry for the TLVs under this new channel
> type is needed, or they can share the same registry?
>
GIM>> You're right. Our intention is to re-use the existing TLV unless
we've missed something preventing that.

>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Thursday, December 23, 2021 9:00 AM
> *To:* Dongjie (Jimmy) <[email-masked]>
> *Cc:* Loa Andersson <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [mpls] Working Group Adoption Poll (WGAP) on
> following on your suggestion, I've added the figure in the working
> version. I greatly appreciate it if you can check the attached diff and let
> me know if I've got your idea right.
>
>
>
> Regards,
>
> Greg
>
>
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Dec 2021 14:55:17 +0800

Greg, Jie, Working Group,

> GIM>> Thanks! Will wait for Loa to guide us on when to upload the new 

The WGAP ends on January 4th, which likely mean that I will call it on 
the morning of the 5, asking you to post the -00 version of the wg 
document (unless something totally unexpected happens), with no other 
changes as compared to the document that we polled than administrativia 
(date, version-number and file name). When that version is posted you 
are free to incorporating changes suggested in the wgap.

/Loa
>     ____
>     __

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 28 Dec 2021 17:18:58 -0500

I support adoption of this draft as a co-author.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]