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, liu.ya...@zte.com.cn 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
> 
> 
> 
> 
> 
> 
> 
> 原始邮件
> 发件人:AceeLindem(acee) <a...@cisco.com>
> 收件人:刘尧00165286;zzhang_i...@hotmail.com <zzhang_i...@hotmail.com>;
> 抄送人:lsr@ietf.org <lsr@ietf.org>;
> 日 期 :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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to