Hi, Please see inline
> -----Original Message----- > From: ext Huaimo Chen [mailto:[email protected]] > Sent: Tuesday, July 19, 2011 4:56 PM > To: Margaria, Cyril (NSN - DE/Munich) > Cc: [email protected] > Subject: FW: [Pce] Compute ingress and egress backup LSP > > Hi Cyril, > > I updated the draft according to some of your suggestions. The > updated draft is posted in IETF web site on July 9, 2011.Please have a > look at it http://datatracker.ietf.org/doc/draft-chen-pce-compute- > backup-ingress/ in section 4.2.2. "External Source Node Object". > After further thought, it seems that we may use END-POINTS to > represent an external source node in a request for computing a backup > ingress node of MPLS LSP. > > Best Regards, > Huaimo > > -----Original Message----- > > From: Huaimo Chen > > Sent: Friday, July 08, 2011 3:20 PM > > To: 'Margaria, Cyril (NSN - DE/Munich)' > > Subject: RE: [Pce] Compute ingress and egress backup LSP > > > > Hi Cyril, > > > > I am updating the draft for submitting to IETF 81 and considering > > your suggestions. But I have some questions about them. > > Firstly, if we use END-POINTS to represent an external source > node > > in a request for computing a backup ingress node of MPLS LSP, how do > > we distinguish different end-points in the message since there may be > > a number of end-points in the message? I do not understand, it seems you see an use case where you would like to request the PCE to calculate at the same time a path and a backup path avoiding what you consider as The LSP. Finding such path can be done using several request (explicitly sharing the path), however I am not sure its possible as of today using one single request, it would be something like a SVEC indicating that all the request should share the path (except on the exclusions), but defining new object also representing the traffic/path endpoints Does not seems the best solution. > > Secondly, if we use END-POINTS to represent a number of external > > destination nodes in a request message for computing a number of > > backup egress nodes of an MPLS TE P2MP LSP, then we need the > > information about the egress node to which each backup egress node is > > associated. How do we represent the information about each egress > node > > and its association with its corresponding backup egress node to be > computed? > > BTW, are you going to attend IETF 81 in Quebec? If you are, we > can > > discuss these in more details. > > > > Best Regards, > > Huaimo > > -----Original Message----- > > From: Margaria, Cyril (NSN - DE/Munich) > > [mailto:[email protected]] > > Sent: Thursday, March 31, 2011 4:09 AM > > To: Huaimo Chen; [email protected] > > Subject: RE: [Pce] Compute ingress and egress backup LSP > > > > Hi, > > Thanks for your answer, I was not detailed enough, please see inline > > > > <cut> > > > I would like to understand what is missing in doing the following > > > requests, using the topology shown in the PCEP IETF80 presentation > > > (http://tools.ietf.org/wg/pce/agenda?item=agenda80.html, > > > http://tools.ietf.org/agenda/80/slides/pce-7.ppt) , slide number 7 > > > > > > Request #1 : > > > o PCReq : > > > - END-POINTS : CE3, leaf : CE1, CE2 > > - IRO : PE5, link CE3-PE5, PE1, Link PE1-CE1, PE3, Link PE3-CE3 > > > > > o PCRep : > > > - ERO : PE5....PE1,CE1 > > > - SERO : n..PE3,CE2 > > > Huaimo: This request should be for computing a P2MP TE LSP path > from > > > PE5 (Ingress) to PE1 (Egress) and PE3 (Egress).It seems that your > > > request is for the P2MP path from CE3 (Ingress) to CE1 > (Egress/Leaf) > > > and CE2 (Egress/Leaf). > > > > > This is correct, I do request the path from the CE node, the term > > ingress/egress can be misleading, it is not required that the > endpoint > > of the path are the LSP ingress/egress > > > > this is the PCC which decide to create an LSP from PE. > > I missed one important point here : the PE5, as LSP endpoint and > > likely PCC, want the path to go though him, hence the IRO (added to > > the message) > > > > > > > Request #2 (backup ingress) : > > > O PCReq : > > > - END-POINTS : CE4, leaf : CE1,CE2 > > > - XRO : {F bit set, exclude : PE5) > > > - RRO : PE5....PE1, CE1 > > - IRO : PE1, Link PE1-CE1, PE3, Link PE3-CE3 > > > > > - SRRO : n..PE3,CE2 > > > O PCRep : > > > - ERO : PE6....PE1,CE1 > > > - SERO : n..PE3,CE2 > > > Huaimo: This request should be for computing a backup ingress of > the > > > P2MP TE LSP in red color, which is from PE5 to PE1 and PE3. > > > > Same here, the request is NOT matching the signaling path, this is > > intentional and do *not* mean that the LSP is required to have a 1:1 > > mapping between PCReq endpoints and LSP ingress/egress. > > > > > The reply > > > for the request may just contain the backup ingress such as PE6 and > > > backup path from the backup ingress such as PE6 to the next hop > node > > of > > > the ingress PE5. The request should indicate that the backup > ingress > > > computed must be able to get the same data that the ingress such as > > PE5 > > > receives and imports into the P2MP TE LSP from a node (external > > > source node), which may not be in the same domain as the ingress. > > > It seems that your request does not have this information. > > > > This is correct, I forgot the IRO, its working with the IRO. > > > > > > > Request #3 (backup egress) : > > > O PCReq : > > > - END-POINTS : CE3, leaf : CE1,CE2 > > > - XRO : {F bit set, exclude : PE1, PE4) > > > > - IRO : PE5, link CE3-PE5, > > > > > - RRO : PE5....PE1, CE1 > > > - SRRO : n..PE3,CE2 > > > O PCRep : > > > - ERO : PE6....PE2,CE1 > > > - SERO : n..PE4,CE2 > > > Huaimo: This request should be for computing a given set of backup > > > egress nodes of the P2MP TE LSP. For example, we may request PCE to > > > compute a backup egress for PE1 and a backup egress for PE3 in one > > > request. In this case, we need to indicate that the backup egress > > > for egress PE1 must have a connection to CE1, to which the data > > > coming out from the egress PE1 of the P2MP TE LSP is sent; and the > > > backup egress for egress PE3 must have a connection to CE3, to > which > > > the data coming out from egress PE3 of the P2MP TE LSP is sent. > > > It seems that your request does not have this information. > > > > This is also correct, the IRO is missing, this is a key point to > force > > the request to use the LSP ingress/egress. > > > > Does it fit with the corrected request (IRO) and responses? > > > > Best Regards > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
