Re: [Idr] Questions on draft-ietf-idr-te-lsp-distribution-01

Hi Olivier, 

Thanks a lot for your comments and questions. Please see my replies inline:

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Olivier Dugeon
> Sent: Friday, December 19, 2014 2:07 AM
> To: idr@ietf.org
> Subject: [Idr] Questions on draft-ietf-idr-te-lsp-distribution-01
> 
> Dear authors,
> 
> After reading and analysis your draft, I have some questions related to PCEand
> Segment Routing for the LSP State Information, in particular on the list of TE
> LSP Objects.
> 
> a) Which routerwill report LSP State Information ? Only the LER, or all routers
> that are located on the path followed by the MPLS-TE LSP ?

In my opinion the LER is responsible for reporting the LSP state information. Other routers on the LSP path may report the LSP information if needed, e.g. the border routers in inter-domain case. 

> 
> b) Is Path Key SubObject is implicitly part of ERO / RRO in your draft?
> if yes, do you think it is pertinent to mention it (through RFC number or
> explicitly) ? If not, do you think it is pertinent to add it ?

In general the SubObjects of ERO/RRO are implicitly included in this draft. Not sure whether we need to mention the SubObjects explicitly. If we decide to do it for the Path Key Subobject, we may need to list all the subobjects explicitly. 

> 
> c)IGP-TE metric have been extended recently (see
> draft-ietf-te-metric-extensions, draft-ietf-ospf-te-metric-extensions)
> with the possibility to distribute them with BGP-LS (see draft-ietf-idr-te-pm-bgp).
> Do you think it is feasible for the LER to compute the cumulative delay, jitter
> and loss along the path from the IGP-TE metrics it learn from the IGP-TE, and
> then, distribute the result through BGP-LS ? In this case, the TE Metric Object in
> the objects list of LSP State Information should be extended with the Metric
> Extensions, at least, delay, jitter and loss.

Agree that if performance information of the end-to-end LSP is needed, the mechanism defined in this document can be used to distribute it northbound. In that case the Metric Object extensions in draft-ietf-pce-pcep-service-aware may be used. 

The performance information of the end-to-end path can be obtained either via performance measurement on the path, or by computing the cumulative performance metrics of the links on the path. The former approach is usually more accurate and easier. 

>
> d) The draft is related to MPLS-TE LSP and RSVP-TE, but I think it could be also
> suitable for path composed by segment. So, do you intend to add SR-ERO, and
> perhaps SR-RRO SubObjects (see draft-ietf-pce-segment-routing-00.txt), in the
> objects listfor the LSP State Informationwhen it is composed by Segment ID or
> do you think it is preferable to left them for another draft devoted specifically
> to Segment Routing?

This is a good question. As a path composed by segment is also one kind of TE path, my personal opinion is it can be included in this draft. Then the SR-ERO and SR-RRO Objects can be seen as part of the ERO and RRO object carried in the LSP State Information. Of course more details need to be considered. 

> 
> e) In case of adding Segment Routing ERO/RRO, what could be envisage for the
> Tunnel ID (which is allocated by RSVP-TE) ? and for the Protocol-ID which is
> linked to RSVP-TE? as there is nodedicated signalling in Segment Routing. This
> information could be provided localy by the router, but combined with the
> Router ID, for example, in order to be unique.

If we decide to report segment routed paths, maybe we need to have a dedicated protocol-ID for it. The Tunnel ID and LSP ID fields could be filled by the ingress router with local identifiers to uniquely identify an SR path on the router.

Best regards,
Jie

> 
> Regards,
> 
> Olivier
> 
> 
> 
> 
> <mailto:olivier.dugeon@orange.com>
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr