Subject: [Pce] FW: Compute ingress and egress backup LSP

From: Huaimo Chen <[email-masked]>
Date: Tue, 19 Jul 2011 20:55:39 +0000

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-masked]]
> Sent: Thursday, March 31, 2011 4:09 AM
> To: Huaimo Chen; [email-masked]
> 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
>

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 24 Jul 2011 22:45:10 +0200

Hi, 

Please see inline

> From: ext Huaimo Chen [mailto:[email-masked]]
> Sent: Tuesday, July 19, 2011 4:56 PM
> To: Margaria, Cyril (NSN - DE/Munich)
> Cc: [email-masked]
> 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
> >     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.

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

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 25 Jul 2011 18:25:22 +0000

Hi Cyril,

    Thanks much for your comments!
    My explanations are inline below.

Best Regards,
Huaimo
-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Sunday, July 24, 2011 4:45 PM
To: Huaimo Chen
Cc: [email-masked]
Subject: RE: [Pce] Compute ingress and egress backup LSP

Hi,

Please see inline

considering
be

[Huaimo Chen]:
The semantics of an END-POINTS object has been defined in RFCs. An END-POINTS object contains both the source IP address and destination IP address(es) of a TE LSP for which a path computation is requested. If we want to re-use the END-POINTS object to represent an external source node for computing a backup ingress, then we need to define the new semantics of the END-POINTS in this case. Thus the same END-POINTS object may have different meanings in different cases. How do we make sure that we can tell the difference from the context?
In addition, if we re-use an END-POINTS object to represent an external source node, the field of destination IP address of the object may be wasted. How do we re-use this field?

is