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