Re: [Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08
Support. From: Pce On Behalf Of Jonathan Hardwick Sent: Saturday, October 13, 2018 10:47 AM To: pce@ietf.org Cc: draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org; pce-cha...@ietf.org Subject: [Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08 This is the start of a two week poll on making draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group document. https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/ Please review the draft and send an email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reasons. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends on Friday, October 26. Many thanks, Jon and Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adoption of draft-pkd-pce-pcep-yang-06
Support. -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: Friday, August 12, 2016 5:43 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-pkd-pce-pcep-yang-06 Hi all, During the joint TEAS-MPLS-PCE Yang session in Berlin, we had a clear consensus in the room on the interest for the aforementioned I-D. We now need to see if the mailing list confirms this consensus. As a result, do you think that draft-pkd-pce-pcep-yang-06 is a right foundation for a PCE WG document? As usual, comments are very welcome, especially if you do not support the adoption. Thanks, JP, Jon & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] PCEP ERO
Igor, Reasonable people can always disagree. :-) It may very well be the case that the scenario you're describing lacks the element of flexibility required for local decisions to be useful. I can see computation by a PCE as being much more scalable than requiring each potential ingress to know about the capabilities of each potential egress, but - in this case - isn't it possible to either push the entire path (for at least a specific domain) from the PCE to the ingress, or use delegation (either approach effectively relieves the ingress from having to "know" anything about the egress)? Or is this what you are trying to get at? If so, and there is really no advantage to local decision-making, what would be the point of using a "loose" ERO? -- Eric -Original Message- From: Igor Bryskin [mailto:ibrys...@advaoptical.com] Sent: Wednesday, June 18, 2014 10:16 AM To: Eric Gray; adr...@olddog.co.uk; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric' Cc: pce@ietf.org Subject: RE: [Pce] PCEP ERO Importance: High Hi Eric, Sorry to say this, but in the context of WDM layer I cannot disagree with you more. It is my conviction that WDM layer path (considering all the WDM related constraints, such as optical impairments) the entire LSP path in all its details must be computed in one place (ingress NE or PCE) and no flexibility must be left for decisions on transit nodes. Regards, Igor -Original Message- From: Eric Gray [mailto:eric.g...@ericsson.com] Sent: Wednesday, June 18, 2014 9:46 AM To: Igor Bryskin; adr...@olddog.co.uk; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric' Cc: pce@ietf.org Subject: RE: [Pce] PCEP ERO Igor, I very much dislike the idea of a path ingress, or a point along the path, making a decision as to what egress interface I will use at any later point in the path (path egress, domain egress or elsewhere), based on an awareness that the decision point supposedly has about the capabilities of a downstream node. Wouldn't it be better to include the desired capabilities in signaling, and let the downstream node(s) make this decision for themselves? That way, it is only necessary for a potential decision point in the network to know that some subsequent (downstream) node has this capability without needing to know which interface(s) (or even necessarily which node) this capability is supported via. This seems a generally desirable behavior associated with information hiding. What is different in this case? -- Eric -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Igor Bryskin Sent: Wednesday, June 18, 2014 7:50 AM To: adr...@olddog.co.uk; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric' Cc: pce@ietf.org Subject: Re: [Pce] PCEP ERO Adrian, Please see in-line. -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Wednesday, June 18, 2014 5:14 AM To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric' Cc: pce@ietf.org Subject: RE: [Pce] PCEP ERO Hi Igor, Why don't you put the address of NE X in the ERO? You wouldn't even need to say loose (unless it was genuinely a loose hop). IB>> I am talking about the "loose" scenario. Yes, it is possible to insert address of NE X as loose hop, but this would at least unnecessarily increase the length of the ERO ( loose node ERSO + strict IN interface ERSO vs. loose OUT interface ERSO). More importantly, sometimes I really need to specify OUT interface in the ERO. Consider, for example, the situation where OUT interface Y can provide the optical signal regeneration I need. The way I constrain the path computation to use the needed re-generation is by specifying OUT interface Y ERSO followed by the label ERSO that encodes the necessary regenerator. I cannot do this by using the peer IN part of the link because the regenerator belongs to the interface Y. Now, maybe you are concerned that, having decided which i/f you want to exit by, there is a risk that you would reach NE X by that interface. IB>> No, this is not my concern. Well, that is ever so slightly possible, but: - It seems incredibly unlikely that the out interface you are so determined to use could accidentally become the in interface. If that happened then you would already have reached the downstream node that you wanted to reach. Uck. Sounds like a bit of bad path computation! - You could use path exclusions to make sure that doesn't happen. BTW... Is it time to move this discussion to CCAMP where signaling people can discuss what you are suggesting? IB>> Well, IMO this is really a path computation problem, more specifically, path computation constraint problem, unless you believe that paths in th
Re: [Pce] PCEP ERO
Igor, I very much dislike the idea of a path ingress, or a point along the path, making a decision as to what egress interface I will use at any later point in the path (path egress, domain egress or elsewhere), based on an awareness that the decision point supposedly has about the capabilities of a downstream node. Wouldn't it be better to include the desired capabilities in signaling, and let the downstream node(s) make this decision for themselves? That way, it is only necessary for a potential decision point in the network to know that some subsequent (downstream) node has this capability without needing to know which interface(s) (or even necessarily which node) this capability is supported via. This seems a generally desirable behavior associated with information hiding. What is different in this case? -- Eric -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Igor Bryskin Sent: Wednesday, June 18, 2014 7:50 AM To: adr...@olddog.co.uk; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric' Cc: pce@ietf.org Subject: Re: [Pce] PCEP ERO Adrian, Please see in-line. -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Wednesday, June 18, 2014 5:14 AM To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric' Cc: pce@ietf.org Subject: RE: [Pce] PCEP ERO Hi Igor, Why don't you put the address of NE X in the ERO? You wouldn't even need to say loose (unless it was genuinely a loose hop). IB>> I am talking about the "loose" scenario. Yes, it is possible to insert address of NE X as loose hop, but this would at least unnecessarily increase the length of the ERO ( loose node ERSO + strict IN interface ERSO vs. loose OUT interface ERSO). More importantly, sometimes I really need to specify OUT interface in the ERO. Consider, for example, the situation where OUT interface Y can provide the optical signal regeneration I need. The way I constrain the path computation to use the needed re-generation is by specifying OUT interface Y ERSO followed by the label ERSO that encodes the necessary regenerator. I cannot do this by using the peer IN part of the link because the regenerator belongs to the interface Y. Now, maybe you are concerned that, having decided which i/f you want to exit by, there is a risk that you would reach NE X by that interface. IB>> No, this is not my concern. Well, that is ever so slightly possible, but: - It seems incredibly unlikely that the out interface you are so determined to use could accidentally become the in interface. If that happened then you would already have reached the downstream node that you wanted to reach. Uck. Sounds like a bit of bad path computation! - You could use path exclusions to make sure that doesn't happen. BTW... Is it time to move this discussion to CCAMP where signaling people can discuss what you are suggesting? IB>> Well, IMO this is really a path computation problem, more specifically, path computation constraint problem, unless you believe that paths in the WDM layer could be computed in a distributed way, which I don't. Cheers, Igor Adrian > -Original Message- > From: Igor Bryskin [mailto:ibrys...@advaoptical.com] > Sent: 17 June 2014 13:11 > To: Zhangxian (Xian); adr...@olddog.co.uk; 'Dhruv Dhody'; 'Julien Meuric' > Cc: pce@ietf.org > Subject: RE: [Pce] PCEP ERO > > Hi Xian, > > Here is my problem. What if I want my path to go through NE X and > exit it via interface Y but do not care on which interface the path enters > the NE X? > What I was saying is that just like we have the LOOSE flag, we > could've had "OUT" > flag, which would solve all kinds of ambiguities. > > Igor > > -Original Message- > From: Zhangxian (Xian) [mailto:zhang.x...@huawei.com] > Sent: Monday, June 16, 2014 10:17 PM > To: Igor Bryskin; adr...@olddog.co.uk; 'Dhruv Dhody'; 'Julien Meuric' > Cc: pce@ietf.org > 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
Re: [Pce] Path Key I-D : number of bits
Adrian, I mostly agree with your reasoning. In the first case, it is probably going to be a too interesting world in which we live if we can expect to get close to exceeding this many current path keys for each of potentially many PCEs. This implies that we would expect to see on the rough order of 64K traffic engineered multi (adminstrative) domain LSPs for which it is necessary for a subset of all PCEs to maintain active state information relative to ongoing signaling transactions. I dislike thinking about the number of actual steady-state traffic engineered, multi (administrative) domain LSPs that might be expected to exist when we expect this many to be in the process of being setup at any time. I also have trouble imagining the application that would require orders of magnitude more than 64K such multi domain TE LSPs. Also, if real-world implementations find it necessary to exceed this number by (for example) 2 or 3 times, a need to maintain multiple PCE IDs is likely to be the least of the issues they will face. However, should a need arise for orders of magnitude greater numbers of path keys (for example, should it turn out that there's a need to record assigned path key values for some period of time - like 24 hours - for any reason), then the approach of using multiple PCE IDs scales rather poorly and would probably require more work. For one thing, I am not sure how this would work; would the PCE from whom a path computation is requested be able to provide responses that specify a separate PCE ID? Do we expect that both PCS and PCC implementations will be able to maintain state on orders of magnitude more PCE IDs? Do extra PCE ID instances go away when no longer needed? Wasn't one of the options to possibly define another subobject in the future - should the need arise? If that were the case, the current sub-object definition allows the implementers today to scale their implementation resource needs to fit a smaller number of possible values we think we might need in the near future, while leaving open the the possibility of later implementations that support larger values... -- Eric Gray Principal Engineer Ericsson > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Farrel > Sent: Thursday, November 27, 2008 6:38 PM > To: pce@ietf.org > Subject: [Pce] Path Key I-D : number of bits > > Hi, > > To repeat something discussed briefly in Minneapolis (this was raised > in CCAMP in discussion of draft-ietf-ccamp-path-key-ero-02.txt, but > more properly applies to draft-ietf-pce-path-key-05.txt). > > The path key subobject is formed as... > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |L|Type | Length| Path Key| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PCE ID (4 bytes) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The question is: Are 16 bits enough for the Path Key? Isn't it possible > that more than 2^16 path segments will be computed and "held" for > possible expansion during signaling at any one time? > > My feeling is that this would not be the case. The keys are relatively > short lived, and can be recycled after a short safety period as > described in the draft. > > There are some special cases where resignaling of the LSP (from the > head end with the same path key) would require the key to be held for > longer, but the domain entry router can hold the key (in association > with the session) to avoid any issues in this case. > > Further, if there really are issues with depletion of keys, the PCE > could use another PCE ID to create a further 2^16 keys. > > What does the working group think? > > Thanks, > Adrian > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] PCE computation time
Adrian, You would not take into consideration the potential for relayed communication times in the distributed PCE case? -- Eric Gray Principal Engineer Ericsson > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Farrel > Sent: Tuesday, August 05, 2008 1:21 PM > To: Meral Shirazipour > Cc: pce@ietf.org > Subject: Re: [Pce] PCE computation time > > I think you might predict PCEP communication time as... > > TCP connection setup > PCEP session establishment > PCEP request/response > > You might approximate this with a web browser or any other TCP-based > application. > > FWIW I would expect a simple CSPF to be computed in a few > hundred ms at > absolute most (but probably in a less than a few tens of ms) and > communication time to be of the order of one second tops. YMMV. > > Cheers, > Adrian > - Original Message - > From: "Meral Shirazipour" <[EMAIL PROTECTED]> > To: "Adrian Farrel" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, August 05, 2008 5:44 PM > Subject: Re: [Pce] PCE computation time > > > > Hi Adrian, > > For the PCE computation time, I was considering all that > you mentioned > > except > > the compiler efficiency/software implementation dependencies. > > > > Also when you say: > >> In general, > >> for this type of computation, we observe that a remote > PCEP communication > >> takes far more time than the computation. (Times may vary > according to > >> the > >> pre-existence of the PCEP session.) > > > > are we talking "worse case" PCEP communication time in the order of > > seconds? > > minutes? ..? > > > > I am assuming that: > > PCE response time = PCEP communication time + PCE computation time > > > > Then the total response time is some sort of a summation of > the response > > times > > of all the PCEs in the PCE chain. > > > > Any further comments would be greatly apperciated. I am > trying to come up > > with > > "typical/realistic" PCE response times for the single LSP > computation > > case. I > > do understand that this time could greatly vary depending > on the criterias > > you > > mentioned (CPU power, etc.), but just knowing if in practice it is > > typically in > > the orders of seconds, minutes, hours would be of great help to me. > > > > many thanks, > > Meral > > > >> Now then, Meral, > >> > >> I think computation times *might* be dependent on CPU > power, loading, > >> compiler efficiency, software implementation, algorithm > choice, network > >> complexity, etc. > >> > >> Some observations suggest that computation for single LSPs > with normal > >> constraints can be achieved using CSPF and there are > studies recording > >> the > >> number of logical steps needed to perform such a > computation. In general, > >> for this type of computation, we observe that a remote > PCEP communication > >> takes far more time than the computation. (Times may vary > according to > >> the > >> pre-existence of the PCEP session.) > >> > >> Other observations note that some computation problems are > quite hard and > >> need a few more cycles. In these cases, given the low > power of CPUs on > >> NEs, > >> the communication time may be less significant. > >> > >> Cheers, > >> Adrian > >> - Original Message - > >> From: "Meral Shirazipour" <[EMAIL PROTECTED]> > >> To: > >> Sent: Tuesday, August 05, 2008 12:24 AM > >> Subject: [Pce] PCE computation time > > > > > >> > Hi, > >> > Does anyone have actual values for the min/average/max PCE > >> > computation > >> > times > >> > in a real network? > >> > I remember that the issue was discussed for the monitoring draft. > >> > > >> > > >> > Thanks, > >> > Meral > >> > > >> > > >> > ___ > >> > Pce mailing list > >> > Pce@ietf.org > >> > https://www.ietf.org/mailman/listinfo/pce > >> > > >> > >> > >> > > > > > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Working Group Last Call
Dear Mom, Thanks for the note. I am in the middle of something right at the moment, but I will be sure to get back to you with more detail as soon as I can. -- Eric Gray Principal Engineer Ericsson > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Farrel > Sent: Tuesday, August 05, 2008 12:21 PM > To: pce@ietf.org > Subject: [Pce] Working Group Last Call > > Hi, > > This email starts a two week working group last call on > draft-ietf-pce-of-04.txt > > (The only differences from draft-ietf-pce-of-03.txt are that > I reformatted > the document to get the indentation right, re-ordered the > sections so that > the Introduction is the first section, expanded some acronyms > where they > first show up, ran I-D nits and fixed the errors, and > regenerated the table > of contents. Sometimes I feel like I am a cross between your > secretary and > your mother!) > > The last call will end at 9am GMT Wednesday 20th August. > > Please send your comments to the list. > > Thanks, > Adrian > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
