Re: [Bier] WG adoption call for draft-chen-idr-bier-te-path-04.txt (6/22/2022 to 7/6/2022

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi,

I have the following comments/questions:

I don't think this need/should be BIER-TE specific. It can be used for regular BIER as well - it does not matter if the BitStrings are just for encoding BFERs (as in BIER) or for encoding replication points.

"Path BitPositions" would be better named to just "BitString". Even in BIER-TE it is BitString.

Instead of describing three ways of propagating BGP update messages, only one way should be used - don't use NO-ADVERTISE and always use route target (and once the RT match stop re-advertising). Just let the BGP infrastructure takes care of it.

Why do we need SI-len, subdomain-id, MT-id, and BIFT-id in the Path BitPositions Sub-TLV? Tunnel-Identifier in the NLRI already has subdomain-id information. I don't see how SI-len, MT-id and BIFT-id will be used. With subdomain-id from the NLRI and the SI-id from the sub-tlv you should have all the information you need.

I am not sure if we should encode Traffic Description Sub-TLVs especially (source, group) information in the TEA. I can understand encoding color information in original TEA, but encoding (source, group) information is like encoding prefix information in TEA.

Thanks.
Jeffrey




Juniper Business Use Only
From: BIER <[e-mail]> On Behalf Of Susan Hares
Sent: Wednesday, June 22, 2022 12:11 PM
To: [e-mail]
Subject: [Bier] FW: WG adoption call for draft-chen-idr-bier-te-path-04.txt (6/22/2022 to 7/6/2022

[External Email. Be cautious of content]

Bier WG:

IDR has begun an adoption call for draft-chen-idr-bier-te-path-04.txt.
Since this document specifies BGP mechanisms
(an NLRI and additions to the BGP TEA).

We welcome your comments on this draft on the IDR thread:
(click below to go directly to the mail thread online)
https://mailarchive.ietf.org/arch/msg/idr/tKgu_S5_32_l5YzWfO8481hpRRY/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/tKgu_S5_32_l5YzWfO8481hpRRY/__;!!NEt6yMaO-gk!GqXTDxXaxzr0khnkwzdV8s2VzxJvZS3K8Ut_pKW2DXOpHrVhxoggde3_19XsyJzRDllqSowqGSy-phY$>

IDR is focused on operational deployments so we'd also
appreciate your input on how this draft might aid or impact
BIER deployments.

Another avenue of input is to provide feedback directly to the
bier chairs.   The IDR Chairs will be checking with the bier chairs
prior to finalizing the adoption of this attribute.

Cheers,
Sue Hares
(IDR co-chair, document shepherd)

From: Susan Hares
Sent: Wednesday, June 22, 2022 12:05 PM
To: [e-mail]<mailto:[e-mail]>
Subject: WG adoption call for draft-chen-idr-bier-te-path-04.txt (6/22/2022 to 7/6/2022

This begins a 2 week Adoption call (6/22/2022 to 7/6/2022)
for draft-chen-idr-bier-te-path-04.txt
(https://datatracker.ietf.org/doc/draft-chen-idr-bier-te-path/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-chen-idr-bier-te-path/__;!!NEt6yMaO-gk!GqXTDxXaxzr0khnkwzdV8s2VzxJvZS3K8Ut_pKW2DXOpHrVhxoggde3_19XsyJzRDllqSowqXwBnHWo$>).

This draft provides extensions to BGP to distribute BIER
(bit replication traffic/tree) data via BGP using a
new NLRI (AFI = IPv4 or IPv6, new SAFI) and
new options for the Tunnel Encapsulation Attribute (TEA).
The NLRI includes an RD + Bier Domain tunnel identifier.

In your comments, please consider if this draft:

1) Does this draft specify appropriate BGP mechanisms for
a controller to distribute bier information?

2) Does this mechanism correctly integrates into
a) the BIER architecture (draft-ietf-bier-te-arch) and
b) Multicast VPNs (BESS)?

3) Will this technology aid the deployment of
Bier multicast forwarding in operational networks?

Cheers, Sue