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

[Gyan Mishra <[e-mail]>]

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

Also noticed Flex Algo constraint missing

Also static SID list weight for UCMP should be added

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

Also I think SRv6 compression draft C-SID should be added.

https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-03

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.

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*