Hi Cheng,
I assume you are recommending the use of Route Origin Extended Community
(https://tools.ietf.org/html/rfc4360#section-5) for conveying the "Originator"
when the SR Policy update is propagated over eBGP sessions via other eBGP/iBGP
sessions instead of direct peering with the headend.
I believe it does address the scenario you describe given that it is expected
that SR Policy propagation via BGP is happening within a single administrative
domain even if it comprises of multiple ASes.
Also copying the IDR WG for inputs since this would likely need to be updated
in draft-ietf-idr-segment-routing-te-policy.
Thanks,
Ketan
From: spring <spring-boun...@ietf.org> On Behalf Of Chengli (Cheng Li)
Sent: 30 April 2020 07:34
To: draft-ietf-spring-segment-routing-pol...@ietf.org
Cc: SPRING WG <spring@ietf.org>; huruizhao <huruiz...@huawei.com>; Fangsheng
<fangsh...@huawei.com>
Subject: [spring] Comments: Route Origin Community in SR
Policy(draft-ietf-spring-segment-routing-policy)
Hi authors,
In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced how
the node-address of "Originator of CP(Candidate Path)" is generated when the
Protocol-Origin is BGP. It says:
"Protocol-Origin is BGP SR Policy, it is provided by the BGP component on
the headend and is:
o the BGP Router ID and ASN of the node/controller signalling the
candidate path when it has a BGP session to the headend, OR
o the BGP Router ID of the eBGP peer signalling the candidate path along
with ASN of origin when the signalling is done via one or more intermediate
eBGP routers, OR
o the BGP Originator ID [RFC4456] and the ASN of the node/controller
when the signalling is done via one or more route-reflectors over iBGP
session."
In the operator's network, in order to reduce the number of BGP sessions in
controller and achieve scalability, the controller only establishes eBGP peer
with the RR. And the RR establishes iBGP peers with the headends. As mentioned
in the draft, the headend will use the RR's Router ID as the CP's node-address
(the signaling is done via route transmission from RR to the headend instead of
route reflection). The headend needs to carry the CP's key when reporting the
SR Policy status to the controller through BGP-LS. And there is a problem that
the controller may not recognize the key because the node-address is generated
by the RR node.
For network robustness, two or more RRs are usually deployed. This will
introduce another problem.. When the same CP advertised by the controller is
delivered to the headend through different RRs, the headend cannot distinguish
whether it is the same CP because the node-address in the CPs' key comes from
different RRs.
To solve these problems, We recommend carrying the Route Origin Community
(defined in RFC 4360) directly when the controller advertises BGP routes. In
this way, the key of the CP is determined by the controller and will not
change during the advertisement of BGP routes.
Thanks,
Cheng
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
