Re: [Idr] 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 Huaimo, Sue,

Regarding the last issue:


Zzh> 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.

[HC]: This provides a way for the ingress to create a forwarding entry.



My view is that (source, group) information should not be part of the TEA, just like that in unicast case, the TEA would not include prefix information (that would use the TEA). My impression is that in RFC9012, the only information in TEA that is used for traffic selection is color information, but no prefix information is included. Specifying which prefix (destination in case of unicast and <source, group> in case of multicast) uses the TEA should be done outside the TEA.



Thanks.

Jeffrey




Juniper Business Use Only
From: BIER <[e-mail]> On Behalf Of Huaimo Chen
Sent: Tuesday, July 5, 2022 9:54 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; idr@ietf. org <[e-mail]>
Subject: Re: [Bier] 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]

Hi Jeffrey,

    Thank you very much for your valuable comments and questions.
    My answers or explanations to them are inline below with [HC].

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, July 5, 2022 10:49 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; idr@ietf. org <[e-mail]<mailto:[e-mail]>>; Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Subject: RE: WG adoption call for draft-chen-idr-bier-te-path-04.txt (6/22/2022 to 7/6/2022


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.

[HC]: I will make it to be used for BIER as well.



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

[HC]:  I will rename "Path BitPositions" as you suggested.



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.

[HC]: I will keep one way and remove the other two.



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.

[HC]: I will remove the redundant parts.



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.

[HC]: This provides a way for the ingress to create a forwarding entry.



Thanks.
Jeffrey







Juniper Business Use Only

From: BIER <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: Wednesday, June 22, 2022 12:11 PM
To: [e-mail]<mailto:[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:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fidr*2FtKgu_S5_32_l5YzWfO8481hpRRY*2F__*3B!!NEt6yMaO-gk!GqXTDxXaxzr0khnkwzdV8s2VzxJvZS3K8Ut_pKW2DXOpHrVhxoggde3_19XsyJzRDllqSowqGSy-phY*24&data=05*7C01*7Chuaimo.chen*40futurewei.com*7C76fa2f88bceb4b9a692408da5e9589c1*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637926293615396488*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=lKoJupcrV0PjcJaEc*2BGviQRXuWNSWVeYimtDJKtjQyQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!F1XZUrP2hPNoJ5adnf3kw2XvcJA53zq74UUFy_RtqBZOSpqi-Z4DNGMDBpn8028rgjR3m5TcOsnXGdmFRdKNHGoa$>



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:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-chen-idr-bier-te-path*2F__*3B!!NEt6yMaO-gk!GqXTDxXaxzr0khnkwzdV8s2VzxJvZS3K8Ut_pKW2DXOpHrVhxoggde3_19XsyJzRDllqSowqXwBnHWo*24&data=05*7C01*7Chuaimo.chen*40futurewei.com*7C76fa2f88bceb4b9a692408da5e9589c1*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637926293615396488*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=HTJbBnxo0NG5GgvWVdcYESQaTz*2FlbC98*2BARgVWyP*2FyA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!F1XZUrP2hPNoJ5adnf3kw2XvcJA53zq74UUFy_RtqBZOSpqi-Z4DNGMDBpn8028rgjR3m5TcOsnXGdmFRR9eQQQ3$>).



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