Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Jeffrey (Zhaohui) Zhang]

Hi,

When it comes to SR-P2MP state downloading, there are three aspects involved 
here:


  1.  NLRI to encode policy information
  2.  NLRI to encode  identification
  3.  Tunnel Encapsulation Attribute (TEA) that encodes actual replication 
branches

The major difference between the two ways is on #3. Indeed, we could not reach 
consensus - there are two ways of encoding the TEA and each has its own 
considerations. The draft-ietf-bess way (even when used for SR-P2MP) is aligned 
with other non-SR multicast trees (IP/mLDP) for a unified approach, while 
draft-hb is aligned to unicast BGP SR policy.

I want to initiate a discussion and I can understand that WGs may eventually 
choose to allow both ways for #3. Even so, I think we should strive for 
consistent approach at least for #1 and #2 (and for that I am not saying that 
draft-ietf-bess way must be used). For example, use the same SAFI and route 
types for both ways, but use different TEA encoding methods.

Thanks.

Jeffrey



Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) 
Sent: Friday, March 25, 2022 11:34 AM
To: Jeffrey (Zhaohui) Zhang ; Susan Hares 
; i...@ietf.org
Cc: 'p...@ietf.org' ; 'BESS' 
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

Hi All

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to 
discuss the two ways and figure out how to proceed. The authors have discussed 
before though we have not reached consensus.

HB> yes there was discussion and there was no consensus to merge the 2 drafts 
as their approach is widely different. The authors of this draft have kept the 
implementation very close to unicast BGP SR Policy for the segment list, which 
simplifies the implementation and deployment of the technology. As you said 
there seems to be two way to download this policy and the segment list and we 
can work on both.
Given the solid support I don't see why the adoption of this draft should  be 
delayed because of these arguments.

Thanks
Hooman

From: pim mailto:pim-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 10:47 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org
Cc: 'p...@ietf.org' mailto:p...@ietf.org>>; 'BESS' 
mailto:bess@ietf.org>>
Subject: Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - 
Adoption call

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. 
Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through 
those to see if I have any addition/follow-up on those.



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with 
daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

IDR WG:

If you just wish to respond to the IDR list,
you may respond to this email on the adoption call.

Cheers, Sue

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: i...@ietf.org; p...@ietf.org; 
bess@ietf.org
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

Zzh> I want to point out that 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
 is another way to do the same. I also explained in 
https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
 why it was in the bess WG.
Zzh> In

Re: [bess] [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Xiejingrong (Jingrong)]

Hi,

I have always had my opinion that Multicast Tree Building procedure is a very 
dynamic procedure, however BGP is skilled at stable-data (like prefix, or 
aggregated MVPN state on edge of a provider) driven “PUSH” thing.

I have almost forget the detail of the draft-ietf-bess-bgp-multicast-controller 
through I had read it long ago.

I would suggest that the relationship of the draft-ietf-bess and the polling 
draft can be re-evaluated.

Thanks,
Jingrong


From: pim [mailto:pim-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, March 28, 2022 4:47 PM
To: Susan Hares 
Cc: i...@ietf.org; Shraddha Hegde ; 
p...@ietf.org; BESS ; Jeffrey (Zhaohui) Zhang 

Subject: Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) 
- Adoption call

Hi,

It also needs to be observed that  draft-ietf-bess-bgp-multicast-controller has 
a broader scope and also covers mLDP functionality what may be extremely useful 
for networks which are not green field and would like to transition from 
current to new multicast trees.

Having solution in IDR which covers multicast tree setup partially and at the 
same time a more complete one which has been already adopted and is progressing 
as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which are 
used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS with 
draft-ietf-bess-bgp-multicast-controller since that WG is center of gravity for 
all VPN/multi-tenant multicast related work.

Kind regards,
Robert


On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
WG,

I agree with Jeffrey that the BESS adopted draft 
draft-ietf-bess-bgp-multicast-controller provides
Solution in the same problem space. It is good to discuss the two drafts before 
adopting
draft-hb-idr-sr-p2mp-policy in IDR.

Rgds
Shraddha



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 8:17 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org
Cc: 'p...@ietf.org' 
mailto:p...@ietf.org>>; 'BESS' 
mailto:bess@ietf.org>>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. 
Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through 
those to see if I have any addition/follow-up on those.



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 
i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with 
daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey



Juniper Business Use Only
From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: i...@ietf.org
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption 
call

[External Email. Be cautious of content]

IDR WG:

If you just wish to respond to the IDR list,
you may respond to this email on the adoption call.

Cheers, Sue

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: i...@ietf.org; p...@ietf.org; 
bess@ietf.org
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

Zzh> I want to point out that 
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
 is another way to do the same. I also explained in 
https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
 why it was in the bess WG.
Zzh> In addition, the bess draft supports *other* mult

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[Robert Raszuk]

Hi,

It also needs to be observed that
draft-ietf-bess-bgp-multicast-controller has a broader scope and also
covers mLDP functionality what may be extremely useful for networks which
are not green field and would like to transition from current to new
multicast trees.

Having solution in IDR which covers multicast tree setup partially and at
the same time a more complete one which has been already adopted and is
progressing as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which
are used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS
with draft-ietf-bess-bgp-multicast-controller since that WG is center of
gravity for all VPN/multi-tenant multicast related work.

Kind regards,
Robert


On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde  wrote:

> WG,
>
>
>
> I agree with Jeffrey that the BESS adopted draft
> draft-ietf-bess-bgp-multicast-controller provides
>
> Solution in the same problem space. It is good to discuss the two drafts
> before adopting
>
> draft-hb-idr-sr-p2mp-policy in IDR.
>
>
>
> Rgds
>
> Shraddha
>
>
>
> Juniper Business Use Only
>
> *From:* Idr  *On Behalf Of * Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 8:17 PM
> *To:* Susan Hares ; i...@ietf.org
> *Cc:* 'p...@ietf.org' ; 'BESS' 
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> [+ BESS, PIM]
>
>
>
> Hi,
>
>
>
> I realized that in a hurry I did not respond to the specific questions
> below. Please see zzh> next to the questions.
>
>
>
> Looks like that there are some comments on BESS/PIM list and I will go
> through those to see if I have any addition/follow-up on those.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr  *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 6:30 AM
> *To:* Susan Hares ; i...@ietf.org
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> I am sorry for responding late. I somehow missed this.
>
>
>
> I think we should discuss the relationship with
> daft-ietf-bess-bgp-multicast-controller further before adopting this.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr  *On Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 10:28 AM
> *To:* i...@ietf.org
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> IDR WG:
>
>
>
> If you just wish to respond to the IDR list,
>
> you may respond to this email on the adoption call.
>
>
>
> Cheers, Sue
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org ] *On
> Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 9:55 AM
> *To:* i...@ietf.org; p...@ietf.org; bess@ietf.org
> *Subject:* [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
>
>
>
> This begins a 2 week WG adoption call for:
>
> draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)
>
>
>
> You can obtain the draft at:
>
> https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/
> 
>
>
>
> In your comments for this call please consider:
>
>
>
> Zzh> I want to point out that
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
> 
> is another way to do the same. I also explained in
> https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
> 
> why it was in the bess WG.
>
> Zzh> In addition, the bess draft supports **other** multicast trees (IP,
> mLDP besides SR-P2MP) using a consistent way.
>
>
>
> 1)  Does this technology support the SR P2MP features
>
> that distributes candidate paths which connect
>
> a multicast distribution tree (tree to leaves).
>
>
>
> Zzh> It is one way to use BGP to support that. The bess draft specifies
> another way.
>
>
>
> 2) Is the technology correctly specified for the
>
> NLRI (AFI/SAFI) and the tunnel encapsulation attribute
>
> additions (sections 2 and 3)?
>
>
>
> Zzh> The specified SAFI and tunnel encapsulation attribute additions are
> one way for the BGP signaling for SR-P2MP. The bess draft specifies another
> way.
>
>
>
> 3) Does the P2MP policy operation (section 4)
>
> provide enough information for those implementing this
>
> technology and those deploying the technology?
>
>
>
> 4) Do you think this multicast techn