Subject: [bess] How often "Prefix-SID TLV" is needed? (draft-ietf-bess-srv6-services question)

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 12 Jan 2022 16:42:37 +0000

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.

Best Regards
Eduard Vasilenko
Senior Architect
Europe Standardization & Industry Development Department
Tel: +7(985) 910-1105, +7(916) 800-5506

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 14 Jan 2022 09:36:41 +0530

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-masked]> 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.
> 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.
>
>
>
>
> Best Regards
>
> Eduard Vasilenko
>
> Senior Architect
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 14 Jan 2022 13:55:16 +0000

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-masked]]
Sent: Friday, January 14, 2022 7:07 AM
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]; [email-masked]
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.

Thanks,
Ketan

On Wed, Jan 12, 2022 at 10:12 PM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> 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.

Best Regards
Eduard Vasilenko
Senior Architect