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

From: Olivier Dugeon <[email-masked]>
Date: Thu, 18 Dec 2014 19:06:44 +0100

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 ?

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 ?

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.

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?

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.

Regards,

Olivier

<mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Fri, 19 Dec 2014 03:30:06 +0000

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.

[Qin]: why rely on LER to compute the cumulative performance results, why not rely on PCE server to compute cumulative results (see draft-ietf-pce-pcep-service-aware).
Is it necessary to distribute cumulative results? I think it adds a lot of complexity.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 19 Dec 2014 08:28:40 +0000

Hi Olivier, 

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

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Olivier Dugeon
> Sent: Friday, December 19, 2014 2:07 AM
> To: [email-masked]
> 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. 

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

> 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

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr