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

Hi Ketan

Welcome!

Responses in-line

Thank you

On Mon, Jan 23, 2023 at 10:06 PM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Hi Gyan,
>
> Thanks for your feedback and please check inline below for responses.
>
> On Fri, Jan 20, 2023 at 9:26 AM Gyan Mishra <hayabusagsm@gmail.com> 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.
>

    Gyan> Ack

>
>> Also noticed Flex Algo constraint missing
>>
>
> KT> FlexAlgo constraint is signaled into BGP-LS via IGPs and covered by
> the BGP-LS FlexAlgo draft.
>
>
    Gyan> Ack.  My thought was that as the goal of this draft is to graph
the SR policy into BGP-LS I was thinking along the lines of the SR Policy
flex algo constraint “SR-Algo” knob that exists for SR-MPLS or SRv6 SR
Policy to instantiate the SR policy steering over an Algo colored links.

>
>> Also static SID list weight for UCMP should be added
>>
>
> KT> Please check sec 6.7 where we have weight per SL.
>

     Gyan> Ack

>
>
>> 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.
>

    Gyan> In section 4.5 where you specify the policy color and endpoint
maybe also specify ODN where only color signaling is used for the dynamic
endpoint tuple to be created.  For automated steering specifically the
0.0.0.0/4 next hop best path.

>
>
>>
>> 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.
>
>
    Gyan> Yep makes sense.

>
>> 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
>

    Gyan> Ack.  I think good idea to discuss with the authors on feedback.

>
> Thanks,
> Ketan
>
>
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>>
>> On Wed, Jan 18, 2023 at 9:01 AM Jeffrey (Zhaohui) Zhang <zzhang=
>> 40juniper.net@dmarc.ietf.org> 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
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*