Re: [Idr] draft-ietf-idr-te-lsp-distribution questions

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

Thanks for your feedback and please check inline below for responses.

On Fri, Jan 20, 2023 at 9:26 AM Gyan Mishra <[e-mail]> wrote:

> Hi Jeffrey
>
> I read the draft as well and I agree with you that it is primarily goal is
> to coalesce all the characteristics of RSVP-TE and SR Policy into new
> BGP-LS TLVs to collect to build a network visualization of a domain wide
> multi area or AS view for stateful path computation and instantiation by
> means other than centralized PCE.  I agree also the goal is to collect the
> multicast related RSVP-TE or SR P2MP policy using the cross connect
> interfaces TLVs.
>
> I agree with your recommendations for enhancements mentioned to support
> multicast.  Makes sense.
>
> Overall I think the draft is very useful as SR policy can be complicated
> and  building the data structures and transporting to a single painted
> glass NMS station or controller is a great idea.
>
> Dear Authors
>
> Few comments on the draft.
>
> I noticed the metric type - IGP, latency, TE, hop count is missing
>

KT> Please check Sec 9.8.


>
> Also noticed Flex Algo constraint missing
>

KT> FlexAlgo constraint is signaled into BGP-LS via IGPs and covered by the
BGP-LS FlexAlgo draft.


>
> Also static SID list weight for UCMP should be added
>

KT> Please check sec 6.7 where we have weight per SL.


>
> Maybe ODN and automated steering color and colorless policy should be
> added
>

KT> These types can be reported via this specification - please let us know
what you think is missing to do that.


>
> Also I think SRv6 compression draft C-SID should be added.
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-03
>

KT> There is no control plane extension required for C-SID since it
leverages base SRv6 - that also applies to this draft. Please let us know
if you think anything is missing.


>
> I think maybe MPLS and Spring path Segment should be included.
>
> SRv6 path Segment
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment
>
> SR-MPLS path Segment
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment
>
> BIDIR path Segment
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment
>
> Possibly SR-PM monitoring policy so that tracking data monitoring of SR
> policy endpoints within the policy can now be monitored by external
> applications.
>

KT> I will discuss with co-authors and get back. Please also
check draft-ietf-idr-bgp-ls-sr-policy-path-segment

Thanks,
Ketan


>
> Kind Regards
>
> Gyan
>
>
>
> On Wed, Jan 18, 2023 at 9:01 AM Jeffrey (Zhaohui) Zhang <zzhang=
> [e-mail]> wrote:
>
>> Hi,
>>
>> I have some questions on this draft.
>>
>> It apparently is TE-specific (RSVP-TE or SR policy) and unicast-specific.
>> While it mentions multicast in the cross-connect case, it is not clear how
>> multicast state is reported. For example, if a node needs to replicate to
>> 10 branches, would there be 10 cross-connect NLRIs used, each for a
>> replication branch? If so, what is the use case of multiple outgoing
>> interfaces?
>>
>> Also, is the cross-connect NLRI intended only for locally "configured"
>> (vs. signaled by RSVP-TE), as implied by the following text?
>>
>>    In many network environments, traffic engineering (TE) policies are
>>    instantiated into various forms:
>>
>>    *  MPLS Traffic Engineering Label Switched Paths (TE-LSPs).
>>
>>    *  Segment Routing (SR) Policies as defined in [RFC9256]
>>
>>    *  Local MPLS cross-connect *configuration*   <------
>>
>> Relatedly, are the TE-LSP and SR policy NLRI intended for headend only
>> (and not used to report RSVP-TE state on transit-nodes)?
>>
>> Consider the following two use cases:
>>
>> - Hop-by-hop signaled mLDP trees are used in a network but the operator
>> wants state on the tree nodes to be reported to a controller for
>> display/visualization purpose.
>> - A PCE signals SR-P2MP trees via BGP and it needs confirmation from tree
>> nodes that replication state has been set up as signaled.
>>
>> I had initially thought that the cross-connect NLRI can be used for that,
>> but looks like quite some enhancements would be needed:
>>
>> - make the draft applicable to non-TE as well
>> - make the cross-connect NLRI applicable to beyond local configuration
>> - add attribute to the cross-connect to indicate tree information (e.g.
>> mLDP FEC, RSVP session object)
>>
>> Alternatively, make the TE-LSP and SR policy NLRI applicable to transit
>> nodes as well and report the cross-connect information as attribute.
>>
>> If this makes sense, do we want to extend the existing draft or should I
>> start a new draft?
>>
>> Thanks.
>> Jeffrey
>>
>> Juniper Business Use Only
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>