Good digging, Xian. Thanks. That covers it better than my email (although the effect is the same :-)
Cheers, Adrian > -----Original Message----- > From: Zhangxian (Xian) [mailto:[email protected]] > Sent: 17 June 2014 03:17 > To: Igor Bryskin; [email protected]; 'Dhruv Dhody'; 'Julien Meuric' > Cc: [email protected] > Subject: RE: [Pce] PCEP ERO > > Hi, Igor, > > I think you raise up a good question. > > Just wonder if the text in Section 6.1.2 of RFC4990 (copied below) touch upon > the very same problem and provide some guidance? > > --------Section 6.1.2 of RFC4990 > There are two differences between Loose and Strict subobjects. > > o A subobject marked as a loose hop in an ERO must not be followed > by a subobject indicating a label value [RFC3473]. > > o A subobject marked as a loose hop in an ERO should never include > an identifier (i.e., address or ID) of the outgoing interface. > > There is no way to specify in an ERO whether a subobject identifies > an incoming or outgoing TE link. Path computation must be performed > by an LSR when it encounters a loose hop in order to resolve the LSP > route to the identified next hop. If an interface is specified as a > loose hop and is treated as an incoming interface, the path > computation will select a path that enters an LSR through that > interface. If the interface was intended to be used as an outgoing > interface, the computed path may be unsatisfactory and the explicit > route in the ERO may be impossible to resolve. Thus a loose hop that > identifies an interface should always identify the incoming TE link > in the data plane. > ----------------- > > Regards, > Xian > > > > -----Original Message----- > From: Pce [mailto:[email protected]] On Behalf Of Igor Bryskin > Sent: 2014年6月16日 20:23 > To: [email protected]; 'Dhruv Dhody'; 'Julien Meuric' > Cc: [email protected] > Subject: Re: [Pce] PCEP ERO > > Hello, > You are right Julien and Adrian, this is a very old issue. One thing that has been > missing IMO is a flag in a numbered/unnumbered link ERSO indicating whether > the indicated side of the link is outbound or inbound wrt the path direction from > its source to destination. The lack of said flag has been especially a problem when > combined with the LOOSE flag. Consider, for example, the situation when a > 1.1.24.1/loose is found in the ERO. If 1.1.24.1 interface is meant to be inbound, > the path should *enter* the NE that terminates the interface. However, If > 1.1.24.1 interface is meant to be outbound, the path should *exit*the said NE. > So, if the ERO is specified as a path computation constraint, the PCE may produce > very different resulting paths depending on the PCE's assumptions/ > interpretations. The introduction of said flag would resolve the ambiguity and > provide the flexibility (e.g. Druv is talking about) for the ERO encoding. > > Regards, > Igor > > > -----Original Message----- > From: Pce [mailto:[email protected]] On Behalf Of Adrian Farrel > Sent: Monday, June 16, 2014 7:33 AM > To: 'Dhruv Dhody'; 'Julien Meuric' > Cc: [email protected] > Subject: Re: [Pce] PCEP ERO > > Julien is right (of course). > > This survey led (in part) to RFC 4990. section 6 may be what Dhruv is looking for. > > A nasty question lurking in the background is whether a PCC needs to indicate > which construction of ERO is prefers. Consider if the interface was CLI not > PCEP: in this case the supported construction of ERO is part of the CLI definition. > However, given that most of the ERO is not for local consumption and does not > need to be examined by the PCC, this question may be of debatable value. > > Adrian > > > -----Original Message----- > > From: Pce [mailto:[email protected]] On Behalf Of Dhruv Dhody > > Sent: 16 June 2014 10:27 > > To: Julien Meuric > > Cc: [email protected] > > Subject: Re: [Pce] PCEP ERO > > > > Hi Julien, > > > > Thanks for the pointer, this surely helps. > > Time to dive into the archives..... > > > > Dhruv > > > > On Mon, Jun 16, 2014 at 2:29 PM, Julien Meuric > > <[email protected]> > > wrote: > > > Hi Dhruv. > > > > > > PCEP does not mandates more rules on ERO than RSVP-TE, which reminds > > > me > > of > > > an old discussion in CCAMP. You may want to have a look at > > > http://tools.ietf.org/html/draft-farrel-ccamp-ero-survey-00 and dive > > > into the associated thread back in 2006. > > > > > > Julien > > > > > > > > > Jun. 16, 2014 - Dhruv Dhody: > > >> > > >> Attaching the figure in a pdf, in case you could not view in my > > >> previous mail. > > >> > > >> Regards, > > >> > > >> Dhruv > > >> > > >> --------------------------------------------------------------- > > >> > > >> *Dhruv Dhody * > > >> > > >> > > >> System Architect, > > >> > > >> Huawei Technologies India Pvt. Ltd., > > >> > > >> Banagalore > > >> > > >> Mobile: +91-9845062422 > > >> > > >> This e-mail and its attachments contain confidential information > > >> from HUAWEI, which > > >> > > >> is intended only for the person or entity whose address is listed above. > > >> Any use of the > > >> > > >> information contained herein in any way (including, but not limited > > >> to, total or partial > > >> > > >> disclosure, reproduction, or dissemination) by persons other than > > >> the intended > > >> > > >> recipient(s) is prohibited. If you receive this e-mail in error, > > >> please notify the sender by > > >> > > >> phone or email immediately and delete it! > > >> > > >> *From:*Dhruv Dhody > > >> *Sent:* 16 June 2014 11:52 > > >> *To:* [email protected] > > >> *Subject:* PCEP ERO > > >> > > >> > > >> Dear WG, > > >> > > >> > > >> Consider the below topology, PCE computes a path from RTA to RTC. > > >> > > >> This path maybe encoded in PCEP ERO as - > > >> > > >> ~ (10.1.1.1, 10.1.1.2, 20.1.1.1, 20.1.1.2) > > >> > > >> or > > >> > > >> ~ (10.1.1.2, 20.1.1.1, 20.1.1.2) [without local IP address of > > >> ingress] > > >> > > >> IMO both should be considered as viable options. > > >> > > >> Is there any reason for PCC to consider one of them as incorrect? > > >> > > >> Regards, > > >> > > >> Dhruv > > >> > > >> --------------------------------------------------------------- > > >> > > >> Dhruv Dhody > > >> > > >> System Architect, > > >> > > >> Huawei Technologies India Pvt. Ltd., > > >> > > >> Banagalore > > >> > > >> Mobile: +91-9845062422 > > >> > > >> > > >> > > >> _______________________________________________ > > >> Pce mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/pce > > >> > > > > > > _______________________________________________ > > > Pce mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > > Pce mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
