Subject: [Pce] Mail regarding draft-zhao-pce-pcep-extension-for-pce-controller

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 1 Apr 2015 15:53:56 +0000

Hi Authors,

          Since PCE Controller has global view of the network.  There are services which spread across multiple AS or IGP domain.  SR domain can be extended across IGP domain to achieve the service requirement as SR domain can also span across IGP Domain. But by using IGP to distribute Segment labels has one drawback, Where all the external prefixes imported by an ASBR will be originated as prefix SID(usually generated by ASBR) in area or AS scope RI LSA TLV (OSPF terminology).  But will not be able to originate adjacent segment SIDs of other IGP domain due to this intermediate nodes on the path has to understand LSP information and push required SR labels which is not desired in segment routing (path has to be decided at the ingress).

In case of SR-TE, PCE can give end to end(across AREA or across AS) SR-TE path with all the TE requirement satisfied, PCE as a controller should ensure SR-Node labels remain unique across AS till the scope of SR domain.

I would like to add a section under "5.5.2.  PCECC Segment Routing (SR)" as below  :

5.5.2.3.  PCECC SR-TE IGP/SR Domain

   PCECC will ensure in allocating unique SR Node Lables across SR

   Domain. There will be cases where some service spread across multiple

   IGP domain yet with in SR Domain. One Such example is Seamless MPLS

   which provides an architecture to support a wide variety of different

   services on a single MPLS platform fully integrating access,

   aggregation and core network. In such cases PCE can help SR ingress

   router to have label stack consist of SR node label and SR Adj Labels

   from different IGP domain.

   The PCECC will send PCLabelUpd to update the SR label information which

   might belong to different IGP doamin yet belong to same SR domain to

   required nodes which fall on the path to reach till the destination.

   PCECC will ensure all TE requirements are addressed while setting up

   the explicit path and required SR label stack is updated to ingress

   node.

   The forwarding behavior will not be different as labels processed

   by  intermediate nodes. ASBR will seamlessly forward the packet

   as the FEC is updated by PCE using PCLabelUpd message.

   The Path Setup Type MUST be set for PCECC SR-TE (see Section 7.3).

   The rest of the PCEP procedures and mechanism are similar to

   [I-D.ietf-pce-segment-routing].

   PCE rely on the Adj label cleanup using the same PCLabelUpd message.

p.s.  Segment Routing Architecture [draft-ietf-spring-segment-routing-01] says  "IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP segment attached to an IGP prefix.

    An IGP-Prefix Segment is always global within the SR/IGP domain"

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel

---

From: Quintin zhao <[email-masked]>
Date: Fri, 3 Apr 2015 19:31:04 +0000

Anil,

Thanks for your detailed comments.  The inter-domain/inter-area scenario you discussed here is a good use case. Similarly, there are other existing MPLS features supported today in service provider networks where the requirements for LSP tunnels are complex. To satisfy more of these existing requirements and also to satisfy more of the new requirements resulting from new application oriented services,  more extensions for IGP to distribute SIDs/Segment labels may need to be added down the road.  Eventually either some of the existing MPLS features cannot be supported anymore or the future IGP protocol may look like a combination of current IGP and parts of LDP/RSVP-TE protocols.

Instead of extending the IGP to distribute SID/segment labels, using PCE as the central controller to distribute the SIDs/labels to setup LSP tunnels is an alternative where it has some advantages. One of these advantages  is that the SR-TE LSP can be supported to reduce the LSP states in the network and at the same time, all the other existing MPLS features including the MPLS multicast and new application oriented features can be supported by just extending the existing PCEP.

The texts you suggested here look good and we will incorporate the use case into the next version of the protocol extension draft and also the use case draft.
We would like to hear more suggestions/comments for our drafts both from SPRNG working group and from PCE working group.
Quintin

From: Anil Kumar S N (VRP Network BL)
Sent: Wednesday, April 01, 2015 11:54 AM
To: [email-masked]; Quintin zhao; Katherine Zhao; [email-masked]; Udayasree palle; [email-masked]; [email-masked]
Cc: VinodS Kumar; Veerendranatha Reddy Vallem
Subject: Mail regarding draft-zhao-pce-pcep-extension-for-pce-controller

Hi Authors,

   node.

Thanks & Regards
Anil S N