Re: [Teas] draft-xie-idr-bgpls-sr-vtn-mt (and draft-zzhang-teas-network-slicing-with-flex-te)

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jie,

Please see zzh> below.


Juniper Business Use Only

-----Original Message-----
From: Dongjie (Jimmy) <[e-mail]> 
Sent: Friday, August 7, 2020 4:50 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]; [e-mail]; Lizhenbin <[e-mail]>
Subject: RE: draft-xie-idr-bgpls-sr-vtn-mt

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your suggestion and information about the Flexible TE draft.

I reviewed your draft, my reading is essentially it only allow the edge nodes to perform per-algo SPF, and only adj-SIDs are used for the SR path. I have a few questions about this document. Could you please help to clarify them?

1. Are the link admin-groups configured on each link in the network? Or they are provisioned on the controller, then distributed only to the edge nodes?

Zzh> They're only configured on the controller, and then either distributed only to relevant edge nodes (if we don't want all the nodes to be involved in per-algo info and calculation) or to all nodes (if the scaling is not a concern but we want to remove the burden of distributed provisioning and flooding).

2. With the proposed mechanism, will IGP still be used for the distribution of Flex-Algo definition, the link admin-group information and the algo-specific SIDs? And are per-algo SIDs still needed?

Zzh> For the case of calculation only on relevant edge nodes, LAGs and FADs are only distributed to those nodes using BGP not IGP. Per-algo SIDs are needed only if the edge-calculated SR-TE path with adjacency-SIDs is too long (last paragraph of section 1.3), and in that case the per-algo SIDs should only be distributed to relevant edge routers using BGP, also using the Bitmask RT for filtering.

3. After an edge node performs per-algo SPF, does it generate a SR policy locally for the calculated SR-TE path?

Zzh> The end result is that it uses the calculated SR-TE path to send traffic. Yes that could be via locally generated SR policy (my understanding is that SR policy is not necessarily tied to controllers).

4. It proposes to use BGP-LS with RT for targeted FAD and link-state information distribution, as discussed in the IDR meeting, some reasons about why BGP-LS or BGP is suitable for this would be needed.

Zzh> I actually missed that discussion. Do you mean why BGP-LS vs. BGP, or why BGP/BGP-LS vs. other means? It seems that BGP-LS is most natural - we already have BGP-LS northbound for routers to send Link information to controllers and the same can be used for controllers to send to routers, except that we use BitMask RT to both carry LAG and for controlling route importation/propagation.

5. In the IGP extensions, a router originates LSAs/LSPs with other node's link-state information, this is different from the traditional IGP mechanism. Also with IGP flooding, there is no control of the target nodes to received and keep such information. Are these IGP extensions comply to the concept of the edge node computation?

Zzh> I assume you're referring to "2.3.  OSPF/ISIS Encoding of Link Administrative Group Information for Cetralized Advertisement".
Zzh> It is not for targeted distribution to only edge nodes. Rather, it is for the traditional FlexAlgo case where every router is doing SPF for every algo, except that the LAGs and FADs are centrally provisioned and signaled (first to a few BGP-LS speakers like ABRs and then flooded to all IGP routers - if they're not all BGP-LS speakers).
Zzh> While the ABRs originate LSAs/LSPs with other node's link information, the ABRs are not spoofing other nodes' LSAs/LSPs. They're using their own LSAs/LSPs but providing the "hosting router" information so that others know which router the links belong to. I think that is reasonable.
Zzh> Thanks.
Zzh> Jeffrey

Looking forward to your feedbacks. Thanks.

Best regards,
Jie

> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
> Sent: Friday, July 31, 2020 11:03 PM
> To: [e-mail]; [e-mail]; Dongjie (Jimmy) 
> <[e-mail]>; Lizhenbin <[e-mail]>
> Subject: draft-xie-idr-bgpls-sr-vtn-mt
>
> Hi,
>
> About the following:
>
> 4.  Scalability Considerations
>
>    The mechanism described in this document requires that each VTN has
>    an independent topology, and for inter-domain VTNs, the MT-ID used in
>    each involved domain is consistent.  While this brings the benefits
>    of simplicity, it also has some limitations.  For example, it means
>    that even if multiple VTNs may have the same topology attribute, they
>    would still need to be identified using different MT-IDs in the
>    control plane.  This requires that for each VTN, independent path
>    computation would be executed.  The number of VTNs supported in a
>    network may be dependent on the number of topologies supported, 
> which
>    is related to the control plane computation overhead.
>
> As I mentioned after Cong's presentation in ID, Flexible TE (Flexible 
> Algorithm
> + SR-TE + Targeted Distribution) addresses the above scaling concerns. 
> + I also
> have some further thoughts on advertising other attributes, to be 
> published in later revisions of my draft-zzhang-teas-flexible-te draft.
>
> Would like to hear your thoughts and perhaps we can collaborate.
>
> Thanks.
> Jeffrey
>
> Juniper Business Use Only