Hi Hannes,
Thanks for the correction. My previous description is not accurate.
What I try to say is that, the operator can run either IGP or BGP on the SF
nodes based on the network deployment consideration.
If a network is deployed as shown in the figure below, we can choose to use IGP
to advertise the SF information intra AS and BGP-LS to collect these
information per AS.
SR-C
^ ^
BGP | | BGP
+------------+ +----------+
| |
node1 nodeN
^ ^
| IGP | IGP
+-------------+ +-------------+
|SF11 SF12 | |SFN1 SFN2 |
|..... | ... |..... |
| (IGP AS 1) | | (IGP AS N) |
+-------------+ +-------------+Regards,
Yao
原始邮件
发件人：HannesGredler <[email protected]>
收件人：刘尧00165286;
抄送人：Acee Lindem <[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
日 期 ：2020年07月29日 15:14
主 题 ：Re: [Lsr] "IGP Extensions for Segment Routing Service
Segment"-draft-lz-lsr-igp-sr-service-segments-02
Yao,
BGP-LS was designed to solve also the distribution of link-state information
between BGP speakers (see Figure 1 from RFC 7752 below).
Just ask yourself: why would one want to use a point to multipoint state
replication protocol as complex as BGP for *just* client server alike
replication ?
We wanted from day-1 to leverage the graph independent replication abilities of
BGP - so doing inter BGP-LS graphs is a legit use-case.
HTH,
/hannes
---
The collection of link-state and TE information and its distribution
to consumers is shown in the following figure.
+-----------+
| Consumer |
+-----------+
^
|
+-----------+
| BGP | +-----------+
| Speaker | | Consumer |
+-----------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
Figure 1: Collection of Link-State and TE Information
---
On 29.07.2020, at 03:57, [email protected] wrote:
Hi Acee,
Thanks for reading the draft.
Yes, the main purpose of this draft is to carry the segment segment information
via IGP so only one node per AS need to be connected with the controller
through BGP-LS.
With the existing BGP-LS extension draft, it is certainly one solution to
configure BGP sessions between all the service function nodes and controller,
and each node sends the SF information to the controller individually.
And if I get you right, we can also select one node to have a BGP session with
the controller and configure BGP sessions between the selected node and SF
nodes.
But how the selected node get the SF information from SF nodes via BGP needs to
be solved, since BGP-LS is typically used for exchanging information between
the south and north rather than nodes of the same level, and there's no other
existing BGP extension for distribute SIDs information between nodes .
This draft aims to provide an alternate way if the operators prefer running IGP
on SF nodes.
So we would like to collect comments on the WG session to see how others think
about it.
Regards,
Yao
_______________________________________________Lsr mailing
[email protected]https://www.ietf.org/mailman/listinfo/lsr
发件人：AceeLindem(acee) <[email protected]>
收件人：刘尧00165286;[email protected] <[email protected]>;
抄送人：[email protected] <[email protected]>;
日 期 ：2020年07月29日 01:53
主 题 ："IGP Extensions for Segment Routing Service Segment"
-draft-lz-lsr-igp-sr-service-segments-02
Speaking as WG member:
It seems the sole purpose of this draft is to get service segment information
from nodes in the IGP domain to the IGP node that has a BGP session with the
controller. You don’t need to put this information
into the IGP in order to do this. Simply configure BGP sessions for the BGP-LS
AF between the nodes with service functions and the node selected to have a BGP
session with the controller.
Speaking as WG Chair – please let me know if we can omit this draft from the
agenda.
Thanks,
Acee
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
