Hi Greg,
Please, see in line. Igor ________________________________ From: Greg Bernstein [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 3:11 PM To: Igor Bryskin Cc: ccamp; [EMAIL PROTECTED] Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... Hi Igor, see comments below. Igor Bryskin wrote: Greg, I believe the draft is very useful. --> Thanks! I have a couple of questions comments: 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network Optimization How the problem of grooming of higher layer network traffic over optical trails is any different from the problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of the OCh layer. ==> Some of my co-authors agree with you on moving this section out. The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass). I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned. If so then I'd feel fine removing this section from the document. IB>> Ok 2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft. --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode? Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows. Was there some general looping concerns already published for GMPLS with respect to circuits? IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP. Cheers, Igor ________________________________ From: Greg Bernstein [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 7:42 PM To: ccamp; [EMAIL PROTECTED] Subject: [Pce] Some key issues with Wavelength Switched Optical Networks... Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up. (a) The draft brings up models for the following WDM network elements: 1. WDM links 2. Optical transmitters 3. Wavelength Converters and OEO regenerators 4. ROADMs, FOADMs, optical splitters and combiners. For items (3) and (4) we are taking the modeling lead rather than some other SDO. And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS). (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols: 1. A single PCE computing both the path and wavelength 2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) Do we really need all three models? (c) G.709 includes the Optical Multiplex Section and Optical Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport Network) control. Weren't we finished with all this optical stuff years ago? I'd like to think the draft answers some of these questions. I also think that network element models and the process models are important enough to warrant this separate framework document. Your opinions are solicited. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
