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 protected]]
Sent: Sunday, July 24, 2011 4:45 PM
To: Huaimo Chen
Cc: [email protected]
Subject: RE: [Pce] Compute ingress and egress backup LSP
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.
[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?
> > 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
