Hi Ketan, Thanks. You have answered my question. Because then like it is discussed in RFC 4271 Appendix F1 Path attribute could be one per many prefixes (up to 4k BGP message size). Hence, built-in BGP-4 optimization applies.
PS: I was looking at https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Where “Prefix-SID TLV Types” is shown outside of BGP Path Attributes context. My fault. I did need to read RFC8669 where “Prefix-SID TLV Types” was introduced. Eduard From: Ketan Talaulikar [mailto:[email protected]] Sent: Friday, January 14, 2022 7:07 AM To: Vasilenko Eduard <[email protected]> Cc: [email protected]; [email protected] Subject: Re: How often "Prefix-SID TLV" is needed? (draft-ietf-bess-srv6-services question) Hi Eduard, BGP Prefix-SID is actually a BGP Path Attribute (refer https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2). I hope that explains the correlation between the path and what's carried in the BGP Prefix-SID attribute TLVs for SRv6. That said, I am not sure if I've understood and answered your question. Thanks, Ketan On Wed, Jan 12, 2022 at 10:12 PM Vasilenko Eduard <[email protected]<mailto:[email protected]>> wrote: Dear Authors, Ordinary BGP services use “BGP Path Attributes” (with MP_REACH_NLRI and Extended Communities inside Path Attribute). SRv6 needs additionally to explain the structure of SID. ”BGP Prefix SID TLV” was chosen for this task. This TLV is at the same BGP level, not inside Path Attribute. So far so good. I am trying to understand how the correlation should be done between routes sent inside “Path Attributes” and SID structure sent inside “Prefix SID TLV”. 1. Potentially it is possible to send the SID structure 1 time. Remote PE could calculate “Label Filed” by transposition scheme out of full SID and put it in some table. Then for every route received in Path Attribute it would be possible to check that such “Label Filed” is already known from this next hop. If known then it is possible to reconstruct full SID and use it for SRH or whatever. 2. The alternative solution is to always supply ”BGP Prefix SID TLV” together with every route in “BGP Path Attributes”. (chatty approach) Then a separate table is not needed – it is possible to derive SID directly out of ”BGP Prefix SID TLV” that is always attached to the route. I have not understood what strategy is assumed by “draft-ietf-bess-srv6-services”. I have not found any recommendation on this matter. Potentially it could create an interoperability issue if one side would choose option 1, but the remote side would be capable only to option 2. [cid:[email protected]] Best Regards Eduard Vasilenko Senior Architect Europe Standardization & Industry Development Department Tel: +7(985) 910-1105, +7(916) 800-5506
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
