Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 19:28:34 -0800 Message-ID: <3BE0C0B8.529DA11A@lucent.com> Date: Wed, 31 Oct 2001 22:25:44 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Yakov Rekhter CC: Dimitri Papadimitriou , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > We have two approaches either "traffic-parameters" are used > > (in SENDER_TSPEC) then i think the Switching Type capability > > is useless or they aren't then such field could be optionaly > > used when applicable (some examples are given in the routing > > document). > > > > Wouldn't be the right way to proceed by defining an "unknown" > > or "unspecified" value used when "traffic-parameters" are > > included within the Path Message and optional use the ones > > proposed in the current version of the specification when they > > aren't. This field is thus optional and MUST only be used when > > traffic parameters are not defined. I think this solves both > > approaches. > > Agreed. When a hybrid NE sees GMPLS (different C-types from MPLS) messages, it knows the LSP is not for conventional data LSP. So there is no confusion about conventional MPLS data LSPs and GMPLS circuit LSPs without Switching Type. Furthermore, if you have "traffic-parameters", Switching Type is useless, as we agreed. So, defining "unknown", "unspecified" is not necessary, and neither is Switching Type. Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 19:28:28 -0800 Message-ID: <3BE0C138.B293CB4E@lucent.com> Date: Wed, 31 Oct 2001 22:27:52 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Yakov Rekhter CC: Zhi-Wei Lin , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Let me see if I understand your proposal. Consider the following > example: > > R1---OXC1---OXC2----R2 > > where the TE interface on R1 is a collection of GigE ports, and the TE > interface on R2 is a collection of OC-48 ports. Are you saying that > establishing an LSP between R1 to R2 makes sense ? > If you have adaptation function in either OXCs, it then makes sense. And sure, you can also treat the R1-R2 connection as two LSPs separated by the adaptation function. Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 18:25:16 -0800 Message-ID: From: John Drake To: 'manoj juneja' , dimitri.papadimitriou@alcatel.be Cc: zwlin@lucent.com, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 18:23:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To handle the case where the path of an LSP transits one or more TE links which are advertised as having more than one of the following switching capabilities (PSC, TDM, LSC, FSC) and the LSP is requesting a switching capability of (PSC, LSC, or FSC). Dimitri's proposal also works just fine when the path of an LSP transits links which have only one advertised switching capability. -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Wednesday, October 31, 2001 6:07 PM To: John Drake; dimitri.papadimitriou@alcatel.be Cc: zwlin@lucent.com; Ben.Mack-Crane@tellabs.com; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Hi John, If the switching type advertised in the link state database is say Lambda or Fiber then why we need to carry this in signalling ? Regards, manoj. >From: John Drake >To: 'manoj juneja' , >dimitri.papadimitriou@alcatel.be >CC: zwlin@lucent.com, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, >ccamp@ops.ietf.org >Subject: RE: Moving right along ... Switching Type >Date: Wed, 31 Oct 2001 17:43:07 -0800 > >Not exactly. When the switching type advertised in the link state database >is TDM, then >the signalling request doesn't require a switching type with a value of TDM > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Wednesday, October 31, 2001 5:32 PM >To: dimitri.papadimitriou@alcatel.be >Cc: zwlin@lucent.com; John Drake; Ben.Mack-Crane@tellabs.com; >kireeti@juniper.net; ccamp@ops.ietf.org >Subject: Re: Moving right along ... Switching Type > > >Hi Dimitri, > This means that switching type is not valid when LSP >encoding > >type is SDH/SONET. Is this true ? > >Thank You for ur help. > >Regards, >manoj. > > >From: Dimitri Papadimitriou > >To: manoj juneja > >CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com, > >kireeti@juniper.net, ccamp@ops.ietf.org > >Subject: Re: Moving right along ... Switching Type > >Date: Thu, 01 Nov 2001 01:30:49 +0100 > > > >Hi Manoj, > > > >When Traffic_Parameters are used to create VC-4-Xc LSP for > >instance, Switching Type would take a default value without > >significance on the node switching capability preference since > >inferred by the Traffic_Parameters. So when creating SDH/Sonet > >LSP the Switching Type value will be ignored. > > > >PS: better to rephrase the below sentence as follows: > > > >The usage of this field is thus optional and can (when applicable) > > > >only be considered when traffic parameters are not defined. > > > >Hope this clarifies, > > > >- dimitri. > > > >manoj juneja wrote: > > > > > > Hi Dimitri, > > > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As > > > per my understanding these are mandatory as it gives information > > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC > > > etc). If SDH/SONET traffic parameters are not present then how can I > > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching > > > type ? > > > > > > Please correct me if I am wrong. > > > > > > Regards, > > > manoj. > > > > > > >From: Dimitri Papadimitriou > > > >To: Zhi-Wei Lin > > > >CC: John Drake , "'Ben Mack-Crane'" > > > >, Kireeti Kompella >, > > > >ccamp@ops.ietf.org > > > >Subject: Re: Moving right along ... Switching Type > > > >Date: Wed, 31 Oct 2001 23:52:16 +0100 > > > > > > > >Hi, > > > > > > > >We have two approaches either "traffic-parameters" are used > > > >(in SENDER_TSPEC) then i think the Switching Type capability > > > >is useless or they aren't then such field could be optionaly > > > >used when applicable (some examples are given in the routing > > > >document). > > > > > > > >Wouldn't be the right way to proceed by defining an "unknown" > > > >or "unspecified" value used when "traffic-parameters" are > > > >included within the Path Message and optional use the ones > > > >proposed in the current version of the specification when they > > > >aren't. This field is thus optional and MUST only be used when > > > >traffic parameters are not defined. I think this solves both > > > >approaches. > > > > > > > >I think that also some additional text is needed in order to > > > >clarify the semantic; the following one can be proposed (after > > > >having discussed with some individuals): > > > >"The Switching Type field is provided to allow nodes having > > > >multiple switching layer capabilities to indicate their > > > >preference. This field should only be used to indicate the > > > >link switching preference but not end-to-end switching > > > >preference". > > > > > > > >Notice that some proposal concerning the applicability scope > > > >have been proposed but never really committed within the I-D. > > > > > > > >Cheers, > > > >- dimitri. > > > > > > > >Zhi-Wei Lin wrote: > > > > > > > > > > Hi John, > > > > > > > > > > > The section you mentioned, from what I can tell, is an >example > >list > > > > > > of some possible combinations of different equipment functions. >I > >see > > > > > > them as examples. But as I said, from routing perspective, it >may > >make > > > > > > sense but not signaling. What you've pointed out is the routing > > > >document... > > > > > > From signaling perspective, if I removed the switching >capability > > > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that > >for > > > >all > > > > > > possible combinations of switching capabilities supported on a > >link, > > > >an > > > > > > intermediate node can deduce, from other fields in the Path > >message, > > > >what > > > > > > switching capability is desired. > > > > > > > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > > > different switching capabilities on each side and the possible > > > > > connections and then demonstrate that what switching capability is > > > > > desired can be deduced...hmmm...can't I just say that whatever the > > > > > encoding type says and the sender_tspec says is what the switching > >type > > > > > used (I'm lazy, it takes too long to run through all the > > > >combinations) > > > > > > > > > > > > > > > > > And if I removed the switching capability field, then it opens >the > > > >door > > > > > > for the possibility where somewhere within my network I might > >change > > > >the > > > > > > switching type in order to satisfy a request (because the > >switching > > > >type > > > > > > requested is non-existent or exhausted). > > > > > > > > > > > > > > > > > > JD: Please give an example of where substituting one value of > > > >switching > > > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > > > > > > > Well, for example, you have a SONET network that can provide > >STS-48c, > > > > > and it goes through an all-optical network that can provide OCh1 > >(2.5G > > > > > service). In the SONET network it switches the STS-48c layer, >while > >in > > > > > OTN network it switches the OCh layer. This is very similar to > >E1/VC-12 > > > > > connection, where one part of network may work PDH-based and > >switching > > > > > E1 while another part may be SDH-based and switching VC-12, but >the > > > > > connection or service is essentially the same. They're not really > > > > > client-server layers but similar layers from different > > > >technologies... > > > > > > > > > > > I think it does make sense. I think you have to assume that > >within > > > > > > the switched transport network there will be many kinds of > >interfaces > > > > > > connecting to the transport network. If you can't offer this > > > >capability, > > > > > > then essentially what you've done is segment the transport >network > > > >into > > > > > > sub-networks based on what interfaces they have and only the > >like-type > > > > > > interfaces can connect to each other. If you look at the IP >world, > > >you > > > > > > might have a switch with 100 Mbps and another with 10 Mbps > >connected > > > > > > together and talking to each other without a problem. This is > > > >capability > > > > > > that is also needed, where one end could be 1 Gbps Ethernet and > > > >another > > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET > >(no > > > > > > reason to restrict this). What really matters is that the >service > >is > > > > > > delivered. Granted there will be some inefficiencies in this, >but > > > >that's > > > > > > really a policy decision whether users are willing to accept >this > >type > > > > > > of connection. > > > > > > > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just > >fine. > > > >What > > > > > > you were describing in your previous example was an LSP, one end > >of > > > >which > > > > > > was > > > > > > PSC and the other end of which was TDM. And that doesn't make > >sense. > > > > > > > > > > > > > > > > Maybe this is one where we need to ask individuals with > >operational > > > > > experience and have some experience with service provisioning > >whether > > > > > having one end with Ethernet and another end with OC-48 sounds >like > >a > > > > > configuration that makes sense? > > > > > > > > > > Again, the point here is that if this doesn't make sense, then > > > > > essentially what you have is multiple switched networks, each > >serving > > > > > one particular type of customer interface, i.e., a switched >network > >for > > > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > > > > > Is this one of those "violent agreements" where we're >concentrating > >on > > > > > two different levels but saying the same thing? > > > ><< dimitri.papadimitriou.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< dimitri.papadimitriou.vcf >> > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 18:08:16 -0800 From: "manoj juneja" To: jdrake@calient.net, dimitri.papadimitriou@alcatel.be Cc: zwlin@lucent.com, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 19:07:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi John, If the switching type advertised in the link state database is say Lambda or Fiber then why we need to carry this in signalling ? Regards, manoj. >From: John Drake >To: 'manoj juneja' , >dimitri.papadimitriou@alcatel.be >CC: zwlin@lucent.com, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, >ccamp@ops.ietf.org >Subject: RE: Moving right along ... Switching Type >Date: Wed, 31 Oct 2001 17:43:07 -0800 > >Not exactly. When the switching type advertised in the link state database >is TDM, then >the signalling request doesn't require a switching type with a value of TDM > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Wednesday, October 31, 2001 5:32 PM >To: dimitri.papadimitriou@alcatel.be >Cc: zwlin@lucent.com; John Drake; Ben.Mack-Crane@tellabs.com; >kireeti@juniper.net; ccamp@ops.ietf.org >Subject: Re: Moving right along ... Switching Type > > >Hi Dimitri, > This means that switching type is not valid when LSP >encoding > >type is SDH/SONET. Is this true ? > >Thank You for ur help. > >Regards, >manoj. > > >From: Dimitri Papadimitriou > >To: manoj juneja > >CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com, > >kireeti@juniper.net, ccamp@ops.ietf.org > >Subject: Re: Moving right along ... Switching Type > >Date: Thu, 01 Nov 2001 01:30:49 +0100 > > > >Hi Manoj, > > > >When Traffic_Parameters are used to create VC-4-Xc LSP for > >instance, Switching Type would take a default value without > >significance on the node switching capability preference since > >inferred by the Traffic_Parameters. So when creating SDH/Sonet > >LSP the Switching Type value will be ignored. > > > >PS: better to rephrase the below sentence as follows: > > > >The usage of this field is thus optional and can (when applicable) > > > >only be considered when traffic parameters are not defined. > > > >Hope this clarifies, > > > >- dimitri. > > > >manoj juneja wrote: > > > > > > Hi Dimitri, > > > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As > > > per my understanding these are mandatory as it gives information > > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC > > > etc). If SDH/SONET traffic parameters are not present then how can I > > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching > > > type ? > > > > > > Please correct me if I am wrong. > > > > > > Regards, > > > manoj. > > > > > > >From: Dimitri Papadimitriou > > > >To: Zhi-Wei Lin > > > >CC: John Drake , "'Ben Mack-Crane'" > > > >, Kireeti Kompella >, > > > >ccamp@ops.ietf.org > > > >Subject: Re: Moving right along ... Switching Type > > > >Date: Wed, 31 Oct 2001 23:52:16 +0100 > > > > > > > >Hi, > > > > > > > >We have two approaches either "traffic-parameters" are used > > > >(in SENDER_TSPEC) then i think the Switching Type capability > > > >is useless or they aren't then such field could be optionaly > > > >used when applicable (some examples are given in the routing > > > >document). > > > > > > > >Wouldn't be the right way to proceed by defining an "unknown" > > > >or "unspecified" value used when "traffic-parameters" are > > > >included within the Path Message and optional use the ones > > > >proposed in the current version of the specification when they > > > >aren't. This field is thus optional and MUST only be used when > > > >traffic parameters are not defined. I think this solves both > > > >approaches. > > > > > > > >I think that also some additional text is needed in order to > > > >clarify the semantic; the following one can be proposed (after > > > >having discussed with some individuals): > > > >"The Switching Type field is provided to allow nodes having > > > >multiple switching layer capabilities to indicate their > > > >preference. This field should only be used to indicate the > > > >link switching preference but not end-to-end switching > > > >preference". > > > > > > > >Notice that some proposal concerning the applicability scope > > > >have been proposed but never really committed within the I-D. > > > > > > > >Cheers, > > > >- dimitri. > > > > > > > >Zhi-Wei Lin wrote: > > > > > > > > > > Hi John, > > > > > > > > > > > The section you mentioned, from what I can tell, is an >example > >list > > > > > > of some possible combinations of different equipment functions. >I > >see > > > > > > them as examples. But as I said, from routing perspective, it >may > >make > > > > > > sense but not signaling. What you've pointed out is the routing > > > >document... > > > > > > From signaling perspective, if I removed the switching >capability > > > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that > >for > > > >all > > > > > > possible combinations of switching capabilities supported on a > >link, > > > >an > > > > > > intermediate node can deduce, from other fields in the Path > >message, > > > >what > > > > > > switching capability is desired. > > > > > > > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > > > different switching capabilities on each side and the possible > > > > > connections and then demonstrate that what switching capability is > > > > > desired can be deduced...hmmm...can't I just say that whatever the > > > > > encoding type says and the sender_tspec says is what the switching > >type > > > > > used (I'm lazy, it takes too long to run through all the > > > >combinations) > > > > > > > > > > > > > > > > > And if I removed the switching capability field, then it opens >the > > > >door > > > > > > for the possibility where somewhere within my network I might > >change > > > >the > > > > > > switching type in order to satisfy a request (because the > >switching > > > >type > > > > > > requested is non-existent or exhausted). > > > > > > > > > > > > > > > > > > JD: Please give an example of where substituting one value of > > > >switching > > > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > > > > > > > Well, for example, you have a SONET network that can provide > >STS-48c, > > > > > and it goes through an all-optical network that can provide OCh1 > >(2.5G > > > > > service). In the SONET network it switches the STS-48c layer, >while > >in > > > > > OTN network it switches the OCh layer. This is very similar to > >E1/VC-12 > > > > > connection, where one part of network may work PDH-based and > >switching > > > > > E1 while another part may be SDH-based and switching VC-12, but >the > > > > > connection or service is essentially the same. They're not really > > > > > client-server layers but similar layers from different > > > >technologies... > > > > > > > > > > > I think it does make sense. I think you have to assume that > >within > > > > > > the switched transport network there will be many kinds of > >interfaces > > > > > > connecting to the transport network. If you can't offer this > > > >capability, > > > > > > then essentially what you've done is segment the transport >network > > > >into > > > > > > sub-networks based on what interfaces they have and only the > >like-type > > > > > > interfaces can connect to each other. If you look at the IP >world, > > >you > > > > > > might have a switch with 100 Mbps and another with 10 Mbps > >connected > > > > > > together and talking to each other without a problem. This is > > > >capability > > > > > > that is also needed, where one end could be 1 Gbps Ethernet and > > > >another > > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET > >(no > > > > > > reason to restrict this). What really matters is that the >service > >is > > > > > > delivered. Granted there will be some inefficiencies in this, >but > > > >that's > > > > > > really a policy decision whether users are willing to accept >this > >type > > > > > > of connection. > > > > > > > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just > >fine. > > > >What > > > > > > you were describing in your previous example was an LSP, one end > >of > > > >which > > > > > > was > > > > > > PSC and the other end of which was TDM. And that doesn't make > >sense. > > > > > > > > > > > > > > > > Maybe this is one where we need to ask individuals with > >operational > > > > > experience and have some experience with service provisioning > >whether > > > > > having one end with Ethernet and another end with OC-48 sounds >like > >a > > > > > configuration that makes sense? > > > > > > > > > > Again, the point here is that if this doesn't make sense, then > > > > > essentially what you have is multiple switched networks, each > >serving > > > > > one particular type of customer interface, i.e., a switched >network > >for > > > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > > > > > Is this one of those "violent agreements" where we're >concentrating > >on > > > > > two different levels but saying the same thing? > > > ><< dimitri.papadimitriou.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< dimitri.papadimitriou.vcf >> > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 17:45:10 -0800 Message-ID: From: John Drake To: 'manoj juneja' , dimitri.papadimitriou@alcatel.be Cc: zwlin@lucent.com, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 17:43:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Not exactly. When the switching type advertised in the link state database is TDM, then the signalling request doesn't require a switching type with a value of TDM -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Wednesday, October 31, 2001 5:32 PM To: dimitri.papadimitriou@alcatel.be Cc: zwlin@lucent.com; John Drake; Ben.Mack-Crane@tellabs.com; kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Hi Dimitri, This means that switching type is not valid when LSP encoding type is SDH/SONET. Is this true ? Thank You for ur help. Regards, manoj. >From: Dimitri Papadimitriou >To: manoj juneja >CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com, >kireeti@juniper.net, ccamp@ops.ietf.org >Subject: Re: Moving right along ... Switching Type >Date: Thu, 01 Nov 2001 01:30:49 +0100 > >Hi Manoj, > >When Traffic_Parameters are used to create VC-4-Xc LSP for >instance, Switching Type would take a default value without >significance on the node switching capability preference since >inferred by the Traffic_Parameters. So when creating SDH/Sonet >LSP the Switching Type value will be ignored. > >PS: better to rephrase the below sentence as follows: > > >The usage of this field is thus optional and can (when applicable) > > >only be considered when traffic parameters are not defined. > >Hope this clarifies, > >- dimitri. > >manoj juneja wrote: > > > > Hi Dimitri, > > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As > > per my understanding these are mandatory as it gives information > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC > > etc). If SDH/SONET traffic parameters are not present then how can I > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching > > type ? > > > > Please correct me if I am wrong. > > > > Regards, > > manoj. > > > > >From: Dimitri Papadimitriou > > >To: Zhi-Wei Lin > > >CC: John Drake , "'Ben Mack-Crane'" > > >, Kireeti Kompella , > > >ccamp@ops.ietf.org > > >Subject: Re: Moving right along ... Switching Type > > >Date: Wed, 31 Oct 2001 23:52:16 +0100 > > > > > >Hi, > > > > > >We have two approaches either "traffic-parameters" are used > > >(in SENDER_TSPEC) then i think the Switching Type capability > > >is useless or they aren't then such field could be optionaly > > >used when applicable (some examples are given in the routing > > >document). > > > > > >Wouldn't be the right way to proceed by defining an "unknown" > > >or "unspecified" value used when "traffic-parameters" are > > >included within the Path Message and optional use the ones > > >proposed in the current version of the specification when they > > >aren't. This field is thus optional and MUST only be used when > > >traffic parameters are not defined. I think this solves both > > >approaches. > > > > > >I think that also some additional text is needed in order to > > >clarify the semantic; the following one can be proposed (after > > >having discussed with some individuals): > > >"The Switching Type field is provided to allow nodes having > > >multiple switching layer capabilities to indicate their > > >preference. This field should only be used to indicate the > > >link switching preference but not end-to-end switching > > >preference". > > > > > >Notice that some proposal concerning the applicability scope > > >have been proposed but never really committed within the I-D. > > > > > >Cheers, > > >- dimitri. > > > > > >Zhi-Wei Lin wrote: > > > > > > > > Hi John, > > > > > > > > > The section you mentioned, from what I can tell, is an example >list > > > > > of some possible combinations of different equipment functions. I >see > > > > > them as examples. But as I said, from routing perspective, it may >make > > > > > sense but not signaling. What you've pointed out is the routing > > >document... > > > > > From signaling perspective, if I removed the switching capability > > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that >for > > >all > > > > > possible combinations of switching capabilities supported on a >link, > > >an > > > > > intermediate node can deduce, from other fields in the Path >message, > > >what > > > > > switching capability is desired. > > > > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > > different switching capabilities on each side and the possible > > > > connections and then demonstrate that what switching capability is > > > > desired can be deduced...hmmm...can't I just say that whatever the > > > > encoding type says and the sender_tspec says is what the switching >type > > > > used (I'm lazy, it takes too long to run through all the > > >combinations) > > > > > > > > > > > > > > And if I removed the switching capability field, then it opens the > > >door > > > > > for the possibility where somewhere within my network I might >change > > >the > > > > > switching type in order to satisfy a request (because the >switching > > >type > > > > > requested is non-existent or exhausted). > > > > > > > > > > > > > > > JD: Please give an example of where substituting one value of > > >switching > > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > > > > Well, for example, you have a SONET network that can provide >STS-48c, > > > > and it goes through an all-optical network that can provide OCh1 >(2.5G > > > > service). In the SONET network it switches the STS-48c layer, while >in > > > > OTN network it switches the OCh layer. This is very similar to >E1/VC-12 > > > > connection, where one part of network may work PDH-based and >switching > > > > E1 while another part may be SDH-based and switching VC-12, but the > > > > connection or service is essentially the same. They're not really > > > > client-server layers but similar layers from different > > >technologies... > > > > > > > > > I think it does make sense. I think you have to assume that >within > > > > > the switched transport network there will be many kinds of >interfaces > > > > > connecting to the transport network. If you can't offer this > > >capability, > > > > > then essentially what you've done is segment the transport network > > >into > > > > > sub-networks based on what interfaces they have and only the >like-type > > > > > interfaces can connect to each other. If you look at the IP world, >you > > > > > might have a switch with 100 Mbps and another with 10 Mbps >connected > > > > > together and talking to each other without a problem. This is > > >capability > > > > > that is also needed, where one end could be 1 Gbps Ethernet and > > >another > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET >(no > > > > > reason to restrict this). What really matters is that the service >is > > > > > delivered. Granted there will be some inefficiencies in this, but > > >that's > > > > > really a policy decision whether users are willing to accept this >type > > > > > of connection. > > > > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just >fine. > > >What > > > > > you were describing in your previous example was an LSP, one end >of > > >which > > > > > was > > > > > PSC and the other end of which was TDM. And that doesn't make >sense. > > > > > > > > > > > > > Maybe this is one where we need to ask individuals with >operational > > > > experience and have some experience with service provisioning >whether > > > > having one end with Ethernet and another end with OC-48 sounds like >a > > > > configuration that makes sense? > > > > > > > > Again, the point here is that if this doesn't make sense, then > > > > essentially what you have is multiple switched networks, each >serving > > > > one particular type of customer interface, i.e., a switched network >for > > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > > > Is this one of those "violent agreements" where we're concentrating >on > > > > two different levels but saying the same thing? > > ><< dimitri.papadimitriou.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 17:42:01 -0800 Message-ID: From: John Drake To: 'Yakov Rekhter' , Dimitri Papadimitriou Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 17:39:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" seems fine -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Wednesday, October 31, 2001 5:21 PM To: Dimitri Papadimitriou Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Dimitri, > We have two approaches either "traffic-parameters" are used > (in SENDER_TSPEC) then i think the Switching Type capability > is useless or they aren't then such field could be optionaly > used when applicable (some examples are given in the routing > document). > > Wouldn't be the right way to proceed by defining an "unknown" > or "unspecified" value used when "traffic-parameters" are > included within the Path Message and optional use the ones > proposed in the current version of the specification when they > aren't. This field is thus optional and MUST only be used when > traffic parameters are not defined. I think this solves both > approaches. Agreed. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 17:34:18 -0800 From: "manoj juneja" To: dimitri.papadimitriou@alcatel.be Cc: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 18:32:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dimitri, This means that switching type is not valid when LSP encoding type is SDH/SONET. Is this true ? Thank You for ur help. Regards, manoj. >From: Dimitri Papadimitriou >To: manoj juneja >CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com, >kireeti@juniper.net, ccamp@ops.ietf.org >Subject: Re: Moving right along ... Switching Type >Date: Thu, 01 Nov 2001 01:30:49 +0100 > >Hi Manoj, > >When Traffic_Parameters are used to create VC-4-Xc LSP for >instance, Switching Type would take a default value without >significance on the node switching capability preference since >inferred by the Traffic_Parameters. So when creating SDH/Sonet >LSP the Switching Type value will be ignored. > >PS: better to rephrase the below sentence as follows: > > >The usage of this field is thus optional and can (when applicable) > > >only be considered when traffic parameters are not defined. > >Hope this clarifies, > >- dimitri. > >manoj juneja wrote: > > > > Hi Dimitri, > > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As > > per my understanding these are mandatory as it gives information > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC > > etc). If SDH/SONET traffic parameters are not present then how can I > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching > > type ? > > > > Please correct me if I am wrong. > > > > Regards, > > manoj. > > > > >From: Dimitri Papadimitriou > > >To: Zhi-Wei Lin > > >CC: John Drake , "'Ben Mack-Crane'" > > >, Kireeti Kompella , > > >ccamp@ops.ietf.org > > >Subject: Re: Moving right along ... Switching Type > > >Date: Wed, 31 Oct 2001 23:52:16 +0100 > > > > > >Hi, > > > > > >We have two approaches either "traffic-parameters" are used > > >(in SENDER_TSPEC) then i think the Switching Type capability > > >is useless or they aren't then such field could be optionaly > > >used when applicable (some examples are given in the routing > > >document). > > > > > >Wouldn't be the right way to proceed by defining an "unknown" > > >or "unspecified" value used when "traffic-parameters" are > > >included within the Path Message and optional use the ones > > >proposed in the current version of the specification when they > > >aren't. This field is thus optional and MUST only be used when > > >traffic parameters are not defined. I think this solves both > > >approaches. > > > > > >I think that also some additional text is needed in order to > > >clarify the semantic; the following one can be proposed (after > > >having discussed with some individuals): > > >"The Switching Type field is provided to allow nodes having > > >multiple switching layer capabilities to indicate their > > >preference. This field should only be used to indicate the > > >link switching preference but not end-to-end switching > > >preference". > > > > > >Notice that some proposal concerning the applicability scope > > >have been proposed but never really committed within the I-D. > > > > > >Cheers, > > >- dimitri. > > > > > >Zhi-Wei Lin wrote: > > > > > > > > Hi John, > > > > > > > > > The section you mentioned, from what I can tell, is an example >list > > > > > of some possible combinations of different equipment functions. I >see > > > > > them as examples. But as I said, from routing perspective, it may >make > > > > > sense but not signaling. What you've pointed out is the routing > > >document... > > > > > From signaling perspective, if I removed the switching capability > > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that >for > > >all > > > > > possible combinations of switching capabilities supported on a >link, > > >an > > > > > intermediate node can deduce, from other fields in the Path >message, > > >what > > > > > switching capability is desired. > > > > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > > different switching capabilities on each side and the possible > > > > connections and then demonstrate that what switching capability is > > > > desired can be deduced...hmmm...can't I just say that whatever the > > > > encoding type says and the sender_tspec says is what the switching >type > > > > used (I'm lazy, it takes too long to run through all the > > >combinations) > > > > > > > > > > > > > > And if I removed the switching capability field, then it opens the > > >door > > > > > for the possibility where somewhere within my network I might >change > > >the > > > > > switching type in order to satisfy a request (because the >switching > > >type > > > > > requested is non-existent or exhausted). > > > > > > > > > > > > > > > JD: Please give an example of where substituting one value of > > >switching > > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > > > > Well, for example, you have a SONET network that can provide >STS-48c, > > > > and it goes through an all-optical network that can provide OCh1 >(2.5G > > > > service). In the SONET network it switches the STS-48c layer, while >in > > > > OTN network it switches the OCh layer. This is very similar to >E1/VC-12 > > > > connection, where one part of network may work PDH-based and >switching > > > > E1 while another part may be SDH-based and switching VC-12, but the > > > > connection or service is essentially the same. They're not really > > > > client-server layers but similar layers from different > > >technologies... > > > > > > > > > I think it does make sense. I think you have to assume that >within > > > > > the switched transport network there will be many kinds of >interfaces > > > > > connecting to the transport network. If you can't offer this > > >capability, > > > > > then essentially what you've done is segment the transport network > > >into > > > > > sub-networks based on what interfaces they have and only the >like-type > > > > > interfaces can connect to each other. If you look at the IP world, >you > > > > > might have a switch with 100 Mbps and another with 10 Mbps >connected > > > > > together and talking to each other without a problem. This is > > >capability > > > > > that is also needed, where one end could be 1 Gbps Ethernet and > > >another > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET >(no > > > > > reason to restrict this). What really matters is that the service >is > > > > > delivered. Granted there will be some inefficiencies in this, but > > >that's > > > > > really a policy decision whether users are willing to accept this >type > > > > > of connection. > > > > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just >fine. > > >What > > > > > you were describing in your previous example was an LSP, one end >of > > >which > > > > > was > > > > > PSC and the other end of which was TDM. And that doesn't make >sense. > > > > > > > > > > > > > Maybe this is one where we need to ask individuals with >operational > > > > experience and have some experience with service provisioning >whether > > > > having one end with Ethernet and another end with OC-48 sounds like >a > > > > configuration that makes sense? > > > > > > > > Again, the point here is that if this doesn't make sense, then > > > > essentially what you have is multiple switched networks, each >serving > > > > one particular type of customer interface, i.e., a switched network >for > > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > > > Is this one of those "violent agreements" where we're concentrating >on > > > > two different levels but saying the same thing? > > ><< dimitri.papadimitriou.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 17:22:38 -0800 Message-Id: <200111010121.fA11L9052917@merlot.juniper.net> To: Dimitri Papadimitriou cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55536.1004577669.1@juniper.net> Date: Wed, 31 Oct 2001 17:21:09 -0800 From: Yakov Rekhter Dimitri, > We have two approaches either "traffic-parameters" are used > (in SENDER_TSPEC) then i think the Switching Type capability > is useless or they aren't then such field could be optionaly > used when applicable (some examples are given in the routing > document). > > Wouldn't be the right way to proceed by defining an "unknown" > or "unspecified" value used when "traffic-parameters" are > included within the Path Message and optional use the ones > proposed in the current version of the specification when they > aren't. This field is thus optional and MUST only be used when > traffic parameters are not defined. I think this solves both > approaches. Agreed. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 17:20:54 -0800 Message-Id: <200111010118.fA11IX052663@merlot.juniper.net> To: Zhi-Wei Lin cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54522.1004577512.1@juniper.net> Date: Wed, 31 Oct 2001 17:18:32 -0800 From: Yakov Rekhter Zhi-Wei, > Maybe this is one where we need to ask individuals with operational > experience and have some experience with service provisioning whether > having one end with Ethernet and another end with OC-48 sounds like a > configuration that makes sense? Let me see if I understand your proposal. Consider the following example: R1---OXC1---OXC2----R2 where the TE interface on R1 is a collection of GigE ports, and the TE interface on R2 is a collection of OC-48 ports. Are you saying that establishing an LSP between R1 to R2 makes sense ? Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 17:20:49 -0800 Message-ID: From: John Drake To: 'Ben Mack-Crane' Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 17:17:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] Sent: Wednesday, October 31, 2001 2:10 PM To: John Drake Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type John, I had read the routing drafts (as thet are referenced from the signaling drafts), and was expressing confusion as a result. The Switching Type values are very broad (each includes several possible encapsulations, including NULL, of the LSP being created). What exactly they include is not clear. For example I don't know where G.709 switching would be included. In fact, even the names are a bit confusing, for example "TDM Capable" -- I don't see what multiplexing has to do with switching (one can switch among both multiplexed and non-multiplexed interfaces). I assume "TDM Capable" means SONET/SDH and maybe PDH... JD: All of the above. Switching Capability is just a rename of Link Multiplex. I have always thought that the LSP Encoding Type, along with the TSPEC, was sufficient to indicate what was being setup (switched) and that how that LSP was encapsulated on each link was a local issue. For example, a packet LSP may be encapsulated in Ethernet, ATM, or FR on any given link along its path, even switched in those forms over several hops, but this is not an end-to-end concern. In fact, restricting the switching type in this case would only artificially restrict the set of available routes. JD: The LSP encoding type doesn't indicate a link's multiplexing capabilities. The switching capability, nee multiplexing capability, is used to indicate the type of LSPs that can be multiplexed on that link. Similarly, I think that if one wants to set up an OC-48 RS transparent LSP, it may be switched at some hop(s) over Lambda-Switch capable links and at some hops over TDM Capable links or even Fiber Switch capable links, and that is just fine. Why one would want to restrict this is not clear. JD: The way that this would be done in GMPLS is through the use of LSP hierarchy. Regards, Ben John Drake wrote: > > Ben, > > I think part of the problem is that you also need to read the GMPLS routing > drafts: > > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > > There are also comments in your text. > > Thanks, > > John > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Monday, October 29, 2001 9:53 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > In reviewing the GMPLS signaling drafts I have been unable to > get a clear understanding of the need for and use of the Switching > Type field in the Generalized Label Request object. > > JD: The Switching Type field is for handling the situation where there > are multiple switching capabilities per interface (see section 6.4.6 of > draft-ietf-ccamp-gmpls-routing-00.txt) > > This appears to be an attempt to address LSP setup involving multiple > layer networks, but it does not adequately address the issues involved. > > JD: Would you please provide some additional prose explaining your > reasoning on this? > > That it "Indicates the type of switching that should be performed on a > particular link." makes it seem to be a local concern, while others > have indicated it is an end-to-end field. For example, George Swallow > says "It is my understanding that for a given LSP it does not change, > but is carried end-to-end and applies at all intermediate hops along > the path." > > JD: I think George's interpretation is correct, and I don't think the > other text you quoted contradicts George. If a given TE link supports > multiple switching types, the node controlling that link needs to know > what switching type a given LSP wants to use. > > As an end-to-end item I have trouble understanding how the originating node > would determine how to set this (on what basis one determines what switching > choice to make in all cases). In fact, I'm not sure why the originating > node would care what type of switching is used as long as the LSP is > delivered > to the egress faithfully. > > JD: The orgin node uses the switching capability information in the link > state > database in its CSPF calculation to ensure that switching capability is > consistent > along the path of the LSP. > > Regards, > Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 16:36:43 -0800 Message-ID: <3BE097B9.8D471127@alcatel.be> Date: Thu, 01 Nov 2001 01:30:49 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: manoj juneja CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------3C32C4292B884F76205AB78B" This is a multi-part message in MIME format. --------------3C32C4292B884F76205AB78B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Manoj, When Traffic_Parameters are used to create VC-4-Xc LSP for instance, Switching Type would take a default value without significance on the node switching capability preference since inferred by the Traffic_Parameters. So when creating SDH/Sonet LSP the Switching Type value will be ignored. PS: better to rephrase the below sentence as follows: > >The usage of this field is thus optional and can (when applicable) > >only be considered when traffic parameters are not defined. Hope this clarifies, - dimitri. manoj juneja wrote: > > Hi Dimitri, > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As > per my understanding these are mandatory as it gives information > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC > etc). If SDH/SONET traffic parameters are not present then how can I > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching > type ? > > Please correct me if I am wrong. > > Regards, > manoj. > > >From: Dimitri Papadimitriou > >To: Zhi-Wei Lin > >CC: John Drake , "'Ben Mack-Crane'" > >, Kireeti Kompella , > >ccamp@ops.ietf.org > >Subject: Re: Moving right along ... Switching Type > >Date: Wed, 31 Oct 2001 23:52:16 +0100 > > > >Hi, > > > >We have two approaches either "traffic-parameters" are used > >(in SENDER_TSPEC) then i think the Switching Type capability > >is useless or they aren't then such field could be optionaly > >used when applicable (some examples are given in the routing > >document). > > > >Wouldn't be the right way to proceed by defining an "unknown" > >or "unspecified" value used when "traffic-parameters" are > >included within the Path Message and optional use the ones > >proposed in the current version of the specification when they > >aren't. This field is thus optional and MUST only be used when > >traffic parameters are not defined. I think this solves both > >approaches. > > > >I think that also some additional text is needed in order to > >clarify the semantic; the following one can be proposed (after > >having discussed with some individuals): > >"The Switching Type field is provided to allow nodes having > >multiple switching layer capabilities to indicate their > >preference. This field should only be used to indicate the > >link switching preference but not end-to-end switching > >preference". > > > >Notice that some proposal concerning the applicability scope > >have been proposed but never really committed within the I-D. > > > >Cheers, > >- dimitri. > > > >Zhi-Wei Lin wrote: > > > > > > Hi John, > > > > > > > The section you mentioned, from what I can tell, is an example list > > > > of some possible combinations of different equipment functions. I see > > > > them as examples. But as I said, from routing perspective, it may make > > > > sense but not signaling. What you've pointed out is the routing > >document... > > > > From signaling perspective, if I removed the switching capability > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for > >all > > > > possible combinations of switching capabilities supported on a link, > >an > > > > intermediate node can deduce, from other fields in the Path message, > >what > > > > switching capability is desired. > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > different switching capabilities on each side and the possible > > > connections and then demonstrate that what switching capability is > > > desired can be deduced...hmmm...can't I just say that whatever the > > > encoding type says and the sender_tspec says is what the switching type > > > used (I'm lazy, it takes too long to run through all the > >combinations) > > > > > > > > > > > And if I removed the switching capability field, then it opens the > >door > > > > for the possibility where somewhere within my network I might change > >the > > > > switching type in order to satisfy a request (because the switching > >type > > > > requested is non-existent or exhausted). > > > > > > > > > > > > JD: Please give an example of where substituting one value of > >switching > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > > and it goes through an all-optical network that can provide OCh1 (2.5G > > > service). In the SONET network it switches the STS-48c layer, while in > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > > connection, where one part of network may work PDH-based and switching > > > E1 while another part may be SDH-based and switching VC-12, but the > > > connection or service is essentially the same. They're not really > > > client-server layers but similar layers from different > >technologies... > > > > > > > I think it does make sense. I think you have to assume that within > > > > the switched transport network there will be many kinds of interfaces > > > > connecting to the transport network. If you can't offer this > >capability, > > > > then essentially what you've done is segment the transport network > >into > > > > sub-networks based on what interfaces they have and only the like-type > > > > interfaces can connect to each other. If you look at the IP world, you > > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > > together and talking to each other without a problem. This is > >capability > > > > that is also needed, where one end could be 1 Gbps Ethernet and > >another > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > > reason to restrict this). What really matters is that the service is > > > > delivered. Granted there will be some inefficiencies in this, but > >that's > > > > really a policy decision whether users are willing to accept this type > > > > of connection. > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. > >What > > > > you were describing in your previous example was an LSP, one end of > >which > > > > was > > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > > > > Maybe this is one where we need to ask individuals with operational > > > experience and have some experience with service provisioning whether > > > having one end with Ethernet and another end with OC-48 sounds like a > > > configuration that makes sense? > > > > > > Again, the point here is that if this doesn't make sense, then > > > essentially what you have is multiple switched networks, each serving > > > one particular type of customer interface, i.e., a switched network for > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > Is this one of those "violent agreements" where we're concentrating on > > > two different levels but saying the same thing? > ><< dimitri.papadimitriou.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------3C32C4292B884F76205AB78B Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------3C32C4292B884F76205AB78B-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 15:47:39 -0800 From: "manoj juneja" To: dimitri.papadimitriou@alcatel.be, zwlin@lucent.com Cc: jdrake@calient.net, Ben.Mack-Crane@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 16:43:33 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dimitri, Are SDH/SONET traffic params in SNDER_TSPEC optional ? As per my understanding these are mandatory as it gives information regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC etc). If SDH/SONET traffic parameters are not present then how can I determine these fields i.e. NCC, NVC, RCC, signals etc. from switching type ? Please correct me if I am wrong. Regards, manoj. >From: Dimitri Papadimitriou >To: Zhi-Wei Lin >CC: John Drake , "'Ben Mack-Crane'" >, Kireeti Kompella , >ccamp@ops.ietf.org >Subject: Re: Moving right along ... Switching Type >Date: Wed, 31 Oct 2001 23:52:16 +0100 > >Hi, > >We have two approaches either "traffic-parameters" are used >(in SENDER_TSPEC) then i think the Switching Type capability >is useless or they aren't then such field could be optionaly >used when applicable (some examples are given in the routing >document). > >Wouldn't be the right way to proceed by defining an "unknown" >or "unspecified" value used when "traffic-parameters" are >included within the Path Message and optional use the ones >proposed in the current version of the specification when they >aren't. This field is thus optional and MUST only be used when >traffic parameters are not defined. I think this solves both >approaches. > >I think that also some additional text is needed in order to >clarify the semantic; the following one can be proposed (after >having discussed with some individuals): >"The Switching Type field is provided to allow nodes having >multiple switching layer capabilities to indicate their >preference. This field should only be used to indicate the >link switching preference but not end-to-end switching >preference". > >Notice that some proposal concerning the applicability scope >have been proposed but never really committed within the I-D. > >Cheers, >- dimitri. > >Zhi-Wei Lin wrote: > > > > Hi John, > > > > > The section you mentioned, from what I can tell, is an example list > > > of some possible combinations of different equipment functions. I see > > > them as examples. But as I said, from routing perspective, it may make > > > sense but not signaling. What you've pointed out is the routing >document... > > > From signaling perspective, if I removed the switching capability > > > field, there is nothing lost...do you agree? > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for >all > > > possible combinations of switching capabilities supported on a link, >an > > > intermediate node can deduce, from other fields in the Path message, >what > > > switching capability is desired. > > > > > > > Wow...ok...so I have to list all the different combinations of > > different switching capabilities on each side and the possible > > connections and then demonstrate that what switching capability is > > desired can be deduced...hmmm...can't I just say that whatever the > > encoding type says and the sender_tspec says is what the switching type > > used (I'm lazy, it takes too long to run through all the >combinations) > > > > > > > > And if I removed the switching capability field, then it opens the >door > > > for the possibility where somewhere within my network I might change >the > > > switching type in order to satisfy a request (because the switching >type > > > requested is non-existent or exhausted). > > > > > > > > > JD: Please give an example of where substituting one value of >switching > > > capability for another in the middle of an LSP makes sense. > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > and it goes through an all-optical network that can provide OCh1 (2.5G > > service). In the SONET network it switches the STS-48c layer, while in > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > connection, where one part of network may work PDH-based and switching > > E1 while another part may be SDH-based and switching VC-12, but the > > connection or service is essentially the same. They're not really > > client-server layers but similar layers from different >technologies... > > > > > I think it does make sense. I think you have to assume that within > > > the switched transport network there will be many kinds of interfaces > > > connecting to the transport network. If you can't offer this >capability, > > > then essentially what you've done is segment the transport network >into > > > sub-networks based on what interfaces they have and only the like-type > > > interfaces can connect to each other. If you look at the IP world, you > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > together and talking to each other without a problem. This is >capability > > > that is also needed, where one end could be 1 Gbps Ethernet and >another > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > reason to restrict this). What really matters is that the service is > > > delivered. Granted there will be some inefficiencies in this, but >that's > > > really a policy decision whether users are willing to accept this type > > > of connection. > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. >What > > > you were describing in your previous example was an LSP, one end of >which > > > was > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > Maybe this is one where we need to ask individuals with operational > > experience and have some experience with service provisioning whether > > having one end with Ethernet and another end with OC-48 sounds like a > > configuration that makes sense? > > > > Again, the point here is that if this doesn't make sense, then > > essentially what you have is multiple switched networks, each serving > > one particular type of customer interface, i.e., a switched network for > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > Is this one of those "violent agreements" where we're concentrating on > > two different levels but saying the same thing? ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 14:59:42 -0800 Message-ID: <3BE080A0.8A5D45CF@alcatel.be> Date: Wed, 31 Oct 2001 23:52:16 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Zhi-Wei Lin CC: John Drake , "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------EB27C59D3EBF0CD7965DFC1B" This is a multi-part message in MIME format. --------------EB27C59D3EBF0CD7965DFC1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We have two approaches either "traffic-parameters" are used (in SENDER_TSPEC) then i think the Switching Type capability is useless or they aren't then such field could be optionaly used when applicable (some examples are given in the routing document). Wouldn't be the right way to proceed by defining an "unknown" or "unspecified" value used when "traffic-parameters" are included within the Path Message and optional use the ones proposed in the current version of the specification when they aren't. This field is thus optional and MUST only be used when traffic parameters are not defined. I think this solves both approaches. I think that also some additional text is needed in order to clarify the semantic; the following one can be proposed (after having discussed with some individuals): "The Switching Type field is provided to allow nodes having multiple switching layer capabilities to indicate their preference. This field should only be used to indicate the link switching preference but not end-to-end switching preference". Notice that some proposal concerning the applicability scope have been proposed but never really committed within the I-D. Cheers, - dimitri. Zhi-Wei Lin wrote: > > Hi John, > > > The section you mentioned, from what I can tell, is an example list > > of some possible combinations of different equipment functions. I see > > them as examples. But as I said, from routing perspective, it may make > > sense but not signaling. What you've pointed out is the routing document... > > From signaling perspective, if I removed the switching capability > > field, there is nothing lost...do you agree? > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > possible combinations of switching capabilities supported on a link, an > > intermediate node can deduce, from other fields in the Path message, what > > switching capability is desired. > > > > Wow...ok...so I have to list all the different combinations of > different switching capabilities on each side and the possible > connections and then demonstrate that what switching capability is > desired can be deduced...hmmm...can't I just say that whatever the > encoding type says and the sender_tspec says is what the switching type > used (I'm lazy, it takes too long to run through all the combinations) > > > > > And if I removed the switching capability field, then it opens the door > > for the possibility where somewhere within my network I might change the > > switching type in order to satisfy a request (because the switching type > > requested is non-existent or exhausted). > > > > > > JD: Please give an example of where substituting one value of switching > > capability for another in the middle of an LSP makes sense. > > > > Well, for example, you have a SONET network that can provide STS-48c, > and it goes through an all-optical network that can provide OCh1 (2.5G > service). In the SONET network it switches the STS-48c layer, while in > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > connection, where one part of network may work PDH-based and switching > E1 while another part may be SDH-based and switching VC-12, but the > connection or service is essentially the same. They're not really > client-server layers but similar layers from different technologies... > > > I think it does make sense. I think you have to assume that within > > the switched transport network there will be many kinds of interfaces > > connecting to the transport network. If you can't offer this capability, > > then essentially what you've done is segment the transport network into > > sub-networks based on what interfaces they have and only the like-type > > interfaces can connect to each other. If you look at the IP world, you > > might have a switch with 100 Mbps and another with 10 Mbps connected > > together and talking to each other without a problem. This is capability > > that is also needed, where one end could be 1 Gbps Ethernet and another > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > reason to restrict this). What really matters is that the service is > > delivered. Granted there will be some inefficiencies in this, but that's > > really a policy decision whether users are willing to accept this type > > of connection. > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > you were describing in your previous example was an LSP, one end of which > > was > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > Maybe this is one where we need to ask individuals with operational > experience and have some experience with service provisioning whether > having one end with Ethernet and another end with OC-48 sounds like a > configuration that makes sense? > > Again, the point here is that if this doesn't make sense, then > essentially what you have is multiple switched networks, each serving > one particular type of customer interface, i.e., a switched network for > 1 Gb Ethernet, a switched network for OC-48, etc. > > Is this one of those "violent agreements" where we're concentrating on > two different levels but saying the same thing? --------------EB27C59D3EBF0CD7965DFC1B Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------EB27C59D3EBF0CD7965DFC1B-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 14:17:22 -0800 Message-ID: <3BE076BF.8F7CA518@tellabs.com> Date: Wed, 31 Oct 2001 16:10:07 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: John Drake CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, I had read the routing drafts (as thet are referenced from the signaling drafts), and was expressing confusion as a result. The Switching Type values are very broad (each includes several possible encapsulations, including NULL, of the LSP being created). What exactly they include is not clear. For example I don't know where G.709 switching would be included. In fact, even the names are a bit confusing, for example "TDM Capable" -- I don't see what multiplexing has to do with switching (one can switch among both multiplexed and non-multiplexed interfaces). I assume "TDM Capable" means SONET/SDH and maybe PDH... I have always thought that the LSP Encoding Type, along with the TSPEC, was sufficient to indicate what was being setup (switched) and that how that LSP was encapsulated on each link was a local issue. For example, a packet LSP may be encapsulated in Ethernet, ATM, or FR on any given link along its path, even switched in those forms over several hops, but this is not an end-to-end concern. In fact, restricting the switching type in this case would only artificially restrict the set of available routes. Similarly, I think that if one wants to set up an OC-48 RS transparent LSP, it may be switched at some hop(s) over Lambda-Switch capable links and at some hops over TDM Capable links or even Fiber Switch capable links, and that is just fine. Why one would want to restrict this is not clear. Regards, Ben John Drake wrote: > > Ben, > > I think part of the problem is that you also need to read the GMPLS routing > drafts: > > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > > There are also comments in your text. > > Thanks, > > John > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Monday, October 29, 2001 9:53 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > In reviewing the GMPLS signaling drafts I have been unable to > get a clear understanding of the need for and use of the Switching > Type field in the Generalized Label Request object. > > JD: The Switching Type field is for handling the situation where there > are multiple switching capabilities per interface (see section 6.4.6 of > draft-ietf-ccamp-gmpls-routing-00.txt) > > This appears to be an attempt to address LSP setup involving multiple > layer networks, but it does not adequately address the issues involved. > > JD: Would you please provide some additional prose explaining your > reasoning on this? > > That it "Indicates the type of switching that should be performed on a > particular link." makes it seem to be a local concern, while others > have indicated it is an end-to-end field. For example, George Swallow > says "It is my understanding that for a given LSP it does not change, > but is carried end-to-end and applies at all intermediate hops along > the path." > > JD: I think George's interpretation is correct, and I don't think the > other text you quoted contradicts George. If a given TE link supports > multiple switching types, the node controlling that link needs to know > what switching type a given LSP wants to use. > > As an end-to-end item I have trouble understanding how the originating node > would determine how to set this (on what basis one determines what switching > choice to make in all cases). In fact, I'm not sure why the originating > node would care what type of switching is used as long as the LSP is > delivered > to the egress faithfully. > > JD: The orgin node uses the switching capability information in the link > state > database in its CSPF calculation to ensure that switching capability is > consistent > along the path of the LSP. > > Regards, > Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 14:02:09 -0800 Message-ID: <3BE0744F.7000904@lucent.com> Date: Wed, 31 Oct 2001 16:59:43 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, > The section you mentioned, from what I can tell, is an example list > of some possible combinations of different equipment functions. I see > them as examples. But as I said, from routing perspective, it may make > sense but not signaling. What you've pointed out is the routing document... > From signaling perspective, if I removed the switching capability > field, there is nothing lost...do you agree? > > > JD: No. I will try again. What you have to demonstrate is that for all > possible combinations of switching capabilities supported on a link, an > intermediate node can deduce, from other fields in the Path message, what > switching capability is desired. > Wow...ok...so I have to list all the different combinations of different switching capabilities on each side and the possible connections and then demonstrate that what switching capability is desired can be deduced...hmmm...can't I just say that whatever the encoding type says and the sender_tspec says is what the switching type used (I'm lazy, it takes too long to run through all the combinations) > > And if I removed the switching capability field, then it opens the door > for the possibility where somewhere within my network I might change the > switching type in order to satisfy a request (because the switching type > requested is non-existent or exhausted). > > > JD: Please give an example of where substituting one value of switching > capability for another in the middle of an LSP makes sense. > Well, for example, you have a SONET network that can provide STS-48c, and it goes through an all-optical network that can provide OCh1 (2.5G service). In the SONET network it switches the STS-48c layer, while in OTN network it switches the OCh layer. This is very similar to E1/VC-12 connection, where one part of network may work PDH-based and switching E1 while another part may be SDH-based and switching VC-12, but the connection or service is essentially the same. They're not really client-server layers but similar layers from different technologies... > I think it does make sense. I think you have to assume that within > the switched transport network there will be many kinds of interfaces > connecting to the transport network. If you can't offer this capability, > then essentially what you've done is segment the transport network into > sub-networks based on what interfaces they have and only the like-type > interfaces can connect to each other. If you look at the IP world, you > might have a switch with 100 Mbps and another with 10 Mbps connected > together and talking to each other without a problem. This is capability > that is also needed, where one end could be 1 Gbps Ethernet and another > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > reason to restrict this). What really matters is that the service is > delivered. Granted there will be some inefficiencies in this, but that's > really a policy decision whether users are willing to accept this type > of connection. > > > JD: What you're describing here is PSC LSPs and they work just fine. What > you were describing in your previous example was an LSP, one end of which > was > PSC and the other end of which was TDM. And that doesn't make sense. > Maybe this is one where we need to ask individuals with operational experience and have some experience with service provisioning whether having one end with Ethernet and another end with OC-48 sounds like a configuration that makes sense? Again, the point here is that if this doesn't make sense, then essentially what you have is multiple switched networks, each serving one particular type of customer interface, i.e., a switched network for 1 Gb Ethernet, a switched network for OC-48, etc. Is this one of those "violent agreements" where we're concentrating on two different levels but saying the same thing? Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 13:20:02 -0800 Message-ID: From: John Drake To: 'Zhi-Wei Lin' Cc: 'Ben Mack-Crane' , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 13:14:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, October 31, 2001 12:54 PM To: John Drake Cc: 'Ben Mack-Crane'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Hi John, > Sorry. I thought this was akin to "obvious to the informed reader". > ;-) Just kidding. Anyway, let's give an example... > > The user has a router with OC-48 physical interface, and is capable of > requesting STS-3c or STS-12c or STS-48c services across that interface. > So now the router has three levels of switching capability within the > TDM layer (as IETF defines the TDM layer). > > Now also assume that the network as a whole can support packet > switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, > STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its > interfaces can support multiples of these types. > > However, even in this case, when the router makes a request, let's say > it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST > object, & the SENDER_TSPEC object tells you what switching to use. Thus > when the network (intermediate nodes) receives these objects, it knows > what switching to use and what signal is been received at the interface. > Therefore the switching capability doesn't tell me anything that is not > already present or not already known by the nodes (another assertion?). > > Hope this was what you were looking for... > > JD: What you give here is an example, not a design. You need to enumerate > the procedure for all possible combinations of multiple switching > capabilities. > As a start I'd suggest going through the examples in > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt, > Section 6.4.9.x. To be clear, I am not saying that it is not possible > to derive a procedure for all possible combinations. What I am saying > is that I don't know if it is possible, but I do know that specifying > switching capability works in all cases in a consistent manner. > The section you mentioned, from what I can tell, is an example list of some possible combinations of different equipment functions. I see them as examples. But as I said, from routing perspective, it may make sense but not signaling. What you've pointed out is the routing document... From signaling perspective, if I removed the switching capability field, there is nothing lost...do you agree? JD: No. I will try again. What you have to demonstrate is that for all possible combinations of switching capabilities supported on a link, an intermediate node can deduce, from other fields in the Path message, what switching capability is desired. And if I removed the switching capability field, then it opens the door for the possibility where somewhere within my network I might change the switching type in order to satisfy a request (because the switching type requested is non-existent or exhausted). JD: Please give an example of where substituting one value of switching capability for another in the middle of an LSP makes sense. > If that's the case, how would you support a non-homogenous > (heterogenous?) connection? By that I mean at the source end it is one > type of interface and at the destination end it is another type of > interface and each end cannot support the other end's switching capability. > > For example, at the source-end, the physical interface is a 1 Gb > Ethernet. At the destination-end, the physical interface is an OC-48 > interface. In this example, the switching capability at the source may > be PSC. However at the destination end the switching capability may be > TDM. The service requested is to be able to transport a "100 Mbps date > stream" from source to destination. > > > JD: The endpoints of an LSP need to have a common understanding of the > multiplexing used on that LSP, so I don't think your example makes sense. > I think it does make sense. I think you have to assume that within the switched transport network there will be many kinds of interfaces connecting to the transport network. If you can't offer this capability, then essentially what you've done is segment the transport network into sub-networks based on what interfaces they have and only the like-type interfaces can connect to each other. If you look at the IP world, you might have a switch with 100 Mbps and another with 10 Mbps connected together and talking to each other without a problem. This is capability that is also needed, where one end could be 1 Gbps Ethernet and another end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no reason to restrict this). What really matters is that the service is delivered. Granted there will be some inefficiencies in this, but that's really a policy decision whether users are willing to accept this type of connection. JD: What you're describing here is PSC LSPs and they work just fine. What you were describing in your previous example was an LSP, one end of which was PSC and the other end of which was TDM. And that doesn't make sense. > > I think for this, what is important is that the service requested can be > supported end-to-end, not the switching capability supported, nor the > signal type supported. Switching and signal type are a means to support > a service, not an end to itself. > > > JD: As far as I know, GMPLS doesn't deal with service definition. > Right. It's a tool to support these services Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 12:58:37 -0800 Message-ID: <3BE064E9.2090802@lucent.com> Date: Wed, 31 Oct 2001 15:54:01 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, > Sorry. I thought this was akin to "obvious to the informed reader". > ;-) Just kidding. Anyway, let's give an example... > > The user has a router with OC-48 physical interface, and is capable of > requesting STS-3c or STS-12c or STS-48c services across that interface. > So now the router has three levels of switching capability within the > TDM layer (as IETF defines the TDM layer). > > Now also assume that the network as a whole can support packet > switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, > STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its > interfaces can support multiples of these types. > > However, even in this case, when the router makes a request, let's say > it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST > object, & the SENDER_TSPEC object tells you what switching to use. Thus > when the network (intermediate nodes) receives these objects, it knows > what switching to use and what signal is been received at the interface. > Therefore the switching capability doesn't tell me anything that is not > already present or not already known by the nodes (another assertion?). > > Hope this was what you were looking for... > > JD: What you give here is an example, not a design. You need to enumerate > the procedure for all possible combinations of multiple switching > capabilities. > As a start I'd suggest going through the examples in > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt, > Section 6.4.9.x. To be clear, I am not saying that it is not possible > to derive a procedure for all possible combinations. What I am saying > is that I don't know if it is possible, but I do know that specifying > switching capability works in all cases in a consistent manner. > The section you mentioned, from what I can tell, is an example list of some possible combinations of different equipment functions. I see them as examples. But as I said, from routing perspective, it may make sense but not signaling. What you've pointed out is the routing document... From signaling perspective, if I removed the switching capability field, there is nothing lost...do you agree? And if I removed the switching capability field, then it opens the door for the possibility where somewhere within my network I might change the switching type in order to satisfy a request (because the switching type requested is non-existent or exhausted). > If that's the case, how would you support a non-homogenous > (heterogenous?) connection? By that I mean at the source end it is one > type of interface and at the destination end it is another type of > interface and each end cannot support the other end's switching capability. > > For example, at the source-end, the physical interface is a 1 Gb > Ethernet. At the destination-end, the physical interface is an OC-48 > interface. In this example, the switching capability at the source may > be PSC. However at the destination end the switching capability may be > TDM. The service requested is to be able to transport a "100 Mbps date > stream" from source to destination. > > > JD: The endpoints of an LSP need to have a common understanding of the > multiplexing used on that LSP, so I don't think your example makes sense. > I think it does make sense. I think you have to assume that within the switched transport network there will be many kinds of interfaces connecting to the transport network. If you can't offer this capability, then essentially what you've done is segment the transport network into sub-networks based on what interfaces they have and only the like-type interfaces can connect to each other. If you look at the IP world, you might have a switch with 100 Mbps and another with 10 Mbps connected together and talking to each other without a problem. This is capability that is also needed, where one end could be 1 Gbps Ethernet and another end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no reason to restrict this). What really matters is that the service is delivered. Granted there will be some inefficiencies in this, but that's really a policy decision whether users are willing to accept this type of connection. > > I think for this, what is important is that the service requested can be > supported end-to-end, not the switching capability supported, nor the > signal type supported. Switching and signal type are a means to support > a service, not an end to itself. > > > JD: As far as I know, GMPLS doesn't deal with service definition. > Right. It's a tool to support these services Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 12:33:01 -0800 Message-ID: From: John Drake To: 'Zhi-Wei Lin' Cc: 'Ben Mack-Crane' , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 12:30:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, October 31, 2001 10:03 AM To: John Drake Cc: 'Ben Mack-Crane'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Hi John, comments in-line. > I think I've mentioned this before, but I'll repeat myself. I think > switching capability may have be useful in identifying what is allowable > for routing purposes and for discovery purposes. > > But once those are identified, signaling does not need to get involved. > > JD: This sounds like an assertion. It would be helpful to see a detailed > proposal that describes how an intermediate node controlling a link with > multiple switching capabilities can determine what switching capability > a given LSP wishes to use. > Sorry. I thought this was akin to "obvious to the informed reader". ;-) Just kidding. Anyway, let's give an example... The user has a router with OC-48 physical interface, and is capable of requesting STS-3c or STS-12c or STS-48c services across that interface. So now the router has three levels of switching capability within the TDM layer (as IETF defines the TDM layer). Now also assume that the network as a whole can support packet switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its interfaces can support multiples of these types. However, even in this case, when the router makes a request, let's say it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST object, & the SENDER_TSPEC object tells you what switching to use. Thus when the network (intermediate nodes) receives these objects, it knows what switching to use and what signal is been received at the interface. Therefore the switching capability doesn't tell me anything that is not already present or not already known by the nodes (another assertion?). Hope this was what you were looking for... JD: What you give here is an example, not a design. You need to enumerate the procedure for all possible combinations of multiple switching capabilities. As a start I'd suggest going through the examples in http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt, Section 6.4.9.x. To be clear, I am not saying that it is not possible to derive a procedure for all possible combinations. What I am saying is that I don't know if it is possible, but I do know that specifying switching capability works in all cases in a consistent manner. > You responded to Ben that the switching capability field is end-to-end > and does not change in intermediate nodes. Is this right? > > JD: As far as I know. > If that's the case, how would you support a non-homogenous (heterogenous?) connection? By that I mean at the source end it is one type of interface and at the destination end it is another type of interface and each end cannot support the other end's switching capability. For example, at the source-end, the physical interface is a 1 Gb Ethernet. At the destination-end, the physical interface is an OC-48 interface. In this example, the switching capability at the source may be PSC. However at the destination end the switching capability may be TDM. The service requested is to be able to transport a "100 Mbps date stream" from source to destination. JD: The endpoints of an LSP need to have a common understanding of the multiplexing used on that LSP, so I don't think your example makes sense. I think for this, what is important is that the service requested can be supported end-to-end, not the switching capability supported, nor the signal type supported. Switching and signal type are a means to support a service, not an end to itself. JD: As far as I know, GMPLS doesn't deal with service definition. > Zhi > > > > John Drake wrote: > > >>Ben, >> >>I think part of the problem is that you also need to read the GMPLS >> > routing > >>drafts: >> >> >> > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > >> >>There are also comments in your text. >> >>Thanks, >> >>John >> >>-----Original Message----- >>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] >>Sent: Monday, October 29, 2001 9:53 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org >>Subject: Re: Moving right along ... Switching Type >> >> >> >>In reviewing the GMPLS signaling drafts I have been unable to >>get a clear understanding of the need for and use of the Switching >>Type field in the Generalized Label Request object. >> >> >>JD: The Switching Type field is for handling the situation where there >>are multiple switching capabilities per interface (see section 6.4.6 of >>draft-ietf-ccamp-gmpls-routing-00.txt) >> >> >>This appears to be an attempt to address LSP setup involving multiple >>layer networks, but it does not adequately address the issues involved. >> >> >>JD: Would you please provide some additional prose explaining your >>reasoning on this? >> >> >>That it "Indicates the type of switching that should be performed on a >>particular link." makes it seem to be a local concern, while others >>have indicated it is an end-to-end field. For example, George Swallow >>says "It is my understanding that for a given LSP it does not change, >>but is carried end-to-end and applies at all intermediate hops along >>the path." >> >> >>JD: I think George's interpretation is correct, and I don't think the >>other text you quoted contradicts George. If a given TE link supports >>multiple switching types, the node controlling that link needs to know >>what switching type a given LSP wants to use. >> >> >>As an end-to-end item I have trouble understanding how the originating >> > node > >>would determine how to set this (on what basis one determines what >> > switching > >>choice to make in all cases). In fact, I'm not sure why the originating >>node would care what type of switching is used as long as the LSP is >>delivered >>to the egress faithfully. >> >> >>JD: The orgin node uses the switching capability information in the link >>state >>database in its CSPF calculation to ensure that switching capability is >>consistent >>along the path of the LSP. >> >> >>Regards, >>Ben Mack-Crane >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 10:16:03 -0800 Message-ID: From: Fugui Wang To: "'ccamp@ops.ietf.org'" Subject: A question regarding draft-itef-ccamp-lmp-01.txt Date: Wed, 31 Oct 2001 13:08:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" A question regarding draft-itef-ccamp-lmp-01.txt In section 13.16 CONFIG_ERROR [page 60]: o CONFIG_ERROR, C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable CONFIG parameter 0x02 = Renegotiate CONFIG parameter 0x04 = Bad Received CCID Question: (1) In which situation should you have error code 0x04 = Bad Received CCID? Since the Config message only bring LOCAL_CCID, the only case I can imagine is that when the LOCAL_ID in Config doesn't match the lmpRemoteCcId field of the receiving node. But in this case, shouldn't we just update the lmpRemoteCcId field (learning remote CCId) instead of sending a ConfigNack with error code = 0x04? (2) For error code 0x01 and 0x02, the N bit in the Config object of ConfigNack already tells about which error it is (The previous draft use the N bit in HelloConfig TLV to handle this). Is it necessary to have an additional ERROR_CODE object in the ConfigNack? I think the ERROR_CODE is redundant to the N bit in Config object. Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 10:09:05 -0800 Message-ID: <3BE03CDB.5040900@lucent.com> Date: Wed, 31 Oct 2001 13:03:07 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, comments in-line. > I think I've mentioned this before, but I'll repeat myself. I think > switching capability may have be useful in identifying what is allowable > for routing purposes and for discovery purposes. > > But once those are identified, signaling does not need to get involved. > > JD: This sounds like an assertion. It would be helpful to see a detailed > proposal that describes how an intermediate node controlling a link with > multiple switching capabilities can determine what switching capability > a given LSP wishes to use. > Sorry. I thought this was akin to "obvious to the informed reader". ;-) Just kidding. Anyway, let's give an example... The user has a router with OC-48 physical interface, and is capable of requesting STS-3c or STS-12c or STS-48c services across that interface. So now the router has three levels of switching capability within the TDM layer (as IETF defines the TDM layer). Now also assume that the network as a whole can support packet switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its interfaces can support multiples of these types. However, even in this case, when the router makes a request, let's say it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST object, & the SENDER_TSPEC object tells you what switching to use. Thus when the network (intermediate nodes) receives these objects, it knows what switching to use and what signal is been received at the interface. Therefore the switching capability doesn't tell me anything that is not already present or not already known by the nodes (another assertion?). Hope this was what you were looking for... > You responded to Ben that the switching capability field is end-to-end > and does not change in intermediate nodes. Is this right? > > JD: As far as I know. > If that's the case, how would you support a non-homogenous (heterogenous?) connection? By that I mean at the source end it is one type of interface and at the destination end it is another type of interface and each end cannot support the other end's switching capability. For example, at the source-end, the physical interface is a 1 Gb Ethernet. At the destination-end, the physical interface is an OC-48 interface. In this example, the switching capability at the source may be PSC. However at the destination end the switching capability may be TDM. The service requested is to be able to transport a "100 Mbps date stream" from source to destination. I think for this, what is important is that the service requested can be supported end-to-end, not the switching capability supported, nor the signal type supported. Switching and signal type are a means to support a service, not an end to itself. > Zhi > > > > John Drake wrote: > > >>Ben, >> >>I think part of the problem is that you also need to read the GMPLS >> > routing > >>drafts: >> >> >> > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > >> >>There are also comments in your text. >> >>Thanks, >> >>John >> >>-----Original Message----- >>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] >>Sent: Monday, October 29, 2001 9:53 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org >>Subject: Re: Moving right along ... Switching Type >> >> >> >>In reviewing the GMPLS signaling drafts I have been unable to >>get a clear understanding of the need for and use of the Switching >>Type field in the Generalized Label Request object. >> >> >>JD: The Switching Type field is for handling the situation where there >>are multiple switching capabilities per interface (see section 6.4.6 of >>draft-ietf-ccamp-gmpls-routing-00.txt) >> >> >>This appears to be an attempt to address LSP setup involving multiple >>layer networks, but it does not adequately address the issues involved. >> >> >>JD: Would you please provide some additional prose explaining your >>reasoning on this? >> >> >>That it "Indicates the type of switching that should be performed on a >>particular link." makes it seem to be a local concern, while others >>have indicated it is an end-to-end field. For example, George Swallow >>says "It is my understanding that for a given LSP it does not change, >>but is carried end-to-end and applies at all intermediate hops along >>the path." >> >> >>JD: I think George's interpretation is correct, and I don't think the >>other text you quoted contradicts George. If a given TE link supports >>multiple switching types, the node controlling that link needs to know >>what switching type a given LSP wants to use. >> >> >>As an end-to-end item I have trouble understanding how the originating >> > node > >>would determine how to set this (on what basis one determines what >> > switching > >>choice to make in all cases). In fact, I'm not sure why the originating >>node would care what type of switching is used as long as the LSP is >>delivered >>to the egress faithfully. >> >> >>JD: The orgin node uses the switching capability information in the link >>state >>database in its CSPF calculation to ensure that switching capability is >>consistent >>along the path of the LSP. >> >> >>Regards, >>Ben Mack-Crane >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 09:01:26 -0800 Message-ID: <3BE02D66.95D2E973@alcatel.be> Date: Wed, 31 Oct 2001 17:57:10 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Zhi-Wei Lin CC: John Drake , "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------F68961D3043E70788A326320" This is a multi-part message in MIME format. --------------F68961D3043E70788A326320 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi, Consider multi-switching OTN devices having transparent OCh_CF and switching capabilities allowing optical signal regeneration if the Switching Type is set by the ingress node how can i change the switching type when the signal would need to be regenerated ? This is i think a case were more flexibility is needed moreover when these regeneration capabilities are limited over the network. However, here the switching type does not help since the regeneration decision is taken locally. Now consider a case were the ODU_CF is on top of the OCH_CF the edge-to-edge policy applies (the switching type won't change from ingress to egress) in such a case the encoding "OCh" would correspond to the switching type "lambda" same behaviour applies for ODU switching layer. Here therefore "identification" is enough and putting the the Switching type in the signalling does not need to be involved while it doesn't harm in fact - this is typically the situation with the ASON/ASTN model. However, there is a case were such capability is useful it is when having multiservice devices and several policies have to be applied at the ingress for instance use the most suitable switching capability depending on the connection request, parameters, capabilities, etc. in such a way that the local decision can be performed by the ingress when specifying the switching type. Nevertheless if i have to follow your reasoning, the TE decision can be performed at the ingress but after you don't need to identify the switching type to be used Could you then tell me how to describe the latter case ? Where i agree is that on this specific issue, more text would be really welcome,... one can not afford to use different semantic and processing for the same parameter. And does not apply to any "multiservice" case since some of them could be implicitly inferred. - dimitri. Zhi-Wei Lin wrote: > > Hi John, > > I think I've mentioned this before, but I'll repeat myself. I think > switching capability may have be useful in identifying what is allowable > for routing purposes and for discovery purposes. > > But once those are identified, signaling does not need to get involved. > You responded to Ben that the switching capability field is end-to-end > and does not change in intermediate nodes. Is this right? > > Zhi > > John Drake wrote: > > > Ben, > > > > I think part of the problem is that you also need to read the GMPLS routing > > drafts: > > > > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > > > > There are also comments in your text. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Monday, October 29, 2001 9:53 AM > > To: Kireeti Kompella > > Cc: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... Switching Type > > > > > > > > In reviewing the GMPLS signaling drafts I have been unable to > > get a clear understanding of the need for and use of the Switching > > Type field in the Generalized Label Request object. > > > > > > JD: The Switching Type field is for handling the situation where there > > are multiple switching capabilities per interface (see section 6.4.6 of > > draft-ietf-ccamp-gmpls-routing-00.txt) > > > > > > This appears to be an attempt to address LSP setup involving multiple > > layer networks, but it does not adequately address the issues involved. > > > > > > JD: Would you please provide some additional prose explaining your > > reasoning on this? > > > > > > That it "Indicates the type of switching that should be performed on a > > particular link." makes it seem to be a local concern, while others > > have indicated it is an end-to-end field. For example, George Swallow > > says "It is my understanding that for a given LSP it does not change, > > but is carried end-to-end and applies at all intermediate hops along > > the path." > > > > > > JD: I think George's interpretation is correct, and I don't think the > > other text you quoted contradicts George. If a given TE link supports > > multiple switching types, the node controlling that link needs to know > > what switching type a given LSP wants to use. > > > > > > As an end-to-end item I have trouble understanding how the originating node > > would determine how to set this (on what basis one determines what switching > > choice to make in all cases). In fact, I'm not sure why the originating > > node would care what type of switching is used as long as the LSP is > > delivered > > to the egress faithfully. > > > > > > JD: The orgin node uses the switching capability information in the link > > state > > database in its CSPF calculation to ensure that switching capability is > > consistent > > along the path of the LSP. > > > > > > Regards, > > Ben Mack-Crane > > > > --------------F68961D3043E70788A326320 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------F68961D3043E70788A326320-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 08:31:09 -0800 Message-ID: From: John Drake To: 'Zhi-Wei Lin' Cc: 'Ben Mack-Crane' , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Wed, 31 Oct 2001 08:27:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Comments in line -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, October 31, 2001 6:51 AM To: John Drake Cc: 'Ben Mack-Crane'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Hi John, I think I've mentioned this before, but I'll repeat myself. I think switching capability may have be useful in identifying what is allowable for routing purposes and for discovery purposes. But once those are identified, signaling does not need to get involved. JD: This sounds like an assertion. It would be helpful to see a detailed proposal that describes how an intermediate node controlling a link with multiple switching capabilities can determine what switching capability a given LSP wishes to use. You responded to Ben that the switching capability field is end-to-end and does not change in intermediate nodes. Is this right? JD: As far as I know. Zhi John Drake wrote: > Ben, > > I think part of the problem is that you also need to read the GMPLS routing > drafts: > > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > > There are also comments in your text. > > Thanks, > > John > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Monday, October 29, 2001 9:53 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > > > In reviewing the GMPLS signaling drafts I have been unable to > get a clear understanding of the need for and use of the Switching > Type field in the Generalized Label Request object. > > > JD: The Switching Type field is for handling the situation where there > are multiple switching capabilities per interface (see section 6.4.6 of > draft-ietf-ccamp-gmpls-routing-00.txt) > > > This appears to be an attempt to address LSP setup involving multiple > layer networks, but it does not adequately address the issues involved. > > > JD: Would you please provide some additional prose explaining your > reasoning on this? > > > That it "Indicates the type of switching that should be performed on a > particular link." makes it seem to be a local concern, while others > have indicated it is an end-to-end field. For example, George Swallow > says "It is my understanding that for a given LSP it does not change, > but is carried end-to-end and applies at all intermediate hops along > the path." > > > JD: I think George's interpretation is correct, and I don't think the > other text you quoted contradicts George. If a given TE link supports > multiple switching types, the node controlling that link needs to know > what switching type a given LSP wants to use. > > > As an end-to-end item I have trouble understanding how the originating node > would determine how to set this (on what basis one determines what switching > choice to make in all cases). In fact, I'm not sure why the originating > node would care what type of switching is used as long as the LSP is > delivered > to the egress faithfully. > > > JD: The orgin node uses the switching capability information in the link > state > database in its CSPF calculation to ensure that switching capability is > consistent > along the path of the LSP. > > > Regards, > Ben Mack-Crane > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Oct 2001 07:02:10 -0800 Message-ID: <3BE00FE3.4020905@lucent.com> Date: Wed, 31 Oct 2001 09:51:15 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, I think I've mentioned this before, but I'll repeat myself. I think switching capability may have be useful in identifying what is allowable for routing purposes and for discovery purposes. But once those are identified, signaling does not need to get involved. You responded to Ben that the switching capability field is end-to-end and does not change in intermediate nodes. Is this right? Zhi John Drake wrote: > Ben, > > I think part of the problem is that you also need to read the GMPLS routing > drafts: > > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > > There are also comments in your text. > > Thanks, > > John > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Monday, October 29, 2001 9:53 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > > > In reviewing the GMPLS signaling drafts I have been unable to > get a clear understanding of the need for and use of the Switching > Type field in the Generalized Label Request object. > > > JD: The Switching Type field is for handling the situation where there > are multiple switching capabilities per interface (see section 6.4.6 of > draft-ietf-ccamp-gmpls-routing-00.txt) > > > This appears to be an attempt to address LSP setup involving multiple > layer networks, but it does not adequately address the issues involved. > > > JD: Would you please provide some additional prose explaining your > reasoning on this? > > > That it "Indicates the type of switching that should be performed on a > particular link." makes it seem to be a local concern, while others > have indicated it is an end-to-end field. For example, George Swallow > says "It is my understanding that for a given LSP it does not change, > but is carried end-to-end and applies at all intermediate hops along > the path." > > > JD: I think George's interpretation is correct, and I don't think the > other text you quoted contradicts George. If a given TE link supports > multiple switching types, the node controlling that link needs to know > what switching type a given LSP wants to use. > > > As an end-to-end item I have trouble understanding how the originating node > would determine how to set this (on what basis one determines what switching > choice to make in all cases). In fact, I'm not sure why the originating > node would care what type of switching is used as long as the LSP is > delivered > to the egress faithfully. > > > JD: The orgin node uses the switching capability information in the link > state > database in its CSPF calculation to ensure that switching capability is > consistent > along the path of the LSP. > > > Regards, > Ben Mack-Crane > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 19:28:00 -0800 Message-Id: <200110310326.f9V3Q1001394@merlot.juniper.net> To: erosen@cisco.com cc: ccamp@ops.ietf.org Subject: Re: CCAMP WG action items MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92892.1004498761.1@juniper.net> Date: Tue, 30 Oct 2001 19:26:01 -0800 From: Yakov Rekhter Eric, > Yakov> I'd like to understand the *practical* benefits that GTTP would bring > Yakov> to the operators *above and beyond* of what is already provided by > Yakov> draft-bonica-icmp-mpls-03.txt (or could be trivially added to > Yakov> draft-bonica-icmp-mpls-03.txt). > > I think GTTP adds the following functions that are not present in > draft-bonica-icmp-mpls: > > - the ability to discover and trace through nested tunnels, even if the TTL > is not percolated through the stack; > > - the ability to trace through a nested tunnel even if interior LSRs of the > tunnel have no route to the management station. > > Do you think these functions offer practical benefits? While I may have an opinion on whether these functions offer any practical benefits, from my point of view it would be more important to get the opinion of the folks who actually use this in the operational environment. With this in mind, I'd like to hear comments from the folks *who have operational experience* with MPLS on whether the functions you mentioned above offer practical benefits. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 17:06:05 -0800 Message-ID: From: John Drake To: 'Ben Mack-Crane' , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Tue, 30 Oct 2001 17:03:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ben, I think part of the problem is that you also need to read the GMPLS routing drafts: http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt There are also comments in your text. Thanks, John -----Original Message----- From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] Sent: Monday, October 29, 2001 9:53 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type In reviewing the GMPLS signaling drafts I have been unable to get a clear understanding of the need for and use of the Switching Type field in the Generalized Label Request object. JD: The Switching Type field is for handling the situation where there are multiple switching capabilities per interface (see section 6.4.6 of draft-ietf-ccamp-gmpls-routing-00.txt) This appears to be an attempt to address LSP setup involving multiple layer networks, but it does not adequately address the issues involved. JD: Would you please provide some additional prose explaining your reasoning on this? That it "Indicates the type of switching that should be performed on a particular link." makes it seem to be a local concern, while others have indicated it is an end-to-end field. For example, George Swallow says "It is my understanding that for a given LSP it does not change, but is carried end-to-end and applies at all intermediate hops along the path." JD: I think George's interpretation is correct, and I don't think the other text you quoted contradicts George. If a given TE link supports multiple switching types, the node controlling that link needs to know what switching type a given LSP wants to use. As an end-to-end item I have trouble understanding how the originating node would determine how to set this (on what basis one determines what switching choice to make in all cases). In fact, I'm not sure why the originating node would care what type of switching is used as long as the LSP is delivered to the egress faithfully. JD: The orgin node uses the switching capability information in the link state database in its CSPF calculation to ensure that switching capability is consistent along the path of the LSP. Regards, Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 13:16:27 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34877840@zcard0ka.ca.nortel.com> From: "David Allan" To: erosen@cisco.com, Yakov Rekhter Cc: Shahram Davari , ccamp@ops.ietf.org Subject: RE: CCAMP WG action items Date: Tue, 30 Oct 2001 16:12:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16187.946AC8F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16187.946AC8F0 Content-Type: text/plain; charset="iso-8859-1" Eric: > > I think GTTP adds the following functions that are > not present in > draft-bonica-icmp-mpls: > > - the ability to discover and trace through nested tunnels, > even if the TTL > is not percolated through the stack; Seems to me that GTTP is "dependent" on TTL not percolating through the stack (a.k.a. the "Pipe" model). In the "Uniform" model GTTP requests will terminate due to TTL exhaust arbitrarily in the network, and in any sort of VPN scenario (disjoint addressing) the LSR where the exhaust occured may not have a clue about the trace originator. > > - the ability to trace through a nested tunnel even if > interior LSRs of the > tunnel have no route to the management station. By interior LSRs I presume you mean the lower level tunnels. LSRs MUST have a route to the trace originator for GTTP to provide useful information about the level under test. Dave ------_=_NextPart_001_01C16187.946AC8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CCAMP WG action items

Eric:

<snip>
>
> I  think  GTTP  adds  = the  following  functions  that  are 
> not  present  in
> draft-bonica-icmp-mpls:
>
> - the ability to discover and  trace = through nested tunnels,
> even if the TTL
>   is not percolated through the = stack;

Seems to me that GTTP is "dependent" on TTL = not percolating through the stack (a.k.a. the "Pipe" = model).

In the "Uniform" model GTTP requests will = terminate due to TTL exhaust arbitrarily in the network, and in any = sort of VPN scenario (disjoint addressing) the LSR where the exhaust = occured may not have a clue about the trace originator.


>
> - the ability to trace through a  nested = tunnel even if
> interior LSRs of the
>   tunnel have no route to the = management station.

By interior LSRs I presume you mean the lower level = tunnels. LSRs MUST have a route to the trace originator for GTTP to = provide useful information about the level under test.

Dave

------_=_NextPart_001_01C16187.946AC8F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 11:08:32 -0800 Message-Id: <200110301905.OAA28486@erosen-u10.cisco.com> To: Yakov Rekhter cc: Shahram Davari , ccamp@ops.ietf.org Subject: Re: CCAMP WG action items Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 30 Oct 2001 14:05:26 -0500 From: Eric Rosen Yakov> I'd like to understand the *practical* benefits that GTTP would bring Yakov> to the operators *above and beyond* of what is already provided by Yakov> draft-bonica-icmp-mpls-03.txt (or could be trivially added to Yakov> draft-bonica-icmp-mpls-03.txt). I think GTTP adds the following functions that are not present in draft-bonica-icmp-mpls: - the ability to discover and trace through nested tunnels, even if the TTL is not percolated through the stack; - the ability to trace through a nested tunnel even if interior LSRs of the tunnel have no route to the management station. Do you think these functions offer practical benefits? Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 11:02:35 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD348776BB@zcard0ka.ca.nortel.com> From: "David Allan" To: erosen@cisco.com, Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: CCAMP WG action items Date: Tue, 30 Oct 2001 13:56:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16174.8A3A9440" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16174.8A3A9440 Content-Type: text/plain; charset="iso-8859-1" Comment at end..... > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, October 30, 2001 12:11 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > Subject: Re: CCAMP WG action items > > > > Shahram> 4) It assumes reachability of all tunnel > ingresses and > Shahram> intermediate nodes by the tracing entity. So, > for example, all > Shahram> intermediate nodes processing GTTP have IP > connectivity to the > Shahram> tracing entity. > > Not exactly. If there is no IP connectivity to a particular > tunnel ingress, > you just can't trace through that tunnel. Many providers do > not want others > tracing through their tunnels. One could still show that > things are okay up > until the particular tunnel is reached. Eric: It's a bit more complicated than that. The tracing entity requires IP connectivity to all nodes that implement the tunnel at the particular level under test. The tunnel level under test needs to be able to carry IP. The tunnel ingress needs to silently discard all "ICMP exhausts" notifications of GTTP messages it receives (presumably by examining the forensic trail returned in the ICMP message to figure out what is GTTP). Similarly, intermediate nodes need to examine all TTL expired packets to check if they are GTTP (via finding a specific UDP port number) instead of just discarding them after generating ICMP messages. So with a lot of provisos this thing can work, but IMHO it is stretching the fabric of the original design of ICMP and TTL handling a bit far.... Dave ------_=_NextPart_001_01C16174.8A3A9440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CCAMP WG action items

Comment at end.....

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Tuesday, October 30, 2001 12:11 PM
> To: Shahram Davari
> Cc: ccamp@ops.ietf.org
> Subject: Re: CCAMP WG action items
>
>

<snip>

>
> Shahram>  4) It   = assumes   reachability  of   all   = tunnel 
> ingresses   and
> Shahram>     = intermediate nodes by the  tracing entity. So,
> for example, all
> Shahram>     = intermediate nodes processing GTTP  have IP
> connectivity to the
> Shahram>     tracing = entity.
>
> Not exactly.  If there is no IP = connectivity to a particular
> tunnel ingress,
> you just can't trace through that tunnel.  = Many providers do
> not want others
> tracing through their tunnels.  One could = still show that
> things are okay up
> until the particular tunnel is reached.

Eric:

It's a bit more complicated than that. The tracing = entity requires IP connectivity to all nodes that implement the tunnel = at the particular level under test. The tunnel level under test needs = to be able to carry IP. The tunnel ingress needs to silently discard = all "ICMP exhausts" notifications of GTTP messages it = receives (presumably by examining the forensic trail returned in the = ICMP message to figure out what is GTTP). Similarly, intermediate nodes = need to examine all TTL expired packets to check if they are GTTP (via = finding a specific UDP port number) instead of just discarding them = after generating ICMP messages.

So with a lot of provisos this thing can work, but = IMHO it is stretching the fabric of the original design of ICMP and TTL = handling a bit far....

Dave

------_=_NextPart_001_01C16174.8A3A9440-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 10:23:57 -0800 Message-ID: From: neil.2.harrison@bt.com To: erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: CCAMP WG action items Date: Tue, 30 Oct 2001 18:23:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric Rosen wrote 30 October 2001 17:11 > Shahram> Some comments regarding Bonica's GTTP draft: > > Shahram> 1) It relies on IP layer being present and IP > management-plane > Shahram> protocol (ICMPs) for the trace-probes, and > trace-response to > Shahram> trace LSPs (layer violation). > > It relies on IP? Heavens. Relying on IP is a layer violation? NH=> One should not require a higher (or indeed lower layer) technology's fault management tools to proxy for missing fault-management. Sure you can work-it for some cases, but it is a not a general solution; what about X-over-MPLS where X is not IP? Further, creating inter-layer dependancies is not good for protocol evolution (add/change/delete). Since MPLS does create new layer networks, and these will have failure modes that are not relevant to any other layer network, then for its own long-term benefit it should be given proper fault-management treatment. > > Shahram> 2) It is complicated. It requires many back and > forth messages up > Shahram> and down the protocol stack (layer violation) > and up and down > Shahram> the path to figure out the trace. > > Messages up and down the path is the tried and > true traceroute > paradigm. Don't now what "up and down the protocol stack" means. NH=> I believe Shahram means between the IP layer and the (potentially many) MPLS layer networks. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 10:20:00 -0800 Message-Id: <200110301818.f9UIIm066551@merlot.juniper.net> To: Shahram Davari cc: ccamp@ops.ietf.org Subject: Re: CCAMP WG action items MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22537.1004465928.1@juniper.net> Date: Tue, 30 Oct 2001 10:18:48 -0800 From: Yakov Rekhter Shahram, > Some comments regarding Bonica's GTTP draft: > > 1) It relies on IP layer being present and IP management-plane protocol > (ICMPs) for the trace-probes, and trace-response to trace LSPs (layer > violation). layer violation doesn't strike me as a pragmatic consideration... > 2) It is complicated. It requires many back and forth messages up and down > the protocol stack (layer violation) and up and down the path to figure > out the trace. I would agree with you that it is certainly more complex than draft-bonica-icmp-mpls-03.txt. Moreover, while draft-bonica-icmp-mpls-03.txt has been implemented by several vendors, the implementations have been shown to be interoperable, and it is being used in the operational environment for quite some time, the same can't be said for the GTTP draft. So, with this in mind I'd like to understand the *practical* benefits that GTTP would bring to the operators *above and beyond* of what is already provided by draft-bonica-icmp-mpls-03.txt (or could be trivially added to draft-bonica-icmp-mpls-03.txt). Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 09:13:31 -0800 Message-Id: <200110301711.MAA23250@erosen-u10.cisco.com> To: Shahram Davari cc: ccamp@ops.ietf.org Subject: Re: CCAMP WG action items Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 30 Oct 2001 12:11:27 -0500 From: Eric Rosen Shahram> Some comments regarding Bonica's GTTP draft: Shahram> 1) It relies on IP layer being present and IP management-plane Shahram> protocol (ICMPs) for the trace-probes, and trace-response to Shahram> trace LSPs (layer violation). It relies on IP? Heavens. Relying on IP is a layer violation? Shahram> 2) It is complicated. It requires many back and forth messages up Shahram> and down the protocol stack (layer violation) and up and down Shahram> the path to figure out the trace. Messages up and down the path is the tried and true traceroute paradigm. Don't now what "up and down the protocol stack" means. Shahram> 3) In hierarchical LSP case, not only the ingress node of the LSP Shahram> under test must run the GTTP, but all ingress LSRs that are in Shahram> the middle of the LSP under test and act as tunneling points Shahram> MUST run GTTP => forklift upgrade required I dare say that most nodes have downloadable software, and hence can be upgraded without the need to replace equipment. The point that all the ingress LSRs must support the procedure is valid. Shahram> 4) It assumes reachability of all tunnel ingresses and Shahram> intermediate nodes by the tracing entity. So, for example, all Shahram> intermediate nodes processing GTTP have IP connectivity to the Shahram> tracing entity. Not exactly. If there is no IP connectivity to a particular tunnel ingress, you just can't trace through that tunnel. Many providers do not want others tracing through their tunnels. One could still show that things are okay up until the particular tunnel is reached. Shahram> 5) Does nothing to improve operational effectiveness for operators, Shahram> ie no automatic fault detection/handling....customer complaint Shahram> still has to roll-in. It is true that this does not provide automatic fault detection. I'm not sure that that's the same as "does nothing to improve operational effectiveness". Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Oct 2001 08:23:35 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCAD5@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: ccamp@ops.ietf.org Subject: RE: CCAMP WG action items Date: Tue, 30 Oct 2001 08:23:32 -0800 MIME-Version: 1.0 Content-Type: text/plain Hi, Some comments regarding Bonica's GTTP draft: 1) It relies on IP layer being present and IP management-plane protocol (ICMPs) for the trace-probes, and trace-response to trace LSPs (layer violation). 2) It is complicated. It requires many back and forth messages up and down the protocol stack (layer violation) and up and down the path to figure out the trace. 3) In hierarchical LSP case, not only the ingress node of the LSP under test must run the GTTP, but all ingress LSRs that are in the middle of the LSP under test and act as tunneling points MUST run GTTP => forklift upgrade required 4) It assumes reachability of all tunnel ingresses and intermediate nodes by the tracing entity. So, for example, all intermediate nodes processing GTTP have IP connectivity to the tracing entity. Therefore it requires homogeneous addressing at any tunnel level. Not necessarily a good thing for inter-carrier tunnels. 5) Does nothing to improve operational effectiveness for operators, ie no automatic fault detection/handling....customer complaint still has to roll-in. Yours, -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, August 08, 2001 12:15 PM > To: ccamp@ops.ietf.org > Subject: CCAMP WG action items > > > 1) Final round of WG comments on GMPLS signalling drafts by August 27. > These include: > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-04.txt > draft-ietf-mpls-generalized-signaling-05.txt > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt > > At that point, the authors (editors) incorporate the comments, and > the documents go to IETF Last Call. > > The pieces of draft-ietf-ccamp-gmpls-sonet-sdh-01.txt that get > taken out are to be put in another draft that will be a CCAMP WG > _informational_ document. When Eric submits this draft, we'll have > a three week WG Last Call on it. > > 2) G.709: move non-ITU-standard stuff into a separate document. > > 3) Reissue routing docs as CCAMP WG docs: > draft-kompella-ospf-gmpls-extensions-02.txt > draft-many-ccamp-gmpls-routing-00.txt > > 4) For each of the following, do you think: > a. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > b. draft-fontana-ccamp-gmpls-g709-00.txt > (assuming that the non-ITU stuff is removed) > c. draft-many-ccamp-gmpls-framework-00.txt > d. draft-bonica-tunneltrace-01.txt > > should these be made CCAMP WG docs or not? > > Also, for (c), do you think that a GMPLS framework doc is useful? > > 5) Tom and co-authors to send mail to the list stating the degree > of independence of LMP MIB to the MPLS TE MIB complex. > > 6) Consensus: don't move forward with NTIP; move forward with LMP-WDM, > subject to due diligence that this work belongs in the IETF. > > 7) Once new versions of the following drafts appear, we will have WG > Last Call on them: > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > draft-ietf-ccamp-lmp-00.txt > draft-many-gmpls-architecture-01.txt > > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Oct 2001 15:09:24 -0800 Message-ID: <3BDDE03F.B1A23A91@tellabs.com> Date: Mon, 29 Oct 2001 17:03:27 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... gmpls-sonet-sdh-02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A couple of comments on draft-ietf-ccamp-gmpls-sonet-sdh-02.txt 1) Under Signal Type there are four transforms described and it is suggested that these four may be applied in the specified order. I don't think transparency makes much sense after specifying concatenation transforms. This should be clarified. 2) In the transparency section it states "Section/Regenerator Section layer transparency means that the entire frames must be delivered unmodified" and "Line/Multiplex Section layer transparency means that the LOH/MSOH must be delivered unmodified." This would seem to preclude the forms of TDM multiplexing supported by some equipment (e.g., 4xOC-48 into "OC-192"). I think we should add language that allows for this. Regards, Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Oct 2001 12:15:22 -0800 Message-ID: <3BDDB758.F3A92C2F@tellabs.com> Date: Mon, 29 Oct 2001 14:08:56 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt I have the following comments and questions: 1) In the procedures regarding the Generalized Label Request object, the statement is made that "The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching." A Tunnel (FA) is a type of link, not a class of switching. This adds to the confusion I've noted about the need for and use of Switching Type. 2) Bandwidth Encoding use of the Intserv Tspec object seems quite unusual since this use is not consistent with existing uses of this object, and new uses could easily use a new C-Type. 3) In the procedures for Generalized Label it states "If the label is unacceptable then the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication." I think "Unacceptable Label Value" would be more appropriate. 4) In the Waveband Switching section it says "For compatibility reasons, a new RSVP C-Type (3) is assigned." What is the compatability problem this is solving? 5) In the Label Set object, why is the Label Type field 14 bits if only the low order 8 bits are used? 6) Some new error strings are defined, "Label Set" and "Unsupported Link Protection," but no values or placeholders are included. Where are new error values to be documented? 7) The Notify message is intended to "enable expedited notification of failures," but it relies on the IP layer which may be affected by the failure that the Notify is reporting. This could defeat the goal of rapid notification. Without some means of guaranteeing the Notify doesn't have to wait for IP routing convergence to be delivered, it isn't a satisfactory solution. 8) The description of the C-Type field in the Label ERO subobject suggests that this subobject contains a Label Object. Is this the case, or does the Label ERO subobject simple contain label values, and the C-Type matches the C-Type that would be used if the same label values were included in a Label object? 9) In deleting an LSP from the egress, the R bit is set in the Admin Status object. The ingress responds with a PathTear message. Does this PathTear contain the Admin Status object or should the R bit be cleared? 10)The Notify message may contain a new setting of the Admin Status. Under what conditions would an intermediate or egress node change Admin Status? What happens if the Notify receiver is not the ingress? 11)In Interface Identification it says "Data channels are specified from the view point of the sender of the Path message." Is this true even for Resv messages or should it read "Data channels are specified from the viewpoint of the sender of the message."? 12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be suppressed during this waiting period." I assume this is refreshes toward the failed neighbor, not to all neighbors for that LSP. True? Regards, Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Oct 2001 10:16:41 -0800 Message-ID: <3BDD9B74.13F2602@tellabs.com> Date: Mon, 29 Oct 2001 12:09:56 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have a few comments and questions: 1) There seems to be no difference as far as label allocation is concerned between LSP Encoding Types Ethernet V2/DIX (2) and Ethernet 802.3 (10). One Encoding type would seem to be sufficient. 2) G-PID types (19), (20), and (21) are repeats of (16), (17), and (18). Since the Siganl Type will indicate whether the LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant. 3) G-PID type (37) Lambda seems insufficient (too vague) to support interoperability. Is there any practical use for this value? 4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP." For SONET/SDH this is unnecessary given the Signal Type is provided. For the other non-packet LSP types (Lambda and Fiber) it is not clear that all the values cited in the example are relevant (for example, a DS0 lambda would seem wasteful...). This is confusing, and should be clarified. In fact, a description of exactly why this field is required is needed. 5) The Waveband ID "is selected by the sender and reused in all subsequent related messages." This seems more the sort of thing that should be negotiated by LMP rather than during connection setup. 6) The definition of Start Label and End Label in waveband switching seems inconsistent with the behavior described in generalized-rsvp-te-05. 7) In Protection Information it states "The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP." This may not always be the case. An explicit flag indicating whether or not extra traffic may use the secondary path resources is needed. 8) The Administrative Status Information includes a bit indicating "Administratively down," but there is no reference to a definition of this state. Is this intended to mirror the MIB variable? If so, a reference is needed. If not, more definition is needed to ensure the local behaviors driven by this bit are in some way consistent. Whether this state defintion is consistent with current transport network operations should also be considered. 9) In Interface Identification, the IP Address for types 3,4, and 5 is described as possibly "an IP address associated with the router ID." Is this intended to mean the Router ID or any IP address owned by the node? It seems the Router ID is the simplest solution, but the wording is not clear. 10)In describing the Interface ID the statement "The special value 0xFFFFFFFF can be used to indicate the same label is to be valid across all component links." What is the "label" referred to in this case? Regards, Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Oct 2001 09:59:48 -0800 Message-ID: <3BDD9763.C6428CC@tellabs.com> Date: Mon, 29 Oct 2001 11:52:35 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In reviewing the GMPLS signaling drafts I have been unable to get a clear understanding of the need for and use of the Switching Type field in the Generalized Label Request object. This appears to be an attempt to address LSP setup involving multiple layer networks, but it does not adequately address the issues involved. That it "Indicates the type of switching that should be performed on a particular link." makes it seem to be a local concern, while others have indicated it is an end-to-end field. For example, George Swallow says "It is my understanding that for a given LSP it does not change, but is carried end-to-end and applies at all intermediate hops along the path." As an end-to-end item I have trouble understanding how the originating node would determine how to set this (on what basis one determines what switching choice to make in all cases). In fact, I'm not sure why the originating node would care what type of switching is used as long as the LSP is delivered to the egress faithfully. Regards, Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Oct 2001 08:50:10 -0800 Message-Id: <200110291641.f9TGfu092142@merlot.juniper.net> To: "Atkinson, Stephen" cc: "'ccamp@ops.ietf.org'" , "'Edward Harrison'" Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96499.1004373716.1@juniper.net> Date: Mon, 29 Oct 2001 08:41:56 -0800 From: Yakov Rekhter Steve, > Hi Ed, > > I agree, comments below. > > Regards, > steve atkinson > > > -----Original Message----- > > From: Edward Harrison [mailto:eph@dataconnection.com] > > Sent: Thursday, September 13, 2001 11:06 AM > > To: 'Yakov Rekhter' > > Cc: Nic Larkin; 'ccamp@ops.ietf.org' > > Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 > > > > > > Yakov, > > > > > > Can you clarify whether you are proposing removing the > > COMPONENT_IF_UPSTREAM > > > > TLV from the INTERFACE_ID hop object (or were you just > > saying that Steve > > > > needn't use it if he doesn't want to)? > > > > > > I am proposing to remove the COMPONENT_IF_UPSTREAM. > > > > In this case, am I right in thinking it makes sense to remove > > COMPONENT_IF_DOWNSTREAM too, and signal the (single) > > component interface > > identifier, in the IPv4, IPv6 or IF_INDEX TLV? > > This is how I felt it should work. I don't see any additional > value in COMPONENT_IF_DOWNSTREAM that can't be handled by > the IF_INDEX TLV. Both carry the same information, the > unnumbered interface identifier. I completely agree with the suggestion to remove both COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM, and use IF_INDEX TLV instead (for both bunlded and/or unnumbered links). Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Oct 2001 00:44:56 -0700 Message-ID: From: neil.2.harrison@bt.com To: jdrake@calient.net, mike.sexton@alcatel.co.uk, mvissers@lucent.com Cc: sudheer@nayna.com, ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Fri, 26 Oct 2001 08:36:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John Drake said 25 October 2001 19:01 > For example, I could very easily argue that a NSAP + > Q.2931/PNNI (signalling > aspects only) + centralised routing approach looks the best > commercially for > what we want to do. > > JD: Neil, as I have told you repeatedly in the past, GMPLS > fully supports > this mode of deployment. NH=> Thanks for clarifying that Q.2931-based/PNNI signalling is supported. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 17:10:48 -0700 Message-Id: <4.3.2.7.2.20011025201031.03eb9e18@bucket.cisco.com> Date: Thu, 25 Oct 2001 20:11:02 -0400 To: "manis@futsoft.com" From: Thomas Nadeau Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted Cc: "'Cheenu Srinivasan'" , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_126716048==_.ALT" --=====================_126716048==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >I agree with you, that the reference need not be placed >at all places.. But for the convenience of the readers, we >can have some consistency in the doc. > >Currently the reference appears at some places and >not at others.. My suggestion is, can this be made >consistent.. ie. >1) place at the first instance and leave it other places Sure, this sounds reasonable to me. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_126716048==_.ALT Content-Type: text/html; charset="us-ascii"
I agree with you, that the reference need not be placed
at all places.. But for the convenience of the readers, we
can have some consistency in the doc.

Currently the reference appears at some places and
not at others.. My suggestion is, can this be made
consistent.. ie.
1) place at the first instance and leave it other places

        Sure, this sounds reasonable to me.

        --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_126716048==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 17:04:48 -0700 Message-Id: <01C15D77.8D7793C0.manis@futsoft.com> From: "S.Manikantan" Reply-To: "manis@futsoft.com" To: "'Thomas Nadeau'" Cc: "'Cheenu Srinivasan'" , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted Date: Thu, 25 Oct 2001 17:07:38 -0700 Organization: Future Communications Software MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Tom I agree with you, that the reference need not be placed at all places.. But for the convenience of the readers, we can have some consistency in the doc. Currently the reference appears at some places and not at others.. My suggestion is, can this be made consistent.. ie. 1) place at the first instance and leave it other places 2 or place at all places Forgive me if my suggestion is stupid or If I am felt bugging :) with best regards mani -----Original Message----- From: Thomas Nadeau [SMTP:tnadeau@cisco.com] Sent: Thursday, October 25, 2001 4:49 PM To: manis@futsoft.com Cc: 'Cheenu Srinivasan'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote: >Hello Cheenu > >Yes. LSR MIB is provided as second item in section 8. > >My comment was w.r.t the cross reference. I meant > > > The MPLS-LSR-MIB describes managed objects for modeling a > >Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for >modeling a" > >reason this was the first time it is mentioned in this section. the cross >references >were used for the other MIBs in the other sections.. > >Hope I have it clear now :) > >I have two more comments. > >Comment 8 : > >In the document I noticed in some places " XXX-YY-MIB [AAMIB]" >and in some places say "XXX-YY-MIB" . > >for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places >and "MPLS-LSR-MIB" at some places. Any specific reason?? or >they will be made consistent? Lets not get carried away here. I think that if we reference one of the MIBs once, that is sufficient for someone to track down the reference. No need to put a reference every place the term is used. --Tom >Comment 9: >The [LDPMIB] reference needs to be added in section 8 references. Currently >I think it is missed out. > >with best regards >mani > > > >-----Original Message----- >From: Cheenu Srinivasan [SMTP:cheenu@alphion.com] >Sent: Thursday, October 25, 2001 11:58 AM >To: 'manis@futsoft.com' >Cc: 'mpls@uu.net'; 'ccamp@ops.ietf.org' >Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted > > > Please find below my comments on the draft. > >That was really quick! The corrections you pointed out will >show up in the next revision. One comment. > > > Comment 3: > > "4.2. MPLS-LSR-MIB > > > > The MPLS-LSR-MIB describes managed objects for modeling a > > ^^^^^^^^ > > ..." > > > > Mani>> The reference to LSRMIB needs to be added?? > >Its already there (the 2nd reference). > >Cheenu ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. << File: ATT00014.htm >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 16:50:13 -0700 Message-Id: <4.3.2.7.2.20011025194818.03fb9b60@bucket.cisco.com> Date: Thu, 25 Oct 2001 19:49:29 -0400 To: "manis@futsoft.com" From: Thomas Nadeau Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted Cc: "'Cheenu Srinivasan'" , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_125422267==_.ALT" --=====================_125422267==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote: >Hello Cheenu > >Yes. LSR MIB is provided as second item in section 8. > >My comment was w.r.t the cross reference. I meant > > > The MPLS-LSR-MIB describes managed objects for modeling a > >Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for >modeling a" > >reason this was the first time it is mentioned in this section. the cross >references >were used for the other MIBs in the other sections.. > >Hope I have it clear now :) > >I have two more comments. > >Comment 8 : > >In the document I noticed in some places " XXX-YY-MIB [AAMIB]" >and in some places say "XXX-YY-MIB" . > >for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places >and "MPLS-LSR-MIB" at some places. Any specific reason?? or >they will be made consistent? Lets not get carried away here. I think that if we reference one of the MIBs once, that is sufficient for someone to track down the reference. No need to put a reference every place the term is used. --Tom >Comment 9: >The [LDPMIB] reference needs to be added in section 8 references. Currently >I think it is missed out. > >with best regards >mani > > > >-----Original Message----- >From: Cheenu Srinivasan [SMTP:cheenu@alphion.com] >Sent: Thursday, October 25, 2001 11:58 AM >To: 'manis@futsoft.com' >Cc: 'mpls@uu.net'; 'ccamp@ops.ietf.org' >Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted > > > Please find below my comments on the draft. > >That was really quick! The corrections you pointed out will >show up in the next revision. One comment. > > > Comment 3: > > "4.2. MPLS-LSR-MIB > > > > The MPLS-LSR-MIB describes managed objects for modeling a > > ^^^^^^^^ > > ..." > > > > Mani>> The reference to LSRMIB needs to be added?? > >Its already there (the 2nd reference). > >Cheenu ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_125422267==_.ALT Content-Type: text/html; charset="us-ascii" At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:
Hello Cheenu

Yes. LSR MIB is provided as second item in section 8.

My comment was w.r.t the cross reference. I meant

>    The MPLS-LSR-MIB describes managed objects for modeling a

Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for modeling a"

reason this was the first time it is mentioned in this section. the cross references
were used for the other MIBs in the other sections..

Hope I have it clear now :)

I have two more comments.

Comment 8 :

In the document I noticed in some places " XXX-YY-MIB [AAMIB]"
and in some places say "XXX-YY-MIB" .

for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places
and "MPLS-LSR-MIB" at some places. Any specific reason?? or
they will be made consistent?

        Lets not get carried away here. I think that if we reference one
of the MIBs once, that is sufficient for someone to track down
the reference. No need to put a reference every place the
term is used.

        --Tom


Comment 9:
The [LDPMIB] reference needs to be added in section 8 references. Currently
I think it is missed out.

with best regards
mani



-----Original Message-----
From:   Cheenu Srinivasan [SMTP:cheenu@alphion.com]
Sent:   Thursday, October 25, 2001 11:58 AM
To:     'manis@futsoft.com'
Cc:     'mpls@uu.net'; 'ccamp@ops.ietf.org'
Subject:        RE: draft-ietf-mpls-mgmt-overview-00.txt posted

> Please find below my comments on the draft.

That was really quick! The corrections you pointed out will
show up in the next revision. One comment.

> Comment 3:
> "4.2.  MPLS-LSR-MIB
>   
>    The MPLS-LSR-MIB describes managed objects for modeling a
>                ^^^^^^^^
>    ..."
>
> Mani>> The reference to LSRMIB needs to be added??

Its already there (the 2nd reference).

Cheenu



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_125422267==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 13:31:04 -0700 Date: Wed, 24 Oct 2001 13:30:26 -0400 (EDT) From: Jim Boyle To: Subject: Last Call on Hierarchy and Restoration Requirements Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII FYI, this was sent to te-wg@ops.ietf.org yesterday. > The message starts a last call on the document: > > draft-ietf-tewg-restore-hierarchy-00.txt > > which outlines requirements for hierarchy and restoration in networks > utilizing CCAMP technologies such as MPLS. This document will > progress as an informational RFC. The last call ends November 9, > 2001. Please comment to te-wg@ops.ietf.org > > thanks, > > Ed & Jim Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 11:48:12 -0700 content-class: urn:content-classes:message Subject: RE: Comments on LMP MIB MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15D84.6CF27390" Date: Thu, 25 Oct 2001 14:39:48 -0400 Message-ID: Thread-Topic: Comments on LMP MIB Thread-Index: AcFdcrShnzJvjehTTLiMAOpHI9Mo+wADLcYQ From: "Martin Dubuc" To: "Baktha Muralidharan" , Cc: , , "Thomas Nadeau" , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" This is a multi-part message in MIME format. ------_=_NextPart_001_01C15D84.6CF27390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Baktha, =20 Thanks a lot for the feedback. See response below. =20 Martin -----Original Message----- From: Baktha Muralidharan [mailto:muralidb@cisco.com] Sent: Thursday, October 25, 2001 12:05 PM To: ccamp@ops.ietf.org Cc: rbradfor@cisco.com; sdatari@cisco.com; Thomas Nadeau; muralidb@cisco.com Subject: Comments on LMP MIB Hello, My feedback comments are prefixed "BM>" /Baktha =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 7.5. lmpLinkVerificationTable This table represents the link verification parameters associated with the TE links. BM> Add "Augments lmpTeLinkTable" [Martin Dubuc] OK.=20 ---------- 7.7. lmpDataBearingLinkPerfTable This table contains the objects to measure the LMP performance of data-bearing links and is an AUGMENT to the lmpDataBearingLinkTable. BM> Add "Augments lmpDataBearingLinkTable" [Martin Dubuc] OK.=20 ------------ 8. Example of LMP Control Channel Setup In this section we provide a brief example of using the MIB objects described in section 11 to set up an LMP control channel. While this example is not meant to illustrate every nuance of the MIB, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB itself. BM> Should read "objects desribed in section 10" [Martin Dubuc] OK.=20 ---------------- lmpAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired operational status of LMP on the node." DEFVAL { up } ::=3D { lmpObjects 1 } BM> Do we mean administrative state? [Martin Dubuc] No, the administraive state specifies the desired operational state. For instance, if an operator sets the administrative state of a control channel to up, it gives the system an indication that it would like the operational state to become up (desired operational state). Now it is possible that the system cannot bring the control channel up (for instance, if the fiber is cut). But as soon as it can, it will bring the control channel up. ---------------------- lmpNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the neighbor node to which control channels may be established." ::=3D { lmpObjects 2 } BM> neighbor node(s) [Martin Dubuc] OK.=20 ---------------------------- lmpNbrRetransmitInterval =3D 10 Wouldn't want this to be the same for link verification, summary etc. [Martin Dubuc] The message retransmission procedure in the latest draft seems to be a generic procedure that is not specific to the message types (as opposed to earlier versions of the drafts). This is why I have collapsed it into a single object.=20 ---------------- lmpNbrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of LMP to this remote node." ::=3D { lmpNbrEntry 3 } BM> Do we mean desired admin. state? [Martin Dubuc] Same as above.=20 -------------------- lmpCcHelloIntervalDefaultMin BM> Presumably, this serves as the default value for lmpCcHelloIntervalMin? [Martin Dubuc] Yes. I will be more specific in the MIB.=20 lmpCcHelloIntervalDefaultMax BM> Presumably, this serves as the default value for lmpCcHelloIntervalMax? [Martin Dubuc] Same as above.=20 lmpCcHelloDeadIntervalDefaultMin BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMin?=20 [Martin Dubuc] Same as above.=20 lmpCcHelloDeadIntervalDefaultMax BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMax? [Martin Dubuc] Same as above.=20 ------------------------ lmpCcHelloDeadIntervalDefault OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default HelloDeadInterval parameter to use in the Hello protocol keep-alive phase. It indicates how long a device should wait before declaring the control channel dead. The HelloDeadInterval parameter must be greater than the HelloInterval parameter and should be at least three times the value of HelloInterval." BM> Remove the part "must be greated than the HelloInterval parameter and" [Martin Dubuc] OK. ----------------- lmpCcIsIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether or not this control channel corresponds to an interface represented in the interfaces group table." ::=3D { lmpControlChannelEntry 3 } BM> Why this additional object?. Why not require that there be a valid BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into "active" state BM> and that in the absence of a valid underlying interface, the CC BM> will be in the "notReady" state? BM> BM> In the TE LInk case, we require that an entry of type "TE Link" exist BM> BEFORE the corresponding teLinkEntry is created... Why not do the same BM> with CC?. After all, the CC is not usable until a real underlying BM> interface is defined! [Martin Dubuc] This allows pre-provisioning of control channels. I guess the same logic could apply to TE links as well. Not sure what to do. =20 -------------- lmpCcNbrNodeId OBJECT-TYPE SYNTAX NodeID MAX-ACCESS read-only STATUS current DESCRIPTION "This is the Node ID of the control channel remote node. This value gets created by the node when a Config message is received or when an outgoing Config message is acknowledged by the remote node." ::=3D { lmpControlChannelEntry 4 } BM> Should NOT be a read-only. Neighbor needs to be specified. Consider BM> an out-of-band Control channel over a shared ethernet LAN interface- BM> If neighbor is not specified, how will hello config be transmitted to BM> a neighbor? BM> Only in the in-band (and with point to point link) case can the neighbor BM> IP address can be learnt! [Martin Dubuc] I could change to read-write and specify in the conformance statements that it can be read-only.=20 ----------------- lmpRemoteCcId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the remote control channel identifier. It is determined during the negotiation phase. A value of zero means that the remote control channel identifier has not yet been assigned." ::=3D { lmpControlChannelEntry 5 } BM> Should read "A value of zero means that the remote CC ID has not yet been learnt" [Martin Dubuc] OK.=20 ---------------------- lmpCcSetupRole OBJECT-TYPE SYNTAX INTEGER { active(1), passive(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The role that this node should take during establishment of this control channel. An active node will initiate establishment. A passive node will wait for the remote node to initiate. A pair of nodes that both take the passive role will never establish communications." DEFVAL { active } Well, this is not consistent with the LMP draft, which defines automatic contention resolution mechanism based on node ID. Besides, this is prone to human(operator)-error. The LMP draft reads: "To avoid ambiguities, the node with the higher Node Id wins=20 the contention; the node with the lower Node Id MUST stop=20 transmitting the Config message and respond to the Config message it=20 received." [Martin Dubuc] Yes, but the draft also allows control channels to be put in a ConfigRcv state, in which the node is waiting for acceptable configuration from the remote node. I agree that this is prone to human error, but we have to be able to support this mode. ------------------------ lmpCcAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of this control channel." ::=3D { lmpControlChannelEntry 17 } BM> Should read "desired admin state" BM> Why is the Admin Status of CC not tied to admin status of the BM> underlying interface? [Martin Dubuc] Desired operational status (see above). As for tying in admin status of CC to admin status of underlying interface, I do not believe we should tie these two. It is possible that one wants to disable a control channel, but not affect any other interfaces/applications sitting on top of the underlying interface. For instance, one may want to strictly disable LMP. --------------------- lmpTeLinkOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), degraded(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this TE link. The status is set to testing when the TE link is performing link verification. A degraded status indicates that the TE link cannot provide the provisioned protection level, but yet, there is no disruption of service. For instance, if the protection type is 1+1 and one link is down, the TE link still carries the requested amount of data traffic, but this traffic is not protected anymore." ::=3D { lmpTeLinkEntry 5 } BM> This should reflect the Finite state machine states, defined in the LMP draft, BM> for TE Links. [Martin Dubuc] I will update the description. Do you want me to remove the testing state?=20 ------------------------------ lmpDataBearingLinkEntry OBJECT-TYPE SYNTAX LmpDataBearingLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table exists for each ifEntry that represents a data-bearing link. An ifEntry with an ifIndex must exist before the corresponding lmpDataBearingLinkEntry is created. If an entry representing the data-bearing link is destroyed in the ifTable, then so is the corresponding entry in the lmpDataBearingLinkTable. The administrative status value is controlled from the ifEntry. The index to this table also used to get information in the dataBearingChannelTable [BUNDLE-MIB]." INDEX { ifIndex } BM> Why is this not an "AUGMENT" to ifEntry? [Martin Dubuc] There is no reason why it shouldn't. Can someone give me a reason why it shouldn't? ------------- BM> From an LMP perspective, the "member data links" of a TE Links need BM> to be known.. I realize that this information is available from the BM> bundling MIB.. It may be handy to add an object to the data bearing BM> link table to store the TE Link ? [Martin Dubuc] The info is actually not in the link bundling MIB, but in the ifStackTable.=20 ------------------ BM> Along the lines of TE Link and CC up/down traps, perhaps we should have BM> a trap to notify user when a data bearing link is transitioned to "down" BM> state due to link verification failure. Note that this information is not BM> obtainable from link up/down trap of underlying interface [Martin Dubuc] I will consider this in the next version.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 ------_=_NextPart_001_01C15D84.6CF27390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Baktha,
 
Thanks=20 a lot for the feedback. See response below.
 
Martin
-----Original Message-----
From: Baktha = Muralidharan=20 [mailto:muralidb@cisco.com]
Sent: Thursday, October 25, 2001 = 12:05=20 PM
To: ccamp@ops.ietf.org
Cc: rbradfor@cisco.com;=20 sdatari@cisco.com; Thomas Nadeau; = muralidb@cisco.com
Subject:=20 Comments on LMP MIB

Hello,
         = =20 My feedback comments are prefixed=20 = "BM>"

/Baktha
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

7.5. =20 lmpLinkVerificationTable

   This table represents the = link=20 verification parameters associated
   with the TE=20 links.

BM> Add "Augments lmpTeLinkTable"
[Martin=20 = Dubuc] OK. 

----------

7.7. =20 lmpDataBearingLinkPerfTable

   This table contains = the=20 objects to measure the LMP performance of
   data-bearing = links=20 and is an AUGMENT to the lmpDataBearingLinkTable.

BM> Add = "Augments=20 lmpDataBearingLinkTable"
[Martin=20 = Dubuc] OK. 

------------

8. =20 Example of LMP Control Channel Setup

   In this = section we=20 provide a brief example of using the MIB
   objects = described in=20 section 11 to set up an LMP control channel.
   While = this=20 example is not meant to illustrate every nuance of the
   = MIB, it=20 is intended as an aid to understanding some of the key
   = concepts. It is meant to be read after going through the MIB=20 itself.


BM> Should read "objects desribed in section=20 10"
[Martin=20 = Dubuc] OK. 
----------------

lmp= AdminStatus=20 OBJECT-TYPE
   = SYNTAX       =20 INTEGER { up(1), down(2) }
   = MAX-ACCESS   =20 read-write
   = STATUS       =20 current
   = DESCRIPTION
      =20 "The desired operational status of LMP on the node."
  =20 DEFVAL        { up = }
   ::=3D {=20 lmpObjects 1 }

BM> Do we mean administrative = state?

[Martin=20 Dubuc] No, the administraive state specifies the desired = operational=20 state. For instance, if an operator sets the administrative state of a = control=20 channel to up, it gives the system an indication = that it would=20 like the operational state to become up (desired operational state). = Now it is=20 possible that the system cannot bring the control channel up (for = instance, if=20 the fiber is cut). But as soon as it can, it will bring the control = channel=20 up.

----------------------

lmpNbrTable = OBJECT-TYPE
  =20 SYNTAX        SEQUENCE OF=20 LmpNbrEntry
   MAX-ACCESS   =20 not-accessible
  =20 STATUS        = current
  =20 DESCRIPTION
       "This table = specifies the=20 neighbor node to which control=20 channels
        may be=20 established."
   ::=3D { lmpObjects 2 }

BM> = neighbor=20 node(s)
[Martin=20 = Dubuc] OK. 
--------------------= --------
     =20 = lmpNbrRetransmitInterval        &= nbsp; =20 =3D 10

Wouldn't want this to be the same for link verification, = summary=20 etc.
[Martin Dubuc] The message = retransmission=20 procedure in the latest draft seems to be a generic procedure that is = not=20 specific to the message types (as opposed to earlier versions of the = drafts).=20 This is why I have collapsed it into a single=20 = object. 
----------------
lmpNbrAd= minStatus=20 OBJECT-TYPE
   = SYNTAX       =20 INTEGER { up(1), down(2) }
   = MAX-ACCESS   =20 read-create
   = STATUS       =20 current
   = DESCRIPTION
      =20 "The desired operational status of LMP to this remote = node."
  =20 ::=3D { lmpNbrEntry 3 }

BM> Do we mean desired admin. = state?
[Martin=20 Dubuc] Same as=20 = above. 
--------------------

lmpCcHel= loIntervalDefaultMin

BM>=20 Presumably, this serves as the default value for=20 lmpCcHelloIntervalMin?
[Martin Dubuc] Yes. I will be more specific in the=20 = MIB. 

lmpCcHelloIntervalDefaultMax

BM>= ;=20 Presumably, this serves as the default value for=20 lmpCcHelloIntervalMax?
[Martin Dubuc] Same as=20 = above. 

lmpCcHelloDeadIntervalDefaultMin=

BM>=20 Presumably, this serves as the default value for = lmpCcHelloDeadIntervalMin?=20
[Martin=20 Dubuc] Same as=20 = above. 

lmpCcHelloDeadIntervalDefaultMax
BM>=20 Presumably, this serves as the default value for=20 lmpCcHelloDeadIntervalMax?
[Martin = Dubuc] Same as=20 = above. 
------------------------
<= BR>lmpCcHelloDeadIntervalDefault=20 OBJECT-TYPE

  =20 SYNTAX        = LmpInterval
  =20 MAX-ACCESS    read-write
  =20 STATUS        = current
  =20 DESCRIPTION
       "This object = specifies the=20 default HelloDeadInterval parameter=20 to
        use in the Hello = protocol=20 keep-alive phase. It indicates how=20 long
        a device should = wait before=20 declaring the control channel=20 dead.
        The = HelloDeadInterval=20 parameter must be greater than=20 the
        HelloInterval = parameter and=20 should be at least three times=20 the
        value of=20 HelloInterval."

BM> Remove the part "must be greated than = the=20 HelloInterval parameter and"
[Martin = Dubuc] OK.
-----------------

lmpCcIsIf=20 OBJECT-TYPE
   = SYNTAX       =20 TruthValue
   MAX-ACCESS   =20 read-create
   = STATUS       =20 current
   = DESCRIPTION
      =20 "Denotes whether or not this control channel corresponds=20 to
        an interface = represented in=20 the interfaces group table."
   ::=3D { = lmpControlChannelEntry 3=20 }

BM> Why this additional object?. Why not require that = there be a=20 valid
BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into = "active"=20 state
BM> and that in the absence of a valid underlying = interface, the=20 CC
BM> will be in the "notReady" state?
BM>
BM> In = the TE=20 LInk case, we require that an entry of type "TE Link" exist
BM> = BEFORE=20 the corresponding teLinkEntry is created... Why not do the = same
BM> with=20 CC?. After all, the CC is not usable until a real underlying
BM> = interface is defined!

[Martin=20 Dubuc] This allows pre-provisioning of control channels. I guess = the same=20 logic could apply to TE links as well. Not sure what to=20 do.
 
--------------

lmpCcNbrNodeId=20 OBJECT-TYPE
   = SYNTAX       =20 NodeID
   MAX-ACCESS    = read-only
  =20 STATUS        = current
  =20 DESCRIPTION
       "This is the Node = ID of=20 the control channel remote = node.
       =20 This value gets created by the node when a Config=20 message
        is received or = when an=20 outgoing Config message is=20 acknowledged
        by the = remote=20 node."
   ::=3D { lmpControlChannelEntry 4 = }

BM> Should=20 NOT be a read-only. Neighbor needs to be specified. Consider
BM> = an=20 out-of-band Control channel over a shared ethernet LAN = interface-
BM> If=20 neighbor is not specified, how will hello config be transmitted = to
BM> a=20 neighbor?
BM> Only in the in-band (and with point to point link) = case=20 can the neighbor
BM> IP address can be learnt!
[Martin=20 Dubuc] I could change to read-write and specify in the = conformance=20 statements that it can be=20 = read-only. 
-----------------
lmpR= emoteCcId=20 OBJECT-TYPE
   = SYNTAX       =20 Unsigned32
   MAX-ACCESS   =20 read-only
   = STATUS       =20 current
   = DESCRIPTION
      =20 "This value represents the remote control channel identifier. It=20 is
        determined during the = negotiation phase. A = value
        of=20 zero means that the remote control channel identifier has=20 not
        yet been=20 assigned."
   ::=3D { lmpControlChannelEntry 5 = }

BM>=20 Should read "A value of zero means that the remote CC ID has not yet = been=20 learnt"

[Martin=20 = Dubuc] OK. 
--------------------= --

lmpCcSetupRole=20 OBJECT-TYPE
   = SYNTAX       =20 INTEGER { active(1), passive(2) }
   = MAX-ACCESS   =20 read-create
   = STATUS       =20 current
   = DESCRIPTION
      =20 "The role that this node should take during establishment of=20 this
        control channel. An = active=20 node will initiate establishment.=20 A
        passive node will wait = for the=20 remote node to initiate. A = pair
       =20 of nodes that both take the passive role will never=20 establish
       =20 communications."
  =20 DEFVAL        { active = }

Well, this=20 is not consistent with the LMP draft, which defines automatic=20 contention
resolution mechanism based on node ID. Besides, this is = prone to=20 human(operator)-error.

The LMP draft reads:
  "To avoid = ambiguities, the node with the higher Node Id wins
   = the=20 contention; the node with the lower Node Id MUST stop
   = transmitting the Config message and respond to the Config message it=20
   received."
[Martin = Dubuc] Yes, but the=20 draft also allows control channels to be put in a ConfigRcv = state, in=20 which the node is waiting for acceptable configuration from the remote = node. I=20 agree that this is prone to human error, but we have to be able to = support=20 this=20 = mode.
------------------------
lmpCcAdm= inStatus=20 OBJECT-TYPE
   = SYNTAX       =20 INTEGER { up(1), down(2) }
   = MAX-ACCESS   =20 read-create
   = STATUS       =20 current
   = DESCRIPTION
      =20 "The desired operational status of this control = channel."
   ::=3D=20 { lmpControlChannelEntry 17 }

BM> Should read "desired admin = state"
BM> Why is the Admin Status of CC not tied to admin = status of=20 the
BM> underlying interface?

[Martin = Dubuc] Desired=20 operational status (see above). As for tying in admin status of CC to = admin=20 status of underlying interface, I do not believe we should = tie these=20 two. It is possible that one wants to disable a control channel, but = not=20 affect any other interfaces/applications sitting on top of the = underlying=20 interface. For instance, one may want to strictly disable=20 = LMP.
---------------------
lmpTeLinkOpe= rStatus=20 OBJECT-TYPE
   = SYNTAX       =20 INTEGER { up(1), down(2), testing(3), degraded(4) }
  =20 MAX-ACCESS    read-only
  =20 STATUS        = current
  =20 DESCRIPTION
       "The actual = operational=20 status of this TE link. The=20 status
        is set to testing = when=20 the TE link is performing = link
       =20 verification. A degraded status indicates that the TE=20 link
        cannot provide the=20 provisioned protection level, but=20 yet,
        there is no = disruption of=20 service. For instance, if = the
       =20 protection type is 1+1 and one link is down, the TE=20 link
        still carries the = requested=20 amount of data traffic, = but
        this=20 traffic is not protected anymore."
   ::=3D { = lmpTeLinkEntry 5=20 }

BM> This should reflect the Finite state machine states, = defined=20 in the LMP draft,
BM> for TE Links.
[Martin=20 Dubuc] I will update the description. Do you want me to remove = the=20 testing=20 = state? 
-----------------------------= -
lmpDataBearingLinkEntry=20 OBJECT-TYPE
   = SYNTAX       =20 LmpDataBearingLinkEntry
   MAX-ACCESS   =20 not-accessible
  =20 STATUS        = current
  =20 DESCRIPTION
       "An entry in this = table=20 exists for each ifEntry that=20 represents
        a = data-bearing link.=20 An ifEntry with an ifIndex must=20 exist
        before the = corresponding=20 lmpDataBearingLinkEntry is=20 created.
        If an entry=20 representing the data-bearing link is destroyed=20 in
        the ifTable, then so = is the=20 corresponding entry in = the
       =20 lmpDataBearingLinkTable. The administrative status value=20 is
        controlled from the = ifEntry.=20 The index to this table = also
       =20 used to get information in the=20 dataBearingChannelTable
       =20 [BUNDLE-MIB]."
  =20 INDEX         { ifIndex=20 }

BM> Why is this not an "AUGMENT" to ifEntry?
[Martin=20 Dubuc] There is no reason why it shouldn't. Can = someone give=20 me a reason why it=20 shouldn't?
-------------

BM> = >From an=20 LMP perspective, the "member data links" of a TE Links need
BM> = to be=20 known.. I realize that this information is available from = the
BM>=20 bundling MIB.. It may be handy to add an object to the data = bearing
BM>=20 link table to store the TE Link ?
[Martin = Dubuc] The info is=20 actually not in the link bundling MIB, but in the=20 = ifStackTable. 
------------------
= BM>=20 Along the lines of TE Link and CC up/down traps, perhaps we should=20 have
BM> a trap to notify user when a data bearing link is = transitioned=20 to "down"
BM> state due to link verification failure. Note that = this=20 information is not
BM> obtainable from link up/down trap of = underlying=20 interface
[Martin Dubuc] I will consider this in = the next=20 = version. 
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=20
------_=_NextPart_001_01C15D84.6CF27390-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 11:47:48 -0700 Message-ID: <176689DD1922D511ABE10001022E4DF229C6D2@OPTONT> From: Cheenu Srinivasan To: "'manis@futsoft.com'" Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted Date: Thu, 25 Oct 2001 14:58:03 -0400 MIME-Version: 1.0 Content-Type: text/plain > Please find below my comments on the draft. That was really quick! The corrections you pointed out will show up in the next revision. One comment. > Comment 3: > "4.2. MPLS-LSR-MIB > > The MPLS-LSR-MIB describes managed objects for modeling a > ^^^^^^^^ > ..." > > Mani>> The reference to LSRMIB needs to be added?? Its already there (the 2nd reference). Cheenu Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 11:45:25 -0700 Message-ID: <3BD85D65.19EC848@nayna.com> Date: Thu, 25 Oct 2001 11:43:49 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: CCAMP WG , Zhi-Wei Lin Subject: 'GMPLS for ASON' discussion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi: Sorry I have to change the title of the on going discussion :-) >From the discussions we had let me summarize the "potential" issues in adopting GMPLS for ASON: 0. Operators may have to have flexibility in selecting IP control plane against other control plane. As you pointed out in one of the recent mails.. a transport network control plane should be independent of the data being carried in the data plane. GMPLS does satisfy this need, so should be other control planes. What else do we need to do to make everybody comfortable here? 1. Call Controller (aka OIF UNI using GMPLS) may need enhancements. Your conention is that this is not private UNI and the line between these enhancements and NNI is bleak. My suggestion is let us move this topic to OIF mailing list in stead of at IETF (if it is ok by you and other folks). 2. Connection controler may pose new GMPLS 'signaling' extensions for inter-domain signaling based on federation models in ASON. Can you point out the enhancements needed? This is an on going work at IETF currently using crankback mechanisms. 3. Link resource manager may pose some new requirements that are not supported by bundling and hierarchy works. Do we see any additional requirements here? 4. ASON routing control requires support of hierarchical, source-based and step-by-step models. IETF does support source-based and step-by-step models. IETF is working on hierarchical (inter-area and inter-domain) TE. Do you see any additional requirements here? 5. ASON requires standardization of interfaces between all the above components. Let us look at valid combination of these components and come up with solid requirements. 6. ASON does not vouch for a specific addressing scheme. Which leaves an option for IPv4, IPv6 and NSAP addressing formats. 7. GMPLS may be supporting more than ASON required parameters. This is due to the principles used for subnetworking by ASON model. What is the problem here? 8. Some of the text is not clear from the IETF protocol specifications. Refer to GMPLS architecture document. Is this a valid answer? Any other issues? Thank you again for the active participation. Regards, sudheer Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 11:17:07 -0700 Message-ID: From: John Drake To: "'neil.2.harrison@bt.com'" , mike.sexton@alcatel.co.uk, mvissers@lucent.com Cc: sudheer@nayna.com, ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 25 Oct 2001 11:01:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Snipped, comments in line -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Thursday, October 25, 2001 3:47 AM To: mike.sexton@alcatel.co.uk; mvissers@lucent.com Cc: sudheer@nayna.com; ccamp@ops.ietf.org Subject: RE: Moving right along ... For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling aspects only) + centralised routing approach looks the best commercially for what we want to do. JD: Neil, as I have told you repeatedly in the past, GMPLS fully supports this mode of deployment. Furthermore, at request of several operators, GMPLS includes the capability of specifying the labels (e.g. time slots) for every hop along the path of an LSP. This allows an offline centralized routing entity to globally optimize not only routes but also time slots within a network and then use GMPLS to signal them. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 11:00:03 -0700 Message-ID: <3BD85030.4020808@lucent.com> Date: Thu, 25 Oct 2001 13:47:28 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Sudheer Dharanikota CC: neil.2.harrison@bt.com, mike.sexton@alcatel.co.uk, mvissers@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, I'm not sure if you can say choose one solution. It really depends on which you're more comfortable with. In IETF, we can choose a solution based on IP. In other groups that are more inclusive of other than IP, there may be other solutions that are non-IP, but also have IP. As to your other email about private UNI (I want to combine to one email), I think you need to be careful. What exactly is private UNI that is not supported by I-NNI or E-NNI? From what I understand all these interfaces (ASON calls these reference points) allows varying of information exchange based on policy applied to them. If you're defining private UNI as one instance of NNI with specific info fixed, then I can imagine other variations that could create new interfaces. Do we want many interfaces? For example, I'm assuming that private UNI will have some ER object, and also security? How would this be different from E-NNI? One thing that I think we need to do is first see what reasons are there for creating this instead of simply creating them because there's some slight differences. Of course, we'll have some fun discussions in OIF on this in a little while...:-) Zhi Sudheer Dharanikota wrote: > Hi Neil: > > Couple of comments. > > neil.2.harrison@bt.com wrote: > > >>Hi Mike.....nice to hear from you and I think you make some good points. >>However, I want to pick-up on one aspect you bring up a few times....and >>that is 'choice'. Operators need choice to suit their views on what >>is/is-not a viable business case. >> >> > > Agreed. > > >>For example, we have various client layer networks besides IP to >>accommodate, and of particular importance are managed BW services directly >>off the L1 fabric, eg VC4 or lambdas say. However, we can't see any valid >>business case for generalised BoD/SVCs services here.....I mean, given >>unknown calling/holding statistics just what capacity would one need to >>build to to offer a GoS that customers would consider acceptable and that >>you could get past finance/products people (esp given current climate)? >> >> > > If you are assuming GMPLS is suitable for BoD/SVC services only then it > is an incorrect assumption. GMPLS is providing Connection control and > RC functions from ASON model. If that is not the assumption please ignore > this comment. > > >>So, on assumption that S-PVC-like services are all that is commercailly >>viable (in our opinion at least) then you can ask yourself just what >>additional revenues and/or Opex cost reductions are available from >>implementating a control-plane solution? Even this is difficult to justify >>given: >>- current NMS approaches (in SDH) can easily cater for current and >>foreseeable core trail churn rates; >>- the big costs are in access and laying ducts and installing >>physicals....no control-plane solution is going to impact these. >> > >>However, assuming you do decide you want to implement a control-plane >>solution in your transport networks then you really ought to be able to >>choose the addressing, signalling and routing components on a best-of-breed >>basis to suit what you want to do. They are after all, quite disjoint >>components and there are many architectural possibilities.......and this is >>what ASON is all about....choice. >> >>For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling >>aspects only) + centralised routing approach looks the best commercially for >>what we want to do. Others may argue that the current GMPLS approach suits >>them best. ASON allows this choice. >> >> > > Personal opinion: > Agreed Neil. But it also depends on how well this piece fits in the eventual > unified network control and management planes :-) We need to move one > step ahead with our development ... If we find no problems with GMPLS and > people are comfortable with IP and MPLS control planes let us move ahead > with GMPLS. It is a good idea to focus our energy on one rather than > on multiple technologies. > > Regards, > > sudheer > > >>regards, Neil >> >> >>>-----Original Message----- >>>From: mike.sexton@alcatel.co.uk [mailto:mike.sexton@alcatel.co.uk] >>>Sent: 25 October 2001 11:49 >>>To: Maarten Vissers >>>Cc: Sudheer Dharanikota; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... >>> >>> >>> >>> >>>Maarten, >>> >>>In the interests of reconciliation consider the following: >>> >>>ASON and G-MPLS are both post hoc conceptual models >>>describing the same physical and logical network. The >>>objectives of automation through signalling are broadly >>>similar. Therefore it would be surprising indeed if the >>>solutions were widely different. ASON >>>is indeed based on the layered model of G.805 and deals with >>>layering issues up-front. GMPLS is derived from the Internet >>>model which regards the physical layer as flat. When real >>>world layering is encountered it is dealt with by refinements >>>many of which >>>appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one >>>of the source documents from which G-MPLS inherits. Here LSP >>>regions are defined in 6.2 which are as near as I can tell >>>exactly equivalent to G.805 layer networks. Further, precedence rules >>>between layers are established with the clear implication >>>that a higher layer cannot be configured until the >>>appropriate resources in the lower layer have been >>>instantiated. The manner in which this may be done is >>>considered a "local matter". The example >>>given indicates that a Forwarding Adjacency (equivalent to a >>>G.805 link supported by one or more trails (LSPs) in the >>>server layer) may be initiated in various ways including from >>>an external manager or another (adjacent) LSR. Thus the >>>example you gave of >>>a VC-1x layer being set up by signalling and VC-4 layer being >>>set up by an external planning/management is certainly a >>>valid implementation within the scope of the G-MPLS solution. >>>By the same token it is undesirable (and anyway will not be >>>possible) to >>>confine signalling to certain layers while reserving others >>>for management through a standard. Operators will want to >>>make such important architectural choices on the basis of >>>optimising their own operation. Once you have agreed on a >>>signalling protocol to >>>create connections within a layer network it is generically >>>applicable to any layer network. Of course making such an >>>implementation choice (ie management for VC-4, signalling for >>>VC-1x) is an example of the "local policies" mentioned above. >>>Such choices >>>frequently appear as part of some sort of application >>>specific profile or applications framework on top of the base >>>generic standard. Note this sort of profiling (if that is the >>>correct term) is >>>generally needed to ensure interworking amongst elements >>>which implement the same generic standard. >>> >>>On the last occasion that we studied application of >>>signalling for transport networks in ITU (over 10 years ago >>>at the time G.805 was first issued) we had concluded that >>>connection set-up within a layer was the easy part ie there >>>were several well >>>established candidates to choose from (B-ISUP was the >>>favorite. Neither PNNI nor RSVP existed at that time. ISIS >>>had already been adopted for DCN in SDH and thus provided >>>basic neighbour discovery and xSPF computation if required). >>>The major new problem to >>>resolve for multi-layer transport networks was indeed >>>considered to be the desired behaviour at inter-layer >>>boundaries. It seems that both initiatives have sidelined >>>this issue as out of scope for the time being. >>> >>>regards, >>> >>>Mike Sexton >>> >>> >>> >>> >>> >>> >>> >>>Maarten Vissers on 25/10/2001 06:03:38 >>> >>> >>> >>> To: Sudheer Dharanikota >>> >>> cc: ccamp@ops.ietf.org(bcc: Michael J >>> SEXTON/GB/ALCATEL) >>> >>> >>> >>> Subject: Re: Moving right along ... >>> >>> >>> >>> >>> >>> >>>Sudheer, >>> >>>Another issue is ... >>> >>> - ASON is layer network based, GMPLS is not >>> >>>i.e. a request for a connection within ASON is treated within >>>the boundaries of >>>one layer network (e.g. within the boundaries of a >>>VT1.5/VC-11 layer network, or >>>within the boundaries of a STS-3c/VC-4 layer network). A >>>VT1.5/VC-11 connection >>>request is processed within the VT1.5/VC-11 layer network, >>>using existing >>>VT1.5/VC-11 links (GMPLS: link bundles). If there is not >>>enough capacity in the >>>VT1.5/VC-11 links to support the request, the call fails. >>>There is no "hidden" >>>set up of a STS-1 or VC-4 trail supporting an additional >>>VT/LOVC link or >>>extending an existing VT/LOVC link. The set up of an >>>additional STS-1 or VC-4 >>>trail is supported within the scope of network planning and/or network >>>engineering. This is separated from the connection set up. >>> >>>Regards, >>> >>>Maarten >>> >>>Sudheer Dharanikota wrote: >>> >>>>Hi Maarten: >>>> >>>>Maarten Vissers wrote: >>>> >>>> >>>>>Sudheer, >>>>> >>>>>At the moment I am unable to briefly summarize the >>>>> >>>differences between GMPLS and >>> >>>>>ASON. I was working from the perception that GMPLS could >>>>> >>>be one of the protocols >>> >>>>>supporting ASON. The technical comments I made during the >>>>> >>>last 10 months were >>> >>>>>based on this perception. Also the last comment >>>>> >>>describing the concept of serial >>> >>>>>compound link had this basis. Reading Yanhe's reply I had >>>>> >>>the impression that >>> >>>>>GMPLS is able to support serial compound links, but >>>>> >>>reading Eric's reply I got >>> >>>>>the opposite impression. Furthermore being very surprised >>>>> >>>by Eric's reaction on >>> >>>>>a pure technical issue, I composed a few challenging >>>>> >>>words to attrack more >>> >>>>>people to participate in the discussion... :-) >>>>> >>>>I see one of the issue here being ... >>>> >>>> - Does GMPLS support serial compound links? >>>> >>>>Let us enumerate few more questions and move the discussion >>>> >>>to a technical >>> >>>>level again, we need participation especially from the >>>> >>>folks who are involved >>> >>>>in ASON architecture work. >>>> >>>> >>>>>Being impressed by the few hundred people attending the >>>>> >>>last ccamp sessions in >>> >>>>>London, I am surprised by the low percentage of those >>>>> >>>people being actively >>> >>>>>contributing to the correspondence. It can't be the case >>>>> >>>that only a handful of >>> >>>>>people have an opinion on these matters... and I believe >>>>> >>>the discussions would >>> >>>>>stay technical if more people express their opinion... >>>>> >>>there would not be a >>> >>>>>yes/no game between just a few people. >>>>> >>>>> >>>>I thought this is how most of the standards meetings work. >>>> >>>5 % work, 95 % >>> >>>>try to gather industry intelligence ( :-) ) either by >>>> >>>attending IETF or by following >>> >>>>the mailing list. >>>> >>>> >>>>>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available >>>>> >>>it will be possible to >>> >>>>>start an evaluation of GMPLS as a specific protocol for >>>>> >>>ASON. As indicated in a >>> >>>>>previous email from Steve Trowbridge, ITU-T will make >>>>> >>>those ASON documents >>> >>>>>available to IETF so we can jointly work this evaluation. >>>>> >>>>> >>>>Most of these documents are available on the t1x1 site. But >>>> >>>what we need here is >>> >>>>the "delta" that is missing between ASON architecture and >>>> >>>the view of GMPLS >>> >>>>architecture. Can you help us with this? We may start with >>>> >>>a short list... >>> >>>>>The approval of the current ASON recommendations is just >>>>> >>>a first step within the >>> >>>>>larger ASON task. Work is started on other elements of >>>>> >>>ASON (G.rtg (routing), >>> >>>>>G.lm (link management) and pnni based specific protocol >>>>> >>>as an implementation of >>> >>>>>the protocol neutral specification in G.7713)), >>>>> >>>discussions are started >>> >>>>>identifying further ASON elements, and work to extend >>>>> >>>G.8080 is planned to start >>> >>>>>after this SG15 meeting. >>>>> >>>>> >>>>Obviously GMPLS is a potential candidate to solve the ASON >>>> >>>issues. It may be >>> >>>>ahead of its time as far as ITU and ANSI are concerned. So >>>> >>>let us ammend or >>> >>>>modify it to the ITU view on the transport control plane. >>>> >>>>Regards, >>>> >>>>sudheer >>>> >>>> >>>>>Up to so far... {time to shut down my computer and go to >>>>> >>>the concert hall in >>> >>>>>Geneva... time to relax after a week and a half of hectic >>>>> >>>work over here...} >>> >>>>>Regards, >>>>> >>>>>Maarten >>>>> >>>>>Sudheer Dharanikota wrote: >>>>> >>>>>>Hi Marteen: >>>>>> >>>>>>Can you briefly summarize the differences you see between >>>>>>GMPLS architecture and ASON architecture? This has been >>>>>>asked by many of the folks at IETF. >>>>>> >>>>>>Regards, >>>>>> >>>>>>sudheer >>>>>> >>>>>>PS: I thought these mails were about label format and suddenly >>>>>>this is turning into an ITU versus IETF discussion :-( >>>>>> > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 10:50:14 -0700 Message-Id: <4.3.2.7.2.20011025134139.03e30360@bucket.cisco.com> Date: Thu, 25 Oct 2001 13:45:09 -0400 To: "manis@futsoft.com" From: Thomas Nadeau Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted Cc: "'Cheenu Srinivasan'" , "'mpls@UU.NET'" , "'ccamp@ops.ietf.org'" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_103563196==_.ALT" --=====================_103563196==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:34 AM 10/25/2001 -0700, S.Manikantan wrote: >Hello Cheenu > >Please find below my comments on the draft. > >with best regards >mani >(S.Manikantan) > >Comment 1: >"1. Introduction > ... > Multi-Protocol Label Switching (MPLS) [MPLSArch]. > ^^^^^^^^^^ > ..." > >"2. Terminology > ... > document [MPLSArch] and various MPLS-related MIBs such as > ^^^^^^^^^^^ > ..." > >Mani>> The reference can be changed to RFC3031. Okay. >Comment 2: >"2. Terminology > ... > [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and > ^^^^^^^^^ > ..." > >Mani>> The reference to LDPMIB needs to be added to section 8 Okay. >References. > >Comment 3: >"4.2. MPLS-LSR-MIB > > The MPLS-LSR-MIB describes managed objects for modeling a > ^^^^^^^^ > ..." > >Mani>> The reference to LSRMIB needs to be added?? Yes. >Comment 4: >"4.2. MPLS-LSR-MIB > ... > MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS > ^^^^^^^ > ..." > >Mani>> Should it be MPLS-LSR-MIB for consistency? Sure. >Comment 5: >"4.3. MPLS-LDP-MIB > ... > Distribution Protocol (LDP). > ^^^^^^^ > ..." > >Mani>> Reference to RFC 3036 can be mentioned here, and RFC3036 >can be added to section 8. References. > >Comment 6: >" 4.7. PPVPN-MPLS-VPN-MIB > > The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects > ^^^^^^^^^^ > > that are used to model and manage RFC2277bis MPLS VPNs. > ^^^^^^^^^^ > ..." > >Mani>> a) Reference to VPNMIB needs to be added in Section 8 References. > b) RFC2277bis - should this be RFC2547bis?? Typo, yes. >Comment 7: >"5.2. Provider Provisioned Virtual Private Network MIBs > ... > MIBs, as this MIB is described above in section > ^^^^^^^^^^ > ..." > >Mani>> section "4.7" - needs added. Thanks for the comments. --Tom >-----Original Message----- >From: Cheenu Srinivasan [SMTP:cheenu@alphion.com] >Sent: Thursday, October 25, 2001 6:33 AM >To: 'mpls@UU.NET'; 'ccamp@ops.ietf.org' >Subject: draft-ietf-mpls-mgmt-overview-00.txt posted > >I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should >appear on the IETF site shortly. A copy of this I-D is attached. > >Cheenu > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Tuesday, October 23, 2001 4:37 PM > > Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt > > > > > > Given that many have supported the idea and none have opposed, the > > above draft is accepted as a work group draft. > > > > ...George > > << File: draft-ietf-mpls-mgmt-overview-00.txt >> ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_103563196==_.ALT Content-Type: text/html; charset="us-ascii" At 10:34 AM 10/25/2001 -0700, S.Manikantan wrote:
Hello Cheenu

Please find below my comments on the draft.

with best regards
mani
(S.Manikantan)

Comment 1:
"1. Introduction
  ...
   Multi-Protocol Label Switching (MPLS) [MPLSArch].
                                         ^^^^^^^^^^
  ..."

"2. Terminology
 ... 
   document [MPLSArch] and various MPLS-related MIBs such as
            ^^^^^^^^^^^
 ..."

Mani>> The reference can be changed to RFC3031.

        Okay.


Comment 2:
"2. Terminology
 ...
   [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and
                         ^^^^^^^^^
 ..."

Mani>> The reference to LDPMIB needs to be added to section 8

        Okay.

References.

Comment 3:
"4.2.  MPLS-LSR-MIB
  
   The MPLS-LSR-MIB describes managed objects for modeling a
               ^^^^^^^^
   ..."

Mani>> The reference to LSRMIB needs to be added??

        Yes.

Comment 4:
"4.2.  MPLS-LSR-MIB
   ...
   MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS
                                                 ^^^^^^^
   ..."

Mani>> Should it be MPLS-LSR-MIB for consistency?

        Sure.

Comment 5:
"4.3.  MPLS-LDP-MIB
   ...
   Distribution Protocol (LDP).
                        ^^^^^^^
   ..."

Mani>> Reference to RFC 3036 can be mentioned here, and RFC3036
can be added to section 8. References.

Comment 6:
" 4.7.  PPVPN-MPLS-VPN-MIB
  
   The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects
                        ^^^^^^^^^^

   that are used to model and manage RFC2277bis MPLS VPNs.
                                     ^^^^^^^^^^
   ..."

Mani>> a) Reference to VPNMIB needs to be added in Section 8 References.
       b) RFC2277bis - should this be RFC2547bis??

        Typo, yes.

Comment 7:
"5.2.  Provider Provisioned Virtual Private Network MIBs
  ...
   MIBs, as this MIB is described above in section
                                            ^^^^^^^^^^
  ..."

Mani>> section "4.7" - needs added.

        Thanks for the comments.

        --Tom




-----Original Message-----
From:   Cheenu Srinivasan [SMTP:cheenu@alphion.com]
Sent:   Thursday, October 25, 2001 6:33 AM
To:     'mpls@UU.NET'; 'ccamp@ops.ietf.org'
Subject:        draft-ietf-mpls-mgmt-overview-00.txt posted

I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should
appear on the IETF site shortly. A copy of this I-D is attached.

Cheenu

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, October 23, 2001 4:37 PM
> Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
>
>
> Given that many have supported the idea and none have opposed, the
> above draft is accepted as a work group draft.
>
> ...George

 << File: draft-ietf-mpls-mgmt-overview-00.txt >>



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_103563196==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 10:25:57 -0700 Message-Id: <4.3.2.7.2.20011025130533.03e60c40@bucket.cisco.com> Date: Thu, 25 Oct 2001 13:13:52 -0400 To: Baktha Muralidharan From: Thomas Nadeau Subject: Re: Comments on LMP MIB Cc: ccamp@ops.ietf.org, rbradfor@cisco.com, sdatari@cisco.com, muralidb@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_101685586==_.ALT" --=====================_101685586==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Comments inline. All editorial comments look good. > My feedback comments are prefixed "BM>" > >/Baktha >====================================================== > >7.5. lmpLinkVerificationTable > > This table represents the link verification parameters associated > with the TE links. > >BM> Add "Augments lmpTeLinkTable" > >---------- > >7.7. lmpDataBearingLinkPerfTable > > This table contains the objects to measure the LMP performance of > data-bearing links and is an AUGMENT to the lmpDataBearingLinkTable. > >BM> Add "Augments lmpDataBearingLinkTable" > >------------ > >8. Example of LMP Control Channel Setup > > In this section we provide a brief example of using the MIB > objects described in section 11 to set up an LMP control channel. > While this example is not meant to illustrate every nuance of the > MIB, it is intended as an aid to understanding some of the key > concepts. It is meant to be read after going through the MIB itself. > > >BM> Should read "objects desribed in section 10" >---------------- > >lmpAdminStatus OBJECT-TYPE > SYNTAX INTEGER { up(1), down(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The desired operational status of LMP on the node." > DEFVAL { up } > ::= { lmpObjects 1 } > >BM> Do we mean administrative state? > >---------------------- > >lmpNbrTable OBJECT-TYPE > SYNTAX SEQUENCE OF LmpNbrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table specifies the neighbor node to which control channels > may be established." > ::= { lmpObjects 2 } > >BM> neighbor node(s) >---------------------------- > lmpNbrRetransmitInterval = 10 > >Wouldn't want this to be the same for link verification, summary etc. >---------------- >lmpNbrAdminStatus OBJECT-TYPE > SYNTAX INTEGER { up(1), down(2) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The desired operational status of LMP to this remote node." > ::= { lmpNbrEntry 3 } > >BM> Do we mean desired admin. state? >-------------------- > >lmpCcHelloIntervalDefaultMin > >BM> Presumably, this serves as the default value for lmpCcHelloIntervalMin? > >lmpCcHelloIntervalDefaultMax > >BM> Presumably, this serves as the default value for lmpCcHelloIntervalMax? > >lmpCcHelloDeadIntervalDefaultMin > >BM> Presumably, this serves as the default value for >lmpCcHelloDeadIntervalMin? > >lmpCcHelloDeadIntervalDefaultMax > >BM> Presumably, this serves as the default value for >lmpCcHelloDeadIntervalMax? >------------------------ > >lmpCcHelloDeadIntervalDefault OBJECT-TYPE > > SYNTAX LmpInterval > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object specifies the default HelloDeadInterval parameter to > use in the Hello protocol keep-alive phase. It indicates how long > a device should wait before declaring the control channel dead. > The HelloDeadInterval parameter must be greater than the > HelloInterval parameter and should be at least three times the > value of HelloInterval." > >BM> Remove the part "must be greated than the HelloInterval parameter and" >----------------- > >lmpCcIsIf OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Denotes whether or not this control channel corresponds to > an interface represented in the interfaces group table." > ::= { lmpControlChannelEntry 3 } > >BM> Why this additional object?. Why not require that there be a valid >BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into "active" state >BM> and that in the absence of a valid underlying interface, the CC >BM> will be in the "notReady" state? I think that these are two different issues. This variable indicates that this CC has its own ifIndex. You can configure your CC as an IfIndex. If you relied on the underlying ifIndex to be present, then you run the risk of its ifIndex constantly changing. That is okay if your implementation wants this behavior, but if you want to configure a fixed ifIndex, this allows for it. >BM> >BM> In the TE LInk case, we require that an entry of type "TE Link" exist >BM> BEFORE the corresponding teLinkEntry is created... Why not do the same >BM> with CC?. After all, the CC is not usable until a real underlying >BM> interface is defined! Right, but what if you just want to configure it and enable it later? It is noted that the CC cannot become active until its associated underlying interface is active. >---------------- > >lmpCcNbrNodeId OBJECT-TYPE > SYNTAX NodeID > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is the Node ID of the control channel remote node. > This value gets created by the node when a Config message > is received or when an outgoing Config message is acknowledged > by the remote node." > ::= { lmpControlChannelEntry 4 } > >BM> Should NOT be a read-only. Neighbor needs to be specified. Consider >BM> an out-of-band Control channel over a shared ethernet LAN interface- >BM> If neighbor is not specified, how will hello config be transmitted to >BM> a neighbor? >BM> Only in the in-band (and with point to point link) case can the neighbor >BM> IP address can be learnt! Okay. >----------------- >lmpRemoteCcId OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This value represents the remote control channel identifier. It is > determined during the negotiation phase. A value > of zero means that the remote control channel identifier has not > yet been assigned." > ::= { lmpControlChannelEntry 5 } > >BM> Should read "A value of zero means that the remote CC ID has not yet >been learnt" > >---------------------- > >lmpCcSetupRole OBJECT-TYPE > SYNTAX INTEGER { active(1), passive(2) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The role that this node should take during establishment of this > control channel. An active node will initiate establishment. A > passive node will wait for the remote node to initiate. A pair > of nodes that both take the passive role will never establish > communications." > DEFVAL { active } > >Well, this is not consistent with the LMP draft, which defines automatic >contention >resolution mechanism based on node ID. Besides, this is prone to >human(operator)-error. > >The LMP draft reads: > "To avoid ambiguities, the node with the higher Node Id wins > the contention; the node with the lower Node Id MUST stop > transmitting the Config message and respond to the Config message it > received." The text needs to be updated. >------------------------ >lmpCcAdminStatus OBJECT-TYPE > SYNTAX INTEGER { up(1), down(2) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The desired operational status of this control channel." > ::= { lmpControlChannelEntry 17 } > >BM> Should read "desired admin state" >BM> Why is the Admin Status of CC not tied to admin status of the >BM> underlying interface? > >--------------------- >lmpTeLinkOperStatus OBJECT-TYPE > SYNTAX INTEGER { up(1), down(2), testing(3), degraded(4) } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The actual operational status of this TE link. The status > is set to testing when the TE link is performing link > verification. A degraded status indicates that the TE link > cannot provide the provisioned protection level, but yet, > there is no disruption of service. For instance, if the > protection type is 1+1 and one link is down, the TE link > still carries the requested amount of data traffic, but > this traffic is not protected anymore." > ::= { lmpTeLinkEntry 5 } > >BM> This should reflect the Finite state machine states, defined in the >LMP draft, >BM> for TE Links. Is that necessary, or is the above subset sufficient? >------------------------------ >lmpDataBearingLinkEntry OBJECT-TYPE > SYNTAX LmpDataBearingLinkEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table exists for each ifEntry that represents > a data-bearing link. An ifEntry with an ifIndex must exist > before the corresponding lmpDataBearingLinkEntry is created. > If an entry representing the data-bearing link is destroyed in > the ifTable, then so is the corresponding entry in the > lmpDataBearingLinkTable. The administrative status value is > controlled from the ifEntry. The index to this table also > used to get information in the dataBearingChannelTable > [BUNDLE-MIB]." > INDEX { ifIndex } > >BM> Why is this not an "AUGMENT" to ifEntry? Because it would violate the stipulation that AUGMENTS entries cannot be associated with the base table in a sparse relationship. >------------- > >BM> From an LMP perspective, the "member data links" of a TE Links need >BM> to be known.. I realize that this information is available from the >BM> bundling MIB.. It may be handy to add an object to the data bearing >BM> link table to store the TE Link ? Isn't this shown through the underlying ifIndex? >------------------ >BM> Along the lines of TE Link and CC up/down traps, perhaps we should have >BM> a trap to notify user when a data bearing link is transitioned to "down" >BM> state due to link verification failure. Note that this information is not >BM> obtainable from link up/down trap of underlying interface >=========================================== This sounds useful. I think that we can add this. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_101685586==_.ALT Content-Type: text/html; charset="us-ascii"
        Comments inline.  All editorial comments
look good.

          My feedback comments are prefixed "BM>"

/Baktha
======================================================

7.5.  lmpLinkVerificationTable

   This table represents the link verification parameters associated
   with the TE links.

BM> Add "Augments lmpTeLinkTable"

----------

7.7.  lmpDataBearingLinkPerfTable

   This table contains the objects to measure the LMP performance of
   data-bearing links and is an AUGMENT to the lmpDataBearingLinkTable.

BM> Add "Augments lmpDataBearingLinkTable"

------------

8.  Example of LMP Control Channel Setup

   In this section we provide a brief example of using the MIB
   objects described in section 11 to set up an LMP control channel.
   While this example is not meant to illustrate every nuance of the
   MIB, it is intended as an aid to understanding some of the key
   concepts. It is meant to be read after going through the MIB itself.


BM> Should read "objects desribed in section 10"
----------------

lmpAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2) }
   MAX-ACCESS    read-write
   STATUS        current
   DESCRIPTION
       "The desired operational status of LMP on the node."
   DEFVAL        { up }
   ::= { lmpObjects 1 }

BM> Do we mean administrative state?

----------------------

lmpNbrTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF LmpNbrEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "This table specifies the neighbor node to which control channels
        may be established."
   ::= { lmpObjects 2 }

BM> neighbor node(s)
----------------------------
      lmpNbrRetransmitInterval           = 10

Wouldn't want this to be the same for link verification, summary etc.
----------------
lmpNbrAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The desired operational status of LMP to this remote node."
   ::= { lmpNbrEntry 3 }

BM> Do we mean desired admin. state?
--------------------

lmpCcHelloIntervalDefaultMin

BM> Presumably, this serves as the default value for lmpCcHelloIntervalMin?

lmpCcHelloIntervalDefaultMax

BM> Presumably, this serves as the default value for lmpCcHelloIntervalMax?

lmpCcHelloDeadIntervalDefaultMin

BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMin?

lmpCcHelloDeadIntervalDefaultMax

BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMax?
------------------------

lmpCcHelloDeadIntervalDefault OBJECT-TYPE

   SYNTAX        LmpInterval
   MAX-ACCESS    read-write
   STATUS        current
   DESCRIPTION
       "This object specifies the default HelloDeadInterval parameter to
        use in the Hello protocol keep-alive phase. It indicates how long
        a device should wait before declaring the control channel dead.
        The HelloDeadInterval parameter must be greater than the
        HelloInterval parameter and should be at least three times the
        value of HelloInterval."

BM> Remove the part "must be greated than the HelloInterval parameter and"
-----------------

lmpCcIsIf OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Denotes whether or not this control channel corresponds to
        an interface represented in the interfaces group table."
   ::= { lmpControlChannelEntry 3 }

BM> Why this additional object?. Why not require that there be a valid
BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into "active" state
BM> and that in the absence of a valid underlying interface, the CC
BM> will be in the "notReady" state?

        I think that these are two different issues. This variable indicates that this CC has its
own ifIndex. You can configure your CC as an IfIndex. If you relied on the underlying
ifIndex to be present, then you run the risk of its ifIndex constantly changing. That is
okay if your implementation wants this behavior, but if you want to configure
a fixed ifIndex, this allows for it.

BM>
BM> In the TE LInk case, we require that an entry of type "TE Link" exist
BM> BEFORE the corresponding teLinkEntry is created... Why not do the same
BM> with CC?. After all, the CC is not usable until a real underlying
BM> interface is defined!

        Right, but what if you just want to configure it and enable it later? It is
noted that the CC cannot become active until its associated underlying interface
is active.

----------------

lmpCcNbrNodeId OBJECT-TYPE
   SYNTAX        NodeID
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This is the Node ID of the control channel remote node.
        This value gets created by the node when a Config message
        is received or when an outgoing Config message is acknowledged
        by the remote node."
   ::= { lmpControlChannelEntry 4 }

BM> Should NOT be a read-only. Neighbor needs to be specified. Consider
BM> an out-of-band Control channel over a shared ethernet LAN interface-
BM> If neighbor is not specified, how will hello config be transmitted to
BM> a neighbor?
BM> Only in the in-band (and with point to point link) case can the neighbor
BM> IP address can be learnt!

        Okay.

-----------------
lmpRemoteCcId OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This value represents the remote control channel identifier. It is
        determined during the negotiation phase. A value
        of zero means that the remote control channel identifier has not
        yet been assigned."
   ::= { lmpControlChannelEntry 5 }

BM> Should read "A value of zero means that the remote CC ID has not yet been learnt"

----------------------

lmpCcSetupRole OBJECT-TYPE
   SYNTAX        INTEGER { active(1), passive(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The role that this node should take during establishment of this
        control channel. An active node will initiate establishment. A
        passive node will wait for the remote node to initiate. A pair
        of nodes that both take the passive role will never establish
        communications."
   DEFVAL        { active }

Well, this is not consistent with the LMP draft, which defines automatic contention
resolution mechanism based on node ID. Besides, this is prone to human(operator)-error.

The LMP draft reads:
  "To avoid ambiguities, the node with the higher Node Id wins
   the contention; the node with the lower Node Id MUST stop
   transmitting the Config message and respond to the Config message it
   received."

        The text needs to be updated.


------------------------
lmpCcAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The desired operational status of this control channel."
   ::= { lmpControlChannelEntry 17 }

BM> Should read "desired admin state"
BM> Why is the Admin Status of CC not tied to admin status of the
BM> underlying interface?

---------------------
lmpTeLinkOperStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2), testing(3), degraded(4) }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "The actual operational status of this TE link. The status
        is set to testing when the TE link is performing link
        verification. A degraded status indicates that the TE link
        cannot provide the provisioned protection level, but yet,
        there is no disruption of service. For instance, if the
        protection type is 1+1 and one link is down, the TE link
        still carries the requested amount of data traffic, but
        this traffic is not protected anymore."
   ::= { lmpTeLinkEntry 5 }

BM> This should reflect the Finite state machine states, defined in the LMP draft,
BM> for TE Links.

        Is that necessary, or is the above subset sufficient?

------------------------------
lmpDataBearingLinkEntry OBJECT-TYPE
   SYNTAX        LmpDataBearingLinkEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "An entry in this table exists for each ifEntry that represents
        a data-bearing link. An ifEntry with an ifIndex must exist
        before the corresponding lmpDataBearingLinkEntry is created.
        If an entry representing the data-bearing link is destroyed in
        the ifTable, then so is the corresponding entry in the
        lmpDataBearingLinkTable. The administrative status value is
        controlled from the ifEntry. The index to this table also
        used to get information in the dataBearingChannelTable
        [BUNDLE-MIB]."
   INDEX         { ifIndex }

BM> Why is this not an "AUGMENT" to ifEntry?

        Because it would violate the stipulation that AUGMENTS entries
cannot be associated with the base table in a sparse relationship.

-------------

BM> From an LMP perspective, the "member data links" of a TE Links need
BM> to be known.. I realize that this information is available from the
BM> bundling MIB.. It may be handy to add an object to the data bearing
BM> link table to store the TE Link ?

        Isn't this shown through the underlying ifIndex?

------------------
BM> Along the lines of TE Link and CC up/down traps, perhaps we should have
BM> a trap to notify user when a data bearing link is transitioned to "down"
BM> state due to link verification failure. Note that this information is not
BM> obtainable from link up/down trap of underlying interface
===========================================

        This sounds useful. I think that we can add this.

        --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_101685586==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 10:23:17 -0700 Message-ID: <3BD847B0.3376D26E@nayna.com> Date: Thu, 25 Oct 2001 10:11:12 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: mike.sexton@alcatel.co.uk, mvissers@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Neil: Couple of comments. neil.2.harrison@bt.com wrote: > Hi Mike.....nice to hear from you and I think you make some good points. > However, I want to pick-up on one aspect you bring up a few times....and > that is 'choice'. Operators need choice to suit their views on what > is/is-not a viable business case. > Agreed. > > For example, we have various client layer networks besides IP to > accommodate, and of particular importance are managed BW services directly > off the L1 fabric, eg VC4 or lambdas say. However, we can't see any valid > business case for generalised BoD/SVCs services here.....I mean, given > unknown calling/holding statistics just what capacity would one need to > build to to offer a GoS that customers would consider acceptable and that > you could get past finance/products people (esp given current climate)? > If you are assuming GMPLS is suitable for BoD/SVC services only then it is an incorrect assumption. GMPLS is providing Connection control and RC functions from ASON model. If that is not the assumption please ignore this comment. > > So, on assumption that S-PVC-like services are all that is commercailly > viable (in our opinion at least) then you can ask yourself just what > additional revenues and/or Opex cost reductions are available from > implementating a control-plane solution? Even this is difficult to justify > given: > - current NMS approaches (in SDH) can easily cater for current and > foreseeable core trail churn rates; > - the big costs are in access and laying ducts and installing > physicals....no control-plane solution is going to impact these. > > However, assuming you do decide you want to implement a control-plane > solution in your transport networks then you really ought to be able to > choose the addressing, signalling and routing components on a best-of-breed > basis to suit what you want to do. They are after all, quite disjoint > components and there are many architectural possibilities.......and this is > what ASON is all about....choice. > > For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling > aspects only) + centralised routing approach looks the best commercially for > what we want to do. Others may argue that the current GMPLS approach suits > them best. ASON allows this choice. > Personal opinion: Agreed Neil. But it also depends on how well this piece fits in the eventual unified network control and management planes :-) We need to move one step ahead with our development ... If we find no problems with GMPLS and people are comfortable with IP and MPLS control planes let us move ahead with GMPLS. It is a good idea to focus our energy on one rather than on multiple technologies. Regards, sudheer > > regards, Neil > > > -----Original Message----- > > From: mike.sexton@alcatel.co.uk [mailto:mike.sexton@alcatel.co.uk] > > Sent: 25 October 2001 11:49 > > To: Maarten Vissers > > Cc: Sudheer Dharanikota; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... > > > > > > > > > > Maarten, > > > > In the interests of reconciliation consider the following: > > > > ASON and G-MPLS are both post hoc conceptual models > > describing the same physical and logical network. The > > objectives of automation through signalling are broadly > > similar. Therefore it would be surprising indeed if the > > solutions were widely different. ASON > > is indeed based on the layered model of G.805 and deals with > > layering issues up-front. GMPLS is derived from the Internet > > model which regards the physical layer as flat. When real > > world layering is encountered it is dealt with by refinements > > many of which > > appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one > > of the source documents from which G-MPLS inherits. Here LSP > > regions are defined in 6.2 which are as near as I can tell > > exactly equivalent to G.805 layer networks. Further, precedence rules > > between layers are established with the clear implication > > that a higher layer cannot be configured until the > > appropriate resources in the lower layer have been > > instantiated. The manner in which this may be done is > > considered a "local matter". The example > > given indicates that a Forwarding Adjacency (equivalent to a > > G.805 link supported by one or more trails (LSPs) in the > > server layer) may be initiated in various ways including from > > an external manager or another (adjacent) LSR. Thus the > > example you gave of > > a VC-1x layer being set up by signalling and VC-4 layer being > > set up by an external planning/management is certainly a > > valid implementation within the scope of the G-MPLS solution. > > By the same token it is undesirable (and anyway will not be > > possible) to > > confine signalling to certain layers while reserving others > > for management through a standard. Operators will want to > > make such important architectural choices on the basis of > > optimising their own operation. Once you have agreed on a > > signalling protocol to > > create connections within a layer network it is generically > > applicable to any layer network. Of course making such an > > implementation choice (ie management for VC-4, signalling for > > VC-1x) is an example of the "local policies" mentioned above. > > Such choices > > frequently appear as part of some sort of application > > specific profile or applications framework on top of the base > > generic standard. Note this sort of profiling (if that is the > > correct term) is > > generally needed to ensure interworking amongst elements > > which implement the same generic standard. > > > > On the last occasion that we studied application of > > signalling for transport networks in ITU (over 10 years ago > > at the time G.805 was first issued) we had concluded that > > connection set-up within a layer was the easy part ie there > > were several well > > established candidates to choose from (B-ISUP was the > > favorite. Neither PNNI nor RSVP existed at that time. ISIS > > had already been adopted for DCN in SDH and thus provided > > basic neighbour discovery and xSPF computation if required). > > The major new problem to > > resolve for multi-layer transport networks was indeed > > considered to be the desired behaviour at inter-layer > > boundaries. It seems that both initiatives have sidelined > > this issue as out of scope for the time being. > > > > regards, > > > > Mike Sexton > > > > > > > > > > > > > > > > Maarten Vissers on 25/10/2001 06:03:38 > > > > > > > > To: Sudheer Dharanikota > > > > cc: ccamp@ops.ietf.org(bcc: Michael J > > SEXTON/GB/ALCATEL) > > > > > > > > Subject: Re: Moving right along ... > > > > > > > > > > > > > > Sudheer, > > > > Another issue is ... > > > > - ASON is layer network based, GMPLS is not > > > > i.e. a request for a connection within ASON is treated within > > the boundaries of > > one layer network (e.g. within the boundaries of a > > VT1.5/VC-11 layer network, or > > within the boundaries of a STS-3c/VC-4 layer network). A > > VT1.5/VC-11 connection > > request is processed within the VT1.5/VC-11 layer network, > > using existing > > VT1.5/VC-11 links (GMPLS: link bundles). If there is not > > enough capacity in the > > VT1.5/VC-11 links to support the request, the call fails. > > There is no "hidden" > > set up of a STS-1 or VC-4 trail supporting an additional > > VT/LOVC link or > > extending an existing VT/LOVC link. The set up of an > > additional STS-1 or VC-4 > > trail is supported within the scope of network planning and/or network > > engineering. This is separated from the connection set up. > > > > Regards, > > > > Maarten > > > > Sudheer Dharanikota wrote: > > > > > > Hi Maarten: > > > > > > Maarten Vissers wrote: > > > > > > > Sudheer, > > > > > > > > At the moment I am unable to briefly summarize the > > differences between GMPLS and > > > > ASON. I was working from the perception that GMPLS could > > be one of the protocols > > > > supporting ASON. The technical comments I made during the > > last 10 months were > > > > based on this perception. Also the last comment > > describing the concept of serial > > > > compound link had this basis. Reading Yanhe's reply I had > > the impression that > > > > GMPLS is able to support serial compound links, but > > reading Eric's reply I got > > > > the opposite impression. Furthermore being very surprised > > by Eric's reaction on > > > > a pure technical issue, I composed a few challenging > > words to attrack more > > > > people to participate in the discussion... :-) > > > > > > I see one of the issue here being ... > > > > > > - Does GMPLS support serial compound links? > > > > > > Let us enumerate few more questions and move the discussion > > to a technical > > > level again, we need participation especially from the > > folks who are involved > > > in ASON architecture work. > > > > > > > > > > > Being impressed by the few hundred people attending the > > last ccamp sessions in > > > > London, I am surprised by the low percentage of those > > people being actively > > > > contributing to the correspondence. It can't be the case > > that only a handful of > > > > people have an opinion on these matters... and I believe > > the discussions would > > > > stay technical if more people express their opinion... > > there would not be a > > > > yes/no game between just a few people. > > > > > > > > > > I thought this is how most of the standards meetings work. > > 5 % work, 95 % > > > try to gather industry intelligence ( :-) ) either by > > attending IETF or by following > > > > > > the mailing list. > > > > > > > > > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available > > it will be possible to > > > > start an evaluation of GMPLS as a specific protocol for > > ASON. As indicated in a > > > > previous email from Steve Trowbridge, ITU-T will make > > those ASON documents > > > > available to IETF so we can jointly work this evaluation. > > > > > > > > > > Most of these documents are available on the t1x1 site. But > > what we need here is > > > the "delta" that is missing between ASON architecture and > > the view of GMPLS > > > architecture. Can you help us with this? We may start with > > a short list... > > > > > > > > > > > The approval of the current ASON recommendations is just > > a first step within the > > > > larger ASON task. Work is started on other elements of > > ASON (G.rtg (routing), > > > > G.lm (link management) and pnni based specific protocol > > as an implementation of > > > > the protocol neutral specification in G.7713)), > > discussions are started > > > > identifying further ASON elements, and work to extend > > G.8080 is planned to start > > > > after this SG15 meeting. > > > > > > > > > > Obviously GMPLS is a potential candidate to solve the ASON > > issues. It may be > > > ahead of its time as far as ITU and ANSI are concerned. So > > let us ammend or > > > modify it to the ITU view on the transport control plane. > > > > > > Regards, > > > > > > sudheer > > > > > > > > > > > Up to so far... {time to shut down my computer and go to > > the concert hall in > > > > Geneva... time to relax after a week and a half of hectic > > work over here...} > > > > > > > > Regards, > > > > > > > > Maarten > > > > > > > > Sudheer Dharanikota wrote: > > > > > > > > > > Hi Marteen: > > > > > > > > > > Can you briefly summarize the differences you see between > > > > > GMPLS architecture and ASON architecture? This has been > > > > > asked by many of the folks at IETF. > > > > > > > > > > Regards, > > > > > > > > > > sudheer > > > > > > > > > > PS: I thought these mails were about label format and suddenly > > > > > this is turning into an ITU versus IETF discussion :-( > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 09:55:29 -0700 Message-ID: <3BD841FC.9C7D29B7@nayna.com> Date: Thu, 25 Oct 2001 09:46:52 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Zhi-Wei Lin CC: Maarten Vissers , ccamp@ops.ietf.org, q12/15 , q14/15 Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi: Zhi-Wei Lin wrote: > Hi Sudheer, I tried answering some of your questions in another email, > so I will put some short answers to this email...below... > > > > Let us enumerate few more questions and move the discussion to a technical > > level again, we need participation especially from the folks who are involved > > in ASON architecture work. > > > > > > This is where I keep suggesting that we put in clarifying text. I > showed an example a few emails back about "A-B-C" configuration where B > is not GMPLS aware. I want to bring out the point that the text in GMPLS > is not clear about whether or not this is supported. > > I believe GMPLS can support serial compound links, but we need to > describe in the text properly (or more clearly) so that people are aware > of this, instead of simply saying that "it is obvious to the informed > reader". I think our goal should be to make it as readable as possible > to the larger audience, not just a few people who has followed the > mailing list. I keep getting reminded of how specific BGP documents are > and how much information on BGP is actually not specified anywhere that > is actually needed in order for it to work properly...this seems a > little "elitist" to me...please don't flame me...:-) > > People have been working on GMPLS for a while. Some of us are catching up and some are deep down in it. Hence for some this is magic and for others this is trivial. Let us be considerate to both. Now there is an architecture document, which tries to capture most of the GMPLS approach. Please refer to this document for 'some' of the answers. > > > >>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to > >>start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a > >>previous email from Steve Trowbridge, ITU-T will make those ASON documents > >>available to IETF so we can jointly work this evaluation. > >> > >> > > > > Most of these documents are available on the t1x1 site. But what we need here is > > the "delta" that is missing between ASON architecture and the view of GMPLS > > architecture. Can you help us with this? We may start with a short list... > > > > > > Well, let's see, I don't think anybody as really gone through the > details of it yet. I would be very interested if anybody out there have > done this already > Well.. I am one of them who is interested and am looking at this. Same would be the case for many of us the vendors who will benifit from this work. > > >>The approval of the current ASON recommendations is just a first step within the > >>larger ASON task. Work is started on other elements of ASON (G.rtg (routing), > >>G.lm (link management) and pnni based specific protocol as an implementation of > >>the protocol neutral specification in G.7713)), discussions are started > >>identifying further ASON elements, and work to extend G.8080 is planned to start > >>after this SG15 meeting. > >> > >> > > > > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be > > ahead of its time as far as ITU and ANSI are concerned. So let us ammend or > > modify it to the ITU view on the transport control plane. > > > > I agree GMPLS is definitely a candidate. That is why I don't > understand some people's mentality of "ITU against/versus IETF". I think > they are complementary. The architecture experts are in ITU (at least > some experts) and the protocol experts are in IETF (again, at least some > experts). In terms of ahead of its times...don't know about > that...depends on your timeframe...1 month? 1 year? 10 years? 1 week? :-) > > The goal is to keep it as tight timeframe as possible. This is certainly the motto of IETF also. But we should be forward thinking too :-) So let us see if GMPLS is meeting ASON requirements. Please refer to my other mail in response to your summry. Regards, sudheer > > > Regards, > > > > sudheer > > > > > >>Up to so far... {time to shut down my computer and go to the concert hall in > >>Geneva... time to relax after a week and a half of hectic work over here...} > >> > >>Regards, > >> > >>Maarten > >> > >>Sudheer Dharanikota wrote: > >> > >>>Hi Marteen: > >>> > >>>Can you briefly summarize the differences you see between > >>>GMPLS architecture and ASON architecture? This has been > >>>asked by many of the folks at IETF. > >>> > >>>Regards, > >>> > >>>sudheer > >>> > >>>PS: I thought these mails were about label format and suddenly > >>>this is turning into an ITU versus IETF discussion :-( > >>> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 09:37:31 -0700 Message-ID: <3BD83EC9.7E59BC61@nayna.com> Date: Thu, 25 Oct 2001 09:33:14 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Zhi-Wei Lin CC: Irfan Lateef , kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi: Thank you for taking time in writing this informative mail. Few of my opinions and questions are inline... Please let me know if I am wrong with any of the assumptions. For those who are interested in ASON architecture refer to http://http://www.t1.org/filemgr/FileList.taf?Directory=t1x1%5Cx1.5&ShowTitle=New%20T1X1.5%20Files Of course, the version on this site is old . But this may be good enough to start some technical discussion. Hopefully ITU will provide an updated version soon for IETF public. Zhi-Wei Lin wrote: > Hi Sudheer, > > OK I'll try to highlight some. I think Maarten mentioned one already: > -- ASON is based on a separation of layer network. > > Not only that, ASON is also based on separation of functional roles of > the switched network. ASON defines the architecture of the switched > network in terms of the interactions of different components. Components > defined by ASON performs specific tasks: > Agreed on ITU/ANSI approach to define ASON. To compare ASON requiremetns with what GMPLS provides, we need to see if all these components are present in what is supported by GMPLS. I would assume this is not an issue if GMPLS has all the components defined by ASON (G.808 V0.8.2). > --Call controller (CallC) is the "service" component that interfaces > with the user to support service requests. I believe this can be viewed > as been handled by the OIF UNI specification, which provides the user to > network request capability Well then - this is not an issue. Because OIF UNI is already using GMPLS extensions to support CallC functions. There are plans to enhance OIF UNI to what ever functions that are missing either using Private UNI or others. Of course we can always discuss this on OIF mailing lists and at the meetings. > > --Connection controller (CC) is the network component that supports the > connection operations, which includes setup and release of individual > links (ITU: link connections) in support of the user request. A set of > connection controllers are involved on a sub-network (area of AS) basis > to set up/release connections within its domain of responsibility, and > interacts with other CC in different ways depending on how the operator > configures the interactions. Methods of interaction include a joint > federation model and a cooperative federation model. CC is I think what > GMPLS is about, in terms of setting up and releasing/tearing down > connections. Agreed that CC is what GMPLS 'signaling' is all about. Currently (untill inter-area TE model is finalized) IETF is working with one area. GMPLS does not assume how to and where to expand loose segments of a path. So a CC can be placed anywhere in an area. This path computation can be in an NE or outside NE. So, in my opinion, this model supports both joint and co-operative federation models. of course, it has to have all the primitives to manage a connection. Let me know if I missed any particular scenario. > --Link resource manager (LRM) is the network component that assigns a link > (ITU: link connection) from a link bundle/TE-link (ITU: link). Thus the > progression of signaling goes from CC which receives requests for > connections to LRM which chooses a link, and provides the CC with the > requested link information so that CC can set up a sub-network > connection (a connection across a sub-network). Note that sub-network > connection "concept" is a recursive definition where the limit of > recursion of a sub-network connection is the fabric connection. The LRM > from GMPLS perspective is subsumed into the CC (this is where the label > negotiation takes place). I may not be catching all the issues here. I know what you mean by sub-network connections (SNPs) and their recursive nature. But why do you think this is not supported by current bundling and hierarchy concepts at IETF? > --Routing controller (RC) is the network component that provides the > routing information, including route dissemination, route determination, > route table update, etc. Three models of routing has been defined: > hierarchical, source-based and step-by-step. As part of the routing > definition, a "routing area" is defined to support > multi-level/hierarchical routing domains. This is very similar (maybe > identical?) to the OSPF/BGP separation of roles. > Agreed that RC is GMPLS 'routing' component. As you know step-by-step and source-based are supported currently by IETF. Some work is going on on hierarchical (inter-area, SRG etc.). Hope we cover all the cases needed for the hierarchical requirements here. > > NOTE that these are all logical components (what ITU calls a > computational view of the control plane), with certain distribution > assumed (what ITU calls an engineering view of the control plane). > Different implementations of these components may have, e.g., CallC, CC > and LRM all in one "box" while another implementation may have CallC in > one box and CC, LRM and RC in another box. However, the functionality is > equivalant. Only difference is in terms of which interfaces have been > exposed and becomes external (that is standardizable). > I see. Why don't we concentrate on this topic and discuss what are the possible combinations and advantages? Coming from the router world I belive these should be internal to increase the efficiency of operation. > > Now to how different or similar is ASON/G.dcm with GMPLS. In terms of > the information mapping and message mapping between them, I would say > they are very close to each other. For example, when ASON/G.dcm > discusses setup/release operations, it views the transport resources as > an "abstract" entity called SNP (subnetwork point). If you are familiar > with management objects, the SNP is very similar to SNTP (subnetwork > termination point). Where SNTP provides the management system with a > view of the underlying transport resources (CTP or TTP or simply TP), > the SNP provides the control plane with a view of the underlying > transport resources. As such these SNP and SNPP (SNP pools which is an > aggregation of the SNPs into a logical "bundle" based on some policy or > provisioned constraints) is used in setting up a connection. The > SNP/SNPP provides an abstraction barrier between physical resources and > logical resources and is provided on a layer basis (i.e., SNP ID > information for a STS-1 layer is independent of the SNP ID information > for a STS-3c layer is independent of the SNP ID information for a ODU1 > layer). > Agreed with the concepts. It was tough to read CCITT documents in 1990 and it is tough to read ITU documents now :-) (pun intended). They are very formal documents and cover all the cases. But this is not an issue for a discussion I hope. > The other difference is that ASON/G.dcm deals with abstract "names" in > terms of specifying relevant endpoints. This is simply a "protocol > neutral" aspect of addresses used in GMPLS, where GMPLS assumes IPv4 and > IPv6, G.dcm does not assume any addressing scheme. This is not > inconsistent, only different levels of specification. One of the "names" > defined in ASON/G.dcm is a "call name" which is a reference to the call. > IETF GMPLS I believe "sort-of" supports this. Call name is essentially a > globally unique identifier that identifies the call. IETF GMPLS also > provides a globally unique identifier in the form of SESSION and > SENDER_TEMPLATE (for RSVP-TE). > My opinion on addresseing: IETF may be interested in IPv4 or IPv6 address space for reasons that it can control the allocation and there was no need to use other address space. It is a good idea from the deplyoment point of view also. Please do not crusify me for this. With your observations on call naming support in GMPLS... naming is not an issue with GMPLS. > > There are also capabilities described in GMPLS that is currently not > specified by the ASON/G.dcm. This includes the capabilities supported by > the Admin_Status object (turning on/off monitoring), and the multiplier > parameter within the SONET/SDH SENDER_TSPEC/FLOWSPEC object. For > example, many of the parameters that support the SONET/SDH connection > (such as what signal type, encoding type, NCC, NVC) are implied > information in ASON/G.dcm since they are layer information. These > parameters in GMPLS may be thought of as an implementation of the layer > information for the specific protocol. > So are you are saying is GMPLS has more than required? This cannot be a drawback in the worst case :-) A comment on the additional parameters... you are assuming that a layer boundary is a domain boundary and there is no need to calculate a TE path through these boundaries. Is this a valid assumption? > > GMPLS RSVP-TE is a soft-state protocol, CR-LDP is more a hard-state > protocol. ASON/G.dcm does not specify whether the protocol needs to be > soft-state or hard-state. It discusses what are the behaviours and how > these "systems" may recover from problems. It also provides a high-level > state transition diagram on the operation of the signaling mechanism. > From this viewpoint, I also don't see too much inconsistency. Of > course, I haven't done any analysis/comparison. If anyone is interested > doing this it let me know! > So this is also a non-issue. > > The first stage of the ITU specification for the ASON work is nearing > completion. The next stage is to start work on the protocol specific > implementations of the ASON model. At the current ITU meeting, we > already have United Kingdom (presented by British Telecom) bring in > contribution requesting to use PNNI as A protocol for supporting ASON. > This was also supported by other carriers. The ITU has now opened the > floor to any other protocols to be submitted as well. > > So if people want to see GMPLS considered as one of the protocols for > ASON, someone needs to submit this to the ITU. Currently the decision is > that if any protocols meets the requirements outlined in ASON and G.dcm, > then they will be considered (i.e., any protocol). There were some > interest shown in the meeting to bringing in GMPLS. > Well GMPLS is satisfying most of the ASON requirements. Why not this is a potential candiadate for submission at ITU? May be the WG chairs have a plan on how to proceed. > > Well, I hope this provides enough of a summary to help the discussions > along. > Thank you for the summary Zhi. Please contribute to this mail thread to narrow down the issues. Regards, sudheer > > Zhi > > Sudheer Dharanikota wrote: > > > Hi Zhi: > > > > Zhi-Wei Lin wrote: > > > > > >> From what I understand G.ason and G.dcm is developed to describe the > >>process and the minimal requirements needed to support a basic switched > >>transport service. GMPLS is a protocol specific implementation that will > >>likely meet many of the requirements, and may have some minor areas that > >>it does not meet. Then the question to ask (as with any requirements and > >>architecture work -- I'm sure we all have architects in our company) is: > >>how critical are the requirements that may not be met and what changes > >>are needed to GMPLS (if any) in order to meet them? > >> > >> > > > > It may be a good idea to explain where GMPLS is lacking in meeting ASON > > and DCM requirements. YOu, being involved in this process, is the best > > person to articulate the major drawbacks. WHy don't you spend a minute in > > higlighting them. > > > > THese discussions are becoming highly non-technical and unproductive. Let us > > streamline our energy to a common cause - find the enhancements needed to > > accomodate ASON architecture. > > > > Regards, > > > > sudheer > > > > > >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 09:23:25 -0700 From: mike.sexton@alcatel.co.uk To: Zhi-Wei Lin cc: Maarten Vissers , Sudheer Dharanikota , ccamp@ops.ietf.org Message-ID: <80256AF0.0057CF96.00@gbmta001.netfr.alcatel.fr> Date: Thu, 25 Oct 2001 17:59:06 +0100 Subject: Re: Moving right along ... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Zhi, I am a little reticent to deepen this discussion on the list. It is difficult to avoid appearing like prevaricating philosophers. I can almost hear those CCAMP guys yawning from here. Please feel free to press delete if this is not for you. See discussion in line. regards, Mike Sexton Zhi-Wei Lin on 25/10/2001 12:04:19 To: Michael J SEXTON/GB/ALCATEL@ALCATEL cc: Maarten Vissers , Sudheer Dharanikota , ccamp@ops.ietf.org Subject: Re: Moving right along ... Hi Mike, I agree with most of what you said. I think the forwarding adjacency is more similar to the serial composed link connections (or serial compound links) than to support from a trail. There is no requirement for forwarding adjacencies to relate to trails (at least I don't think so). MS: Not exactly so but I'd rather pass this one up for now as it may get us in even deeper. And yes, I fully agree that the inter-layer piece is the interesting piece. I believe Maarten has presented this in several places as the network engineering function (what you called the "local matter") as subject to policy control (very operator business model dependent). MS: I did not follow this thread very closely but my understanding was that Maarten was essentially dividing what IETF call traffic engineering into two sub-domains: network engineering choosing optimum paths within a layer (LSP region) and traffic engineering - assigning traffic selectively to one or more alternative paths available at the point the traffic is applied. At a layer boundary this implies some sort of daemon capable of making assignment decisions which may in turn be dependent on policies implemented locally or impressed remotely. Is this in line with your interpretation. As for the hierarchy and the layer model, I think the hierarchical model of MPLS is more atuned to the sub-network partition (and sub-network recursion) which is within a layer. I'm not sure that the hierarchy was defined for layer network (although I don't see why it can't apply either). MS: In G.805 the layer network hierarchical relationship is n:n, client:server (ie a network layer can be served by one or more servers and may in turn support one or more clients. This implies a precedence: client connections can only be provided in the context of a server (logical) topology. The server topology is generated by the connections created between the edges of the server and so on ad infinitum. This is exactly the recursive relationship described rather more tersely in draft-ietf-mpls-lsp-hierarchy-03.txt para 6.2. The partitioning relationship between partitioning "levels" (we normally try and avoid overusing the term layer in this context) is 1:n, superior:subordinate. The most superior subnetwork includes (contains) 1 to n subnetworks; each of these in turn includes 1 to n subnetworks and so on recursively until the subordinate subnetwork coincides exactly with a single node (matrix, forwarding engine etc) at which point the recursion efrfectively terminates. In both GMPLS and G.805 partitioning is considered essentially an administrative activity and local policies are again cited. In practice there are externally imposed limits imposed on administrative choice (eg it is difficult to justify creating a subnetwork which ignores the self selected boundaries imposed by protected subnetworks (eg rings)). Similarly routing domain boundaries must be honoured. Having clarified that (I hope) it must be noted that subnetworks at any level map onto 1 or more server "layer networks". For example a subnetwork partition of an MPLS layer (eg PSC3) may be partially supported over VC-4/PoS (TSC) and partially over WDM (LSC). These are indeed subnetworks in VC-4 and WDM layers respectively and may be offering transit services for other adjacent subnetworks in the same layers. However of particular interest here is that they are also layer network segments containing all the points at which interlayer services are offered to this particular client. These are all the points where multiplexing choices are made, traffic is offered (or rejected) in short all the issues currently in the realm of local policy with no standard support for bringing this under control. This was the main point I was making. There is nothing about the layered model which proscribes interlayer control interfaces and connection control planes in multiple layers which was a possible inference from Maarten's note. I am not sure precisely whether ASON has limited its scope in this manner but if so I suppose this can be seen in the context of prioritising and phasing results as G-MPLS has also limited scope rather than an interdictory prosciption. For completeness I should add one further comment. Although the ID referred to above and G-MPLS in general leaves the interlayer issue open as covered by "local implementation" there is a strong suggestion of a default behaviour in which a new server FA-LSP is opened (request to the server) if there are no further link resources available for the recommended next hop and that further more this LSP is routed along the shortest path indicated by the IGP which is subsequently used until it in turn exhausts. This exploits the unique property of shortest path trees in distributed route computation which also works across layer boundaries. Now in terms of the layer model itself, I think (as I said many times) that the problem is mainly in how people interpret the text in these documents. That is why (my little rambling again) I think we need to add text to clarify some of these concepts...people don't seem to want to add clarifying text though...sigh... Zhi mike.sexton@alcatel.co.uk wrote: > > Maarten, > > In the interests of reconciliation consider the following: > > ASON and G-MPLS are both post hoc conceptual models describing the > same physical and logical network. The objectives of automation > through signalling are broadly similar. Therefore it would be > surprising indeed if the solutions were widely different. ASON is > indeed based on the layered model of G.805 and deals with layering > issues up-front. GMPLS is derived from the Internet model which > regards the physical layer as flat. When real world layering is > encountered it is dealt with by refinements many of which appear in > draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source > documents from which G-MPLS inherits. Here LSP regions are defined > in 6.2 which are as near as I can tell exactly equivalent to G.805 > layer networks. Further, precedence rules between layers are > established with the clear implication that a higher layer cannot > be configured until the appropriate resources in the lower layer > have been instantiated. The manner in which this may be done is > considered a "local matter". The example given indicates that a > Forwarding Adjacency (equivalent to a G.805 link supported by one > or more trails (LSPs) in the server layer) may be initiated in > various ways including from an external manager or another > (adjacent) LSR. Thus the example you gave of a VC-1x layer being > set up by signalling and VC-4 layer being set up by an external > planning/management is certainly a valid implementation within the > scope of the G-MPLS solution. By the same token it is undesirable > (and anyway will not be possible) to confine signalling to certain > layers while reserving others for management through a standard. > Operators will want to make such important architectural choices on > the basis of optimising their own operation. Once you have agreed > on a signalling protocol to create connections within a layer > network it is generically applicable to any layer network. Of > course making such an implementation choice (ie management for > VC-4, signalling for VC-1x) is an example of the "local policies" > mentioned above. Such choices frequently appear as part of some > sort of application specific profile or applications framework on > top of the base generic standard. Note this sort of profiling (if > that is the correct term) is generally needed to ensure > interworking amongst elements which implement the same generic > standard. > > On the last occasion that we studied application of signalling for > transport networks in ITU (over 10 years ago at the time G.805 was > first issued) we had concluded that connection set-up within a > layer was the easy part ie there were several well established > candidates to choose from (B-ISUP was the favorite. Neither PNNI > nor RSVP existed at that time. ISIS had already been adopted for > DCN in SDH and thus provided basic neighbour discovery and xSPF > computation if required). The major new problem to resolve for > multi-layer transport networks was indeed considered to be the > desired behaviour at inter-layer boundaries. It seems that both > initiatives have sidelined this issue as out of scope for the time > being. > > regards, > > Mike Sexton > > > > > > > > Maarten Vissers on 25/10/2001 06:03:38 > > > > To: Sudheer Dharanikota > > cc: ccamp@ops.ietf.org(bcc: Michael J SEXTON/GB/ALCATEL) > > > > > Subject: Re: Moving right along ... > > > > > > > Sudheer, > > Another issue is ... > > - ASON is layer network based, GMPLS is not > > i.e. a request for a connection within ASON is treated within the > boundaries of one layer network (e.g. within the boundaries of a > VT1.5/VC-11 layer network, or within the boundaries of a > STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is > processed within the VT1.5/VC-11 layer network, using existing VT1.5/VC-11 > links (GMPLS: link bundles). If there is not enough capacity in > the VT1.5/VC-11 links to support the request, the call fails. There > is no "hidden" set up of a STS-1 or VC-4 trail supporting an > additional VT/LOVC link or extending an existing VT/LOVC link. The > set up of an additional STS-1 or VC-4 trail is supported within the > scope of network planning and/or network engineering. This is > separated from the connection set up. > > Regards, > > Maarten > > Sudheer Dharanikota wrote: > >> Hi Maarten: >> >> Maarten Vissers wrote: >> >> >>> Sudheer, >>> >>> At the moment I am unable to briefly summarize the differences >>> between GMPLS and ASON. I was working from the perception that >>> GMPLS could be one of the protocols supporting ASON. The >>> technical comments I made during the last 10 months were based >>> on this perception. Also the last comment describing the >>> concept of serial compound link had this basis. Reading Yanhe's >>> reply I had the impression that GMPLS is able to support >>> serial compound links, but reading Eric's reply I got the >>> opposite impression. Furthermore being very surprised by Eric's >>> reaction on a pure technical issue, I composed a few >>> challenging words to attrack more people to participate in the >>> discussion... :-) >>> >> I see one of the issue here being ... >> >> - Does GMPLS support serial compound links? >> >> Let us enumerate few more questions and move the discussion to a >> technical level again, we need participation especially from the >> folks who are involved in ASON architecture work. >> >> >>> Being impressed by the few hundred people attending the last >>> ccamp sessions in London, I am surprised by the low percentage >>> of those people being actively contributing to the >>> correspondence. It can't be the case that only a handful of people >>> have an opinion on these matters... and I believe the >>> discussions would stay technical if more people express their >>> opinion... there would not be a yes/no game between just a few >>> people. >>> >>> >> I thought this is how most of the standards meetings work. 5 % >> work, 95 % try to gather industry intelligence ( :-) ) either by >> attending IETF or by following >> >> the mailing list. >> >> >>> With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it >>> will be possible to start an evaluation of GMPLS as a specific >>> protocol for ASON. As indicated in a previous email from Steve >>> Trowbridge, ITU-T will make those ASON documents available to >>> IETF so we can jointly work this evaluation. >>> >>> >> Most of these documents are available on the t1x1 site. But what >> we need here is the "delta" that is missing between ASON >> architecture and the view of GMPLS architecture. Can you help us >> with this? We may start with a short list... >> >> >>> The approval of the current ASON recommendations is just a first >>> step within the larger ASON task. Work is started on other >>> elements of ASON (G.rtg (routing), G.lm (link management) and >>> pnni based specific protocol as an implementation of the >>> protocol neutral specification in G.7713)), discussions are >>> started identifying further ASON elements, and work to extend >>> G.8080 is planned to start after this SG15 meeting. >>> >>> >> Obviously GMPLS is a potential candidate to solve the ASON issues. >> It may be ahead of its time as far as ITU and ANSI are >> concerned. So let us ammend or modify it to the ITU view on the >> transport control plane. >> >> Regards, >> >> sudheer >> >> >>> Up to so far... {time to shut down my computer and go to the >>> concert hall in Geneva... time to relax after a week and a half >>> of hectic work over here...} >>> >>> Regards, >>> >>> Maarten >>> >>> Sudheer Dharanikota wrote: >>> >>>> Hi Marteen: >>>> >>>> Can you briefly summarize the differences you see between GMPLS >>>> architecture and ASON architecture? This has been asked by >>>> many of the folks at IETF. >>>> >>>> Regards, >>>> >>>> sudheer >>>> >>>> PS: I thought these mails were about label format and suddenly this >>>> is turning into an ITU versus IETF discussion :-( >>>> >>>> Part 1.1 >>>> >>>> Content-Type: >>>> >>>> text/plain >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> mvissers.vcf >>>> >>>> Content-Type: >>>> >>>> application/octet-stream Content-Encoding: >>>> >>>> base64 >>>> >>>> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 09:12:16 -0700 Message-Id: <4.3.2.7.2.20011025120255.01853980@funnel.cisco.com> Date: Thu, 25 Oct 2001 12:05:17 -0400 To: ccamp@ops.ietf.org From: Baktha Muralidharan Subject: Comments on LMP MIB Cc: rbradfor@cisco.com, sdatari@cisco.com, Thomas Nadeau , muralidb@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9978528==_.ALT" --=====================_9978528==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, My feedback comments are prefixed "BM>" /Baktha ====================================================== 7.5. lmpLinkVerificationTable This table represents the link verification parameters associated with the TE links. BM> Add "Augments lmpTeLinkTable" ---------- 7.7. lmpDataBearingLinkPerfTable This table contains the objects to measure the LMP performance of data-bearing links and is an AUGMENT to the lmpDataBearingLinkTable. BM> Add "Augments lmpDataBearingLinkTable" ------------ 8. Example of LMP Control Channel Setup In this section we provide a brief example of using the MIB objects described in section 11 to set up an LMP control channel. While this example is not meant to illustrate every nuance of the MIB, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB itself. BM> Should read "objects desribed in section 10" ---------------- lmpAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired operational status of LMP on the node." DEFVAL { up } ::= { lmpObjects 1 } BM> Do we mean administrative state? ---------------------- lmpNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the neighbor node to which control channels may be established." ::= { lmpObjects 2 } BM> neighbor node(s) ---------------------------- lmpNbrRetransmitInterval = 10 Wouldn't want this to be the same for link verification, summary etc. ---------------- lmpNbrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of LMP to this remote node." ::= { lmpNbrEntry 3 } BM> Do we mean desired admin. state? -------------------- lmpCcHelloIntervalDefaultMin BM> Presumably, this serves as the default value for lmpCcHelloIntervalMin? lmpCcHelloIntervalDefaultMax BM> Presumably, this serves as the default value for lmpCcHelloIntervalMax? lmpCcHelloDeadIntervalDefaultMin BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMin? lmpCcHelloDeadIntervalDefaultMax BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMax? ------------------------ lmpCcHelloDeadIntervalDefault OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default HelloDeadInterval parameter to use in the Hello protocol keep-alive phase. It indicates how long a device should wait before declaring the control channel dead. The HelloDeadInterval parameter must be greater than the HelloInterval parameter and should be at least three times the value of HelloInterval." BM> Remove the part "must be greated than the HelloInterval parameter and" ----------------- lmpCcIsIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether or not this control channel corresponds to an interface represented in the interfaces group table." ::= { lmpControlChannelEntry 3 } BM> Why this additional object?. Why not require that there be a valid BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into "active" state BM> and that in the absence of a valid underlying interface, the CC BM> will be in the "notReady" state? BM> BM> In the TE LInk case, we require that an entry of type "TE Link" exist BM> BEFORE the corresponding teLinkEntry is created... Why not do the same BM> with CC?. After all, the CC is not usable until a real underlying BM> interface is defined! ---------------- lmpCcNbrNodeId OBJECT-TYPE SYNTAX NodeID MAX-ACCESS read-only STATUS current DESCRIPTION "This is the Node ID of the control channel remote node. This value gets created by the node when a Config message is received or when an outgoing Config message is acknowledged by the remote node." ::= { lmpControlChannelEntry 4 } BM> Should NOT be a read-only. Neighbor needs to be specified. Consider BM> an out-of-band Control channel over a shared ethernet LAN interface- BM> If neighbor is not specified, how will hello config be transmitted to BM> a neighbor? BM> Only in the in-band (and with point to point link) case can the neighbor BM> IP address can be learnt! ----------------- lmpRemoteCcId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the remote control channel identifier. It is determined during the negotiation phase. A value of zero means that the remote control channel identifier has not yet been assigned." ::= { lmpControlChannelEntry 5 } BM> Should read "A value of zero means that the remote CC ID has not yet been learnt" ---------------------- lmpCcSetupRole OBJECT-TYPE SYNTAX INTEGER { active(1), passive(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The role that this node should take during establishment of this control channel. An active node will initiate establishment. A passive node will wait for the remote node to initiate. A pair of nodes that both take the passive role will never establish communications." DEFVAL { active } Well, this is not consistent with the LMP draft, which defines automatic contention resolution mechanism based on node ID. Besides, this is prone to human(operator)-error. The LMP draft reads: "To avoid ambiguities, the node with the higher Node Id wins the contention; the node with the lower Node Id MUST stop transmitting the Config message and respond to the Config message it received." ------------------------ lmpCcAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of this control channel." ::= { lmpControlChannelEntry 17 } BM> Should read "desired admin state" BM> Why is the Admin Status of CC not tied to admin status of the BM> underlying interface? --------------------- lmpTeLinkOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), degraded(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this TE link. The status is set to testing when the TE link is performing link verification. A degraded status indicates that the TE link cannot provide the provisioned protection level, but yet, there is no disruption of service. For instance, if the protection type is 1+1 and one link is down, the TE link still carries the requested amount of data traffic, but this traffic is not protected anymore." ::= { lmpTeLinkEntry 5 } BM> This should reflect the Finite state machine states, defined in the LMP draft, BM> for TE Links. ------------------------------ lmpDataBearingLinkEntry OBJECT-TYPE SYNTAX LmpDataBearingLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table exists for each ifEntry that represents a data-bearing link. An ifEntry with an ifIndex must exist before the corresponding lmpDataBearingLinkEntry is created. If an entry representing the data-bearing link is destroyed in the ifTable, then so is the corresponding entry in the lmpDataBearingLinkTable. The administrative status value is controlled from the ifEntry. The index to this table also used to get information in the dataBearingChannelTable [BUNDLE-MIB]." INDEX { ifIndex } BM> Why is this not an "AUGMENT" to ifEntry? ------------- BM> From an LMP perspective, the "member data links" of a TE Links need BM> to be known.. I realize that this information is available from the BM> bundling MIB.. It may be handy to add an object to the data bearing BM> link table to store the TE Link ? ------------------ BM> Along the lines of TE Link and CC up/down traps, perhaps we should have BM> a trap to notify user when a data bearing link is transitioned to "down" BM> state due to link verification failure. Note that this information is not BM> obtainable from link up/down trap of underlying interface =========================================== --=====================_9978528==_.ALT Content-Type: text/html; charset="us-ascii" Hello,
          My feedback comments are prefixed "BM>"

/Baktha
======================================================

7.5.  lmpLinkVerificationTable

   This table represents the link verification parameters associated
   with the TE links.

BM> Add "Augments lmpTeLinkTable"

----------

7.7.  lmpDataBearingLinkPerfTable

   This table contains the objects to measure the LMP performance of
   data-bearing links and is an AUGMENT to the lmpDataBearingLinkTable.

BM> Add "Augments lmpDataBearingLinkTable"

------------

8.  Example of LMP Control Channel Setup

   In this section we provide a brief example of using the MIB
   objects described in section 11 to set up an LMP control channel.
   While this example is not meant to illustrate every nuance of the
   MIB, it is intended as an aid to understanding some of the key
   concepts. It is meant to be read after going through the MIB itself.


BM> Should read "objects desribed in section 10"
----------------

lmpAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2) }
   MAX-ACCESS    read-write
   STATUS        current
   DESCRIPTION
       "The desired operational status of LMP on the node."
   DEFVAL        { up }
   ::= { lmpObjects 1 }

BM> Do we mean administrative state?

----------------------

lmpNbrTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF LmpNbrEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "This table specifies the neighbor node to which control channels
        may be established."
   ::= { lmpObjects 2 }

BM> neighbor node(s)
----------------------------
      lmpNbrRetransmitInterval           = 10

Wouldn't want this to be the same for link verification, summary etc.
----------------
lmpNbrAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The desired operational status of LMP to this remote node."
   ::= { lmpNbrEntry 3 }

BM> Do we mean desired admin. state?
--------------------

lmpCcHelloIntervalDefaultMin

BM> Presumably, this serves as the default value for lmpCcHelloIntervalMin?

lmpCcHelloIntervalDefaultMax

BM> Presumably, this serves as the default value for lmpCcHelloIntervalMax?

lmpCcHelloDeadIntervalDefaultMin

BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMin?

lmpCcHelloDeadIntervalDefaultMax

BM> Presumably, this serves as the default value for lmpCcHelloDeadIntervalMax?
------------------------

lmpCcHelloDeadIntervalDefault OBJECT-TYPE

   SYNTAX        LmpInterval
   MAX-ACCESS    read-write
   STATUS        current
   DESCRIPTION
       "This object specifies the default HelloDeadInterval parameter to
        use in the Hello protocol keep-alive phase. It indicates how long
        a device should wait before declaring the control channel dead.
        The HelloDeadInterval parameter must be greater than the
        HelloInterval parameter and should be at least three times the
        value of HelloInterval."

BM> Remove the part "must be greated than the HelloInterval parameter and"
-----------------

lmpCcIsIf OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Denotes whether or not this control channel corresponds to
        an interface represented in the interfaces group table."
   ::= { lmpControlChannelEntry 3 }

BM> Why this additional object?. Why not require that there be a valid
BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into "active" state
BM> and that in the absence of a valid underlying interface, the CC
BM> will be in the "notReady" state?
BM>
BM> In the TE LInk case, we require that an entry of type "TE Link" exist
BM> BEFORE the corresponding teLinkEntry is created... Why not do the same
BM> with CC?. After all, the CC is not usable until a real underlying
BM> interface is defined!

----------------

lmpCcNbrNodeId OBJECT-TYPE
   SYNTAX        NodeID
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This is the Node ID of the control channel remote node.
        This value gets created by the node when a Config message
        is received or when an outgoing Config message is acknowledged
        by the remote node."
   ::= { lmpControlChannelEntry 4 }

BM> Should NOT be a read-only. Neighbor needs to be specified. Consider
BM> an out-of-band Control channel over a shared ethernet LAN interface-
BM> If neighbor is not specified, how will hello config be transmitted to
BM> a neighbor?
BM> Only in the in-band (and with point to point link) case can the neighbor
BM> IP address can be learnt!
-----------------
lmpRemoteCcId OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This value represents the remote control channel identifier. It is
        determined during the negotiation phase. A value
        of zero means that the remote control channel identifier has not
        yet been assigned."
   ::= { lmpControlChannelEntry 5 }

BM> Should read "A value of zero means that the remote CC ID has not yet been learnt"

----------------------

lmpCcSetupRole OBJECT-TYPE
   SYNTAX        INTEGER { active(1), passive(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The role that this node should take during establishment of this
        control channel. An active node will initiate establishment. A
        passive node will wait for the remote node to initiate. A pair
        of nodes that both take the passive role will never establish
        communications."
   DEFVAL        { active }

Well, this is not consistent with the LMP draft, which defines automatic contention
resolution mechanism based on node ID. Besides, this is prone to human(operator)-error.

The LMP draft reads:
  "To avoid ambiguities, the node with the higher Node Id wins
   the contention; the node with the lower Node Id MUST stop
   transmitting the Config message and respond to the Config message it
   received."
------------------------
lmpCcAdminStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The desired operational status of this control channel."
   ::= { lmpControlChannelEntry 17 }

BM> Should read "desired admin state"
BM> Why is the Admin Status of CC not tied to admin status of the
BM> underlying interface?

---------------------
lmpTeLinkOperStatus OBJECT-TYPE
   SYNTAX        INTEGER { up(1), down(2), testing(3), degraded(4) }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "The actual operational status of this TE link. The status
        is set to testing when the TE link is performing link
        verification. A degraded status indicates that the TE link
        cannot provide the provisioned protection level, but yet,
        there is no disruption of service. For instance, if the
        protection type is 1+1 and one link is down, the TE link
        still carries the requested amount of data traffic, but
        this traffic is not protected anymore."
   ::= { lmpTeLinkEntry 5 }

BM> This should reflect the Finite state machine states, defined in the LMP draft,
BM> for TE Links.
------------------------------
lmpDataBearingLinkEntry OBJECT-TYPE
   SYNTAX        LmpDataBearingLinkEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
       "An entry in this table exists for each ifEntry that represents
        a data-bearing link. An ifEntry with an ifIndex must exist
        before the corresponding lmpDataBearingLinkEntry is created.
        If an entry representing the data-bearing link is destroyed in
        the ifTable, then so is the corresponding entry in the
        lmpDataBearingLinkTable. The administrative status value is
        controlled from the ifEntry. The index to this table also
        used to get information in the dataBearingChannelTable
        [BUNDLE-MIB]."
   INDEX         { ifIndex }

BM> Why is this not an "AUGMENT" to ifEntry?
-------------

BM> From an LMP perspective, the "member data links" of a TE Links need
BM> to be known.. I realize that this information is available from the
BM> bundling MIB.. It may be handy to add an object to the data bearing
BM> link table to store the TE Link ?
------------------
BM> Along the lines of TE Link and CC up/down traps, perhaps we should have
BM> a trap to notify user when a data bearing link is transitioned to "down"
BM> state due to link verification failure. Note that this information is not
BM> obtainable from link up/down trap of underlying interface
=========================================== --=====================_9978528==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 08:09:31 -0700 Message-ID: From: Fugui Wang To: "'Martin Dubuc'" , Fugui Wang Cc: sudheer@nayna.com, tnadeau@cisco.com, jplang@calient.net, evan@calient.net, ccamp@ops.ietf.org Subject: RE: Questions about draft-ietf-ccamp-lmp-mib-00.txt Date: Thu, 25 Oct 2001 11:06:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Martin, Thanks for the clarification. But isn't lmpDataBearingLinkEncodingType also redundant with dataBearingChannelEncodingType and teLinkEncodingType in the link bundling MIB? Thanks, Fugui -----Original Message----- From: Martin Dubuc [mailto:martin.dubuc@edgeflow.com] Sent: Wednesday, October 24, 2001 2:09 PM To: Fugui Wang Cc: sudheer@nayna.com; tnadeau@cisco.com; jplang@calient.net; evan@calient.net; ccamp@ops.ietf.org Subject: RE: Questions about draft-ietf-ccamp-lmp-mib-00.txt Fugui, The lmpRemoteTeLinkId and lmpRemoteTeLinkType was removed from the latest LMP MIB because it was redundant with information stored in the link bundling MIB (see http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt). The link bundling MIB contains a TE link table (teLinkTable) which captures the information you are looking for. The remote TE link type is found in the teLinkNumberingType object and the remote TE link identifier is either teLinkRemoteIpAddr or teLinkIncomingIfId depending on whether or not the TE link is numbered or unnumbered. Regards, Martin -----Original Message----- From: Fugui Wang [mailto:fwang@axiowave.com] Sent: Wednesday, October 24, 2001 12:08 PM To: Martin Dubuc; 'sudheer@nayna.com'; 'tnadeau@cisco.com'; 'jplang@calient.net'; 'evan@calient.net' Cc: 'ccamp@ops.ietf.org' Subject: Questions about draft-ietf-ccamp-lmp-mib-00.txt I noticed that lmpRemoteTeLinkId and lmpRemoteTeLinkType were taken away from the TE Link Table in this version. Is there any special reason for that? In the latest LMP draft draft-ietf-ccamp-lmp-01.txt, when we do link verification or link summary, we still need the remote TE link ID infomation. Would you suggest that we store the remote TE link ID in other places instead of in the TE link Table? Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 07:49:19 -0700 Message-ID: From: neil.2.harrison@bt.com To: mike.sexton@alcatel.co.uk Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 25 Oct 2001 15:46:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Mike, you wrote 25 October 2001 15:26 > I am not sure that it is appropriate to get into business > model issues on this list. NH=> Agreed in general....but if one is doing something technical one assumes there is a problem it is solving. I am showing that the 'business problem' is not at all clear (even if we had loads of money to spend at the moment)....irrespective of the right/wrongs of the particular 'technical solution'. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 06:53:02 -0700 Message-ID: <3BD818A1.6070100@lucent.com> Date: Thu, 25 Oct 2001 09:50:25 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Maarten Vissers'" , Sudheer Dharanikota , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, Let's not say which one is sub-set of which other one. As I mentioned, ASON and GMPLS (or ASON and PNNI, but from what I understand IETF doesn't do PNNI so this issue is not discussed here) are complementary. Let's treat it that way and move forward by trying to align the two so that the industry will benefit (my little rambling again). However, there are still some issues of GMPLS technology specific that still needs to be resolved. Those are not ASON issues, since ASON treats these as generic "labels". From what I understand several people are still discussing this (I use "discussing" broadly...it sounds better)...I think you know my position and several people's position on this... Zhi Mannie, Eric wrote: > Hello Maarten, > > >>ASON is layer network based, GMPLS is not >> > > Sorry, but you misunderstood how GMPLS works for SDH/SONET. > > GMPLS supports *all* approaches that you described: "layer network based" > and/or "hidden set up of a STS-1 or VC-4 trail supporting an additional > VT/LOVC link or extending an existing VT/LOVC link". > > The difference between these two approaches is a policy matter and should be > independent of the protocols. That's what we are doing (made) with GMPLS: we > are developing a toolbox without specifying (forcing) the policies. > > That's up to the manufacturer to decide which policies he will implement > (e.g. both) and to the operator to decide which policies he wants to use. > Policies can even be dynamic and depends on customers. You can even use the > COPS model to deal with these policies. > > To be more clear, at each switch you could have different policies, at some > places the call could fails (referring here to you example), at some places > the call could trigger a "hidden" VC-4. GMPLS doesn't specifies that. An > operator could operate its network in a pure layer network based approach, > or using only the other approach or using a mix. > > If you mean that ASON "hardcoded" the policies by limiting the architecture > and the protocols to the example you gave (layer network based), that's a > *serious* limitation of ASON (and by the way totally unjustified). Clearly > from that perspective ASON is a subset of GMPLS. Is it the case ? > > Kind regards, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Thursday, October 25, 2001 7:04 AM > To: Sudheer Dharanikota > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > > Sudheer, > > Another issue is ... > > - ASON is layer network based, GMPLS is not > > i.e. a request for a connection within ASON is treated within the boundaries > of > one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer > network, or > within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 > connection > request is processed within the VT1.5/VC-11 layer network, using existing > VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity in > the > VT1.5/VC-11 links to support the request, the call fails. There is no > "hidden" > set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or > extending an existing VT/LOVC link. The set up of an additional STS-1 or > VC-4 > trail is supported within the scope of network planning and/or network > engineering. This is separated from the connection set up. > > Regards, > > Maarten > > Sudheer Dharanikota wrote: > >>Hi Maarten: >> >>Maarten Vissers wrote: >> >> >>>Sudheer, >>> >>>At the moment I am unable to briefly summarize the differences between >>> > GMPLS and > >>>ASON. I was working from the perception that GMPLS could be one of the >>> > protocols > >>>supporting ASON. The technical comments I made during the last 10 months >>> > were > >>>based on this perception. Also the last comment describing the concept >>> > of serial > >>>compound link had this basis. Reading Yanhe's reply I had the impression >>> > that > >>>GMPLS is able to support serial compound links, but reading Eric's reply >>> > I got > >>>the opposite impression. Furthermore being very surprised by Eric's >>> > reaction on > >>>a pure technical issue, I composed a few challenging words to attrack >>> > more > >>>people to participate in the discussion... :-) >>> >>I see one of the issue here being ... >> >> - Does GMPLS support serial compound links? >> >>Let us enumerate few more questions and move the discussion to a technical >>level again, we need participation especially from the folks who are >> > involved > >>in ASON architecture work. >> >> >>>Being impressed by the few hundred people attending the last ccamp >>> > sessions in > >>>London, I am surprised by the low percentage of those people being >>> > actively > >>>contributing to the correspondence. It can't be the case that only a >>> > handful of > >>>people have an opinion on these matters... and I believe the discussions >>> > would > >>>stay technical if more people express their opinion... there would not >>> > be a > >>>yes/no game between just a few people. >>> >>> >>I thought this is how most of the standards meetings work. 5 % work, 95 % >>try to gather industry intelligence ( :-) ) either by attending IETF or by >> > following > >>the mailing list. >> >> >>>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be >>> > possible to > >>>start an evaluation of GMPLS as a specific protocol for ASON. As >>> > indicated in a > >>>previous email from Steve Trowbridge, ITU-T will make those ASON >>> > documents > >>>available to IETF so we can jointly work this evaluation. >>> >>> >>Most of these documents are available on the t1x1 site. But what we need >> > here is > >>the "delta" that is missing between ASON architecture and the view of >> > GMPLS > >>architecture. Can you help us with this? We may start with a short list... >> >> >>>The approval of the current ASON recommendations is just a first step >>> > within the > >>>larger ASON task. Work is started on other elements of ASON (G.rtg >>> > (routing), > >>>G.lm (link management) and pnni based specific protocol as an >>> > implementation of > >>>the protocol neutral specification in G.7713)), discussions are started >>>identifying further ASON elements, and work to extend G.8080 is planned >>> > to start > >>>after this SG15 meeting. >>> >>> >>Obviously GMPLS is a potential candidate to solve the ASON issues. It may >> > be > >>ahead of its time as far as ITU and ANSI are concerned. So let us ammend >> > or > >>modify it to the ITU view on the transport control plane. >> >>Regards, >> >>sudheer >> >> >>>Up to so far... {time to shut down my computer and go to the concert >>> > hall in > >>>Geneva... time to relax after a week and a half of hectic work over >>> > here...} > >>>Regards, >>> >>>Maarten >>> >>>Sudheer Dharanikota wrote: >>> >>>>Hi Marteen: >>>> >>>>Can you briefly summarize the differences you see between >>>>GMPLS architecture and ASON architecture? This has been >>>>asked by many of the folks at IETF. >>>> >>>>Regards, >>>> >>>>sudheer >>>> >>>>PS: I thought these mails were about label format and suddenly >>>>this is turning into an ITU versus IETF discussion :-( >>>> > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 06:49:48 -0700 From: mike.sexton@alcatel.co.uk To: neil.2.harrison@bt.com cc: mvissers@lucent.com, sudheer@nayna.com, ccamp@ops.ietf.org Message-ID: <80256AF0.0049C9EC.00@gbmta001.netfr.alcatel.fr> Date: Thu, 25 Oct 2001 15:25:58 +0100 Subject: RE: Moving right along ... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Neil, I am not sure that it is appropriate to get into business model issues on this list. I'd have to get my marketing and business development hat on. However below, in line, is a brief response I suggest if you want to pursue this further we do it off list. regards, Mike Sexton neil.2.harrison@bt.com on 25/10/2001 11:47:18 To: Michael J SEXTON/GB/ALCATEL@ALCATEL, mvissers@lucent.com cc: sudheer@nayna.com, ccamp@ops.ietf.org Subject: RE: Moving right along ... Hi Mike.....nice to hear from you and I think you make some good points. However, I want to pick-up on one aspect you bring up a few times....and that is 'choice'. Operators need choice to suit their views on what is/is-not a viable business case. MS: Naturally. For example, we have various client layer networks besides IP to accommodate, and of particular importance are managed BW services directly off the L1 fabric, eg VC4 or lambdas say. However, we can't see any valid business case for generalised BoD/SVCs services here.....I mean, given unknown calling/holding statistics just what capacity would one need to build to to offer a GoS that customers would consider acceptable and that you could get past finance/products people (esp given current climate)? MS: The service level differences here are quite subtle. They are for many practical purposes indistinguishable. But, getting back on subject, whether they are implemented with the help of a control plane or through a centralised service management process will only affect secondary features (eg speed of customer response, performance etc) and these will be more determined by implementation details in either model. So, on assumption that S-PVC-like services are all that is commercailly viable (in our opinion at least) then you can ask yourself just what additional revenues and/or Opex cost reductions are available from implementating a control-plane solution? Even this is difficult to justify given: - current NMS approaches (in SDH) can easily cater for current and foreseeable core trail churn rates; - the big costs are in access and laying ducts and installing physicals....no control-plane solution is going to impact these. MS: Agreed these are difficult calls to make. However I note that there has been considerable interest in recent times in the developing business of bandwidth brokerage. In just a few years implementations of this business model have progressed from purely paper contract based introductions between buyers and sellers through Web based service transactions to automatically switched on demand. In the last case the bandwidth broker installs a switch (controlled through SS7) or an optical cross-connect controlled through service management centre (in future ?) buyers and sellers attach themselves to BB premises via metro fibre links and exchange bandwidth either on a form of spot market (as available) or under an evergrowing variety of more elaborate contracts (time of day, OVPN, standby for overflow or protection etc). This trend may continue or it may indeed fizzle out. However, assuming you do decide you want to implement a control-plane solution in your transport networks then you really ought to be able to choose the addressing, signalling and routing components on a best-of-breed basis to suit what you want to do. They are after all, quite disjoint components and there are many architectural possibilities.......and this is what ASON is all about....choice. MS: This is the basic standardisation dilemma. where is the "right" trade off between choice and efficiency. The modern solution to protect choice is to set off a number of de juro standards and leave them to slug it out in the market place. Those that retain sufficient flexibility to find their market niche and adapt, survive those that don't don't. For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling aspects only) + centralised routing approach looks the best commercially for what we want to do. Others may argue that the current GMPLS approach suits them best. ASON allows this choice. regards, Neil > -----Original Message----- > From: mike.sexton@alcatel.co.uk [mailto:mike.sexton@alcatel.co.uk] > Sent: 25 October 2001 11:49 > To: Maarten Vissers > Cc: Sudheer Dharanikota; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > > > > Maarten, > > In the interests of reconciliation consider the following: > > ASON and G-MPLS are both post hoc conceptual models > describing the same physical and logical network. The > objectives of automation through signalling are broadly > similar. Therefore it would be surprising indeed if the > solutions were widely different. ASON > is indeed based on the layered model of G.805 and deals with > layering issues up-front. GMPLS is derived from the Internet > model which regards the physical layer as flat. When real > world layering is encountered it is dealt with by refinements > many of which > appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one > of the source documents from which G-MPLS inherits. Here LSP > regions are defined in 6.2 which are as near as I can tell > exactly equivalent to G.805 layer networks. Further, precedence rules > between layers are established with the clear implication > that a higher layer cannot be configured until the > appropriate resources in the lower layer have been > instantiated. The manner in which this may be done is > considered a "local matter". The example > given indicates that a Forwarding Adjacency (equivalent to a > G.805 link supported by one or more trails (LSPs) in the > server layer) may be initiated in various ways including from > an external manager or another (adjacent) LSR. Thus the > example you gave of > a VC-1x layer being set up by signalling and VC-4 layer being > set up by an external planning/management is certainly a > valid implementation within the scope of the G-MPLS solution. > By the same token it is undesirable (and anyway will not be > possible) to > confine signalling to certain layers while reserving others > for management through a standard. Operators will want to > make such important architectural choices on the basis of > optimising their own operation. Once you have agreed on a > signalling protocol to > create connections within a layer network it is generically > applicable to any layer network. Of course making such an > implementation choice (ie management for VC-4, signalling for > VC-1x) is an example of the "local policies" mentioned above. > Such choices > frequently appear as part of some sort of application > specific profile or applications framework on top of the base > generic standard. Note this sort of profiling (if that is the > correct term) is > generally needed to ensure interworking amongst elements > which implement the same generic standard. > > On the last occasion that we studied application of > signalling for transport networks in ITU (over 10 years ago > at the time G.805 was first issued) we had concluded that > connection set-up within a layer was the easy part ie there > were several well > established candidates to choose from (B-ISUP was the > favorite. Neither PNNI nor RSVP existed at that time. ISIS > had already been adopted for DCN in SDH and thus provided > basic neighbour discovery and xSPF computation if required). > The major new problem to > resolve for multi-layer transport networks was indeed > considered to be the desired behaviour at inter-layer > boundaries. It seems that both initiatives have sidelined > this issue as out of scope for the time being. > > regards, > > Mike Sexton > > > > > > > > Maarten Vissers on 25/10/2001 06:03:38 > > > > To: Sudheer Dharanikota > > cc: ccamp@ops.ietf.org(bcc: Michael J > SEXTON/GB/ALCATEL) > > > > Subject: Re: Moving right along ... > > > > > > > Sudheer, > > Another issue is ... > > - ASON is layer network based, GMPLS is not > > i.e. a request for a connection within ASON is treated within > the boundaries of > one layer network (e.g. within the boundaries of a > VT1.5/VC-11 layer network, or > within the boundaries of a STS-3c/VC-4 layer network). A > VT1.5/VC-11 connection > request is processed within the VT1.5/VC-11 layer network, > using existing > VT1.5/VC-11 links (GMPLS: link bundles). If there is not > enough capacity in the > VT1.5/VC-11 links to support the request, the call fails. > There is no "hidden" > set up of a STS-1 or VC-4 trail supporting an additional > VT/LOVC link or > extending an existing VT/LOVC link. The set up of an > additional STS-1 or VC-4 > trail is supported within the scope of network planning and/or network > engineering. This is separated from the connection set up. > > Regards, > > Maarten > > Sudheer Dharanikota wrote: > > > > Hi Maarten: > > > > Maarten Vissers wrote: > > > > > Sudheer, > > > > > > At the moment I am unable to briefly summarize the > differences between GMPLS and > > > ASON. I was working from the perception that GMPLS could > be one of the protocols > > > supporting ASON. The technical comments I made during the > last 10 months were > > > based on this perception. Also the last comment > describing the concept of serial > > > compound link had this basis. Reading Yanhe's reply I had > the impression that > > > GMPLS is able to support serial compound links, but > reading Eric's reply I got > > > the opposite impression. Furthermore being very surprised > by Eric's reaction on > > > a pure technical issue, I composed a few challenging > words to attrack more > > > people to participate in the discussion... :-) > > > > I see one of the issue here being ... > > > > - Does GMPLS support serial compound links? > > > > Let us enumerate few more questions and move the discussion > to a technical > > level again, we need participation especially from the > folks who are involved > > in ASON architecture work. > > > > > > > > Being impressed by the few hundred people attending the > last ccamp sessions in > > > London, I am surprised by the low percentage of those > people being actively > > > contributing to the correspondence. It can't be the case > that only a handful of > > > people have an opinion on these matters... and I believe > the discussions would > > > stay technical if more people express their opinion... > there would not be a > > > yes/no game between just a few people. > > > > > > > I thought this is how most of the standards meetings work. > 5 % work, 95 % > > try to gather industry intelligence ( :-) ) either by > attending IETF or by following > > > > the mailing list. > > > > > > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available > it will be possible to > > > start an evaluation of GMPLS as a specific protocol for > ASON. As indicated in a > > > previous email from Steve Trowbridge, ITU-T will make > those ASON documents > > > available to IETF so we can jointly work this evaluation. > > > > > > > Most of these documents are available on the t1x1 site. But > what we need here is > > the "delta" that is missing between ASON architecture and > the view of GMPLS > > architecture. Can you help us with this? We may start with > a short list... > > > > > > > > The approval of the current ASON recommendations is just > a first step within the > > > larger ASON task. Work is started on other elements of > ASON (G.rtg (routing), > > > G.lm (link management) and pnni based specific protocol > as an implementation of > > > the protocol neutral specification in G.7713)), > discussions are started > > > identifying further ASON elements, and work to extend > G.8080 is planned to start > > > after this SG15 meeting. > > > > > > > Obviously GMPLS is a potential candidate to solve the ASON > issues. It may be > > ahead of its time as far as ITU and ANSI are concerned. So > let us ammend or > > modify it to the ITU view on the transport control plane. > > > > Regards, > > > > sudheer > > > > > > > > Up to so far... {time to shut down my computer and go to > the concert hall in > > > Geneva... time to relax after a week and a half of hectic > work over here...} > > > > > > Regards, > > > > > > Maarten > > > > > > Sudheer Dharanikota wrote: > > > > > > > > Hi Marteen: > > > > > > > > Can you briefly summarize the differences you see between > > > > GMPLS architecture and ASON architecture? This has been > > > > asked by many of the folks at IETF. > > > > > > > > Regards, > > > > > > > > sudheer > > > > > > > > PS: I thought these mails were about label format and suddenly > > > > this is turning into an ITU versus IETF discussion :-( > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 06:20:24 -0700 Message-ID: <176689DD1922D511ABE10001022E4DF229C6C1@OPTONT> From: Cheenu Srinivasan To: "'mpls@UU.NET'" , "'ccamp@ops.ietf.org'" Subject: draft-ietf-mpls-mgmt-overview-00.txt posted Date: Thu, 25 Oct 2001 09:33:29 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C15D59.A1CC7C50" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C15D59.A1CC7C50 Content-Type: text/plain I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should appear on the IETF site shortly. A copy of this I-D is attached. Cheenu > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Tuesday, October 23, 2001 4:37 PM > Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt > > > Given that many have supported the idea and none have opposed, the > above draft is accepted as a work group draft. > > ...George ------_=_NextPart_000_01C15D59.A1CC7C50 Content-Type: text/plain; name="draft-ietf-mpls-mgmt-overview-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-mpls-mgmt-overview-00.txt" Network Working Group Thomas D. Nadeau Internet Draft Cisco Systems, Inc. Category: Informational =20 Expires: April 2002 Cheenu Srinivasan Alphion Corp. =20 Adrian Farrel Movaz Networks, Inc. =20 October 2001 =20 =20 Multiprotocol Label Switching (MPLS) Management Overview =20 draft-ietf-mpls-mgmt-overview-00.txt Status of this Memo =20 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. =20 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. =20 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." =20 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. =20 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Table of Contents =20 Abstract ..................................................... 2 1. Introduction .............................................. 2 2. Terminology ............................................... 2 3. The SNMP Management Framework ............................. 3 4. MIBs Addressed by the MPLS Management Framework ........... 4 4.1. MPLS-TC-MIB ............................................. 4 4.2. MPLS-LSR-MIB ............................................ 4 4.2.1. Dependencies .......................................... 4 4.3. MPLS-LDP-MIB ............................................ 5 4.3.1. Dependencies .......................................... 5 4.4. MPLS-TE-MIB ............................................. 5 Nadeau et al. Expires April 2002 [Page 1] =0C Internet Draft MPLS Management Overview October 2001 4.4.1. Dependencies .......................................... 5 4.5. MPLS-FTN-MIB ............................................ 6 4.5.1. Dependencies .......................................... 6 4.6. MPLS-LINK-BUNDLING-MIB .................................. 6 4.6.1. Dependencies .......................................... 6 4.7. PPVPN-MPLS-VPN-MIB ...................................... 6 4.7.1. Dependencies .......................................... 7 5. Dependencies on Other IETF Working Groups ................. 7 5.1. Pseudo Wire Emulation Edge to Edge MIBs ................. 7 5.2. Provider Provisioned Virtual Private Network MIBs ....... 7 5.3. Common Control and Measurement Plane (CCAMP) WG ......... 7 6. Security Considerations ................................... 7 7. Acknowledgments ........................................... 8 8. References ................................................ 8 9. Authors' Addresses ........................................ 10 10. Full Copyright Statement ................................. 11 Abstract =20 This memo describes the Multi-Protocol Label Switching (MPLS) [RFC3031] management architecture and the inter- relationships between the different management information bases (MIBs). 1. Introduction =20 This memo describes the Management Architecture for Multi- Protocol Label Switching. In particular, it describes how various managed objects defined in various Management Information Base (MIB) documents model different aspects of Multi-Protocol Label Switching (MPLS) [MPLSArch]. Furthermore, this document explains the interactions and dependencies between each of these documents. =20 Comments should be made directly to the MPLS mailing list at mpls@uu.net. =20 =20 =20 This draft does not propose any additions to the MPLS MIB framework, nor define any standards for the Internet community. It is an informational draft. 2. Terminology =20 This document uses terminology from the MPLS architecture Nadeau et al. Expires April 2002 [Page 2] =0C Internet Draft MPLS Management Overview October 2001 document [MPLSArch] and various MPLS-related MIBs such as the MPLS-TC-MIB [TCMIB], MPLS-LSR-MIB [LSRMIB], MPLS-TE-MIB [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and the MPLS-LINK-BUNDLING-MIB [LBMIB]. 3. The SNMP Management Framework =20 The SNMP Management Framework presently consists of five major components: =20 - An overall architecture, described in RFC 2571 [RFC2571]. =20 - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and STD 16, RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. =20 - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. =20 - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. =20 - A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. =20 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. =20 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Nadeau et al. Expires April 2002 [Page 3] =0C Internet Draft MPLS Management Overview October 2001 Objects in the MIB are defined using the mechanisms defined in the SMI. 4. MIBs Addressed by the MPLS Management Framework =20 This section briefly explains what the purpose of each MPLS related MIB is and what it can be used for. Each section contains a subsection that details the interdependencies between that MIB and any of the other MPLS MIBs. 4.1. MPLS-TC-MIB =20 The MPLS-TC-MIB [TCMIB] describes textual conventions [RFC2579] and object identities that may be common to MPLS- related MIBs. For example, the textual convention for representing an MPLS label should be commonly represented and used by all MPLS-related MIBs. 4.2. MPLS-LSR-MIB =20 The MPLS-LSR-MIB describes managed objects for modeling a Multi-Protocol Label Switching (MPLS) [RFC3031] Label Switch Router (LSR). In particular, this MIB is used to model and manage the basic label switching behavior and the label forwarding information base (LFIB) of an MPLS LSR. In doing so, the MIB provides a view of the LSPs that are being switched by the LSR in question. =20 This MIB is the basis for many of the MPLS MIBs, since basic MPLS label switching is common to all MPLS applications. In general, the MPLS-LSR-MIB provides a model of incoming labels on MPLS-enabled interfaces being mapped to outgoing labels on MPLS-enabled interfaces via a conceptual object called an MPLS cross-connect. MPLS cross- connect entries and their properties are represented in the MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS cross-connect entries are typically referred to by other MIBs in order to reference the underlying MPLS LSP. =20 For example, the MPLS-TE-MIB [TEMIB] models traffic engineered tunnels. These tunnels map to one more underlying MPLS LSPs. Thus, the MPLS-TE-MIB's tunnel table (mplsTunnelTable) entries refer to the underlying LSP by pointing to entries in mplsXCTable. 4.2.1. Dependencies =20 Nadeau et al. Expires April 2002 [Page 4] =0C Internet Draft MPLS Management Overview October 2001 This MIB does not directly depend upon any other MPLS MIBs. It does represent MPLS-enabled interfaces as entries in the Interfaces MIB [RFC2233] Interface Table (ifTable). This MIB imports several textual conventions from the MPLS-TC- MIB [TCMIB]. 4.3. MPLS-LDP-MIB =20 The MPLS-LDP-MIB describes managed objects used to model and manage the Multiprotocol Label Switching Label Distribution Protocol (LDP). 4.3.1. Dependencies =20 The LDP MIB [LDPMIB] has three mapping tables - mplsLdpSesInLabelMapTable, mplsLdpSesOutLabelMapTable and mplsLdpSesXCMapTable - which map the LDP MIB=92s representation of LDP sessions to the underlying LSR MIB=92s representation of the LSPs created by these sessions by pointing to mplsInSegmentTable, mplsOutSegmentTable and mplsXCTable, respectively. The LDP MIB=92s mplsXCsFecsTable shows the relationship between between forwarding equivalence classes (FECs) and cross-connect entries by referring to entries in the LSR MIB=92s mplsXCTable. =20 This MIB also imports several textual conventions from the MPLS-TC-MIB [TCMIB]. 4.4. MPLS-TE-MIB =20 The MPLS-TE-MIB [TEMIB] describes managed objects that are used to model and manage MPLS Traffic Engineered (TE) Tunnels. The MIB is based around a table that represents TE tunnels that either originate at the LSR in question or traverse via or terminate on the LSR. Note that the later case is optional, as only tunnel "heads" are required to be represented. This MIB provides statistics and configuration objects needed for TE tunnels. 4.4.1. Dependencies =20 This MIB depends on the MPLS-LSR-MIB [LSRMIB] and Interfaces MIB [RFC2233]. Tunnel entries in the MPLS-TE- MIB=92s mplsTunnelTable refer to entries in mplsXCTable in the MPLS-LSR-MIB. When MPLS TE tunnels are represented as interfaces, entries for such tunnels in mplsTunnelTable have corresponding entries in the Interfaces MIB=92s [RFC2233] Interfaces Table (ifTable). This MIB also imports Nadeau et al. Expires April 2002 [Page 5] =0C Internet Draft MPLS Management Overview October 2001 several textual conventions from the MPLS-TC-MIB [TCMIB]. 4.5. MPLS-FTN-MIB =20 The MPLS-FTN-MIB [FTNMIB] describes managed objects that are used to model and manage the MPLS FEC-to-NHLFE mappings which take place at any LSR that is on the edge between an MPLS domain and a non-MPLS domain. On each such edge LSR, to map traffic from the non-MPLS domain into the MPLS domain, the FEC-to-NHLFE mapping objects in the MPLS-FTN- MIB must be supported. In the case of an IP-to-MPLS mapping, the FEC objects describe IP 5-tuples representing IP source and destination ranges, protocol ranges etc. Matching IP packets can be mapped to an NHLFE which can either be an MPLS LSP or an MPLS TE tunnel. 4.5.1. Dependencies =20 This MIB relies directly on the MPLS-LSR-MIB [LSRMIB] and MPLS-TE-MIB [TEMIB]. FECs can be mapped to two types of NHLFEs by the MPLS-FTN-MIB. When the NHLFE is an LSP, the FEC-to-NHLFE mapping is accomplished by referring to a corresponding entry in mplsXCTable in the MPLS-LSR-MIB. When the NHLFE is an MPLS TE tunnel, this mapping is accomplished by referring to a corresponding entry in mplsTunnelTable in MPLS-TE-MIB. 4.6. MPLS-LINK-BUNDLING-MIB =20 The MPLS-LINK-BUNDLING-MIB [LBMIB] describes managed objects that are used to model and manage the MPLS TE interfaces, as well as the link bundling relationships that may exist between those interfaces. 4.6.1. Dependencies =20 The MPLS-LINK-BUNDLING-MIB [LBMIB] interacts directly only with the Interfaces MIB [RFC2233]; it references MPLS TE interfaces that are modeled by entries in the interfaces table (ifTable) in the Interfaces MIB [RFC2233]. 4.7. PPVPN-MPLS-VPN-MIB =20 The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects that are used to model and manage RFC2277bis MPLS VPNs. This MIB contains tables which model virtual routing forwarding entries (VRFs), as well as the interfaces Nadeau et al. Expires April 2002 [Page 6] =0C Internet Draft MPLS Management Overview October 2001 associated with those VRFs. 4.7.1. Dependencies =20 This MIB currently has no direct dependencies to any of the MPLS MIBs. This MIB does model MPLS VPN interfaces as entries in the Interfaces MIB [RFC2233]. This MIB may be modified in the future to import textual conventions from the MPLS-TC-MIB [TCMIB]. 5. Dependencies on Other IETF Working Groups =20 This section will detail the broad interactions between other working groups and the MPLS MIBs. 5.1. Pseudo Wire Emulation Edge to Edge MIBs =20 The Pseudo Wire Emulation Edge to Edge (pwe3) working group has produced a framework [PWE3ARCH] describes a framework for PWE3 MIBs. Since the PWE3 architecture includes the use of MPLS as an emulated service and as a PSN service, the MPLS MIBs described above may be leveraged. This framework document describes the interactions between the MPLS MIBs and the PWE3 MIBs. 5.2. Provider Provisioned Virtual Private Network MIBs =20 At present, the Provider Provisioned Virtual Private Network (PPVPN) working group has not included a discussion of how the MPLS MIBs interact with the MIBs being produced by that working group. The authors of this draft hope to make a forthcoming addition to their framework [PPVPNFW] document detailing these interactions. At the moment, there is only a single MIB produced which interacts with the MPLS MIBs, as this MIB is described above in section 5.3. Common Control and Measurement Plane (CCAMP) WG =20 At present, there are no MIBs produced by the CCAMP working group that interact directly with the MPLS MIBs. However, in the future, the existing MPLS MIBs will need to be extended and augmented to facilitate the technology being produced by this working group. 6. Security Considerations Nadeau et al. Expires April 2002 [Page 7] =0C Internet Draft MPLS Management Overview October 2001 =20 This document describes the inter-relationships amongst the different MIBs relevant to MPLS management and as such does not have any security implications beyond those imposed by these MIBs themselves. 7. Acknowledgments =20 TBD. 8. References =20 [TCMIB] Nadeau, T., Cucchiara, J., Srinivasan, C, Viswanathan, A. and H. Sjostrand, "Definition of Textual Conventions and OBJECT-IDENTITIES for Multi-Protocol Label Switching (MPLS) Management", Internet Draft , August 2001. =20 [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", Internet Draft , January 2001. =20 [TEMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", Internet Draft , August 2001. =20 [FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", Internet Draft , August 2001. =20 [LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang, "Link Bundling Management Information Base Using SMIv2", Internet Draft , September 2001. =20 [PWE3ARCH] Pate, P., Xiao, X., White., C., Kompella., K., Malis, A., Johnson, T., and T. Nadeau, "Framework for Pseudo Wire Emulation Edge-to- Edge (PWE3)", Internet Draft , September, 2001. =20 [PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis, A., Muthukrishnan, K., Rosen, E., Sargor, C., and J. Yu, "A Framework for Provider Provisioned Virtual Private Networks", Internet Draft , July 2001. =20 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, May 1990. =20 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. =20 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, March 1991. =20 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. =20 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. =20 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. =20 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. =20 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. =20 [RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interface Group MIB Using SMIv2", RFC 2233, November 1997. =20 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. =20 Nadeau et al. Expires April 2002 [Page 9] =0C Internet Draft MPLS Management Overview October 2001 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. =20 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. =20 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. =20 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. =20 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. =20 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. =20 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. =20 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. =20 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 9. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Nadeau et al. Expires April 2002 [Page 10] =0C Internet Draft MPLS Management Overview October 2001 Email: tnadeau@cisco.com Cheenu Srinivasan Alphion Corp. 4 Industrial Way West Eatontown, NJ 07724 Phone: +1-732-676-7066 Email: cheenu@alphion.com Adrian Farrel Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Phone: +1-703-847-9847 Email: afarrel@movaz.com 10. Full Copyright Statement =20 Copyright (C) The Internet Society (2001). All Rights Reserved. =20 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. =20 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nadeau et al. Expires April 2002 [Page 11] ------_=_NextPart_000_01C15D59.A1CC7C50-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 04:48:12 -0700 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' , Sudheer Dharanikota Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 25 Oct 2001 13:41:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, > ASON is layer network based, GMPLS is not Sorry, but you misunderstood how GMPLS works for SDH/SONET. GMPLS supports *all* approaches that you described: "layer network based" and/or "hidden set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or extending an existing VT/LOVC link". The difference between these two approaches is a policy matter and should be independent of the protocols. That's what we are doing (made) with GMPLS: we are developing a toolbox without specifying (forcing) the policies. That's up to the manufacturer to decide which policies he will implement (e.g. both) and to the operator to decide which policies he wants to use. Policies can even be dynamic and depends on customers. You can even use the COPS model to deal with these policies. To be more clear, at each switch you could have different policies, at some places the call could fails (referring here to you example), at some places the call could trigger a "hidden" VC-4. GMPLS doesn't specifies that. An operator could operate its network in a pure layer network based approach, or using only the other approach or using a mix. If you mean that ASON "hardcoded" the policies by limiting the architecture and the protocols to the example you gave (layer network based), that's a *serious* limitation of ASON (and by the way totally unjustified). Clearly from that perspective ASON is a subset of GMPLS. Is it the case ? Kind regards, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Thursday, October 25, 2001 7:04 AM To: Sudheer Dharanikota Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Sudheer, Another issue is ... - ASON is layer network based, GMPLS is not i.e. a request for a connection within ASON is treated within the boundaries of one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer network, or within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is processed within the VT1.5/VC-11 layer network, using existing VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity in the VT1.5/VC-11 links to support the request, the call fails. There is no "hidden" set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or extending an existing VT/LOVC link. The set up of an additional STS-1 or VC-4 trail is supported within the scope of network planning and/or network engineering. This is separated from the connection set up. Regards, Maarten Sudheer Dharanikota wrote: > > Hi Maarten: > > Maarten Vissers wrote: > > > Sudheer, > > > > At the moment I am unable to briefly summarize the differences between GMPLS and > > ASON. I was working from the perception that GMPLS could be one of the protocols > > supporting ASON. The technical comments I made during the last 10 months were > > based on this perception. Also the last comment describing the concept of serial > > compound link had this basis. Reading Yanhe's reply I had the impression that > > GMPLS is able to support serial compound links, but reading Eric's reply I got > > the opposite impression. Furthermore being very surprised by Eric's reaction on > > a pure technical issue, I composed a few challenging words to attrack more > > people to participate in the discussion... :-) > > I see one of the issue here being ... > > - Does GMPLS support serial compound links? > > Let us enumerate few more questions and move the discussion to a technical > level again, we need participation especially from the folks who are involved > in ASON architecture work. > > > > > Being impressed by the few hundred people attending the last ccamp sessions in > > London, I am surprised by the low percentage of those people being actively > > contributing to the correspondence. It can't be the case that only a handful of > > people have an opinion on these matters... and I believe the discussions would > > stay technical if more people express their opinion... there would not be a > > yes/no game between just a few people. > > > > I thought this is how most of the standards meetings work. 5 % work, 95 % > try to gather industry intelligence ( :-) ) either by attending IETF or by following > > the mailing list. > > > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to > > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a > > previous email from Steve Trowbridge, ITU-T will make those ASON documents > > available to IETF so we can jointly work this evaluation. > > > > Most of these documents are available on the t1x1 site. But what we need here is > the "delta" that is missing between ASON architecture and the view of GMPLS > architecture. Can you help us with this? We may start with a short list... > > > > > The approval of the current ASON recommendations is just a first step within the > > larger ASON task. Work is started on other elements of ASON (G.rtg (routing), > > G.lm (link management) and pnni based specific protocol as an implementation of > > the protocol neutral specification in G.7713)), discussions are started > > identifying further ASON elements, and work to extend G.8080 is planned to start > > after this SG15 meeting. > > > > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be > ahead of its time as far as ITU and ANSI are concerned. So let us ammend or > modify it to the ITU view on the transport control plane. > > Regards, > > sudheer > > > > > Up to so far... {time to shut down my computer and go to the concert hall in > > Geneva... time to relax after a week and a half of hectic work over here...} > > > > Regards, > > > > Maarten > > > > Sudheer Dharanikota wrote: > > > > > > Hi Marteen: > > > > > > Can you briefly summarize the differences you see between > > > GMPLS architecture and ASON architecture? This has been > > > asked by many of the folks at IETF. > > > > > > Regards, > > > > > > sudheer > > > > > > PS: I thought these mails were about label format and suddenly > > > this is turning into an ITU versus IETF discussion :-( Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 04:05:17 -0700 Message-ID: <3BD7F1B3.3010804@lucent.com> Date: Thu, 25 Oct 2001 07:04:19 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: mike.sexton@alcatel.co.uk CC: Maarten Vissers , Sudheer Dharanikota , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Mike, I agree with most of what you said. I think the forwarding adjacency is more similar to the serial composed link connections (or serial compound links) than to support from a trail. There is no requirement for forwarding adjacencies to relate to trails (at least I don't think so). And yes, I fully agree that the inter-layer piece is the interesting piece. I believe Maarten has presented this in several places as the network engineering function (what you called the "local matter") as subject to policy control (very operator business model dependent). As for the hierarchy and the layer model, I think the hierarchical model of MPLS is more atuned to the sub-network partition (and sub-network recursion) which is within a layer. I'm not sure that the hierarchy was defined for layer network (although I don't see why it can't apply either). Now in terms of the layer model itself, I think (as I said many times) that the problem is mainly in how people interpret the text in these documents. That is why (my little rambling again) I think we need to add text to clarify some of these concepts...people don't seem to want to add clarifying text though...sigh... Zhi mike.sexton@alcatel.co.uk wrote: > > Maarten, > > In the interests of reconciliation consider the following: > > ASON and G-MPLS are both post hoc conceptual models describing the > same physical and logical network. The objectives of automation > through signalling are broadly similar. Therefore it would be > surprising indeed if the solutions were widely different. ASON is > indeed based on the layered model of G.805 and deals with layering > issues up-front. GMPLS is derived from the Internet model which > regards the physical layer as flat. When real world layering is > encountered it is dealt with by refinements many of which appear in > draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source > documents from which G-MPLS inherits. Here LSP regions are defined > in 6.2 which are as near as I can tell exactly equivalent to G.805 > layer networks. Further, precedence rules between layers are > established with the clear implication that a higher layer cannot > be configured until the appropriate resources in the lower layer > have been instantiated. The manner in which this may be done is > considered a "local matter". The example given indicates that a > Forwarding Adjacency (equivalent to a G.805 link supported by one > or more trails (LSPs) in the server layer) may be initiated in > various ways including from an external manager or another > (adjacent) LSR. Thus the example you gave of a VC-1x layer being > set up by signalling and VC-4 layer being set up by an external > planning/management is certainly a valid implementation within the > scope of the G-MPLS solution. By the same token it is undesirable > (and anyway will not be possible) to confine signalling to certain > layers while reserving others for management through a standard. > Operators will want to make such important architectural choices on > the basis of optimising their own operation. Once you have agreed > on a signalling protocol to create connections within a layer > network it is generically applicable to any layer network. Of > course making such an implementation choice (ie management for > VC-4, signalling for VC-1x) is an example of the "local policies" > mentioned above. Such choices frequently appear as part of some > sort of application specific profile or applications framework on > top of the base generic standard. Note this sort of profiling (if > that is the correct term) is generally needed to ensure > interworking amongst elements which implement the same generic > standard. > > On the last occasion that we studied application of signalling for > transport networks in ITU (over 10 years ago at the time G.805 was > first issued) we had concluded that connection set-up within a > layer was the easy part ie there were several well established > candidates to choose from (B-ISUP was the favorite. Neither PNNI > nor RSVP existed at that time. ISIS had already been adopted for > DCN in SDH and thus provided basic neighbour discovery and xSPF > computation if required). The major new problem to resolve for > multi-layer transport networks was indeed considered to be the > desired behaviour at inter-layer boundaries. It seems that both > initiatives have sidelined this issue as out of scope for the time > being. > > regards, > > Mike Sexton > > > > > > > > Maarten Vissers on 25/10/2001 06:03:38 > > > > To: Sudheer Dharanikota > > cc: ccamp@ops.ietf.org(bcc: Michael J SEXTON/GB/ALCATEL) > > > > > Subject: Re: Moving right along ... > > > > > > > Sudheer, > > Another issue is ... > > - ASON is layer network based, GMPLS is not > > i.e. a request for a connection within ASON is treated within the > boundaries of one layer network (e.g. within the boundaries of a > VT1.5/VC-11 layer network, or within the boundaries of a > STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is > processed within the VT1.5/VC-11 layer network, using existing VT1.5/VC-11 > links (GMPLS: link bundles). If there is not enough capacity in > the VT1.5/VC-11 links to support the request, the call fails. There > is no "hidden" set up of a STS-1 or VC-4 trail supporting an > additional VT/LOVC link or extending an existing VT/LOVC link. The > set up of an additional STS-1 or VC-4 trail is supported within the > scope of network planning and/or network engineering. This is > separated from the connection set up. > > Regards, > > Maarten > > Sudheer Dharanikota wrote: > >> Hi Maarten: >> >> Maarten Vissers wrote: >> >> >>> Sudheer, >>> >>> At the moment I am unable to briefly summarize the differences >>> between GMPLS and ASON. I was working from the perception that >>> GMPLS could be one of the protocols supporting ASON. The >>> technical comments I made during the last 10 months were based >>> on this perception. Also the last comment describing the >>> concept of serial compound link had this basis. Reading Yanhe's >>> reply I had the impression that GMPLS is able to support >>> serial compound links, but reading Eric's reply I got the >>> opposite impression. Furthermore being very surprised by Eric's >>> reaction on a pure technical issue, I composed a few >>> challenging words to attrack more people to participate in the >>> discussion... :-) >>> >> I see one of the issue here being ... >> >> - Does GMPLS support serial compound links? >> >> Let us enumerate few more questions and move the discussion to a >> technical level again, we need participation especially from the >> folks who are involved in ASON architecture work. >> >> >>> Being impressed by the few hundred people attending the last >>> ccamp sessions in London, I am surprised by the low percentage >>> of those people being actively contributing to the >>> correspondence. It can't be the case that only a handful of people >>> have an opinion on these matters... and I believe the >>> discussions would stay technical if more people express their >>> opinion... there would not be a yes/no game between just a few >>> people. >>> >>> >> I thought this is how most of the standards meetings work. 5 % >> work, 95 % try to gather industry intelligence ( :-) ) either by >> attending IETF or by following >> >> the mailing list. >> >> >>> With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it >>> will be possible to start an evaluation of GMPLS as a specific >>> protocol for ASON. As indicated in a previous email from Steve >>> Trowbridge, ITU-T will make those ASON documents available to >>> IETF so we can jointly work this evaluation. >>> >>> >> Most of these documents are available on the t1x1 site. But what >> we need here is the "delta" that is missing between ASON >> architecture and the view of GMPLS architecture. Can you help us >> with this? We may start with a short list... >> >> >>> The approval of the current ASON recommendations is just a first >>> step within the larger ASON task. Work is started on other >>> elements of ASON (G.rtg (routing), G.lm (link management) and >>> pnni based specific protocol as an implementation of the >>> protocol neutral specification in G.7713)), discussions are >>> started identifying further ASON elements, and work to extend >>> G.8080 is planned to start after this SG15 meeting. >>> >>> >> Obviously GMPLS is a potential candidate to solve the ASON issues. >> It may be ahead of its time as far as ITU and ANSI are >> concerned. So let us ammend or modify it to the ITU view on the >> transport control plane. >> >> Regards, >> >> sudheer >> >> >>> Up to so far... {time to shut down my computer and go to the >>> concert hall in Geneva... time to relax after a week and a half >>> of hectic work over here...} >>> >>> Regards, >>> >>> Maarten >>> >>> Sudheer Dharanikota wrote: >>> >>>> Hi Marteen: >>>> >>>> Can you briefly summarize the differences you see between GMPLS >>>> architecture and ASON architecture? This has been asked by >>>> many of the folks at IETF. >>>> >>>> Regards, >>>> >>>> sudheer >>>> >>>> PS: I thought these mails were about label format and suddenly this >>>> is turning into an ITU versus IETF discussion :-( >>>> >>>> Part 1.1 >>>> >>>> Content-Type: >>>> >>>> text/plain >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> mvissers.vcf >>>> >>>> Content-Type: >>>> >>>> application/octet-stream Content-Encoding: >>>> >>>> base64 >>>> >>>> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 03:49:06 -0700 Message-ID: From: neil.2.harrison@bt.com To: mike.sexton@alcatel.co.uk, mvissers@lucent.com Cc: sudheer@nayna.com, ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 25 Oct 2001 11:47:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Mike.....nice to hear from you and I think you make some good points. However, I want to pick-up on one aspect you bring up a few times....and that is 'choice'. Operators need choice to suit their views on what is/is-not a viable business case. For example, we have various client layer networks besides IP to accommodate, and of particular importance are managed BW services directly off the L1 fabric, eg VC4 or lambdas say. However, we can't see any valid business case for generalised BoD/SVCs services here.....I mean, given unknown calling/holding statistics just what capacity would one need to build to to offer a GoS that customers would consider acceptable and that you could get past finance/products people (esp given current climate)? So, on assumption that S-PVC-like services are all that is commercailly viable (in our opinion at least) then you can ask yourself just what additional revenues and/or Opex cost reductions are available from implementating a control-plane solution? Even this is difficult to justify given: - current NMS approaches (in SDH) can easily cater for current and foreseeable core trail churn rates; - the big costs are in access and laying ducts and installing physicals....no control-plane solution is going to impact these. However, assuming you do decide you want to implement a control-plane solution in your transport networks then you really ought to be able to choose the addressing, signalling and routing components on a best-of-breed basis to suit what you want to do. They are after all, quite disjoint components and there are many architectural possibilities.......and this is what ASON is all about....choice. For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling aspects only) + centralised routing approach looks the best commercially for what we want to do. Others may argue that the current GMPLS approach suits them best. ASON allows this choice. regards, Neil > -----Original Message----- > From: mike.sexton@alcatel.co.uk [mailto:mike.sexton@alcatel.co.uk] > Sent: 25 October 2001 11:49 > To: Maarten Vissers > Cc: Sudheer Dharanikota; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > > > > Maarten, > > In the interests of reconciliation consider the following: > > ASON and G-MPLS are both post hoc conceptual models > describing the same physical and logical network. The > objectives of automation through signalling are broadly > similar. Therefore it would be surprising indeed if the > solutions were widely different. ASON > is indeed based on the layered model of G.805 and deals with > layering issues up-front. GMPLS is derived from the Internet > model which regards the physical layer as flat. When real > world layering is encountered it is dealt with by refinements > many of which > appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one > of the source documents from which G-MPLS inherits. Here LSP > regions are defined in 6.2 which are as near as I can tell > exactly equivalent to G.805 layer networks. Further, precedence rules > between layers are established with the clear implication > that a higher layer cannot be configured until the > appropriate resources in the lower layer have been > instantiated. The manner in which this may be done is > considered a "local matter". The example > given indicates that a Forwarding Adjacency (equivalent to a > G.805 link supported by one or more trails (LSPs) in the > server layer) may be initiated in various ways including from > an external manager or another (adjacent) LSR. Thus the > example you gave of > a VC-1x layer being set up by signalling and VC-4 layer being > set up by an external planning/management is certainly a > valid implementation within the scope of the G-MPLS solution. > By the same token it is undesirable (and anyway will not be > possible) to > confine signalling to certain layers while reserving others > for management through a standard. Operators will want to > make such important architectural choices on the basis of > optimising their own operation. Once you have agreed on a > signalling protocol to > create connections within a layer network it is generically > applicable to any layer network. Of course making such an > implementation choice (ie management for VC-4, signalling for > VC-1x) is an example of the "local policies" mentioned above. > Such choices > frequently appear as part of some sort of application > specific profile or applications framework on top of the base > generic standard. Note this sort of profiling (if that is the > correct term) is > generally needed to ensure interworking amongst elements > which implement the same generic standard. > > On the last occasion that we studied application of > signalling for transport networks in ITU (over 10 years ago > at the time G.805 was first issued) we had concluded that > connection set-up within a layer was the easy part ie there > were several well > established candidates to choose from (B-ISUP was the > favorite. Neither PNNI nor RSVP existed at that time. ISIS > had already been adopted for DCN in SDH and thus provided > basic neighbour discovery and xSPF computation if required). > The major new problem to > resolve for multi-layer transport networks was indeed > considered to be the desired behaviour at inter-layer > boundaries. It seems that both initiatives have sidelined > this issue as out of scope for the time being. > > regards, > > Mike Sexton > > > > > > > > Maarten Vissers on 25/10/2001 06:03:38 > > > > To: Sudheer Dharanikota > > cc: ccamp@ops.ietf.org(bcc: Michael J > SEXTON/GB/ALCATEL) > > > > Subject: Re: Moving right along ... > > > > > > > Sudheer, > > Another issue is ... > > - ASON is layer network based, GMPLS is not > > i.e. a request for a connection within ASON is treated within > the boundaries of > one layer network (e.g. within the boundaries of a > VT1.5/VC-11 layer network, or > within the boundaries of a STS-3c/VC-4 layer network). A > VT1.5/VC-11 connection > request is processed within the VT1.5/VC-11 layer network, > using existing > VT1.5/VC-11 links (GMPLS: link bundles). If there is not > enough capacity in the > VT1.5/VC-11 links to support the request, the call fails. > There is no "hidden" > set up of a STS-1 or VC-4 trail supporting an additional > VT/LOVC link or > extending an existing VT/LOVC link. The set up of an > additional STS-1 or VC-4 > trail is supported within the scope of network planning and/or network > engineering. This is separated from the connection set up. > > Regards, > > Maarten > > Sudheer Dharanikota wrote: > > > > Hi Maarten: > > > > Maarten Vissers wrote: > > > > > Sudheer, > > > > > > At the moment I am unable to briefly summarize the > differences between GMPLS and > > > ASON. I was working from the perception that GMPLS could > be one of the protocols > > > supporting ASON. The technical comments I made during the > last 10 months were > > > based on this perception. Also the last comment > describing the concept of serial > > > compound link had this basis. Reading Yanhe's reply I had > the impression that > > > GMPLS is able to support serial compound links, but > reading Eric's reply I got > > > the opposite impression. Furthermore being very surprised > by Eric's reaction on > > > a pure technical issue, I composed a few challenging > words to attrack more > > > people to participate in the discussion... :-) > > > > I see one of the issue here being ... > > > > - Does GMPLS support serial compound links? > > > > Let us enumerate few more questions and move the discussion > to a technical > > level again, we need participation especially from the > folks who are involved > > in ASON architecture work. > > > > > > > > Being impressed by the few hundred people attending the > last ccamp sessions in > > > London, I am surprised by the low percentage of those > people being actively > > > contributing to the correspondence. It can't be the case > that only a handful of > > > people have an opinion on these matters... and I believe > the discussions would > > > stay technical if more people express their opinion... > there would not be a > > > yes/no game between just a few people. > > > > > > > I thought this is how most of the standards meetings work. > 5 % work, 95 % > > try to gather industry intelligence ( :-) ) either by > attending IETF or by following > > > > the mailing list. > > > > > > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available > it will be possible to > > > start an evaluation of GMPLS as a specific protocol for > ASON. As indicated in a > > > previous email from Steve Trowbridge, ITU-T will make > those ASON documents > > > available to IETF so we can jointly work this evaluation. > > > > > > > Most of these documents are available on the t1x1 site. But > what we need here is > > the "delta" that is missing between ASON architecture and > the view of GMPLS > > architecture. Can you help us with this? We may start with > a short list... > > > > > > > > The approval of the current ASON recommendations is just > a first step within the > > > larger ASON task. Work is started on other elements of > ASON (G.rtg (routing), > > > G.lm (link management) and pnni based specific protocol > as an implementation of > > > the protocol neutral specification in G.7713)), > discussions are started > > > identifying further ASON elements, and work to extend > G.8080 is planned to start > > > after this SG15 meeting. > > > > > > > Obviously GMPLS is a potential candidate to solve the ASON > issues. It may be > > ahead of its time as far as ITU and ANSI are concerned. So > let us ammend or > > modify it to the ITU view on the transport control plane. > > > > Regards, > > > > sudheer > > > > > > > > Up to so far... {time to shut down my computer and go to > the concert hall in > > > Geneva... time to relax after a week and a half of hectic > work over here...} > > > > > > Regards, > > > > > > Maarten > > > > > > Sudheer Dharanikota wrote: > > > > > > > > Hi Marteen: > > > > > > > > Can you briefly summarize the differences you see between > > > > GMPLS architecture and ASON architecture? This has been > > > > asked by many of the folks at IETF. > > > > > > > > Regards, > > > > > > > > sudheer > > > > > > > > PS: I thought these mails were about label format and suddenly > > > > this is turning into an ITU versus IETF discussion :-( > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 03:03:01 -0700 From: mike.sexton@alcatel.co.uk To: Maarten Vissers cc: Sudheer Dharanikota , ccamp@ops.ietf.org Message-ID: <80256AF0.0035E8CC.00@gbmta001.netfr.alcatel.fr> Date: Thu, 25 Oct 2001 11:48:46 +0100 Subject: Re: Moving right along ... Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU" Content-Disposition: inline --0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU Content-type: text/plain; charset=us-ascii Content-Disposition: inline Maarten, In the interests of reconciliation consider the following: ASON and G-MPLS are both post hoc conceptual models describing the same physical and logical network. The objectives of automation through signalling are broadly similar. Therefore it would be surprising indeed if the solutions were widely different. ASON is indeed based on the layered model of G.805 and deals with layering issues up-front. GMPLS is derived from the Internet model which regards the physical layer as flat. When real world layering is encountered it is dealt with by refinements many of which appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source documents from which G-MPLS inherits. Here LSP regions are defined in 6.2 which are as near as I can tell exactly equivalent to G.805 layer networks. Further, precedence rules between layers are established with the clear implication that a higher layer cannot be configured until the appropriate resources in the lower layer have been instantiated. The manner in which this may be done is considered a "local matter". The example given indicates that a Forwarding Adjacency (equivalent to a G.805 link supported by one or more trails (LSPs) in the server layer) may be initiated in various ways including from an external manager or another (adjacent) LSR. Thus the example you gave of a VC-1x layer being set up by signalling and VC-4 layer being set up by an external planning/management is certainly a valid implementation within the scope of the G-MPLS solution. By the same token it is undesirable (and anyway will not be possible) to confine signalling to certain layers while reserving others for management through a standard. Operators will want to make such important architectural choices on the basis of optimising their own operation. Once you have agreed on a signalling protocol to create connections within a layer network it is generically applicable to any layer network. Of course making such an implementation choice (ie management for VC-4, signalling for VC-1x) is an example of the "local policies" mentioned above. Such choices frequently appear as part of some sort of application specific profile or applications framework on top of the base generic standard. Note this sort of profiling (if that is the correct term) is generally needed to ensure interworking amongst elements which implement the same generic standard. On the last occasion that we studied application of signalling for transport networks in ITU (over 10 years ago at the time G.805 was first issued) we had concluded that connection set-up within a layer was the easy part ie there were several well established candidates to choose from (B-ISUP was the favorite. Neither PNNI nor RSVP existed at that time. ISIS had already been adopted for DCN in SDH and thus provided basic neighbour discovery and xSPF computation if required). The major new problem to resolve for multi-layer transport networks was indeed considered to be the desired behaviour at inter-layer boundaries. It seems that both initiatives have sidelined this issue as out of scope for the time being. regards, Mike Sexton Maarten Vissers on 25/10/2001 06:03:38 To: Sudheer Dharanikota cc: ccamp@ops.ietf.org(bcc: Michael J SEXTON/GB/ALCATEL) Subject: Re: Moving right along ... Sudheer, Another issue is ... - ASON is layer network based, GMPLS is not i.e. a request for a connection within ASON is treated within the boundaries of one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer network, or within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is processed within the VT1.5/VC-11 layer network, using existing VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity in the VT1.5/VC-11 links to support the request, the call fails. There is no "hidden" set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or extending an existing VT/LOVC link. The set up of an additional STS-1 or VC-4 trail is supported within the scope of network planning and/or network engineering. This is separated from the connection set up. Regards, Maarten Sudheer Dharanikota wrote: > > Hi Maarten: > > Maarten Vissers wrote: > > > Sudheer, > > > > At the moment I am unable to briefly summarize the differences between GMPLS and > > ASON. I was working from the perception that GMPLS could be one of the protocols > > supporting ASON. The technical comments I made during the last 10 months were > > based on this perception. Also the last comment describing the concept of serial > > compound link had this basis. Reading Yanhe's reply I had the impression that > > GMPLS is able to support serial compound links, but reading Eric's reply I got > > the opposite impression. Furthermore being very surprised by Eric's reaction on > > a pure technical issue, I composed a few challenging words to attrack more > > people to participate in the discussion... :-) > > I see one of the issue here being ... > > - Does GMPLS support serial compound links? > > Let us enumerate few more questions and move the discussion to a technical > level again, we need participation especially from the folks who are involved > in ASON architecture work. > > > > > Being impressed by the few hundred people attending the last ccamp sessions in > > London, I am surprised by the low percentage of those people being actively > > contributing to the correspondence. It can't be the case that only a handful of > > people have an opinion on these matters... and I believe the discussions would > > stay technical if more people express their opinion... there would not be a > > yes/no game between just a few people. > > > > I thought this is how most of the standards meetings work. 5 % work, 95 % > try to gather industry intelligence ( :-) ) either by attending IETF or by following > > the mailing list. > > > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to > > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a > > previous email from Steve Trowbridge, ITU-T will make those ASON documents > > available to IETF so we can jointly work this evaluation. > > > > Most of these documents are available on the t1x1 site. But what we need here is > the "delta" that is missing between ASON architecture and the view of GMPLS > architecture. Can you help us with this? We may start with a short list... > > > > > The approval of the current ASON recommendations is just a first step within the > > larger ASON task. Work is started on other elements of ASON (G.rtg (routing), > > G.lm (link management) and pnni based specific protocol as an implementation of > > the protocol neutral specification in G.7713)), discussions are started > > identifying further ASON elements, and work to extend G.8080 is planned to start > > after this SG15 meeting. > > > > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be > ahead of its time as far as ITU and ANSI are concerned. So let us ammend or > modify it to the ITU view on the transport control plane. > > Regards, > > sudheer > > > > > Up to so far... {time to shut down my computer and go to the concert hall in > > Geneva... time to relax after a week and a half of hectic work over here...} > > > > Regards, > > > > Maarten > > > > Sudheer Dharanikota wrote: > > > > > > Hi Marteen: > > > > > > Can you briefly summarize the differences you see between > > > GMPLS architecture and ASON architecture? This has been > > > asked by many of the folks at IETF. > > > > > > Regards, > > > > > > sudheer > > > > > > PS: I thought these mails were about label format and suddenly > > > this is turning into an ITU versus IETF discussion :-( --0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU Content-type: application/octet-stream; name="mvissers.vcf" Content-Disposition: attachment; filename="mvissers.vcf" Content-transfer-encoding: base64 YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1 DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7 d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K --0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 00:21:41 -0700 Message-ID: <3BD7BBAD.1080200@lucent.com> Date: Thu, 25 Oct 2001 03:13:49 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Sudheer Dharanikota CC: Maarten Vissers , ccamp@ops.ietf.org, q12/15 , q14/15 Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, I tried answering some of your questions in another email, so I will put some short answers to this email...below... Sudheer Dharanikota wrote: > Hi Maarten: > > > Maarten Vissers wrote: > > >>Sudheer, >> >>At the moment I am unable to briefly summarize the differences between GMPLS and >>ASON. I was working from the perception that GMPLS could be one of the protocols >>supporting ASON. The technical comments I made during the last 10 months were >>based on this perception. Also the last comment describing the concept of serial >>compound link had this basis. Reading Yanhe's reply I had the impression that >>GMPLS is able to support serial compound links, but reading Eric's reply I got >>the opposite impression. Furthermore being very surprised by Eric's reaction on >>a pure technical issue, I composed a few challenging words to attrack more >>people to participate in the discussion... :-) >> > > I see one of the issue here being ... > > - Does GMPLS support serial compound links? > > Let us enumerate few more questions and move the discussion to a technical > level again, we need participation especially from the folks who are involved > in ASON architecture work. > > This is where I keep suggesting that we put in clarifying text. I showed an example a few emails back about "A-B-C" configuration where B is not GMPLS aware. I want to bring out the point that the text in GMPLS is not clear about whether or not this is supported. I believe GMPLS can support serial compound links, but we need to describe in the text properly (or more clearly) so that people are aware of this, instead of simply saying that "it is obvious to the informed reader". I think our goal should be to make it as readable as possible to the larger audience, not just a few people who has followed the mailing list. I keep getting reminded of how specific BGP documents are and how much information on BGP is actually not specified anywhere that is actually needed in order for it to work properly...this seems a little "elitist" to me...please don't flame me...:-) >>Being impressed by the few hundred people attending the last ccamp sessions in >>London, I am surprised by the low percentage of those people being actively >>contributing to the correspondence. It can't be the case that only a handful of >>people have an opinion on these matters... and I believe the discussions would >>stay technical if more people express their opinion... there would not be a >>yes/no game between just a few people. >> >> > > I thought this is how most of the standards meetings work. 5 % work, 95 % > try to gather industry intelligence ( :-) ) either by attending IETF or by following > > the mailing list. > > :-) >>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to >>start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a >>previous email from Steve Trowbridge, ITU-T will make those ASON documents >>available to IETF so we can jointly work this evaluation. >> >> > > Most of these documents are available on the t1x1 site. But what we need here is > the "delta" that is missing between ASON architecture and the view of GMPLS > architecture. Can you help us with this? We may start with a short list... > > Well, let's see, I don't think anybody as really gone through the details of it yet. I would be very interested if anybody out there have done this already >>The approval of the current ASON recommendations is just a first step within the >>larger ASON task. Work is started on other elements of ASON (G.rtg (routing), >>G.lm (link management) and pnni based specific protocol as an implementation of >>the protocol neutral specification in G.7713)), discussions are started >>identifying further ASON elements, and work to extend G.8080 is planned to start >>after this SG15 meeting. >> >> > > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be > ahead of its time as far as ITU and ANSI are concerned. So let us ammend or > modify it to the ITU view on the transport control plane. > I agree GMPLS is definitely a candidate. That is why I don't understand some people's mentality of "ITU against/versus IETF". I think they are complementary. The architecture experts are in ITU (at least some experts) and the protocol experts are in IETF (again, at least some experts). In terms of ahead of its times...don't know about that...depends on your timeframe...1 month? 1 year? 10 years? 1 week? :-) > Regards, > > sudheer > > >>Up to so far... {time to shut down my computer and go to the concert hall in >>Geneva... time to relax after a week and a half of hectic work over here...} >> >>Regards, >> >>Maarten >> >>Sudheer Dharanikota wrote: >> >>>Hi Marteen: >>> >>>Can you briefly summarize the differences you see between >>>GMPLS architecture and ASON architecture? This has been >>>asked by many of the folks at IETF. >>> >>>Regards, >>> >>>sudheer >>> >>>PS: I thought these mails were about label format and suddenly >>>this is turning into an ITU versus IETF discussion :-( >>> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Oct 2001 00:00:30 -0700 Message-ID: <3BD7B829.1030907@lucent.com> Date: Thu, 25 Oct 2001 02:58:49 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Sudheer Dharanikota CC: Irfan Lateef , kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, OK I'll try to highlight some. I think Maarten mentioned one already: -- ASON is based on a separation of layer network. Not only that, ASON is also based on separation of functional roles of the switched network. ASON defines the architecture of the switched network in terms of the interactions of different components. Components defined by ASON performs specific tasks: --Call controller (CallC) is the "service" component that interfaces with the user to support service requests. I believe this can be viewed as been handled by the OIF UNI specification, which provides the user to network request capability --Connection controller (CC) is the network component that supports the connection operations, which includes setup and release of individual links (ITU: link connections) in support of the user request. A set of connection controllers are involved on a sub-network (area of AS) basis to set up/release connections within its domain of responsibility, and interacts with other CC in different ways depending on how the operator configures the interactions. Methods of interaction include a joint federation model and a cooperative federation model. CC is I think what GMPLS is about, in terms of setting up and releasing/tearing down connections. --Link resource manager is the network component that assigns a link (ITU: link connection) from a link bundle/TE-link (ITU: link). Thus the progression of signaling goes from CC which receives requests for connections to LRM which chooses a link, and provides the CC with the requested link information so that CC can set up a sub-network connection (a connection across a sub-network). Note that sub-network connection "concept" is a recursive definition where the limit of recursion of a sub-network connection is the fabric connection. The LRM from GMPLS perspective is subsumed into the CC (this is where the label negotiation takes place). --Routing controller (RC) is the network component that provides the routing information, including route dissemination, route determination, route table update, etc. Three models of routing has been defined: hierarchical, source-based and step-by-step. As part of the routing definition, a "routing area" is defined to support multi-level/hierarchical routing domains. This is very similar (maybe identical?) to the OSPF/BGP separation of roles. NOTE that these are all logical components (what ITU calls a computational view of the control plane), with certain distribution assumed (what ITU calls an engineering view of the control plane). Different implementations of these components may have, e.g., CallC, CC and LRM all in one "box" while another implementation may have CallC in one box and CC, LRM and RC in another box. However, the functionality is equivalant. Only difference is in terms of which interfaces have been exposed and becomes external (that is standardizable). Now to how different or similar is ASON/G.dcm with GMPLS. In terms of the information mapping and message mapping between them, I would say they are very close to each other. For example, when ASON/G.dcm discusses setup/release operations, it views the transport resources as an "abstract" entity called SNP (subnetwork point). If you are familiar with management objects, the SNP is very similar to SNTP (subnetwork termination point). Where SNTP provides the management system with a view of the underlying transport resources (CTP or TTP or simply TP), the SNP provides the control plane with a view of the underlying transport resources. As such these SNP and SNPP (SNP pools which is an aggregation of the SNPs into a logical "bundle" based on some policy or provisioned constraints) is used in setting up a connection. The SNP/SNPP provides an abstraction barrier between physical resources and logical resources and is provided on a layer basis (i.e., SNP ID information for a STS-1 layer is independent of the SNP ID information for a STS-3c layer is independent of the SNP ID information for a ODU1 layer). The other difference is that ASON/G.dcm deals with abstract "names" in terms of specifying relevant endpoints. This is simply a "protocol neutral" aspect of addresses used in GMPLS, where GMPLS assumes IPv4 and IPv6, G.dcm does not assume any addressing scheme. This is not inconsistent, only different levels of specification. One of the "names" defined in ASON/G.dcm is a "call name" which is a reference to the call. IETF GMPLS I believe "sort-of" supports this. Call name is essentially a globally unique identifier that identifies the call. IETF GMPLS also provides a globally unique identifier in the form of SESSION and SENDER_TEMPLATE (for RSVP-TE). There are also capabilities described in GMPLS that is currently not specified by the ASON/G.dcm. This includes the capabilities supported by the Admin_Status object (turning on/off monitoring), and the multiplier parameter within the SONET/SDH SENDER_TSPEC/FLOWSPEC object. For example, many of the parameters that support the SONET/SDH connection (such as what signal type, encoding type, NCC, NVC) are implied information in ASON/G.dcm since they are layer information. These parameters in GMPLS may be thought of as an implementation of the layer information for the specific protocol. GMPLS RSVP-TE is a soft-state protocol, CR-LDP is more a hard-state protocol. ASON/G.dcm does not specify whether the protocol needs to be soft-state or hard-state. It discusses what are the behaviours and how these "systems" may recover from problems. It also provides a high-level state transition diagram on the operation of the signaling mechanism. From this viewpoint, I also don't see too much inconsistency. Of course, I haven't done any analysis/comparison. If anyone is interested doing this it let me know! The first stage of the ITU specification for the ASON work is nearing completion. The next stage is to start work on the protocol specific implementations of the ASON model. At the current ITU meeting, we already have United Kingdom (presented by British Telecom) bring in contribution requesting to use PNNI as A protocol for supporting ASON. This was also supported by other carriers. The ITU has now opened the floor to any other protocols to be submitted as well. So if people want to see GMPLS considered as one of the protocols for ASON, someone needs to submit this to the ITU. Currently the decision is that if any protocols meets the requirements outlined in ASON and G.dcm, then they will be considered (i.e., any protocol). There were some interest shown in the meeting to bringing in GMPLS. Well, I hope this provides enough of a summary to help the discussions along. Zhi Sudheer Dharanikota wrote: > Hi Zhi: > > Zhi-Wei Lin wrote: > > >> From what I understand G.ason and G.dcm is developed to describe the >>process and the minimal requirements needed to support a basic switched >>transport service. GMPLS is a protocol specific implementation that will >>likely meet many of the requirements, and may have some minor areas that >>it does not meet. Then the question to ask (as with any requirements and >>architecture work -- I'm sure we all have architects in our company) is: >>how critical are the requirements that may not be met and what changes >>are needed to GMPLS (if any) in order to meet them? >> >> > > It may be a good idea to explain where GMPLS is lacking in meeting ASON > and DCM requirements. YOu, being involved in this process, is the best > person to articulate the major drawbacks. WHy don't you spend a minute in > higlighting them. > > THese discussions are becoming highly non-technical and unproductive. Let us > streamline our energy to a common cause - find the enhancements needed to > accomodate ASON architecture. > > Regards, > > sudheer > > >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 22:10:13 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3BD79D2A.8DD0F8FA@lucent.com> Date: Thu, 25 Oct 2001 07:03:38 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Sudheer Dharanikota Original-CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------9156D9B97ADC3B13F978BCD8" This is a multi-part message in MIME format. --------------9156D9B97ADC3B13F978BCD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sudheer, Another issue is ... - ASON is layer network based, GMPLS is not i.e. a request for a connection within ASON is treated within the boundaries of one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer network, or within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is processed within the VT1.5/VC-11 layer network, using existing VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity in the VT1.5/VC-11 links to support the request, the call fails. There is no "hidden" set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or extending an existing VT/LOVC link. The set up of an additional STS-1 or VC-4 trail is supported within the scope of network planning and/or network engineering. This is separated from the connection set up. Regards, Maarten Sudheer Dharanikota wrote: > > Hi Maarten: > > Maarten Vissers wrote: > > > Sudheer, > > > > At the moment I am unable to briefly summarize the differences between GMPLS and > > ASON. I was working from the perception that GMPLS could be one of the protocols > > supporting ASON. The technical comments I made during the last 10 months were > > based on this perception. Also the last comment describing the concept of serial > > compound link had this basis. Reading Yanhe's reply I had the impression that > > GMPLS is able to support serial compound links, but reading Eric's reply I got > > the opposite impression. Furthermore being very surprised by Eric's reaction on > > a pure technical issue, I composed a few challenging words to attrack more > > people to participate in the discussion... :-) > > I see one of the issue here being ... > > - Does GMPLS support serial compound links? > > Let us enumerate few more questions and move the discussion to a technical > level again, we need participation especially from the folks who are involved > in ASON architecture work. > > > > > Being impressed by the few hundred people attending the last ccamp sessions in > > London, I am surprised by the low percentage of those people being actively > > contributing to the correspondence. It can't be the case that only a handful of > > people have an opinion on these matters... and I believe the discussions would > > stay technical if more people express their opinion... there would not be a > > yes/no game between just a few people. > > > > I thought this is how most of the standards meetings work. 5 % work, 95 % > try to gather industry intelligence ( :-) ) either by attending IETF or by following > > the mailing list. > > > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to > > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a > > previous email from Steve Trowbridge, ITU-T will make those ASON documents > > available to IETF so we can jointly work this evaluation. > > > > Most of these documents are available on the t1x1 site. But what we need here is > the "delta" that is missing between ASON architecture and the view of GMPLS > architecture. Can you help us with this? We may start with a short list... > > > > > The approval of the current ASON recommendations is just a first step within the > > larger ASON task. Work is started on other elements of ASON (G.rtg (routing), > > G.lm (link management) and pnni based specific protocol as an implementation of > > the protocol neutral specification in G.7713)), discussions are started > > identifying further ASON elements, and work to extend G.8080 is planned to start > > after this SG15 meeting. > > > > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be > ahead of its time as far as ITU and ANSI are concerned. So let us ammend or > modify it to the ITU view on the transport control plane. > > Regards, > > sudheer > > > > > Up to so far... {time to shut down my computer and go to the concert hall in > > Geneva... time to relax after a week and a half of hectic work over here...} > > > > Regards, > > > > Maarten > > > > Sudheer Dharanikota wrote: > > > > > > Hi Marteen: > > > > > > Can you briefly summarize the differences you see between > > > GMPLS architecture and ASON architecture? This has been > > > asked by many of the folks at IETF. > > > > > > Regards, > > > > > > sudheer > > > > > > PS: I thought these mails were about label format and suddenly > > > this is turning into an ITU versus IETF discussion :-( --------------9156D9B97ADC3B13F978BCD8 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------9156D9B97ADC3B13F978BCD8-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 11:52:05 -0700 Message-ID: <3BD70CCA.F4F0806B@nayna.com> Date: Wed, 24 Oct 2001 11:47:38 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Maarten Vissers CC: ccamp@ops.ietf.org, q12/15 , q14/15 Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Maarten: Maarten Vissers wrote: > Sudheer, > > At the moment I am unable to briefly summarize the differences between GMPLS and > ASON. I was working from the perception that GMPLS could be one of the protocols > supporting ASON. The technical comments I made during the last 10 months were > based on this perception. Also the last comment describing the concept of serial > compound link had this basis. Reading Yanhe's reply I had the impression that > GMPLS is able to support serial compound links, but reading Eric's reply I got > the opposite impression. Furthermore being very surprised by Eric's reaction on > a pure technical issue, I composed a few challenging words to attrack more > people to participate in the discussion... :-) I see one of the issue here being ... - Does GMPLS support serial compound links? Let us enumerate few more questions and move the discussion to a technical level again, we need participation especially from the folks who are involved in ASON architecture work. > > Being impressed by the few hundred people attending the last ccamp sessions in > London, I am surprised by the low percentage of those people being actively > contributing to the correspondence. It can't be the case that only a handful of > people have an opinion on these matters... and I believe the discussions would > stay technical if more people express their opinion... there would not be a > yes/no game between just a few people. > I thought this is how most of the standards meetings work. 5 % work, 95 % try to gather industry intelligence ( :-) ) either by attending IETF or by following the mailing list. > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a > previous email from Steve Trowbridge, ITU-T will make those ASON documents > available to IETF so we can jointly work this evaluation. > Most of these documents are available on the t1x1 site. But what we need here is the "delta" that is missing between ASON architecture and the view of GMPLS architecture. Can you help us with this? We may start with a short list... > > The approval of the current ASON recommendations is just a first step within the > larger ASON task. Work is started on other elements of ASON (G.rtg (routing), > G.lm (link management) and pnni based specific protocol as an implementation of > the protocol neutral specification in G.7713)), discussions are started > identifying further ASON elements, and work to extend G.8080 is planned to start > after this SG15 meeting. > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be ahead of its time as far as ITU and ANSI are concerned. So let us ammend or modify it to the ITU view on the transport control plane. Regards, sudheer > > Up to so far... {time to shut down my computer and go to the concert hall in > Geneva... time to relax after a week and a half of hectic work over here...} > > Regards, > > Maarten > > Sudheer Dharanikota wrote: > > > > Hi Marteen: > > > > Can you briefly summarize the differences you see between > > GMPLS architecture and ASON architecture? This has been > > asked by many of the folks at IETF. > > > > Regards, > > > > sudheer > > > > PS: I thought these mails were about label format and suddenly > > this is turning into an ITU versus IETF discussion :-( Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 11:21:43 -0700 Message-ID: <3BD705F3.771BF52E@nayna.com> Date: Wed, 24 Oct 2001 11:18:27 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Zhi-Wei Lin CC: Irfan Lateef , kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi: Zhi-Wei Lin wrote: > > From what I understand G.ason and G.dcm is developed to describe the > process and the minimal requirements needed to support a basic switched > transport service. GMPLS is a protocol specific implementation that will > likely meet many of the requirements, and may have some minor areas that > it does not meet. Then the question to ask (as with any requirements and > architecture work -- I'm sure we all have architects in our company) is: > how critical are the requirements that may not be met and what changes > are needed to GMPLS (if any) in order to meet them? > It may be a good idea to explain where GMPLS is lacking in meeting ASON and DCM requirements. YOu, being involved in this process, is the best person to articulate the major drawbacks. WHy don't you spend a minute in higlighting them. THese discussions are becoming highly non-technical and unproductive. Let us streamline our energy to a common cause - find the enhancements needed to accomodate ASON architecture. Regards, sudheer > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 11:14:18 -0700 content-class: urn:content-classes:message Subject: RE: Questions about draft-ietf-ccamp-lmp-mib-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2001 14:08:32 -0400 Message-ID: Thread-Topic: Questions about draft-ietf-ccamp-lmp-mib-00.txt Thread-Index: AcFcpaZeqgRAaJUcRqikdU/p2FGENAAECX5w From: "Martin Dubuc" To: "Fugui Wang" Cc: , , , , Fugui, The lmpRemoteTeLinkId and lmpRemoteTeLinkType was removed from the latest LMP MIB because it was redundant with information stored in the link bundling MIB (see http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt). The link bundling MIB contains a TE link table (teLinkTable) which captures the information you are looking for. The remote TE link type is found in the teLinkNumberingType object and the remote TE link identifier is either teLinkRemoteIpAddr or teLinkIncomingIfId depending on whether or not the TE link is numbered or unnumbered. Regards, Martin -----Original Message----- From: Fugui Wang [mailto:fwang@axiowave.com] Sent: Wednesday, October 24, 2001 12:08 PM To: Martin Dubuc; 'sudheer@nayna.com'; 'tnadeau@cisco.com'; 'jplang@calient.net'; 'evan@calient.net' Cc: 'ccamp@ops.ietf.org' Subject: Questions about draft-ietf-ccamp-lmp-mib-00.txt I noticed that lmpRemoteTeLinkId and lmpRemoteTeLinkType were taken away from the TE Link Table in this version. Is there any special reason for that? In the latest LMP draft draft-ietf-ccamp-lmp-01.txt, when we do link verification or link summary, we still need the remote TE link ID infomation. Would you suggest that we store the remote TE link ID in other places instead of in the TE link Table? Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 11:14:10 -0700 Message-Id: <200110241812.f9OICX066352@merlot.juniper.net> To: Gopal Kailad cc: ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64355.1003947152.1@juniper.net> Date: Wed, 24 Oct 2001 11:12:33 -0700 From: Yakov Rekhter Gopal, [clipped...] > >>>>If a node supports PSC as well as TDM or LSC interfaces, it > >>>>might want to advertise different set of parameters in the > >>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM > >>>>LSPs which form bearer channels in transport networks. > >>>>Currently this is not possible. > >>>> > >>>>>Can you give us explicit examples as to why and what do > >>>>>you gain by giving different values for PSC, TDM ? > >>>>> > >>>>In case of PSC devices, it may be OK to remove state that > >>>>is not resynchronized at the end of the recovery period, >>>>and the recovery period advertised might reflect that. > >>>> > >>>> > >>>>But for LSPs in transport networks, one might want to > >>>>have a different recovery period to avoid any LSP from > >>>>going down because of recovery timer expiry. > >>>> > >>>There is no requirement for a node to advertise exactly the > >>>same Restart_Cap on all the interfaces. So, on PSC interfaces > >>>the node could advertise that it will remove the state that > >>>isn't syncronized at the end of the recovery period, while > >>>on the TDM interface precisely the same node could advertise > >>>that the LSPs would be kept even after the recovery time expires. > >>> > >>But to set up LSPs over TDM/LSC interfaces, the PSC interface > >>is going to be used for signaling - since control and data > >>planes are decoupled! So, how will this help? > >> > > > >Help with what ? You asserted that it "is not possible" for > >"a node that supports PSC as well as TDM and LSC interfaces.. > >to advertise different set of parameters in the RESTART_CAP > >object for data LSPs as opposed to SONET/WDM LSPs." > > > >I pointed out to you that your assertion is incorrect, as > >there is no requirement for a node to advertise exactly the > >same Restart_Cap on all of its interfaces. > > > I believe your assertion is misleading - If two nodes A and > B have multiple TDM/LSC links (with out of band signaling) > between them as well as a PSC link, (they are all unnumbered > interfaces), there will be only one Hello adjacency between > A and B, resulting in just one Restart_cap object advertised > in each direction. > > In that case, how can one advertise different values in the > Restart_cap object for TDM/LSC LSPs as opposed to data LSPs? > > Since there is only one adjacency, the suggestion above to > treat the node failure as control channel failure does not > work either, as the restarting node might want to get > resynchronized for data LSPs. > > I believe your assertion is possible only if all interfaces > are numbered. That is incorrect - what I described is possible if only the control channel is numbered (note that a control channel, just like any other link, could have multiple IP addresses assigned to it). > If so, this is a huge constraint - please > refer draft-ietf-ipo-carrier-requirements-00, sec 7.4. In the context of UNI the (multiple) IP addresses assigned to a control channel could be locally defined. As such it would meet the requirements of section 7.4 of the draft you mentioned. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 09:12:17 -0700 Message-ID: From: Fugui Wang To: "'martin.dubuc@edgeflow.com'" , "'sudheer@nayna.com'" , "'tnadeau@cisco.com'" , "'jplang@calient.net'" , "'evan@calient.net'" Cc: "'ccamp@ops.ietf.org'" Subject: Questions about draft-ietf-ccamp-lmp-mib-00.txt Date: Wed, 24 Oct 2001 12:07:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I noticed that lmpRemoteTeLinkId and lmpRemoteTeLinkType were taken away from the TE Link Table in this version. Is there any special reason for that? In the latest LMP draft draft-ietf-ccamp-lmp-01.txt, when we do link verification or link summary, we still need the remote TE link ID infomation. Would you suggest that we store the remote TE link ID in other places instead of in the TE link Table? Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 09:05:26 -0700 Cc: ccamp@ops.ietf.org, q12/15 , q14/15 Message-ID: <3BD6E562.18428419@lucent.com> Date: Wed, 24 Oct 2001 17:59:30 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Sudheer Dharanikota Original-CC: ccamp@ops.ietf.org, q12/15 , q14/15 Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------237325921DB8ED75897EC97C" This is a multi-part message in MIME format. --------------237325921DB8ED75897EC97C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sudheer, At the moment I am unable to briefly summarize the differences between GMPLS and ASON. I was working from the perception that GMPLS could be one of the protocols supporting ASON. The technical comments I made during the last 10 months were based on this perception. Also the last comment describing the concept of serial compound link had this basis. Reading Yanhe's reply I had the impression that GMPLS is able to support serial compound links, but reading Eric's reply I got the opposite impression. Furthermore being very surprised by Eric's reaction on a pure technical issue, I composed a few challenging words to attrack more people to participate in the discussion... :-) Being impressed by the few hundred people attending the last ccamp sessions in London, I am surprised by the low percentage of those people being actively contributing to the correspondence. It can't be the case that only a handful of people have an opinion on these matters... and I believe the discussions would stay technical if more people express their opinion... there would not be a yes/no game between just a few people. With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a previous email from Steve Trowbridge, ITU-T will make those ASON documents available to IETF so we can jointly work this evaluation. The approval of the current ASON recommendations is just a first step within the larger ASON task. Work is started on other elements of ASON (G.rtg (routing), G.lm (link management) and pnni based specific protocol as an implementation of the protocol neutral specification in G.7713)), discussions are started identifying further ASON elements, and work to extend G.8080 is planned to start after this SG15 meeting. Up to so far... {time to shut down my computer and go to the concert hall in Geneva... time to relax after a week and a half of hectic work over here...} Regards, Maarten Sudheer Dharanikota wrote: > > Hi Marteen: > > Can you briefly summarize the differences you see between > GMPLS architecture and ASON architecture? This has been > asked by many of the folks at IETF. > > Regards, > > sudheer > > PS: I thought these mails were about label format and suddenly > this is turning into an ITU versus IETF discussion :-( --------------237325921DB8ED75897EC97C Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------237325921DB8ED75897EC97C-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 08:55:48 -0700 Message-ID: <3BD6E298.6000502@acm.org> Date: Wed, 24 Oct 2001 11:47:36 -0400 From: Gopal Kailad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org, gkailad@acm.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Yakov, Yakov Rekhter wrote: >>> >>>>>>I have some questions/concerns on the restart mechanism as >>>>>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt. I >>>>>>have listed them below. >>>>>> >>>>>>If a node that is terminating hierarchical LSPs restarts, >>>>>>there is an ordering issue during resynchronization, since >>>>>>the LSPs would depend on other FA-LSPs the interface IDs for >>>>>>which would have been generated dynamically. So the >>>>>>mechanism as described will not work, unless this >>>>>>information is preserved across restarts - in which case we >>>>>>might as well preserve other information as well, and avoid >>>>>>resynchronization. >>>>>> >>>>>Since transit node of the FA-LSP does not see the RSVP >>>>>messages that use the FA, we only need to consider >>>>>the ingress and egress node. If the egress node restarts, >>>>>the worst case is that its upstream node sends an ERO >>>>>consisting a unrecognized interface address. Since the >>>>>Path message will carry RECOVERY_LABEL (replacing >>>>>SUGGESTED_LABEL), the egress node knows that it might >>>>>not have complete information yet, and can hold on to >>>>>the Path message until the FA-LSP is established. >>>>>All the information is there, so implementation >>>>>can be completely within the egress node. It does work, >>>>>just not specified enough. >>>>> >>>>>Ingress node will have to know the dependency, so not >>>>>a problem there. >>>>> >>>>Are you suggesting that in case of an ERO with an >>>>unrecognized interface id, if the Path message also >>>>carries a RECOVERY LABEL, the egress node can hold on >>>>to it until later? Note that there may not be a >>>>RECOVERY LABEL - since this Path message is for a >>>>hierarchical LSP, and the previous node may not be >>>>directly connected in the control plane. Here is an >>>>example - There is an LSP L1 from C to F, and on top of >>>>it there is an LSP L2 from A to G. >>>> >>>>L1: C --- D --- E --- F >>>>L2: A --- B --- C --------------- F --- G >>>> >>>>When F restarts, C may not even know, unless HELLO >>>>protocol is run between C and F. Note that the >>>>HELLO mechanism is intended for immediate neighbors. >>>> >>>>And even if the HELLO mechanism is extended, there >>>>is the issue of interface id assigned by F. F needs >>>>to assign the same interface id upon restart so as >>>>not to bring down the hierarchical LSPs set up on top >>>>of L1 in >>>>the reverse direction (say an LSP from G to >>>>B set up on top of L1.) Where would F get this >>>>information ? >>>> >>>Couple of points: >>> >>>(1) First of all, you do run RSVP Hello between C and F. >>> >>O.K. >> >>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should >>>be able to recover the Interface ID it assigns to L1 from >>>a combination of (a) the OSPF/ISIS link state database that >>>F would recover, and (b) the Forward Interface ID (the one >>>assigned by C). >>> >>True. One could either use IGP restart mechanism to relearn >>this (I have other concerns on RSVP restart being dependent on >>IGP restart, but that for later) or preserve this across restarts. >>In either case, you agree that RSVP restart depends on some >>mechanism outside RSVP to help it along? So RSVP needs a new >>interface to get this mapping upon restarts, right? This is not >>clear in the draft. >> > >Couple of points: > >1. As Dimitri Papadimitriou mentioned in his other e-mail to this >list, an Internet Draft "is not a textbook on how to use GMPLS-SIG". > The intent is not to make this a textbook at all. I refer you to documents such as draft-ietf-ospf-hitless-restart-01.txt which state clearely what help you need from outside OSPF for restart to work, and as far as interfaces, RFC 2205 sec 3.11. In addition, the first answer I got on this list, (I believe, from one of the authors) stated that " All the information is there, so implementation can be completely within the egress node. It does work, just not specified enough." whereas, in your answer, you have acknowledged that RSVP does need help in learning the interface ids. that the restarting node had assigned. So, is the other answer from an "uninformed reader" ? I am not trying to put down anybody - just trying to point out some things are not clear. I have also heard from implementors who did not realize that RSVP needs to learn the interface ids that were assigned before the restart. They could claim that their implementation is in full compliance with the draft, even though hierarchical LSPs will be dropped upon restart. > > >2. What I mentioned in the above should be abundantly obvious to the >informed reader of RSVP and LSP Hierarchy specs. > > > >>>>>>Also, let us consider a node that can preserve state across >>>>>>restarts, and hence does not need its state to be synced by >>>>>>its peer. How will it advertise this in the RESTART_CAP >>>>>>object? >>>>>> >>>>>We still need to resynchronize the state since the other >>>>>side might have connections that are in progress. The >>>>> >>>>Let us say the node can resynchronize its neighbor if >>>>the neighbor restarts and requests state recovery. But >>>>the issue is how a node can advertise that it does not >>>>need recovery since all its state was preserved? >>>> >>>By treating is the same way as the way the spec handles >>>control channel fault. >>> >>True, but this does not help. >> > >Help with what ? > I meant this does not work - for reasons cited below. > > >>See below. >> * deleted * > >>>> >>>>If a node supports PSC as well as TDM or LSC interfaces, it >>>>might want to advertise different set of parameters in the >>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM >>>>LSPs which form bearer channels in transport networks. >>>>Currently this is not possible. >>>> >>>>>Can you give us explicit examples as to why and what do >>>>>you gain by giving different values for PSC, TDM ? >>>>> >>>>In case of PSC devices, it may be OK to remove state that >>>>is not resynchronized at the end of the recovery period, >>>>and the recovery period advertised might reflect that. >>>> >>>> >>>>But for LSPs in transport networks, one might want to >>>>have a different recovery period to avoid any LSP from >>>>going down because of recovery timer expiry. >>>> >>>There is no requirement for a node to advertise exactly the >>>same Restart_Cap on all the interfaces. So, on PSC interfaces >>>the node could advertise that it will remove the state that >>>isn't syncronized at the end of the recovery period, while >>>on the TDM interface precisely the same node could advertise >>>that the LSPs would be kept even after the recovery time expires. >>> >>But to set up LSPs over TDM/LSC interfaces, the PSC interface >>is going to be used for signaling - since control and data >>planes are decoupled! So, how will this help? >> > >Help with what ? You asserted that it "is not possible" for >"a node that supports PSC as well as TDM and LSC interfaces.. >to advertise different set of parameters in the RESTART_CAP >object for data LSPs as opposed to SONET/WDM LSPs." > >I pointed out to you that your assertion is incorrect, as >there is no requirement for a node to advertise exactly the >same Restart_Cap on all of its interfaces. > I believe your assertion is misleading - If two nodes A and B have multiple TDM/LSC links (with out of band signaling) between them as well as a PSC link, (they are all unnumbered interfaces), there will be only one Hello adjacency between A and B, resulting in just one Restart_cap object advertised in each direction. In that case, how can one advertise different values in the Restart_cap object for TDM/LSC LSPs as opposed to data LSPs? Since there is only one adjacency, the suggestion above to treat the node failure as control channel failure does not work either, as the restarting node might want to get resynchronized for data LSPs. I believe your assertion is possible only if all interfaces are numbered. If so, this is a huge constraint - please refer draft-ietf-ipo-carrier-requirements-00, sec 7.4. Cheers, Gopal > > >>>>>>According to 9.5.1. (procedures for restarting LSR): "When >>>>>>sending the corresponding outgoing Path message the node >>>>>>SHOULD include a SUGGESTED_LABEL object with a label value >>>>>>^^^^^^ >>>>>>matching the outgoing label from the now restored forwarding >>>>>>entry." >>>>>> >>>>>>This has a conflict with 9.5.2. Consider the case where >>>>>>adjacent nodes B and C restart, and B has another adjacent >>>>>>node A, and C has another adjacent node D. B and C will get >>>>>>resynced by A and D, and during this process, they will >>>>>>resync. each other. While resyncing each other, they act as >>>>>>neighbors of a restarting LSR, and hence according to 9.5.2, >>>>>>MUST include the SUGGESTED_LABEL. >>>>>> >>>>>>Also according to 9.5.2: "During the recovery period, new >>>>>>Path state being advertised to the restarted neighbor SHOULD >>>>>>not include the SUGGESTED_LABEL object in the corresponding >>>>>>outgoing Path message. This will prevent the restarting >>>>>>node >>>>>>from erroneously reusing a saved forwarding entry." >>>>>> >>>>>>I guess this would mean that if suggested labels are used >>>>>>during new LSP setup (as they are likely to be while >>>>>>provisioning lightpaths - to reduce latency), then new LSP >>>>>>setup will not be allowed during resyncing? >>>>>> >>>>>The use of RECOVERY_LABEL address all the above questions. >>>>> >>>>The first problems seems to be there still - consider two >>>>adjacent nodes restarting. They both act both as the restarting >>>>node as well as the neighbor to the restarting node. So, once >>>>they learn the state from the upstream neighbor, do they use >>>>suggested label or the recovery label when they send the path >>>>message to the just restarted downstream neighbor? >>>> >>>The recovery label. >>> >>>The following should be added to the existing text from the document: >>> >>> In the special case where a restarting node also has a restating >>> downstream neighbor, a Recovery_Label object should be used instead >>> of a Suggested_Label object. >>> >>Since a restarting node may not be able to detect that a >>downstream neighbor is restarting, I suggest it always use >>a Recovery_Label object instead of a Suggested_Label object. >> > >Please see my reply to Yangguang on this topic. > > > >Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 08:18:37 -0700 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624101B24@OCCLUST02EVS1.ugd.att.com> From: "Brungard, Deborah A, ALCTA" To: "'Mannie, Eric'" , ccamp@ops.ietf.org Cc: kireeti@juniper.net, "'t1x15@t1.org'" , "'tsg15q11@itu.int'" Subject: RE: Moving right along ... Date: Wed, 24 Oct 2001 11:16:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric, My comment on the labels was in reference to the gen-signaling draft. As you note in the gmpls-sonet-sdh draft, sonet/sdh are defined as a base (combined) set. Whereas in the gen-signaling draft, the LSP encoding type and G-PID assign different values for the two types. The two documents do not appear to be in alignment? One value should apply in the gen-draft, and in the technology specific draft, the additional technology related attributes can be described. My comment is the same for the two values assigned for ANSI PDH and ETSI PDH in the gen draft. One label, PDH, should be used and reference to the ITU-T documents e.g. one of the most common PDH rates, 45M, is used both in the U.S. and Europe. The gen draft limits it to ANSI and SONET technologies. This is in-correct. You are correct, there is no support for TUG-3 multiplexing in SONET. But this does not limit "SONET" equipment from supporting TUG-3. Gateway equipment may support both multiplexing hierarchies (AU-3, AU-4). GMPLS should allow for each link to negotiate - we do not want to limit equipment to either AU-3 or AU-4 support by the gmpls label assignment. Just as many of the routers today can be placed in the U.S. or Europe and connect at a STS-3c (VC-4) - the STS-3c/VC-4 are equivalent and the PPP/ATM mapping is the same. We do not want GMPLS to prevent this connectivity. For example, the current gen-labels limit PPP to SONET - which is incorrect (whereas ATM can be supported by both sdh and sonet in the current draft). I had suggested this past summer to use simply SDH and PDH as the gen-labels. And any technology attributes and related discussion should be in the tech-specific documents. As for the only other difference - the SONET VT3 (3.456M)- why it is in T1.105 and not in G.707 - was before my time :-) As there are no service mappings defined for it, I don't see it as a show-stopper for preventing gmpls to be a truly global protocol vs. localized defined. I would propose in the sdh-sonet draft, it can be included with a note that it is not supported in ITU-T G707 or it can simply be omitted and if a need arises, it can be added later (both to G707 and GMPLS). As I think you commented, gmpls needs to be flexible as there will be future additions (e.g. ODU over SDH). The ability to decouple the service from the local connection link technology is the basis for the ITU-T ASON work. The ITU-T ASON work describes an end-to-end model supporting both client services and native connections. As GMPLS is only addressing the local link set-up, it does need information on the payload. But the labels should not constrain the local link technology which may be used or the services which can be supported. Deborah Brungard AT&T -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, October 24, 2001 7:50 AM To: ccamp@ops.ietf.org Cc: kireeti@juniper.net Subject: RE: Moving right along ... Dear All, Let me strongly clarify something about the SDH/SONET label. I started to see and receive comments from people that obviously didn't read the text carefully, or get lost due to "non-technical" comments. Let's kill the rumor. 1. The draft defines ONE label format: SUKLM As explained in the draft the SONET multiplexing structure is seen as a subset of the SDH one. It is also said that S, L and M have a similar meaning for SONET and SDH. U and K are not significant for SONET. This is why we have on single label format for "SDH/SONET". 2. We claimed since the beginning that our goal was to have a common format for both: This is why this format was accepted, discussed and enhanced, and this was beginning of year 2000! 3. SDH and SONET have and will continue to have two different multiplexing structures: - because there is no TUG-3 equivalent in SONET. - because there is no VT-3 equivalent in SDH. This is a fact. So it results, that the label for SONET and SDH can be as similar as possible, given these two limitations. They will NEVER be completely identical because this is not physically possible. The proposal of Juergen doesn't change that. The only difference between the current text and the proposal of Juergen is that: - the current text uses the single stage interleaving approach of SONET. - Juergen's proposal uses the two-stage interleaving approach of SONET. That's the only difference. I already explained the reasons why we used the single stage interleaving approach. So please, don't tell me that "some people want to align the labels...", this is we made almost two years ago. Kind regards, Eric -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, October 24, 2001 9:11 AM To: Irfan Lateef Cc: kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: Moving right along ... Hi Irfan, good summary! I think (b) is probably right for some. I don't see (c) as been the case... From one uninformed reader to another, I think the quote you had was a frustrated person stating what he thinks was implied by another frustrated person's statement (am I putting words in anyone's mouth?). From what I understand G.ason and G.dcm is developed to describe the process and the minimal requirements needed to support a basic switched transport service. GMPLS is a protocol specific implementation that will likely meet many of the requirements, and may have some minor areas that it does not meet. Then the question to ask (as with any requirements and architecture work -- I'm sure we all have architects in our company) is: how critical are the requirements that may not be met and what changes are needed to GMPLS (if any) in order to meet them? The last few email exchanges I think has been process related: why are things added to GMPLS, who has authority to add. Why can't we make GMPLS drafts more clear to people reading these drafts? Of course there were also some fundamental issues, such as Juergen's desire to align the labels (which I agree with), Yangguang's question of why we are taking a fundamentally different approach for recovery since the "transport world" has done it one way for a long time and now it's suddenly changed & and authors not willing to discuss why the "traditional" way is not desired, and of course my desire to add clarifying text to the document to help uninformed reader like myself understand what SONET/SDH is all about (which is probably purely political rambling...) Zhi Irfan Lateef wrote: > A view from the side lines > ------------------------------- > > First, on the lighter side I have the following suggestion. > we should change the subject line to any of the following, > a. Stubbornly stuck - refusing to move forward > b. Political Ramblings > c. Serious Trouble > d. Ugly email war among adults behaving like kids > I vote for (b) > > Now on the serious side, I have a few questions. > > 1. Does the chair of this WG think that this email thread is a necessary > democratic step in the process. > > 2. If not, then why isn't somebody stepping in with a summary of issues > and resolving them. Isn't there any arbitration process. > > 3. If the protocols are designed to be flexible to accomadate future changes, > why aren't the authors treating "some of the" requests as part of the flexibility > > and getting along. > > 4. I feel the authors were treating last call as a formality and are not ready > to accept changes because it is a last call. Then what is the real intent of > last call. > > 5. There seems to be a real disconnect between the needs of, > a. vendors and service providers > b. data vendors and transport vendors > If GMPLS is for at least this three groups, then the issues need to be > resolved to the satisfaction of this small set. > (I personally agree with not spending 10 years trying to develop a panacea for > all) > > 6. And finally it is alarming to me to note the following assertion. > "GMPLS wouldn't fit the ASON model... :-( " > Can someone clarify the true import of this statement. My understanding was > GMPLS is > the only thing on which ITU,OIF and IETF are on the same page. Can you please > correct > me on this and clarify as am a truly "uninformed" person on this. > > Regards, > Irfan Lateef > > Maarten Vissers wrote: > > >>Eric, >> >>What you refer to as "our own model" is already developed by ITU-T SG15... it is >>in G.8080 (ex. G.ason) and other ASON related recommendations which will be >>approved later this week. We are also entering the next phase in ASON >>development; a phase in which protocol specific details will be defined. A >>proposal to use PNNI as a basis is accepted... and expected in the near future >>is a proposal to use also GMPLS as a 2nd protocol version... but if I understand >>your message, GMPLS wouldn't fit the ASON model... :-( >> >>It's good to know this beforehand... no need then to consider this further... >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over >>the last 10 months... hope it's different however. >> >>Regards, >> >>Maarten >>PS. when I wrote my reply to Yanhe there was no frustation... and their isn't >>today either... >> >>"Mannie, Eric" wrote: >> >>>Hi Maarten and Zhi, >>> >>>I have the feeling that you are inventing a new model with a new protocol. >>>This is not how GMPLS works. I understand your frustrations and I have the >>>feeling that your ideas should be addressed somewhere else rather than >>>trying to change a model that we are finalizing and that we got from the >>>MPLS model. >>> >>>There are maybe 1000 ways of designing a control plane for transmission >>>networks. I would suggest that you first develop your own model and then >>>that we compare the two. >>> >>>Please, don't forget that we have here to be constructive in terms of GMPLS. >>>We have final discussions about the core GMPLS signaling, this is not the >>>beginning but the end of an (intermediate) phase. >>> >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your >>>house :-) We know it. Personally, I don't believe in the ultimate model and >>>protocol that will do everything and that will take 10 years to be >>>specified, with abstract protocols, meta-models, etc. >>> >>>By the way, personally I don't see any benefit of defining these >>>meta-models, abstract models and abstract protocols. It is hard to >>>understand for non super-expert and it is a complete loss of time for the >>>readers. I prefer practical solutions. >>> >>>I am also seeing discussions that we already have many times in the past. I >>>don't see any benefit of having them again, and again, and again. If we >>>continue like this we will all implement a tool to answer automatically with >>>our previous e-mails :-) >>> >>>Ok, there is a small set of people that don't like the way that GMPLS is >>>designed and defined (always the same 4 or 5 people by the way) - that's >>>100% your right guys and I respect it. In comparison with the hundreds >>>(thousands ?) of people that are working on GMPLS and implementing it, this >>>is a great achievement ! >>> >>>So, I ask you the question: what do you want to achieve personally at this >>>stage ? Don't you think that sometimes it is needed to finish one step, >>>before going to the next one ? >>> >>>Kind regards, >>> >>>Eric >>> >>>-----Original Message----- >>>From: Maarten Vissers [mailto:mvissers@lucent.com] >>>Sent: Monday, October 22, 2001 11:07 PM >>>To: Yanhe Fan >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... >>> >>>Yanhe, >>> >>>The situation Zhi describes is one that will be very typical in the optical >>>(SDH/SONET) network in the coming years. We will most likely see islands of >>>switched subnetworks interconnected via the existing SDH/SONET non-switched >>>networks. By means of management actions, links (GMPLS: link bundles) will >>>be >>>setup between an edge node in one switched subnetwork and an other edge node >>>in >>>the next switched subnetwork. In G.805 terminology, these links are so >>>called >>>serial compound links. >>> >>>The switched subnetworks will treat these serial compound links as normal >>>links, >>>"ignoring" the intermediate non-switched nodes they traverse. These links >>>will >>>contain a fixed set of link connections, which are identified by their >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz). >>>The server signal that carries the e.g. 5 STS1 link connections in the link >>>at A >>>can be an OC12, whereas this can be an OC48 at Z. >>> >>>During discovery or by means of provisioning both A and Z nodes get aware of >>>the >>>5 sTS1 link connections as tuples of e.g. >>> >>> SNPa SNPz >>>----------------------------------- >>>- port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) >>>- port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) >>>- port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) >>>- port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) >>>- port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) >>> >>>As both ends of the link build up this same relation information, it is >>>possible >>>to use as link connection identifier only one of the two SNPs. E.g. node A >>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this >>>info >>>to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". >>>Vice >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when >>>received >>>by node A, this will be converted into Ai/T1. >>> >>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot at >>>both ends of the link connection, only the timeslot at the sending end. The >>>receiving end needs to convert this then into its local timeslot number. >>> >>>Regards, >>> >>>Maarten >>> >>>Yanhe Fan wrote: >>> >>>>Hi Zhi, >>>> >>>>What B does is breaking the label association between A and C by crossing >>>>connect >>>>the time slots. >>>> >>>>If the cross connect performed by B is fixed (in your case), what needs to >>>>do is >>>>just to rebuild the label association by configuration or a protocol such >>>> >>>as >>> >>>>LMP; >>>>If the cross connect is not fixed but dynamic, the best thing to do is to >>>>make B >>>>a GMPLS speaker. >>>> >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's transport >>>network... no chance... those will stay non-switched... >>> >>> >>>>Yanhe >>>> >>>>-----Original Message----- >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >>>>Sent: Friday, October 19, 2001 6:01 PM >>>>To: Yanhe Fan >>>>Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>>Subject: Re: Moving right along ... >>>> >>>>Hi Yanhe, >>>> >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It >>>>is simply part of the network that made up the "dumb" pipe. And because >>>>the control plane control channel is separate, A and C can be adjacent >>>>without ever knowing who B is or that even B existed. From A and C's >>>>point of view, the network looks like: >>>> >>>> A ----- C >>>> >>>>Think of the case of how a BGP sees an area. If an area is made up of: >>>> >>>> A -- B -- C >>>> >>>>and B is internal router, does BGP "see" B? >>>> >>>>Zhi >>>> >>>>Yanhe Fan wrote: >>>> >>>> >>>>>Hi, Zhi >>>>> >>>>> >>>>> >>>>>>For the label value for SONET/SDH or the label description in the >>>>>>generic draft, the label is defined as directly representing the >>>>>>"timeslot". Now if I have a control plane controlled transport network >>>>>>that goes through a ADM that is not control plane controlled, as: >>>>>> >>>>>> >>>>>>+--------+ +--------+ +--------+ >>>>>>| | ---1--------- | | ----1-------- | | >>>>>>| | ---2--------- | | ----2-------- | | >>>>>>| A | ---3--------- | B | ----3-------- | C | >>>>>>| | ---4--------- | | ----4-------- | | >>>>>>| | ---5--------- | | ----5-------- | | >>>>>>+--------+ +--------+ +--------+ >>>>>> >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >>>>>>has labels 1,2,3,4,5 incoming. >>>>>> >>>>>>Now imagine that at B, it actually has a fixed cross-connect that >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. >>>>>> >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1". >>>>>>However, the connection/LSP associated with timeslot "1" is actually the >>>>>>label of timeslot "2" at C. >>>>>> >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node >>>>> >>>(B) >>> >>>>>which can't understand GMPLS. >>>>> >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using >>>>>GMPLS if B can't understand GMPLS? >>>>> >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't >>>>>understand >>>>>MPLS), can you setup an LSP A-B-C? >>>>> >>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't >>>>>understand PNNI at all? >>>>> >>>>>My point is that in order to make you case work, some additional work >>>>> >>>need >>> >>>>>to >>>>>be done besie simply using GMPLS as singnaling protocol, becase some >>>>> >>>node >>> >>>>on >>>> >>>>>the path is not GMPLS speakers. A and C needs the info of time slot >>>>> >>>>aligment >>>> >>>>>between them. This can be done by some configurations, some link >>>>> >>>>management >>>> >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info, >>>>>eveything >>>>>works fine. >>>>> >>>>>Yanhe >>>>> >>>>> > > -- > Irfan Lateef > Village Networks Inc, > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 07:34:54 -0700 From: "Juergen Heiles" To: "Mannie, Eric" Cc: , , , Subject: AW: Moving right along ... Date: Wed, 24 Oct 2001 16:32:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Eric, may be I was not clear when I asked for common labels: A STM-4 signal with higher order VC-3 and lower order VC-11 is identical to a STS-12 with STS-1 SPEs and VT1.5-SPEs. They have the same multiplex structure and recent SDH and SONET equipment that supports such signals can accept both with out problems. The same applies to a STM-16 with higher ordr VC-4 and a STS-48 with STS-3c-SPEs. However with the the current defintion we would get different SUKLM values for SDH and SONET. That is what should be avoided. You mentioned one/two stage multiplexing. This is an implementation issue. The result always has to look like two-stage multiplexing, for SDH and SONET. The current proposal is based on one-stage multiplexing for SONET and two-stage multiplexing for SDH. This is the differenc. My original propsoal uses two stage multipelxing for both (align the SONET label to the SDH label). You said that it will result in problems forSONET in case of forwarding adjacencies that are not STS-3xN (e.g. STS-4). Ok, but the current proposal has the same problem for SDH AU3s when you use a forwarding adjacency that is not 3xN AU-3 (e.g. 4 AU-3). So we have to use the one-stage approach for both SONET and SDH in order to avoid the problem. Again we are back to the same SUKLM structure for SONET and SDH. Regards Juergen > -----Ursprüngliche Nachricht----- > Von: owner-tsg15q11@itu.int [mailto:owner-tsg15q11@itu.int]Im Auftrag > von Mannie, Eric > Gesendet: Mittwoch, 24. Oktober 2001 14:56 > An: 'tsg15q11@itu.ch'; 't1x15@t1.org' > Betreff: FW: Moving right along ... > > > Dear All, > > I had the feeling that the information is passing transformed > from the IETF > to the ITU-T. So, I am forwarding you this e-mail. > > Kind regards, > > Eric > > -----Original Message----- > From: Mannie, Eric > Sent: Wednesday, October 24, 2001 1:50 PM > To: ccamp@ops.ietf.org > Cc: kireeti@juniper.net > Subject: RE: Moving right along ... > > > Dear All, > > Let me strongly clarify something about the SDH/SONET label. I started to > see and receive comments from people that obviously didn't read the text > carefully, or get lost due to "non-technical" comments. > > Let's kill the rumor. > > 1. The draft defines ONE label format: SUKLM > > As explained in the draft the SONET multiplexing structure is seen as a > subset of the SDH one. It is also said that S, L and M have a similar > meaning for SONET and SDH. U and K are not significant for SONET. This is > why we have on single label format for "SDH/SONET". > > 2. We claimed since the beginning that our goal was to have a > common format > for both: > > This is why this format was accepted, discussed and enhanced, and this was > beginning of year 2000! > > 3. SDH and SONET have and will continue to have two different multiplexing > structures: > > - because there is no TUG-3 equivalent in SONET. > - because there is no VT-3 equivalent in SDH. > > This is a fact. > > So it results, that the label for SONET and SDH can be as similar as > possible, given these two limitations. They will NEVER be completely > identical because this is not physically possible. The proposal of Juergen > doesn't change that. > > The only difference between the current text and the proposal of > Juergen is > that: > > - the current text uses the single stage interleaving approach of SONET. > - Juergen's proposal uses the two-stage interleaving approach of SONET. > > That's the only difference. I already explained the reasons why > we used the > single stage interleaving approach. > > So please, don't tell me that "some people want to align the labels...", > this is we made almost two years ago. > > Kind regards, > > Eric > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, October 24, 2001 9:11 AM > To: Irfan Lateef > Cc: kireeti@juniper.net; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > > Hi Irfan, good summary! I think (b) is probably right for some. I don't > see (c) as been the case... > > From one uninformed reader to another, I think the quote you had was a > frustrated person stating what he thinks was implied by another > frustrated person's statement (am I putting words in anyone's mouth?). > > From what I understand G.ason and G.dcm is developed to describe the > process and the minimal requirements needed to support a basic switched > transport service. GMPLS is a protocol specific implementation that will > likely meet many of the requirements, and may have some minor areas that > it does not meet. Then the question to ask (as with any requirements and > architecture work -- I'm sure we all have architects in our company) is: > how critical are the requirements that may not be met and what changes > are needed to GMPLS (if any) in order to meet them? > > The last few email exchanges I think has been process related: why are > things added to GMPLS, who has authority to add. Why can't we make GMPLS > drafts more clear to people reading these drafts? > > Of course there were also some fundamental issues, such as Juergen's > desire to align the labels (which I agree with), Yangguang's question of > why we are taking a fundamentally different approach for recovery since > the "transport world" has done it one way for a long time and now it's > suddenly changed & and authors not willing to discuss why the > "traditional" way is not desired, and of course my desire to add > clarifying text to the document to help uninformed reader like myself > understand what SONET/SDH is all about (which is probably purely > political rambling...) > > Zhi > > > Irfan Lateef wrote: > > > A view from the side lines > > ------------------------------- > > > > First, on the lighter side I have the following suggestion. > > we should change the subject line to any of the following, > > a. Stubbornly stuck - refusing to move forward > > b. Political Ramblings > > c. Serious Trouble > > d. Ugly email war among adults behaving like kids > > I vote for (b) > > > > Now on the serious side, I have a few questions. > > > > 1. Does the chair of this WG think that this email thread is a necessary > > democratic step in the process. > > > > 2. If not, then why isn't somebody stepping in with a summary of issues > > and resolving them. Isn't there any arbitration process. > > > > 3. If the protocols are designed to be flexible to accomadate future > changes, > > why aren't the authors treating "some of the" requests as part of the > flexibility > > > > and getting along. > > > > 4. I feel the authors were treating last call as a formality and are not > ready > > to accept changes because it is a last call. Then what is the real > intent of > > last call. > > > > 5. There seems to be a real disconnect between the needs of, > > a. vendors and service providers > > b. data vendors and transport vendors > > If GMPLS is for at least this three groups, then the issues > need to be > > resolved to the satisfaction of this small set. > > (I personally agree with not spending 10 years trying to develop a > panacea for > > all) > > > > 6. And finally it is alarming to me to note the following assertion. > > "GMPLS wouldn't fit the ASON model... :-( " > > Can someone clarify the true import of this statement. My > understanding was > > GMPLS is > > the only thing on which ITU,OIF and IETF are on the same > page. Can you > please > > correct > > me on this and clarify as am a truly "uninformed" person on this. > > > > Regards, > > Irfan Lateef > > > > Maarten Vissers wrote: > > > > > >>Eric, > >> > >>What you refer to as "our own model" is already developed by > ITU-T SG15... > it is > >>in G.8080 (ex. G.ason) and other ASON related recommendations which will > be > >>approved later this week. We are also entering the next phase in ASON > >>development; a phase in which protocol specific details will be > defined. A > >>proposal to use PNNI as a basis is accepted... and expected in the near > future > >>is a proposal to use also GMPLS as a 2nd protocol version... but if I > understand > >>your message, GMPLS wouldn't fit the ASON model... :-( > >> > >>It's good to know this beforehand... no need then to consider this > further... > >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and > OTN details > over > >>the last 10 months... hope it's different however. > >> > >>Regards, > >> > >>Maarten > >>PS. when I wrote my reply to Yanhe there was no frustation... and their > isn't > >>today either... > >> > >>"Mannie, Eric" wrote: > >> > >>>Hi Maarten and Zhi, > >>> > >>>I have the feeling that you are inventing a new model with a new > protocol. > >>>This is not how GMPLS works. I understand your frustrations and I have > the > >>>feeling that your ideas should be addressed somewhere else rather than > >>>trying to change a model that we are finalizing and that we > got from the > >>>MPLS model. > >>> > >>>There are maybe 1000 ways of designing a control plane for transmission > >>>networks. I would suggest that you first develop your own > model and then > >>>that we compare the two. > >>> > >>>Please, don't forget that we have here to be constructive in terms of > GMPLS. > >>>We have final discussions about the core GMPLS signaling, this > is not the > >>>beginning but the end of an (intermediate) phase. > >>> > >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean > your > >>>house :-) We know it. Personally, I don't believe in the ultimate model > and > >>>protocol that will do everything and that will take 10 years to be > >>>specified, with abstract protocols, meta-models, etc. > >>> > >>>By the way, personally I don't see any benefit of defining these > >>>meta-models, abstract models and abstract protocols. It is hard to > >>>understand for non super-expert and it is a complete loss of > time for the > >>>readers. I prefer practical solutions. > >>> > >>>I am also seeing discussions that we already have many times > in the past. > I > >>>don't see any benefit of having them again, and again, and again. If we > >>>continue like this we will all implement a tool to answer automatically > with > >>>our previous e-mails :-) > >>> > >>>Ok, there is a small set of people that don't like the way > that GMPLS is > >>>designed and defined (always the same 4 or 5 people by the > way) - that's > >>>100% your right guys and I respect it. In comparison with the hundreds > >>>(thousands ?) of people that are working on GMPLS and implementing it, > this > >>>is a great achievement ! > >>> > >>>So, I ask you the question: what do you want to achieve personally at > this > >>>stage ? Don't you think that sometimes it is needed to finish one step, > >>>before going to the next one ? > >>> > >>>Kind regards, > >>> > >>>Eric > >>> > >>>-----Original Message----- > >>>From: Maarten Vissers [mailto:mvissers@lucent.com] > >>>Sent: Monday, October 22, 2001 11:07 PM > >>>To: Yanhe Fan > >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org > >>>Subject: Re: Moving right along ... > >>> > >>>Yanhe, > >>> > >>>The situation Zhi describes is one that will be very typical in the > optical > >>>(SDH/SONET) network in the coming years. We will most likely > see islands > of > >>>switched subnetworks interconnected via the existing SDH/SONET > non-switched > >>>networks. By means of management actions, links (GMPLS: link bundles) > will > >>>be > >>>setup between an edge node in one switched subnetwork and an other edge > node > >>>in > >>>the next switched subnetwork. In G.805 terminology, these links are so > >>>called > >>>serial compound links. > >>> > >>>The switched subnetworks will treat these serial compound > links as normal > >>>links, > >>>"ignoring" the intermediate non-switched nodes they traverse. > These links > >>>will > >>>contain a fixed set of link connections, which are identified by their > >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz). > >>>The server signal that carries the e.g. 5 STS1 link connections in the > link > >>>at A > >>>can be an OC12, whereas this can be an OC48 at Z. > >>> > >>>During discovery or by means of provisioning both A and Z > nodes get aware > of > >>>the > >>>5 sTS1 link connections as tuples of e.g. > >>> > >>> SNPa SNPz > >>>----------------------------------- > >>>- port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) > >>>- port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) > >>>- port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) > >>>- port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) > >>>- port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) > >>> > >>>As both ends of the link build up this same relation information, it is > >>>possible > >>>to use as link connection identifier only one of the two SNPs. > E.g. node > A > >>>identifies the STS1 link connection #1 by means of "Ai/T1" and > sends this > >>>info > >>>to node Z. Node Z receiving this Ai/T1 converts this locally into > "Zj/Ta". > >>>Vice > >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when > >>>received > >>>by node A, this will be converted into Ai/T1. > >>> > >>>For GMPLS this implies that the GMPLS label doesn't identify > the timeslot > at > >>>both ends of the link connection, only the timeslot at the sending end. > The > >>>receiving end needs to convert this then into its local > timeslot number. > >>> > >>>Regards, > >>> > >>>Maarten > >>> > >>>Yanhe Fan wrote: > >>> > >>>>Hi Zhi, > >>>> > >>>>What B does is breaking the label association between A and C by > crossing > >>>>connect > >>>>the time slots. > >>>> > >>>>If the cross connect performed by B is fixed (in your case), > what needs > to > >>>>do is > >>>>just to rebuild the label association by configuration or a protocol > such > >>>> > >>>as > >>> > >>>>LMP; > >>>>If the cross connect is not fixed but dynamic, the best thing to do is > to > >>>>make B > >>>>a GMPLS speaker. > >>>> > >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's > transport > >>>network... no chance... those will stay non-switched... > >>> > >>> > >>>>Yanhe > >>>> > >>>>-----Original Message----- > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > >>>>Sent: Friday, October 19, 2001 6:01 PM > >>>>To: Yanhe Fan > >>>>Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > >>>>Subject: Re: Moving right along ... > >>>> > >>>>Hi Yanhe, > >>>> > >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > >>>>is simply part of the network that made up the "dumb" pipe. > And because > >>>>the control plane control channel is separate, A and C can be adjacent > >>>>without ever knowing who B is or that even B existed. From A and C's > >>>>point of view, the network looks like: > >>>> > >>>> A ----- C > >>>> > >>>>Think of the case of how a BGP sees an area. If an area is made up of: > >>>> > >>>> A -- B -- C > >>>> > >>>>and B is internal router, does BGP "see" B? > >>>> > >>>>Zhi > >>>> > >>>>Yanhe Fan wrote: > >>>> > >>>> > >>>>>Hi, Zhi > >>>>> > >>>>> > >>>>> > >>>>>>For the label value for SONET/SDH or the label description in the > >>>>>>generic draft, the label is defined as directly representing the > >>>>>>"timeslot". Now if I have a control plane controlled > transport network > >>>>>>that goes through a ADM that is not control plane controlled, as: > >>>>>> > >>>>>> > >>>>>>+--------+ +--------+ +--------+ > >>>>>>| | ---1--------- | | ----1-------- | | > >>>>>>| | ---2--------- | | ----2-------- | | > >>>>>>| A | ---3--------- | B | ----3-------- | C | > >>>>>>| | ---4--------- | | ----4-------- | | > >>>>>>| | ---5--------- | | ----5-------- | | > >>>>>>+--------+ +--------+ +--------+ > >>>>>> > >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So > at > >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM > format) and > C > >>>>>>has labels 1,2,3,4,5 incoming. > >>>>>> > >>>>>>Now imagine that at B, it actually has a fixed cross-connect that > >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming > timeslot #2), A-2 > to > >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >>>>>> > >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1". > >>>>>>However, the connection/LSP associated with timeslot "1" is actually > the > >>>>>>label of timeslot "2" at C. > >>>>>> > >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node > >>>>> > >>>(B) > >>> > >>>>>which can't understand GMPLS. > >>>>> > >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by > using > >>>>>GMPLS if B can't understand GMPLS? > >>>>> > >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't > >>>>>understand > >>>>>MPLS), can you setup an LSP A-B-C? > >>>>> > >>>>>Now imagine A, B and C are ATM switches, can you setup a svc > if B can't > >>>>>understand PNNI at all? > >>>>> > >>>>>My point is that in order to make you case work, some additional work > >>>>> > >>>need > >>> > >>>>>to > >>>>>be done besie simply using GMPLS as singnaling protocol, becase some > >>>>> > >>>node > >>> > >>>>on > >>>> > >>>>>the path is not GMPLS speakers. A and C needs the info of time slot > >>>>> > >>>>aligment > >>>> > >>>>>between them. This can be done by some configurations, some link > >>>>> > >>>>management > >>>> > >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info, > >>>>>eveything > >>>>>works fine. > >>>>> > >>>>>Yanhe > >>>>> > >>>>> > > > > -- > > Irfan Lateef > > Village Networks Inc, > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 05:58:07 -0700 Message-ID: <1B08859602C8D211B66F0000C0769CFA03A95E29@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALCTA" To: "'Irfan Lateef'" , kireeti@juniper.net Cc: "Ash, Gerald R (Jerry), ALCTA" , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Wed, 24 Oct 2001 08:56:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > why isn't somebody stepping in with a summary of issues > and resolving them. Isn't there any arbitration process. This is a good suggestion. Perhaps some objective person (e.g., Kireeti) could step in and help here. Further repetition by commenters and authors isn't really helping or needed. Jerry Ash AT&T Labs Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 05:43:45 -0700 Message-ID: <3BD6B711.3BC854B@alcatel.be> Date: Wed, 24 Oct 2001 14:41:53 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Zhi-Wei Lin'" , Irfan Lateef , kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------90AA354664CEBD1312A5D854" This is a multi-part message in MIME format. --------------90AA354664CEBD1312A5D854 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi, I still don't understand the following you claim to be an "uninformed reader which would like to know what SDH/Sonet is all about" but after you are defending the Juergen's proposal. How can an uninformed reader defend a technical solution for which he requests more clarifying text to be become informed ? Are you an technically informed uninformed reader ;-) ? Please clarify your position, Dimitri. "Mannie, Eric" wrote: > > Hello Zhi, > > > From one uninformed reader to another... and of course my desire to add > > clarifying text to the document to help uninformed reader like myself > >understand what SONET/SDH is all about... > > Is this a joke ? May I remind you that you and your colleagues where more > than deeply involved in the SDH/SONET drafts, and also that you are listed > among the co-authors of that draft. I am surprised to see that you are > uninformed :-) > > Kind regards, > > Eric > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, October 24, 2001 9:11 AM > To: Irfan Lateef > Cc: kireeti@juniper.net; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Hi Irfan, good summary! I think (b) is probably right for some. I don't > see (c) as been the case... > > From one uninformed reader to another, I think the quote you had was a > frustrated person stating what he thinks was implied by another > frustrated person's statement (am I putting words in anyone's mouth?). > > From what I understand G.ason and G.dcm is developed to describe the > process and the minimal requirements needed to support a basic switched > transport service. GMPLS is a protocol specific implementation that will > likely meet many of the requirements, and may have some minor areas that > it does not meet. Then the question to ask (as with any requirements and > architecture work -- I'm sure we all have architects in our company) is: > how critical are the requirements that may not be met and what changes > are needed to GMPLS (if any) in order to meet them? > > The last few email exchanges I think has been process related: why are > things added to GMPLS, who has authority to add. Why can't we make GMPLS > drafts more clear to people reading these drafts? > > Of course there were also some fundamental issues, such as Juergen's > desire to align the labels (which I agree with), Yangguang's question of > why we are taking a fundamentally different approach for recovery since > the "transport world" has done it one way for a long time and now it's > suddenly changed & and authors not willing to discuss why the > "traditional" way is not desired, and of course my desire to add > clarifying text to the document to help uninformed reader like myself > understand what SONET/SDH is all about (which is probably purely > political rambling...) > > Zhi > > Irfan Lateef wrote: > > > A view from the side lines > > ------------------------------- > > > > First, on the lighter side I have the following suggestion. > > we should change the subject line to any of the following, > > a. Stubbornly stuck - refusing to move forward > > b. Political Ramblings > > c. Serious Trouble > > d. Ugly email war among adults behaving like kids > > I vote for (b) > > > > Now on the serious side, I have a few questions. > > > > 1. Does the chair of this WG think that this email thread is a necessary > > democratic step in the process. > > > > 2. If not, then why isn't somebody stepping in with a summary of issues > > and resolving them. Isn't there any arbitration process. > > > > 3. If the protocols are designed to be flexible to accomadate future > changes, > > why aren't the authors treating "some of the" requests as part of the > flexibility > > > > and getting along. > > > > 4. I feel the authors were treating last call as a formality and are not > ready > > to accept changes because it is a last call. Then what is the real > intent of > > last call. > > > > 5. There seems to be a real disconnect between the needs of, > > a. vendors and service providers > > b. data vendors and transport vendors > > If GMPLS is for at least this three groups, then the issues need to be > > resolved to the satisfaction of this small set. > > (I personally agree with not spending 10 years trying to develop a > panacea for > > all) > > > > 6. And finally it is alarming to me to note the following assertion. > > "GMPLS wouldn't fit the ASON model... :-( " > > Can someone clarify the true import of this statement. My > understanding was > > GMPLS is > > the only thing on which ITU,OIF and IETF are on the same page. Can you > please > > correct > > me on this and clarify as am a truly "uninformed" person on this. > > > > Regards, > > Irfan Lateef > > > > Maarten Vissers wrote: > > > > > >>Eric, > >> > >>What you refer to as "our own model" is already developed by ITU-T SG15... > it is > >>in G.8080 (ex. G.ason) and other ASON related recommendations which will > be > >>approved later this week. We are also entering the next phase in ASON > >>development; a phase in which protocol specific details will be defined. A > >>proposal to use PNNI as a basis is accepted... and expected in the near > future > >>is a proposal to use also GMPLS as a 2nd protocol version... but if I > understand > >>your message, GMPLS wouldn't fit the ASON model... :-( > >> > >>It's good to know this beforehand... no need then to consider this > further... > >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details > over > >>the last 10 months... hope it's different however. > >> > >>Regards, > >> > >>Maarten > >>PS. when I wrote my reply to Yanhe there was no frustation... and their > isn't > >>today either... > >> > >>"Mannie, Eric" wrote: > >> > >>>Hi Maarten and Zhi, > >>> > >>>I have the feeling that you are inventing a new model with a new > protocol. > >>>This is not how GMPLS works. I understand your frustrations and I have > the > >>>feeling that your ideas should be addressed somewhere else rather than > >>>trying to change a model that we are finalizing and that we got from the > >>>MPLS model. > >>> > >>>There are maybe 1000 ways of designing a control plane for transmission > >>>networks. I would suggest that you first develop your own model and then > >>>that we compare the two. > >>> > >>>Please, don't forget that we have here to be constructive in terms of > GMPLS. > >>>We have final discussions about the core GMPLS signaling, this is not the > >>>beginning but the end of an (intermediate) phase. > >>> > >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean > your > >>>house :-) We know it. Personally, I don't believe in the ultimate model > and > >>>protocol that will do everything and that will take 10 years to be > >>>specified, with abstract protocols, meta-models, etc. > >>> > >>>By the way, personally I don't see any benefit of defining these > >>>meta-models, abstract models and abstract protocols. It is hard to > >>>understand for non super-expert and it is a complete loss of time for the > >>>readers. I prefer practical solutions. > >>> > >>>I am also seeing discussions that we already have many times in the past. > I > >>>don't see any benefit of having them again, and again, and again. If we > >>>continue like this we will all implement a tool to answer automatically > with > >>>our previous e-mails :-) > >>> > >>>Ok, there is a small set of people that don't like the way that GMPLS is > >>>designed and defined (always the same 4 or 5 people by the way) - that's > >>>100% your right guys and I respect it. In comparison with the hundreds > >>>(thousands ?) of people that are working on GMPLS and implementing it, > this > >>>is a great achievement ! > >>> > >>>So, I ask you the question: what do you want to achieve personally at > this > >>>stage ? Don't you think that sometimes it is needed to finish one step, > >>>before going to the next one ? > >>> > >>>Kind regards, > >>> > >>>Eric > >>> > >>>-----Original Message----- > >>>From: Maarten Vissers [mailto:mvissers@lucent.com] > >>>Sent: Monday, October 22, 2001 11:07 PM > >>>To: Yanhe Fan > >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org > >>>Subject: Re: Moving right along ... > >>> > >>>Yanhe, > >>> > >>>The situation Zhi describes is one that will be very typical in the > optical > >>>(SDH/SONET) network in the coming years. We will most likely see islands > of > >>>switched subnetworks interconnected via the existing SDH/SONET > non-switched > >>>networks. By means of management actions, links (GMPLS: link bundles) > will > >>>be > >>>setup between an edge node in one switched subnetwork and an other edge > node > >>>in > >>>the next switched subnetwork. In G.805 terminology, these links are so > >>>called > >>>serial compound links. > >>> > >>>The switched subnetworks will treat these serial compound links as normal > >>>links, > >>>"ignoring" the intermediate non-switched nodes they traverse. These links > >>>will > >>>contain a fixed set of link connections, which are identified by their > >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz). > >>>The server signal that carries the e.g. 5 STS1 link connections in the > link > >>>at A > >>>can be an OC12, whereas this can be an OC48 at Z. > >>> > >>>During discovery or by means of provisioning both A and Z nodes get aware > of > >>>the > >>>5 sTS1 link connections as tuples of e.g. > >>> > >>> SNPa SNPz > >>>----------------------------------- > >>>- port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) > >>>- port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) > >>>- port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) > >>>- port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) > >>>- port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) > >>> > >>>As both ends of the link build up this same relation information, it is > >>>possible > >>>to use as link connection identifier only one of the two SNPs. E.g. node > A > >>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this > >>>info > >>>to node Z. Node Z receiving this Ai/T1 converts this locally into > "Zj/Ta". > >>>Vice > >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when > >>>received > >>>by node A, this will be converted into Ai/T1. > >>> > >>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot > at > >>>both ends of the link connection, only the timeslot at the sending end. > The > >>>receiving end needs to convert this then into its local timeslot number. > >>> > >>>Regards, > >>> > >>>Maarten > >>> > >>>Yanhe Fan wrote: > >>> > >>>>Hi Zhi, > >>>> > >>>>What B does is breaking the label association between A and C by > crossing > >>>>connect > >>>>the time slots. > >>>> > >>>>If the cross connect performed by B is fixed (in your case), what needs > to > >>>>do is > >>>>just to rebuild the label association by configuration or a protocol > such > >>>> > >>>as > >>> > >>>>LMP; > >>>>If the cross connect is not fixed but dynamic, the best thing to do is > to > >>>>make B > >>>>a GMPLS speaker. > >>>> > >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's > transport > >>>network... no chance... those will stay non-switched... > >>> > >>> > >>>>Yanhe > >>>> > >>>>-----Original Message----- > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > >>>>Sent: Friday, October 19, 2001 6:01 PM > >>>>To: Yanhe Fan > >>>>Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > >>>>Subject: Re: Moving right along ... > >>>> > >>>>Hi Yanhe, > >>>> > >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > >>>>is simply part of the network that made up the "dumb" pipe. And because > >>>>the control plane control channel is separate, A and C can be adjacent > >>>>without ever knowing who B is or that even B existed. From A and C's > >>>>point of view, the network looks like: > >>>> > >>>> A ----- C > >>>> > >>>>Think of the case of how a BGP sees an area. If an area is made up of: > >>>> > >>>> A -- B -- C > >>>> > >>>>and B is internal router, does BGP "see" B? > >>>> > >>>>Zhi > >>>> > >>>>Yanhe Fan wrote: > >>>> > >>>> > >>>>>Hi, Zhi > >>>>> > >>>>> > >>>>> > >>>>>>For the label value for SONET/SDH or the label description in the > >>>>>>generic draft, the label is defined as directly representing the > >>>>>>"timeslot". Now if I have a control plane controlled transport network > >>>>>>that goes through a ADM that is not control plane controlled, as: > >>>>>> > >>>>>> > >>>>>>+--------+ +--------+ +--------+ > >>>>>>| | ---1--------- | | ----1-------- | | > >>>>>>| | ---2--------- | | ----2-------- | | > >>>>>>| A | ---3--------- | B | ----3-------- | C | > >>>>>>| | ---4--------- | | ----4-------- | | > >>>>>>| | ---5--------- | | ----5-------- | | > >>>>>>+--------+ +--------+ +--------+ > >>>>>> > >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So > at > >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and > C > >>>>>>has labels 1,2,3,4,5 incoming. > >>>>>> > >>>>>>Now imagine that at B, it actually has a fixed cross-connect that > >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 > to > >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >>>>>> > >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1". > >>>>>>However, the connection/LSP associated with timeslot "1" is actually > the > >>>>>>label of timeslot "2" at C. > >>>>>> > >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node > >>>>> > >>>(B) > >>> > >>>>>which can't understand GMPLS. > >>>>> > >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by > using > >>>>>GMPLS if B can't understand GMPLS? > >>>>> > >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't > >>>>>understand > >>>>>MPLS), can you setup an LSP A-B-C? > >>>>> > >>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't > >>>>>understand PNNI at all? > >>>>> > >>>>>My point is that in order to make you case work, some additional work > >>>>> > >>>need > >>> > >>>>>to > >>>>>be done besie simply using GMPLS as singnaling protocol, becase some > >>>>> > >>>node > >>> > >>>>on > >>>> > >>>>>the path is not GMPLS speakers. A and C needs the info of time slot > >>>>> > >>>>aligment > >>>> > >>>>>between them. This can be done by some configurations, some link > >>>>> > >>>>management > >>>> > >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info, > >>>>>eveything > >>>>>works fine. > >>>>> > >>>>>Yanhe > >>>>> > >>>>> > > > > -- > > Irfan Lateef > > Village Networks Inc, > > > > > > > > --------------90AA354664CEBD1312A5D854 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------90AA354664CEBD1312A5D854-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 05:23:40 -0700 Message-ID: From: "Mannie, Eric" To: 'Zhi-Wei Lin' , Irfan Lateef Cc: kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Wed, 24 Oct 2001 14:22:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Zhi, > From one uninformed reader to another... and of course my desire to add > clarifying text to the document to help uninformed reader like myself >understand what SONET/SDH is all about... Is this a joke ? May I remind you that you and your colleagues where more than deeply involved in the SDH/SONET drafts, and also that you are listed among the co-authors of that draft. I am surprised to see that you are uninformed :-) Kind regards, Eric -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, October 24, 2001 9:11 AM To: Irfan Lateef Cc: kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: Moving right along ... Hi Irfan, good summary! I think (b) is probably right for some. I don't see (c) as been the case... From one uninformed reader to another, I think the quote you had was a frustrated person stating what he thinks was implied by another frustrated person's statement (am I putting words in anyone's mouth?). From what I understand G.ason and G.dcm is developed to describe the process and the minimal requirements needed to support a basic switched transport service. GMPLS is a protocol specific implementation that will likely meet many of the requirements, and may have some minor areas that it does not meet. Then the question to ask (as with any requirements and architecture work -- I'm sure we all have architects in our company) is: how critical are the requirements that may not be met and what changes are needed to GMPLS (if any) in order to meet them? The last few email exchanges I think has been process related: why are things added to GMPLS, who has authority to add. Why can't we make GMPLS drafts more clear to people reading these drafts? Of course there were also some fundamental issues, such as Juergen's desire to align the labels (which I agree with), Yangguang's question of why we are taking a fundamentally different approach for recovery since the "transport world" has done it one way for a long time and now it's suddenly changed & and authors not willing to discuss why the "traditional" way is not desired, and of course my desire to add clarifying text to the document to help uninformed reader like myself understand what SONET/SDH is all about (which is probably purely political rambling...) Zhi Irfan Lateef wrote: > A view from the side lines > ------------------------------- > > First, on the lighter side I have the following suggestion. > we should change the subject line to any of the following, > a. Stubbornly stuck - refusing to move forward > b. Political Ramblings > c. Serious Trouble > d. Ugly email war among adults behaving like kids > I vote for (b) > > Now on the serious side, I have a few questions. > > 1. Does the chair of this WG think that this email thread is a necessary > democratic step in the process. > > 2. If not, then why isn't somebody stepping in with a summary of issues > and resolving them. Isn't there any arbitration process. > > 3. If the protocols are designed to be flexible to accomadate future changes, > why aren't the authors treating "some of the" requests as part of the flexibility > > and getting along. > > 4. I feel the authors were treating last call as a formality and are not ready > to accept changes because it is a last call. Then what is the real intent of > last call. > > 5. There seems to be a real disconnect between the needs of, > a. vendors and service providers > b. data vendors and transport vendors > If GMPLS is for at least this three groups, then the issues need to be > resolved to the satisfaction of this small set. > (I personally agree with not spending 10 years trying to develop a panacea for > all) > > 6. And finally it is alarming to me to note the following assertion. > "GMPLS wouldn't fit the ASON model... :-( " > Can someone clarify the true import of this statement. My understanding was > GMPLS is > the only thing on which ITU,OIF and IETF are on the same page. Can you please > correct > me on this and clarify as am a truly "uninformed" person on this. > > Regards, > Irfan Lateef > > Maarten Vissers wrote: > > >>Eric, >> >>What you refer to as "our own model" is already developed by ITU-T SG15... it is >>in G.8080 (ex. G.ason) and other ASON related recommendations which will be >>approved later this week. We are also entering the next phase in ASON >>development; a phase in which protocol specific details will be defined. A >>proposal to use PNNI as a basis is accepted... and expected in the near future >>is a proposal to use also GMPLS as a 2nd protocol version... but if I understand >>your message, GMPLS wouldn't fit the ASON model... :-( >> >>It's good to know this beforehand... no need then to consider this further... >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over >>the last 10 months... hope it's different however. >> >>Regards, >> >>Maarten >>PS. when I wrote my reply to Yanhe there was no frustation... and their isn't >>today either... >> >>"Mannie, Eric" wrote: >> >>>Hi Maarten and Zhi, >>> >>>I have the feeling that you are inventing a new model with a new protocol. >>>This is not how GMPLS works. I understand your frustrations and I have the >>>feeling that your ideas should be addressed somewhere else rather than >>>trying to change a model that we are finalizing and that we got from the >>>MPLS model. >>> >>>There are maybe 1000 ways of designing a control plane for transmission >>>networks. I would suggest that you first develop your own model and then >>>that we compare the two. >>> >>>Please, don't forget that we have here to be constructive in terms of GMPLS. >>>We have final discussions about the core GMPLS signaling, this is not the >>>beginning but the end of an (intermediate) phase. >>> >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your >>>house :-) We know it. Personally, I don't believe in the ultimate model and >>>protocol that will do everything and that will take 10 years to be >>>specified, with abstract protocols, meta-models, etc. >>> >>>By the way, personally I don't see any benefit of defining these >>>meta-models, abstract models and abstract protocols. It is hard to >>>understand for non super-expert and it is a complete loss of time for the >>>readers. I prefer practical solutions. >>> >>>I am also seeing discussions that we already have many times in the past. I >>>don't see any benefit of having them again, and again, and again. If we >>>continue like this we will all implement a tool to answer automatically with >>>our previous e-mails :-) >>> >>>Ok, there is a small set of people that don't like the way that GMPLS is >>>designed and defined (always the same 4 or 5 people by the way) - that's >>>100% your right guys and I respect it. In comparison with the hundreds >>>(thousands ?) of people that are working on GMPLS and implementing it, this >>>is a great achievement ! >>> >>>So, I ask you the question: what do you want to achieve personally at this >>>stage ? Don't you think that sometimes it is needed to finish one step, >>>before going to the next one ? >>> >>>Kind regards, >>> >>>Eric >>> >>>-----Original Message----- >>>From: Maarten Vissers [mailto:mvissers@lucent.com] >>>Sent: Monday, October 22, 2001 11:07 PM >>>To: Yanhe Fan >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... >>> >>>Yanhe, >>> >>>The situation Zhi describes is one that will be very typical in the optical >>>(SDH/SONET) network in the coming years. We will most likely see islands of >>>switched subnetworks interconnected via the existing SDH/SONET non-switched >>>networks. By means of management actions, links (GMPLS: link bundles) will >>>be >>>setup between an edge node in one switched subnetwork and an other edge node >>>in >>>the next switched subnetwork. In G.805 terminology, these links are so >>>called >>>serial compound links. >>> >>>The switched subnetworks will treat these serial compound links as normal >>>links, >>>"ignoring" the intermediate non-switched nodes they traverse. These links >>>will >>>contain a fixed set of link connections, which are identified by their >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz). >>>The server signal that carries the e.g. 5 STS1 link connections in the link >>>at A >>>can be an OC12, whereas this can be an OC48 at Z. >>> >>>During discovery or by means of provisioning both A and Z nodes get aware of >>>the >>>5 sTS1 link connections as tuples of e.g. >>> >>> SNPa SNPz >>>----------------------------------- >>>- port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) >>>- port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) >>>- port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) >>>- port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) >>>- port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) >>> >>>As both ends of the link build up this same relation information, it is >>>possible >>>to use as link connection identifier only one of the two SNPs. E.g. node A >>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this >>>info >>>to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". >>>Vice >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when >>>received >>>by node A, this will be converted into Ai/T1. >>> >>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot at >>>both ends of the link connection, only the timeslot at the sending end. The >>>receiving end needs to convert this then into its local timeslot number. >>> >>>Regards, >>> >>>Maarten >>> >>>Yanhe Fan wrote: >>> >>>>Hi Zhi, >>>> >>>>What B does is breaking the label association between A and C by crossing >>>>connect >>>>the time slots. >>>> >>>>If the cross connect performed by B is fixed (in your case), what needs to >>>>do is >>>>just to rebuild the label association by configuration or a protocol such >>>> >>>as >>> >>>>LMP; >>>>If the cross connect is not fixed but dynamic, the best thing to do is to >>>>make B >>>>a GMPLS speaker. >>>> >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's transport >>>network... no chance... those will stay non-switched... >>> >>> >>>>Yanhe >>>> >>>>-----Original Message----- >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >>>>Sent: Friday, October 19, 2001 6:01 PM >>>>To: Yanhe Fan >>>>Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>>Subject: Re: Moving right along ... >>>> >>>>Hi Yanhe, >>>> >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It >>>>is simply part of the network that made up the "dumb" pipe. And because >>>>the control plane control channel is separate, A and C can be adjacent >>>>without ever knowing who B is or that even B existed. From A and C's >>>>point of view, the network looks like: >>>> >>>> A ----- C >>>> >>>>Think of the case of how a BGP sees an area. If an area is made up of: >>>> >>>> A -- B -- C >>>> >>>>and B is internal router, does BGP "see" B? >>>> >>>>Zhi >>>> >>>>Yanhe Fan wrote: >>>> >>>> >>>>>Hi, Zhi >>>>> >>>>> >>>>> >>>>>>For the label value for SONET/SDH or the label description in the >>>>>>generic draft, the label is defined as directly representing the >>>>>>"timeslot". Now if I have a control plane controlled transport network >>>>>>that goes through a ADM that is not control plane controlled, as: >>>>>> >>>>>> >>>>>>+--------+ +--------+ +--------+ >>>>>>| | ---1--------- | | ----1-------- | | >>>>>>| | ---2--------- | | ----2-------- | | >>>>>>| A | ---3--------- | B | ----3-------- | C | >>>>>>| | ---4--------- | | ----4-------- | | >>>>>>| | ---5--------- | | ----5-------- | | >>>>>>+--------+ +--------+ +--------+ >>>>>> >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >>>>>>has labels 1,2,3,4,5 incoming. >>>>>> >>>>>>Now imagine that at B, it actually has a fixed cross-connect that >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. >>>>>> >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1". >>>>>>However, the connection/LSP associated with timeslot "1" is actually the >>>>>>label of timeslot "2" at C. >>>>>> >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node >>>>> >>>(B) >>> >>>>>which can't understand GMPLS. >>>>> >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using >>>>>GMPLS if B can't understand GMPLS? >>>>> >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't >>>>>understand >>>>>MPLS), can you setup an LSP A-B-C? >>>>> >>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't >>>>>understand PNNI at all? >>>>> >>>>>My point is that in order to make you case work, some additional work >>>>> >>>need >>> >>>>>to >>>>>be done besie simply using GMPLS as singnaling protocol, becase some >>>>> >>>node >>> >>>>on >>>> >>>>>the path is not GMPLS speakers. A and C needs the info of time slot >>>>> >>>>aligment >>>> >>>>>between them. This can be done by some configurations, some link >>>>> >>>>management >>>> >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info, >>>>>eveything >>>>>works fine. >>>>> >>>>>Yanhe >>>>> >>>>> > > -- > Irfan Lateef > Village Networks Inc, > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 04:52:55 -0700 Message-ID: From: "Mannie, Eric" To: ccamp@ops.ietf.org Cc: kireeti@juniper.net Subject: RE: Moving right along ... Date: Wed, 24 Oct 2001 13:49:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear All, Let me strongly clarify something about the SDH/SONET label. I started to see and receive comments from people that obviously didn't read the text carefully, or get lost due to "non-technical" comments. Let's kill the rumor. 1. The draft defines ONE label format: SUKLM As explained in the draft the SONET multiplexing structure is seen as a subset of the SDH one. It is also said that S, L and M have a similar meaning for SONET and SDH. U and K are not significant for SONET. This is why we have on single label format for "SDH/SONET". 2. We claimed since the beginning that our goal was to have a common format for both: This is why this format was accepted, discussed and enhanced, and this was beginning of year 2000! 3. SDH and SONET have and will continue to have two different multiplexing structures: - because there is no TUG-3 equivalent in SONET. - because there is no VT-3 equivalent in SDH. This is a fact. So it results, that the label for SONET and SDH can be as similar as possible, given these two limitations. They will NEVER be completely identical because this is not physically possible. The proposal of Juergen doesn't change that. The only difference between the current text and the proposal of Juergen is that: - the current text uses the single stage interleaving approach of SONET. - Juergen's proposal uses the two-stage interleaving approach of SONET. That's the only difference. I already explained the reasons why we used the single stage interleaving approach. So please, don't tell me that "some people want to align the labels...", this is we made almost two years ago. Kind regards, Eric -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, October 24, 2001 9:11 AM To: Irfan Lateef Cc: kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: Moving right along ... Hi Irfan, good summary! I think (b) is probably right for some. I don't see (c) as been the case... From one uninformed reader to another, I think the quote you had was a frustrated person stating what he thinks was implied by another frustrated person's statement (am I putting words in anyone's mouth?). From what I understand G.ason and G.dcm is developed to describe the process and the minimal requirements needed to support a basic switched transport service. GMPLS is a protocol specific implementation that will likely meet many of the requirements, and may have some minor areas that it does not meet. Then the question to ask (as with any requirements and architecture work -- I'm sure we all have architects in our company) is: how critical are the requirements that may not be met and what changes are needed to GMPLS (if any) in order to meet them? The last few email exchanges I think has been process related: why are things added to GMPLS, who has authority to add. Why can't we make GMPLS drafts more clear to people reading these drafts? Of course there were also some fundamental issues, such as Juergen's desire to align the labels (which I agree with), Yangguang's question of why we are taking a fundamentally different approach for recovery since the "transport world" has done it one way for a long time and now it's suddenly changed & and authors not willing to discuss why the "traditional" way is not desired, and of course my desire to add clarifying text to the document to help uninformed reader like myself understand what SONET/SDH is all about (which is probably purely political rambling...) Zhi Irfan Lateef wrote: > A view from the side lines > ------------------------------- > > First, on the lighter side I have the following suggestion. > we should change the subject line to any of the following, > a. Stubbornly stuck - refusing to move forward > b. Political Ramblings > c. Serious Trouble > d. Ugly email war among adults behaving like kids > I vote for (b) > > Now on the serious side, I have a few questions. > > 1. Does the chair of this WG think that this email thread is a necessary > democratic step in the process. > > 2. If not, then why isn't somebody stepping in with a summary of issues > and resolving them. Isn't there any arbitration process. > > 3. If the protocols are designed to be flexible to accomadate future changes, > why aren't the authors treating "some of the" requests as part of the flexibility > > and getting along. > > 4. I feel the authors were treating last call as a formality and are not ready > to accept changes because it is a last call. Then what is the real intent of > last call. > > 5. There seems to be a real disconnect between the needs of, > a. vendors and service providers > b. data vendors and transport vendors > If GMPLS is for at least this three groups, then the issues need to be > resolved to the satisfaction of this small set. > (I personally agree with not spending 10 years trying to develop a panacea for > all) > > 6. And finally it is alarming to me to note the following assertion. > "GMPLS wouldn't fit the ASON model... :-( " > Can someone clarify the true import of this statement. My understanding was > GMPLS is > the only thing on which ITU,OIF and IETF are on the same page. Can you please > correct > me on this and clarify as am a truly "uninformed" person on this. > > Regards, > Irfan Lateef > > Maarten Vissers wrote: > > >>Eric, >> >>What you refer to as "our own model" is already developed by ITU-T SG15... it is >>in G.8080 (ex. G.ason) and other ASON related recommendations which will be >>approved later this week. We are also entering the next phase in ASON >>development; a phase in which protocol specific details will be defined. A >>proposal to use PNNI as a basis is accepted... and expected in the near future >>is a proposal to use also GMPLS as a 2nd protocol version... but if I understand >>your message, GMPLS wouldn't fit the ASON model... :-( >> >>It's good to know this beforehand... no need then to consider this further... >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over >>the last 10 months... hope it's different however. >> >>Regards, >> >>Maarten >>PS. when I wrote my reply to Yanhe there was no frustation... and their isn't >>today either... >> >>"Mannie, Eric" wrote: >> >>>Hi Maarten and Zhi, >>> >>>I have the feeling that you are inventing a new model with a new protocol. >>>This is not how GMPLS works. I understand your frustrations and I have the >>>feeling that your ideas should be addressed somewhere else rather than >>>trying to change a model that we are finalizing and that we got from the >>>MPLS model. >>> >>>There are maybe 1000 ways of designing a control plane for transmission >>>networks. I would suggest that you first develop your own model and then >>>that we compare the two. >>> >>>Please, don't forget that we have here to be constructive in terms of GMPLS. >>>We have final discussions about the core GMPLS signaling, this is not the >>>beginning but the end of an (intermediate) phase. >>> >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your >>>house :-) We know it. Personally, I don't believe in the ultimate model and >>>protocol that will do everything and that will take 10 years to be >>>specified, with abstract protocols, meta-models, etc. >>> >>>By the way, personally I don't see any benefit of defining these >>>meta-models, abstract models and abstract protocols. It is hard to >>>understand for non super-expert and it is a complete loss of time for the >>>readers. I prefer practical solutions. >>> >>>I am also seeing discussions that we already have many times in the past. I >>>don't see any benefit of having them again, and again, and again. If we >>>continue like this we will all implement a tool to answer automatically with >>>our previous e-mails :-) >>> >>>Ok, there is a small set of people that don't like the way that GMPLS is >>>designed and defined (always the same 4 or 5 people by the way) - that's >>>100% your right guys and I respect it. In comparison with the hundreds >>>(thousands ?) of people that are working on GMPLS and implementing it, this >>>is a great achievement ! >>> >>>So, I ask you the question: what do you want to achieve personally at this >>>stage ? Don't you think that sometimes it is needed to finish one step, >>>before going to the next one ? >>> >>>Kind regards, >>> >>>Eric >>> >>>-----Original Message----- >>>From: Maarten Vissers [mailto:mvissers@lucent.com] >>>Sent: Monday, October 22, 2001 11:07 PM >>>To: Yanhe Fan >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... >>> >>>Yanhe, >>> >>>The situation Zhi describes is one that will be very typical in the optical >>>(SDH/SONET) network in the coming years. We will most likely see islands of >>>switched subnetworks interconnected via the existing SDH/SONET non-switched >>>networks. By means of management actions, links (GMPLS: link bundles) will >>>be >>>setup between an edge node in one switched subnetwork and an other edge node >>>in >>>the next switched subnetwork. In G.805 terminology, these links are so >>>called >>>serial compound links. >>> >>>The switched subnetworks will treat these serial compound links as normal >>>links, >>>"ignoring" the intermediate non-switched nodes they traverse. These links >>>will >>>contain a fixed set of link connections, which are identified by their >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz). >>>The server signal that carries the e.g. 5 STS1 link connections in the link >>>at A >>>can be an OC12, whereas this can be an OC48 at Z. >>> >>>During discovery or by means of provisioning both A and Z nodes get aware of >>>the >>>5 sTS1 link connections as tuples of e.g. >>> >>> SNPa SNPz >>>----------------------------------- >>>- port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) >>>- port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) >>>- port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) >>>- port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) >>>- port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) >>> >>>As both ends of the link build up this same relation information, it is >>>possible >>>to use as link connection identifier only one of the two SNPs. E.g. node A >>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this >>>info >>>to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". >>>Vice >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when >>>received >>>by node A, this will be converted into Ai/T1. >>> >>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot at >>>both ends of the link connection, only the timeslot at the sending end. The >>>receiving end needs to convert this then into its local timeslot number. >>> >>>Regards, >>> >>>Maarten >>> >>>Yanhe Fan wrote: >>> >>>>Hi Zhi, >>>> >>>>What B does is breaking the label association between A and C by crossing >>>>connect >>>>the time slots. >>>> >>>>If the cross connect performed by B is fixed (in your case), what needs to >>>>do is >>>>just to rebuild the label association by configuration or a protocol such >>>> >>>as >>> >>>>LMP; >>>>If the cross connect is not fixed but dynamic, the best thing to do is to >>>>make B >>>>a GMPLS speaker. >>>> >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's transport >>>network... no chance... those will stay non-switched... >>> >>> >>>>Yanhe >>>> >>>>-----Original Message----- >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >>>>Sent: Friday, October 19, 2001 6:01 PM >>>>To: Yanhe Fan >>>>Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>>Subject: Re: Moving right along ... >>>> >>>>Hi Yanhe, >>>> >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It >>>>is simply part of the network that made up the "dumb" pipe. And because >>>>the control plane control channel is separate, A and C can be adjacent >>>>without ever knowing who B is or that even B existed. From A and C's >>>>point of view, the network looks like: >>>> >>>> A ----- C >>>> >>>>Think of the case of how a BGP sees an area. If an area is made up of: >>>> >>>> A -- B -- C >>>> >>>>and B is internal router, does BGP "see" B? >>>> >>>>Zhi >>>> >>>>Yanhe Fan wrote: >>>> >>>> >>>>>Hi, Zhi >>>>> >>>>> >>>>> >>>>>>For the label value for SONET/SDH or the label description in the >>>>>>generic draft, the label is defined as directly representing the >>>>>>"timeslot". Now if I have a control plane controlled transport network >>>>>>that goes through a ADM that is not control plane controlled, as: >>>>>> >>>>>> >>>>>>+--------+ +--------+ +--------+ >>>>>>| | ---1--------- | | ----1-------- | | >>>>>>| | ---2--------- | | ----2-------- | | >>>>>>| A | ---3--------- | B | ----3-------- | C | >>>>>>| | ---4--------- | | ----4-------- | | >>>>>>| | ---5--------- | | ----5-------- | | >>>>>>+--------+ +--------+ +--------+ >>>>>> >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >>>>>>has labels 1,2,3,4,5 incoming. >>>>>> >>>>>>Now imagine that at B, it actually has a fixed cross-connect that >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. >>>>>> >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1". >>>>>>However, the connection/LSP associated with timeslot "1" is actually the >>>>>>label of timeslot "2" at C. >>>>>> >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node >>>>> >>>(B) >>> >>>>>which can't understand GMPLS. >>>>> >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using >>>>>GMPLS if B can't understand GMPLS? >>>>> >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't >>>>>understand >>>>>MPLS), can you setup an LSP A-B-C? >>>>> >>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't >>>>>understand PNNI at all? >>>>> >>>>>My point is that in order to make you case work, some additional work >>>>> >>>need >>> >>>>>to >>>>>be done besie simply using GMPLS as singnaling protocol, becase some >>>>> >>>node >>> >>>>on >>>> >>>>>the path is not GMPLS speakers. A and C needs the info of time slot >>>>> >>>>aligment >>>> >>>>>between them. This can be done by some configurations, some link >>>>> >>>>management >>>> >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info, >>>>>eveything >>>>>works fine. >>>>> >>>>>Yanhe >>>>> >>>>> > > -- > Irfan Lateef > Village Networks Inc, > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Oct 2001 00:12:53 -0700 Message-ID: <3BD66976.70406@lucent.com> Date: Wed, 24 Oct 2001 03:10:46 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Irfan Lateef CC: kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Irfan, good summary! I think (b) is probably right for some. I don't see (c) as been the case... From one uninformed reader to another, I think the quote you had was a frustrated person stating what he thinks was implied by another frustrated person's statement (am I putting words in anyone's mouth?). From what I understand G.ason and G.dcm is developed to describe the process and the minimal requirements needed to support a basic switched transport service. GMPLS is a protocol specific implementation that will likely meet many of the requirements, and may have some minor areas that it does not meet. Then the question to ask (as with any requirements and architecture work -- I'm sure we all have architects in our company) is: how critical are the requirements that may not be met and what changes are needed to GMPLS (if any) in order to meet them? The last few email exchanges I think has been process related: why are things added to GMPLS, who has authority to add. Why can't we make GMPLS drafts more clear to people reading these drafts? Of course there were also some fundamental issues, such as Juergen's desire to align the labels (which I agree with), Yangguang's question of why we are taking a fundamentally different approach for recovery since the "transport world" has done it one way for a long time and now it's suddenly changed & and authors not willing to discuss why the "traditional" way is not desired, and of course my desire to add clarifying text to the document to help uninformed reader like myself understand what SONET/SDH is all about (which is probably purely political rambling...) Zhi Irfan Lateef wrote: > A view from the side lines > ------------------------------- > > First, on the lighter side I have the following suggestion. > we should change the subject line to any of the following, > a. Stubbornly stuck - refusing to move forward > b. Political Ramblings > c. Serious Trouble > d. Ugly email war among adults behaving like kids > I vote for (b) > > Now on the serious side, I have a few questions. > > 1. Does the chair of this WG think that this email thread is a necessary > democratic step in the process. > > 2. If not, then why isn't somebody stepping in with a summary of issues > and resolving them. Isn't there any arbitration process. > > 3. If the protocols are designed to be flexible to accomadate future changes, > why aren't the authors treating "some of the" requests as part of the flexibility > > and getting along. > > 4. I feel the authors were treating last call as a formality and are not ready > to accept changes because it is a last call. Then what is the real intent of > last call. > > 5. There seems to be a real disconnect between the needs of, > a. vendors and service providers > b. data vendors and transport vendors > If GMPLS is for at least this three groups, then the issues need to be > resolved to the satisfaction of this small set. > (I personally agree with not spending 10 years trying to develop a panacea for > all) > > 6. And finally it is alarming to me to note the following assertion. > "GMPLS wouldn't fit the ASON model... :-( " > Can someone clarify the true import of this statement. My understanding was > GMPLS is > the only thing on which ITU,OIF and IETF are on the same page. Can you please > correct > me on this and clarify as am a truly "uninformed" person on this. > > Regards, > Irfan Lateef > > Maarten Vissers wrote: > > >>Eric, >> >>What you refer to as "our own model" is already developed by ITU-T SG15... it is >>in G.8080 (ex. G.ason) and other ASON related recommendations which will be >>approved later this week. We are also entering the next phase in ASON >>development; a phase in which protocol specific details will be defined. A >>proposal to use PNNI as a basis is accepted... and expected in the near future >>is a proposal to use also GMPLS as a 2nd protocol version... but if I understand >>your message, GMPLS wouldn't fit the ASON model... :-( >> >>It's good to know this beforehand... no need then to consider this further... >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over >>the last 10 months... hope it's different however. >> >>Regards, >> >>Maarten >>PS. when I wrote my reply to Yanhe there was no frustation... and their isn't >>today either... >> >>"Mannie, Eric" wrote: >> >>>Hi Maarten and Zhi, >>> >>>I have the feeling that you are inventing a new model with a new protocol. >>>This is not how GMPLS works. I understand your frustrations and I have the >>>feeling that your ideas should be addressed somewhere else rather than >>>trying to change a model that we are finalizing and that we got from the >>>MPLS model. >>> >>>There are maybe 1000 ways of designing a control plane for transmission >>>networks. I would suggest that you first develop your own model and then >>>that we compare the two. >>> >>>Please, don't forget that we have here to be constructive in terms of GMPLS. >>>We have final discussions about the core GMPLS signaling, this is not the >>>beginning but the end of an (intermediate) phase. >>> >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your >>>house :-) We know it. Personally, I don't believe in the ultimate model and >>>protocol that will do everything and that will take 10 years to be >>>specified, with abstract protocols, meta-models, etc. >>> >>>By the way, personally I don't see any benefit of defining these >>>meta-models, abstract models and abstract protocols. It is hard to >>>understand for non super-expert and it is a complete loss of time for the >>>readers. I prefer practical solutions. >>> >>>I am also seeing discussions that we already have many times in the past. I >>>don't see any benefit of having them again, and again, and again. If we >>>continue like this we will all implement a tool to answer automatically with >>>our previous e-mails :-) >>> >>>Ok, there is a small set of people that don't like the way that GMPLS is >>>designed and defined (always the same 4 or 5 people by the way) - that's >>>100% your right guys and I respect it. In comparison with the hundreds >>>(thousands ?) of people that are working on GMPLS and implementing it, this >>>is a great achievement ! >>> >>>So, I ask you the question: what do you want to achieve personally at this >>>stage ? Don't you think that sometimes it is needed to finish one step, >>>before going to the next one ? >>> >>>Kind regards, >>> >>>Eric >>> >>>-----Original Message----- >>>From: Maarten Vissers [mailto:mvissers@lucent.com] >>>Sent: Monday, October 22, 2001 11:07 PM >>>To: Yanhe Fan >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... >>> >>>Yanhe, >>> >>>The situation Zhi describes is one that will be very typical in the optical >>>(SDH/SONET) network in the coming years. We will most likely see islands of >>>switched subnetworks interconnected via the existing SDH/SONET non-switched >>>networks. By means of management actions, links (GMPLS: link bundles) will >>>be >>>setup between an edge node in one switched subnetwork and an other edge node >>>in >>>the next switched subnetwork. In G.805 terminology, these links are so >>>called >>>serial compound links. >>> >>>The switched subnetworks will treat these serial compound links as normal >>>links, >>>"ignoring" the intermediate non-switched nodes they traverse. These links >>>will >>>contain a fixed set of link connections, which are identified by their >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz). >>>The server signal that carries the e.g. 5 STS1 link connections in the link >>>at A >>>can be an OC12, whereas this can be an OC48 at Z. >>> >>>During discovery or by means of provisioning both A and Z nodes get aware of >>>the >>>5 sTS1 link connections as tuples of e.g. >>> >>> SNPa SNPz >>>----------------------------------- >>>- port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) >>>- port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) >>>- port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) >>>- port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) >>>- port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) >>> >>>As both ends of the link build up this same relation information, it is >>>possible >>>to use as link connection identifier only one of the two SNPs. E.g. node A >>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this >>>info >>>to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". >>>Vice >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when >>>received >>>by node A, this will be converted into Ai/T1. >>> >>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot at >>>both ends of the link connection, only the timeslot at the sending end. The >>>receiving end needs to convert this then into its local timeslot number. >>> >>>Regards, >>> >>>Maarten >>> >>>Yanhe Fan wrote: >>> >>>>Hi Zhi, >>>> >>>>What B does is breaking the label association between A and C by crossing >>>>connect >>>>the time slots. >>>> >>>>If the cross connect performed by B is fixed (in your case), what needs to >>>>do is >>>>just to rebuild the label association by configuration or a protocol such >>>> >>>as >>> >>>>LMP; >>>>If the cross connect is not fixed but dynamic, the best thing to do is to >>>>make B >>>>a GMPLS speaker. >>>> >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's transport >>>network... no chance... those will stay non-switched... >>> >>> >>>>Yanhe >>>> >>>>-----Original Message----- >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >>>>Sent: Friday, October 19, 2001 6:01 PM >>>>To: Yanhe Fan >>>>Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>>Subject: Re: Moving right along ... >>>> >>>>Hi Yanhe, >>>> >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It >>>>is simply part of the network that made up the "dumb" pipe. And because >>>>the control plane control channel is separate, A and C can be adjacent >>>>without ever knowing who B is or that even B existed. From A and C's >>>>point of view, the network looks like: >>>> >>>> A ----- C >>>> >>>>Think of the case of how a BGP sees an area. If an area is made up of: >>>> >>>> A -- B -- C >>>> >>>>and B is internal router, does BGP "see" B? >>>> >>>>Zhi >>>> >>>>Yanhe Fan wrote: >>>> >>>> >>>>>Hi, Zhi >>>>> >>>>> >>>>> >>>>>>For the label value for SONET/SDH or the label description in the >>>>>>generic draft, the label is defined as directly representing the >>>>>>"timeslot". Now if I have a control plane controlled transport network >>>>>>that goes through a ADM that is not control plane controlled, as: >>>>>> >>>>>> >>>>>>+--------+ +--------+ +--------+ >>>>>>| | ---1--------- | | ----1-------- | | >>>>>>| | ---2--------- | | ----2-------- | | >>>>>>| A | ---3--------- | B | ----3-------- | C | >>>>>>| | ---4--------- | | ----4-------- | | >>>>>>| | ---5--------- | | ----5-------- | | >>>>>>+--------+ +--------+ +--------+ >>>>>> >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >>>>>>has labels 1,2,3,4,5 incoming. >>>>>> >>>>>>Now imagine that at B, it actually has a fixed cross-connect that >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. >>>>>> >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1". >>>>>>However, the connection/LSP associated with timeslot "1" is actually the >>>>>>label of timeslot "2" at C. >>>>>> >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node >>>>> >>>(B) >>> >>>>>which can't understand GMPLS. >>>>> >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using >>>>>GMPLS if B can't understand GMPLS? >>>>> >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't >>>>>understand >>>>>MPLS), can you setup an LSP A-B-C? >>>>> >>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't >>>>>understand PNNI at all? >>>>> >>>>>My point is that in order to make you case work, some additional work >>>>> >>>need >>> >>>>>to >>>>>be done besie simply using GMPLS as singnaling protocol, becase some >>>>> >>>node >>> >>>>on >>>> >>>>>the path is not GMPLS speakers. A and C needs the info of time slot >>>>> >>>>aligment >>>> >>>>>between them. This can be done by some configurations, some link >>>>> >>>>management >>>> >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info, >>>>>eveything >>>>>works fine. >>>>> >>>>>Yanhe >>>>> >>>>> > > -- > Irfan Lateef > Village Networks Inc, > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 17:55:29 -0700 From: "Susumu Yoneda" To: "Yakov Rekhter" , "Lazer, Monica A, NNAD" Cc: , Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Wed, 24 Oct 2001 09:54:39 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, I would like to address one of carrier's perspective. We will deploy GMPLS in next year. However, we do not expect GMPLS to support all services for all people. We are looking at future services and applications, which are basically unknown. Therefore, GMPLS should be flexible enough to incorporate future needs when they become clear. At that point, if some migrations of existing service controls into GMPLS become economical, then we will do so. OW, the current control will be fine with us. Do I have confused all of you? Thank you, Best Regards. Susumu -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Yakov Rekhter Sent: Wednesday, October 24, 2001 12:17 AM To: Lazer, Monica A, NNAD Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Monica, > All, > I am in full agreement with Shehzad. From a carrier's perspective, the value > of the control plane is in taking over specific functions which currently > reside in OSSs outside of the network itself. Having only some applications, > but not others of the given function move into the network greatly > diminishes the value of having that function supported in the control plane. > To be more specific, if out of n services supported by the transport > network, the control plane supports automated provisioning of 1/2n services > and the other 1/2n need support in the OSS, we still need to do the OSS work > for the given transport technology. So from a cost perspective, now we have > to ask ourselves whether we should pay for the provisioning function twice. While what you said makes sense from a given carrier's perspective, we need to take a broader view, as producing a "perfect solution" that meets *all* the requirements of *all* the carriers is an explicit non-goal of GMPLS. With this in mind, if the 1/2n services that aren't supported by the control plane are the services that are required by 90% of the carriers market, then indeed this is a problem. On the other hand, if these 1/2n services that aren't supported are the services required by only 10% of the carriers market, then this is quite acceptable. Understandably, the carriers who would fall into this 10% category could be quite unhappy about, and could even be quite vocal in expressing their dissatisfaction... Yakov. > Regards, > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] > Sent: Tuesday, October 23, 2001 6:25 AM > To: yakov@juniper.net > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > Subject: RE: Generalized Signaling - LSP Encoding Type expansion > > Yakov, > > See comments in-line > > > -----Original Message----- > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > Sent: 22 October 2001 21:12 > > To: Lazer, Monica A, NNAD > > Cc: ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > Monica, > > > > > Dimitri, > > > Actually, it may be more accurate to put it differently - if GMPLS > > supports > > > only a handful of the services running on a given transport network, > > than > > > its value as a network's control plane component is diminished. > > > > To be even more accurate, GMPLS value is diminished *in the context* > > of that particular transport network. And unless *all* providers > > are going to run *all possible services* on their transport networks > > (which is a somewhat unrealistic scenario), that means that the > > value of GMPLS as a network's control plane component would be > > diminished for *some*, but not *all* service providers. > > > > > > > [shehzad] > For a control plane not to support all the transport services capable of > being carried over an operator's network diminishes the value of that > particular control plane. What is the point of having transparent/optical > equipment capable of transporting both Gigabit Ethernet and Fiber Channel > (as an example), if provisioning was based on signalling that could only > support Gigabit Ethernet? > > This is a restriction for every provider regardless of whether a network is > a standalone one built for a large customer or a national network serving > multiple customers. The effective 'banning' of certain services that are > currently being offered by providers will unnecessarily damage the business > case for the adoption of GMPLS. > > > > > At the same time, it is important to keep in mind that being "all > > things for all people" (aka as "perfect solution") is one of the > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > *particular* provider GMPLS would *not* support *all* the services > > that this provider runs on its transport network. > > > > Yakov. > > > > > [Shehzad] > There is no technical reason why a GMPLS encoding type could not be > adopted for a recognised format such as Fiber Channel, as far as I am aware > the adoption of Fiber Channel is not likely to destroy the foundations of > GMPLS. > > On a more general point, is the support of transport technologies > within GMPLS signalling restricted to those that the authors of the GMPLS > drafts will allow? > > > > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > Sent: Monday, October 22, 2001 3:15 PM > > > To: Lazer, Monica A, NNAD > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > > > Fine. Now we know the following: GMPLS is really attractive for > > > carriers when it supports all transport technologies so it has > > > to support Fiber Channel as well. > > > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > > > Regards, > > > Dimitri. > > > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > > > Dimitri, > > > > I am just answering the PS question with this message. > > > > The short answer is yes. The long answer is that the GMPLS control > > plane > > > is > > > > really useful if it can support connection management for all the > > > transport > > > > services supported by the transport network using GMPLS. Therefore, > > the > > > > carrier services section for the NNI document to be posted on the OIF > > site > > > > within a few minutes and the next draft of the carrier requirements > > IETF > > > > draft will both contain references to support of Fiber Channel. > > > > Regards, > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > -----Original Message----- > > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > To: Ewart Tempest > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > expansion > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > > > If you take a look on the IEEE Standards you will see > > > > that GE is referred to as > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > > > So my question is what do you have in mind ? to separate > > > > these values ? > > > > > > > > Thanks, > > > > Dimitri. > > > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > > > ------- > > > > > > > > [1] From - http://standards.ieee.org > > > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > > augmentation of its operation, physical layer characteristics, > > repeater > > > > functions and management parameters for transfer of 802.3 and Ethernet > > > > format frames at 1,000 Mb/s. > > > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > > significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of CSMA/CD nodes, previous investment in > > > > research > > > > and development, and principles of network operation and management. > > > > > > > > [2] From - http://standards.ieee.org > > > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > > minimal augmentation of its operation, physical layer characteristics > > > > and management parameters for transfer of LLC and Ethernet format > > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > > standard. In addition to the traditional LAN space, add parameters and > > > > mechanisms that enable deployment of Ethernet over the Wide Area > > Network > > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > > payload > > > > rate. > > > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > > application space to include Wide Area Network links in order to > > provide > > > > a significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of 802.3 interfaces, previous investment in > > > > research > > > > and development, and principles of network operation and management. > > > > > > > > ------- > > > > > > > > > Ewart Tempest wrote: > > > > > > > > > > Lou, > > > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > > GE is not really covered by the existing Ethernet related encoding > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > Ewart > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2654.19"> > RE: Generalized Signaling - LSP Encoding Type expansion > > > >

All, >
I am in full agreement with Shehzad. From a = > carrier's perspective, the value of the control plane is in taking over = > specific functions which currently reside in OSSs outside of the = > network itself. Having only some applications, but not others of the = > given function move into the network greatly diminishes the value of = > having that function supported in the control plane. To be more = > specific, if out of n services supported by the transport network, the = > control plane supports automated provisioning  of 1/2n services = and the other 1/2n need support in the OSS, we still need to do the OSS = > work for the given transport technology. So from a cost perspective, = > now we have to ask ourselves whether we should pay for the provisioning = > function twice.

> >

Regards, >

> >

Monica A. Lazer >
Advanced Transport Technology and Architecture = > Planning >

> >

908 234 8462 >
mlazer@att.com >

>
> >

 -----Original Message----- >
From:   shehzad.mirza@bt.com [ HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = > >
Sent:   Tuesday, October 23, 2001 6:25 = > AM >
To:     yakov@juniper.net >
Cc:     Lazer, Monica A, NNAD; = > ccamp@ops.ietf.org >
Subject:        = > RE: Generalized Signaling - LSP Encoding Type expansion >

> >

Yakov, >

> >

See comments in-line >

> >

> -----Original Message----- >
> From: Yakov Rekhter = > [SMTP:yakov@juniper.net] >
> Sent: 22 October 2001 21:12 >
> To:   Lazer, Monica A, NNAD >
> Cc:   ccamp@ops.ietf.org >
> Subject:      Re: = > Generalized Signaling - LSP Encoding Type expansion >
> >
> Monica, >
> >
> > Dimitri, >
> > Actually, it may be more accurate to put = > it differently - if GMPLS >
> supports >
> > only a handful of the services running on = > a given transport network, >
> than >
> > its value as a network's control plane = > component is diminished. >
> >
> To be even more accurate, GMPLS value is = > diminished *in the context* >
> of that particular transport network. And = > unless *all* providers >
> are going to run *all possible services* on = > their transport networks >
> (which is a somewhat unrealistic scenario), = > that means that the >
> value of GMPLS as a network's control plane = > component would be >
> diminished for *some*, but not *all* service = > providers. >
> >
> >
> >
        SIZE=3D2>[shehzad]  >
For a control plane not to support all the transport = > services capable of >
being carried over an operator's network diminishes = > the value of that >
particular control plane.  What is the point of = > having transparent/optical >
equipment capable of transporting both Gigabit = > Ethernet and Fiber Channel >
(as an example), if provisioning was based on = > signalling that could only >
support Gigabit Ethernet? >

> >

This is a restriction for every provider regardless = > of whether a network is >
a standalone one built for a large customer or a = > national network serving >
multiple customers. The effective 'banning' of = > certain services that are >
currently being offered by providers will = > unnecessarily damage the business >
case for the adoption of GMPLS. >

>
>
> >

> At the same time, it is important to keep in = > mind that being "all >
> things for all people" (aka as = > "perfect solution") is one of the >
> *non-goals* of GMPLS. So, it shouldn't come as = > a surprise if for a >
> *particular* provider GMPLS would *not* support = > *all* the services >
> that this provider runs on its transport = > network. >
> >
> Yakov. >
> >
> >
        SIZE=3D2>[Shehzad] >
        There is = > no technical reason why a GMPLS encoding type could not be >
adopted for a recognised format such as Fiber = > Channel, as far as I am aware >
the adoption of Fiber Channel is not likely to = > destroy the foundations of >
GMPLS. >

> >

        On a more = > general point, is the support of transport technologies >
within GMPLS signalling restricted to those that the = > authors of the GMPLS >
drafts will allow? >
         = > >

>
>
>
>
> >

> > Monica A. Lazer >
> > Advanced Transport Technology and = > Architecture Planning >
> > >
> > 908 234 8462 >
> > mlazer@att.com >
> > >
> > >
> >  -----Original Message----- >
> > From:       = > Dimitri Papadimitriou >
> [ HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > triou@alcatel.be] >
>  >
> > Sent:       = > Monday, October 22, 2001 3:15 PM >
> > To: Lazer, Monica A, NNAD >
> > Cc: Ewart Tempest; lberger@movaz.com; = > ccamp@ops.ietf.org >
> > Subject:    Re: Generalized = > Signaling - LSP Encoding Type expansion >
> > >
> >  << File: Card for Dimitri = > Papadimitriou >> Hi Monica, >
> > >
> > Fine. Now we know the following: GMPLS is = > really attractive for >
> > carriers when it supports all transport = > technologies so it has >
> > to support Fiber Channel as well. >
> > >
> > I wasn't aware that Ewart was capable to = > read in your mind ;-) >
> > >
> > Regards, >
> > Dimitri. >
> > >
> > "Lazer, Monica A, NNAD" = > wrote: >
> > > >
> > > Dimitri, >
> > > I am just answering the PS question = > with this message. >
> > > The short answer is yes.  The = > long answer is that the GMPLS control >
> plane >
> > is >
> > > really useful if it can support = > connection management for all the >
> > transport >
> > > services supported by the transport = > network using GMPLS. Therefore, >
> the >
> > > carrier services section for the NNI = > document to be posted on the OIF >
> site >
> > > within a few minutes and the next = > draft of the carrier requirements >
> IETF >
> > > draft will both contain references to = > support of Fiber Channel. >
> > > Regards, >
> > > Monica A. Lazer >
> > > Advanced Transport Technology and = > Architecture Planning >
> > > >
> > > 908 234 8462 >
> > > mlazer@att.com >
> > > >
> > >  -----Original = > Message----- >
> > > From:   Dimitri = > Papadimitriou >
> [ HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > triou@alcatel.be] >
> > > Sent:   Monday, October 22, = > 2001 2:47 PM >
> > > To:     Ewart = > Tempest >
> > > Cc:     = > lberger@movaz.com; ccamp@ops.ietf.org >
> > > = > Subject:        Re: Generalized = > Signaling - LSP Encoding Type >
> expansion >
> > > >
> > >  << File: Card for Dimitri = > Papadimitriou >> Hi Ewart, >
> > > >
> > > If you take a look on the IEEE = > Standards you will see >
> > > that GE is referred to as >
> > > - 802.3z for 1Gbps (see below [1]) = > same exists for copper 802.3ab >
> > > - 802.3ae for 10Gbps (see below = > [2]) >
> > > >
> > > So my question is what do you have in = > mind ? to separate >
> > > these values ? >
> > > >
> > > Thanks, >
> > > Dimitri. >
> > > >
> > > PS: for FiberChannel sorry i am not = > an expert but is someone >
> > >     targeting to = > use GMPLS for FiberChannel LSP ? >
> > > >
> > > ------- >
> > > >
> > > [1] From - HREF=3D"http://standards.ieee.org" = > TARGET=3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define Carrier Sense = > Multiple Access with Collision >
> > > Detection (CSMA/CD) Media Access = > Control (MAC) parameters and minimal >
> > > augmentation of its operation, = > physical layer characteristics, >
> repeater >
> > > functions and management parameters = > for transfer of 802.3 and Ethernet >
> > > format frames at 1,000 Mb/s. >
> > > >
> > > Project purpose: The purpose of this = > project is to extend the 802.3 >
> > > protocol to an operating speed of = > 1,000 Mb/s in order to provide a >
> > > significant increase in bandwidth = > while maintaining maximum >
> > > compatibility >
> > > with the installed base of CSMA/CD = > nodes, previous investment in >
> > > research >
> > > and development, and principles of = > network operation and management. >
> > > >
> > > [2] From - HREF=3D"http://standards.ieee.org" = > TARGET=3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define 802.3 Media = > Access Control (MAC) parameters and >
> > > minimal augmentation of its = > operation, physical layer characteristics >
> > > and management parameters for = > transfer of LLC and Ethernet format >
> > > frames at 10 Gb/s using full duplex = > operation as defined in the 802.3 >
> > > standard. In addition to the = > traditional LAN space, add parameters and >
> > > mechanisms that enable deployment of = > Ethernet over the Wide Area >
> Network >
> > > operating at a data rate compatible = > with OC-192c and SDH VC-4-64c >
> > > payload >
> > > rate. >
> > > >
> > > Project purpose: The purpose of this = > project is to extend the 802.3 >
> > > protocol to an operating speed of 10 = > Gb/s and to expand the Ethernet >
> > > application space to include Wide = > Area Network links in order to >
> provide >
> > > a significant increase in bandwidth = > while maintaining maximum >
> > > compatibility >
> > > with the installed base of 802.3 = > interfaces, previous investment in >
> > > research >
> > > and development, and principles of = > network operation and management. >
> > > >
> > > ------- >
> > > >
> > > > Ewart Tempest wrote: >
> > > > >
> > > > Lou, >
> > > > >
> > > > Within section 3.1.1 of = > draft-ietf-mpls-generalized-signaling-06 can >
> > > > you please add additonal LSP = > Encoding Types for GE and FiberChannel. >
> > > > GE is not really covered by the = > existing Ethernet related encoding >
> > > > types, and FiberChannel is not = > covered at all. Thanks. >
> > > > >
> > > > Ewart >
> > >

> > > > ------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 17:23:59 -0700 Message-ID: <3BD60A46.29A1E3D@vill.com> Date: Tue, 23 Oct 2001 20:24:38 -0400 From: Irfan Lateef Organization: Village Networks Inc MIME-Version: 1.0 To: kireeti@juniper.net CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A view from the side lines ------------------------------- First, on the lighter side I have the following suggestion. we should change the subject line to any of the following, a. Stubbornly stuck - refusing to move forward b. Political Ramblings c. Serious Trouble d. Ugly email war among adults behaving like kids I vote for (b) Now on the serious side, I have a few questions. 1. Does the chair of this WG think that this email thread is a necessary democratic step in the process. 2. If not, then why isn't somebody stepping in with a summary of issues and resolving them. Isn't there any arbitration process. 3. If the protocols are designed to be flexible to accomadate future changes, why aren't the authors treating "some of the" requests as part of the flexibility and getting along. 4. I feel the authors were treating last call as a formality and are not ready to accept changes because it is a last call. Then what is the real intent of last call. 5. There seems to be a real disconnect between the needs of, a. vendors and service providers b. data vendors and transport vendors If GMPLS is for at least this three groups, then the issues need to be resolved to the satisfaction of this small set. (I personally agree with not spending 10 years trying to develop a panacea for all) 6. And finally it is alarming to me to note the following assertion. "GMPLS wouldn't fit the ASON model... :-( " Can someone clarify the true import of this statement. My understanding was GMPLS is the only thing on which ITU,OIF and IETF are on the same page. Can you please correct me on this and clarify as am a truly "uninformed" person on this. Regards, Irfan Lateef Maarten Vissers wrote: > Eric, > > What you refer to as "our own model" is already developed by ITU-T SG15... it is > in G.8080 (ex. G.ason) and other ASON related recommendations which will be > approved later this week. We are also entering the next phase in ASON > development; a phase in which protocol specific details will be defined. A > proposal to use PNNI as a basis is accepted... and expected in the near future > is a proposal to use also GMPLS as a 2nd protocol version... but if I understand > your message, GMPLS wouldn't fit the ASON model... :-( > > It's good to know this beforehand... no need then to consider this further... > feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over > the last 10 months... hope it's different however. > > Regards, > > Maarten > PS. when I wrote my reply to Yanhe there was no frustation... and their isn't > today either... > > "Mannie, Eric" wrote: > > > > Hi Maarten and Zhi, > > > > I have the feeling that you are inventing a new model with a new protocol. > > This is not how GMPLS works. I understand your frustrations and I have the > > feeling that your ideas should be addressed somewhere else rather than > > trying to change a model that we are finalizing and that we got from the > > MPLS model. > > > > There are maybe 1000 ways of designing a control plane for transmission > > networks. I would suggest that you first develop your own model and then > > that we compare the two. > > > > Please, don't forget that we have here to be constructive in terms of GMPLS. > > We have final discussions about the core GMPLS signaling, this is not the > > beginning but the end of an (intermediate) phase. > > > > Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your > > house :-) We know it. Personally, I don't believe in the ultimate model and > > protocol that will do everything and that will take 10 years to be > > specified, with abstract protocols, meta-models, etc. > > > > By the way, personally I don't see any benefit of defining these > > meta-models, abstract models and abstract protocols. It is hard to > > understand for non super-expert and it is a complete loss of time for the > > readers. I prefer practical solutions. > > > > I am also seeing discussions that we already have many times in the past. I > > don't see any benefit of having them again, and again, and again. If we > > continue like this we will all implement a tool to answer automatically with > > our previous e-mails :-) > > > > Ok, there is a small set of people that don't like the way that GMPLS is > > designed and defined (always the same 4 or 5 people by the way) - that's > > 100% your right guys and I respect it. In comparison with the hundreds > > (thousands ?) of people that are working on GMPLS and implementing it, this > > is a great achievement ! > > > > So, I ask you the question: what do you want to achieve personally at this > > stage ? Don't you think that sometimes it is needed to finish one step, > > before going to the next one ? > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, October 22, 2001 11:07 PM > > To: Yanhe Fan > > Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... > > > > Yanhe, > > > > The situation Zhi describes is one that will be very typical in the optical > > (SDH/SONET) network in the coming years. We will most likely see islands of > > switched subnetworks interconnected via the existing SDH/SONET non-switched > > networks. By means of management actions, links (GMPLS: link bundles) will > > be > > setup between an edge node in one switched subnetwork and an other edge node > > in > > the next switched subnetwork. In G.805 terminology, these links are so > > called > > serial compound links. > > > > The switched subnetworks will treat these serial compound links as normal > > links, > > "ignoring" the intermediate non-switched nodes they traverse. These links > > will > > contain a fixed set of link connections, which are identified by their > > respective endpoints at nodes A and Z (i.e. SNPa - SNPz). > > The server signal that carries the e.g. 5 STS1 link connections in the link > > at A > > can be an OC12, whereas this can be an OC48 at Z. > > > > During discovery or by means of provisioning both A and Z nodes get aware of > > the > > 5 sTS1 link connections as tuples of e.g. > > > > SNPa SNPz > > ----------------------------------- > > - port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) > > - port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) > > - port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) > > - port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) > > - port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) > > > > As both ends of the link build up this same relation information, it is > > possible > > to use as link connection identifier only one of the two SNPs. E.g. node A > > identifies the STS1 link connection #1 by means of "Ai/T1" and sends this > > info > > to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". > > Vice > > versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when > > received > > by node A, this will be converted into Ai/T1. > > > > For GMPLS this implies that the GMPLS label doesn't identify the timeslot at > > both ends of the link connection, only the timeslot at the sending end. The > > receiving end needs to convert this then into its local timeslot number. > > > > Regards, > > > > Maarten > > > > Yanhe Fan wrote: > > > > > > Hi Zhi, > > > > > > What B does is breaking the label association between A and C by crossing > > > connect > > > the time slots. > > > > > > If the cross connect performed by B is fixed (in your case), what needs to > > > do is > > > just to rebuild the label association by configuration or a protocol such > > as > > > LMP; > > > If the cross connect is not fixed but dynamic, the best thing to do is to > > > make B > > > a GMPLS speaker. > > > > Tell this to the 1.000.000+ SDH/SONET network elements in today's transport > > network... no chance... those will stay non-switched... > > > > > > > > Yanhe > > > > > > -----Original Message----- > > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > > Sent: Friday, October 19, 2001 6:01 PM > > > To: Yanhe Fan > > > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... > > > > > > Hi Yanhe, > > > > > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > > > is simply part of the network that made up the "dumb" pipe. And because > > > the control plane control channel is separate, A and C can be adjacent > > > without ever knowing who B is or that even B existed. From A and C's > > > point of view, the network looks like: > > > > > > A ----- C > > > > > > Think of the case of how a BGP sees an area. If an area is made up of: > > > > > > A -- B -- C > > > > > > and B is internal router, does BGP "see" B? > > > > > > Zhi > > > > > > Yanhe Fan wrote: > > > > > > > Hi, Zhi > > > > > > > > > > > >>For the label value for SONET/SDH or the label description in the > > > >>generic draft, the label is defined as directly representing the > > > >>"timeslot". Now if I have a control plane controlled transport network > > > >>that goes through a ADM that is not control plane controlled, as: > > > >> > > > >> > > > >>+--------+ +--------+ +--------+ > > > >>| | ---1--------- | | ----1-------- | | > > > >>| | ---2--------- | | ----2-------- | | > > > >>| A | ---3--------- | B | ----3-------- | C | > > > >>| | ---4--------- | | ----4-------- | | > > > >>| | ---5--------- | | ----5-------- | | > > > >>+--------+ +--------+ +--------+ > > > >> > > > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at > > > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C > > > >>has labels 1,2,3,4,5 incoming. > > > >> > > > >>Now imagine that at B, it actually has a fixed cross-connect that > > > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to > > > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > > > >> > > > >>Now when A GMPLS sends a message to C, the label it uses is "1". > > > >>However, the connection/LSP associated with timeslot "1" is actually the > > > >>label of timeslot "2" at C. > > > >> > > > > > > > > In this case, you're trying to use GMPLS to setup an LSP cross a node > > (B) > > > > which can't understand GMPLS. > > > > > > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > > > > GMPLS if B can't understand GMPLS? > > > > > > > > Now imagine A and B are LSRs, and B is a conventional router (can't > > > > understand > > > > MPLS), can you setup an LSP A-B-C? > > > > > > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > > > > understand PNNI at all? > > > > > > > > My point is that in order to make you case work, some additional work > > need > > > > to > > > > be done besie simply using GMPLS as singnaling protocol, becase some > > node > > > on > > > > the path is not GMPLS speakers. A and C needs the info of time slot > > > aligment > > > > > > > > between them. This can be done by some configurations, some link > > > management > > > > protocls (LMP maybe) etc. As long as A and C have this piece of info, > > > > eveything > > > > works fine. > > > > > > > > Yanhe > > > > -- Irfan Lateef Village Networks Inc, Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 17:12:14 -0700 Message-ID: <3BD606C6.FC903E95@nayna.com> Date: Tue, 23 Oct 2001 17:09:42 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Maarten Vissers CC: "Mannie, Eric" , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Marteen: Can you briefly summarize the differences you see between GMPLS architecture and ASON architecture? This has been asked by many of the folks at IETF. Regards, sudheer PS: I thought these mails were about label format and suddenly this is turning into an ITU versus IETF discussion :-( Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 15:59:36 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3BD5F533.B3F4FE6A@lucent.com> Date: Wed, 24 Oct 2001 00:54:44 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------8BC15EED8DAA848A85239179" This is a multi-part message in MIME format. --------------8BC15EED8DAA848A85239179 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, What you refer to as "our own model" is already developed by ITU-T SG15... it is in G.8080 (ex. G.ason) and other ASON related recommendations which will be approved later this week. We are also entering the next phase in ASON development; a phase in which protocol specific details will be defined. A proposal to use PNNI as a basis is accepted... and expected in the near future is a proposal to use also GMPLS as a 2nd protocol version... but if I understand your message, GMPLS wouldn't fit the ASON model... :-( It's good to know this beforehand... no need then to consider this further... feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over the last 10 months... hope it's different however. Regards, Maarten PS. when I wrote my reply to Yanhe there was no frustation... and their isn't today either... "Mannie, Eric" wrote: > > Hi Maarten and Zhi, > > I have the feeling that you are inventing a new model with a new protocol. > This is not how GMPLS works. I understand your frustrations and I have the > feeling that your ideas should be addressed somewhere else rather than > trying to change a model that we are finalizing and that we got from the > MPLS model. > > There are maybe 1000 ways of designing a control plane for transmission > networks. I would suggest that you first develop your own model and then > that we compare the two. > > Please, don't forget that we have here to be constructive in terms of GMPLS. > We have final discussions about the core GMPLS signaling, this is not the > beginning but the end of an (intermediate) phase. > > Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your > house :-) We know it. Personally, I don't believe in the ultimate model and > protocol that will do everything and that will take 10 years to be > specified, with abstract protocols, meta-models, etc. > > By the way, personally I don't see any benefit of defining these > meta-models, abstract models and abstract protocols. It is hard to > understand for non super-expert and it is a complete loss of time for the > readers. I prefer practical solutions. > > I am also seeing discussions that we already have many times in the past. I > don't see any benefit of having them again, and again, and again. If we > continue like this we will all implement a tool to answer automatically with > our previous e-mails :-) > > Ok, there is a small set of people that don't like the way that GMPLS is > designed and defined (always the same 4 or 5 people by the way) - that's > 100% your right guys and I respect it. In comparison with the hundreds > (thousands ?) of people that are working on GMPLS and implementing it, this > is a great achievement ! > > So, I ask you the question: what do you want to achieve personally at this > stage ? Don't you think that sometimes it is needed to finish one step, > before going to the next one ? > > Kind regards, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, October 22, 2001 11:07 PM > To: Yanhe Fan > Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Yanhe, > > The situation Zhi describes is one that will be very typical in the optical > (SDH/SONET) network in the coming years. We will most likely see islands of > switched subnetworks interconnected via the existing SDH/SONET non-switched > networks. By means of management actions, links (GMPLS: link bundles) will > be > setup between an edge node in one switched subnetwork and an other edge node > in > the next switched subnetwork. In G.805 terminology, these links are so > called > serial compound links. > > The switched subnetworks will treat these serial compound links as normal > links, > "ignoring" the intermediate non-switched nodes they traverse. These links > will > contain a fixed set of link connections, which are identified by their > respective endpoints at nodes A and Z (i.e. SNPa - SNPz). > The server signal that carries the e.g. 5 STS1 link connections in the link > at A > can be an OC12, whereas this can be an OC48 at Z. > > During discovery or by means of provisioning both A and Z nodes get aware of > the > 5 sTS1 link connections as tuples of e.g. > > SNPa SNPz > ----------------------------------- > - port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) > - port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) > - port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) > - port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) > - port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) > > As both ends of the link build up this same relation information, it is > possible > to use as link connection identifier only one of the two SNPs. E.g. node A > identifies the STS1 link connection #1 by means of "Ai/T1" and sends this > info > to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". > Vice > versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when > received > by node A, this will be converted into Ai/T1. > > For GMPLS this implies that the GMPLS label doesn't identify the timeslot at > both ends of the link connection, only the timeslot at the sending end. The > receiving end needs to convert this then into its local timeslot number. > > Regards, > > Maarten > > Yanhe Fan wrote: > > > > Hi Zhi, > > > > What B does is breaking the label association between A and C by crossing > > connect > > the time slots. > > > > If the cross connect performed by B is fixed (in your case), what needs to > > do is > > just to rebuild the label association by configuration or a protocol such > as > > LMP; > > If the cross connect is not fixed but dynamic, the best thing to do is to > > make B > > a GMPLS speaker. > > Tell this to the 1.000.000+ SDH/SONET network elements in today's transport > network... no chance... those will stay non-switched... > > > > > Yanhe > > > > -----Original Message----- > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > Sent: Friday, October 19, 2001 6:01 PM > > To: Yanhe Fan > > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... > > > > Hi Yanhe, > > > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > > is simply part of the network that made up the "dumb" pipe. And because > > the control plane control channel is separate, A and C can be adjacent > > without ever knowing who B is or that even B existed. From A and C's > > point of view, the network looks like: > > > > A ----- C > > > > Think of the case of how a BGP sees an area. If an area is made up of: > > > > A -- B -- C > > > > and B is internal router, does BGP "see" B? > > > > Zhi > > > > Yanhe Fan wrote: > > > > > Hi, Zhi > > > > > > > > >>For the label value for SONET/SDH or the label description in the > > >>generic draft, the label is defined as directly representing the > > >>"timeslot". Now if I have a control plane controlled transport network > > >>that goes through a ADM that is not control plane controlled, as: > > >> > > >> > > >>+--------+ +--------+ +--------+ > > >>| | ---1--------- | | ----1-------- | | > > >>| | ---2--------- | | ----2-------- | | > > >>| A | ---3--------- | B | ----3-------- | C | > > >>| | ---4--------- | | ----4-------- | | > > >>| | ---5--------- | | ----5-------- | | > > >>+--------+ +--------+ +--------+ > > >> > > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at > > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C > > >>has labels 1,2,3,4,5 incoming. > > >> > > >>Now imagine that at B, it actually has a fixed cross-connect that > > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to > > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > > >> > > >>Now when A GMPLS sends a message to C, the label it uses is "1". > > >>However, the connection/LSP associated with timeslot "1" is actually the > > >>label of timeslot "2" at C. > > >> > > > > > > In this case, you're trying to use GMPLS to setup an LSP cross a node > (B) > > > which can't understand GMPLS. > > > > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > > > GMPLS if B can't understand GMPLS? > > > > > > Now imagine A and B are LSRs, and B is a conventional router (can't > > > understand > > > MPLS), can you setup an LSP A-B-C? > > > > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > > > understand PNNI at all? > > > > > > My point is that in order to make you case work, some additional work > need > > > to > > > be done besie simply using GMPLS as singnaling protocol, becase some > node > > on > > > the path is not GMPLS speakers. A and C needs the info of time slot > > aligment > > > > > > between them. This can be done by some configurations, some link > > management > > > protocls (LMP maybe) etc. As long as A and C have this piece of info, > > > eveything > > > works fine. > > > > > > Yanhe > > > --------------8BC15EED8DAA848A85239179 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------8BC15EED8DAA848A85239179-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 13:52:23 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBBE@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Yakov Rekhter'" , shehzad.mirza@bt.com Cc: ccamp@ops.ietf.org Subject: RE: Generalized Signalling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 16:49:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yakov, More comments in line. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Tuesday, October 23, 2001 1:26 PM To: shehzad.mirza@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Generalized Signalling - LSP Encoding Type expansion Shehzad, > Yakov, > > The percentage of carriers that have all of their requirements met by the > current GMPLS drafts is an unknown. However the following points still > need to be addressed. > > 1. Why would an operator adopt GMPLS infrastructure if it only carried a > subset of the transport services that they are already offer to customers? > In effect spending more and getting less. It depends on the percentage of the total profit that could be generated by the subset. [[Lazer, AT&T]] This is neither here nor there, for a standards organization to decide. [[Lazer, AT&T]] Let me restate: a network element shall not require separate control plane for individual line cards (this will be a strong requirement). Service companies need to make their choices as to what the business case is for each service offering; individual equipment vendors will decide what specific services, line cards, or features to support on each NE. But it is not the role of a body to decide that only some services deserve to be supported by the control plane, while others are undeserving. This is not IETF's job! > 2. Why is there a problem reserving a code-point for a service that some > vendors may wish to implement on their GMPLS equipment? Presumably they > would not implement capability for which there is no demand. If all you ask is a code-point, this code point is relevant only to the LSPs' end-points, and not every GMPLS vendor is *required* to support this code-point, then I don't think there is a problem with doing this. [[Lazer, AT&T]] Clearly not every GMPLS vendor would be required to support every service. Every vendor claiming support of GMPLS on the NE will be asked whether that applies to all the interfaces and services supported by the NE. I believe that code points will be relevant to subnetwork inter-connection points too, not only the network edges. Let me re-iterate, every vendor needs to make its own decision as to what needs to be supported in the NEs they sell. Every carrier makes its decision as to what to support in the networks they deploy. > 3. What is the process by which certain transport services are decided > suitable for inclusion into the GMPLS specifications/drafts? It seems that > inclusion of additional services fraught with difficulties, this is likely > to get worse when the drafts turn into specifications. The types of services that would be suitable for inclusion are the services that (a) would *not* require changes/upgrades to the GMPLS core, and (b) would not require every GMPLS vendor to implement every service. [[Lazer, AT&T]] So what you are saying is that every carrier will need to beg for IETF's blessing for every new service if GMPLS will be the architecture of choice for control plane? Let me state something else again: If IETF forces GMPLS to be an architecture where control plane support for some services needs to be separate from the control plane for some of its other services, than IETF ensures that GMPLS has a diminished value. GMPLS is not just a protocol. It is a distributed control plane architecture using a suite of protocols. If this architecture makes it very hard to evolve the control plane in step with the data plane, than this architecture needs a lot of work. Monica Yakov. > > > > Shehzad > > > > > -----Original Message----- > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > Sent: 23 October 2001 16:17 > > To: Lazer, Monica A, NNAD > > Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > Monica, > > > > > All, > > > I am in full agreement with Shehzad. From a carrier's perspective, the > > value > > > of the control plane is in taking over specific functions which > > currently > > > reside in OSSs outside of the network itself. Having only some > > applications, > > > but not others of the given function move into the network greatly > > > diminishes the value of having that function supported in the control > > plane. > > > To be more specific, if out of n services supported by the transport > > > network, the control plane supports automated provisioning of 1/2n > > services > > > and the other 1/2n need support in the OSS, we still need to do the OSS > > work > > > for the given transport technology. So from a cost perspective, now we > > have > > > to ask ourselves whether we should pay for the provisioning function > > twice. > > > > While what you said makes sense from a given carrier's perspective, > > we need to take a broader view, as producing a "perfect solution" > > that meets *all* the requirements of *all* the carriers is an > > explicit non-goal of GMPLS. With this in mind, if the 1/2n services > > that aren't supported by the control plane are the services that > > are required by 90% of the carriers market, then indeed this is a > > problem. On the other hand, if these 1/2n services that aren't > > supported are the services required by only 10% of the carriers > > market, then this is quite acceptable. Understandably, the carriers > > who would fall into this 10% category could be quite unhappy about, > > and could even be quite vocal in expressing their dissatisfaction... > > > > Yakov. > > > > > Regards, > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > > > > -----Original Message----- > > > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] > > > Sent: Tuesday, October 23, 2001 6:25 AM > > > To: yakov@juniper.net > > > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > > > Subject: RE: Generalized Signaling - LSP Encoding Type expansion > > > > > > Yakov, > > > > > > See comments in-line > > > > > > > -----Original Message----- > > > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > > > Sent: 22 October 2001 21:12 > > > > To: Lazer, Monica A, NNAD > > > > Cc: ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > > > Monica, > > > > > > > > > Dimitri, > > > > > Actually, it may be more accurate to put it differently - if GMPLS > > > > supports > > > > > only a handful of the services running on a given transport network, > > > > than > > > > > its value as a network's control plane component is diminished. > > > > > > > > To be even more accurate, GMPLS value is diminished *in the context* > > > > of that particular transport network. And unless *all* providers > > > > are going to run *all possible services* on their transport networks > > > > (which is a somewhat unrealistic scenario), that means that the > > > > value of GMPLS as a network's control plane component would be > > > > diminished for *some*, but not *all* service providers. > > > > > > > > > > > > > > > [shehzad] > > > For a control plane not to support all the transport services capable of > > being carried over an operator's network diminishes the value of that > > > particular control plane. What is the point of having > > transparent/optical > > > equipment capable of transporting both Gigabit Ethernet and Fiber > > Channel > > > (as an example), if provisioning was based on signalling that could only > > > support Gigabit Ethernet? > > > > > > This is a restriction for every provider regardless of whether a network > > is > > > a standalone one built for a large customer or a national network > > serving > > > multiple customers. The effective 'banning' of certain services that are > > > currently being offered by providers will unnecessarily damage the > > business > > > case for the adoption of GMPLS. > > > > > > > > > > > > > At the same time, it is important to keep in mind that being "all > > > > things for all people" (aka as "perfect solution") is one of the > > > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > > > *particular* provider GMPLS would *not* support *all* the services > > > > that this provider runs on its transport network. > > > > > > > > Yakov. > > > > > > > > > > > [Shehzad] > > > There is no technical reason why a GMPLS encoding type could not be > > > adopted for a recognised format such as Fiber Channel, as far as I am > > aware > > > the adoption of Fiber Channel is not likely to destroy the foundations > > of > > > GMPLS. > > > > > > On a more general point, is the support of transport technologies > > > within GMPLS signalling restricted to those that the authors of the > > GMPLS > > > drafts will allow? > > > > > > > > > > > > > > > > > > > > > > > Monica A. Lazer > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > 908 234 8462 > > > > > mlazer@att.com > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dimitri Papadimitriou > > > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > > > > > Sent: Monday, October 22, 2001 3:15 PM > > > > > To: Lazer, Monica A, NNAD > > > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > expansion > > > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > > > > > > > Fine. Now we know the following: GMPLS is really attractive for > > > > > carriers when it supports all transport technologies so it has > > > > > to support Fiber Channel as well. > > > > > > > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > > > > > > > Regards, > > > > > Dimitri. > > > > > > > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > > > > > > > Dimitri, > > > > > > I am just answering the PS question with this message. > > > > > > The short answer is yes. The long answer is that the GMPLS > > control > > > > plane > > > > > is > > > > > > really useful if it can support connection management for all the > > > > > transport > > > > > > services supported by the transport network using GMPLS. > > Therefore, > > > > the > > > > > > carrier services section for the NNI document to be posted on the > > OIF > > > > site > > > > > > within a few minutes and the next draft of the carrier > > requirements > > > > IETF > > > > > > draft will both contain references to support of Fiber Channel. > > > > > > Regards, > > > > > > Monica A. Lazer > > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > > > 908 234 8462 > > > > > > mlazer@att.com > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dimitri Papadimitriou > > > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > > > To: Ewart Tempest > > > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > > > expansion > > > > > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > > > > > > > If you take a look on the IEEE Standards you will see > > > > > > that GE is referred to as > > > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > > > > > > > So my question is what do you have in mind ? to separate > > > > > > these values ? > > > > > > > > > > > > Thanks, > > > > > > Dimitri. > > > > > > > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > > > > > > > ------- > > > > > > > > > > > > [1] From - http://standards.ieee.org > > > > > > > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and > > minimal > > > > > > augmentation of its operation, physical layer characteristics, > > > > repeater > > > > > > functions and management parameters for transfer of 802.3 and > > Ethernet > > > > > > format frames at 1,000 Mb/s. > > > > > > > > > > > > Project purpose: The purpose of this project is to extend the > > 802.3 > > > > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > > > > significant increase in bandwidth while maintaining maximum > > > > > > compatibility > > > > > > with the installed base of CSMA/CD nodes, previous investment in > > > > > > research > > > > > > and development, and principles of network operation and > > management. > > > > > > > > > > > > [2] From - http://standards.ieee.org > > > > > > > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters > > and > > > > > > minimal augmentation of its operation, physical layer > > characteristics > > > > > > and management parameters for transfer of LLC and Ethernet format > > > > > > frames at 10 Gb/s using full duplex operation as defined in the > > 802.3 > > > > > > standard. In addition to the traditional LAN space, add parameters > > and > > > > > > mechanisms that enable deployment of Ethernet over the Wide Area > > > > Network > > > > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > > > > payload > > > > > > rate. > > > > > > > > > > > > Project purpose: The purpose of this project is to extend the > > 802.3 > > > > > > protocol to an operating speed of 10 Gb/s and to expand the > > Ethernet > > > > > > application space to include Wide Area Network links in order to > > > > provide > > > > > > a significant increase in bandwidth while maintaining maximum > > > > > > compatibility > > > > > > with the installed base of 802.3 interfaces, previous investment > > in > > > > > > research > > > > > > and development, and principles of network operation and > > management. > > > > > > > > > > > > ------- > > > > > > > > > > > > > Ewart Tempest wrote: > > > > > > > > > > > > > > Lou, > > > > > > > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 > > can > > > > > > > you please add additonal LSP Encoding Types for GE and > > FiberChannel. > > > > > > > GE is not really covered by the existing Ethernet related > > encoding > > > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > > > > > Ewart > > > > > > > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650 > > > Content-Type: text/html; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > 5.5.2654.19"> > > > RE: Generalized Signaling - LSP Encoding Type expansion > > > > > > > > > > > >

All, > > >
I am in full agreement with Shehzad. From a = > > > carrier's perspective, the value of the control plane is in taking over > > = > > > specific functions which currently reside in OSSs outside of the = > > > network itself. Having only some applications, but not others of the = > > > given function move into the network greatly diminishes the value of = > > > having that function supported in the control plane. To be more = > > > specific, if out of n services supported by the transport network, the = > > > control plane supports automated provisioning  of 1/2n services = > > and the other 1/2n need support in the OSS, we still need to do the OSS = > > > work for the given transport technology. So from a cost perspective, = > > > now we have to ask ourselves whether we should pay for the provisioning > > = > > > function twice.

> > > > > >

Regards, > > >

> > > > > >

Monica A. Lazer > > >
Advanced Transport Technology and Architecture = > > > Planning > > >

> > > > > >

908 234 8462 > > >
mlazer@att.com > > >

> > >
> > > > > >

 -----Original Message----- > > >
From:   shehzad.mirza@bt.com [ > > HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = > > > > > >
Sent:   Tuesday, October 23, 2001 6:25 = > > > AM > > >
To:     yakov@juniper.net > > >
Cc:     Lazer, Monica A, NNAD; = > > > ccamp@ops.ietf.org > > >
Subject:        = > > > RE: Generalized Signaling - LSP Encoding Type expansion > > >

> > > > > >

Yakov, > > >

> > > > > >

See comments in-line > > >

> > > > > >

> -----Original Message----- > > >
> From: Yakov Rekhter = > > > [SMTP:yakov@juniper.net] > > >
> Sent: 22 October 2001 21:12 > > >
> To:   Lazer, Monica A, NNAD > > >
> Cc:   ccamp@ops.ietf.org > > >
> Subject:      Re: = > > > Generalized Signaling - LSP Encoding Type expansion > > >
> > > >
> Monica, > > >
> > > >
> > Dimitri, > > >
> > Actually, it may be more accurate to put = > > > it differently - if GMPLS > > >
> supports > > >
> > only a handful of the services running on = > > > a given transport network, > > >
> than > > >
> > its value as a network's control plane = > > > component is diminished. > > >
> > > >
> To be even more accurate, GMPLS value is = > > > diminished *in the context* > > >
> of that particular transport network. And = > > > unless *all* providers > > >
> are going to run *all possible services* on = > > > their transport networks > > >
> (which is a somewhat unrealistic scenario), = > > > that means that the > > >
> value of GMPLS as a network's control plane = > > > component would be > > >
> diminished for *some*, but not *all* service = > > > providers. > > >
> > > >
> > > >
> > > >
        > > SIZE=3D2>[shehzad]  > > >
For a control plane not to support all the transport > > = > > > services capable of > > >
being carried over an operator's network diminishes = > > > the value of that > > >
particular control plane.  What is the point of > > = > > > having transparent/optical > > >
equipment capable of transporting both Gigabit = > > > Ethernet and Fiber Channel > > >
(as an example), if provisioning was based on = > > > signalling that could only > > >
support Gigabit Ethernet? > > >

> > > > > >

This is a restriction for every provider regardless = > > > of whether a network is > > >
a standalone one built for a large customer or a = > > > national network serving > > >
multiple customers. The effective 'banning' of = > > > certain services that are > > >
currently being offered by providers will = > > > unnecessarily damage the business > > >
case for the adoption of GMPLS. > > >

> > >
> > >
> > > > > >

> At the same time, it is important to keep in = > > > mind that being "all > > >
> things for all people" (aka as = > > > "perfect solution") is one of the > > >
> *non-goals* of GMPLS. So, it shouldn't come as = > > > a surprise if for a > > >
> *particular* provider GMPLS would *not* support > > = > > > *all* the services > > >
> that this provider runs on its transport = > > > network. > > >
> > > >
> Yakov. > > >
> > > >
> > > >
        > > SIZE=3D2>[Shehzad] > > >
        There is = > > > no technical reason why a GMPLS encoding type could not be > > >
adopted for a recognised format such as Fiber = > > > Channel, as far as I am aware > > >
the adoption of Fiber Channel is not likely to = > > > destroy the foundations of > > >
GMPLS. > > >

> > > > > >

        On a more = > > > general point, is the support of transport technologies > > >
within GMPLS signalling restricted to those that the > > = > > > authors of the GMPLS > > >
drafts will allow? > > >
         = > > > > > >

> > >
> > >
> > >
> > >
> > > > > >

> > Monica A. Lazer > > >
> > Advanced Transport Technology and = > > > Architecture Planning > > >
> > > > >
> > 908 234 8462 > > >
> > mlazer@att.com > > >
> > > > >
> > > > >
> >  -----Original Message----- > > >
> > From:       = > > > Dimitri Papadimitriou > > >
> [ > > > > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > > > triou@alcatel.be] > > >
>  > > >
> > Sent:       = > > > Monday, October 22, 2001 3:15 PM > > >
> > To: Lazer, Monica A, NNAD > > >
> > Cc: Ewart Tempest; lberger@movaz.com; = > > > ccamp@ops.ietf.org > > >
> > Subject:    Re: Generalized > > = > > > Signaling - LSP Encoding Type expansion > > >
> > > > >
> >  << File: Card for Dimitri = > > > Papadimitriou >> Hi Monica, > > >
> > > > >
> > Fine. Now we know the following: GMPLS is = > > > really attractive for > > >
> > carriers when it supports all transport = > > > technologies so it has > > >
> > to support Fiber Channel as well. > > >
> > > > >
> > I wasn't aware that Ewart was capable to = > > > read in your mind ;-) > > >
> > > > >
> > Regards, > > >
> > Dimitri. > > >
> > > > >
> > "Lazer, Monica A, NNAD" = > > > wrote: > > >
> > > > > >
> > > Dimitri, > > >
> > > I am just answering the PS question = > > > with this message. > > >
> > > The short answer is yes.  The = > > > long answer is that the GMPLS control > > >
> plane > > >
> > is > > >
> > > really useful if it can support = > > > connection management for all the > > >
> > transport > > >
> > > services supported by the transport = > > > network using GMPLS. Therefore, > > >
> the > > >
> > > carrier services section for the NNI = > > > document to be posted on the OIF > > >
> site > > >
> > > within a few minutes and the next = > > > draft of the carrier requirements > > >
> IETF > > >
> > > draft will both contain references to > > = > > > support of Fiber Channel. > > >
> > > Regards, > > >
> > > Monica A. Lazer > > >
> > > Advanced Transport Technology and = > > > Architecture Planning > > >
> > > > > >
> > > 908 234 8462 > > >
> > > mlazer@att.com > > >
> > > > > >
> > >  -----Original = > > > Message----- > > >
> > > From:   Dimitri = > > > Papadimitriou > > >
> [ > > > > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > > > triou@alcatel.be] > > >
> > > Sent:   Monday, October 22, > > = > > > 2001 2:47 PM > > >
> > > To:     Ewart = > > > Tempest > > >
> > > Cc:     = > > > lberger@movaz.com; ccamp@ops.ietf.org > > >
> > > = > > > Subject:        Re: Generalized = > > > Signaling - LSP Encoding Type > > >
> expansion > > >
> > > > > >
> > >  << File: Card for Dimitri > > = > > > Papadimitriou >> Hi Ewart, > > >
> > > > > >
> > > If you take a look on the IEEE = > > > Standards you will see > > >
> > > that GE is referred to as > > >
> > > - 802.3z for 1Gbps (see below [1]) = > > > same exists for copper 802.3ab > > >
> > > - 802.3ae for 10Gbps (see below = > > > [2]) > > >
> > > > > >
> > > So my question is what do you have in > > = > > > mind ? to separate > > >
> > > these values ? > > >
> > > > > >
> > > Thanks, > > >
> > > Dimitri. > > >
> > > > > >
> > > PS: for FiberChannel sorry i am not = > > > an expert but is someone > > >
> > >     targeting to = > > > use GMPLS for FiberChannel LSP ? > > >
> > > > > >
> > > ------- > > >
> > > > > >
> > > [1] From - > > HREF=3D"http://standards.ieee.org" = > > > TARGET=3D"_blank">http://standards.ieee.org > > >
> > > > > >
> > > Project scope: Define Carrier Sense = > > > Multiple Access with Collision > > >
> > > Detection (CSMA/CD) Media Access = > > > Control (MAC) parameters and minimal > > >
> > > augmentation of its operation, = > > > physical layer characteristics, > > >
> repeater > > >
> > > functions and management parameters = > > > for transfer of 802.3 and Ethernet > > >
> > > format frames at 1,000 Mb/s. > > >
> > > > > >
> > > Project purpose: The purpose of this = > > > project is to extend the 802.3 > > >
> > > protocol to an operating speed of = > > > 1,000 Mb/s in order to provide a > > >
> > > significant increase in bandwidth = > > > while maintaining maximum > > >
> > > compatibility > > >
> > > with the installed base of CSMA/CD = > > > nodes, previous investment in > > >
> > > research > > >
> > > and development, and principles of = > > > network operation and management. > > >
> > > > > >
> > > [2] From - > > HREF=3D"http://standards.ieee.org" = > > > TARGET=3D"_blank">http://standards.ieee.org > > >
> > > > > >
> > > Project scope: Define 802.3 Media = > > > Access Control (MAC) parameters and > > >
> > > minimal augmentation of its = > > > operation, physical layer characteristics > > >
> > > and management parameters for = > > > transfer of LLC and Ethernet format > > >
> > > frames at 10 Gb/s using full duplex = > > > operation as defined in the 802.3 > > >
> > > standard. In addition to the = > > > traditional LAN space, add parameters and > > >
> > > mechanisms that enable deployment of = > > > Ethernet over the Wide Area > > >
> Network > > >
> > > operating at a data rate compatible = > > > with OC-192c and SDH VC-4-64c > > >
> > > payload > > >
> > > rate. > > >
> > > > > >
> > > Project purpose: The purpose of this = > > > project is to extend the 802.3 > > >
> > > protocol to an operating speed of 10 = > > > Gb/s and to expand the Ethernet > > >
> > > application space to include Wide = > > > Area Network links in order to > > >
> provide > > >
> > > a significant increase in bandwidth = > > > while maintaining maximum > > >
> > > compatibility > > >
> > > with the installed base of 802.3 = > > > interfaces, previous investment in > > >
> > > research > > >
> > > and development, and principles of = > > > network operation and management. > > >
> > > > > >
> > > ------- > > >
> > > > > >
> > > > Ewart Tempest wrote: > > >
> > > > > > >
> > > > Lou, > > >
> > > > > > >
> > > > Within section 3.1.1 of = > > > draft-ietf-mpls-generalized-signaling-06 can > > >
> > > > you please add additonal LSP = > > > Encoding Types for GE and FiberChannel. > > >
> > > > GE is not really covered by the = > > > existing Ethernet related encoding > > >
> > > > types, and FiberChannel is not = > > > covered at all. Thanks. > > >
> > > > > > >
> > > > Ewart > > >
> > > > >

> > > > > > > > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 12:50:24 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBBC@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Eric Gray'" Cc: Yakov Rekhter , ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 15:49:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric, Eric, you are telling me that transport boxes are not allowed to support services other than IP? Isn't this a choice to be made by individual service providers? Why is a standards body trying to impede development of control plane support for a subset of transport services? What is the principle here? I am not saying that a every vendor needs to implement all services in the control plane. But if a vendor chooses to implement a set of services in the data plane, then there should be standards for controlling them. Let me offer you the analogy of how I see this discussion. Assume that a road contractor is building a road because he knows that a lot of cars will go through the area. But he decides that only cars carrying married people will be allowed on the road. No cars carrying a parent and a child are allowed. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Tuesday, October 23, 2001 2:34 PM To: Lazer, Monica A, NNAD Cc: Yakov Rekhter; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Monica, I believe this is both the crux of the argument and the point at which people keep arguing past each other. Some people would like to see a unified transport control plane while other would like to see an IP control plane for transport networks. These would be very different goals. If you'll bear with an analogy for a moment, imagine that you were to set out to design a bicycle. Now along comes somebody that says - "hey, it looks like you've got a pretty good start on a design for an all terrain vehicle; all you need to do is add this, change that and bing, bang, boom - we have an ATV." That would be just fine, provided you didn't have any particular reason to be designing a bicycle. But, assuming what you really wanted was a bicycle, this somebody could not be looked on as being helpful, could they? You wrote: > [[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we > should work to make it that. -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 12:46:37 -0700 Message-ID: <3BD5C8E4.7020302@lucent.com> Date: Tue, 23 Oct 2001 15:45:40 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yakov Rekhter CC: "Lazer, Monica A, NNAD" , "'shehzad.mirza@bt.com'" , ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, While we're talking about why something should be added, and some folks seem to be getting a rough time needing to explain completely why they need it (and that if they want to add it, then it better be useful to majority of the folks), then could I ask that things such as "switching type" (which was added without much of a discussion of why it's needed and how many people actually need it, and for what purpose) also be open for discussion before it is actually accepted into the document? Zhi Yakov Rekhter wrote: > Monica, > > >>All, >>I am in full agreement with Shehzad. From a carrier's perspective, the value >>of the control plane is in taking over specific functions which currently >>reside in OSSs outside of the network itself. Having only some applications, >>but not others of the given function move into the network greatly >>diminishes the value of having that function supported in the control plane. >>To be more specific, if out of n services supported by the transport >>network, the control plane supports automated provisioning of 1/2n services >>and the other 1/2n need support in the OSS, we still need to do the OSS work >>for the given transport technology. So from a cost perspective, now we have >>to ask ourselves whether we should pay for the provisioning function twice. >> > > While what you said makes sense from a given carrier's perspective, > we need to take a broader view, as producing a "perfect solution" > that meets *all* the requirements of *all* the carriers is an > explicit non-goal of GMPLS. With this in mind, if the 1/2n services > that aren't supported by the control plane are the services that > are required by 90% of the carriers market, then indeed this is a > problem. On the other hand, if these 1/2n services that aren't > supported are the services required by only 10% of the carriers > market, then this is quite acceptable. Understandably, the carriers > who would fall into this 10% category could be quite unhappy about, > and could even be quite vocal in expressing their dissatisfaction... > > Yakov. > > >>Regards, >> >>Monica A. Lazer >>Advanced Transport Technology and Architecture Planning >> >>908 234 8462 >>mlazer@att.com >> >> >> -----Original Message----- >>From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] >>Sent: Tuesday, October 23, 2001 6:25 AM >>To: yakov@juniper.net >>Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org >>Subject: RE: Generalized Signaling - LSP Encoding Type expansion >> >>Yakov, >> >>See comments in-line >> >> >>>-----Original Message----- >>>From: Yakov Rekhter [SMTP:yakov@juniper.net] >>>Sent: 22 October 2001 21:12 >>>To: Lazer, Monica A, NNAD >>>Cc: ccamp@ops.ietf.org >>>Subject: Re: Generalized Signaling - LSP Encoding Type expansion >>> >>>Monica, >>> >>> >>>>Dimitri, >>>>Actually, it may be more accurate to put it differently - if GMPLS >>>> >>>supports >>> >>>>only a handful of the services running on a given transport network, >>>> >>>than >>> >>>>its value as a network's control plane component is diminished. >>>> >>>To be even more accurate, GMPLS value is diminished *in the context* >>>of that particular transport network. And unless *all* providers >>>are going to run *all possible services* on their transport networks >>>(which is a somewhat unrealistic scenario), that means that the >>>value of GMPLS as a network's control plane component would be >>>diminished for *some*, but not *all* service providers. >>> >>> >>> >>> >> [shehzad] >>For a control plane not to support all the transport services capable of >>being carried over an operator's network diminishes the value of that >>particular control plane. What is the point of having transparent/optical >>equipment capable of transporting both Gigabit Ethernet and Fiber Channel >>(as an example), if provisioning was based on signalling that could only >>support Gigabit Ethernet? >> >>This is a restriction for every provider regardless of whether a network is >>a standalone one built for a large customer or a national network serving >>multiple customers. The effective 'banning' of certain services that are >>currently being offered by providers will unnecessarily damage the business >>case for the adoption of GMPLS. >> >> >> >> >>>At the same time, it is important to keep in mind that being "all >>>things for all people" (aka as "perfect solution") is one of the >>>*non-goals* of GMPLS. So, it shouldn't come as a surprise if for a >>>*particular* provider GMPLS would *not* support *all* the services >>>that this provider runs on its transport network. >>> >>>Yakov. >>> >>> >>> >> [Shehzad] >> There is no technical reason why a GMPLS encoding type could not be >>adopted for a recognised format such as Fiber Channel, as far as I am aware >>the adoption of Fiber Channel is not likely to destroy the foundations of >>GMPLS. >> >> On a more general point, is the support of transport technologies >>within GMPLS signalling restricted to those that the authors of the GMPLS >>drafts will allow? >> >> >> >> >> >> >> >>>>Monica A. Lazer >>>>Advanced Transport Technology and Architecture Planning >>>> >>>>908 234 8462 >>>>mlazer@att.com >>>> >>>> >>>> -----Original Message----- >>>>From: Dimitri Papadimitriou >>>> >>>[mailto:dimitri.papadimitriou@alcatel.be] >>> >>> >>>>Sent: Monday, October 22, 2001 3:15 PM >>>>To: Lazer, Monica A, NNAD >>>>Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org >>>>Subject: Re: Generalized Signaling - LSP Encoding Type expansion >>>> >>>> << File: Card for Dimitri Papadimitriou >> Hi Monica, >>>> >>>>Fine. Now we know the following: GMPLS is really attractive for >>>>carriers when it supports all transport technologies so it has >>>>to support Fiber Channel as well. >>>> >>>>I wasn't aware that Ewart was capable to read in your mind ;-) >>>> >>>>Regards, >>>>Dimitri. >>>> >>>>"Lazer, Monica A, NNAD" wrote: >>>> >>>>>Dimitri, >>>>>I am just answering the PS question with this message. >>>>>The short answer is yes. The long answer is that the GMPLS control >>>>> >>>plane >>> >>>>is >>>> >>>>>really useful if it can support connection management for all the >>>>> >>>>transport >>>> >>>>>services supported by the transport network using GMPLS. Therefore, >>>>> >>>the >>> >>>>>carrier services section for the NNI document to be posted on the OIF >>>>> >>>site >>> >>>>>within a few minutes and the next draft of the carrier requirements >>>>> >>>IETF >>> >>>>>draft will both contain references to support of Fiber Channel. >>>>>Regards, >>>>>Monica A. Lazer >>>>>Advanced Transport Technology and Architecture Planning >>>>> >>>>>908 234 8462 >>>>>mlazer@att.com >>>>> >>>>> -----Original Message----- >>>>>From: Dimitri Papadimitriou >>>>> >>>[mailto:dimitri.papadimitriou@alcatel.be] >>> >>>>>Sent: Monday, October 22, 2001 2:47 PM >>>>>To: Ewart Tempest >>>>>Cc: lberger@movaz.com; ccamp@ops.ietf.org >>>>>Subject: Re: Generalized Signaling - LSP Encoding Type >>>>> >>>expansion >>> >>>>> << File: Card for Dimitri Papadimitriou >> Hi Ewart, >>>>> >>>>>If you take a look on the IEEE Standards you will see >>>>>that GE is referred to as >>>>>- 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab >>>>>- 802.3ae for 10Gbps (see below [2]) >>>>> >>>>>So my question is what do you have in mind ? to separate >>>>>these values ? >>>>> >>>>>Thanks, >>>>>Dimitri. >>>>> >>>>>PS: for FiberChannel sorry i am not an expert but is someone >>>>> targeting to use GMPLS for FiberChannel LSP ? >>>>> >>>>>------- >>>>> >>>>>[1] From - http://standards.ieee.org >>>>> >>>>>Project scope: Define Carrier Sense Multiple Access with Collision >>>>>Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal >>>>>augmentation of its operation, physical layer characteristics, >>>>> >>>repeater >>> >>>>>functions and management parameters for transfer of 802.3 and Ethernet >>>>>format frames at 1,000 Mb/s. >>>>> >>>>>Project purpose: The purpose of this project is to extend the 802.3 >>>>>protocol to an operating speed of 1,000 Mb/s in order to provide a >>>>>significant increase in bandwidth while maintaining maximum >>>>>compatibility >>>>>with the installed base of CSMA/CD nodes, previous investment in >>>>>research >>>>>and development, and principles of network operation and management. >>>>> >>>>>[2] From - http://standards.ieee.org >>>>> >>>>>Project scope: Define 802.3 Media Access Control (MAC) parameters and >>>>>minimal augmentation of its operation, physical layer characteristics >>>>>and management parameters for transfer of LLC and Ethernet format >>>>>frames at 10 Gb/s using full duplex operation as defined in the 802.3 >>>>>standard. In addition to the traditional LAN space, add parameters and >>>>>mechanisms that enable deployment of Ethernet over the Wide Area >>>>> >>>Network >>> >>>>>operating at a data rate compatible with OC-192c and SDH VC-4-64c >>>>>payload >>>>>rate. >>>>> >>>>>Project purpose: The purpose of this project is to extend the 802.3 >>>>>protocol to an operating speed of 10 Gb/s and to expand the Ethernet >>>>>application space to include Wide Area Network links in order to >>>>> >>>provide >>> >>>>>a significant increase in bandwidth while maintaining maximum >>>>>compatibility >>>>>with the installed base of 802.3 interfaces, previous investment in >>>>>research >>>>>and development, and principles of network operation and management. >>>>> >>>>>------- >>>>> >>>>> >>>>>>Ewart Tempest wrote: >>>>>> >>>>>>Lou, >>>>>> >>>>>>Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can >>>>>>you please add additonal LSP Encoding Types for GE and FiberChannel. >>>>>>GE is not really covered by the existing Ethernet related encoding >>>>>>types, and FiberChannel is not covered at all. Thanks. >>>>>> >>>>>>Ewart >>>>>> >>------_=_NextPart_001_01C15BCA.5A2A5650 >>Content-Type: text/html; >> charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >>>charset=3Diso-8859-1"> >>>5.5.2654.19"> >>RE: Generalized Signaling - LSP Encoding Type expansion >> >> >> >>

All, >>
I am in full agreement with Shehzad. From a = >>carrier's perspective, the value of the control plane is in taking over = >>specific functions which currently reside in OSSs outside of the = >>network itself. Having only some applications, but not others of the = >>given function move into the network greatly diminishes the value of = >>having that function supported in the control plane. To be more = >>specific, if out of n services supported by the transport network, the = >>control plane supports automated provisioning  of 1/2n services = >> > and the other 1/2n need support in the OSS, we still need to do the OSS = > >>work for the given transport technology. So from a cost perspective, = >>now we have to ask ourselves whether we should pay for the provisioning = >>function twice.

>> >>

Regards, >>

>> >>

Monica A. Lazer >>
Advanced Transport Technology and Architecture = >>Planning >>

>> >>

908 234 8462 >>
mlazer@att.com >>

>>
>> >>

 -----Original Message----- >>
From:   shehzad.mirza@bt.com [>HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = >> >>
Sent:   Tuesday, October 23, 2001 6:25 = >>AM >>
To:     yakov@juniper.net >>
Cc:     Lazer, Monica A, NNAD; = >>ccamp@ops.ietf.org >>
Subject:        = >>RE: Generalized Signaling - LSP Encoding Type expansion >>

>> >>

Yakov, >>

>> >>

See comments in-line >>

>> >>

> -----Original Message----- >>
> From: Yakov Rekhter = >>[SMTP:yakov@juniper.net] >>
> Sent: 22 October 2001 21:12 >>
> To:   Lazer, Monica A, NNAD >>
> Cc:   ccamp@ops.ietf.org >>
> Subject:      Re: = >>Generalized Signaling - LSP Encoding Type expansion >>
> >>
> Monica, >>
> >>
> > Dimitri, >>
> > Actually, it may be more accurate to put = >>it differently - if GMPLS >>
> supports >>
> > only a handful of the services running on = >>a given transport network, >>
> than >>
> > its value as a network's control plane = >>component is diminished. >>
> >>
> To be even more accurate, GMPLS value is = >>diminished *in the context* >>
> of that particular transport network. And = >>unless *all* providers >>
> are going to run *all possible services* on = >>their transport networks >>
> (which is a somewhat unrealistic scenario), = >>that means that the >>
> value of GMPLS as a network's control plane = >>component would be >>
> diminished for *some*, but not *all* service = >>providers. >>
> >>
> >>
> >>
        >SIZE=3D2>[shehzad]  >>
For a control plane not to support all the transport = >>services capable of >>
being carried over an operator's network diminishes = >>the value of that >>
particular control plane.  What is the point of = >>having transparent/optical >>
equipment capable of transporting both Gigabit = >>Ethernet and Fiber Channel >>
(as an example), if provisioning was based on = >>signalling that could only >>
support Gigabit Ethernet? >>

>> >>

This is a restriction for every provider regardless = >>of whether a network is >>
a standalone one built for a large customer or a = >>national network serving >>
multiple customers. The effective 'banning' of = >>certain services that are >>
currently being offered by providers will = >>unnecessarily damage the business >>
case for the adoption of GMPLS. >>

>>
>>
>> >>

> At the same time, it is important to keep in = >>mind that being "all >>
> things for all people" (aka as = >>"perfect solution") is one of the >>
> *non-goals* of GMPLS. So, it shouldn't come as = >>a surprise if for a >>
> *particular* provider GMPLS would *not* support = >>*all* the services >>
> that this provider runs on its transport = >>network. >>
> >>
> Yakov. >>
> >>
> >>
        >SIZE=3D2>[Shehzad] >>
        There is = >>no technical reason why a GMPLS encoding type could not be >>
adopted for a recognised format such as Fiber = >>Channel, as far as I am aware >>
the adoption of Fiber Channel is not likely to = >>destroy the foundations of >>
GMPLS. >>

>> >>

        On a more = >>general point, is the support of transport technologies >>
within GMPLS signalling restricted to those that the = >>authors of the GMPLS >>
drafts will allow? >>
         = >> >>

>>
>>
>>
>>
>> >>

> > Monica A. Lazer >>
> > Advanced Transport Technology and = >>Architecture Planning >>
> > >>
> > 908 234 8462 >>
> > mlazer@att.com >>
> > >>
> > >>
> >  -----Original Message----- >>
> > From:       = >>Dimitri Papadimitriou >>
> [>HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= >>triou@alcatel.be] >>
>  >>
> > Sent:       = >>Monday, October 22, 2001 3:15 PM >>
> > To: Lazer, Monica A, NNAD >>
> > Cc: Ewart Tempest; lberger@movaz.com; = >>ccamp@ops.ietf.org >>
> > Subject:    Re: Generalized = >>Signaling - LSP Encoding Type expansion >>
> > >>
> >  << File: Card for Dimitri = >>Papadimitriou >> Hi Monica, >>
> > >>
> > Fine. Now we know the following: GMPLS is = >>really attractive for >>
> > carriers when it supports all transport = >>technologies so it has >>
> > to support Fiber Channel as well. >>
> > >>
> > I wasn't aware that Ewart was capable to = >>read in your mind ;-) >>
> > >>
> > Regards, >>
> > Dimitri. >>
> > >>
> > "Lazer, Monica A, NNAD" = >>wrote: >>
> > > >>
> > > Dimitri, >>
> > > I am just answering the PS question = >>with this message. >>
> > > The short answer is yes.  The = >>long answer is that the GMPLS control >>
> plane >>
> > is >>
> > > really useful if it can support = >>connection management for all the >>
> > transport >>
> > > services supported by the transport = >>network using GMPLS. Therefore, >>
> the >>
> > > carrier services section for the NNI = >>document to be posted on the OIF >>
> site >>
> > > within a few minutes and the next = >>draft of the carrier requirements >>
> IETF >>
> > > draft will both contain references to = >>support of Fiber Channel. >>
> > > Regards, >>
> > > Monica A. Lazer >>
> > > Advanced Transport Technology and = >>Architecture Planning >>
> > > >>
> > > 908 234 8462 >>
> > > mlazer@att.com >>
> > > >>
> > >  -----Original = >>Message----- >>
> > > From:   Dimitri = >>Papadimitriou >>
> [>HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= >>triou@alcatel.be] >>
> > > Sent:   Monday, October 22, = >>2001 2:47 PM >>
> > > To:     Ewart = >>Tempest >>
> > > Cc:     = >>lberger@movaz.com; ccamp@ops.ietf.org >>
> > > = >>Subject:        Re: Generalized = >>Signaling - LSP Encoding Type >>
> expansion >>
> > > >>
> > >  << File: Card for Dimitri = >>Papadimitriou >> Hi Ewart, >>
> > > >>
> > > If you take a look on the IEEE = >>Standards you will see >>
> > > that GE is referred to as >>
> > > - 802.3z for 1Gbps (see below [1]) = >>same exists for copper 802.3ab >>
> > > - 802.3ae for 10Gbps (see below = >>[2]) >>
> > > >>
> > > So my question is what do you have in = >>mind ? to separate >>
> > > these values ? >>
> > > >>
> > > Thanks, >>
> > > Dimitri. >>
> > > >>
> > > PS: for FiberChannel sorry i am not = >>an expert but is someone >>
> > >     targeting to = >>use GMPLS for FiberChannel LSP ? >>
> > > >>
> > > ------- >>
> > > >>
> > > [1] From - >HREF=3D"http://standards.ieee.org" = >>TARGET=3D"_blank">http://standards.ieee.org >>
> > > >>
> > > Project scope: Define Carrier Sense = >>Multiple Access with Collision >>
> > > Detection (CSMA/CD) Media Access = >>Control (MAC) parameters and minimal >>
> > > augmentation of its operation, = >>physical layer characteristics, >>
> repeater >>
> > > functions and management parameters = >>for transfer of 802.3 and Ethernet >>
> > > format frames at 1,000 Mb/s. >>
> > > >>
> > > Project purpose: The purpose of this = >>project is to extend the 802.3 >>
> > > protocol to an operating speed of = >>1,000 Mb/s in order to provide a >>
> > > significant increase in bandwidth = >>while maintaining maximum >>
> > > compatibility >>
> > > with the installed base of CSMA/CD = >>nodes, previous investment in >>
> > > research >>
> > > and development, and principles of = >>network operation and management. >>
> > > >>
> > > [2] From - >HREF=3D"http://standards.ieee.org" = >>TARGET=3D"_blank">http://standards.ieee.org >>
> > > >>
> > > Project scope: Define 802.3 Media = >>Access Control (MAC) parameters and >>
> > > minimal augmentation of its = >>operation, physical layer characteristics >>
> > > and management parameters for = >>transfer of LLC and Ethernet format >>
> > > frames at 10 Gb/s using full duplex = >>operation as defined in the 802.3 >>
> > > standard. In addition to the = >>traditional LAN space, add parameters and >>
> > > mechanisms that enable deployment of = >>Ethernet over the Wide Area >>
> Network >>
> > > operating at a data rate compatible = >>with OC-192c and SDH VC-4-64c >>
> > > payload >>
> > > rate. >>
> > > >>
> > > Project purpose: The purpose of this = >>project is to extend the 802.3 >>
> > > protocol to an operating speed of 10 = >>Gb/s and to expand the Ethernet >>
> > > application space to include Wide = >>Area Network links in order to >>
> provide >>
> > > a significant increase in bandwidth = >>while maintaining maximum >>
> > > compatibility >>
> > > with the installed base of 802.3 = >>interfaces, previous investment in >>
> > > research >>
> > > and development, and principles of = >>network operation and management. >>
> > > >>
> > > ------- >>
> > > >>
> > > > Ewart Tempest wrote: >>
> > > > >>
> > > > Lou, >>
> > > > >>
> > > > Within section 3.1.1 of = >>draft-ietf-mpls-generalized-signaling-06 can >>
> > > > you please add additonal LSP = >>Encoding Types for GE and FiberChannel. >>
> > > > GE is not really covered by the = >>existing Ethernet related encoding >>
> > > > types, and FiberChannel is not = >>covered at all. Thanks. >>
> > > > >>
> > > > Ewart >>
> > >>

>> >> >> >>------_=_NextPart_001_01C15BCA.5A2A5650-- >> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 12:46:30 -0700 Message-ID: <3BD5C82A.9080607@lucent.com> Date: Tue, 23 Oct 2001 15:42:34 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Eric Gray CC: "Lazer, Monica A, NNAD" , Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, Maybe I'm confused but is it really talking about "unified transport CP"? I think we are still talking about an IP control plane (BTW, what is the definition of IP CP?), but using this IP control plane to allow requesting different types of transport plane for services that those transport planes can offer, still using the IP-based protocols. Is that right, or am I completely uninformed? Zhi Eric Gray wrote: > Monica, > > I believe this is both the crux of the argument and the point at which > people keep arguing past each other. Some people would like to see a > unified transport control plane while other would like to see an IP control > plane for transport networks. These would be very different goals. > > If you'll bear with an analogy for a moment, imagine that you were to set > out to design a bicycle. Now along comes somebody that says - "hey, it > looks like you've got a pretty good start on a design for an all terrain vehicle; > all you need to do is add this, change that and bing, bang, boom - we have > an ATV." That would be just fine, provided you didn't have any particular > reason to be designing a bicycle. But, assuming what you really wanted was > a bicycle, this somebody could not be looked on as being helpful, could they? > > You wrote: > > >>[[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we >>should work to make it that. >> > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 11:42:23 -0700 Message-ID: <3BD5B823.971F439F@sandburst.com> Date: Tue, 23 Oct 2001 14:34:11 -0400 From: Eric Gray MIME-Version: 1.0 To: "Lazer, Monica A, NNAD" Cc: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Monica, I believe this is both the crux of the argument and the point at which people keep arguing past each other. Some people would like to see a unified transport control plane while other would like to see an IP control plane for transport networks. These would be very different goals. If you'll bear with an analogy for a moment, imagine that you were to set out to design a bicycle. Now along comes somebody that says - "hey, it looks like you've got a pretty good start on a design for an all terrain vehicle; all you need to do is add this, change that and bing, bang, boom - we have an ATV." That would be just fine, provided you didn't have any particular reason to be designing a bicycle. But, assuming what you really wanted was a bicycle, this somebody could not be looked on as being helpful, could they? You wrote: > [[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we > should work to make it that. -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 11:38:03 -0700 Message-ID: From: "Mannie, Eric" To: 'Juergen Heiles' , 'Kireeti Kompella' , ccamp@ops.ietf.org Cc: "'tsg15q11@itu.ch'" , "'t1x15@t1.org'" Subject: RE: Moving right along ... Date: Tue, 23 Oct 2001 20:22:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Juergen, More about the SDH and SONET labels: We designed them using the same principles to have as much = compatibility as possible between SDH and SONET, this was our objective. But they will = never be the same as explained hereafter. For the Sonet label we have the choice between the single stage = interleaving and the two stage interleaving approach. One must choose either one or = the other. Your proposal is to use the two stage interleaving to define the Sonet label. We chosen the single stage Sonet interleaving. The advantage of = using the single stage interleaving as a basis is that it works in both cases = in the same way, i.e. it just point to the first STS-1 and the label = doesn't care if a single or two stage interleaving is used, it results that S = has exactly the same *semantic* for SDH and SONET, but not the same *value* = of course. Another reason to use the single stage interleaving is to avoid to = introduce a particular case just for SONET. If we introduce a STS-3 group we = could also introduce AUG-4, AUG-16, AUG-64 and AUG-256. If we do that (to be compatible with the two stage SONET approach), the label needs three additional artificial fields. Each time we add an additional level, we = need to add a field. It becomes more complex without adding any new feature = and we loose the flexibility. One main driver for our solution is that the label doesn't need to know about the grouping of STS-1 or AUG, there is no need to encode that information in the label because nobody is going to use it. So we = obtained an easier coding. More important: the label structure will NEVER be the same for SONET = and SDH because this is physically not possible: there is not TUG-3 equivalent = in SONET, there is no VT-3 equivalent in SDH. So whatever is the label = coding, K and M will ALWAYS be different. Nobody can change it. The C code for coding and dealing with the multiplex allocation will = never be the same neither. A link will never be operated at the same time as = SDH and SONET. The label is always local to a link and there is no interoperability = issue between SONET and SDH for that reason (because they are physically separated). We had the same desire to have the SDH and SONET label as compatible as possible, and this is what we think we achieved while taking into consideration the purpose of the label, why we need a label and where = we need a label. Kind regards, Eric -----Original Message----- From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] Sent: Tuesday, October 23, 2001 6:08 PM To: Mannie, Eric; 'Juergen Heiles'; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: AW: Moving right along ... > -----Urspr=FCngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Dienstag, 23. Oktober 2001 17:12 > An: 'Juergen Heiles'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Betreff: RE: Moving right along ... > > > Juergen, > > I am answering to your e-mails exactly because I am the editor of = these > documents. Some people don't want to answer anymore. Answering or not = to > e-mails is a personal decision of each one, nobody is forced to = answer. > > You had the feedback from the mailing list. In general when > people are happy > with what they saw they don't spend time to add more comments. > > Your proposals were supported by you and Maarten. I answered with = Dimitri. > It is easy of course (for all of us) to ask all our colleagues and = friends > to flood a mailing list. > > Concerning your request to move the group signals to the other draft: = this > was answered publicly by Kireeti during the last CCAMP meeting and = the > answer was no. I asked again to Kireeti a couple of weeks ago, > same answer. > This is also the advice that I received from Rob. As this is not a question of rough consensus let the chairs sort this = out. > > Concerning your label proposal: details are not yet cooked from our = (I and > Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding = Adjacency > there is no second STS-3 group, sorry if my example was confusing). = Your > text needs to be corrected but that's a detail, it just shows that it = is > quite difficult to write a text that works in all cases. > What does a STS-4 SPE Forwarding Adjacency provide capacity for 4 STS-1 SPEs? Ok, how about a 4xAU-3 Forwarding Adjacency, the SDH equivalent. It = should be also possible (Japan for example uses SDH AU3). How would you use it with the current SDH lable. If you consider such features I agree that my proposal has problems, but the current = proposal also for AU3. To cover it for both SONET and SDH AU3 we have to use the current SONET labels also for SDH AU3. Again we would have identical = SONET and SDH labels. And this example clearly shows to me that we need the same lables. = Otherwise we end up with some features that are only possible in SDH or only = possible in SONET because of different restrictions due to the different lables. = What can be done in SONET can also be done in SDH. > We spend a considerable amount of time reviewing the current > label encoding > and we made sure that it works in the craziest cases. Indeed, this is = the > most stable part of the SDH/SONET draft since a very long time. > By adopting > your proposal we will have to do it again for no additional benefit = and we > will need another WG last call (you know it perfectly). That's > why I refused > during the WG last call some months ago, and why I am refusing again. > > As an editor my job is also to keep the boat in the middle of the > river and > to make sure that drafts are progressing and are not being constantly > re-worded. Also, I don't want to force all manufacturers to change = their > implementations (prototypes:-) of the SONET label just because you = found > another way of encoding it. One solution or the other is more a = matter of > personal feeling. > > At this stage, as a co-author you should be more concerned by > finishing this > work. We can spend years having new ideas, improving and proposing > modifications to a draft. > If a co-author has to keep quiet on the mailing list or during the = meeting with comments on the document it is fine with me to be removed as = co-author. > It is a fact that we spend a huge amount of time (for me it = represents > months of work since the beginning of year 2000) fine-tuning this > draft. Now > it is time to publish it. > > >From the technical point of view your proposals versus keeping > the current > text will not change anything. It started as a political issue and I = hope > that it didn't become a personal issue. > > I am just asking you to help us to publish this work, even if it > is not 100% > as you would like to see it. > > Kind regards, > > Eric > > > -----Urspr=FCngliche Nachricht----- > > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > > Gesendet: Dienstag, 23. Oktober 2001 12:23 > > An: 'Juergen Heiles'; 'Kireeti Kompella'; ccamp@ops.ietf.org > > Betreff: RE: Moving right along ... > > > > > > Hi Juergen, > > > > We already discussed all these points (at least 5 times) :-) > even more > > > > > > - about automatic detection: > > > > Indeed, you either configure a box with a signal structure, or if > > implemented you can ask to the box to discover itself the > structure (what > > you call automatic detection). > > > For groups the box has to discover the structure itself. > > > > Automatic detection is a process applied internally to a box, > and this is > > totally invisible to any other box in the network. This is an > > implementation > > issue, not a protocol issue since the protocol defines > everyhting you need > > to do it. > > > > I understand your frustration that SDH standards don't describe all = the > > processes for an implementation, but in general standards don't > touch that > > part. > > > SDH and Sonet standards define detailed equipment functionality > in order to > ensure interworking. > ITU has for example G.783 that defeins in detail what to do in SDH > equipment. Even G.707 gives some details > on pointer processing (genration, interpretation). For SONET we > have GR-253 > from Telcordia which provides this details. > No of them mentiones automatic detection. > > > > Automatic detection is a matter of reading the standard and > understanding > > how the multiplexing works. By the way, you explained it yourself > > very well. > > > > The fact that a process is not described in some SDH standards has = no > > meaning, it is simply not relevant. Every manufacturer is free to = do its > > implementation as he likes if the protocol is fullfilled, and > this is the > > case. > > > > - about the comparison of automatic detection and transparency: > > > > You are comparing apples with chocolates. Transparency may require = to > > transport bytes in unused bytes, so in that case it changes the > overhead. > > Automatic detection is an internal process. > > > > - You wrote: "During errors (defects, AIS condtions) of > individual singals > > of a group (e.g. one VC-12 in a TUG3 fails) it can get = problematic." > > > > and I already answered many times: a super signal (group signal) is = one > > single LSP. If something fails inside everything fails. In that = case you > > don't need to demultiplex anymore, you just protect/restore the > whole (if > > required). A group signal is a signaling plane object, i.e. one > > single LSP. > > > I mentioned the case that the problem is outside your LSP. You get = for > example a signal from a user and setup a group LSP. > Now due to problems on the user side one of the VCs has AIS, may > be the user > isn't even using this VC currently. You cannot protect it as the > problem is > outside the LSP. If you now drop all other VCs of this group your > user would > be very happy I assume. > > > > - Can you present me any ITU/ANSI standard that defines automatic > > detection > > of the group structure? > > > > No need, this is not in the scope of ITU/ANSI standards. > > Are you defining what is in the scope of ITU/ANSI standards? > This is in the scope of ITU/ANSI/Telcordia standards. Look on > G.707 pointer > interpretation, G.783 and GR-253 as mentioned above. When we talk = about > standard SONET/SDH it includes the equipment functionality. For > ETSI we even > have compliance statements that go down to these details. > I have no problems when soemone implements this feature, but we = should no > give the impression that this is a standard SONET/SDH feature by > putting it > into the standard features document. Move it to the non-standard = document. > > > > > - You wrote " You haven't provided a reason for different lables. = We had > > several people that wanted to have the same label structure and = only you > > opposed. So what is rough consensus?" > > > > The labels are local per interface, so they are "different" by > definition > > since an SDH interface is not a Sonet interface. > > A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N > with AU-3 have > the identical structure. > But with the current proposal we have to use different lables. Is = this > simple? > > > However, we > > defined the two > > label formats based on the same principles, i.e. the first field is = the > > index of the first AUG-1/STS-1 (easy). We chosen not to > indicate any level > > of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) > because this > > is not needed and less flexible. A label is just a simple pointer = in the > > multiplex, how to interpret the content of what is pointed to is > > not defined > > by the label. > > > > I just took the SDH AU3 case and used it for SONET. So if you see > a problem > it would already apply to the defined SDH lable. > > > > Using your proposal we would introduce a particular case, and > in that case > > there is no reason why we should not introduce other particular > > case (AUG-4, > > etc). At the end we would have something totally unreadable. > > > > Your proposal has also some issues, e.g. with your definition of = the S > > field: > > > > "1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N > > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > > multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 = group, > > and S=3DN indicates the last AUG-1/STS-3 group of this = multiplex. > > S is not significant for STM-0/STS-1. > > > > What happens if a link is not a a multiple of 3xN STS-1 ? For > instance, a > > virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or > an STS-4. > > There is no real second STS-3 group. Your proposal is not > > appropriate to the > > level of flexibility that we want to provide. Another observations: = our > > undrestanding of the label is that it is defined before any > interleaving, > > not after. > > > > Oh, suddently we have STS-4, STS-4 virtual links poping up, > interesting. But > couldn't we also have virtual SDH signals with only 5 AU-3? > I don't know as I don't have any information about this virtual link > concept. But if you introduce something like this there should be no > difference between SONET and SDH. Otherwise we introduce new = differences > between SONET and SDH that we tried to avoid now for some years (see > Deborahs e-mail). We learned from the mistakes made during the = development > of SONET and SDH. In todays global world we don't want these = differences. > And that is the reason why we propose to use a common lable. > Don't make the > same mistakes again. So if you see a problem it also applies to > the defined > SDH label. > > > > > I am opposed because your proposal doesn't bring any new = functionality. > > There are probably 100 ways of coding such a label for SDH and = Sonet. We > > discussed it during one year, > The proposal to use a common lable is already disucssed for several = month > (over 1/2 year) as soon as we got involved in the GMPLS discussions. > > > > we agreed on the current one because it is > > simple, easy to understand, easy to code and very flexible (and = more > > important we never broke it !!!). We validate it, it is stable > > since a very > > long time. Why should we accept your way of coding it, and not > the way of > > somebody else at this final stage ? > > > > To use a common label is the only alternative proposal we have, no = others. > It makes a lot of sense and is supported by several people on the = list. Up > to know only oppossed by you. Again what is rough consensus? > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] > > Sent: Monday, October 22, 2001 3:01 PM > > To: Mannie, Eric; 'Kireeti Kompella'; ccamp@ops.ietf.org > > Subject: AW: Moving right along ... > > > > > > Hi Eric, > > > > sorry for the delayed answer, but I have problems with the remtoe > > LAN access > > here in Geneva. > > I am therefore sending the mail via my ITU e-mail account and hope = it is > > accepted by the ccamp list server. > > > > You compare groups with the multiplier, this is wrong. The > multiplier sets > > up n indivudal VC-n connections. The transport plane sees only the > > individual VCs and the VC type (VC-4/372712711) is explicitly > > defined. So no > > additional support at the transport plane is needed. It is a > pure control > > plane feature. > > Groups are not a pure control plane feature. When you setup a > group (AUG, > > TUG, VTG, STSG) the transport plane still has to handle the = individual > > VCs/SPEs that are part of the group. Due the independent timing of = each > > VC/STS-SPE pointer processing has to be done per individual VC/SPE. = The > > transport plane cannot switch the group as a whole between > STM/STS ports. > > The transport plane therefore has to automatically detect the > structure of > > the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, > VC-11 or a > > mixture and that may change over the lifetime of the group. > This automatic > > detection is not a standard SONET/SDH feature. As I described > in previous > > e-mails it is possible to do it based on pointer values during non = error > > situations. During errors (defects, AIS condtions) of individual > > singals of > > a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. > > If a single > > VC-12 in a TUG3 group has AIS (note that the AIS could result > > from a failure > > outside the LSP), I assume that still all the other VCs of the > group shall > > be connected without errors. No SONET/SDH standard covers the = automatic > > detection. > > So in my view it is similarly to transparency of individual SOH > > bytes. G.707 > > defines the individual SOH bytes, however transparency it is > not standard > > SONET/SDH and is therefore in the non-standard document. In the = same way > > G.707 defines groups, but not the automatic detection of the group > > structure. So it should be moved to the non-standards document. At = the > > London meeting Kireeti said the decision on > standard/non-standard features > > is not based on rough consensus, but on what is in the ITU/ANSI > documents. > > Can you present me any ITU/ANSI standard that defines automatic > > detection of > > the group structure? > > > > You say groups are cool, may be for some applications. But note > > that groups > > have the same fragementation problem as contiguous concatenation. > > The VCs in > > a group always have to stay together. If for a example a TUG2 > consits of 3 > > VC-12 you cannot put them in arbitrary free time slots. They > have stay in > > the time slots that belong to a single TUG2. > > > > > > Concering the lable, aligning the SONET labels with the SDH lables = makes > > live easier. It is also a sign that SONET and SDH are identical for = most > > parts. I also showed you that SONET uses the same two-stage = interleaving > > process as SDH. If you look at the attached figure from T1.105 > > you see that > > the STS-1 time slots in an STS-N signal are not continously > > number. First 3 > > STS-1s are combiend to a STS3 groupg and then the STS3 groups are > > multiplexed. The same as SDH with AU3s and AUGs. > > As the SONET lables will become the same as the SDH labels we > > don't have to > > evaluate much. I already made a proposal some time ago. Why = introduce > > different labels without a need? > > You haven't provided a reason for different lables. We had > several people > > that wanted to have the same label structure and only you > opposed. So what > > is rough consensus? > > > > See my proposal for the labels below. > > > > > > Juergen > > > > > > This is my proposal for the label: > > The format of the label for SDH and/or SONET TDM-LSR link is: > > > > 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 > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | S | U | K | L | M = | > > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > For SDH, this is an extension of the numbering scheme defined in > > G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the = same > > signaling scheme is used in order to provide easy > interworkign between > > SDH and SONET signaling. For the S field a STS-3 group,which > > corresponds with the SDH AUG-1 level is introduce. The U field > > indicates > > the position of the STS-3c-SPE or STS-1-SPE within the STS-3 > > group. The K > > field is not significant for SONET as it doesn't support = structured > > STS-3c-SPEs and must be set to zero. > > > > Each letter indicates a possible branch number starting at the > > parent node in the multiplex structure. Branches are considered = as > > numbered in increasing order, starting from the top of the > > multiplexing structure. The numbering starts at 1, zero is used = to > > indicate a non-significant field. > > > > When a field is not significant in a particular context it MUST = be > > set to zero when transmitted, and MUST be ignored when received. > > > > When hierarchical SDH/SONET LSPs are used, an LSP with a given > > bandwidth can be used to tunnel lower order LSPs. The higher > > order SDH/SONET LSP behaves as a virtual link with a given > > bandwidth (e.g. VC-3), it may also be used as a Forwarding > > Adjacency. A lower order SDH/SONET LSP can be established = through > > that higher order LSP. Since a label is local to a (virtual) = link, > > the highest part of that label is non-significant and is set to > > zero. > > > > For instance, a VC-3 LSP can be advertised as a forwarding > > adjacency. In that case the labels allocated between the two = ends > > of that LSP (i.e. for that "link") will have S, U and K set to > > zero, i.e., non-significant, while L and M will be used to > > indicate the signal allocated in that VC-3. > > > > 1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N > > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > > multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 = group, > > and S=3DN indicates the last AUG-1/STS-3 group of this = multiplex. > > S is not significant for STM-0/STS-1. > > > > 2. U indicates a specific VC/STS-SPE inside a given = AUG-1/STS-3 > > group or STM-0/STS-1. U=3D1 indicates a single VC-4/STS-3c-SPE = in a > > AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, > > while U=3D2->4 > > indicates a specific VC-3/STS-1-SPE inside the given = AUG-1/STS-3 > > group. > > > > 3. K is only significant for SDH VC-4 and must be ignored for > > SONET and SDH HOVC-3. It indicates a specific branch of a = VC-4. > > K=3D1 indicates that the VC-4 is not further subdivided and > > contains a C-4. K=3D2->4 indicates a specific TUG-3 inside the = VC- > > 4. K is not significant when the AUG-1 is divided into AU-3s > > (easy to read and test). > > > > 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 = SPE. > > It is not significant for an unstructured VC-4 or > VC-3/STS-1 SPE. L=3D1 > > indicates that the TUG-3/VC-3/STS-1 SPE is not further > > subdivided and contains a VC-3/C-3 in SDH or the equivalent in > > SONET. L=3D2->8 indicates a specific TUG-2/VT Group inside the > > corresponding higher order signal. > > > > 5. M indicates a specific branch of a TUG-2/VT Group. It is = not > > significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 = SPE. > > M=3D1 indicates that the TUG-2/VT Group is not further = subdivided > > and contains a VC-2/VT-6 SPE. M=3D2->3 indicates a specific = VT-3 > > inside the corresponding VT Group, these values MUST NOT be = used > > for SDH since there is no equivalent of VT-3 with SDH. = M=3D4->6 > > indicates a specific VC-12/VT-2 SPE inside the corresponding > > TUG-2/VT Group. M=3D7->10 indicates a specific VC-11/VT-1.5 = SPE > > inside the corresponding TUG-2/VT Group. Note that M=3D0 = denotes > > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). > > > > > > The M encoding is summarized in the following table: > > > > M SDH SONET > > ---------------------------------------------------------- > > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE > > 1 VC-2 VT-6 > > 2 - 1st VT-3 > > 3 - 2nd VT-3 > > 4 1st VC-12 1st VT-2 > > 5 2nd VC-12 2nd VT-2 > > 6 3rd VC-12 3rd VT-2 > > 7 1st VC-11 1st VT-1.5 > > 8 2nd VC-11 2nd VT-1.5 > > 9 3rd VC-11 3rd VT-1.5 > > 10 4th VC-11 4th VT-1.5 > > > > In case of contiguous concatenation, the label that is used is = the > > lowest label of the contiguously concatenated signal as = explained > > before. The higher part of the label indicates where the signal > > starts and the lowest part is not significant. For instance, = when > > requesting an STS-48c the label is S>0, U=3D0, K=3D0, L=3D0, = M=3D0. > > > > Examples of labels: > > > > Example 1: S>0, U=3D1, K=3D1, L=3D0, M=3D0 > > Denotes the unstructured VC-4/STS-3c-SPE of the Sth > AUG-1/STS-3 group. > > > > Example 2: S>0, U=3D1, K>1, L=3D1, M=3D0 > > Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth = AUG-1. > > > > Example 3: S>0, U>1, K=3D0, L=3D0, M=3D0 > > Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth > > AUG-1/STS-3 group. > > > > Example 4: S>0, U>1, K=3D0, L>1, M=3D1 > > Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth > VC-3/STS-1 > > SPE of the Sth AUG-1/STS-3 group. > > > > Example 5: S>0, U>1, K=3D0, L>1, M=3D9 > > Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the = Uth > > VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. > > > > Example 6: S>0, U=3D1, K>1, L>1, M=3D5 > > Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in > the VC-4 of > > the Sth AUG-1. > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > > > Gesendet: Donnerstag, 18. Oktober 2001 18:58 > > > An: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > > > Betreff: RE: Moving right along ... > > > > > > > > > Hello Juergen, > > > > > > Your comments are addressed hereafter. Note that you didn't = raised any > > > technical problem or mistake in your comments (i.e. the draft > > "works" very > > > well as it is). > > > > > > - the first comment is not about a technical issue but an > > > "editorial" issue. > > > - the second comment is about a change that will not bring any = new > > > capability. > > > > > > >Concerning the SDH/Sonet documents I want to raise a formal = issue. > > > >We have now two documents, a document that covers ITU/ANSI = standard > > > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document = that > > > covers non-standard features > > > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in > > > Appendix 1 > > > of the standard feature document a non standard feature (Group > > signals) is > > > listed. It is even mentioned that the use of groups (AUG, STSG, > > > ...) is not > > > described in standards. So this feature should be moved to the > > > non-standards > > > document. Otherwise the split of the documents doesn't make = sense. > > > > > > We spend a considerable amount of time speaking about this > > > particular issue > > > and I still don't see any technical justification for what you = said. > > > > > > For those who are not SDH/SONET experts some quick explanation: > > > > > > We call a "super-circuit" a set of physical circuits in the > > > transport plane > > > all belonging to the same LSP in the signaling plane. We > > defined two kinds > > > of super-circuits: "group circuits" and "multiplicative = circuits". > > > > > > Multiplicative circuits are setup using the multiplier field that > > > we defined > > > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no > > > objection > > > about these ones. > > > > > > Group circuits are setup using the SDH/SONET naming for groups, > > i.e. AUG, > > > TUG, VTG (we defined the equivalent signal type in the = signaling). The > > > comment of Juergen is about these group circuits. A group circuit > > > represents > > > some bandwidth at a given place in the SDH/SONET multiplex. The > > > advantage of > > > such a super-circuit is that the customer can re-structure its > > content as > > > he/she likes. The operator doesn't care. > > > > > > Such an application is possible and is already implemented. > SDH/SONET is > > > self-describing, i.e. by looking at the signal one can understand > > > how it is > > > structured (like Juergen explained on the mailing list), so one > > > can setup a > > > circuit without describing the content (very very cool). > > > > > > The transport plane ignores that the signaling plane uses an > > "abstraction" > > > (i.e. an LSP) representing several physical circuits. Note that > > > restoration > > > and management belong respectively to the signaling plane and to = the > > > management plane in the IETF view (not to the transport plane > > like in the > > > ITU-T view). > > > > > > From that point of view, group circuits are a GMPLS signaling > > > plane feature > > > and not a transport plane feature. We put the comment on the fact > > > that this > > > is not defined (like GMPLS LSPs, etc) by ITU-T to make some > guys happy. > > > > > > I could say clearly at the beginning of the draft that the signal > > > types that > > > we are defining in this document are not ITU-T signal types but > > > GMPLS signal > > > types (of course) whose have in some cases a direct > > relationship with the > > > ITU-T signal types. > > > > > > Any objection ? > > > > > > >For the Sonet and SDH labels in > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I > > > prefer to have the same coding for Sonet and SDH. That makes the > > > implementation for Sonet and SDH simpler. Furthermore ITU and T1 > > > have tried > > > over the last years to align Sonet and SDH as much as possible. = The > > > definition of different labels for Sonet and SDH contradicts = these > > > activities. > > > > > > We discussed this one since a long time as well. Let me be clear: > > > > > > - labels are local to an interface (we all agree). > > > - a link (interface) is operated at one point in the time as > > either SDH or > > > SONET. > > > - your proposal will require to re-evaluate many things. > > > - and it took us a lot of time to fine-tune and to validate > the current > > > label structure. > > > - we could have technical issues with your proposal that would > > impact more > > > than this draft (Dimitri saw some of them, please see with him). > > > - you never provided a complete analysis of your proposal. > > > > > > But more important: your proposal doesn't bring any additional > > > functionality > > > to the draft. > > > > > > At this very late stage, since this not bringing any new > > > functionality, and > > > since the label structure is very stable since a long time, I > > would prefer > > > not to restart a long technical discussion to change and > re-validate the > > > draft. > > > > > > Kind regards, > > > > > > Eric > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > > > > An: ccamp@ops.ietf.org > > > > Betreff: Moving right along ... > > > > > > > > > > > > Despite the energetic subject line, we the WG chairs have been > > > > lax in our duties. So, here goes: > > > > > > > > Lou has submitted the latest versions of the generalized > > > > signaling documents quite some time ago (thanks, Lou): > > > > > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > > > draft-ietf-mpls-generalized-signaling-06.txt > > > > > > > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > > > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > > > > > All of these should have addressed the issues raised in the = earlier > > > > versions. Please read the new versions, and send your comments = to > > > > the list by Tuesday Oct 23. At that point, when the final = round > > > > of comments have been addressed, these docs will go to IESG = Last > > > > Call. If any one objects to sending these docs to IESG Last = Call, > > > > raise your issues now. > > > > > > > > I see that the GMPLS architecture document is a CCAMP WG doc, = but > > > > the minutes say that we should look for consensus on the list. = So, > > > > if you think this doc *shouldn't* be a WG doc, let us know. = (If we > > > > arrived at a consensus, remind me :-)) If nothing is heard, = the doc > > > > will progress to WG Last Call. > > > > > > > > The docs > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration = to be > > > > CCAMP WG docs; consensus at the meeting was Yes. Please let = the > > > > list know what your thinking is on these. (BTW, both these = docs > > > > were to have some edits done. If the authors could do that = before > > > > the next IETF, we can try to make more progress then.) > > > > > > > > The MIB overview doc was recently posted. Please read and = comment > > > > to the list. > > > > > > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > was generally thought to be useful; it will be published as a > > > > CCAMP informational doc. This begins a two week Last Call on > > > > the doc, ending Tuesday Oct 30. > > > > > > > > There was no consensus on whether the GMPLS framework should be > > > > a CCAMP WG doc. Please indicate your pleasure. > > > > > > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > > > raised that this draft is close to ready for WG Last Call. = Please > > > > review it, and let us know if you disagree. > > > > > > > > The OLI requirements doc was broadly accepted. Please let the > > > > list know if you think this doc should be a WG doc. > > > > > > > > It's still open whether we (the IETF) should be working on > > > > LMP-WDM. I urge the authors to keep on working on the doc, and > > > > keeping it in sync with LMP; however, we will postpone making = it > > > > a CCAMP WG doc until the issue is resolved. Hopefully that = will > > > > happen in Salt Lake City. > > > > > > > > There was reasonable interest in the tunnel trace requirements > > > > doc. Let's formalize this: do you think this should be made a > > > > CCAMP WG document? > > > > > > > > Summary: > > > > > > > > 1) Final comments and IESG Last Call readiness for: > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > > > draft-ietf-mpls-generalized-signaling-06.txt > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > > > > > 2) Should the following documents be CCAMP WG docs? > > > > draft-bonica-tunneltrace-02.txt > > > > draft-fontana-ccamp-gmpls-g709-00.txt > > > > draft-ietf-ccamp-gmpls-architecture-00.txt > > > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > > > draft-many-ccamp-gmpls-framework-00.txt > > > > draft-many-oli-reqts-00.txt > > > > > > > > 3) Comment on MIB overview. > > > > > > > > 4) Two week Last Call comments on > > > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > > > > > 5) Last Call readiness of > > > > draft-ietf-ccamp-gmpls-architecture-00.txt > > > > draft-ietf-ccamp-lmp-01.txt > > > > > > > > Thanks, > > > > Kireeti. > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 10:28:19 -0700 Message-Id: <200110231725.f9NHPu000172@merlot.juniper.net> To: shehzad.mirza@bt.com cc: ccamp@ops.ietf.org Subject: Re: Generalized Signalling - LSP Encoding Type expansion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44986.1003857956.1@juniper.net> Date: Tue, 23 Oct 2001 10:25:56 -0700 From: Yakov Rekhter Shehzad, > Yakov, > > The percentage of carriers that have all of their requirements met by the > current GMPLS drafts is an unknown. However the following points still > need to be addressed. > > 1. Why would an operator adopt GMPLS infrastructure if it only carried a > subset of the transport services that they are already offer to customers? > In effect spending more and getting less. It depends on the percentage of the total profit that could be generated by the subset. > 2. Why is there a problem reserving a code-point for a service that some > vendors may wish to implement on their GMPLS equipment? Presumably they > would not implement capability for which there is no demand. If all you ask is a code-point, this code point is relevant only to the LSPs' end-points, and not every GMPLS vendor is *required* to support this code-point, then I don't think there is a problem with doing this. > 3. What is the process by which certain transport services are decided > suitable for inclusion into the GMPLS specifications/drafts? It seems that > inclusion of additional services fraught with difficulties, this is likely > to get worse when the drafts turn into specifications. The types of services that would be suitable for inclusion are the services that (a) would *not* require changes/upgrades to the GMPLS core, and (b) would not require every GMPLS vendor to implement every service. Yakov. > > > > Shehzad > > > > > -----Original Message----- > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > Sent: 23 October 2001 16:17 > > To: Lazer, Monica A, NNAD > > Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > Monica, > > > > > All, > > > I am in full agreement with Shehzad. From a carrier's perspective, the > > value > > > of the control plane is in taking over specific functions which > > currently > > > reside in OSSs outside of the network itself. Having only some > > applications, > > > but not others of the given function move into the network greatly > > > diminishes the value of having that function supported in the control > > plane. > > > To be more specific, if out of n services supported by the transport > > > network, the control plane supports automated provisioning of 1/2n > > services > > > and the other 1/2n need support in the OSS, we still need to do the OSS > > work > > > for the given transport technology. So from a cost perspective, now we > > have > > > to ask ourselves whether we should pay for the provisioning function > > twice. > > > > While what you said makes sense from a given carrier's perspective, > > we need to take a broader view, as producing a "perfect solution" > > that meets *all* the requirements of *all* the carriers is an > > explicit non-goal of GMPLS. With this in mind, if the 1/2n services > > that aren't supported by the control plane are the services that > > are required by 90% of the carriers market, then indeed this is a > > problem. On the other hand, if these 1/2n services that aren't > > supported are the services required by only 10% of the carriers > > market, then this is quite acceptable. Understandably, the carriers > > who would fall into this 10% category could be quite unhappy about, > > and could even be quite vocal in expressing their dissatisfaction... > > > > Yakov. > > > > > Regards, > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > > > > -----Original Message----- > > > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] > > > Sent: Tuesday, October 23, 2001 6:25 AM > > > To: yakov@juniper.net > > > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > > > Subject: RE: Generalized Signaling - LSP Encoding Type expansion > > > > > > Yakov, > > > > > > See comments in-line > > > > > > > -----Original Message----- > > > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > > > Sent: 22 October 2001 21:12 > > > > To: Lazer, Monica A, NNAD > > > > Cc: ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > > > Monica, > > > > > > > > > Dimitri, > > > > > Actually, it may be more accurate to put it differently - if GMPLS > > > > supports > > > > > only a handful of the services running on a given transport network, > > > > than > > > > > its value as a network's control plane component is diminished. > > > > > > > > To be even more accurate, GMPLS value is diminished *in the context* > > > > of that particular transport network. And unless *all* providers > > > > are going to run *all possible services* on their transport networks > > > > (which is a somewhat unrealistic scenario), that means that the > > > > value of GMPLS as a network's control plane component would be > > > > diminished for *some*, but not *all* service providers. > > > > > > > > > > > > > > > [shehzad] > > > For a control plane not to support all the transport services capable of > > being carried over an operator's network diminishes the value of that > > > particular control plane. What is the point of having > > transparent/optical > > > equipment capable of transporting both Gigabit Ethernet and Fiber > > Channel > > > (as an example), if provisioning was based on signalling that could only > > > support Gigabit Ethernet? > > > > > > This is a restriction for every provider regardless of whether a network > > is > > > a standalone one built for a large customer or a national network > > serving > > > multiple customers. The effective 'banning' of certain services that are > > > currently being offered by providers will unnecessarily damage the > > business > > > case for the adoption of GMPLS. > > > > > > > > > > > > > At the same time, it is important to keep in mind that being "all > > > > things for all people" (aka as "perfect solution") is one of the > > > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > > > *particular* provider GMPLS would *not* support *all* the services > > > > that this provider runs on its transport network. > > > > > > > > Yakov. > > > > > > > > > > > [Shehzad] > > > There is no technical reason why a GMPLS encoding type could not be > > > adopted for a recognised format such as Fiber Channel, as far as I am > > aware > > > the adoption of Fiber Channel is not likely to destroy the foundations > > of > > > GMPLS. > > > > > > On a more general point, is the support of transport technologies > > > within GMPLS signalling restricted to those that the authors of the > > GMPLS > > > drafts will allow? > > > > > > > > > > > > > > > > > > > > > > > Monica A. Lazer > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > 908 234 8462 > > > > > mlazer@att.com > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dimitri Papadimitriou > > > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > > > > > Sent: Monday, October 22, 2001 3:15 PM > > > > > To: Lazer, Monica A, NNAD > > > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > expansion > > > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > > > > > > > Fine. Now we know the following: GMPLS is really attractive for > > > > > carriers when it supports all transport technologies so it has > > > > > to support Fiber Channel as well. > > > > > > > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > > > > > > > Regards, > > > > > Dimitri. > > > > > > > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > > > > > > > Dimitri, > > > > > > I am just answering the PS question with this message. > > > > > > The short answer is yes. The long answer is that the GMPLS > > control > > > > plane > > > > > is > > > > > > really useful if it can support connection management for all the > > > > > transport > > > > > > services supported by the transport network using GMPLS. > > Therefore, > > > > the > > > > > > carrier services section for the NNI document to be posted on the > > OIF > > > > site > > > > > > within a few minutes and the next draft of the carrier > > requirements > > > > IETF > > > > > > draft will both contain references to support of Fiber Channel. > > > > > > Regards, > > > > > > Monica A. Lazer > > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > > > 908 234 8462 > > > > > > mlazer@att.com > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dimitri Papadimitriou > > > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > > > To: Ewart Tempest > > > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > > > expansion > > > > > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > > > > > > > If you take a look on the IEEE Standards you will see > > > > > > that GE is referred to as > > > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > > > > > > > So my question is what do you have in mind ? to separate > > > > > > these values ? > > > > > > > > > > > > Thanks, > > > > > > Dimitri. > > > > > > > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > > > > > > > ------- > > > > > > > > > > > > [1] From - http://standards.ieee.org > > > > > > > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and > > minimal > > > > > > augmentation of its operation, physical layer characteristics, > > > > repeater > > > > > > functions and management parameters for transfer of 802.3 and > > Ethernet > > > > > > format frames at 1,000 Mb/s. > > > > > > > > > > > > Project purpose: The purpose of this project is to extend the > > 802.3 > > > > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > > > > significant increase in bandwidth while maintaining maximum > > > > > > compatibility > > > > > > with the installed base of CSMA/CD nodes, previous investment in > > > > > > research > > > > > > and development, and principles of network operation and > > management. > > > > > > > > > > > > [2] From - http://standards.ieee.org > > > > > > > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters > > and > > > > > > minimal augmentation of its operation, physical layer > > characteristics > > > > > > and management parameters for transfer of LLC and Ethernet format > > > > > > frames at 10 Gb/s using full duplex operation as defined in the > > 802.3 > > > > > > standard. In addition to the traditional LAN space, add parameters > > and > > > > > > mechanisms that enable deployment of Ethernet over the Wide Area > > > > Network > > > > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > > > > payload > > > > > > rate. > > > > > > > > > > > > Project purpose: The purpose of this project is to extend the > > 802.3 > > > > > > protocol to an operating speed of 10 Gb/s and to expand the > > Ethernet > > > > > > application space to include Wide Area Network links in order to > > > > provide > > > > > > a significant increase in bandwidth while maintaining maximum > > > > > > compatibility > > > > > > with the installed base of 802.3 interfaces, previous investment > > in > > > > > > research > > > > > > and development, and principles of network operation and > > management. > > > > > > > > > > > > ------- > > > > > > > > > > > > > Ewart Tempest wrote: > > > > > > > > > > > > > > Lou, > > > > > > > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 > > can > > > > > > > you please add additonal LSP Encoding Types for GE and > > FiberChannel. > > > > > > > GE is not really covered by the existing Ethernet related > > encoding > > > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > > > > > Ewart > > > > > > > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650 > > > Content-Type: text/html; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > 5.5.2654.19"> > > > RE: Generalized Signaling - LSP Encoding Type expansion > > > > > > > > > > > >

All, > > >
I am in full agreement with Shehzad. From a = > > > carrier's perspective, the value of the control plane is in taking over > > = > > > specific functions which currently reside in OSSs outside of the = > > > network itself. Having only some applications, but not others of the = > > > given function move into the network greatly diminishes the value of = > > > having that function supported in the control plane. To be more = > > > specific, if out of n services supported by the transport network, the = > > > control plane supports automated provisioning  of 1/2n services = > > and the other 1/2n need support in the OSS, we still need to do the OSS = > > > work for the given transport technology. So from a cost perspective, = > > > now we have to ask ourselves whether we should pay for the provisioning > > = > > > function twice.

> > > > > >

Regards, > > >

> > > > > >

Monica A. Lazer > > >
Advanced Transport Technology and Architecture = > > > Planning > > >

> > > > > >

908 234 8462 > > >
mlazer@att.com > > >

> > >
> > > > > >

 -----Original Message----- > > >
From:   shehzad.mirza@bt.com [ > > HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = > > > > > >
Sent:   Tuesday, October 23, 2001 6:25 = > > > AM > > >
To:     yakov@juniper.net > > >
Cc:     Lazer, Monica A, NNAD; = > > > ccamp@ops.ietf.org > > >
Subject:        = > > > RE: Generalized Signaling - LSP Encoding Type expansion > > >

> > > > > >

Yakov, > > >

> > > > > >

See comments in-line > > >

> > > > > >

> -----Original Message----- > > >
> From: Yakov Rekhter = > > > [SMTP:yakov@juniper.net] > > >
> Sent: 22 October 2001 21:12 > > >
> To:   Lazer, Monica A, NNAD > > >
> Cc:   ccamp@ops.ietf.org > > >
> Subject:      Re: = > > > Generalized Signaling - LSP Encoding Type expansion > > >
> > > >
> Monica, > > >
> > > >
> > Dimitri, > > >
> > Actually, it may be more accurate to put = > > > it differently - if GMPLS > > >
> supports > > >
> > only a handful of the services running on = > > > a given transport network, > > >
> than > > >
> > its value as a network's control plane = > > > component is diminished. > > >
> > > >
> To be even more accurate, GMPLS value is = > > > diminished *in the context* > > >
> of that particular transport network. And = > > > unless *all* providers > > >
> are going to run *all possible services* on = > > > their transport networks > > >
> (which is a somewhat unrealistic scenario), = > > > that means that the > > >
> value of GMPLS as a network's control plane = > > > component would be > > >
> diminished for *some*, but not *all* service = > > > providers. > > >
> > > >
> > > >
> > > >
        > > SIZE=3D2>[shehzad]  > > >
For a control plane not to support all the transport > > = > > > services capable of > > >
being carried over an operator's network diminishes = > > > the value of that > > >
particular control plane.  What is the point of > > = > > > having transparent/optical > > >
equipment capable of transporting both Gigabit = > > > Ethernet and Fiber Channel > > >
(as an example), if provisioning was based on = > > > signalling that could only > > >
support Gigabit Ethernet? > > >

> > > > > >

This is a restriction for every provider regardless = > > > of whether a network is > > >
a standalone one built for a large customer or a = > > > national network serving > > >
multiple customers. The effective 'banning' of = > > > certain services that are > > >
currently being offered by providers will = > > > unnecessarily damage the business > > >
case for the adoption of GMPLS. > > >

> > >
> > >
> > > > > >

> At the same time, it is important to keep in = > > > mind that being "all > > >
> things for all people" (aka as = > > > "perfect solution") is one of the > > >
> *non-goals* of GMPLS. So, it shouldn't come as = > > > a surprise if for a > > >
> *particular* provider GMPLS would *not* support > > = > > > *all* the services > > >
> that this provider runs on its transport = > > > network. > > >
> > > >
> Yakov. > > >
> > > >
> > > >
        > > SIZE=3D2>[Shehzad] > > >
        There is = > > > no technical reason why a GMPLS encoding type could not be > > >
adopted for a recognised format such as Fiber = > > > Channel, as far as I am aware > > >
the adoption of Fiber Channel is not likely to = > > > destroy the foundations of > > >
GMPLS. > > >

> > > > > >

        On a more = > > > general point, is the support of transport technologies > > >
within GMPLS signalling restricted to those that the > > = > > > authors of the GMPLS > > >
drafts will allow? > > >
         = > > > > > >

> > >
> > >
> > >
> > >
> > > > > >

> > Monica A. Lazer > > >
> > Advanced Transport Technology and = > > > Architecture Planning > > >
> > > > >
> > 908 234 8462 > > >
> > mlazer@att.com > > >
> > > > >
> > > > >
> >  -----Original Message----- > > >
> > From:       = > > > Dimitri Papadimitriou > > >
> [ > > > > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > > > triou@alcatel.be] > > >
>  > > >
> > Sent:       = > > > Monday, October 22, 2001 3:15 PM > > >
> > To: Lazer, Monica A, NNAD > > >
> > Cc: Ewart Tempest; lberger@movaz.com; = > > > ccamp@ops.ietf.org > > >
> > Subject:    Re: Generalized > > = > > > Signaling - LSP Encoding Type expansion > > >
> > > > >
> >  << File: Card for Dimitri = > > > Papadimitriou >> Hi Monica, > > >
> > > > >
> > Fine. Now we know the following: GMPLS is = > > > really attractive for > > >
> > carriers when it supports all transport = > > > technologies so it has > > >
> > to support Fiber Channel as well. > > >
> > > > >
> > I wasn't aware that Ewart was capable to = > > > read in your mind ;-) > > >
> > > > >
> > Regards, > > >
> > Dimitri. > > >
> > > > >
> > "Lazer, Monica A, NNAD" = > > > wrote: > > >
> > > > > >
> > > Dimitri, > > >
> > > I am just answering the PS question = > > > with this message. > > >
> > > The short answer is yes.  The = > > > long answer is that the GMPLS control > > >
> plane > > >
> > is > > >
> > > really useful if it can support = > > > connection management for all the > > >
> > transport > > >
> > > services supported by the transport = > > > network using GMPLS. Therefore, > > >
> the > > >
> > > carrier services section for the NNI = > > > document to be posted on the OIF > > >
> site > > >
> > > within a few minutes and the next = > > > draft of the carrier requirements > > >
> IETF > > >
> > > draft will both contain references to > > = > > > support of Fiber Channel. > > >
> > > Regards, > > >
> > > Monica A. Lazer > > >
> > > Advanced Transport Technology and = > > > Architecture Planning > > >
> > > > > >
> > > 908 234 8462 > > >
> > > mlazer@att.com > > >
> > > > > >
> > >  -----Original = > > > Message----- > > >
> > > From:   Dimitri = > > > Papadimitriou > > >
> [ > > > > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > > > triou@alcatel.be] > > >
> > > Sent:   Monday, October 22, > > = > > > 2001 2:47 PM > > >
> > > To:     Ewart = > > > Tempest > > >
> > > Cc:     = > > > lberger@movaz.com; ccamp@ops.ietf.org > > >
> > > = > > > Subject:        Re: Generalized = > > > Signaling - LSP Encoding Type > > >
> expansion > > >
> > > > > >
> > >  << File: Card for Dimitri > > = > > > Papadimitriou >> Hi Ewart, > > >
> > > > > >
> > > If you take a look on the IEEE = > > > Standards you will see > > >
> > > that GE is referred to as > > >
> > > - 802.3z for 1Gbps (see below [1]) = > > > same exists for copper 802.3ab > > >
> > > - 802.3ae for 10Gbps (see below = > > > [2]) > > >
> > > > > >
> > > So my question is what do you have in > > = > > > mind ? to separate > > >
> > > these values ? > > >
> > > > > >
> > > Thanks, > > >
> > > Dimitri. > > >
> > > > > >
> > > PS: for FiberChannel sorry i am not = > > > an expert but is someone > > >
> > >     targeting to = > > > use GMPLS for FiberChannel LSP ? > > >
> > > > > >
> > > ------- > > >
> > > > > >
> > > [1] From - > > HREF=3D"http://standards.ieee.org" = > > > TARGET=3D"_blank">http://standards.ieee.org > > >
> > > > > >
> > > Project scope: Define Carrier Sense = > > > Multiple Access with Collision > > >
> > > Detection (CSMA/CD) Media Access = > > > Control (MAC) parameters and minimal > > >
> > > augmentation of its operation, = > > > physical layer characteristics, > > >
> repeater > > >
> > > functions and management parameters = > > > for transfer of 802.3 and Ethernet > > >
> > > format frames at 1,000 Mb/s. > > >
> > > > > >
> > > Project purpose: The purpose of this = > > > project is to extend the 802.3 > > >
> > > protocol to an operating speed of = > > > 1,000 Mb/s in order to provide a > > >
> > > significant increase in bandwidth = > > > while maintaining maximum > > >
> > > compatibility > > >
> > > with the installed base of CSMA/CD = > > > nodes, previous investment in > > >
> > > research > > >
> > > and development, and principles of = > > > network operation and management. > > >
> > > > > >
> > > [2] From - > > HREF=3D"http://standards.ieee.org" = > > > TARGET=3D"_blank">http://standards.ieee.org > > >
> > > > > >
> > > Project scope: Define 802.3 Media = > > > Access Control (MAC) parameters and > > >
> > > minimal augmentation of its = > > > operation, physical layer characteristics > > >
> > > and management parameters for = > > > transfer of LLC and Ethernet format > > >
> > > frames at 10 Gb/s using full duplex = > > > operation as defined in the 802.3 > > >
> > > standard. In addition to the = > > > traditional LAN space, add parameters and > > >
> > > mechanisms that enable deployment of = > > > Ethernet over the Wide Area > > >
> Network > > >
> > > operating at a data rate compatible = > > > with OC-192c and SDH VC-4-64c > > >
> > > payload > > >
> > > rate. > > >
> > > > > >
> > > Project purpose: The purpose of this = > > > project is to extend the 802.3 > > >
> > > protocol to an operating speed of 10 = > > > Gb/s and to expand the Ethernet > > >
> > > application space to include Wide = > > > Area Network links in order to > > >
> provide > > >
> > > a significant increase in bandwidth = > > > while maintaining maximum > > >
> > > compatibility > > >
> > > with the installed base of 802.3 = > > > interfaces, previous investment in > > >
> > > research > > >
> > > and development, and principles of = > > > network operation and management. > > >
> > > > > >
> > > ------- > > >
> > > > > >
> > > > Ewart Tempest wrote: > > >
> > > > > > >
> > > > Lou, > > >
> > > > > > >
> > > > Within section 3.1.1 of = > > > draft-ietf-mpls-generalized-signaling-06 can > > >
> > > > you please add additonal LSP = > > > Encoding Types for GE and FiberChannel. > > >
> > > > GE is not really covered by the = > > > existing Ethernet related encoding > > >
> > > > types, and FiberChannel is not = > > > covered at all. Thanks. > > >
> > > > > > >
> > > > Ewart > > >
> > > > >

> > > > > > > > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 09:30:16 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBB3@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Eric Gray'" , Yakov Rekhter Cc: ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 11:49:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric, let's see if I got this right... Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Tuesday, October 23, 2001 11:37 AM To: Yakov Rekhter Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Yakov, To be completely fair, it is NOT necessary for any provider to run "*all possible services*" for the introduction of a new control plane which supports only a subset of those services to be costly. It is only necessary for a provider to need to provide some services from that subset and some services from the universe-less-that-subset for it to be necessary to either support multiple control planes, or avoid use of the new control plane. [[Lazer, AT&T]] Yes, what I mean is that if a given NE needs two control planes that is bad. This is probably what Monica means by diminished value. On the other hand, GMPLS is intended to be optimized for IP which - in some people's model of *the future of networking* - might mean that it will likely be adopted in spite of a perceived diminished value in the general sense. Hence, I think part of your point might be better expressed as: [[Lazer, AT&T]] As far as I understand, MPLS is for IP, GMPLS encompasses extensions needed to control the transport network. IP networks, whether they represent a large percentage of the traffic, still run over facilities. In my view GMPLS is a control plane intended for managing facilities. Saying that GMPLS is only intended for IP is puzzling, because if this is true, why is it a claim that it can provide the control plane of transport facilities? *Extending GMPLS to support all possible applications in an effort to reduce a perception of diminished value, would actually diminish the value of GMPLS for its target application(s).* [[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we should work to make it that. What do you think? You wrote: > Monica, > > > Dimitri, > > Actually, it may be more accurate to put it differently - if GMPLS supports > > only a handful of the services running on a given transport network, than > > its value as a network's control plane component is diminished. > > To be even more accurate, GMPLS value is diminished *in the context* > of that particular transport network. And unless *all* providers > are going to run *all possible services* on their transport networks > (which is a somewhat unrealistic scenario), that means that the > value of GMPLS as a network's control plane component would be > diminished for *some*, but not *all* service providers. > > At the same time, it is important to keep in mind that being "all > things for all people" (aka as "perfect solution") is one of the > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > *particular* provider GMPLS would *not* support *all* the services > that this provider runs on its transport network. > > Yakov. > > > > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 3:15 PM > > To: Lazer, Monica A, NNAD > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > Fine. Now we know the following: GMPLS is really attractive for > > carriers when it supports all transport technologies so it has > > to support Fiber Channel as well. > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > Regards, > > Dimitri. > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > Dimitri, > > > I am just answering the PS question with this message. > > > The short answer is yes. The long answer is that the GMPLS control plane > > is > > > really useful if it can support connection management for all the > > transport > > > services supported by the transport network using GMPLS. Therefore, the > > > carrier services section for the NNI document to be posted on the OIF site > > > within a few minutes and the next draft of the carrier requirements IETF > > > draft will both contain references to support of Fiber Channel. > > > Regards, > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 2:47 PM > > > To: Ewart Tempest > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > If you take a look on the IEEE Standards you will see > > > that GE is referred to as > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > So my question is what do you have in mind ? to separate > > > these values ? > > > > > > Thanks, > > > Dimitri. > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > ------- > > > > > > [1] From - http://standards.ieee.org > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > augmentation of its operation, physical layer characteristics, repeater > > > functions and management parameters for transfer of 802.3 and Ethernet > > > format frames at 1,000 Mb/s. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of CSMA/CD nodes, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > [2] From - http://standards.ieee.org > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > minimal augmentation of its operation, physical layer characteristics > > > and management parameters for transfer of LLC and Ethernet format > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > standard. In addition to the traditional LAN space, add parameters and > > > mechanisms that enable deployment of Ethernet over the Wide Area Network > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > payload > > > rate. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > application space to include Wide Area Network links in order to provide > > > a significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of 802.3 interfaces, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > ------- > > > > > > > Ewart Tempest wrote: > > > > > > > > Lou, > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > GE is not really covered by the existing Ethernet related encoding > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > Ewart > > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 09:05:00 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBB4@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Yakov Rekhter'" Cc: "'shehzad.mirza@bt.com'" , ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 11:49:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15BDA.57D4DA50" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15BDA.57D4DA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yakov,=20 We seem to have the same discussion on two separate threads. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net]=20 Sent: Tuesday, October 23, 2001 11:17 AM To: Lazer, Monica A, NNAD Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion=20 Monica, > All, > I am in full agreement with Shehzad. From a carrier's perspective, = the value > of the control plane is in taking over specific functions which = currently > reside in OSSs outside of the network itself. Having only some applications, > but not others of the given function move into the network greatly > diminishes the value of having that function supported in the control plane. > To be more specific, if out of n services supported by the transport > network, the control plane supports automated provisioning of 1/2n services > and the other 1/2n need support in the OSS, we still need to do the = OSS work > for the given transport technology. So from a cost perspective, now = we have > to ask ourselves whether we should pay for the provisioning function twice. While what you said makes sense from a given carrier's perspective, we need to take a broader view, as producing a "perfect solution" that meets *all* the requirements of *all* the carriers is an explicit non-goal of GMPLS. With this in mind, if the 1/2n services that aren't supported by the control plane are the services that are required by 90% of the carriers market, then indeed this is a problem. On the other hand, if these 1/2n services that aren't supported are the services required by only 10% of the carriers market, then this is quite acceptable. Understandably, the carriers who would fall into this 10% category could be quite unhappy about, and could even be quite vocal in expressing their dissatisfaction... [[Lazer, AT&T]] I would add one thing - if the actual box supports the = n services, than its brains should too. Going from generic to specifics, there is a growing interest for SAN services within the industry.=20 Going from experience, at OIF we had to give up support for GbE from = UNI 1.0 and we see that leaving it out it was a poor choice. So, are we = looking at "d=E9j=E0 vu all over again"? I hope not. And obviously, nobody would = expect the control plane implementation in a given NE to support services that the = NE itself does not. Also, there may be some connection management items = that are not considered equally hot by all. So there is a lot of room in = that area.=20 Regards, again Yakov. > Regards, >=20 > Monica A. Lazer > Advanced Transport Technology and Architecture Planning >=20 > 908 234 8462 > mlazer@att.com >=20 >=20 > -----Original Message----- > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com]=20 > Sent: Tuesday, October 23, 2001 6:25 AM > To: yakov@juniper.net > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > Subject: RE: Generalized Signaling - LSP Encoding Type expansion=20 >=20 > Yakov, >=20 > See comments in-line >=20 > > -----Original Message----- > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > Sent: 22 October 2001 21:12 > > To: Lazer, Monica A, NNAD > > Cc: ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion=20 > >=20 > > Monica, > >=20 > > > Dimitri, > > > Actually, it may be more accurate to put it differently - if = GMPLS > > supports > > > only a handful of the services running on a given transport = network, > > than > > > its value as a network's control plane component is diminished.=20 > >=20 > > To be even more accurate, GMPLS value is diminished *in the = context* > > of that particular transport network. And unless *all* providers > > are going to run *all possible services* on their transport = networks > > (which is a somewhat unrealistic scenario), that means that the > > value of GMPLS as a network's control plane component would be > > diminished for *some*, but not *all* service providers. > >=20 > >=20 > >=20 > [shehzad] =20 > For a control plane not to support all the transport services capable = of > being carried over an operator's network diminishes the value of that > particular control plane. What is the point of having = transparent/optical > equipment capable of transporting both Gigabit Ethernet and Fiber = Channel > (as an example), if provisioning was based on signalling that could = only > support Gigabit Ethernet? >=20 > This is a restriction for every provider regardless of whether a = network is > a standalone one built for a large customer or a national network = serving > multiple customers. The effective 'banning' of certain services that = are > currently being offered by providers will unnecessarily damage the business > case for the adoption of GMPLS. >=20 >=20 >=20 > > At the same time, it is important to keep in mind that being "all > > things for all people" (aka as "perfect solution") is one of the > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > *particular* provider GMPLS would *not* support *all* the services > > that this provider runs on its transport network. > >=20 > > Yakov. > >=20 > >=20 > [Shehzad] > There is no technical reason why a GMPLS encoding type could not be > adopted for a recognised format such as Fiber Channel, as far as I am aware > the adoption of Fiber Channel is not likely to destroy the = foundations of > GMPLS. >=20 > On a more general point, is the support of transport technologies > within GMPLS signalling restricted to those that the authors of the = GMPLS > drafts will allow?=20 > =20 >=20 >=20 >=20 >=20 >=20 > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > >=20 > > > 908 234 8462 > > > mlazer@att.com > > >=20 > > >=20 > > > -----Original Message----- > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > =20 > > > Sent: Monday, October 22, 2001 3:15 PM > > > To: Lazer, Monica A, NNAD > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > >=20 > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > >=20 > > > Fine. Now we know the following: GMPLS is really attractive for=20 > > > carriers when it supports all transport technologies so it has=20 > > > to support Fiber Channel as well. > > >=20 > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > >=20 > > > Regards, > > > Dimitri. > > >=20 > > > "Lazer, Monica A, NNAD" wrote: > > > >=20 > > > > Dimitri, > > > > I am just answering the PS question with this message. > > > > The short answer is yes. The long answer is that the GMPLS = control > > plane > > > is > > > > really useful if it can support connection management for all = the > > > transport > > > > services supported by the transport network using GMPLS. = Therefore, > > the > > > > carrier services section for the NNI document to be posted on = the OIF > > site > > > > within a few minutes and the next draft of the carrier = requirements > > IETF > > > > draft will both contain references to support of Fiber Channel. > > > > Regards, > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > >=20 > > > > 908 234 8462 > > > > mlazer@att.com > > > >=20 > > > > -----Original Message----- > > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > To: Ewart Tempest > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > expansion > > > >=20 > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > >=20 > > > > If you take a look on the IEEE Standards you will see > > > > that GE is referred to as > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper = 802.3ab > > > > - 802.3ae for 10Gbps (see below [2]) > > > >=20 > > > > So my question is what do you have in mind ? to separate > > > > these values ? > > > >=20 > > > > Thanks, > > > > Dimitri. > > > >=20 > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > targeting to use GMPLS for FiberChannel LSP ? > > > >=20 > > > > ------- > > > >=20 > > > > [1] From - http://standards.ieee.org > > > >=20 > > > > Project scope: Define Carrier Sense Multiple Access with = Collision > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > > augmentation of its operation, physical layer characteristics, > > repeater > > > > functions and management parameters for transfer of 802.3 and Ethernet > > > > format frames at 1,000 Mb/s. > > > >=20 > > > > Project purpose: The purpose of this project is to extend the = 802.3 > > > > protocol to an operating speed of 1,000 Mb/s in order to = provide a > > > > significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of CSMA/CD nodes, previous investment = in > > > > research > > > > and development, and principles of network operation and = management. > > > >=20 > > > > [2] From - http://standards.ieee.org > > > >=20 > > > > Project scope: Define 802.3 Media Access Control (MAC) = parameters and > > > > minimal augmentation of its operation, physical layer characteristics > > > > and management parameters for transfer of LLC and Ethernet = format > > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > > standard. In addition to the traditional LAN space, add = parameters and > > > > mechanisms that enable deployment of Ethernet over the Wide = Area > > Network > > > > operating at a data rate compatible with OC-192c and SDH = VC-4-64c > > > > payload > > > > rate. > > > >=20 > > > > Project purpose: The purpose of this project is to extend the = 802.3 > > > > protocol to an operating speed of 10 Gb/s and to expand the = Ethernet > > > > application space to include Wide Area Network links in order = to > > provide > > > > a significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of 802.3 interfaces, previous = investment in > > > > research > > > > and development, and principles of network operation and = management. > > > >=20 > > > > ------- > > > >=20 > > > > > Ewart Tempest wrote: > > > > > > > > > > Lou, > > > > > > > > > > Within section 3.1.1 of = draft-ietf-mpls-generalized-signaling-06 can > > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > > GE is not really covered by the existing Ethernet related = encoding > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > Ewart > > >=20 >=20 > ------_=3D_NextPart_001_01C15BCA.5A2A5650 > Content-Type: text/html; > charset=3D"iso-8859-1" > Content-Transfer-Encoding: quoted-printable >=20 > > > > charset=3D3Diso-8859-1"> > 5.5.2654.19"> > RE: Generalized Signaling - LSP Encoding Type expansion = > > >=20 >

All, >
I am in full agreement with Shehzad. From a =3D > carrier's perspective, the value of the control plane is in taking = over =3D > specific functions which currently reside in OSSs outside of the =3D > network itself. Having only some applications, but not others of the = =3D > given function move into the network greatly diminishes the value of = =3D > having that function supported in the control plane. To be more =3D > specific, if out of n services supported by the transport network, = the =3D > control plane supports automated provisioning  of 1/2n services = =3D and the other 1/2n need support in the OSS, we still need to do the OSS = =3D > work for the given transport technology. So from a cost perspective, = =3D > now we have to ask ourselves whether we should pay for the = provisioning =3D > function twice.

>=20 >

Regards, >

>=20 >

Monica A. Lazer >
Advanced Transport Technology and Architecture = =3D > Planning >

>=20 >

908 234 8462 >
mlazer@att.com >

>
>=20 >

 -----Original Message----- >
From:   shehzad.mirza@bt.com [ = HREF=3D3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = =3D > >
Sent:   Tuesday, October 23, 2001 6:25 = =3D > AM >
To:     = yakov@juniper.net >
Cc:     Lazer, Monica A, = NNAD; =3D > ccamp@ops.ietf.org >
Subject:        =3D > RE: Generalized Signaling - LSP Encoding Type expansion >

>=20 >

Yakov, >

>=20 >

See comments in-line >

>=20 >

> -----Original Message----- >
> From: Yakov Rekhter =3D > [SMTP:yakov@juniper.net] >
> Sent: 22 October 2001 21:12 >
> To:   Lazer, Monica A, = NNAD >
> Cc:   ccamp@ops.ietf.org >
> Subject:      Re: = =3D > Generalized Signaling - LSP Encoding Type expansion >
> >
> Monica, >
> >
> > Dimitri, >
> > Actually, it may be more accurate to = put =3D > it differently - if GMPLS >
> supports >
> > only a handful of the services running = on =3D > a given transport network, >
> than >
> > its value as a network's control plane = =3D > component is diminished. >
> >
> To be even more accurate, GMPLS value is = =3D > diminished *in the context* >
> of that particular transport network. And = =3D > unless *all* providers >
> are going to run *all possible services* on = =3D > their transport networks >
> (which is a somewhat unrealistic scenario), = =3D > that means that the >
> value of GMPLS as a network's control plane = =3D > component would be >
> diminished for *some*, but not *all* = service =3D > providers. >
> >
> >
> >
        SIZE=3D3D2>[shehzad]  >
For a control plane not to support all the = transport =3D > services capable of >
being carried over an operator's network = diminishes =3D > the value of that >
particular control plane.  What is the = point of =3D > having transparent/optical >
equipment capable of transporting both Gigabit = =3D > Ethernet and Fiber Channel >
(as an example), if provisioning was based on = =3D > signalling that could only >
support Gigabit Ethernet? >

>=20 >

This is a restriction for every provider = regardless =3D > of whether a network is >
a standalone one built for a large customer or a = =3D > national network serving >
multiple customers. The effective 'banning' of = =3D > certain services that are >
currently being offered by providers will =3D > unnecessarily damage the business >
case for the adoption of GMPLS. >

>
>
>=20 >

> At the same time, it is important to keep in = =3D > mind that being "all >
> things for all people" (aka as =3D > "perfect solution") is one of the >
> *non-goals* of GMPLS. So, it shouldn't come = as =3D > a surprise if for a >
> *particular* provider GMPLS would *not* = support =3D > *all* the services >
> that this provider runs on its transport = =3D > network. >
> >
> Yakov. >
> >
> >
        SIZE=3D3D2>[Shehzad] >
        There = is =3D > no technical reason why a GMPLS encoding type could not be >
adopted for a recognised format such as Fiber = =3D > Channel, as far as I am aware >
the adoption of Fiber Channel is not likely to = =3D > destroy the foundations of >
GMPLS. >

>=20 >

        On a = more =3D > general point, is the support of transport technologies >
within GMPLS signalling restricted to those that = the =3D > authors of the GMPLS >
drafts will allow? >
         = =3D > >

>
>
>
>
>=20 >

> > Monica A. Lazer >
> > Advanced Transport Technology and =3D > Architecture Planning >
> > >
> > 908 234 8462 >
> > mlazer@att.com >
> > >
> > >
> >  -----Original = Message----- >
> > From:       = =3D > Dimitri Papadimitriou >
> [ = HREF=3D3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadi= mi=3D > triou@alcatel.be] >
>  >
> > = Sent:       =3D > Monday, October 22, 2001 3:15 PM >
> > To: Lazer, Monica A, NNAD >
> > Cc: Ewart Tempest; lberger@movaz.com; = =3D > ccamp@ops.ietf.org >
> > Subject:    Re: = Generalized =3D > Signaling - LSP Encoding Type expansion >
> > >
> >  << File: Card for Dimitri = =3D > Papadimitriou >> Hi Monica, >
> > >
> > Fine. Now we know the following: GMPLS = is =3D > really attractive for >
> > carriers when it supports all = transport =3D > technologies so it has >
> > to support Fiber Channel as = well. >
> > >
> > I wasn't aware that Ewart was capable = to =3D > read in your mind ;-) >
> > >
> > Regards, >
> > Dimitri. >
> > >
> > "Lazer, Monica A, NNAD" =3D > wrote: >
> > > >
> > > Dimitri, >
> > > I am just answering the PS = question =3D > with this message. >
> > > The short answer is yes.  = The =3D > long answer is that the GMPLS control >
> plane >
> > is >
> > > really useful if it can support = =3D > connection management for all the >
> > transport >
> > > services supported by the = transport =3D > network using GMPLS. Therefore, >
> the >
> > > carrier services section for the = NNI =3D > document to be posted on the OIF >
> site >
> > > within a few minutes and the next = =3D > draft of the carrier requirements >
> IETF >
> > > draft will both contain = references to =3D > support of Fiber Channel. >
> > > Regards, >
> > > Monica A. Lazer >
> > > Advanced Transport Technology and = =3D > Architecture Planning >
> > > >
> > > 908 234 8462 >
> > > mlazer@att.com >
> > > >
> > >  -----Original =3D > Message----- >
> > > From:   Dimitri =3D > Papadimitriou >
> [ = HREF=3D3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadi= mi=3D > triou@alcatel.be] >
> > > Sent:   Monday, October = 22, =3D > 2001 2:47 PM >
> > > To:     Ewart = =3D > Tempest >
> > > Cc:     =3D > lberger@movaz.com; ccamp@ops.ietf.org >
> > > =3D > Subject:        Re: Generalized = =3D > Signaling - LSP Encoding Type >
> expansion >
> > > >
> > >  << File: Card for = Dimitri =3D > Papadimitriou >> Hi Ewart, >
> > > >
> > > If you take a look on the IEEE = =3D > Standards you will see >
> > > that GE is referred to as >
> > > - 802.3z for 1Gbps (see below = [1]) =3D > same exists for copper 802.3ab >
> > > - 802.3ae for 10Gbps (see below = =3D > [2]) >
> > > >
> > > So my question is what do you = have in =3D > mind ? to separate >
> > > these values ? >
> > > >
> > > Thanks, >
> > > Dimitri. >
> > > >
> > > PS: for FiberChannel sorry i am = not =3D > an expert but is someone >
> > >     targeting = to =3D > use GMPLS for FiberChannel LSP ? >
> > > >
> > > ------- >
> > > >
> > > [1] From - HREF=3D3D"http://standards.ieee.org" =3D > TARGET=3D3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define Carrier = Sense =3D > Multiple Access with Collision >
> > > Detection (CSMA/CD) Media Access = =3D > Control (MAC) parameters and minimal >
> > > augmentation of its operation, = =3D > physical layer characteristics, >
> repeater >
> > > functions and management = parameters =3D > for transfer of 802.3 and Ethernet >
> > > format frames at 1,000 = Mb/s. >
> > > >
> > > Project purpose: The purpose of = this =3D > project is to extend the 802.3 >
> > > protocol to an operating speed of = =3D > 1,000 Mb/s in order to provide a >
> > > significant increase in bandwidth = =3D > while maintaining maximum >
> > > compatibility >
> > > with the installed base of = CSMA/CD =3D > nodes, previous investment in >
> > > research >
> > > and development, and principles = of =3D > network operation and management. >
> > > >
> > > [2] From - HREF=3D3D"http://standards.ieee.org" =3D > TARGET=3D3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define 802.3 Media = =3D > Access Control (MAC) parameters and >
> > > minimal augmentation of its =3D > operation, physical layer characteristics >
> > > and management parameters for =3D > transfer of LLC and Ethernet format >
> > > frames at 10 Gb/s using full = duplex =3D > operation as defined in the 802.3 >
> > > standard. In addition to the =3D > traditional LAN space, add parameters and >
> > > mechanisms that enable deployment = of =3D > Ethernet over the Wide Area >
> Network >
> > > operating at a data rate = compatible =3D > with OC-192c and SDH VC-4-64c >
> > > payload >
> > > rate. >
> > > >
> > > Project purpose: The purpose of = this =3D > project is to extend the 802.3 >
> > > protocol to an operating speed of = 10 =3D > Gb/s and to expand the Ethernet >
> > > application space to include Wide = =3D > Area Network links in order to >
> provide >
> > > a significant increase in = bandwidth =3D > while maintaining maximum >
> > > compatibility >
> > > with the installed base of 802.3 = =3D > interfaces, previous investment in >
> > > research >
> > > and development, and principles = of =3D > network operation and management. >
> > > >
> > > ------- >
> > > >
> > > > Ewart Tempest wrote: >
> > > > >
> > > > Lou, >
> > > > >
> > > > Within section 3.1.1 of =3D > draft-ietf-mpls-generalized-signaling-06 can >
> > > > you please add additonal LSP = =3D > Encoding Types for GE and FiberChannel. >
> > > > GE is not really covered by = the =3D > existing Ethernet related encoding >
> > > > types, and FiberChannel is = not =3D > covered at all. Thanks. >
> > > > >
> > > > Ewart >
> > >

>=20 > > > ------_=3D_NextPart_001_01C15BCA.5A2A5650-- ------_=_NextPart_001_01C15BDA.57D4DA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Generalized Signaling - LSP Encoding Type expansion

Yakov,
We seem to have the same discussion on two separate = threads.

Monica A. Lazer
Advanced Transport Technology and Architecture = Planning

908 234 8462
mlazer@att.com


 -----Original Message-----
From:   Yakov Rekhter [mailto:yakov@juniper.net]
Sent:   Tuesday, October 23, 2001 11:17 = AM
To:     Lazer, Monica A, = NNAD
Cc:     'shehzad.mirza@bt.com'; = ccamp@ops.ietf.org
Subject:        = Re: Generalized Signaling - LSP Encoding Type expansion

Monica,

> All,
> I am in full agreement with Shehzad. From a = carrier's perspective, the value
> of the control plane is in taking over specific = functions which currently
> reside in OSSs outside of the network itself. = Having only some applications,
> but not others of the given function move into = the network greatly
> diminishes the value of having that function = supported in the control plane.
> To be more specific, if out of n services = supported by the transport
> network, the control plane supports automated = provisioning  of 1/2n services
> and the other 1/2n need support in the OSS, we = still need to do the OSS work
> for the given transport technology. So from a = cost perspective, now we have
> to ask ourselves whether we should pay for the = provisioning function twice.

While what you said makes sense from a given = carrier's perspective,
we need to take a broader view, as producing a = "perfect solution"
that meets *all* the requirements of *all* the = carriers is an
explicit non-goal of GMPLS. With this in mind, if = the 1/2n services
that aren't supported by the control plane are the = services that
are required by 90% of the carriers market, then = indeed this is a
problem. On the other hand, if these 1/2n services = that aren't
supported are the services required by only 10% of = the carriers
market, then this is quite acceptable. = Understandably, the carriers
who would fall into this 10% category could be quite = unhappy about,
and could even be quite vocal in expressing their = dissatisfaction...

[[Lazer, AT&T]] I would add one thing - if the = actual box supports the n services, than its brains should too.
Going from generic to specifics, there is a growing = interest for SAN services within the industry.
Going from experience, at OIF we had to give up = support for GbE from UNI 1.0 and we see that leaving it out it was a = poor choice.  So, are we looking at "d=E9j=E0 vu all over = again"? I hope not. And obviously, nobody would expect the control = plane implementation in a given NE to support services that the NE = itself does not. Also, there may be some connection management items = that are not considered equally hot by all. So there is a lot of room = in that area.


Regards, again
Yakov.

> Regards,
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture = Planning
>
> 908 234 8462
> mlazer@att.com
>
>
>  -----Original Message-----
> From: =         shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] =
> Sent: Tuesday, October 23, 2001 6:25 AM
> To:   yakov@juniper.net
> Cc:   Lazer, Monica A, NNAD; = ccamp@ops.ietf.org
> Subject:      RE: = Generalized Signaling - LSP Encoding Type expansion
>
> Yakov,
>
> See comments in-line
>
> > -----Original Message-----
> > From:       = Yakov Rekhter [SMTP:yakov@juniper.net]
> > Sent:       = 22 October 2001 21:12
> > To: Lazer, Monica A, NNAD
> > Cc: ccamp@ops.ietf.org
> > Subject:    Re: Generalized = Signaling - LSP Encoding Type expansion
> >
> > Monica,
> >
> > > Dimitri,
> > > Actually, it may be more accurate to = put it differently - if GMPLS
> > supports
> > > only a handful of the services = running on a given transport network,
> > than
> > > its value as a network's control = plane component is diminished.
> >
> > To be even more accurate, GMPLS value is = diminished *in the context*
> > of that particular transport network. And = unless *all* providers
> > are going to run *all possible services* = on their transport networks
> > (which is a somewhat unrealistic = scenario), that means that the
> > value of GMPLS as a network's control = plane component would be
> > diminished for *some*, but not *all* = service providers.
> >
> >
> >
>       [shehzad]  =
> For a control plane not to support all the = transport services capable of
> being carried over an operator's network = diminishes the value of that
> particular control plane.  What is the = point of having transparent/optical
> equipment capable of transporting both Gigabit = Ethernet and Fiber Channel
> (as an example), if provisioning was based on = signalling that could only
> support Gigabit Ethernet?
>
> This is a restriction for every provider = regardless of whether a network is
> a standalone one built for a large customer or = a national network serving
> multiple customers. The effective 'banning' of = certain services that are
> currently being offered by providers will = unnecessarily damage the business
> case for the adoption of GMPLS.
>
>
>
> > At the same time, it is important to keep = in mind that being "all
> > things for all people" (aka as = "perfect solution") is one of the
> > *non-goals* of GMPLS. So, it shouldn't = come as a surprise if for a
> > *particular* provider GMPLS would *not* = support *all* the services
> > that this provider runs on its transport = network.
> >
> > Yakov.
> >
> >
>       [Shehzad]
>       There is no = technical reason why a GMPLS encoding type could not be
> adopted for a recognised format such as Fiber = Channel, as far as I am aware
> the adoption of Fiber Channel is not likely to = destroy the foundations of
> GMPLS.
>
>       On a more = general point, is the support of transport technologies
> within GMPLS signalling restricted to those = that the authors of the GMPLS
> drafts will allow?
>       
>
>
>
>
>
> > > Monica A. Lazer
> > > Advanced Transport Technology and = Architecture Planning
> > >
> > > 908 234 8462
> > > mlazer@att.com
> > >
> > >
> > >  -----Original = Message-----
> > > From:     Dimitri = Papadimitriou
> > [mailto:dimitri.papadimi= triou@alcatel.be]
> > 
> > > Sent:     Monday, = October 22, 2001 3:15 PM
> > > = To:       Lazer, Monica A, NNAD
> > > = Cc:       Ewart Tempest; = lberger@movaz.com; ccamp@ops.ietf.org
> > > Subject:  Re: Generalized = Signaling - LSP Encoding Type expansion
> > >
> > >  << File: Card for Dimitri = Papadimitriou >> Hi Monica,
> > >
> > > Fine. Now we know the following: = GMPLS is really attractive for
> > > carriers when it supports all = transport technologies so it has
> > > to support Fiber Channel as = well.
> > >
> > > I wasn't aware that Ewart was capable = to read in your mind ;-)
> > >
> > > Regards,
> > > Dimitri.
> > >
> > > "Lazer, Monica A, NNAD" = wrote:
> > > >
> > > > Dimitri,
> > > > I am just answering the PS = question with this message.
> > > > The short answer is yes.  = The long answer is that the GMPLS control
> > plane
> > > is
> > > > really useful if it can support = connection management for all the
> > > transport
> > > > services supported by the = transport network using GMPLS. Therefore,
> > the
> > > > carrier services section for the = NNI document to be posted on the OIF
> > site
> > > > within a few minutes and the = next draft of the carrier requirements
> > IETF
> > > > draft will both contain = references to support of Fiber Channel.
> > > > Regards,
> > > > Monica A. Lazer
> > > > Advanced Transport Technology = and Architecture Planning
> > > >
> > > > 908 234 8462
> > > > mlazer@att.com
> > > >
> > > >  -----Original = Message-----
> > > > From:   Dimitri = Papadimitriou
> > [mailto:dimitri.papadimi= triou@alcatel.be]
> > > > Sent:   Monday, = October 22, 2001 2:47 PM
> > > > To:     = Ewart Tempest
> > > > Cc:     = lberger@movaz.com; ccamp@ops.ietf.org
> > > > = Subject:        Re: Generalized = Signaling - LSP Encoding Type
> > expansion
> > > >
> > > >  << File: Card for = Dimitri Papadimitriou >> Hi Ewart,
> > > >
> > > > If you take a look on the IEEE = Standards you will see
> > > > that GE is referred to as
> > > > - 802.3z for 1Gbps (see below = [1]) same exists for copper 802.3ab
> > > > - 802.3ae for 10Gbps (see below = [2])
> > > >
> > > > So my question is what do you = have in mind ? to separate
> > > > these values ?
> > > >
> > > > Thanks,
> > > > Dimitri.
> > > >
> > > > PS: for FiberChannel sorry i am = not an expert but is someone
> > > >     = targeting to use GMPLS for FiberChannel LSP ?
> > > >
> > > > -------
> > > >
> > > > [1] From - http://standards.ieee.org
> > > >
> > > > Project scope: Define Carrier = Sense Multiple Access with Collision
> > > > Detection (CSMA/CD) Media Access = Control (MAC) parameters and minimal
> > > > augmentation of its operation, = physical layer characteristics,
> > repeater
> > > > functions and management = parameters for transfer of 802.3 and Ethernet
> > > > format frames at 1,000 = Mb/s.
> > > >
> > > > Project purpose: The purpose of = this project is to extend the 802.3
> > > > protocol to an operating speed = of 1,000 Mb/s in order to provide a
> > > > significant increase in = bandwidth while maintaining maximum
> > > > compatibility
> > > > with the installed base of = CSMA/CD nodes, previous investment in
> > > > research
> > > > and development, and principles = of network operation and management.
> > > >
> > > > [2] From - http://standards.ieee.org
> > > >
> > > > Project scope: Define 802.3 = Media Access Control (MAC) parameters and
> > > > minimal augmentation of its = operation, physical layer characteristics
> > > > and management parameters for = transfer of LLC and Ethernet format
> > > > frames at 10 Gb/s using full = duplex operation as defined in the 802.3
> > > > standard. In addition to the = traditional LAN space, add parameters and
> > > > mechanisms that enable = deployment of Ethernet over the Wide Area
> > Network
> > > > operating at a data rate = compatible with OC-192c and SDH VC-4-64c
> > > > payload
> > > > rate.
> > > >
> > > > Project purpose: The purpose of = this project is to extend the 802.3
> > > > protocol to an operating speed = of 10 Gb/s and to expand the Ethernet
> > > > application space to include = Wide Area Network links in order to
> > provide
> > > > a significant increase in = bandwidth while maintaining maximum
> > > > compatibility
> > > > with the installed base of 802.3 = interfaces, previous investment in
> > > > research
> > > > and development, and principles = of network operation and management.
> > > >
> > > > -------
> > > >
> > > > > Ewart Tempest wrote:
> > > > >
> > > > > Lou,
> > > > >
> > > > > Within section 3.1.1 of = draft-ietf-mpls-generalized-signaling-06 can
> > > > > you please add additonal = LSP Encoding Types for GE and FiberChannel.
> > > > > GE is not really covered by = the existing Ethernet related encoding
> > > > > types, and FiberChannel is = not covered at all. Thanks.
> > > > >
> > > > > Ewart
> > >
>
> = ------_=3D_NextPart_001_01C15BCA.5A2A5650
> Content-Type: text/html;
>       = charset=3D"iso-8859-1"
> Content-Transfer-Encoding: = quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML = 3.2//EN">
> <HTML>
> <HEAD>
> <META = HTTP-EQUIV=3D3D"Content-Type" CONTENT=3D3D"text/html; = =3D
> charset=3D3Diso-8859-1">
> <META NAME=3D3D"Generator" = CONTENT=3D3D"MS Exchange Server version =3D
> 5.5.2654.19">
> <TITLE>RE: Generalized Signaling - LSP = Encoding Type expansion </TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT = SIZE=3D3D2>All,</FONT>
> <BR><FONT SIZE=3D3D2>I am in full = agreement with Shehzad. From a =3D
> carrier's perspective, the value of the control = plane is in taking over =3D
> specific functions which currently reside in = OSSs outside of the =3D
> network itself. Having only some applications, = but not others of the =3D
> given function move into the network greatly = diminishes the value of =3D
> having that function supported in the control = plane. To be more =3D
> specific, if out of n services supported by the = transport network, the =3D
> control plane supports automated = provisioning&nbsp; of 1/2n services =3D
and the other 1/2n need support in the OSS, we still = need to do the OSS =3D
> work for the given transport technology. So = from a cost perspective, =3D
> now we have to ask ourselves whether we should = pay for the provisioning =3D
> function twice.</FONT></P>
>
> <P><FONT = SIZE=3D3D2>Regards,</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>Monica A. = Lazer</FONT>
> <BR><FONT SIZE=3D3D2>Advanced = Transport Technology and Architecture =3D
> Planning</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>908 234 = 8462</FONT>
> <BR><FONT = SIZE=3D3D2>mlazer@att.com</FONT>
> </P>
> <BR>
>
> <P><FONT = SIZE=3D3D2>&nbsp;-----Original Message-----</FONT>
> <BR><FONT SIZE=3D3D2>From: = &nbsp; shehzad.mirza@bt.com [<A =3D
> HREF=3D3D"mailto:shehzad.mirza@bt.com&quo= t;>mailto:shehzad.mirza@bt.com<= /A>] =3D
> </FONT>
> <BR><FONT = SIZE=3D3D2>Sent:&nbsp;&nbsp; Tuesday, October 23, 2001 6:25 = =3D
> AM</FONT>
> <BR><FONT = SIZE=3D3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; = yakov@juniper.net</FONT>
> <BR><FONT = SIZE=3D3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Lazer, Monica = A, NNAD; =3D
> ccamp@ops.ietf.org</FONT>
> <BR><FONT = SIZE=3D3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp; =3D
> RE: Generalized Signaling - LSP Encoding Type = expansion </FONT>
> </P>
>
> <P><FONT = SIZE=3D3D2>Yakov,</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>See comments = in-line</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>&gt; = -----Original Message-----</FONT>
> <BR><FONT SIZE=3D3D2>&gt; From: = Yakov Rekhter =3D
> [SMTP:yakov@juniper.net]</FONT>
> <BR><FONT SIZE=3D3D2>&gt; Sent: = 22 October 2001 21:12</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = To:&nbsp;&nbsp; Lazer, Monica A, NNAD</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = Cc:&nbsp;&nbsp; ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: = =3D
> Generalized Signaling - LSP Encoding Type = expansion </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = Monica,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Dimitri,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Actually, it may be more accurate to put =3D
> it differently - if GMPLS</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = supports</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; only a handful of the services running on =3D
> a given transport network,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = than</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; its value as a network's control plane =3D
> component is diminished. </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; To be = even more accurate, GMPLS value is =3D
> diminished *in the context*</FONT>
> <BR><FONT SIZE=3D3D2>&gt; of = that particular transport network. And =3D
> unless *all* providers</FONT>
> <BR><FONT SIZE=3D3D2>&gt; are = going to run *all possible services* on =3D
> their transport networks</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = (which is a somewhat unrealistic scenario), =3D
> that means that the</FONT>
> <BR><FONT SIZE=3D3D2>&gt; value = of GMPLS as a network's control plane =3D
> component would be</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = diminished for *some*, but not *all* service =3D
> providers.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> = <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a= mp;nbsp; <FONT =3D
> SIZE=3D3D2>[shehzad]&nbsp; = </FONT>
> <BR><FONT SIZE=3D3D2>For a control = plane not to support all the transport =3D
> services capable of</FONT>
> <BR><FONT SIZE=3D3D2>being carried = over an operator's network diminishes =3D
> the value of that</FONT>
> <BR><FONT SIZE=3D3D2>particular = control plane.&nbsp; What is the point of =3D
> having transparent/optical</FONT>
> <BR><FONT SIZE=3D3D2>equipment = capable of transporting both Gigabit =3D
> Ethernet and Fiber Channel</FONT>
> <BR><FONT SIZE=3D3D2>(as an = example), if provisioning was based on =3D
> signalling that could only</FONT>
> <BR><FONT SIZE=3D3D2>support = Gigabit Ethernet?</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>This is a = restriction for every provider regardless =3D
> of whether a network is</FONT>
> <BR><FONT SIZE=3D3D2>a standalone = one built for a large customer or a =3D
> national network serving</FONT>
> <BR><FONT SIZE=3D3D2>multiple = customers. The effective 'banning' of =3D
> certain services that are</FONT>
> <BR><FONT SIZE=3D3D2>currently = being offered by providers will =3D
> unnecessarily damage the = business</FONT>
> <BR><FONT SIZE=3D3D2>case for the = adoption of GMPLS.</FONT>
> </P>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D3D2>&gt; At the = same time, it is important to keep in =3D
> mind that being = &quot;all</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = things for all people&quot; (aka as =3D
> &quot;perfect solution&quot;) is one of = the</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = *non-goals* of GMPLS. So, it shouldn't come as =3D
> a surprise if for a</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = *particular* provider GMPLS would *not* support =3D
> *all* the services</FONT>
> <BR><FONT SIZE=3D3D2>&gt; that = this provider runs on its transport =3D
> network.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = Yakov.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = </FONT>
> = <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a= mp;nbsp; <FONT =3D
> SIZE=3D3D2>[Shehzad]</FONT>
> = <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a= mp;nbsp; <FONT SIZE=3D3D2>There is =3D
> no technical reason why a GMPLS encoding type = could not be</FONT>
> <BR><FONT SIZE=3D3D2>adopted for a = recognised format such as Fiber =3D
> Channel, as far as I am = aware</FONT>
> <BR><FONT SIZE=3D3D2>the adoption = of Fiber Channel is not likely to =3D
> destroy the foundations of</FONT>
> <BR><FONT = SIZE=3D3D2>GMPLS.</FONT>
> </P>
>
> = <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&am= p;nbsp; <FONT SIZE=3D3D2>On a more =3D
> general point, is the support of transport = technologies</FONT>
> <BR><FONT SIZE=3D3D2>within GMPLS = signalling restricted to those that the =3D
> authors of the GMPLS</FONT>
> <BR><FONT SIZE=3D3D2>drafts will = allow? </FONT>
> = <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a= mp;nbsp;&nbsp;<FONT SIZE=3D3D2> =3D
> </FONT>
> </P>
> <BR>
> <BR>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D3D2>&gt; = &gt; Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Advanced Transport Technology and =3D
> Architecture Planning</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; 908 234 8462</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; mlazer@att.com</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt;&nbsp; -----Original Message-----</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; From: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = =3D
> Dimitri Papadimitriou</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = [<A =3D
> HREF=3D3D"mailto:dimitri.papadimi= triou@alcatel.be">mailto:dimitri.papadimi=3D
> triou@alcatel.be</A>]</FONT>
> <BR><FONT = SIZE=3D3D2>&gt;&nbsp; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; = Sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = =3D
> Monday, October 22, 2001 3:15 = PM</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; To: Lazer, Monica A, NNAD</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Cc: Ewart Tempest; lberger@movaz.com; =3D
> ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Subject:&nbsp;&nbsp;&nbsp; Re: Generalized = =3D
> Signaling - LSP Encoding Type = expansion</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt;&nbsp; &lt;&lt; File: Card for Dimitri =3D
> Papadimitriou &gt;&gt; Hi = Monica,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Fine. Now we know the following: GMPLS is =3D
> really attractive for </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; carriers when it supports all transport =3D
> technologies so it has </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; to support Fiber Channel as well.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; I wasn't aware that Ewart was capable to =3D
> read in your mind ;-)</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Regards,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; Dimitri.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &quot;Lazer, Monica A, NNAD&quot; =3D
> wrote:</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Dimitri,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; I am just answering the PS question =3D
> with this message.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; The short answer is yes.&nbsp; The =3D
> long answer is that the GMPLS = control</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = plane</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; is</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; really useful if it can support =3D
> connection management for all = the</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; transport</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; services supported by the transport =3D
> network using GMPLS. = Therefore,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = the</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; carrier services section for the NNI =3D
> document to be posted on the = OIF</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = site</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; within a few minutes and the next =3D
> draft of the carrier = requirements</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = IETF</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; draft will both contain references to =3D
> support of Fiber Channel.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Regards,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Advanced Transport Technology and =3D
> Architecture Planning</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; 908 234 8462</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; mlazer@att.com</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt;&nbsp; -----Original =3D
> Message-----</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; From:&nbsp;&nbsp; Dimitri =3D
> Papadimitriou</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = [<A =3D
> HREF=3D3D"mailto:dimitri.papadimi= triou@alcatel.be">mailto:dimitri.papadimi=3D
> triou@alcatel.be</A>]</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Sent:&nbsp;&nbsp; Monday, October 22, = =3D
> 2001 2:47 PM</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; To:&nbsp;&nbsp;&nbsp;&nbsp; Ewart = =3D
> Tempest</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Cc:&nbsp;&nbsp;&nbsp;&nbsp; = =3D
> lberger@movaz.com; = ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; =3D
> = Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp; Re: Generalized =3D
> Signaling - LSP Encoding = Type</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = expansion</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt;&nbsp; &lt;&lt; File: Card for Dimitri = =3D
> Papadimitriou &gt;&gt; Hi = Ewart,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; If you take a look on the IEEE =3D
> Standards you will see</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; that GE is referred to as</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; - 802.3z for 1Gbps (see below [1]) =3D
> same exists for copper = 802.3ab</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; - 802.3ae for 10Gbps (see below =3D
> [2])</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; So my question is what do you have in =3D
> mind ? to separate</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; these values ?</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Thanks,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Dimitri.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; PS: for FiberChannel sorry i am not =3D
> an expert but is someone</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; targeting to = =3D
> use GMPLS for FiberChannel LSP = ?</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; -------</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; [1] From - <A =3D
> HREF=3D3D"http://standards.ieee.org" =3D
> TARGET=3D3D"_blank">http://standards.ieee.org</A></FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Project scope: Define Carrier Sense =3D
> Multiple Access with = Collision</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Detection (CSMA/CD) Media Access =3D
> Control (MAC) parameters and = minimal</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; augmentation of its operation, =3D
> physical layer = characteristics,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = repeater</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; functions and management parameters =3D
> for transfer of 802.3 and = Ethernet</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; format frames at 1,000 Mb/s.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Project purpose: The purpose of this =3D
> project is to extend the = 802.3</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; protocol to an operating speed of =3D
> 1,000 Mb/s in order to provide = a</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; significant increase in bandwidth =3D
> while maintaining maximum</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; compatibility</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; with the installed base of CSMA/CD =3D
> nodes, previous investment = in</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; research</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; and development, and principles of =3D
> network operation and = management.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; [2] From - <A =3D
> HREF=3D3D"http://standards.ieee.org" =3D
> TARGET=3D3D"_blank">http://standards.ieee.org</A></FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Project scope: Define 802.3 Media =3D
> Access Control (MAC) parameters = and</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; minimal augmentation of its =3D
> operation, physical layer = characteristics</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; and management parameters for =3D
> transfer of LLC and Ethernet = format</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; frames at 10 Gb/s using full duplex =3D
> operation as defined in the = 802.3</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; standard. In addition to the =3D
> traditional LAN space, add parameters = and</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; mechanisms that enable deployment of =3D
> Ethernet over the Wide Area</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = Network</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; operating at a data rate compatible =3D
> with OC-192c and SDH = VC-4-64c</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; payload</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; rate.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; Project purpose: The purpose of this =3D
> project is to extend the = 802.3</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; protocol to an operating speed of 10 =3D
> Gb/s and to expand the = Ethernet</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; application space to include Wide =3D
> Area Network links in order = to</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = provide</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; a significant increase in bandwidth =3D
> while maintaining maximum</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; compatibility</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; with the installed base of 802.3 =3D
> interfaces, previous investment = in</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; research</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; and development, and principles of =3D
> network operation and = management.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; -------</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; </FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; Ewart Tempest wrote:</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; Lou,</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; Within section 3.1.1 of =3D
> draft-ietf-mpls-generalized-signaling-06 = can</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; you please add additonal LSP =3D
> Encoding Types for GE and = FiberChannel.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; GE is not really covered by the =3D
> existing Ethernet related = encoding</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; types, and FiberChannel is not =3D
> covered at all. Thanks.</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt;</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; &gt; &gt; Ewart</FONT>
> <BR><FONT SIZE=3D3D2>&gt; = &gt; </FONT>
> </P>
>
> </BODY>
> </HTML>
> = ------_=3D_NextPart_001_01C15BCA.5A2A5650--

------_=_NextPart_001_01C15BDA.57D4DA50-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 09:02:36 -0700 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A94092DDF73@mbtlipnt01.btlabs.bt.co.uk> From: shehzad.mirza@bt.com To: yakov@juniper.net Cc: ccamp@ops.ietf.org, mlazer@att.com Subject: RE: Generalized Signalling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 16:45:58 +0100 MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Yakov, The percentage of carriers that have all of their requirements met by the current GMPLS drafts is an unknown. However the following points still need to be addressed. 1. Why would an operator adopt GMPLS infrastructure if it only carried a subset of the transport services that they are already offer to customers? In effect spending more and getting less. 2. Why is there a problem reserving a code-point for a service that some vendors may wish to implement on their GMPLS equipment? Presumably they would not implement capability for which there is no demand. 3. What is the process by which certain transport services are decided suitable for inclusion into the GMPLS specifications/drafts? It seems that inclusion of additional services fraught with difficulties, this is likely to get worse when the drafts turn into specifications. Shehzad > -----Original Message----- > From: Yakov Rekhter [SMTP:yakov@juniper.net] > Sent: 23 October 2001 16:17 > To: Lazer, Monica A, NNAD > Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > Monica, > > > All, > > I am in full agreement with Shehzad. From a carrier's perspective, the > value > > of the control plane is in taking over specific functions which > currently > > reside in OSSs outside of the network itself. Having only some > applications, > > but not others of the given function move into the network greatly > > diminishes the value of having that function supported in the control > plane. > > To be more specific, if out of n services supported by the transport > > network, the control plane supports automated provisioning of 1/2n > services > > and the other 1/2n need support in the OSS, we still need to do the OSS > work > > for the given transport technology. So from a cost perspective, now we > have > > to ask ourselves whether we should pay for the provisioning function > twice. > > While what you said makes sense from a given carrier's perspective, > we need to take a broader view, as producing a "perfect solution" > that meets *all* the requirements of *all* the carriers is an > explicit non-goal of GMPLS. With this in mind, if the 1/2n services > that aren't supported by the control plane are the services that > are required by 90% of the carriers market, then indeed this is a > problem. On the other hand, if these 1/2n services that aren't > supported are the services required by only 10% of the carriers > market, then this is quite acceptable. Understandably, the carriers > who would fall into this 10% category could be quite unhappy about, > and could even be quite vocal in expressing their dissatisfaction... > > Yakov. > > > Regards, > > > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > > > -----Original Message----- > > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] > > Sent: Tuesday, October 23, 2001 6:25 AM > > To: yakov@juniper.net > > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > > Subject: RE: Generalized Signaling - LSP Encoding Type expansion > > > > Yakov, > > > > See comments in-line > > > > > -----Original Message----- > > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > > Sent: 22 October 2001 21:12 > > > To: Lazer, Monica A, NNAD > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > Monica, > > > > > > > Dimitri, > > > > Actually, it may be more accurate to put it differently - if GMPLS > > > supports > > > > only a handful of the services running on a given transport network, > > > than > > > > its value as a network's control plane component is diminished. > > > > > > To be even more accurate, GMPLS value is diminished *in the context* > > > of that particular transport network. And unless *all* providers > > > are going to run *all possible services* on their transport networks > > > (which is a somewhat unrealistic scenario), that means that the > > > value of GMPLS as a network's control plane component would be > > > diminished for *some*, but not *all* service providers. > > > > > > > > > > > [shehzad] > > For a control plane not to support all the transport services capable of > > being carried over an operator's network diminishes the value of that > > particular control plane. What is the point of having > transparent/optical > > equipment capable of transporting both Gigabit Ethernet and Fiber > Channel > > (as an example), if provisioning was based on signalling that could only > > support Gigabit Ethernet? > > > > This is a restriction for every provider regardless of whether a network > is > > a standalone one built for a large customer or a national network > serving > > multiple customers. The effective 'banning' of certain services that are > > currently being offered by providers will unnecessarily damage the > business > > case for the adoption of GMPLS. > > > > > > > > > At the same time, it is important to keep in mind that being "all > > > things for all people" (aka as "perfect solution") is one of the > > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > > *particular* provider GMPLS would *not* support *all* the services > > > that this provider runs on its transport network. > > > > > > Yakov. > > > > > > > > [Shehzad] > > There is no technical reason why a GMPLS encoding type could not be > > adopted for a recognised format such as Fiber Channel, as far as I am > aware > > the adoption of Fiber Channel is not likely to destroy the foundations > of > > GMPLS. > > > > On a more general point, is the support of transport technologies > > within GMPLS signalling restricted to those that the authors of the > GMPLS > > drafts will allow? > > > > > > > > > > > > > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > > > > > -----Original Message----- > > > > From: Dimitri Papadimitriou > > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > > > Sent: Monday, October 22, 2001 3:15 PM > > > > To: Lazer, Monica A, NNAD > > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > expansion > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > > > > > Fine. Now we know the following: GMPLS is really attractive for > > > > carriers when it supports all transport technologies so it has > > > > to support Fiber Channel as well. > > > > > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > > > > > Regards, > > > > Dimitri. > > > > > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > > > > > Dimitri, > > > > > I am just answering the PS question with this message. > > > > > The short answer is yes. The long answer is that the GMPLS > control > > > plane > > > > is > > > > > really useful if it can support connection management for all the > > > > transport > > > > > services supported by the transport network using GMPLS. > Therefore, > > > the > > > > > carrier services section for the NNI document to be posted on the > OIF > > > site > > > > > within a few minutes and the next draft of the carrier > requirements > > > IETF > > > > > draft will both contain references to support of Fiber Channel. > > > > > Regards, > > > > > Monica A. Lazer > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > 908 234 8462 > > > > > mlazer@att.com > > > > > > > > > > -----Original Message----- > > > > > From: Dimitri Papadimitriou > > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > > To: Ewart Tempest > > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > > expansion > > > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > > > > > If you take a look on the IEEE Standards you will see > > > > > that GE is referred to as > > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > > > > > So my question is what do you have in mind ? to separate > > > > > these values ? > > > > > > > > > > Thanks, > > > > > Dimitri. > > > > > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > > > > > ------- > > > > > > > > > > [1] From - http://standards.ieee.org > > > > > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and > minimal > > > > > augmentation of its operation, physical layer characteristics, > > > repeater > > > > > functions and management parameters for transfer of 802.3 and > Ethernet > > > > > format frames at 1,000 Mb/s. > > > > > > > > > > Project purpose: The purpose of this project is to extend the > 802.3 > > > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > > > significant increase in bandwidth while maintaining maximum > > > > > compatibility > > > > > with the installed base of CSMA/CD nodes, previous investment in > > > > > research > > > > > and development, and principles of network operation and > management. > > > > > > > > > > [2] From - http://standards.ieee.org > > > > > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters > and > > > > > minimal augmentation of its operation, physical layer > characteristics > > > > > and management parameters for transfer of LLC and Ethernet format > > > > > frames at 10 Gb/s using full duplex operation as defined in the > 802.3 > > > > > standard. In addition to the traditional LAN space, add parameters > and > > > > > mechanisms that enable deployment of Ethernet over the Wide Area > > > Network > > > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > > > payload > > > > > rate. > > > > > > > > > > Project purpose: The purpose of this project is to extend the > 802.3 > > > > > protocol to an operating speed of 10 Gb/s and to expand the > Ethernet > > > > > application space to include Wide Area Network links in order to > > > provide > > > > > a significant increase in bandwidth while maintaining maximum > > > > > compatibility > > > > > with the installed base of 802.3 interfaces, previous investment > in > > > > > research > > > > > and development, and principles of network operation and > management. > > > > > > > > > > ------- > > > > > > > > > > > Ewart Tempest wrote: > > > > > > > > > > > > Lou, > > > > > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 > can > > > > > > you please add additonal LSP Encoding Types for GE and > FiberChannel. > > > > > > GE is not really covered by the existing Ethernet related > encoding > > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > > > Ewart > > > > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > charset=3Diso-8859-1"> > > > 5.5.2654.19"> > > RE: Generalized Signaling - LSP Encoding Type expansion > > > > > > > >

All, > >
I am in full agreement with Shehzad. From a = > > carrier's perspective, the value of the control plane is in taking over > = > > specific functions which currently reside in OSSs outside of the = > > network itself. Having only some applications, but not others of the = > > given function move into the network greatly diminishes the value of = > > having that function supported in the control plane. To be more = > > specific, if out of n services supported by the transport network, the = > > control plane supports automated provisioning  of 1/2n services = > and the other 1/2n need support in the OSS, we still need to do the OSS = > > work for the given transport technology. So from a cost perspective, = > > now we have to ask ourselves whether we should pay for the provisioning > = > > function twice.

> > > >

Regards, > >

> > > >

Monica A. Lazer > >
Advanced Transport Technology and Architecture = > > Planning > >

> > > >

908 234 8462 > >
mlazer@att.com > >

> >
> > > >

 -----Original Message----- > >
From:   shehzad.mirza@bt.com [ > HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = > > > >
Sent:   Tuesday, October 23, 2001 6:25 = > > AM > >
To:     yakov@juniper.net > >
Cc:     Lazer, Monica A, NNAD; = > > ccamp@ops.ietf.org > >
Subject:        = > > RE: Generalized Signaling - LSP Encoding Type expansion > >

> > > >

Yakov, > >

> > > >

See comments in-line > >

> > > >

> -----Original Message----- > >
> From: Yakov Rekhter = > > [SMTP:yakov@juniper.net] > >
> Sent: 22 October 2001 21:12 > >
> To:   Lazer, Monica A, NNAD > >
> Cc:   ccamp@ops.ietf.org > >
> Subject:      Re: = > > Generalized Signaling - LSP Encoding Type expansion > >
> > >
> Monica, > >
> > >
> > Dimitri, > >
> > Actually, it may be more accurate to put = > > it differently - if GMPLS > >
> supports > >
> > only a handful of the services running on = > > a given transport network, > >
> than > >
> > its value as a network's control plane = > > component is diminished. > >
> > >
> To be even more accurate, GMPLS value is = > > diminished *in the context* > >
> of that particular transport network. And = > > unless *all* providers > >
> are going to run *all possible services* on = > > their transport networks > >
> (which is a somewhat unrealistic scenario), = > > that means that the > >
> value of GMPLS as a network's control plane = > > component would be > >
> diminished for *some*, but not *all* service = > > providers. > >
> > >
> > >
> > >
        > SIZE=3D2>[shehzad]  > >
For a control plane not to support all the transport > = > > services capable of > >
being carried over an operator's network diminishes = > > the value of that > >
particular control plane.  What is the point of > = > > having transparent/optical > >
equipment capable of transporting both Gigabit = > > Ethernet and Fiber Channel > >
(as an example), if provisioning was based on = > > signalling that could only > >
support Gigabit Ethernet? > >

> > > >

This is a restriction for every provider regardless = > > of whether a network is > >
a standalone one built for a large customer or a = > > national network serving > >
multiple customers. The effective 'banning' of = > > certain services that are > >
currently being offered by providers will = > > unnecessarily damage the business > >
case for the adoption of GMPLS. > >

> >
> >
> > > >

> At the same time, it is important to keep in = > > mind that being "all > >
> things for all people" (aka as = > > "perfect solution") is one of the > >
> *non-goals* of GMPLS. So, it shouldn't come as = > > a surprise if for a > >
> *particular* provider GMPLS would *not* support > = > > *all* the services > >
> that this provider runs on its transport = > > network. > >
> > >
> Yakov. > >
> > >
> > >
        > SIZE=3D2>[Shehzad] > >
        There is = > > no technical reason why a GMPLS encoding type could not be > >
adopted for a recognised format such as Fiber = > > Channel, as far as I am aware > >
the adoption of Fiber Channel is not likely to = > > destroy the foundations of > >
GMPLS. > >

> > > >

        On a more = > > general point, is the support of transport technologies > >
within GMPLS signalling restricted to those that the > = > > authors of the GMPLS > >
drafts will allow? > >
         = > > > >

> >
> >
> >
> >
> > > >

> > Monica A. Lazer > >
> > Advanced Transport Technology and = > > Architecture Planning > >
> > > >
> > 908 234 8462 > >
> > mlazer@att.com > >
> > > >
> > > >
> >  -----Original Message----- > >
> > From:       = > > Dimitri Papadimitriou > >
> [ > > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > > triou@alcatel.be] > >
>  > >
> > Sent:       = > > Monday, October 22, 2001 3:15 PM > >
> > To: Lazer, Monica A, NNAD > >
> > Cc: Ewart Tempest; lberger@movaz.com; = > > ccamp@ops.ietf.org > >
> > Subject:    Re: Generalized > = > > Signaling - LSP Encoding Type expansion > >
> > > >
> >  << File: Card for Dimitri = > > Papadimitriou >> Hi Monica, > >
> > > >
> > Fine. Now we know the following: GMPLS is = > > really attractive for > >
> > carriers when it supports all transport = > > technologies so it has > >
> > to support Fiber Channel as well. > >
> > > >
> > I wasn't aware that Ewart was capable to = > > read in your mind ;-) > >
> > > >
> > Regards, > >
> > Dimitri. > >
> > > >
> > "Lazer, Monica A, NNAD" = > > wrote: > >
> > > > >
> > > Dimitri, > >
> > > I am just answering the PS question = > > with this message. > >
> > > The short answer is yes.  The = > > long answer is that the GMPLS control > >
> plane > >
> > is > >
> > > really useful if it can support = > > connection management for all the > >
> > transport > >
> > > services supported by the transport = > > network using GMPLS. Therefore, > >
> the > >
> > > carrier services section for the NNI = > > document to be posted on the OIF > >
> site > >
> > > within a few minutes and the next = > > draft of the carrier requirements > >
> IETF > >
> > > draft will both contain references to > = > > support of Fiber Channel. > >
> > > Regards, > >
> > > Monica A. Lazer > >
> > > Advanced Transport Technology and = > > Architecture Planning > >
> > > > >
> > > 908 234 8462 > >
> > > mlazer@att.com > >
> > > > >
> > >  -----Original = > > Message----- > >
> > > From:   Dimitri = > > Papadimitriou > >
> [ > > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > > triou@alcatel.be] > >
> > > Sent:   Monday, October 22, > = > > 2001 2:47 PM > >
> > > To:     Ewart = > > Tempest > >
> > > Cc:     = > > lberger@movaz.com; ccamp@ops.ietf.org > >
> > > = > > Subject:        Re: Generalized = > > Signaling - LSP Encoding Type > >
> expansion > >
> > > > >
> > >  << File: Card for Dimitri > = > > Papadimitriou >> Hi Ewart, > >
> > > > >
> > > If you take a look on the IEEE = > > Standards you will see > >
> > > that GE is referred to as > >
> > > - 802.3z for 1Gbps (see below [1]) = > > same exists for copper 802.3ab > >
> > > - 802.3ae for 10Gbps (see below = > > [2]) > >
> > > > >
> > > So my question is what do you have in > = > > mind ? to separate > >
> > > these values ? > >
> > > > >
> > > Thanks, > >
> > > Dimitri. > >
> > > > >
> > > PS: for FiberChannel sorry i am not = > > an expert but is someone > >
> > >     targeting to = > > use GMPLS for FiberChannel LSP ? > >
> > > > >
> > > ------- > >
> > > > >
> > > [1] From - > HREF=3D"http://standards.ieee.org" = > > TARGET=3D"_blank">http://standards.ieee.org > >
> > > > >
> > > Project scope: Define Carrier Sense = > > Multiple Access with Collision > >
> > > Detection (CSMA/CD) Media Access = > > Control (MAC) parameters and minimal > >
> > > augmentation of its operation, = > > physical layer characteristics, > >
> repeater > >
> > > functions and management parameters = > > for transfer of 802.3 and Ethernet > >
> > > format frames at 1,000 Mb/s. > >
> > > > >
> > > Project purpose: The purpose of this = > > project is to extend the 802.3 > >
> > > protocol to an operating speed of = > > 1,000 Mb/s in order to provide a > >
> > > significant increase in bandwidth = > > while maintaining maximum > >
> > > compatibility > >
> > > with the installed base of CSMA/CD = > > nodes, previous investment in > >
> > > research > >
> > > and development, and principles of = > > network operation and management. > >
> > > > >
> > > [2] From - > HREF=3D"http://standards.ieee.org" = > > TARGET=3D"_blank">http://standards.ieee.org > >
> > > > >
> > > Project scope: Define 802.3 Media = > > Access Control (MAC) parameters and > >
> > > minimal augmentation of its = > > operation, physical layer characteristics > >
> > > and management parameters for = > > transfer of LLC and Ethernet format > >
> > > frames at 10 Gb/s using full duplex = > > operation as defined in the 802.3 > >
> > > standard. In addition to the = > > traditional LAN space, add parameters and > >
> > > mechanisms that enable deployment of = > > Ethernet over the Wide Area > >
> Network > >
> > > operating at a data rate compatible = > > with OC-192c and SDH VC-4-64c > >
> > > payload > >
> > > rate. > >
> > > > >
> > > Project purpose: The purpose of this = > > project is to extend the 802.3 > >
> > > protocol to an operating speed of 10 = > > Gb/s and to expand the Ethernet > >
> > > application space to include Wide = > > Area Network links in order to > >
> provide > >
> > > a significant increase in bandwidth = > > while maintaining maximum > >
> > > compatibility > >
> > > with the installed base of 802.3 = > > interfaces, previous investment in > >
> > > research > >
> > > and development, and principles of = > > network operation and management. > >
> > > > >
> > > ------- > >
> > > > >
> > > > Ewart Tempest wrote: > >
> > > > > >
> > > > Lou, > >
> > > > > >
> > > > Within section 3.1.1 of = > > draft-ietf-mpls-generalized-signaling-06 can > >
> > > > you please add additonal LSP = > > Encoding Types for GE and FiberChannel. > >
> > > > GE is not really covered by the = > > existing Ethernet related encoding > >
> > > > types, and FiberChannel is not = > > covered at all. Thanks. > >
> > > > > >
> > > > Ewart > >
> > > >

> > > > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 08:56:57 -0700 Message-ID: From: John Drake To: 'Yakov Rekhter' , "Lazer, Monica A, NNAD" Cc: "'shehzad.mirza@bt.com'" , ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 08:41:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I think it's the case that if we'e dealing with end-end services across a GMPLS core, the types of end-end services that could be supported is fairly open without having to upgrade the GMPLS core, and without having to require every vendor implementing GMPLS to support every conceivable type of end-end service. I.e., you could deploy a GMPLS network with core switches from vendor 1, SONET/SDH grooming service devices from vendor 2, IP router service devicess from vendor 3, ATM service devices from vendor 3, transparent LAN service devices from vendor 4, private line service devices from vendor 5, etc -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Tuesday, October 23, 2001 8:17 AM To: Lazer, Monica A, NNAD Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Monica, > All, > I am in full agreement with Shehzad. From a carrier's perspective, the value > of the control plane is in taking over specific functions which currently > reside in OSSs outside of the network itself. Having only some applications, > but not others of the given function move into the network greatly > diminishes the value of having that function supported in the control plane. > To be more specific, if out of n services supported by the transport > network, the control plane supports automated provisioning of 1/2n services > and the other 1/2n need support in the OSS, we still need to do the OSS work > for the given transport technology. So from a cost perspective, now we have > to ask ourselves whether we should pay for the provisioning function twice. While what you said makes sense from a given carrier's perspective, we need to take a broader view, as producing a "perfect solution" that meets *all* the requirements of *all* the carriers is an explicit non-goal of GMPLS. With this in mind, if the 1/2n services that aren't supported by the control plane are the services that are required by 90% of the carriers market, then indeed this is a problem. On the other hand, if these 1/2n services that aren't supported are the services required by only 10% of the carriers market, then this is quite acceptable. Understandably, the carriers who would fall into this 10% category could be quite unhappy about, and could even be quite vocal in expressing their dissatisfaction... Yakov. > Regards, > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] > Sent: Tuesday, October 23, 2001 6:25 AM > To: yakov@juniper.net > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > Subject: RE: Generalized Signaling - LSP Encoding Type expansion > > Yakov, > > See comments in-line > > > -----Original Message----- > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > Sent: 22 October 2001 21:12 > > To: Lazer, Monica A, NNAD > > Cc: ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > Monica, > > > > > Dimitri, > > > Actually, it may be more accurate to put it differently - if GMPLS > > supports > > > only a handful of the services running on a given transport network, > > than > > > its value as a network's control plane component is diminished. > > > > To be even more accurate, GMPLS value is diminished *in the context* > > of that particular transport network. And unless *all* providers > > are going to run *all possible services* on their transport networks > > (which is a somewhat unrealistic scenario), that means that the > > value of GMPLS as a network's control plane component would be > > diminished for *some*, but not *all* service providers. > > > > > > > [shehzad] > For a control plane not to support all the transport services capable of > being carried over an operator's network diminishes the value of that > particular control plane. What is the point of having transparent/optical > equipment capable of transporting both Gigabit Ethernet and Fiber Channel > (as an example), if provisioning was based on signalling that could only > support Gigabit Ethernet? > > This is a restriction for every provider regardless of whether a network is > a standalone one built for a large customer or a national network serving > multiple customers. The effective 'banning' of certain services that are > currently being offered by providers will unnecessarily damage the business > case for the adoption of GMPLS. > > > > > At the same time, it is important to keep in mind that being "all > > things for all people" (aka as "perfect solution") is one of the > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > *particular* provider GMPLS would *not* support *all* the services > > that this provider runs on its transport network. > > > > Yakov. > > > > > [Shehzad] > There is no technical reason why a GMPLS encoding type could not be > adopted for a recognised format such as Fiber Channel, as far as I am aware > the adoption of Fiber Channel is not likely to destroy the foundations of > GMPLS. > > On a more general point, is the support of transport technologies > within GMPLS signalling restricted to those that the authors of the GMPLS > drafts will allow? > > > > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > Sent: Monday, October 22, 2001 3:15 PM > > > To: Lazer, Monica A, NNAD > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > > > Fine. Now we know the following: GMPLS is really attractive for > > > carriers when it supports all transport technologies so it has > > > to support Fiber Channel as well. > > > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > > > Regards, > > > Dimitri. > > > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > > > Dimitri, > > > > I am just answering the PS question with this message. > > > > The short answer is yes. The long answer is that the GMPLS control > > plane > > > is > > > > really useful if it can support connection management for all the > > > transport > > > > services supported by the transport network using GMPLS. Therefore, > > the > > > > carrier services section for the NNI document to be posted on the OIF > > site > > > > within a few minutes and the next draft of the carrier requirements > > IETF > > > > draft will both contain references to support of Fiber Channel. > > > > Regards, > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > -----Original Message----- > > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > To: Ewart Tempest > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > expansion > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > > > If you take a look on the IEEE Standards you will see > > > > that GE is referred to as > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > > > So my question is what do you have in mind ? to separate > > > > these values ? > > > > > > > > Thanks, > > > > Dimitri. > > > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > > > ------- > > > > > > > > [1] From - http://standards.ieee.org > > > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > > augmentation of its operation, physical layer characteristics, > > repeater > > > > functions and management parameters for transfer of 802.3 and Ethernet > > > > format frames at 1,000 Mb/s. > > > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > > significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of CSMA/CD nodes, previous investment in > > > > research > > > > and development, and principles of network operation and management. > > > > > > > > [2] From - http://standards.ieee.org > > > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > > minimal augmentation of its operation, physical layer characteristics > > > > and management parameters for transfer of LLC and Ethernet format > > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > > standard. In addition to the traditional LAN space, add parameters and > > > > mechanisms that enable deployment of Ethernet over the Wide Area > > Network > > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > > payload > > > > rate. > > > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > > application space to include Wide Area Network links in order to > > provide > > > > a significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of 802.3 interfaces, previous investment in > > > > research > > > > and development, and principles of network operation and management. > > > > > > > > ------- > > > > > > > > > Ewart Tempest wrote: > > > > > > > > > > Lou, > > > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > > GE is not really covered by the existing Ethernet related encoding > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > Ewart > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2654.19"> > RE: Generalized Signaling - LSP Encoding Type expansion > > > >

All, >
I am in full agreement with Shehzad. From a = > carrier's perspective, the value of the control plane is in taking over = > specific functions which currently reside in OSSs outside of the = > network itself. Having only some applications, but not others of the = > given function move into the network greatly diminishes the value of = > having that function supported in the control plane. To be more = > specific, if out of n services supported by the transport network, the = > control plane supports automated provisioning  of 1/2n services = and the other 1/2n need support in the OSS, we still need to do the OSS = > work for the given transport technology. So from a cost perspective, = > now we have to ask ourselves whether we should pay for the provisioning = > function twice.

> >

Regards, >

> >

Monica A. Lazer >
Advanced Transport Technology and Architecture = > Planning >

> >

908 234 8462 >
mlazer@att.com >

>
> >

 -----Original Message----- >
From:   shehzad.mirza@bt.com [ HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = > >
Sent:   Tuesday, October 23, 2001 6:25 = > AM >
To:     yakov@juniper.net >
Cc:     Lazer, Monica A, NNAD; = > ccamp@ops.ietf.org >
Subject:        = > RE: Generalized Signaling - LSP Encoding Type expansion >

> >

Yakov, >

> >

See comments in-line >

> >

> -----Original Message----- >
> From: Yakov Rekhter = > [SMTP:yakov@juniper.net] >
> Sent: 22 October 2001 21:12 >
> To:   Lazer, Monica A, NNAD >
> Cc:   ccamp@ops.ietf.org >
> Subject:      Re: = > Generalized Signaling - LSP Encoding Type expansion >
> >
> Monica, >
> >
> > Dimitri, >
> > Actually, it may be more accurate to put = > it differently - if GMPLS >
> supports >
> > only a handful of the services running on = > a given transport network, >
> than >
> > its value as a network's control plane = > component is diminished. >
> >
> To be even more accurate, GMPLS value is = > diminished *in the context* >
> of that particular transport network. And = > unless *all* providers >
> are going to run *all possible services* on = > their transport networks >
> (which is a somewhat unrealistic scenario), = > that means that the >
> value of GMPLS as a network's control plane = > component would be >
> diminished for *some*, but not *all* service = > providers. >
> >
> >
> >
        SIZE=3D2>[shehzad]  >
For a control plane not to support all the transport = > services capable of >
being carried over an operator's network diminishes = > the value of that >
particular control plane.  What is the point of = > having transparent/optical >
equipment capable of transporting both Gigabit = > Ethernet and Fiber Channel >
(as an example), if provisioning was based on = > signalling that could only >
support Gigabit Ethernet? >

> >

This is a restriction for every provider regardless = > of whether a network is >
a standalone one built for a large customer or a = > national network serving >
multiple customers. The effective 'banning' of = > certain services that are >
currently being offered by providers will = > unnecessarily damage the business >
case for the adoption of GMPLS. >

>
>
> >

> At the same time, it is important to keep in = > mind that being "all >
> things for all people" (aka as = > "perfect solution") is one of the >
> *non-goals* of GMPLS. So, it shouldn't come as = > a surprise if for a >
> *particular* provider GMPLS would *not* support = > *all* the services >
> that this provider runs on its transport = > network. >
> >
> Yakov. >
> >
> >
        SIZE=3D2>[Shehzad] >
        There is = > no technical reason why a GMPLS encoding type could not be >
adopted for a recognised format such as Fiber = > Channel, as far as I am aware >
the adoption of Fiber Channel is not likely to = > destroy the foundations of >
GMPLS. >

> >

        On a more = > general point, is the support of transport technologies >
within GMPLS signalling restricted to those that the = > authors of the GMPLS >
drafts will allow? >
         = > >

>
>
>
>
> >

> > Monica A. Lazer >
> > Advanced Transport Technology and = > Architecture Planning >
> > >
> > 908 234 8462 >
> > mlazer@att.com >
> > >
> > >
> >  -----Original Message----- >
> > From:       = > Dimitri Papadimitriou >
> [ HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > triou@alcatel.be] >
>  >
> > Sent:       = > Monday, October 22, 2001 3:15 PM >
> > To: Lazer, Monica A, NNAD >
> > Cc: Ewart Tempest; lberger@movaz.com; = > ccamp@ops.ietf.org >
> > Subject:    Re: Generalized = > Signaling - LSP Encoding Type expansion >
> > >
> >  << File: Card for Dimitri = > Papadimitriou >> Hi Monica, >
> > >
> > Fine. Now we know the following: GMPLS is = > really attractive for >
> > carriers when it supports all transport = > technologies so it has >
> > to support Fiber Channel as well. >
> > >
> > I wasn't aware that Ewart was capable to = > read in your mind ;-) >
> > >
> > Regards, >
> > Dimitri. >
> > >
> > "Lazer, Monica A, NNAD" = > wrote: >
> > > >
> > > Dimitri, >
> > > I am just answering the PS question = > with this message. >
> > > The short answer is yes.  The = > long answer is that the GMPLS control >
> plane >
> > is >
> > > really useful if it can support = > connection management for all the >
> > transport >
> > > services supported by the transport = > network using GMPLS. Therefore, >
> the >
> > > carrier services section for the NNI = > document to be posted on the OIF >
> site >
> > > within a few minutes and the next = > draft of the carrier requirements >
> IETF >
> > > draft will both contain references to = > support of Fiber Channel. >
> > > Regards, >
> > > Monica A. Lazer >
> > > Advanced Transport Technology and = > Architecture Planning >
> > > >
> > > 908 234 8462 >
> > > mlazer@att.com >
> > > >
> > >  -----Original = > Message----- >
> > > From:   Dimitri = > Papadimitriou >
> [ HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > triou@alcatel.be] >
> > > Sent:   Monday, October 22, = > 2001 2:47 PM >
> > > To:     Ewart = > Tempest >
> > > Cc:     = > lberger@movaz.com; ccamp@ops.ietf.org >
> > > = > Subject:        Re: Generalized = > Signaling - LSP Encoding Type >
> expansion >
> > > >
> > >  << File: Card for Dimitri = > Papadimitriou >> Hi Ewart, >
> > > >
> > > If you take a look on the IEEE = > Standards you will see >
> > > that GE is referred to as >
> > > - 802.3z for 1Gbps (see below [1]) = > same exists for copper 802.3ab >
> > > - 802.3ae for 10Gbps (see below = > [2]) >
> > > >
> > > So my question is what do you have in = > mind ? to separate >
> > > these values ? >
> > > >
> > > Thanks, >
> > > Dimitri. >
> > > >
> > > PS: for FiberChannel sorry i am not = > an expert but is someone >
> > >     targeting to = > use GMPLS for FiberChannel LSP ? >
> > > >
> > > ------- >
> > > >
> > > [1] From - HREF=3D"http://standards.ieee.org" = > TARGET=3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define Carrier Sense = > Multiple Access with Collision >
> > > Detection (CSMA/CD) Media Access = > Control (MAC) parameters and minimal >
> > > augmentation of its operation, = > physical layer characteristics, >
> repeater >
> > > functions and management parameters = > for transfer of 802.3 and Ethernet >
> > > format frames at 1,000 Mb/s. >
> > > >
> > > Project purpose: The purpose of this = > project is to extend the 802.3 >
> > > protocol to an operating speed of = > 1,000 Mb/s in order to provide a >
> > > significant increase in bandwidth = > while maintaining maximum >
> > > compatibility >
> > > with the installed base of CSMA/CD = > nodes, previous investment in >
> > > research >
> > > and development, and principles of = > network operation and management. >
> > > >
> > > [2] From - HREF=3D"http://standards.ieee.org" = > TARGET=3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define 802.3 Media = > Access Control (MAC) parameters and >
> > > minimal augmentation of its = > operation, physical layer characteristics >
> > > and management parameters for = > transfer of LLC and Ethernet format >
> > > frames at 10 Gb/s using full duplex = > operation as defined in the 802.3 >
> > > standard. In addition to the = > traditional LAN space, add parameters and >
> > > mechanisms that enable deployment of = > Ethernet over the Wide Area >
> Network >
> > > operating at a data rate compatible = > with OC-192c and SDH VC-4-64c >
> > > payload >
> > > rate. >
> > > >
> > > Project purpose: The purpose of this = > project is to extend the 802.3 >
> > > protocol to an operating speed of 10 = > Gb/s and to expand the Ethernet >
> > > application space to include Wide = > Area Network links in order to >
> provide >
> > > a significant increase in bandwidth = > while maintaining maximum >
> > > compatibility >
> > > with the installed base of 802.3 = > interfaces, previous investment in >
> > > research >
> > > and development, and principles of = > network operation and management. >
> > > >
> > > ------- >
> > > >
> > > > Ewart Tempest wrote: >
> > > > >
> > > > Lou, >
> > > > >
> > > > Within section 3.1.1 of = > draft-ietf-mpls-generalized-signaling-06 can >
> > > > you please add additonal LSP = > Encoding Types for GE and FiberChannel. >
> > > > GE is not really covered by the = > existing Ethernet related encoding >
> > > > types, and FiberChannel is not = > covered at all. Thanks. >
> > > > >
> > > > Ewart >
> > >

> > > > ------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 08:56:50 -0700 Message-ID: From: "Mannie, Eric" To: "'tsg15q11@itu.ch'" , "'t1x15@t1.org'" Cc: 'Juergen Heiles' , "'kireeti@juniper.net'" , "'ccamp@ops.ietf.org'" Subject: FW: Moving right along ... Date: Tue, 23 Oct 2001 17:39:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear ITU-T and T1 folks, Since Juergen is fowarding some e-mails from the IETF CCAMP mailing list to ITU-T and T1, I thought it is appropriate to forward also my answer :-) (I put the full text). Please note also that I don't want to start an inter-mailing list flooding between three bodies, since all people interested by GMPLS are on the CCAMP mailing list I guess. I tried to remove all frustrations in my answer :-) Kind regards, Eric -----Original Message----- From: Mannie, Eric Sent: Tuesday, October 23, 2001 5:12 PM To: 'Juergen Heiles'; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: RE: Moving right along ... Juergen, I am answering to your e-mails exactly because I am the editor of these documents. Some people don't want to answer anymore. Answering or not to e-mails is a personal decision of each one, nobody is forced to answer. You had the feedback from the mailing list. In general when people are happy with what they saw they don't spend time to add more comments. Your proposals were supported by you and Maarten. I answered with Dimitri. It is easy of course (for all of us) to ask all our colleagues and friends to flood a mailing list. Concerning your request to move the group signals to the other draft: this was answered publicly by Kireeti during the last CCAMP meeting and the answer was no. I asked again to Kireeti a couple of weeks ago, same answer. This is also the advice that I received from Rob. Concerning your label proposal: details are not yet cooked from our (I and Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding Adjacency there is no second STS-3 group, sorry if my example was confusing). Your text needs to be corrected but that's a detail, it just shows that it is quite difficult to write a text that works in all cases. We spend a considerable amount of time reviewing the current label encoding and we made sure that it works in the craziest cases. Indeed, this is the most stable part of the SDH/SONET draft since a very long time. By adopting your proposal we will have to do it again for no additional benefit and we will need another WG last call (you know it perfectly). That's why I refused during the WG last call some months ago, and why I am refusing again. As an editor my job is also to keep the boat in the middle of the river and to make sure that drafts are progressing and are not being constantly re-worded. Also, I don't want to force all manufacturers to change their implementations (prototypes:-) of the SONET label just because you found another way of encoding it. One solution or the other is more a matter of personal feeling. At this stage, as a co-author you should be more concerned by finishing this work. We can spend years having new ideas, improving and proposing modifications to a draft. It is a fact that we spend a huge amount of time (for me it represents months of work since the beginning of year 2000) fine-tuning this draft. Now it is time to publish it. >From the technical point of view your proposals versus keeping the current text will not change anything. It started as a political issue and I hope that it didn't become a personal issue. I am just asking you to help us to publish this work, even if it is not 100% as you would like to see it. Kind regards, Eric >-----Original Message----- >From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] >Sent: Tuesday, October 23, 2001 1:46 PM >To: Mannie, Eric; 'Juergen Heiles'; 'Kireeti Kompella'; >ccamp@ops.ietf.org >Subject: AW: Moving right along ... > > >Eric, > > >it is getting boring and frustrating to discuss the same issue for several >month with several people supporting the proposals and only one person >opposing them. But this person has the power to reject them as editor. If >this is the way IETF works I have to accept it. However I have to reconsider >my future activities in this case. >It seems that you think I want to block the GMPLS activities by bringing up >late issues. That is not the case, we have a long discussion on these issues >for month (on the ccamp list and on private lists) and the only rejection >came from your side. > > >So see my comments below > >Juergen > > -----Ursprüngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Dienstag, 23. Oktober 2001 12:23 > An: 'Juergen Heiles'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Betreff: RE: Moving right along ... > > > Hi Juergen, > > We already discussed all these points (at least 5 times) :-) even more > > - about automatic detection: > > Indeed, you either configure a box with a signal structure, or if > implemented you can ask to the box to discover itself the structure (what > you call automatic detection). > For groups the box has to discover the structure itself. > Automatic detection is a process applied internally to a box, and this is > totally invisible to any other box in the network. This is an > implementation > issue, not a protocol issue since the protocol defines everyhting you need > to do it. > > I understand your frustration that SDH standards don't describe all the > processes for an implementation, but in general standards don't touch that > part. > SDH and Sonet standards define detailed equipment functionality in order to ensure interworking. ITU has for example G.783 that defeins in detail what to do in SDH equipment. Even G.707 gives some details on pointer processing (genration, interpretation). For SONET we have GR-253 from Telcordia which provides this details. No of them mentiones automatic detection. > Automatic detection is a matter of reading the standard and understanding > how the multiplexing works. By the way, you explained it yourself > very well. > > The fact that a process is not described in some SDH standards has no > meaning, it is simply not relevant. Every manufacturer is free to do its > implementation as he likes if the protocol is fullfilled, and this is the > case. > > - about the comparison of automatic detection and transparency: > > You are comparing apples with chocolates. Transparency may require to > transport bytes in unused bytes, so in that case it changes the overhead. > Automatic detection is an internal process. > > - You wrote: "During errors (defects, AIS condtions) of individual singals > of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic." > > and I already answered many times: a super signal (group signal) is one > single LSP. If something fails inside everything fails. In that case you > don't need to demultiplex anymore, you just protect/restore the whole (if > required). A group signal is a signaling plane object, i.e. one > single LSP. > I mentioned the case that the problem is outside your LSP. You get for example a signal from a user and setup a group LSP. Now due to problems on the user side one of the VCs has AIS, may be the user isn't even using this VC currently. You cannot protect it as the problem is outside the LSP. If you now drop all other VCs of this group your user would be very happy I assume. > - Can you present me any ITU/ANSI standard that defines automatic > detection > of the group structure? > > No need, this is not in the scope of ITU/ANSI standards. Are you defining what is in the scope of ITU/ANSI standards? This is in the scope of ITU/ANSI/Telcordia standards. Look on G.707 pointer interpretation, G.783 and GR-253 as mentioned above. When we talk about standard SONET/SDH it includes the equipment functionality. For ETSI we even have compliance statements that go down to these details. I have no problems when soemone implements this feature, but we should no give the impression that this is a standard SONET/SDH feature by putting it into the standard features document. Move it to the non-standard document. > > - You wrote " You haven't provided a reason for different lables. We had > several people that wanted to have the same label structure and only you > opposed. So what is rough consensus?" > > The labels are local per interface, so they are "different" by definition > since an SDH interface is not a Sonet interface. A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N with AU-3 have the identical structure. But with the current proposal we have to use different lables. Is this simple? > However, we > defined the two > label formats based on the same principles, i.e. the first field is the > index of the first AUG-1/STS-1 (easy). We chosen not to indicate any level > of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because this > is not needed and less flexible. A label is just a simple pointer in the > multiplex, how to interpret the content of what is pointed to is > not defined > by the label. > I just took the SDH AU3 case and used it for SONET. So if you see a problem it would already apply to the defined SDH lable. > Using your proposal we would introduce a particular case, and in that case > there is no reason why we should not introduce other particular > case (AUG-4, > etc). At the end we would have something totally unreadable. > > Your proposal has also some issues, e.g. with your definition of the S > field: > > "1. S is the index of a particular AUG-1/STS-3 group. S=1->N > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, > and S=N indicates the last AUG-1/STS-3 group of this multiplex. > S is not significant for STM-0/STS-1. > > What happens if a link is not a a multiple of 3xN STS-1 ? For instance, a > virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an STS-4. > There is no real second STS-3 group. Your proposal is not > appropriate to the > level of flexibility that we want to provide. Another observations: our > undrestanding of the label is that it is defined before any interleaving, > not after. > Oh, suddently we have STS-4, STS-4 virtual links poping up, interesting. But couldn't we also have virtual SDH signals with only 5 AU-3? I don't know as I don't have any information about this virtual link concept. But if you introduce something like this there should be no difference between SONET and SDH. Otherwise we introduce new differences between SONET and SDH that we tried to avoid now for some years (see Deborahs e-mail). We learned from the mistakes made during the development of SONET and SDH. In todays global world we don't want these differences. And that is the reason why we propose to use a common lable. Don't make the same mistakes again. So if you see a problem it also applies to the defined SDH label. > I am opposed because your proposal doesn't bring any new functionality. > There are probably 100 ways of coding such a label for SDH and Sonet. We > discussed it during one year, The proposal to use a common lable is already disucssed for several month (over 1/2 year) as soon as we got involved in the GMPLS discussions. > we agreed on the current one because it is > simple, easy to understand, easy to code and very flexible (and more > important we never broke it !!!). We validate it, it is stable > since a very > long time. Why should we accept your way of coding it, and not the way of > somebody else at this final stage ? > To use a common label is the only alternative proposal we have, no others. It makes a lot of sense and is supported by several people on the list. Up to know only oppossed by you. Again what is rough consensus? > Kind regards, > > Eric > > -----Original Message----- > From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] > Sent: Monday, October 22, 2001 3:01 PM > To: Mannie, Eric; 'Kireeti Kompella'; ccamp@ops.ietf.org > Subject: AW: Moving right along ... > > > Hi Eric, > > sorry for the delayed answer, but I have problems with the remtoe > LAN access > here in Geneva. > I am therefore sending the mail via my ITU e-mail account and hope it is > accepted by the ccamp list server. > > You compare groups with the multiplier, this is wrong. The multiplier sets > up n indivudal VC-n connections. The transport plane sees only the > individual VCs and the VC type (VC-4/372712711) is explicitly > defined. So no > additional support at the transport plane is needed. It is a pure control > plane feature. > Groups are not a pure control plane feature. When you setup a group (AUG, > TUG, VTG, STSG) the transport plane still has to handle the individual > VCs/SPEs that are part of the group. Due the independent timing of each > VC/STS-SPE pointer processing has to be done per individual VC/SPE. The > transport plane cannot switch the group as a whole between STM/STS ports. > The transport plane therefore has to automatically detect the structure of > the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a > mixture and that may change over the lifetime of the group. This automatic > detection is not a standard SONET/SDH feature. As I described in previous > e-mails it is possible to do it based on pointer values during non error > situations. During errors (defects, AIS condtions) of individual > singals of > a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. > If a single > VC-12 in a TUG3 group has AIS (note that the AIS could result > from a failure > outside the LSP), I assume that still all the other VCs of the group shall > be connected without errors. No SONET/SDH standard covers the automatic > detection. > So in my view it is similarly to transparency of individual SOH > bytes. G.707 > defines the individual SOH bytes, however transparency it is not standard > SONET/SDH and is therefore in the non-standard document. In the same way > G.707 defines groups, but not the automatic detection of the group > structure. So it should be moved to the non-standards document. At the > London meeting Kireeti said the decision on standard/non-standard features > is not based on rough consensus, but on what is in the ITU/ANSI documents. > Can you present me any ITU/ANSI standard that defines automatic > detection of > the group structure? > > You say groups are cool, may be for some applications. But note > that groups > have the same fragementation problem as contiguous concatenation. > The VCs in > a group always have to stay together. If for a example a TUG2 consits of 3 > VC-12 you cannot put them in arbitrary free time slots. They have stay in > the time slots that belong to a single TUG2. > > > Concering the lable, aligning the SONET labels with the SDH lables makes > live easier. It is also a sign that SONET and SDH are identical for most > parts. I also showed you that SONET uses the same two-stage interleaving > process as SDH. If you look at the attached figure from T1.105 > you see that > the STS-1 time slots in an STS-N signal are not continously > number. First 3 > STS-1s are combiend to a STS3 groupg and then the STS3 groups are > multiplexed. The same as SDH with AU3s and AUGs. > As the SONET lables will become the same as the SDH labels we > don't have to > evaluate much. I already made a proposal some time ago. Why introduce > different labels without a need? > You haven't provided a reason for different lables. We had several people > that wanted to have the same label structure and only you opposed. So what > is rough consensus? > > See my proposal for the labels below. > > > Juergen > > > This is my proposal for the label: > The format of the label for SDH and/or SONET TDM-LSR link is: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S | U | K | L | M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For SDH, this is an extension of the numbering scheme defined in > G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same > signaling scheme is used in order to provide easy interworkign between > SDH and SONET signaling. For the S field a STS-3 group,which > corresponds with the SDH AUG-1 level is introduce. The U field > indicates > the position of the STS-3c-SPE or STS-1-SPE within the STS-3 > group. The K > field is not significant for SONET as it doesn't support structured > STS-3c-SPEs and must be set to zero. > > Each letter indicates a possible branch number starting at the > parent node in the multiplex structure. Branches are considered as > numbered in increasing order, starting from the top of the > multiplexing structure. The numbering starts at 1, zero is used to > indicate a non-significant field. > > When a field is not significant in a particular context it MUST be > set to zero when transmitted, and MUST be ignored when received. > > When hierarchical SDH/SONET LSPs are used, an LSP with a given > bandwidth can be used to tunnel lower order LSPs. The higher > order SDH/SONET LSP behaves as a virtual link with a given > bandwidth (e.g. VC-3), it may also be used as a Forwarding > Adjacency. A lower order SDH/SONET LSP can be established through > that higher order LSP. Since a label is local to a (virtual) link, > the highest part of that label is non-significant and is set to > zero. > > For instance, a VC-3 LSP can be advertised as a forwarding > adjacency. In that case the labels allocated between the two ends > of that LSP (i.e. for that "link") will have S, U and K set to > zero, i.e., non-significant, while L and M will be used to > indicate the signal allocated in that VC-3. > > 1. S is the index of a particular AUG-1/STS-3 group. S=1->N > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, > and S=N indicates the last AUG-1/STS-3 group of this multiplex. > S is not significant for STM-0/STS-1. > > 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 > group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a > AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, > while U=2->4 > indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 > group. > > 3. K is only significant for SDH VC-4 and must be ignored for > SONET and SDH HOVC-3. It indicates a specific branch of a VC-4. > K=1 indicates that the VC-4 is not further subdivided and > contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC- > 4. K is not significant when the AUG-1 is divided into AU-3s > (easy to read and test). > > 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. > It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1 > indicates that the TUG-3/VC-3/STS-1 SPE is not further > subdivided and contains a VC-3/C-3 in SDH or the equivalent in > SONET. L=2->8 indicates a specific TUG-2/VT Group inside the > corresponding higher order signal. > > 5. M indicates a specific branch of a TUG-2/VT Group. It is not > significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. > M=1 indicates that the TUG-2/VT Group is not further subdivided > and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 > inside the corresponding VT Group, these values MUST NOT be used > for SDH since there is no equivalent of VT-3 with SDH. M=4->6 > indicates a specific VC-12/VT-2 SPE inside the corresponding > TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE > inside the corresponding TUG-2/VT Group. Note that M=0 denotes > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). > > > The M encoding is summarized in the following table: > > M SDH SONET > ---------------------------------------------------------- > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE > 1 VC-2 VT-6 > 2 - 1st VT-3 > 3 - 2nd VT-3 > 4 1st VC-12 1st VT-2 > 5 2nd VC-12 2nd VT-2 > 6 3rd VC-12 3rd VT-2 > 7 1st VC-11 1st VT-1.5 > 8 2nd VC-11 2nd VT-1.5 > 9 3rd VC-11 3rd VT-1.5 > 10 4th VC-11 4th VT-1.5 > > In case of contiguous concatenation, the label that is used is the > lowest label of the contiguously concatenated signal as explained > before. The higher part of the label indicates where the signal > starts and the lowest part is not significant. For instance, when > requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0. > > Examples of labels: > > Example 1: S>0, U=1, K=1, L=0, M=0 > Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group. > > Example 2: S>0, U=1, K>1, L=1, M=0 > Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. > > Example 3: S>0, U>1, K=0, L=0, M=0 > Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth > AUG-1/STS-3 group. > > Example 4: S>0, U>1, K=0, L>1, M=1 > Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 > SPE of the Sth AUG-1/STS-3 group. > > Example 5: S>0, U>1, K=0, L>1, M=9 > Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth > VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. > > Example 6: S>0, U=1, K>1, L>1, M=5 > Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of > the Sth AUG-1. > > > > > > -----Ursprüngliche Nachricht----- > > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > > Gesendet: Donnerstag, 18. Oktober 2001 18:58 > > An: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > > Betreff: RE: Moving right along ... > > > > > > Hello Juergen, > > > > Your comments are addressed hereafter. Note that you didn't raised any > > technical problem or mistake in your comments (i.e. the draft > "works" very > > well as it is). > > > > - the first comment is not about a technical issue but an > > "editorial" issue. > > - the second comment is about a change that will not bring any new > > capability. > > > > >Concerning the SDH/Sonet documents I want to raise a formal issue. > > >We have now two documents, a document that covers ITU/ANSI standard > > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that > > covers non-standard features > > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in > > Appendix 1 > > of the standard feature document a non standard feature (Group > signals) is > > listed. It is even mentioned that the use of groups (AUG, STSG, > > ...) is not > > described in standards. So this feature should be moved to the > > non-standards > > document. Otherwise the split of the documents doesn't make sense. > > > > We spend a considerable amount of time speaking about this > > particular issue > > and I still don't see any technical justification for what you said. > > > > For those who are not SDH/SONET experts some quick explanation: > > > > We call a "super-circuit" a set of physical circuits in the > > transport plane > > all belonging to the same LSP in the signaling plane. We > defined two kinds > > of super-circuits: "group circuits" and "multiplicative circuits". > > > > Multiplicative circuits are setup using the multiplier field that > > we defined > > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no > > objection > > about these ones. > > > > Group circuits are setup using the SDH/SONET naming for groups, > i.e. AUG, > > TUG, VTG (we defined the equivalent signal type in the signaling). The > > comment of Juergen is about these group circuits. A group circuit > > represents > > some bandwidth at a given place in the SDH/SONET multiplex. The > > advantage of > > such a super-circuit is that the customer can re-structure its > content as > > he/she likes. The operator doesn't care. > > > > Such an application is possible and is already implemented. SDH/SONET is > > self-describing, i.e. by looking at the signal one can understand > > how it is > > structured (like Juergen explained on the mailing list), so one > > can setup a > > circuit without describing the content (very very cool). > > > > The transport plane ignores that the signaling plane uses an > "abstraction" > > (i.e. an LSP) representing several physical circuits. Note that > > restoration > > and management belong respectively to the signaling plane and to the > > management plane in the IETF view (not to the transport plane > like in the > > ITU-T view). > > > > From that point of view, group circuits are a GMPLS signaling > > plane feature > > and not a transport plane feature. We put the comment on the fact > > that this > > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy. > > > > I could say clearly at the beginning of the draft that the signal > > types that > > we are defining in this document are not ITU-T signal types but > > GMPLS signal > > types (of course) whose have in some cases a direct > relationship with the > > ITU-T signal types. > > > > Any objection ? > > > > >For the Sonet and SDH labels in > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I > > prefer to have the same coding for Sonet and SDH. That makes the > > implementation for Sonet and SDH simpler. Furthermore ITU and T1 > > have tried > > over the last years to align Sonet and SDH as much as possible. The > > definition of different labels for Sonet and SDH contradicts these > > activities. > > > > We discussed this one since a long time as well. Let me be clear: > > > > - labels are local to an interface (we all agree). > > - a link (interface) is operated at one point in the time as > either SDH or > > SONET. > > - your proposal will require to re-evaluate many things. > > - and it took us a lot of time to fine-tune and to validate the current > > label structure. > > - we could have technical issues with your proposal that would > impact more > > than this draft (Dimitri saw some of them, please see with him). > > - you never provided a complete analysis of your proposal. > > > > But more important: your proposal doesn't bring any additional > > functionality > > to the draft. > > > > At this very late stage, since this not bringing any new > > functionality, and > > since the label structure is very stable since a long time, I > would prefer > > not to restart a long technical discussion to change and re-validate the > > draft. > > > > Kind regards, > > > > Eric > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > > > An: ccamp@ops.ietf.org > > > Betreff: Moving right along ... > > > > > > > > > Despite the energetic subject line, we the WG chairs have been > > > lax in our duties. So, here goes: > > > > > > Lou has submitted the latest versions of the generalized > > > signaling documents quite some time ago (thanks, Lou): > > > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > > draft-ietf-mpls-generalized-signaling-06.txt > > > > > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > > > All of these should have addressed the issues raised in the earlier > > > versions. Please read the new versions, and send your comments to > > > the list by Tuesday Oct 23. At that point, when the final round > > > of comments have been addressed, these docs will go to IESG Last > > > Call. If any one objects to sending these docs to IESG Last Call, > > > raise your issues now. > > > > > > I see that the GMPLS architecture document is a CCAMP WG doc, but > > > the minutes say that we should look for consensus on the list. So, > > > if you think this doc *shouldn't* be a WG doc, let us know. (If we > > > arrived at a consensus, remind me :-)) If nothing is heard, the doc > > > will progress to WG Last Call. > > > > > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > > CCAMP WG docs; consensus at the meeting was Yes. Please let the > > > list know what your thinking is on these. (BTW, both these docs > > > were to have some edits done. If the authors could do that before > > > the next IETF, we can try to make more progress then.) > > > > > > The MIB overview doc was recently posted. Please read and comment > > > to the list. > > > > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > was generally thought to be useful; it will be published as a > > > CCAMP informational doc. This begins a two week Last Call on > > > the doc, ending Tuesday Oct 30. > > > > > > There was no consensus on whether the GMPLS framework should be > > > a CCAMP WG doc. Please indicate your pleasure. > > > > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > > raised that this draft is close to ready for WG Last Call. Please > > > review it, and let us know if you disagree. > > > > > > The OLI requirements doc was broadly accepted. Please let the > > > list know if you think this doc should be a WG doc. > > > > > > It's still open whether we (the IETF) should be working on > > > LMP-WDM. I urge the authors to keep on working on the doc, and > > > keeping it in sync with LMP; however, we will postpone making it > > > a CCAMP WG doc until the issue is resolved. Hopefully that will > > > happen in Salt Lake City. > > > > > > There was reasonable interest in the tunnel trace requirements > > > doc. Let's formalize this: do you think this should be made a > > > CCAMP WG document? > > > > > > Summary: > > > > > > 1) Final comments and IESG Last Call readiness for: > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > > draft-ietf-mpls-generalized-signaling-06.txt > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > > > 2) Should the following documents be CCAMP WG docs? > > > draft-bonica-tunneltrace-02.txt > > > draft-fontana-ccamp-gmpls-g709-00.txt > > > draft-ietf-ccamp-gmpls-architecture-00.txt > > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > > draft-many-ccamp-gmpls-framework-00.txt > > > draft-many-oli-reqts-00.txt > > > > > > 3) Comment on MIB overview. > > > > > > 4) Two week Last Call comments on > > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > > > 5) Last Call readiness of > > > draft-ietf-ccamp-gmpls-architecture-00.txt > > > draft-ietf-ccamp-lmp-01.txt > > > > > > Thanks, > > > Kireeti. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 08:44:26 -0700 Message-ID: <3BD58E94.1462988E@sandburst.com> Date: Tue, 23 Oct 2001 11:36:52 -0400 From: Eric Gray MIME-Version: 1.0 To: Yakov Rekhter Cc: "Lazer, Monica A, NNAD" , ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yakov, To be completely fair, it is NOT necessary for any provider to run "*all possible services*" for the introduction of a new control plane which supports only a subset of those services to be costly. It is only necessary for a provider to need to provide some services from that subset and some services from the universe-less-that-subset for it to be necessary to either support multiple control planes, or avoid use of the new control plane. This is probably what Monica means by diminished value. On the other hand, GMPLS is intended to be optimized for IP which - in some people's model of *the future of networking* - might mean that it will likely be adopted in spite of a perceived diminished value in the general sense. Hence, I think part of your point might be better expressed as: *Extending GMPLS to support all possible applications in an effort to reduce a perception of diminished value, would actually diminish the value of GMPLS for its target application(s).* What do you think? You wrote: > Monica, > > > Dimitri, > > Actually, it may be more accurate to put it differently - if GMPLS supports > > only a handful of the services running on a given transport network, than > > its value as a network's control plane component is diminished. > > To be even more accurate, GMPLS value is diminished *in the context* > of that particular transport network. And unless *all* providers > are going to run *all possible services* on their transport networks > (which is a somewhat unrealistic scenario), that means that the > value of GMPLS as a network's control plane component would be > diminished for *some*, but not *all* service providers. > > At the same time, it is important to keep in mind that being "all > things for all people" (aka as "perfect solution") is one of the > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > *particular* provider GMPLS would *not* support *all* the services > that this provider runs on its transport network. > > Yakov. > > > > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 3:15 PM > > To: Lazer, Monica A, NNAD > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > Fine. Now we know the following: GMPLS is really attractive for > > carriers when it supports all transport technologies so it has > > to support Fiber Channel as well. > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > Regards, > > Dimitri. > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > Dimitri, > > > I am just answering the PS question with this message. > > > The short answer is yes. The long answer is that the GMPLS control plane > > is > > > really useful if it can support connection management for all the > > transport > > > services supported by the transport network using GMPLS. Therefore, the > > > carrier services section for the NNI document to be posted on the OIF site > > > within a few minutes and the next draft of the carrier requirements IETF > > > draft will both contain references to support of Fiber Channel. > > > Regards, > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 2:47 PM > > > To: Ewart Tempest > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > If you take a look on the IEEE Standards you will see > > > that GE is referred to as > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > So my question is what do you have in mind ? to separate > > > these values ? > > > > > > Thanks, > > > Dimitri. > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > ------- > > > > > > [1] From - http://standards.ieee.org > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > augmentation of its operation, physical layer characteristics, repeater > > > functions and management parameters for transfer of 802.3 and Ethernet > > > format frames at 1,000 Mb/s. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of CSMA/CD nodes, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > [2] From - http://standards.ieee.org > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > minimal augmentation of its operation, physical layer characteristics > > > and management parameters for transfer of LLC and Ethernet format > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > standard. In addition to the traditional LAN space, add parameters and > > > mechanisms that enable deployment of Ethernet over the Wide Area Network > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > payload > > > rate. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > application space to include Wide Area Network links in order to provide > > > a significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of 802.3 interfaces, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > ------- > > > > > > > Ewart Tempest wrote: > > > > > > > > Lou, > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > GE is not really covered by the existing Ethernet related encoding > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > Ewart > > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 08:23:21 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBB2@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Yakov Rekhter'" Cc: ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 11:20:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yakov, Thank you for your reply. I appreciate your comments, but we may have some differences of opinion. For convenience, I am inserting my opinions in line. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Monday, October 22, 2001 4:12 PM To: Lazer, Monica A, NNAD Cc: ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Monica, > Dimitri, > Actually, it may be more accurate to put it differently - if GMPLS supports > only a handful of the services running on a given transport network, than > its value as a network's control plane component is diminished. To be even more accurate, GMPLS value is diminished *in the context* of that particular transport network. And unless *all* providers are going to run *all possible services* on their transport networks (which is a somewhat unrealistic scenario), that means that the value of GMPLS as a network's control plane component would be diminished for *some*, but not *all* service providers. [[Lazer, AT&T]] I think that we may have somewhat diverging opinions. For me a control plane of value for a given transport technology needs to support control for all the services supported in the data plane. To be more specific, if a transport technology supports transport for SONET, GbE, and SAN, its associated control plane must support signaling and routing for same. It does not need to encumber itself for support of services not implemented in the hardware, but I see no good reason to support a service in the data plane, but not in the control plane. At the same time, it is important to keep in mind that being "all things for all people" (aka as "perfect solution") is one of the *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a *particular* provider GMPLS would *not* support *all* the services that this provider runs on its transport network. [[Lazer, AT&T]] I am not looking at "all things for all people". I am looking, as I mentioned in an earlier message at the control plane of a given subnetwork supporting all the services of the data plane it controls. If some services using a given network elements use the control plane, while others need an outside OS, resource allocation and coordination becomes are real issue. Yakov. > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Monday, October 22, 2001 3:15 PM > To: Lazer, Monica A, NNAD > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > Fine. Now we know the following: GMPLS is really attractive for > carriers when it supports all transport technologies so it has > to support Fiber Channel as well. > > I wasn't aware that Ewart was capable to read in your mind ;-) > > Regards, > Dimitri. > > "Lazer, Monica A, NNAD" wrote: > > > > Dimitri, > > I am just answering the PS question with this message. > > The short answer is yes. The long answer is that the GMPLS control plane > is > > really useful if it can support connection management for all the > transport > > services supported by the transport network using GMPLS. Therefore, the > > carrier services section for the NNI document to be posted on the OIF site > > within a few minutes and the next draft of the carrier requirements IETF > > draft will both contain references to support of Fiber Channel. > > Regards, > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Monday, October 22, 2001 2:47 PM > > To: Ewart Tempest > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > If you take a look on the IEEE Standards you will see > > that GE is referred to as > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > - 802.3ae for 10Gbps (see below [2]) > > > > So my question is what do you have in mind ? to separate > > these values ? > > > > Thanks, > > Dimitri. > > > > PS: for FiberChannel sorry i am not an expert but is someone > > targeting to use GMPLS for FiberChannel LSP ? > > > > ------- > > > > [1] From - http://standards.ieee.org > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > augmentation of its operation, physical layer characteristics, repeater > > functions and management parameters for transfer of 802.3 and Ethernet > > format frames at 1,000 Mb/s. > > > > Project purpose: The purpose of this project is to extend the 802.3 > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > significant increase in bandwidth while maintaining maximum > > compatibility > > with the installed base of CSMA/CD nodes, previous investment in > > research > > and development, and principles of network operation and management. > > > > [2] From - http://standards.ieee.org > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > minimal augmentation of its operation, physical layer characteristics > > and management parameters for transfer of LLC and Ethernet format > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > standard. In addition to the traditional LAN space, add parameters and > > mechanisms that enable deployment of Ethernet over the Wide Area Network > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > payload > > rate. > > > > Project purpose: The purpose of this project is to extend the 802.3 > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > application space to include Wide Area Network links in order to provide > > a significant increase in bandwidth while maintaining maximum > > compatibility > > with the installed base of 802.3 interfaces, previous investment in > > research > > and development, and principles of network operation and management. > > > > ------- > > > > > Ewart Tempest wrote: > > > > > > Lou, > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > GE is not really covered by the existing Ethernet related encoding > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > Ewart > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 08:16:53 -0700 Message-Id: <200110231516.f9NFGW092807@merlot.juniper.net> To: "Lazer, Monica A, NNAD" cc: "'shehzad.mirza@bt.com'" , ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9837.1003850192.1@juniper.net> Date: Tue, 23 Oct 2001 08:16:32 -0700 From: Yakov Rekhter Monica, > All, > I am in full agreement with Shehzad. From a carrier's perspective, the value > of the control plane is in taking over specific functions which currently > reside in OSSs outside of the network itself. Having only some applications, > but not others of the given function move into the network greatly > diminishes the value of having that function supported in the control plane. > To be more specific, if out of n services supported by the transport > network, the control plane supports automated provisioning of 1/2n services > and the other 1/2n need support in the OSS, we still need to do the OSS work > for the given transport technology. So from a cost perspective, now we have > to ask ourselves whether we should pay for the provisioning function twice. While what you said makes sense from a given carrier's perspective, we need to take a broader view, as producing a "perfect solution" that meets *all* the requirements of *all* the carriers is an explicit non-goal of GMPLS. With this in mind, if the 1/2n services that aren't supported by the control plane are the services that are required by 90% of the carriers market, then indeed this is a problem. On the other hand, if these 1/2n services that aren't supported are the services required by only 10% of the carriers market, then this is quite acceptable. Understandably, the carriers who would fall into this 10% category could be quite unhappy about, and could even be quite vocal in expressing their dissatisfaction... Yakov. > Regards, > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] > Sent: Tuesday, October 23, 2001 6:25 AM > To: yakov@juniper.net > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org > Subject: RE: Generalized Signaling - LSP Encoding Type expansion > > Yakov, > > See comments in-line > > > -----Original Message----- > > From: Yakov Rekhter [SMTP:yakov@juniper.net] > > Sent: 22 October 2001 21:12 > > To: Lazer, Monica A, NNAD > > Cc: ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > Monica, > > > > > Dimitri, > > > Actually, it may be more accurate to put it differently - if GMPLS > > supports > > > only a handful of the services running on a given transport network, > > than > > > its value as a network's control plane component is diminished. > > > > To be even more accurate, GMPLS value is diminished *in the context* > > of that particular transport network. And unless *all* providers > > are going to run *all possible services* on their transport networks > > (which is a somewhat unrealistic scenario), that means that the > > value of GMPLS as a network's control plane component would be > > diminished for *some*, but not *all* service providers. > > > > > > > [shehzad] > For a control plane not to support all the transport services capable of > being carried over an operator's network diminishes the value of that > particular control plane. What is the point of having transparent/optical > equipment capable of transporting both Gigabit Ethernet and Fiber Channel > (as an example), if provisioning was based on signalling that could only > support Gigabit Ethernet? > > This is a restriction for every provider regardless of whether a network is > a standalone one built for a large customer or a national network serving > multiple customers. The effective 'banning' of certain services that are > currently being offered by providers will unnecessarily damage the business > case for the adoption of GMPLS. > > > > > At the same time, it is important to keep in mind that being "all > > things for all people" (aka as "perfect solution") is one of the > > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > > *particular* provider GMPLS would *not* support *all* the services > > that this provider runs on its transport network. > > > > Yakov. > > > > > [Shehzad] > There is no technical reason why a GMPLS encoding type could not be > adopted for a recognised format such as Fiber Channel, as far as I am aware > the adoption of Fiber Channel is not likely to destroy the foundations of > GMPLS. > > On a more general point, is the support of transport technologies > within GMPLS signalling restricted to those that the authors of the GMPLS > drafts will allow? > > > > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > > Sent: Monday, October 22, 2001 3:15 PM > > > To: Lazer, Monica A, NNAD > > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > > > Fine. Now we know the following: GMPLS is really attractive for > > > carriers when it supports all transport technologies so it has > > > to support Fiber Channel as well. > > > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > > > Regards, > > > Dimitri. > > > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > > > Dimitri, > > > > I am just answering the PS question with this message. > > > > The short answer is yes. The long answer is that the GMPLS control > > plane > > > is > > > > really useful if it can support connection management for all the > > > transport > > > > services supported by the transport network using GMPLS. Therefore, > > the > > > > carrier services section for the NNI document to be posted on the OIF > > site > > > > within a few minutes and the next draft of the carrier requirements > > IETF > > > > draft will both contain references to support of Fiber Channel. > > > > Regards, > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > -----Original Message----- > > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > > Sent: Monday, October 22, 2001 2:47 PM > > > > To: Ewart Tempest > > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > > Subject: Re: Generalized Signaling - LSP Encoding Type > > expansion > > > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > > > If you take a look on the IEEE Standards you will see > > > > that GE is referred to as > > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > > > So my question is what do you have in mind ? to separate > > > > these values ? > > > > > > > > Thanks, > > > > Dimitri. > > > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > > > ------- > > > > > > > > [1] From - http://standards.ieee.org > > > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > > augmentation of its operation, physical layer characteristics, > > repeater > > > > functions and management parameters for transfer of 802.3 and Ethernet > > > > format frames at 1,000 Mb/s. > > > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > > significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of CSMA/CD nodes, previous investment in > > > > research > > > > and development, and principles of network operation and management. > > > > > > > > [2] From - http://standards.ieee.org > > > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > > minimal augmentation of its operation, physical layer characteristics > > > > and management parameters for transfer of LLC and Ethernet format > > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > > standard. In addition to the traditional LAN space, add parameters and > > > > mechanisms that enable deployment of Ethernet over the Wide Area > > Network > > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > > payload > > > > rate. > > > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > > application space to include Wide Area Network links in order to > > provide > > > > a significant increase in bandwidth while maintaining maximum > > > > compatibility > > > > with the installed base of 802.3 interfaces, previous investment in > > > > research > > > > and development, and principles of network operation and management. > > > > > > > > ------- > > > > > > > > > Ewart Tempest wrote: > > > > > > > > > > Lou, > > > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > > GE is not really covered by the existing Ethernet related encoding > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > > > Ewart > > > > > ------_=_NextPart_001_01C15BCA.5A2A5650 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2654.19"> > RE: Generalized Signaling - LSP Encoding Type expansion > > > >

All, >
I am in full agreement with Shehzad. From a = > carrier's perspective, the value of the control plane is in taking over = > specific functions which currently reside in OSSs outside of the = > network itself. Having only some applications, but not others of the = > given function move into the network greatly diminishes the value of = > having that function supported in the control plane. To be more = > specific, if out of n services supported by the transport network, the = > control plane supports automated provisioning  of 1/2n services = and the other 1/2n need support in the OSS, we still need to do the OSS = > work for the given transport technology. So from a cost perspective, = > now we have to ask ourselves whether we should pay for the provisioning = > function twice.

> >

Regards, >

> >

Monica A. Lazer >
Advanced Transport Technology and Architecture = > Planning >

> >

908 234 8462 >
mlazer@att.com >

>
> >

 -----Original Message----- >
From:   shehzad.mirza@bt.com [ HREF=3D"mailto:shehzad.mirza@bt.com">mailto:shehzad.mirza@bt.com] = > >
Sent:   Tuesday, October 23, 2001 6:25 = > AM >
To:     yakov@juniper.net >
Cc:     Lazer, Monica A, NNAD; = > ccamp@ops.ietf.org >
Subject:        = > RE: Generalized Signaling - LSP Encoding Type expansion >

> >

Yakov, >

> >

See comments in-line >

> >

> -----Original Message----- >
> From: Yakov Rekhter = > [SMTP:yakov@juniper.net] >
> Sent: 22 October 2001 21:12 >
> To:   Lazer, Monica A, NNAD >
> Cc:   ccamp@ops.ietf.org >
> Subject:      Re: = > Generalized Signaling - LSP Encoding Type expansion >
> >
> Monica, >
> >
> > Dimitri, >
> > Actually, it may be more accurate to put = > it differently - if GMPLS >
> supports >
> > only a handful of the services running on = > a given transport network, >
> than >
> > its value as a network's control plane = > component is diminished. >
> >
> To be even more accurate, GMPLS value is = > diminished *in the context* >
> of that particular transport network. And = > unless *all* providers >
> are going to run *all possible services* on = > their transport networks >
> (which is a somewhat unrealistic scenario), = > that means that the >
> value of GMPLS as a network's control plane = > component would be >
> diminished for *some*, but not *all* service = > providers. >
> >
> >
> >
        SIZE=3D2>[shehzad]  >
For a control plane not to support all the transport = > services capable of >
being carried over an operator's network diminishes = > the value of that >
particular control plane.  What is the point of = > having transparent/optical >
equipment capable of transporting both Gigabit = > Ethernet and Fiber Channel >
(as an example), if provisioning was based on = > signalling that could only >
support Gigabit Ethernet? >

> >

This is a restriction for every provider regardless = > of whether a network is >
a standalone one built for a large customer or a = > national network serving >
multiple customers. The effective 'banning' of = > certain services that are >
currently being offered by providers will = > unnecessarily damage the business >
case for the adoption of GMPLS. >

>
>
> >

> At the same time, it is important to keep in = > mind that being "all >
> things for all people" (aka as = > "perfect solution") is one of the >
> *non-goals* of GMPLS. So, it shouldn't come as = > a surprise if for a >
> *particular* provider GMPLS would *not* support = > *all* the services >
> that this provider runs on its transport = > network. >
> >
> Yakov. >
> >
> >
        SIZE=3D2>[Shehzad] >
        There is = > no technical reason why a GMPLS encoding type could not be >
adopted for a recognised format such as Fiber = > Channel, as far as I am aware >
the adoption of Fiber Channel is not likely to = > destroy the foundations of >
GMPLS. >

> >

        On a more = > general point, is the support of transport technologies >
within GMPLS signalling restricted to those that the = > authors of the GMPLS >
drafts will allow? >
         = > >

>
>
>
>
> >

> > Monica A. Lazer >
> > Advanced Transport Technology and = > Architecture Planning >
> > >
> > 908 234 8462 >
> > mlazer@att.com >
> > >
> > >
> >  -----Original Message----- >
> > From:       = > Dimitri Papadimitriou >
> [ HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > triou@alcatel.be] >
>  >
> > Sent:       = > Monday, October 22, 2001 3:15 PM >
> > To: Lazer, Monica A, NNAD >
> > Cc: Ewart Tempest; lberger@movaz.com; = > ccamp@ops.ietf.org >
> > Subject:    Re: Generalized = > Signaling - LSP Encoding Type expansion >
> > >
> >  << File: Card for Dimitri = > Papadimitriou >> Hi Monica, >
> > >
> > Fine. Now we know the following: GMPLS is = > really attractive for >
> > carriers when it supports all transport = > technologies so it has >
> > to support Fiber Channel as well. >
> > >
> > I wasn't aware that Ewart was capable to = > read in your mind ;-) >
> > >
> > Regards, >
> > Dimitri. >
> > >
> > "Lazer, Monica A, NNAD" = > wrote: >
> > > >
> > > Dimitri, >
> > > I am just answering the PS question = > with this message. >
> > > The short answer is yes.  The = > long answer is that the GMPLS control >
> plane >
> > is >
> > > really useful if it can support = > connection management for all the >
> > transport >
> > > services supported by the transport = > network using GMPLS. Therefore, >
> the >
> > > carrier services section for the NNI = > document to be posted on the OIF >
> site >
> > > within a few minutes and the next = > draft of the carrier requirements >
> IETF >
> > > draft will both contain references to = > support of Fiber Channel. >
> > > Regards, >
> > > Monica A. Lazer >
> > > Advanced Transport Technology and = > Architecture Planning >
> > > >
> > > 908 234 8462 >
> > > mlazer@att.com >
> > > >
> > >  -----Original = > Message----- >
> > > From:   Dimitri = > Papadimitriou >
> [ HREF=3D"mailto:dimitri.papadimitriou@alcatel.be">mailto:dimitri.papadimi= > triou@alcatel.be] >
> > > Sent:   Monday, October 22, = > 2001 2:47 PM >
> > > To:     Ewart = > Tempest >
> > > Cc:     = > lberger@movaz.com; ccamp@ops.ietf.org >
> > > = > Subject:        Re: Generalized = > Signaling - LSP Encoding Type >
> expansion >
> > > >
> > >  << File: Card for Dimitri = > Papadimitriou >> Hi Ewart, >
> > > >
> > > If you take a look on the IEEE = > Standards you will see >
> > > that GE is referred to as >
> > > - 802.3z for 1Gbps (see below [1]) = > same exists for copper 802.3ab >
> > > - 802.3ae for 10Gbps (see below = > [2]) >
> > > >
> > > So my question is what do you have in = > mind ? to separate >
> > > these values ? >
> > > >
> > > Thanks, >
> > > Dimitri. >
> > > >
> > > PS: for FiberChannel sorry i am not = > an expert but is someone >
> > >     targeting to = > use GMPLS for FiberChannel LSP ? >
> > > >
> > > ------- >
> > > >
> > > [1] From - HREF=3D"http://standards.ieee.org" = > TARGET=3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define Carrier Sense = > Multiple Access with Collision >
> > > Detection (CSMA/CD) Media Access = > Control (MAC) parameters and minimal >
> > > augmentation of its operation, = > physical layer characteristics, >
> repeater >
> > > functions and management parameters = > for transfer of 802.3 and Ethernet >
> > > format frames at 1,000 Mb/s. >
> > > >
> > > Project purpose: The purpose of this = > project is to extend the 802.3 >
> > > protocol to an operating speed of = > 1,000 Mb/s in order to provide a >
> > > significant increase in bandwidth = > while maintaining maximum >
> > > compatibility >
> > > with the installed base of CSMA/CD = > nodes, previous investment in >
> > > research >
> > > and development, and principles of = > network operation and management. >
> > > >
> > > [2] From - HREF=3D"http://standards.ieee.org" = > TARGET=3D"_blank">http://standards.ieee.org >
> > > >
> > > Project scope: Define 802.3 Media = > Access Control (MAC) parameters and >
> > > minimal augmentation of its = > operation, physical layer characteristics >
> > > and management parameters for = > transfer of LLC and Ethernet format >
> > > frames at 10 Gb/s using full duplex = > operation as defined in the 802.3 >
> > > standard. In addition to the = > traditional LAN space, add parameters and >
> > > mechanisms that enable deployment of = > Ethernet over the Wide Area >
> Network >
> > > operating at a data rate compatible = > with OC-192c and SDH VC-4-64c >
> > > payload >
> > > rate. >
> > > >
> > > Project purpose: The purpose of this = > project is to extend the 802.3 >
> > > protocol to an operating speed of 10 = > Gb/s and to expand the Ethernet >
> > > application space to include Wide = > Area Network links in order to >
> provide >
> > > a significant increase in bandwidth = > while maintaining maximum >
> > > compatibility >
> > > with the installed base of 802.3 = > interfaces, previous investment in >
> > > research >
> > > and development, and principles of = > network operation and management. >
> > > >
> > > ------- >
> > > >
> > > > Ewart Tempest wrote: >
> > > > >
> > > > Lou, >
> > > > >
> > > > Within section 3.1.1 of = > draft-ietf-mpls-generalized-signaling-06 can >
> > > > you please add additonal LSP = > Encoding Types for GE and FiberChannel. >
> > > > GE is not really covered by the = > existing Ethernet related encoding >
> > > > types, and FiberChannel is not = > covered at all. Thanks. >
> > > > >
> > > > Ewart >
> > >

> > > > ------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 08:15:38 -0700 Message-ID: From: "Mannie, Eric" To: 'Juergen Heiles' , 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Tue, 23 Oct 2001 17:12:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen, I am answering to your e-mails exactly because I am the editor of these documents. Some people don't want to answer anymore. Answering or not = to e-mails is a personal decision of each one, nobody is forced to answer. You had the feedback from the mailing list. In general when people are = happy with what they saw they don't spend time to add more comments. Your proposals were supported by you and Maarten. I answered with = Dimitri. It is easy of course (for all of us) to ask all our colleagues and = friends to flood a mailing list. Concerning your request to move the group signals to the other draft: = this was answered publicly by Kireeti during the last CCAMP meeting and the answer was no. I asked again to Kireeti a couple of weeks ago, same = answer. This is also the advice that I received from Rob. Concerning your label proposal: details are not yet cooked from our (I = and Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding = Adjacency there is no second STS-3 group, sorry if my example was confusing). = Your text needs to be corrected but that's a detail, it just shows that it = is quite difficult to write a text that works in all cases. We spend a considerable amount of time reviewing the current label = encoding and we made sure that it works in the craziest cases. Indeed, this is = the most stable part of the SDH/SONET draft since a very long time. By = adopting your proposal we will have to do it again for no additional benefit and = we will need another WG last call (you know it perfectly). That's why I = refused during the WG last call some months ago, and why I am refusing again. As an editor my job is also to keep the boat in the middle of the river = and to make sure that drafts are progressing and are not being constantly re-worded. Also, I don't want to force all manufacturers to change = their implementations (prototypes:-) of the SONET label just because you = found another way of encoding it. One solution or the other is more a matter = of personal feeling. At this stage, as a co-author you should be more concerned by finishing = this work. We can spend years having new ideas, improving and proposing modifications to a draft. It is a fact that we spend a huge amount of time (for me it represents months of work since the beginning of year 2000) fine-tuning this = draft. Now it is time to publish it. >From the technical point of view your proposals versus keeping the = current text will not change anything. It started as a political issue and I = hope that it didn't become a personal issue. I am just asking you to help us to publish this work, even if it is not = 100% as you would like to see it. Kind regards, Eric > -----Urspr=FCngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Dienstag, 23. Oktober 2001 12:23 > An: 'Juergen Heiles'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Betreff: RE: Moving right along ... > > > Hi Juergen, > > We already discussed all these points (at least 5 times) :-) even more > > - about automatic detection: > > Indeed, you either configure a box with a signal structure, or if > implemented you can ask to the box to discover itself the structure = (what > you call automatic detection). > For groups the box has to discover the structure itself. > Automatic detection is a process applied internally to a box, and = this is > totally invisible to any other box in the network. This is an > implementation > issue, not a protocol issue since the protocol defines everyhting you = need > to do it. > > I understand your frustration that SDH standards don't describe all = the > processes for an implementation, but in general standards don't touch = that > part. > SDH and Sonet standards define detailed equipment functionality in = order to ensure interworking. ITU has for example G.783 that defeins in detail what to do in SDH equipment. Even G.707 gives some details on pointer processing (genration, interpretation). For SONET we have = GR-253 from Telcordia which provides this details. No of them mentiones automatic detection. > Automatic detection is a matter of reading the standard and = understanding > how the multiplexing works. By the way, you explained it yourself > very well. > > The fact that a process is not described in some SDH standards has no > meaning, it is simply not relevant. Every manufacturer is free to do = its > implementation as he likes if the protocol is fullfilled, and this is = the > case. > > - about the comparison of automatic detection and transparency: > > You are comparing apples with chocolates. Transparency may require to > transport bytes in unused bytes, so in that case it changes the = overhead. > Automatic detection is an internal process. > > - You wrote: "During errors (defects, AIS condtions) of individual = singals > of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic." > > and I already answered many times: a super signal (group signal) is = one > single LSP. If something fails inside everything fails. In that case = you > don't need to demultiplex anymore, you just protect/restore the whole = (if > required). A group signal is a signaling plane object, i.e. one > single LSP. > I mentioned the case that the problem is outside your LSP. You get for example a signal from a user and setup a group LSP. Now due to problems on the user side one of the VCs has AIS, may be the = user isn't even using this VC currently. You cannot protect it as the = problem is outside the LSP. If you now drop all other VCs of this group your user = would be very happy I assume. > - Can you present me any ITU/ANSI standard that defines automatic > detection > of the group structure? > > No need, this is not in the scope of ITU/ANSI standards. Are you defining what is in the scope of ITU/ANSI standards? This is in the scope of ITU/ANSI/Telcordia standards. Look on G.707 = pointer interpretation, G.783 and GR-253 as mentioned above. When we talk about standard SONET/SDH it includes the equipment functionality. For ETSI we = even have compliance statements that go down to these details. I have no problems when soemone implements this feature, but we should = no give the impression that this is a standard SONET/SDH feature by = putting it into the standard features document. Move it to the non-standard = document. > > - You wrote " You haven't provided a reason for different lables. We = had > several people that wanted to have the same label structure and only = you > opposed. So what is rough consensus?" > > The labels are local per interface, so they are "different" by = definition > since an SDH interface is not a Sonet interface. A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N with AU-3 = have the identical structure. But with the current proposal we have to use different lables. Is this simple? > However, we > defined the two > label formats based on the same principles, i.e. the first field is = the > index of the first AUG-1/STS-1 (easy). We chosen not to indicate any = level > of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because = this > is not needed and less flexible. A label is just a simple pointer in = the > multiplex, how to interpret the content of what is pointed to is > not defined > by the label. > I just took the SDH AU3 case and used it for SONET. So if you see a = problem it would already apply to the defined SDH lable. > Using your proposal we would introduce a particular case, and in that = case > there is no reason why we should not introduce other particular > case (AUG-4, > etc). At the end we would have something totally unreadable. > > Your proposal has also some issues, e.g. with your definition of the = S > field: > > "1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 = group, > and S=3DN indicates the last AUG-1/STS-3 group of this multiplex. > S is not significant for STM-0/STS-1. > > What happens if a link is not a a multiple of 3xN STS-1 ? For = instance, a > virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an = STS-4. > There is no real second STS-3 group. Your proposal is not > appropriate to the > level of flexibility that we want to provide. Another observations: = our > undrestanding of the label is that it is defined before any = interleaving, > not after. > Oh, suddently we have STS-4, STS-4 virtual links poping up, = interesting. But couldn't we also have virtual SDH signals with only 5 AU-3? I don't know as I don't have any information about this virtual link concept. But if you introduce something like this there should be no difference between SONET and SDH. Otherwise we introduce new = differences between SONET and SDH that we tried to avoid now for some years (see Deborahs e-mail). We learned from the mistakes made during the = development of SONET and SDH. In todays global world we don't want these = differences. And that is the reason why we propose to use a common lable. Don't make = the same mistakes again. So if you see a problem it also applies to the = defined SDH label. > I am opposed because your proposal doesn't bring any new = functionality. > There are probably 100 ways of coding such a label for SDH and Sonet. = We > discussed it during one year, The proposal to use a common lable is already disucssed for several = month (over 1/2 year) as soon as we got involved in the GMPLS discussions. > we agreed on the current one because it is > simple, easy to understand, easy to code and very flexible (and more > important we never broke it !!!). We validate it, it is stable > since a very > long time. Why should we accept your way of coding it, and not the = way of > somebody else at this final stage ? > To use a common label is the only alternative proposal we have, no = others. It makes a lot of sense and is supported by several people on the list. = Up to know only oppossed by you. Again what is rough consensus? > Kind regards, > > Eric > > -----Original Message----- > From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] > Sent: Monday, October 22, 2001 3:01 PM > To: Mannie, Eric; 'Kireeti Kompella'; ccamp@ops.ietf.org > Subject: AW: Moving right along ... > > > Hi Eric, > > sorry for the delayed answer, but I have problems with the remtoe > LAN access > here in Geneva. > I am therefore sending the mail via my ITU e-mail account and hope it = is > accepted by the ccamp list server. > > You compare groups with the multiplier, this is wrong. The multiplier = sets > up n indivudal VC-n connections. The transport plane sees only the > individual VCs and the VC type (VC-4/372712711) is explicitly > defined. So no > additional support at the transport plane is needed. It is a pure = control > plane feature. > Groups are not a pure control plane feature. When you setup a group = (AUG, > TUG, VTG, STSG) the transport plane still has to handle the = individual > VCs/SPEs that are part of the group. Due the independent timing of = each > VC/STS-SPE pointer processing has to be done per individual VC/SPE. = The > transport plane cannot switch the group as a whole between STM/STS = ports. > The transport plane therefore has to automatically detect the = structure of > the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 = or a > mixture and that may change over the lifetime of the group. This = automatic > detection is not a standard SONET/SDH feature. As I described in = previous > e-mails it is possible to do it based on pointer values during non = error > situations. During errors (defects, AIS condtions) of individual > singals of > a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. > If a single > VC-12 in a TUG3 group has AIS (note that the AIS could result > from a failure > outside the LSP), I assume that still all the other VCs of the group = shall > be connected without errors. No SONET/SDH standard covers the = automatic > detection. > So in my view it is similarly to transparency of individual SOH > bytes. G.707 > defines the individual SOH bytes, however transparency it is not = standard > SONET/SDH and is therefore in the non-standard document. In the same = way > G.707 defines groups, but not the automatic detection of the group > structure. So it should be moved to the non-standards document. At = the > London meeting Kireeti said the decision on standard/non-standard = features > is not based on rough consensus, but on what is in the ITU/ANSI = documents. > Can you present me any ITU/ANSI standard that defines automatic > detection of > the group structure? > > You say groups are cool, may be for some applications. But note > that groups > have the same fragementation problem as contiguous concatenation. > The VCs in > a group always have to stay together. If for a example a TUG2 consits = of 3 > VC-12 you cannot put them in arbitrary free time slots. They have = stay in > the time slots that belong to a single TUG2. > > > Concering the lable, aligning the SONET labels with the SDH lables = makes > live easier. It is also a sign that SONET and SDH are identical for = most > parts. I also showed you that SONET uses the same two-stage = interleaving > process as SDH. If you look at the attached figure from T1.105 > you see that > the STS-1 time slots in an STS-N signal are not continously > number. First 3 > STS-1s are combiend to a STS3 groupg and then the STS3 groups are > multiplexed. The same as SDH with AU3s and AUGs. > As the SONET lables will become the same as the SDH labels we > don't have to > evaluate much. I already made a proposal some time ago. Why introduce > different labels without a need? > You haven't provided a reason for different lables. We had several = people > that wanted to have the same label structure and only you opposed. So = what > is rough consensus? > > See my proposal for the labels below. > > > Juergen > > > This is my proposal for the label: > The format of the label for SDH and/or SONET TDM-LSR link is: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S | U | K | L | M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For SDH, this is an extension of the numbering scheme defined in > G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the = same > signaling scheme is used in order to provide easy interworkign = between > SDH and SONET signaling. For the S field a STS-3 group,which > corresponds with the SDH AUG-1 level is introduce. The U field > indicates > the position of the STS-3c-SPE or STS-1-SPE within the STS-3 > group. The K > field is not significant for SONET as it doesn't support = structured > STS-3c-SPEs and must be set to zero. > > Each letter indicates a possible branch number starting at the > parent node in the multiplex structure. Branches are considered as > numbered in increasing order, starting from the top of the > multiplexing structure. The numbering starts at 1, zero is used to > indicate a non-significant field. > > When a field is not significant in a particular context it MUST be > set to zero when transmitted, and MUST be ignored when received. > > When hierarchical SDH/SONET LSPs are used, an LSP with a given > bandwidth can be used to tunnel lower order LSPs. The higher > order SDH/SONET LSP behaves as a virtual link with a given > bandwidth (e.g. VC-3), it may also be used as a Forwarding > Adjacency. A lower order SDH/SONET LSP can be established through > that higher order LSP. Since a label is local to a (virtual) link, > the highest part of that label is non-significant and is set to > zero. > > For instance, a VC-3 LSP can be advertised as a forwarding > adjacency. In that case the labels allocated between the two ends > of that LSP (i.e. for that "link") will have S, U and K set to > zero, i.e., non-significant, while L and M will be used to > indicate the signal allocated in that VC-3. > > 1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 = group, > and S=3DN indicates the last AUG-1/STS-3 group of this = multiplex. > S is not significant for STM-0/STS-1. > > 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 > group or STM-0/STS-1. U=3D1 indicates a single VC-4/STS-3c-SPE = in a > AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, > while U=3D2->4 > indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 > group. > > 3. K is only significant for SDH VC-4 and must be ignored for > SONET and SDH HOVC-3. It indicates a specific branch of a VC-4. > K=3D1 indicates that the VC-4 is not further subdivided and > contains a C-4. K=3D2->4 indicates a specific TUG-3 inside the = VC- > 4. K is not significant when the AUG-1 is divided into AU-3s > (easy to read and test). > > 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. > It is not significant for an unstructured VC-4 or VC-3/STS-1 = SPE. L=3D1 > indicates that the TUG-3/VC-3/STS-1 SPE is not further > subdivided and contains a VC-3/C-3 in SDH or the equivalent in > SONET. L=3D2->8 indicates a specific TUG-2/VT Group inside the > corresponding higher order signal. > > 5. M indicates a specific branch of a TUG-2/VT Group. It is not > significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. > M=3D1 indicates that the TUG-2/VT Group is not further = subdivided > and contains a VC-2/VT-6 SPE. M=3D2->3 indicates a specific VT-3 > inside the corresponding VT Group, these values MUST NOT be used > for SDH since there is no equivalent of VT-3 with SDH. M=3D4->6 > indicates a specific VC-12/VT-2 SPE inside the corresponding > TUG-2/VT Group. M=3D7->10 indicates a specific VC-11/VT-1.5 SPE > inside the corresponding TUG-2/VT Group. Note that M=3D0 denotes > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). > > > The M encoding is summarized in the following table: > > M SDH SONET > ---------------------------------------------------------- > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE > 1 VC-2 VT-6 > 2 - 1st VT-3 > 3 - 2nd VT-3 > 4 1st VC-12 1st VT-2 > 5 2nd VC-12 2nd VT-2 > 6 3rd VC-12 3rd VT-2 > 7 1st VC-11 1st VT-1.5 > 8 2nd VC-11 2nd VT-1.5 > 9 3rd VC-11 3rd VT-1.5 > 10 4th VC-11 4th VT-1.5 > > In case of contiguous concatenation, the label that is used is the > lowest label of the contiguously concatenated signal as explained > before. The higher part of the label indicates where the signal > starts and the lowest part is not significant. For instance, when > requesting an STS-48c the label is S>0, U=3D0, K=3D0, L=3D0, = M=3D0. > > Examples of labels: > > Example 1: S>0, U=3D1, K=3D1, L=3D0, M=3D0 > Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 = group. > > Example 2: S>0, U=3D1, K>1, L=3D1, M=3D0 > Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. > > Example 3: S>0, U>1, K=3D0, L=3D0, M=3D0 > Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth > AUG-1/STS-3 group. > > Example 4: S>0, U>1, K=3D0, L>1, M=3D1 > Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth = VC-3/STS-1 > SPE of the Sth AUG-1/STS-3 group. > > Example 5: S>0, U>1, K=3D0, L>1, M=3D9 > Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth > VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. > > Example 6: S>0, U=3D1, K>1, L>1, M=3D5 > Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the = VC-4 of > the Sth AUG-1. > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > > Gesendet: Donnerstag, 18. Oktober 2001 18:58 > > An: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > > Betreff: RE: Moving right along ... > > > > > > Hello Juergen, > > > > Your comments are addressed hereafter. Note that you didn't raised = any > > technical problem or mistake in your comments (i.e. the draft > "works" very > > well as it is). > > > > - the first comment is not about a technical issue but an > > "editorial" issue. > > - the second comment is about a change that will not bring any new > > capability. > > > > >Concerning the SDH/Sonet documents I want to raise a formal issue. > > >We have now two documents, a document that covers ITU/ANSI = standard > > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document = that > > covers non-standard features > > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in > > Appendix 1 > > of the standard feature document a non standard feature (Group > signals) is > > listed. It is even mentioned that the use of groups (AUG, STSG, > > ...) is not > > described in standards. So this feature should be moved to the > > non-standards > > document. Otherwise the split of the documents doesn't make sense. > > > > We spend a considerable amount of time speaking about this > > particular issue > > and I still don't see any technical justification for what you = said. > > > > For those who are not SDH/SONET experts some quick explanation: > > > > We call a "super-circuit" a set of physical circuits in the > > transport plane > > all belonging to the same LSP in the signaling plane. We > defined two kinds > > of super-circuits: "group circuits" and "multiplicative circuits". > > > > Multiplicative circuits are setup using the multiplier field that > > we defined > > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no > > objection > > about these ones. > > > > Group circuits are setup using the SDH/SONET naming for groups, > i.e. AUG, > > TUG, VTG (we defined the equivalent signal type in the signaling). = The > > comment of Juergen is about these group circuits. A group circuit > > represents > > some bandwidth at a given place in the SDH/SONET multiplex. The > > advantage of > > such a super-circuit is that the customer can re-structure its > content as > > he/she likes. The operator doesn't care. > > > > Such an application is possible and is already implemented. = SDH/SONET is > > self-describing, i.e. by looking at the signal one can understand > > how it is > > structured (like Juergen explained on the mailing list), so one > > can setup a > > circuit without describing the content (very very cool). > > > > The transport plane ignores that the signaling plane uses an > "abstraction" > > (i.e. an LSP) representing several physical circuits. Note that > > restoration > > and management belong respectively to the signaling plane and to = the > > management plane in the IETF view (not to the transport plane > like in the > > ITU-T view). > > > > From that point of view, group circuits are a GMPLS signaling > > plane feature > > and not a transport plane feature. We put the comment on the fact > > that this > > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys = happy. > > > > I could say clearly at the beginning of the draft that the signal > > types that > > we are defining in this document are not ITU-T signal types but > > GMPLS signal > > types (of course) whose have in some cases a direct > relationship with the > > ITU-T signal types. > > > > Any objection ? > > > > >For the Sonet and SDH labels in > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I > > prefer to have the same coding for Sonet and SDH. That makes the > > implementation for Sonet and SDH simpler. Furthermore ITU and T1 > > have tried > > over the last years to align Sonet and SDH as much as possible. The > > definition of different labels for Sonet and SDH contradicts these > > activities. > > > > We discussed this one since a long time as well. Let me be clear: > > > > - labels are local to an interface (we all agree). > > - a link (interface) is operated at one point in the time as > either SDH or > > SONET. > > - your proposal will require to re-evaluate many things. > > - and it took us a lot of time to fine-tune and to validate the = current > > label structure. > > - we could have technical issues with your proposal that would > impact more > > than this draft (Dimitri saw some of them, please see with him). > > - you never provided a complete analysis of your proposal. > > > > But more important: your proposal doesn't bring any additional > > functionality > > to the draft. > > > > At this very late stage, since this not bringing any new > > functionality, and > > since the label structure is very stable since a long time, I > would prefer > > not to restart a long technical discussion to change and = re-validate the > > draft. > > > > Kind regards, > > > > Eric > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > > > An: ccamp@ops.ietf.org > > > Betreff: Moving right along ... > > > > > > > > > Despite the energetic subject line, we the WG chairs have been > > > lax in our duties. So, here goes: > > > > > > Lou has submitted the latest versions of the generalized > > > signaling documents quite some time ago (thanks, Lou): > > > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > > draft-ietf-mpls-generalized-signaling-06.txt > > > > > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > > > All of these should have addressed the issues raised in the = earlier > > > versions. Please read the new versions, and send your comments = to > > > the list by Tuesday Oct 23. At that point, when the final round > > > of comments have been addressed, these docs will go to IESG Last > > > Call. If any one objects to sending these docs to IESG Last = Call, > > > raise your issues now. > > > > > > I see that the GMPLS architecture document is a CCAMP WG doc, but > > > the minutes say that we should look for consensus on the list. = So, > > > if you think this doc *shouldn't* be a WG doc, let us know. (If = we > > > arrived at a consensus, remind me :-)) If nothing is heard, the = doc > > > will progress to WG Last Call. > > > > > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt = and > > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to = be > > > CCAMP WG docs; consensus at the meeting was Yes. Please let the > > > list know what your thinking is on these. (BTW, both these docs > > > were to have some edits done. If the authors could do that = before > > > the next IETF, we can try to make more progress then.) > > > > > > The MIB overview doc was recently posted. Please read and = comment > > > to the list. > > > > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > was generally thought to be useful; it will be published as a > > > CCAMP informational doc. This begins a two week Last Call on > > > the doc, ending Tuesday Oct 30. > > > > > > There was no consensus on whether the GMPLS framework should be > > > a CCAMP WG doc. Please indicate your pleasure. > > > > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > > raised that this draft is close to ready for WG Last Call. = Please > > > review it, and let us know if you disagree. > > > > > > The OLI requirements doc was broadly accepted. Please let the > > > list know if you think this doc should be a WG doc. > > > > > > It's still open whether we (the IETF) should be working on > > > LMP-WDM. I urge the authors to keep on working on the doc, and > > > keeping it in sync with LMP; however, we will postpone making it > > > a CCAMP WG doc until the issue is resolved. Hopefully that will > > > happen in Salt Lake City. > > > > > > There was reasonable interest in the tunnel trace requirements > > > doc. Let's formalize this: do you think this should be made a > > > CCAMP WG document? > > > > > > Summary: > > > > > > 1) Final comments and IESG Last Call readiness for: > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > > draft-ietf-mpls-generalized-signaling-06.txt > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > > > 2) Should the following documents be CCAMP WG docs? > > > draft-bonica-tunneltrace-02.txt > > > draft-fontana-ccamp-gmpls-g709-00.txt > > > draft-ietf-ccamp-gmpls-architecture-00.txt > > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > > draft-many-ccamp-gmpls-framework-00.txt > > > draft-many-oli-reqts-00.txt > > > > > > 3) Comment on MIB overview. > > > > > > 4) Two week Last Call comments on > > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > > > 5) Last Call readiness of > > > draft-ietf-ccamp-gmpls-architecture-00.txt > > > draft-ietf-ccamp-lmp-01.txt > > > > > > Thanks, > > > Kireeti. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 06:58:50 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBAE@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'shehzad.mirza@bt.com'" , yakov@juniper.net Cc: ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 09:55:19 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15BCA.5A2A5650" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15BCA.5A2A5650 Content-Type: text/plain; charset="iso-8859-1" All, I am in full agreement with Shehzad. From a carrier's perspective, the value of the control plane is in taking over specific functions which currently reside in OSSs outside of the network itself. Having only some applications, but not others of the given function move into the network greatly diminishes the value of having that function supported in the control plane. To be more specific, if out of n services supported by the transport network, the control plane supports automated provisioning of 1/2n services and the other 1/2n need support in the OSS, we still need to do the OSS work for the given transport technology. So from a cost perspective, now we have to ask ourselves whether we should pay for the provisioning function twice. Regards, Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] Sent: Tuesday, October 23, 2001 6:25 AM To: yakov@juniper.net Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Yakov, See comments in-line > -----Original Message----- > From: Yakov Rekhter [SMTP:yakov@juniper.net] > Sent: 22 October 2001 21:12 > To: Lazer, Monica A, NNAD > Cc: ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > Monica, > > > Dimitri, > > Actually, it may be more accurate to put it differently - if GMPLS > supports > > only a handful of the services running on a given transport network, > than > > its value as a network's control plane component is diminished. > > To be even more accurate, GMPLS value is diminished *in the context* > of that particular transport network. And unless *all* providers > are going to run *all possible services* on their transport networks > (which is a somewhat unrealistic scenario), that means that the > value of GMPLS as a network's control plane component would be > diminished for *some*, but not *all* service providers. > > > [shehzad] For a control plane not to support all the transport services capable of being carried over an operator's network diminishes the value of that particular control plane. What is the point of having transparent/optical equipment capable of transporting both Gigabit Ethernet and Fiber Channel (as an example), if provisioning was based on signalling that could only support Gigabit Ethernet? This is a restriction for every provider regardless of whether a network is a standalone one built for a large customer or a national network serving multiple customers. The effective 'banning' of certain services that are currently being offered by providers will unnecessarily damage the business case for the adoption of GMPLS. > At the same time, it is important to keep in mind that being "all > things for all people" (aka as "perfect solution") is one of the > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > *particular* provider GMPLS would *not* support *all* the services > that this provider runs on its transport network. > > Yakov. > > [Shehzad] There is no technical reason why a GMPLS encoding type could not be adopted for a recognised format such as Fiber Channel, as far as I am aware the adoption of Fiber Channel is not likely to destroy the foundations of GMPLS. On a more general point, is the support of transport technologies within GMPLS signalling restricted to those that the authors of the GMPLS drafts will allow? > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > > > -----Original Message----- > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 3:15 PM > > To: Lazer, Monica A, NNAD > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > Fine. Now we know the following: GMPLS is really attractive for > > carriers when it supports all transport technologies so it has > > to support Fiber Channel as well. > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > Regards, > > Dimitri. > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > Dimitri, > > > I am just answering the PS question with this message. > > > The short answer is yes. The long answer is that the GMPLS control > plane > > is > > > really useful if it can support connection management for all the > > transport > > > services supported by the transport network using GMPLS. Therefore, > the > > > carrier services section for the NNI document to be posted on the OIF > site > > > within a few minutes and the next draft of the carrier requirements > IETF > > > draft will both contain references to support of Fiber Channel. > > > Regards, > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 2:47 PM > > > To: Ewart Tempest > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type > expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > If you take a look on the IEEE Standards you will see > > > that GE is referred to as > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > So my question is what do you have in mind ? to separate > > > these values ? > > > > > > Thanks, > > > Dimitri. > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > ------- > > > > > > [1] From - http://standards.ieee.org > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > augmentation of its operation, physical layer characteristics, > repeater > > > functions and management parameters for transfer of 802.3 and Ethernet > > > format frames at 1,000 Mb/s. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of CSMA/CD nodes, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > [2] From - http://standards.ieee.org > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > minimal augmentation of its operation, physical layer characteristics > > > and management parameters for transfer of LLC and Ethernet format > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > standard. In addition to the traditional LAN space, add parameters and > > > mechanisms that enable deployment of Ethernet over the Wide Area > Network > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > payload > > > rate. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > application space to include Wide Area Network links in order to > provide > > > a significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of 802.3 interfaces, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > ------- > > > > > > > Ewart Tempest wrote: > > > > > > > > Lou, > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > GE is not really covered by the existing Ethernet related encoding > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > Ewart > > ------_=_NextPart_001_01C15BCA.5A2A5650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Generalized Signaling - LSP Encoding Type expansion

All,
I am in full agreement with Shehzad. From a = carrier's perspective, the value of the control plane is in taking over = specific functions which currently reside in OSSs outside of the = network itself. Having only some applications, but not others of the = given function move into the network greatly diminishes the value of = having that function supported in the control plane. To be more = specific, if out of n services supported by the transport network, the = control plane supports automated provisioning  of 1/2n services = and the other 1/2n need support in the OSS, we still need to do the OSS = work for the given transport technology. So from a cost perspective, = now we have to ask ourselves whether we should pay for the provisioning = function twice.

Regards,

Monica A. Lazer
Advanced Transport Technology and Architecture = Planning

908 234 8462
mlazer@att.com


 -----Original Message-----
From:   shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com] =
Sent:   Tuesday, October 23, 2001 6:25 = AM
To:     yakov@juniper.net
Cc:     Lazer, Monica A, NNAD; = ccamp@ops.ietf.org
Subject:        = RE: Generalized Signaling - LSP Encoding Type expansion

Yakov,

See comments in-line

> -----Original Message-----
> From: Yakov Rekhter = [SMTP:yakov@juniper.net]
> Sent: 22 October 2001 21:12
> To:   Lazer, Monica A, NNAD
> Cc:   ccamp@ops.ietf.org
> Subject:      Re: = Generalized Signaling - LSP Encoding Type expansion
>
> Monica,
>
> > Dimitri,
> > Actually, it may be more accurate to put = it differently - if GMPLS
> supports
> > only a handful of the services running on = a given transport network,
> than
> > its value as a network's control plane = component is diminished.
>
> To be even more accurate, GMPLS value is = diminished *in the context*
> of that particular transport network. And = unless *all* providers
> are going to run *all possible services* on = their transport networks
> (which is a somewhat unrealistic scenario), = that means that the
> value of GMPLS as a network's control plane = component would be
> diminished for *some*, but not *all* service = providers.
>
>
>
        [shehzad] 
For a control plane not to support all the transport = services capable of
being carried over an operator's network diminishes = the value of that
particular control plane.  What is the point of = having transparent/optical
equipment capable of transporting both Gigabit = Ethernet and Fiber Channel
(as an example), if provisioning was based on = signalling that could only
support Gigabit Ethernet?

This is a restriction for every provider regardless = of whether a network is
a standalone one built for a large customer or a = national network serving
multiple customers. The effective 'banning' of = certain services that are
currently being offered by providers will = unnecessarily damage the business
case for the adoption of GMPLS.



> At the same time, it is important to keep in = mind that being "all
> things for all people" (aka as = "perfect solution") is one of the
> *non-goals* of GMPLS. So, it shouldn't come as = a surprise if for a
> *particular* provider GMPLS would *not* support = *all* the services
> that this provider runs on its transport = network.
>
> Yakov.
>
>
        [Shehzad]
        There is = no technical reason why a GMPLS encoding type could not be
adopted for a recognised format such as Fiber = Channel, as far as I am aware
the adoption of Fiber Channel is not likely to = destroy the foundations of
GMPLS.

        On a more = general point, is the support of transport technologies
within GMPLS signalling restricted to those that the = authors of the GMPLS
drafts will allow?
         =





> > Monica A. Lazer
> > Advanced Transport Technology and = Architecture Planning
> >
> > 908 234 8462
> > mlazer@att.com
> >
> >
> >  -----Original Message-----
> > From:       = Dimitri Papadimitriou
> [mailto:dimitri.papadimi= triou@alcatel.be]
> 
> > Sent:       = Monday, October 22, 2001 3:15 PM
> > To: Lazer, Monica A, NNAD
> > Cc: Ewart Tempest; lberger@movaz.com; = ccamp@ops.ietf.org
> > Subject:    Re: Generalized = Signaling - LSP Encoding Type expansion
> >
> >  << File: Card for Dimitri = Papadimitriou >> Hi Monica,
> >
> > Fine. Now we know the following: GMPLS is = really attractive for
> > carriers when it supports all transport = technologies so it has
> > to support Fiber Channel as well.
> >
> > I wasn't aware that Ewart was capable to = read in your mind ;-)
> >
> > Regards,
> > Dimitri.
> >
> > "Lazer, Monica A, NNAD" = wrote:
> > >
> > > Dimitri,
> > > I am just answering the PS question = with this message.
> > > The short answer is yes.  The = long answer is that the GMPLS control
> plane
> > is
> > > really useful if it can support = connection management for all the
> > transport
> > > services supported by the transport = network using GMPLS. Therefore,
> the
> > > carrier services section for the NNI = document to be posted on the OIF
> site
> > > within a few minutes and the next = draft of the carrier requirements
> IETF
> > > draft will both contain references to = support of Fiber Channel.
> > > Regards,
> > > Monica A. Lazer
> > > Advanced Transport Technology and = Architecture Planning
> > >
> > > 908 234 8462
> > > mlazer@att.com
> > >
> > >  -----Original = Message-----
> > > From:   Dimitri = Papadimitriou
> [mailto:dimitri.papadimi= triou@alcatel.be]
> > > Sent:   Monday, October 22, = 2001 2:47 PM
> > > To:     Ewart = Tempest
> > > Cc:     = lberger@movaz.com; ccamp@ops.ietf.org
> > > = Subject:        Re: Generalized = Signaling - LSP Encoding Type
> expansion
> > >
> > >  << File: Card for Dimitri = Papadimitriou >> Hi Ewart,
> > >
> > > If you take a look on the IEEE = Standards you will see
> > > that GE is referred to as
> > > - 802.3z for 1Gbps (see below [1]) = same exists for copper 802.3ab
> > > - 802.3ae for 10Gbps (see below = [2])
> > >
> > > So my question is what do you have in = mind ? to separate
> > > these values ?
> > >
> > > Thanks,
> > > Dimitri.
> > >
> > > PS: for FiberChannel sorry i am not = an expert but is someone
> > >     targeting to = use GMPLS for FiberChannel LSP ?
> > >
> > > -------
> > >
> > > [1] From - http://standards.ieee.org
> > >
> > > Project scope: Define Carrier Sense = Multiple Access with Collision
> > > Detection (CSMA/CD) Media Access = Control (MAC) parameters and minimal
> > > augmentation of its operation, = physical layer characteristics,
> repeater
> > > functions and management parameters = for transfer of 802.3 and Ethernet
> > > format frames at 1,000 Mb/s.
> > >
> > > Project purpose: The purpose of this = project is to extend the 802.3
> > > protocol to an operating speed of = 1,000 Mb/s in order to provide a
> > > significant increase in bandwidth = while maintaining maximum
> > > compatibility
> > > with the installed base of CSMA/CD = nodes, previous investment in
> > > research
> > > and development, and principles of = network operation and management.
> > >
> > > [2] From - http://standards.ieee.org
> > >
> > > Project scope: Define 802.3 Media = Access Control (MAC) parameters and
> > > minimal augmentation of its = operation, physical layer characteristics
> > > and management parameters for = transfer of LLC and Ethernet format
> > > frames at 10 Gb/s using full duplex = operation as defined in the 802.3
> > > standard. In addition to the = traditional LAN space, add parameters and
> > > mechanisms that enable deployment of = Ethernet over the Wide Area
> Network
> > > operating at a data rate compatible = with OC-192c and SDH VC-4-64c
> > > payload
> > > rate.
> > >
> > > Project purpose: The purpose of this = project is to extend the 802.3
> > > protocol to an operating speed of 10 = Gb/s and to expand the Ethernet
> > > application space to include Wide = Area Network links in order to
> provide
> > > a significant increase in bandwidth = while maintaining maximum
> > > compatibility
> > > with the installed base of 802.3 = interfaces, previous investment in
> > > research
> > > and development, and principles of = network operation and management.
> > >
> > > -------
> > >
> > > > Ewart Tempest wrote:
> > > >
> > > > Lou,
> > > >
> > > > Within section 3.1.1 of = draft-ietf-mpls-generalized-signaling-06 can
> > > > you please add additonal LSP = Encoding Types for GE and FiberChannel.
> > > > GE is not really covered by the = existing Ethernet related encoding
> > > > types, and FiberChannel is not = covered at all. Thanks.
> > > >
> > > > Ewart
> >

------_=_NextPart_001_01C15BCA.5A2A5650-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 06:13:39 -0700 Message-Id: <4.3.2.7.2.20011023091250.0243de48@bucket.cisco.com> Date: Tue, 23 Oct 2001 09:13:26 -0400 To: "Wijnen, Bert (Bert)" From: Thomas Nadeau Subject: Re: the LMP mib Cc: ccamp-wg Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_86702211==_.ALT" --=====================_86702211==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Bert, >Just a very quick reaction (better to alert you at rev 00 than >later). Thanks for the review. We will clean things up in the next revision. --Tom >- You have picked up an old template for section 4. > It references obsolted RFCs. Pls use latest one >- Section 4.1 is redundant and can be removed. >- Remove "using SMIv2" from the title. > We have been using SMIv2 for 5 years or so. This > "Using SMIv2" was customary when we had SMIv1 > as the standard tool. These days SMIv2 is mandatory >- Why is the abstract and the 1st para of the intro (just > underneath each other) exactly the same? >- sect 9. DO not talk about interfaces group of MIB II. > Instead just stick to IFMIB (RFC2863) >- You are importing/using IpAddress. > CANNOT do that. Pls use TCs from RFC2851, or better > from the update that is being done right now. >- REVISION clause(s). In the end, when this MIB is first > published as RFC, we only want one simple revision > clause, aka: > REVISION "yyyymmddhhmmZ" > DESCRIPTION "Initial version, published as RFC xxxx" > -- xxxx to be assigned by RFC Editor. > All the changes made during InternetDraft stages are > nice for the WG, but not really interesting once we publish. > You can put them in an appendix till doc goes to RFC-Editor >- lmpNbrNodeId OBJECT-TYPE > SYNTAX NodeID > MAX-ACCESS accessible-for-notify > STATUS current > This is an INDEX object... should be not-accessible! >- STorageType object needs to describe which objects > (if any) must be writable when the StorageType is permanent >- RowStatus object needs to describe which objects (if any) > can be modified when the status is active. >- I do not see a reference to any discontinuity object in you > counter32/counter64 objects. Is there no potential for > discontinuity, otehr than at restart of the SNMP agent? > I guess there is, because you do have such an object >- In general, I would just talk about "notifications" and not > about traps. A notification can be send as a trap or as > an inform, but that is under control of the MIB(s) in > RFC2573. >- I would like to see 2 conformance statements: > > lmpMIBFullConformance which allow READ/Create, so that it > can be used for configuration and > monitoring. > lmpMIBReadOnlyCompliance which is more or less the one you > have now and which allows for just > minitoring. > > >- In the security section, can you add some words about which objects > contain sensitive information and why? That would be usefull for > users so they can determine how serious they have to excercise > access control. > >Just a quick sniff. >Bert >Bert ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_86702211==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Bert,

Just a very quick reaction (better to alert you at rev 00 than
later).

        Thanks for the review. We will clean things up in
the next revision.

        --Tom


        
- You have picked up an old template for section 4.
  It references obsolted RFCs. Pls use latest one
- Section 4.1 is redundant and can be removed.
- Remove "using SMIv2" from the title.
  We have been using SMIv2 for 5 years or so. This
  "Using SMIv2" was customary when we had SMIv1
  as the standard tool. These days SMIv2 is mandatory
- Why is the abstract and the 1st para of the intro (just
  underneath each other) exactly the same?
- sect 9. DO not talk about interfaces group of MIB II.
  Instead just stick to IFMIB (RFC2863)
- You are importing/using IpAddress.
  CANNOT do that. Pls use TCs from RFC2851, or better
  from the update that is being done right now.
- REVISION clause(s). In the end, when this MIB is first
  published as RFC, we only want one simple revision
  clause, aka:
    REVISION "yyyymmddhhmmZ"
    DESCRIPTION "Initial version, published as RFC xxxx"
    -- xxxx to be assigned by RFC Editor.
  All the changes made during InternetDraft stages are
  nice for the WG, but not really interesting once we publish.
  You can put them in an appendix till doc goes to RFC-Editor
- lmpNbrNodeId OBJECT-TYPE
   SYNTAX        NodeID
   MAX-ACCESS    accessible-for-notify
   STATUS        current
  This is an INDEX object... should be not-accessible!
- STorageType object needs to describe which objects
  (if any) must be writable when the StorageType is permanent
- RowStatus object needs to describe which objects (if any)
  can be modified when the status is active.
- I do not see a reference to any discontinuity object in you
  counter32/counter64 objects. Is there no potential for
  discontinuity, otehr than at restart of the SNMP agent?
  I guess there is, because you do have such an object
- In general, I would just talk about "notifications" and not
  about traps. A notification can be send as a trap or as
  an inform, but that is under control of the MIB(s) in
  RFC2573.
- I would like to see 2 conformance statements:
 
  lmpMIBFullConformance which allow READ/Create, so that it
                        can be used for configuration and
                        monitoring.
  lmpMIBReadOnlyCompliance which is more or less the one you
                           have now and which allows for just
                           minitoring.

  
- In the security section, can you add some words about which objects
  contain sensitive information and why? That would be usefull for
  users so they can determine how serious they have to excercise
  access control.

Just a quick sniff.
Bert
Bert



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_86702211==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 06:02:07 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0DC4FA07@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Subject: the LMP mib Date: Tue, 23 Oct 2001 14:59:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Just a very quick reaction (better to alert you at rev 00 than later). - You have picked up an old template for section 4. It references obsolted RFCs. Pls use latest one - Section 4.1 is redundant and can be removed. - Remove "using SMIv2" from the title. We have been using SMIv2 for 5 years or so. This "Using SMIv2" was customary when we had SMIv1 as the standard tool. These days SMIv2 is mandatory - Why is the abstract and the 1st para of the intro (just underneath each other) exactly the same? - sect 9. DO not talk about interfaces group of MIB II. Instead just stick to IFMIB (RFC2863) - You are importing/using IpAddress. CANNOT do that. Pls use TCs from RFC2851, or better from the update that is being done right now. - REVISION clause(s). In the end, when this MIB is first published as RFC, we only want one simple revision clause, aka: REVISION "yyyymmddhhmmZ" DESCRIPTION "Initial version, published as RFC xxxx" -- xxxx to be assigned by RFC Editor. All the changes made during InternetDraft stages are nice for the WG, but not really interesting once we publish. You can put them in an appendix till doc goes to RFC-Editor - lmpNbrNodeId OBJECT-TYPE SYNTAX NodeID MAX-ACCESS accessible-for-notify STATUS current This is an INDEX object... should be not-accessible! - STorageType object needs to describe which objects (if any) must be writable when the StorageType is permanent - RowStatus object needs to describe which objects (if any) can be modified when the status is active. - I do not see a reference to any discontinuity object in you counter32/counter64 objects. Is there no potential for discontinuity, otehr than at restart of the SNMP agent? I guess there is, because you do have such an object - In general, I would just talk about "notifications" and not about traps. A notification can be send as a trap or as an inform, but that is under control of the MIB(s) in RFC2573. - I would like to see 2 conformance statements: lmpMIBFullConformance which allow READ/Create, so that it can be used for configuration and monitoring. lmpMIBReadOnlyCompliance which is more or less the one you have now and which allows for just minitoring. - In the security section, can you add some words about which objects contain sensitive information and why? That would be usefull for users so they can determine how serious they have to excercise access control. Just a quick sniff. Bert Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 04:53:56 -0700 Message-ID: From: "Mannie, Eric" To: 'Dimitri Papadimitriou' , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Tue, 23 Oct 2001 13:49:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Manoj, Manoj: >> 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table >> as an addendum to the draft. Dimitri: >This would apply to the SDH/Sonet document ... however i see it more >adapted to the "SDH/Sonet framework" one. Personally i think that in >such I-D it can be useful (please contact Eric for that purpose) and >so i think we are in agreement here. I agree with Dimitri. Note also that EDCBA is a notation convention used in G.707 to help the reader, this is not transported by any overhead. So this conversion table doesn't belong to the protocol work but more the explanatory work. Manoj: >> 4. As per OIF, the carrier requirement is that SDH LSPs should be >> either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS >> supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS >> has different set of carrier requirements in this regard ? > Dimitri: >The I-D is covering HO/STS SPE and LOVC/VT for completeness (as described in G.707 ANSI T1.105), OIF UNI 1.0 uses a subset. Why not. Right, GMPLS is a tool box. From that perspective, the OIF chosen to use some tools and not others. It was very very easy to cover the LOVC/VT case. It doesn't mean that it must be implemented. Don't forget that a core switch is nothing without metro and edge switches and that carriers need end-to-end signaling (between customer access points) if they really want to take benefit of the control plane (for restoration, etc). What is the use of a control plane for SDH/SONET that stops at the edge of the core, without going to the metro ? It is quite limited. Manoj: > 2. Usage of Label Set : > There are cases mentioned in the draft which explains the usage > of label set. It should also mention that the range of labels in > SDH/SONET does not make sense. I don't think so. Sometimes you have tools that you don't need now but that could be useful for future usage. The label set is a very rich tool that could be used for SONET/SDH as well. There is no need today to restrict its usage to all optical applications only. Indeed, there are two different design approaches that can be compared: either you design an open protocol, or a closed protocol. We chosen to design an open protocol and this is consistent with the toolbox approach. We didn't want to completely limit everything from time zero. This gives room for growth and future developments. Another approach is the closed one, this was many times defended by some ITU-T folks. E.g. to say for each field "this field is not applicable to and to .... and to ... and to...", or "this range is limited to....". In that case you block everything. It is better to say "this field can be used for.... and the current values are....", then somebody else could use that "tool" for an additional purpose in the future. Don't close the door too quickly at this stage, certainly when you don't need to close the door. If you completely close the door, then GMPLS will be very difficult to extend and will stop to be a toolbox. GMPLS is not an architecture that can be applied as such, it needs a profile for each particular application. If someone read it, thinking: "I will know exactly what my GMPLS control plane for SDH/SONET needs to implement", he/she is completely missing the point and will be very confused. Kind regards, Eric -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Sunday, October 21, 2001 1:57 PM To: manoj juneja Cc: zwlin@lucent.com; kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: Moving right along ... Hi Manoj, My previous e-mail was a generic one, not only focused on your question concerning the conversion table. I personally think the following on this issue: > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table > as an addendum to the draft. This would apply to the SDH/Sonet document ... however i see it more adapted to the "SDH/Sonet framework" one. Personally i think that in such I-D it can be useful (please contact Eric for that purpose) and so i think we are in agreement here. Here the response to your other questions: > 1. Can someone please tell me the usage of bandwidth encoding > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > will be drived from the signal type field. How the bandwidth encoding > type will be interpreted in case of other LSP encoding types (lambda, > waveband, fiber etc) ? The draft should list down the cases in which > the bandwidth encoding type is to be filled. To which I-D do you refer here, in GMPLS-SIG this is well explained. For the SDH/Sonet one, we had this discussion sometime ago and the outcome was to "un-use" this value (even if i don't think it is the best solution but since discussion brought us to more complexity...) Remember that the resulting bandwidth is dependent on the application of the different field on the elementary Signal Type resulting in a final signal. Anyway, if it has to be detailed it would be in the SDH/Sonet and other technology dependent ones. > 2. Usage of Label Set : > There are cases mentioned in the draft which explains the usage > of label set. It should also mention that the range of labels in > SDH/SONET does not make sense. Ranges in label set are applicable in > case of waveband/lambda switching etc. The range in label set is valid > in SDH/SONET only if there is one element in the range i.e. start range > and end range should be same. Is it a question or an assertion ? I refer you also here to my previous e-mail > 3. There are couple of scenarios where there can be contention for > establishing bi-directional LSPs. All the scenarios are not listed in > the document. If it is not possible to list all the scenarios then the > draft should say that this is one of the example scenario. The > contention can also be possible in case where same label set and > upstream label are used in both the directions. This has been extensively discussed on this mailing list i am referring you to the outcome of this discussion > 4. As per OIF, the carrier requirement is that SDH LSPs should be > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS > has different set of carrier requirements in this regard ? The I-D is covering HO/STS SPE and LOVC/VT for completeness (as described in G.707 ANSI T1.105), OIF UNI 1.0 uses a subset. Why not. > 6. The relation between switching capability and LSP encoding type > should be clearly explained in the drafts. As the switching capability > field was added very late (just 2 months back) in the drafts, > specific reason should be mentioned for its addition. ... ? re-phrasing one of the remarks i saw this week can be applied here we are not discussing "requirement" document here Hope this will help you, Regards, Dimitri. manoj juneja wrote: > > Hi Dimitri, > I don't think there is any issue in including the > conversion table in the draft. Even this table can be kept in some > informational draft. The inclusion of conversion table is a valid thing and > probably nobody on ccamp mailing list would like oppose. I > still didn't get answers to other points in my mail. > > Regards, > manoj. > > >From: Dimitri Papadimitriou > >To: Zhi-Wei Lin > >CC: manoj juneja , kireeti@juniper.net, > >ccamp@ops.ietf.org > >Subject: Re: Moving right along ... > >Date: Sat, 20 Oct 2001 16:05:01 +0200 > > > >Hi Zhi, > > > >I would like to remember you something here: the SDH/Sonet I-D is not > >1) a textbook on how to use GMPLS-SIG but must be understood an > > additional document complementing the signalling one > >2) a tutorial on Sonet/SDH (a framework has been proposed for that > > purpose) > > > >We have spent hard time together with the SDH/Sonet I-D co-authors in > >order to find the best balance between reproducing well known SDH/Sonet > >concepts and paragraphs really providing an added value in this document > > > >Of course we can not make 100% people happy (even between the list of > >30 co-authors) some of us found there was too much explanations while > >others were requesting more content. > > > >Therefore for the non-covered content we are referencing the appropriate > >document either it comes from ITU or IETF. Please understand that we > >can not wait until everybody in this world has no question anymore or a > >full understanding on any technical detail in order to go forward with > >these documents. > > > >Thanks for your "virtual" understanding, > >Dimitri. > > > >Zhi-Wei Lin wrote: > > > > > > Hi Manoj, > > > > > > I agree with many of your points. I actually submitted an I-D several > > > months ago (I think it's expired) that proposes some text to add to the > > > GMPLS SONET/SDH on the rules for setting different values, such as for > > > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the > > > range of acceptable value of X, etc. > > > > > > My rationale at that time was that not everyone is a SONET/SDH expert > > > and instead of asking them to look somewhere else and dig through those > > > documents to find the answer, if we can provide them in the GMPLS set of > > > drafts it would be extremely useful for the entire IETF community and > > > would help clarify the usage of these parameters. But unfortunately if > > > you were at the meeting at the time, it wasn't accepted because some > > > folks thought that these were obvious or that this info is not needed > > > because they can find it in other places referenced... > > > > > > If you have the old drafts, the file was: > > > draft-lin-ccamp-ipo-common-label-request-01 > > > > > > But anyway...people will just have to read all the referenced documents > > > to understand how to use the different parameters... > > > > > > Zhi > > > > > > manoj juneja wrote: > > > > > > > Hi Kireeti, > > > > I am not an active member of IETF but a regular reader of > > > > GMPLS drafts. I am not sure how much weight my mail will carry but as > >a > > > > regular reader of these drafts, I recommend the following points > >should > > > > be made clear in the documents before proceeding to the last call. > > > > > > > > > > > > 1. Can someone please tell me the usage of bandwidth encoding > > > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > > > > will be drived from the signal type field. How the bandwidth encoding > > > > type will be interpreted in case of other LSP encoding types (lambda, > > > > waveband, fiber etc) ? The draft should list down the cases in which > >the > > > > bandwidth encoding type is to be filled. > > > > > > > > 2. Usage of Label Set : > > > > There are cases mentioned in the draft which explains the usage > > > > of label set. It should also mention that the range of labels in > > > > SDH/SONET does not make sense. Ranges in label set are applicable in > > > > case of waveband/lambda switching etc. The range in label set is valid > > > > in SDH/SONET only if there is one element in the range i.e. start > >range > > > > and end range should be same. > > > > > > > > 3. There are couple of scenarios where there can be contention for > > > > establishing bi-directional LSPs. All the scenarios are not listed in > > > > the document. If it is not possible to list all the scenarios then the > > > > draft should say that this is one of the example scenario. The > > > > contention can also be possible in case where same label set and > > > > upstream label are used in both the directions. > > > > > > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be > > > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > > > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean > >GMPLS > > > > has different set of carrier requirements in this regard ? > > > > > > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as > > > > an addendum to the draft. > > > > > > > > 6. The relation between switching capability and LSP encoding type > > > > should be clearly explained in the drafts. As the switching capability > > > > field was added very late (just 2 months back) in the drafts, > > > > specific reason should be mentioned for its addition. > > > > > > > > Regards, > > > > manoj. > > > > > > > > > > > > > > > >> From: Kireeti Kompella > > > >> To: ccamp@ops.ietf.org > > > >> Subject: Moving right along ... > > > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) > > > >> > > > >> Despite the energetic subject line, we the WG chairs have been > > > >> lax in our duties. So, here goes: > > > >> > > > >> Lou has submitted the latest versions of the generalized > > > >> signaling documents quite some time ago (thanks, Lou): > > > >> > > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > > >> draft-ietf-mpls-generalized-signaling-06.txt > > > >> > > > >> Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > >> > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > >> > > > >> All of these should have addressed the issues raised in the earlier > > > >> versions. Please read the new versions, and send your comments to > > > >> the list by Tuesday Oct 23. At that point, when the final round > > > >> of comments have been addressed, these docs will go to IESG Last > > > >> Call. If any one objects to sending these docs to IESG Last Call, > > > >> raise your issues now. > > > >> > > > >> I see that the GMPLS architecture document is a CCAMP WG doc, but > > > >> the minutes say that we should look for consensus on the list. So, > > > >> if you think this doc *shouldn't* be a WG doc, let us know. (If we > > > >> arrived at a consensus, remind me :-)) If nothing is heard, the doc > > > >> will progress to WG Last Call. > > > >> > > > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > > >> CCAMP WG docs; consensus at the meeting was Yes. Please let the > > > >> list know what your thinking is on these. (BTW, both these docs > > > >> were to have some edits done. If the authors could do that before > > > >> the next IETF, we can try to make more progress then.) > > > >> > > > >> The MIB overview doc was recently posted. Please read and comment > > > >> to the list. > > > >> > > > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > >> was generally thought to be useful; it will be published as a > > > >> CCAMP informational doc. This begins a two week Last Call on > > > >> the doc, ending Tuesday Oct 30. > > > >> > > > >> There was no consensus on whether the GMPLS framework should be > > > >> a CCAMP WG doc. Please indicate your pleasure. > > > >> > > > >> draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > > >> raised that this draft is close to ready for WG Last Call. Please > > > >> review it, and let us know if you disagree. > > > >> > > > >> The OLI requirements doc was broadly accepted. Please let the > > > >> list know if you think this doc should be a WG doc. > > > >> > > > >> It's still open whether we (the IETF) should be working on > > > >> LMP-WDM. I urge the authors to keep on working on the doc, and > > > >> keeping it in sync with LMP; however, we will postpone making it > > > >> a CCAMP WG doc until the issue is resolved. Hopefully that will > > > >> happen in Salt Lake City. > > > >> > > > >> There was reasonable interest in the tunnel trace requirements > > > >> doc. Let's formalize this: do you think this should be made a > > > >> CCAMP WG document? > > > >> > > > >> Summary: > > > >> > > > >> 1) Final comments and IESG Last Call readiness for: > > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > > >> draft-ietf-mpls-generalized-signaling-06.txt > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > >> > > > >> 2) Should the following documents be CCAMP WG docs? > > > >> draft-bonica-tunneltrace-02.txt > > > >> draft-fontana-ccamp-gmpls-g709-00.txt > > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > > >> draft-many-ccamp-gmpls-framework-00.txt > > > >> draft-many-oli-reqts-00.txt > > > >> > > > >> 3) Comment on MIB overview. > > > >> > > > >> 4) Two week Last Call comments on > > > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > >> > > > >> 5) Last Call readiness of > > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > > >> draft-ietf-ccamp-lmp-01.txt > > > >> > > > >> Thanks, > > > >> Kireeti. > > > >> > > > > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > > > > > > > > > ><< dimitri.papadimitriou.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 04:03:09 -0700 Message-Id: <200110231102.HAA25412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-00.txt Date: Tue, 23 Oct 2001 07:02:10 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol Management Information Base Using SMIv2 Author(s) : M. Dubuc et al. Filename : draft-ietf-ccamp-lmp-mib-00.txt Pages : 18 Date : 22-Oct-01 This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP) [LMP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lmp-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011022135434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011022135434.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 03:26:56 -0700 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A94092DDF71@mbtlipnt01.btlabs.bt.co.uk> From: shehzad.mirza@bt.com To: yakov@juniper.net Cc: mlazer@att.com, ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Tue, 23 Oct 2001 11:25:13 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Yakov, See comments in-line > -----Original Message----- > From: Yakov Rekhter [SMTP:yakov@juniper.net] > Sent: 22 October 2001 21:12 > To: Lazer, Monica A, NNAD > Cc: ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > Monica, > > > Dimitri, > > Actually, it may be more accurate to put it differently - if GMPLS > supports > > only a handful of the services running on a given transport network, > than > > its value as a network's control plane component is diminished. > > To be even more accurate, GMPLS value is diminished *in the context* > of that particular transport network. And unless *all* providers > are going to run *all possible services* on their transport networks > (which is a somewhat unrealistic scenario), that means that the > value of GMPLS as a network's control plane component would be > diminished for *some*, but not *all* service providers. > > > [shehzad] For a control plane not to support all the transport services capable of being carried over an operator's network diminishes the value of that particular control plane. What is the point of having transparent/optical equipment capable of transporting both Gigabit Ethernet and Fiber Channel (as an example), if provisioning was based on signalling that could only support Gigabit Ethernet? This is a restriction for every provider regardless of whether a network is a standalone one built for a large customer or a national network serving multiple customers. The effective 'banning' of certain services that are currently being offered by providers will unnecessarily damage the business case for the adoption of GMPLS. > At the same time, it is important to keep in mind that being "all > things for all people" (aka as "perfect solution") is one of the > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a > *particular* provider GMPLS would *not* support *all* the services > that this provider runs on its transport network. > > Yakov. > > [Shehzad] There is no technical reason why a GMPLS encoding type could not be adopted for a recognised format such as Fiber Channel, as far as I am aware the adoption of Fiber Channel is not likely to destroy the foundations of GMPLS. On a more general point, is the support of transport technologies within GMPLS signalling restricted to those that the authors of the GMPLS drafts will allow? > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > > > -----Original Message----- > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 3:15 PM > > To: Lazer, Monica A, NNAD > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > > > Fine. Now we know the following: GMPLS is really attractive for > > carriers when it supports all transport technologies so it has > > to support Fiber Channel as well. > > > > I wasn't aware that Ewart was capable to read in your mind ;-) > > > > Regards, > > Dimitri. > > > > "Lazer, Monica A, NNAD" wrote: > > > > > > Dimitri, > > > I am just answering the PS question with this message. > > > The short answer is yes. The long answer is that the GMPLS control > plane > > is > > > really useful if it can support connection management for all the > > transport > > > services supported by the transport network using GMPLS. Therefore, > the > > > carrier services section for the NNI document to be posted on the OIF > site > > > within a few minutes and the next draft of the carrier requirements > IETF > > > draft will both contain references to support of Fiber Channel. > > > Regards, > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 2:47 PM > > > To: Ewart Tempest > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type > expansion > > > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > > > If you take a look on the IEEE Standards you will see > > > that GE is referred to as > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > So my question is what do you have in mind ? to separate > > > these values ? > > > > > > Thanks, > > > Dimitri. > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > ------- > > > > > > [1] From - http://standards.ieee.org > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > > augmentation of its operation, physical layer characteristics, > repeater > > > functions and management parameters for transfer of 802.3 and Ethernet > > > format frames at 1,000 Mb/s. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of CSMA/CD nodes, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > [2] From - http://standards.ieee.org > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > > minimal augmentation of its operation, physical layer characteristics > > > and management parameters for transfer of LLC and Ethernet format > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > > standard. In addition to the traditional LAN space, add parameters and > > > mechanisms that enable deployment of Ethernet over the Wide Area > Network > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > payload > > > rate. > > > > > > Project purpose: The purpose of this project is to extend the 802.3 > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > application space to include Wide Area Network links in order to > provide > > > a significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of 802.3 interfaces, previous investment in > > > research > > > and development, and principles of network operation and management. > > > > > > ------- > > > > > > > Ewart Tempest wrote: > > > > > > > > Lou, > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > > GE is not really covered by the existing Ethernet related encoding > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > Ewart > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 03:24:54 -0700 Message-ID: From: "Mannie, Eric" To: 'Juergen Heiles' , 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Tue, 23 Oct 2001 12:23:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Juergen, We already discussed all these points (at least 5 times) :-) - about automatic detection: Indeed, you either configure a box with a signal structure, or if implemented you can ask to the box to discover itself the structure (what you call automatic detection). Automatic detection is a process applied internally to a box, and this is totally invisible to any other box in the network. This is an implementation issue, not a protocol issue since the protocol defines everyhting you need to do it. I understand your frustration that SDH standards don't describe all the processes for an implementation, but in general standards don't touch that part. Automatic detection is a matter of reading the standard and understanding how the multiplexing works. By the way, you explained it yourself very well. The fact that a process is not described in some SDH standards has no meaning, it is simply not relevant. Every manufacturer is free to do its implementation as he likes if the protocol is fullfilled, and this is the case. - about the comparison of automatic detection and transparency: You are comparing apples with chocolates. Transparency may require to transport bytes in unused bytes, so in that case it changes the overhead. Automatic detection is an internal process. - You wrote: "During errors (defects, AIS condtions) of individual singals of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic." and I already answered many times: a super signal (group signal) is one single LSP. If something fails inside everything fails. In that case you don't need to demultiplex anymore, you just protect/restore the whole (if required). A group signal is a signaling plane object, i.e. one single LSP. - Can you present me any ITU/ANSI standard that defines automatic detection of the group structure? No need, this is not in the scope of ITU/ANSI standards. - You wrote " You haven't provided a reason for different lables. We had several people that wanted to have the same label structure and only you opposed. So what is rough consensus?" The labels are local per interface, so they are "different" by definition since an SDH interface is not a Sonet interface. However, we defined the two label formats based on the same principles, i.e. the first field is the index of the first AUG-1/STS-1 (easy). We chosen not to indicate any level of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because this is not needed and less flexible. A label is just a simple pointer in the multiplex, how to interpret the content of what is pointed to is not defined by the label. Using your proposal we would introduce a particular case, and in that case there is no reason why we should not introduce other particular case (AUG-4, etc). At the end we would have something totally unreadable. Your proposal has also some issues, e.g. with your definition of the S field: "1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. What happens if a link is not a a multiple of 3xN STS-1 ? For instance, a virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an STS-4. There is no real second STS-3 group. Your proposal is not appropriate to the level of flexibility that we want to provide. Another observations: our undrestanding of the label is that it is defined before any interleaving, not after. I am opposed because your proposal doesn't bring any new functionality. There are probably 100 ways of coding such a label for SDH and Sonet. We discussed it during one year, we agreed on the current one because it is simple, easy to understand, easy to code and very flexible (and more important we never broke it !!!). We validate it, it is stable since a very long time. Why should we accept your way of coding it, and not the way of somebody else at this final stage ? Kind regards, Eric -----Original Message----- From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] Sent: Monday, October 22, 2001 3:01 PM To: Mannie, Eric; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: AW: Moving right along ... Hi Eric, sorry for the delayed answer, but I have problems with the remtoe LAN access here in Geneva. I am therefore sending the mail via my ITU e-mail account and hope it is accepted by the ccamp list server. You compare groups with the multiplier, this is wrong. The multiplier sets up n indivudal VC-n connections. The transport plane sees only the individual VCs and the VC type (VC-4/372712711) is explicitly defined. So no additional support at the transport plane is needed. It is a pure control plane feature. Groups are not a pure control plane feature. When you setup a group (AUG, TUG, VTG, STSG) the transport plane still has to handle the individual VCs/SPEs that are part of the group. Due the independent timing of each VC/STS-SPE pointer processing has to be done per individual VC/SPE. The transport plane cannot switch the group as a whole between STM/STS ports. The transport plane therefore has to automatically detect the structure of the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a mixture and that may change over the lifetime of the group. This automatic detection is not a standard SONET/SDH feature. As I described in previous e-mails it is possible to do it based on pointer values during non error situations. During errors (defects, AIS condtions) of individual singals of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. If a single VC-12 in a TUG3 group has AIS (note that the AIS could result from a failure outside the LSP), I assume that still all the other VCs of the group shall be connected without errors. No SONET/SDH standard covers the automatic detection. So in my view it is similarly to transparency of individual SOH bytes. G.707 defines the individual SOH bytes, however transparency it is not standard SONET/SDH and is therefore in the non-standard document. In the same way G.707 defines groups, but not the automatic detection of the group structure. So it should be moved to the non-standards document. At the London meeting Kireeti said the decision on standard/non-standard features is not based on rough consensus, but on what is in the ITU/ANSI documents. Can you present me any ITU/ANSI standard that defines automatic detection of the group structure? You say groups are cool, may be for some applications. But note that groups have the same fragementation problem as contiguous concatenation. The VCs in a group always have to stay together. If for a example a TUG2 consits of 3 VC-12 you cannot put them in arbitrary free time slots. They have stay in the time slots that belong to a single TUG2. Concering the lable, aligning the SONET labels with the SDH lables makes live easier. It is also a sign that SONET and SDH are identical for most parts. I also showed you that SONET uses the same two-stage interleaving process as SDH. If you look at the attached figure from T1.105 you see that the STS-1 time slots in an STS-N signal are not continously number. First 3 STS-1s are combiend to a STS3 groupg and then the STS3 groups are multiplexed. The same as SDH with AU3s and AUGs. As the SONET lables will become the same as the SDH labels we don't have to evaluate much. I already made a proposal some time ago. Why introduce different labels without a need? You haven't provided a reason for different lables. We had several people that wanted to have the same label structure and only you opposed. So what is rough consensus? See my proposal for the labels below. Juergen This is my proposal for the label: The format of the label for SDH and/or SONET TDM-LSR link is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | U | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH, this is an extension of the numbering scheme defined in G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same signaling scheme is used in order to provide easy interworkign between SDH and SONET signaling. For the S field a STS-3 group,which corresponds with the SDH AUG-1 level is introduce. The U field indicates the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. The K field is not significant for SONET as it doesn't support structured STS-3c-SPEs and must be set to zero. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non-significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. When hierarchical SDH/SONET LSPs are used, an LSP with a given bandwidth can be used to tunnel lower order LSPs. The higher order SDH/SONET LSP behaves as a virtual link with a given bandwidth (e.g. VC-3), it may also be used as a Forwarding Adjacency. A lower order SDH/SONET LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label is non-significant and is set to zero. For instance, a VC-3 LSP can be advertised as a forwarding adjacency. In that case the labels allocated between the two ends of that LSP (i.e. for that "link") will have S, U and K set to zero, i.e., non-significant, while L and M will be used to indicate the signal allocated in that VC-3. 1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4 indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 group. 3. K is only significant for SDH VC-4 and must be ignored for SONET and SDH HOVC-3. It indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further subdivided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC- 4. K is not significant when the AUG-1 is divided into AU-3s (easy to read and test). 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further subdivided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. 5. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. M=1 indicates that the TUG-2/VT Group is not further subdivided and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific VC-12/VT-2 SPE inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE inside the corresponding TUG-2/VT Group. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). The M encoding is summarized in the following table: M SDH SONET ---------------------------------------------------------- 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 1 VC-2 VT-6 2 - 1st VT-3 3 - 2nd VT-3 4 1st VC-12 1st VT-2 5 2nd VC-12 2nd VT-2 6 3rd VC-12 3rd VT-2 7 1st VC-11 1st VT-1.5 8 2nd VC-11 2nd VT-1.5 9 3rd VC-11 3rd VT-1.5 10 4th VC-11 4th VT-1.5 In case of contiguous concatenation, the label that is used is the lowest label of the contiguously concatenated signal as explained before. The higher part of the label indicates where the signal starts and the lowest part is not significant. For instance, when requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0. Examples of labels: Example 1: S>0, U=1, K=1, L=0, M=0 Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group. Example 2: S>0, U=1, K>1, L=1, M=0 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. Example 3: S>0, U>1, K=0, L=0, M=0 Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 4: S>0, U>1, K=0, L>1, M=1 Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 5: S>0, U>1, K=0, L>1, M=9 Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 6: S>0, U=1, K>1, L>1, M=5 Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of the Sth AUG-1. > -----Ursprüngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Donnerstag, 18. Oktober 2001 18:58 > An: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Betreff: RE: Moving right along ... > > > Hello Juergen, > > Your comments are addressed hereafter. Note that you didn't raised any > technical problem or mistake in your comments (i.e. the draft "works" very > well as it is). > > - the first comment is not about a technical issue but an > "editorial" issue. > - the second comment is about a change that will not bring any new > capability. > > >Concerning the SDH/Sonet documents I want to raise a formal issue. > >We have now two documents, a document that covers ITU/ANSI standard > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that > covers non-standard features > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in > Appendix 1 > of the standard feature document a non standard feature (Group signals) is > listed. It is even mentioned that the use of groups (AUG, STSG, > ...) is not > described in standards. So this feature should be moved to the > non-standards > document. Otherwise the split of the documents doesn't make sense. > > We spend a considerable amount of time speaking about this > particular issue > and I still don't see any technical justification for what you said. > > For those who are not SDH/SONET experts some quick explanation: > > We call a "super-circuit" a set of physical circuits in the > transport plane > all belonging to the same LSP in the signaling plane. We defined two kinds > of super-circuits: "group circuits" and "multiplicative circuits". > > Multiplicative circuits are setup using the multiplier field that > we defined > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no > objection > about these ones. > > Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG, > TUG, VTG (we defined the equivalent signal type in the signaling). The > comment of Juergen is about these group circuits. A group circuit > represents > some bandwidth at a given place in the SDH/SONET multiplex. The > advantage of > such a super-circuit is that the customer can re-structure its content as > he/she likes. The operator doesn't care. > > Such an application is possible and is already implemented. SDH/SONET is > self-describing, i.e. by looking at the signal one can understand > how it is > structured (like Juergen explained on the mailing list), so one > can setup a > circuit without describing the content (very very cool). > > The transport plane ignores that the signaling plane uses an "abstraction" > (i.e. an LSP) representing several physical circuits. Note that > restoration > and management belong respectively to the signaling plane and to the > management plane in the IETF view (not to the transport plane like in the > ITU-T view). > > From that point of view, group circuits are a GMPLS signaling > plane feature > and not a transport plane feature. We put the comment on the fact > that this > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy. > > I could say clearly at the beginning of the draft that the signal > types that > we are defining in this document are not ITU-T signal types but > GMPLS signal > types (of course) whose have in some cases a direct relationship with the > ITU-T signal types. > > Any objection ? > > >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I > prefer to have the same coding for Sonet and SDH. That makes the > implementation for Sonet and SDH simpler. Furthermore ITU and T1 > have tried > over the last years to align Sonet and SDH as much as possible. The > definition of different labels for Sonet and SDH contradicts these > activities. > > We discussed this one since a long time as well. Let me be clear: > > - labels are local to an interface (we all agree). > - a link (interface) is operated at one point in the time as either SDH or > SONET. > - your proposal will require to re-evaluate many things. > - and it took us a lot of time to fine-tune and to validate the current > label structure. > - we could have technical issues with your proposal that would impact more > than this draft (Dimitri saw some of them, please see with him). > - you never provided a complete analysis of your proposal. > > But more important: your proposal doesn't bring any additional > functionality > to the draft. > > At this very late stage, since this not bringing any new > functionality, and > since the label structure is very stable since a long time, I would prefer > not to restart a long technical discussion to change and re-validate the > draft. > > Kind regards, > > Eric > > > > > -----Ursprüngliche Nachricht----- > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > > An: ccamp@ops.ietf.org > > Betreff: Moving right along ... > > > > > > Despite the energetic subject line, we the WG chairs have been > > lax in our duties. So, here goes: > > > > Lou has submitted the latest versions of the generalized > > signaling documents quite some time ago (thanks, Lou): > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > draft-ietf-mpls-generalized-signaling-06.txt > > > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > All of these should have addressed the issues raised in the earlier > > versions. Please read the new versions, and send your comments to > > the list by Tuesday Oct 23. At that point, when the final round > > of comments have been addressed, these docs will go to IESG Last > > Call. If any one objects to sending these docs to IESG Last Call, > > raise your issues now. > > > > I see that the GMPLS architecture document is a CCAMP WG doc, but > > the minutes say that we should look for consensus on the list. So, > > if you think this doc *shouldn't* be a WG doc, let us know. (If we > > arrived at a consensus, remind me :-)) If nothing is heard, the doc > > will progress to WG Last Call. > > > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > CCAMP WG docs; consensus at the meeting was Yes. Please let the > > list know what your thinking is on these. (BTW, both these docs > > were to have some edits done. If the authors could do that before > > the next IETF, we can try to make more progress then.) > > > > The MIB overview doc was recently posted. Please read and comment > > to the list. > > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > was generally thought to be useful; it will be published as a > > CCAMP informational doc. This begins a two week Last Call on > > the doc, ending Tuesday Oct 30. > > > > There was no consensus on whether the GMPLS framework should be > > a CCAMP WG doc. Please indicate your pleasure. > > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > raised that this draft is close to ready for WG Last Call. Please > > review it, and let us know if you disagree. > > > > The OLI requirements doc was broadly accepted. Please let the > > list know if you think this doc should be a WG doc. > > > > It's still open whether we (the IETF) should be working on > > LMP-WDM. I urge the authors to keep on working on the doc, and > > keeping it in sync with LMP; however, we will postpone making it > > a CCAMP WG doc until the issue is resolved. Hopefully that will > > happen in Salt Lake City. > > > > There was reasonable interest in the tunnel trace requirements > > doc. Let's formalize this: do you think this should be made a > > CCAMP WG document? > > > > Summary: > > > > 1) Final comments and IESG Last Call readiness for: > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > draft-ietf-mpls-generalized-signaling-06.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > 2) Should the following documents be CCAMP WG docs? > > draft-bonica-tunneltrace-02.txt > > draft-fontana-ccamp-gmpls-g709-00.txt > > draft-ietf-ccamp-gmpls-architecture-00.txt > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > draft-many-ccamp-gmpls-framework-00.txt > > draft-many-oli-reqts-00.txt > > > > 3) Comment on MIB overview. > > > > 4) Two week Last Call comments on > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > 5) Last Call readiness of > > draft-ietf-ccamp-gmpls-architecture-00.txt > > draft-ietf-ccamp-lmp-01.txt > > > > Thanks, > > Kireeti. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Oct 2001 03:22:39 -0700 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' , Yanhe Fan Cc: 'Zhi-Wei Lin' , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Tue, 23 Oct 2001 12:20:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Maarten and Zhi, I have the feeling that you are inventing a new model with a new protocol. This is not how GMPLS works. I understand your frustrations and I have the feeling that your ideas should be addressed somewhere else rather than trying to change a model that we are finalizing and that we got from the MPLS model. There are maybe 1000 ways of designing a control plane for transmission networks. I would suggest that you first develop your own model and then that we compare the two. Please, don't forget that we have here to be constructive in terms of GMPLS. We have final discussions about the core GMPLS signaling, this is not the beginning but the end of an (intermediate) phase. Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your house :-) We know it. Personally, I don't believe in the ultimate model and protocol that will do everything and that will take 10 years to be specified, with abstract protocols, meta-models, etc. By the way, personally I don't see any benefit of defining these meta-models, abstract models and abstract protocols. It is hard to understand for non super-expert and it is a complete loss of time for the readers. I prefer practical solutions. I am also seeing discussions that we already have many times in the past. I don't see any benefit of having them again, and again, and again. If we continue like this we will all implement a tool to answer automatically with our previous e-mails :-) Ok, there is a small set of people that don't like the way that GMPLS is designed and defined (always the same 4 or 5 people by the way) - that's 100% your right guys and I respect it. In comparison with the hundreds (thousands ?) of people that are working on GMPLS and implementing it, this is a great achievement ! So, I ask you the question: what do you want to achieve personally at this stage ? Don't you think that sometimes it is needed to finish one step, before going to the next one ? Kind regards, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Monday, October 22, 2001 11:07 PM To: Yanhe Fan Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... Yanhe, The situation Zhi describes is one that will be very typical in the optical (SDH/SONET) network in the coming years. We will most likely see islands of switched subnetworks interconnected via the existing SDH/SONET non-switched networks. By means of management actions, links (GMPLS: link bundles) will be setup between an edge node in one switched subnetwork and an other edge node in the next switched subnetwork. In G.805 terminology, these links are so called serial compound links. The switched subnetworks will treat these serial compound links as normal links, "ignoring" the intermediate non-switched nodes they traverse. These links will contain a fixed set of link connections, which are identified by their respective endpoints at nodes A and Z (i.e. SNPa - SNPz). The server signal that carries the e.g. 5 STS1 link connections in the link at A can be an OC12, whereas this can be an OC48 at Z. During discovery or by means of provisioning both A and Z nodes get aware of the 5 sTS1 link connections as tuples of e.g. SNPa SNPz ----------------------------------- - port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) - port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) - port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) - port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) - port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) As both ends of the link build up this same relation information, it is possible to use as link connection identifier only one of the two SNPs. E.g. node A identifies the STS1 link connection #1 by means of "Ai/T1" and sends this info to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". Vice versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when received by node A, this will be converted into Ai/T1. For GMPLS this implies that the GMPLS label doesn't identify the timeslot at both ends of the link connection, only the timeslot at the sending end. The receiving end needs to convert this then into its local timeslot number. Regards, Maarten Yanhe Fan wrote: > > Hi Zhi, > > What B does is breaking the label association between A and C by crossing > connect > the time slots. > > If the cross connect performed by B is fixed (in your case), what needs to > do is > just to rebuild the label association by configuration or a protocol such as > LMP; > If the cross connect is not fixed but dynamic, the best thing to do is to > make B > a GMPLS speaker. Tell this to the 1.000.000+ SDH/SONET network elements in today's transport network... no chance... those will stay non-switched... > > Yanhe > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Friday, October 19, 2001 6:01 PM > To: Yanhe Fan > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Hi Yanhe, > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > is simply part of the network that made up the "dumb" pipe. And because > the control plane control channel is separate, A and C can be adjacent > without ever knowing who B is or that even B existed. From A and C's > point of view, the network looks like: > > A ----- C > > Think of the case of how a BGP sees an area. If an area is made up of: > > A -- B -- C > > and B is internal router, does BGP "see" B? > > Zhi > > Yanhe Fan wrote: > > > Hi, Zhi > > > > > >>For the label value for SONET/SDH or the label description in the > >>generic draft, the label is defined as directly representing the > >>"timeslot". Now if I have a control plane controlled transport network > >>that goes through a ADM that is not control plane controlled, as: > >> > >> > >>+--------+ +--------+ +--------+ > >>| | ---1--------- | | ----1-------- | | > >>| | ---2--------- | | ----2-------- | | > >>| A | ---3--------- | B | ----3-------- | C | > >>| | ---4--------- | | ----4-------- | | > >>| | ---5--------- | | ----5-------- | | > >>+--------+ +--------+ +--------+ > >> > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C > >>has labels 1,2,3,4,5 incoming. > >> > >>Now imagine that at B, it actually has a fixed cross-connect that > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >> > >>Now when A GMPLS sends a message to C, the label it uses is "1". > >>However, the connection/LSP associated with timeslot "1" is actually the > >>label of timeslot "2" at C. > >> > > > > In this case, you're trying to use GMPLS to setup an LSP cross a node (B) > > which can't understand GMPLS. > > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > > GMPLS if B can't understand GMPLS? > > > > Now imagine A and B are LSRs, and B is a conventional router (can't > > understand > > MPLS), can you setup an LSP A-B-C? > > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > > understand PNNI at all? > > > > My point is that in order to make you case work, some additional work need > > to > > be done besie simply using GMPLS as singnaling protocol, becase some node > on > > the path is not GMPLS speakers. A and C needs the info of time slot > aligment > > > > between them. This can be done by some configurations, some link > management > > protocls (LMP maybe) etc. As long as A and C have this piece of info, > > eveything > > works fine. > > > > Yanhe > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 20:12:25 -0700 From: "Juergen Heiles" To: "Mannie, Eric" , "'Kireeti Kompella'" , Subject: AW: Moving right along ... Date: Mon, 22 Oct 2001 15:00:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C15B0A.53696060" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C15B0A.53696060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Eric, sorry for the delayed answer, but I have problems with the remtoe LAN access here in Geneva. I am therefore sending the mail via my ITU e-mail account and hope it is accepted by the ccamp list server. You compare groups with the multiplier, this is wrong. The multiplier sets up n indivudal VC-n connections. The transport plane sees only the individual VCs and the VC type (VC-4/372712711) is explicitly defined. So no additional support at the transport plane is needed. It is a pure control plane feature. Groups are not a pure control plane feature. When you setup a group (AUG, TUG, VTG, STSG) the transport plane still has to handle the individual VCs/SPEs that are part of the group. Due the independent timing of each VC/STS-SPE pointer processing has to be done per individual VC/SPE. The transport plane cannot switch the group as a whole between STM/STS ports. The transport plane therefore has to automatically detect the structure of the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a mixture and that may change over the lifetime of the group. This automatic detection is not a standard SONET/SDH feature. As I described in previous e-mails it is possible to do it based on pointer values during non error situations. During errors (defects, AIS condtions) of individual singals of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. If a single VC-12 in a TUG3 group has AIS (note that the AIS could result from a failure outside the LSP), I assume that still all the other VCs of the group shall be connected without errors. No SONET/SDH standard covers the automatic detection. So in my view it is similarly to transparency of individual SOH bytes. G.707 defines the individual SOH bytes, however transparency it is not standard SONET/SDH and is therefore in the non-standard document. In the same way G.707 defines groups, but not the automatic detection of the group structure. So it should be moved to the non-standards document. At the London meeting Kireeti said the decision on standard/non-standard features is not based on rough consensus, but on what is in the ITU/ANSI documents. Can you present me any ITU/ANSI standard that defines automatic detection of the group structure? You say groups are cool, may be for some applications. But note that groups have the same fragementation problem as contiguous concatenation. The VCs in a group always have to stay together. If for a example a TUG2 consits of 3 VC-12 you cannot put them in arbitrary free time slots. They have stay in the time slots that belong to a single TUG2. Concering the lable, aligning the SONET labels with the SDH lables makes live easier. It is also a sign that SONET and SDH are identical for most parts. I also showed you that SONET uses the same two-stage interleaving process as SDH. If you look at the attached figure from T1.105 you see that the STS-1 time slots in an STS-N signal are not continously number. First 3 STS-1s are combiend to a STS3 groupg and then the STS3 groups are multiplexed. The same as SDH with AU3s and AUGs. As the SONET lables will become the same as the SDH labels we don't have to evaluate much. I already made a proposal some time ago. Why introduce different labels without a need? You haven't provided a reason for different lables. We had several people that wanted to have the same label structure and only you opposed. So what is rough consensus? See my proposal for the labels below. Juergen This is my proposal for the label: The format of the label for SDH and/or SONET TDM-LSR link is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | U | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH, this is an extension of the numbering scheme defined in G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same signaling scheme is used in order to provide easy interworkign between SDH and SONET signaling. For the S field a STS-3 group,which corresponds with the SDH AUG-1 level is introduce. The U field indicates the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. The K field is not significant for SONET as it doesn't support structured STS-3c-SPEs and must be set to zero. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non-significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. When hierarchical SDH/SONET LSPs are used, an LSP with a given bandwidth can be used to tunnel lower order LSPs. The higher order SDH/SONET LSP behaves as a virtual link with a given bandwidth (e.g. VC-3), it may also be used as a Forwarding Adjacency. A lower order SDH/SONET LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label is non-significant and is set to zero. For instance, a VC-3 LSP can be advertised as a forwarding adjacency. In that case the labels allocated between the two ends of that LSP (i.e. for that "link") will have S, U and K set to zero, i.e., non-significant, while L and M will be used to indicate the signal allocated in that VC-3. 1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4 indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 group. 3. K is only significant for SDH VC-4 and must be ignored for SONET and SDH HOVC-3. It indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further subdivided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC- 4. K is not significant when the AUG-1 is divided into AU-3s (easy to read and test). 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further subdivided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. 5. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. M=1 indicates that the TUG-2/VT Group is not further subdivided and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific VC-12/VT-2 SPE inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE inside the corresponding TUG-2/VT Group. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). The M encoding is summarized in the following table: M SDH SONET ---------------------------------------------------------- 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 1 VC-2 VT-6 2 - 1st VT-3 3 - 2nd VT-3 4 1st VC-12 1st VT-2 5 2nd VC-12 2nd VT-2 6 3rd VC-12 3rd VT-2 7 1st VC-11 1st VT-1.5 8 2nd VC-11 2nd VT-1.5 9 3rd VC-11 3rd VT-1.5 10 4th VC-11 4th VT-1.5 In case of contiguous concatenation, the label that is used is the lowest label of the contiguously concatenated signal as explained before. The higher part of the label indicates where the signal starts and the lowest part is not significant. For instance, when requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0. Examples of labels: Example 1: S>0, U=1, K=1, L=0, M=0 Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group. Example 2: S>0, U=1, K>1, L=1, M=0 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. Example 3: S>0, U>1, K=0, L=0, M=0 Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 4: S>0, U>1, K=0, L>1, M=1 Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 5: S>0, U>1, K=0, L>1, M=9 Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 6: S>0, U=1, K>1, L>1, M=5 Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of the Sth AUG-1. > -----Ursprüngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Donnerstag, 18. Oktober 2001 18:58 > An: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Betreff: RE: Moving right along ... > > > Hello Juergen, > > Your comments are addressed hereafter. Note that you didn't raised any > technical problem or mistake in your comments (i.e. the draft "works" very > well as it is). > > - the first comment is not about a technical issue but an > "editorial" issue. > - the second comment is about a change that will not bring any new > capability. > > >Concerning the SDH/Sonet documents I want to raise a formal issue. > >We have now two documents, a document that covers ITU/ANSI standard > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that > covers non-standard features > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in > Appendix 1 > of the standard feature document a non standard feature (Group signals) is > listed. It is even mentioned that the use of groups (AUG, STSG, > ...) is not > described in standards. So this feature should be moved to the > non-standards > document. Otherwise the split of the documents doesn't make sense. > > We spend a considerable amount of time speaking about this > particular issue > and I still don't see any technical justification for what you said. > > For those who are not SDH/SONET experts some quick explanation: > > We call a "super-circuit" a set of physical circuits in the > transport plane > all belonging to the same LSP in the signaling plane. We defined two kinds > of super-circuits: "group circuits" and "multiplicative circuits". > > Multiplicative circuits are setup using the multiplier field that > we defined > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no > objection > about these ones. > > Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG, > TUG, VTG (we defined the equivalent signal type in the signaling). The > comment of Juergen is about these group circuits. A group circuit > represents > some bandwidth at a given place in the SDH/SONET multiplex. The > advantage of > such a super-circuit is that the customer can re-structure its content as > he/she likes. The operator doesn't care. > > Such an application is possible and is already implemented. SDH/SONET is > self-describing, i.e. by looking at the signal one can understand > how it is > structured (like Juergen explained on the mailing list), so one > can setup a > circuit without describing the content (very very cool). > > The transport plane ignores that the signaling plane uses an "abstraction" > (i.e. an LSP) representing several physical circuits. Note that > restoration > and management belong respectively to the signaling plane and to the > management plane in the IETF view (not to the transport plane like in the > ITU-T view). > > From that point of view, group circuits are a GMPLS signaling > plane feature > and not a transport plane feature. We put the comment on the fact > that this > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy. > > I could say clearly at the beginning of the draft that the signal > types that > we are defining in this document are not ITU-T signal types but > GMPLS signal > types (of course) whose have in some cases a direct relationship with the > ITU-T signal types. > > Any objection ? > > >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I > prefer to have the same coding for Sonet and SDH. That makes the > implementation for Sonet and SDH simpler. Furthermore ITU and T1 > have tried > over the last years to align Sonet and SDH as much as possible. The > definition of different labels for Sonet and SDH contradicts these > activities. > > We discussed this one since a long time as well. Let me be clear: > > - labels are local to an interface (we all agree). > - a link (interface) is operated at one point in the time as either SDH or > SONET. > - your proposal will require to re-evaluate many things. > - and it took us a lot of time to fine-tune and to validate the current > label structure. > - we could have technical issues with your proposal that would impact more > than this draft (Dimitri saw some of them, please see with him). > - you never provided a complete analysis of your proposal. > > But more important: your proposal doesn't bring any additional > functionality > to the draft. > > At this very late stage, since this not bringing any new > functionality, and > since the label structure is very stable since a long time, I would prefer > not to restart a long technical discussion to change and re-validate the > draft. > > Kind regards, > > Eric > > > > > -----Ursprüngliche Nachricht----- > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > > An: ccamp@ops.ietf.org > > Betreff: Moving right along ... > > > > > > Despite the energetic subject line, we the WG chairs have been > > lax in our duties. So, here goes: > > > > Lou has submitted the latest versions of the generalized > > signaling documents quite some time ago (thanks, Lou): > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > draft-ietf-mpls-generalized-signaling-06.txt > > > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > All of these should have addressed the issues raised in the earlier > > versions. Please read the new versions, and send your comments to > > the list by Tuesday Oct 23. At that point, when the final round > > of comments have been addressed, these docs will go to IESG Last > > Call. If any one objects to sending these docs to IESG Last Call, > > raise your issues now. > > > > I see that the GMPLS architecture document is a CCAMP WG doc, but > > the minutes say that we should look for consensus on the list. So, > > if you think this doc *shouldn't* be a WG doc, let us know. (If we > > arrived at a consensus, remind me :-)) If nothing is heard, the doc > > will progress to WG Last Call. > > > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > CCAMP WG docs; consensus at the meeting was Yes. Please let the > > list know what your thinking is on these. (BTW, both these docs > > were to have some edits done. If the authors could do that before > > the next IETF, we can try to make more progress then.) > > > > The MIB overview doc was recently posted. Please read and comment > > to the list. > > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > was generally thought to be useful; it will be published as a > > CCAMP informational doc. This begins a two week Last Call on > > the doc, ending Tuesday Oct 30. > > > > There was no consensus on whether the GMPLS framework should be > > a CCAMP WG doc. Please indicate your pleasure. > > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > raised that this draft is close to ready for WG Last Call. Please > > review it, and let us know if you disagree. > > > > The OLI requirements doc was broadly accepted. Please let the > > list know if you think this doc should be a WG doc. > > > > It's still open whether we (the IETF) should be working on > > LMP-WDM. I urge the authors to keep on working on the doc, and > > keeping it in sync with LMP; however, we will postpone making it > > a CCAMP WG doc until the issue is resolved. Hopefully that will > > happen in Salt Lake City. > > > > There was reasonable interest in the tunnel trace requirements > > doc. Let's formalize this: do you think this should be made a > > CCAMP WG document? > > > > Summary: > > > > 1) Final comments and IESG Last Call readiness for: > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > draft-ietf-mpls-generalized-signaling-06.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > 2) Should the following documents be CCAMP WG docs? > > draft-bonica-tunneltrace-02.txt > > draft-fontana-ccamp-gmpls-g709-00.txt > > draft-ietf-ccamp-gmpls-architecture-00.txt > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > draft-many-ccamp-gmpls-framework-00.txt > > draft-many-oli-reqts-00.txt > > > > 3) Comment on MIB overview. > > > > 4) Two week Last Call comments on > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > 5) Last Call readiness of > > draft-ietf-ccamp-gmpls-architecture-00.txt > > draft-ietf-ccamp-lmp-01.txt > > > > Thanks, > > Kireeti. > > > ------=_NextPart_000_0000_01C15B0A.53696060 Content-Type: application/msword; name="sonet_interleaver.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sonet_interleaver.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALAAAAAAAAAAA EAAALgAAAAEAAAD+////AAAAACsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWyAJBAAA+BK/AAAAAAAAEAAAAAAABAAAAgQAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA AAAHBBYALgwAAIBqAQCAagEAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAALoAAAAAAAAAugAAALoA AAAAAAAAugAAAAAAAAC6AAAAAAAAALoAAAAAAAAAugAAABQAAAAAAAAAAAAAAM4AAAAAAAAA6AAA AAAAAADoAAAAAAAAAOgAAAAAAAAA6AAAAAwAAAD0AAAADAAAAM4AAAAAAAAAIwIAALYAAAAMAQAA AAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAA AAAAogEAAAIAAACkAQAAAAAAAKQBAAAAAAAApAEAAAAAAACkAQAAAAAAAKQBAAAAAAAApAEAACQA AADZAgAAIAIAAPkEAABkAAAAyAEAABUAAAAAAAAAAAAAAAAAAAAAAAAAugAAAAAAAAAMAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAMgBAAAAAAAA IAEAAAAAAAC6AAAAAAAAALoAAAAAAAAADAEAAAAAAAAAAAAAAAAAAAwBAAAAAAAA3QEAABYAAAAg AQAAAAAAACABAAAAAAAAIAEAAAAAAAAMAQAACgAAALoAAAAAAAAADAEAAAAAAAC6AAAAAAAAAAwB AAAAAAAAogEAAAAAAAAAAAAAAAAAACABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADAEAAAAAAACiAQAAAAAAACABAABuAAAAIAEAAAAAAAAAAAAA AAAAAI4BAAAAAAAAugAAAAAAAAC6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjgEAAAAAAAAMAQAAAAAAAAABAAAMAAAAQPt/eB4n wQHOAAAAGgAAAOgAAAAAAAAAFgEAAAoAAACOAQAAAAAAAAAAAAAAAAAAjgEAABQAAADzAQAAMAAA ACMCAAAAAAAAjgEAAAAAAABdBQAAAAAAACABAAAAAAAAXQUAAAAAAACOAQAAAAAAACABAAAAAAAA zgAAAAAAAADOAAAAAAAAALoAAAAAAAAAugAAAAAAAAC6AAAAAAAAALoAAAAAAAAAAgDZAAAAAQ0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA AQQAAAIEAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkDagAAAABVCAEAAgAEAAAC BAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAQAAAIE AAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQEsADGQaAEf sIIuILDGQSGwiQUisIkFI5CJBSSQbgQlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZxUAAEQAZAAA AAAAAAACAAAAAAAAAAEAAAAAAPEjXSzZA9kDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAPAATwPAAAALIECvAIAAAAAQQAAAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAI AAAAEPAEAAAAAAAAgDIAB/DXFAAAAwQSZdWleLAU807dWckCo9zp/wCzFAAAAQAAAEQAAAAAAA8F YCEb8KsUAAASZdWleLAU807dWckCo9zpAhIAAAAAAAAAAAAAzQEAADkCAADsVVkAvENuADMGAAAA /nicjZdrbFRFFMfPme1uaRekgQqVFlyiLR9oobt9URKpLRZSRKB2U6KQADbbBwLS8qhQIqmi0AcN 1RJjeGuAgIUGMAERY1pajKE1fiBV+IKJH5T4gCCBqGg9uzv3v9O9NbLJbc/vzG/u7Nx53FmmOCIH yx8npVDw45TLrYbkE4xGq3w1wMEohsfo0hmcpCPFrKM4ZdXlYF1ySDSF3PI3zTWWRlPwfqQ/o+T6 U7mINcfIlcHh2onqHU4OReNVpY4SVT7X6lyajhLVTu7RuWodJapB5PolCvbnL/VA2t3h2OHYYzWX 4K9ZG9ggQaErvvfozl/rT8v1TdXt+iATxevvw8EnQ1OdTirzl2VkDb3BX+hWdnGLbqVKR8GWW9By i61mk7bylFtbEyQyLe+QT8XDmgxrss1KhpUJK9NmzYQ1F9Zcm1UIqxxWuc0qg1UNq9pmVcFqgNVg s7bAaoPVZrN2wzoC64jNOgTrHKxzNusMrCuwrtisPljXYV23Wd9SrGQeylwPT+fwTFGhbHLMBDWO lGJQqlAiKE8oDbRAKB+0XOh50HqhFaA3hWpBe4V2gI4LvQ/6TOgkaEDoEuim0Negh0I/g8ayUv+A pgolsEXZQk+B5gnlgF4WKgGtEVoG2i60DtQu1Ag6KtQBOi90jMNPP1fdw9O/Z3v6v5NludiyXBxt OXGvSbAm2ayJsNJhpdus6bAKYBXYrGdglcIqtVmlsAKwAjarAlY9rHqbVQ+rGVazzWqCdQDWAZu1 D1YXrC6bdQpWD6wem9WNUf1KRvWCrqP0zjZe3WFrj1MqBbkU5GYiNxO5IuSKkPMj50euCrkq5LYi txW5VuRakTuI3EHkziJ3Frle5HqRG0RuUL/ZnFFvNoe8/4iedsRQAd3h1XKV0SAHY+vNFyxPjSqf Q7f10+znVLrA4/QK/UToEGif0E7QAC8XswTmcjoM2i+0CzTAHWI2wuwQsxFmh5iNMPvFvAizX8yL MPvFvGjrZ7304UO5WqQf9SP00yzfLP2Mrn9aym7I1SPlp0eoP7zcXj9WynxyJUt57Aj1zXKX/Lfe 4dbJ46pE0e/wiTh3lOHcYb0ZB5Hrlyi65mLb84mjKr4mVy3lcDCO/n7Dyyv1PJjGDfS4zO4wjRdS IBL6jSz6hRroBui60JegPqFzoLNCh0EHhVpBzUJbQJuFAqAKoVLQEqE5ZK27OWSd1lii8Cns/n+e wnY741PNU1iQI6ewmND/OziNucJ7jS+TanRrrO7r1jr5PlalU+9Ssm9hF0pCLgm56chZez1jr+/k AnhL4C2BF4AX0DlSm3TuY96Euk2o24TcfuT2o24X6nahjW600W2b5Xepk69yJ6+S73SXTtpmUXT5 qNATdFD2bG/GS1xHYY4hr2+2t5lXoDxrttd7S3ZWk3/kNhpe3hsa+6lOJq+c/uNBPqEpoCyKVT5Q tpQVgXKEykG5QtWgPKFtoFlCbaB8ocNG626ZAZHW3WoUR1qPUykcad2tZnCkdbd6ls3W/Rxp3a0q 2Wx9K0dad6tWTYq8mQnqUIS8CepMhHwJ6rJhjpHTacQcI2fOiPmYnDbDaymdV3MyL9Vr/gmhWJBL 6B5ZdJdW8/egm0IDoKtCn4LOCx0DfST0LmiP0HbQNqFXQTVCS0HlQs8JhefmYplX4bmZrqNEGVsr 55Ro+IrN1vcJj1k7TzHG7ASbM6bboFwhvzFjjnO5MZvajbJ8MduMGXNC3u+R8WwHBZ/2ZTaevbfT pMz3hMaFKIn8Sxd7Mjxl/sL5xZ6SRf7iFxcWF5aXLJr/E3VQYshJpjLhhcUjavQHvc3D979LKnr/ k1+dfVG/QvvMX6Hh/S+GJoXam0bzaqo21QU8WbkZnuLXV61dvybgea3SU7RlY8BTsm5joG5NYNXm mnVVzgV8mR9h702L2nvTRtp7jZWfcUvuOvLv+sjoviCjHxndD6jCWJG3jLJsWmGU5dApg3Lpb8PM ow0GzaJuw8ynsVxhrLMmWmmsyO/oFWNFpvJKHv7trYfyf32aL98g0qe9VGfM2B9oozErl1GtMWNP GGYuPTDMPFpr3HMWfW6YsstwnTEr34IZ7NM1k3xP8gZ6lD6Zp9JpPDTkCNG/WXVXsUIFGk8AAP// ////////zAEAADgCAADsVVkAvENuACIOAAAA/nic1Vt9cBXVFT9neXn5ICEQQoQQa4yDBgMUAknA PzSioJEIKGnAAELsBEj4jEoQsJLw/ZHagBSYijRIUBQGrDqCGOorUqtVqDPtZGqKQmfUVoPUYaxj /Wj6u3v35e3bd+8z7wOf3WFz332/3fs7v3POnr139zFpQCc2YzS/3YebaXUzNTIleb/K4fU0kM7n 8BiqpU9zeAOdpL/ncBuaL/bSDko2iHuJnbDtpV9RQue3+NSTCIOQtQ2hBEqPK6teWPVAD0pPocRh 5BIH5PIy+k3clLIpQ0fiaJ5HR7mBTjYJEFsmZXtbQC/xamrDObYtrp4oqZgooVh+FqD3gGT0E4sl 7vJY35E8NtUj2+QgxzbTTj8vbKQtdE7o3hKCbqFvpV1fA/Q1qvXVQ19zzPQZRTD9XPeFGXmdX5vC RuBbI4vYKKBkhTBAZBSi7yeMLCNdxT5Rl0/YlSEIG5xmV9UXqn6kVpUGVfmxVDU8FFXpdlXXQVW+ WtW1UDU+lqpuCTtWY6DqVrWq0VA1LZaqysNWNQGqytWq7oCqmliqmhd2Bs6Cqhq1qnuh6pFYqloZ dqxqoephtaolUNUUS1WPhh2rdVDVpFa1FqpaYqlqb9ix2glVT6pV7YCql2Kp6oWwVT0DVS+qVR2A qjdiqer1sDPwBFS9oVbVClVnY6nq3bBj9SeoalerOgNVF2OlKtHLOMKAICOD0hI7rW20H5YObJAG uxZYkQYbA+wODTYB2AwNNgvYEg1WC2y1BlsL7JcabCewpzXYs8Be0WCtwE5rsDPAzmmwDmDfaLD/ Ghmcqsa4N7CrNdg1wEZpsAJg4zVYCbAKDTYd2AINtgjYKg3WAGyrBtsObL8GewrYUR+Wgwvgczrf /Ssry35ldeDK+kJ9ZX1iFHJS7OpFIbtDUeVXL741CjhBreobDJwVS1WZ4ariVKjKVKrCSIU8LJaq hoSiyn7HwiVZwMPUqsTAY2Op6qawY1UAVcVqVaMwcFksVd0VdqxKoKpMrep2DDwvlqqqwo7VdKia o1ZVgYFXxFLVsrBjtRiqVqhVLcLAj8ZS1eawY9UAVaqHgoDqMXBzLFU9Ebaqx6Bqj1rVNgz8fCxV HQlb1X6oek6tqgUDn4qlqpNhX1cvQ9UptapjGPivP4S1CCzJ4Dftc0QDci6KJks2P5bNWNmUyWau bFbIplE2e2TzvGxOyaaNLsYLrhz+jGqEJc17qYWMnt92WVFLmdxGNwoc+01m20ZT+F/4zufaeDiD u+wUo92UR9cQXfPxR+JvxwD87Tp4re9jM+2zSbcB3iFwfseAZtrr8wofozR+W70K418De1GDbQD2 uAY7RiV8Wr0KQy0qwZhqbCOw3RrsGDVgzO2aMRswphrbCGy3BjtGxzHm25oxj2NMNbYR2G471hX1 J4NEvU7g2JeZbRttQdTrgkZ9WUDUuxvsZbZgdxnXHsS4wwLHLts2OgnjDgc17vAQ07h/msZdCMU4 cSZOu+BnXH4Q49wCxx5vtm00EK07qHHxfp7LDMG4eMtzmTBOvKwbSP8O6WVdov1lXSo3kGptAqgX rybH2uR7fFmHy3eKfAk7JYSXkYNH28XdBnF3q8WNh7g5sRJnpdRc+os2pQooUeDYZVtAtTwHn3Up le09UqTTE2fE310juplUvnNx4q4R/tW3H83l62ilssrgzsN91RhdBEYarB13rAsa7A/A3tVgLwD7 vQZrBva8BmsEtkeDLQe2WYNVAavTYHcB+6kGuxHYZDuWg69q6bUgaZzql8YplJRLg2ia25y/5Auk D92HCrTIm805VjaLtg9V0khq8M9m92xkIY5JaEYWzvZGGkTn0c+2HVjv23t5kPnN8ryexRjjvDzE zHTrXNF6M113vHPaxvQFHcT0g+Nk0182eaJhLNbN3mTZqxIN8VL55SbZ7JZfHpGH/I4OWlfQIX5L ewVNpksC50NWO5kr+Vl81l9B1pHi2tnRIv5urej2FeQ9FydurcAVFCTUbkdFnkrVPUbdIGapXIrJ 1nSq8wa5txVktICqeQZtcsxSFQE1bJ9NDIE1sHN9V3CCGJfoZ1zeJ8NcI/KlbQ9xOTfyfV7b+lm2 oeVlJlTnsE1sSIqrPLI8ejeX7XMysDT0+2BP8KjPCW6v05n/oAk9RkqDz1Ipd9A0lTPP0gS+QPND c6bbIzNd7F4RoRn3Ia3zGtdO6/lj2qYyrp3W8Se0//s1Lq/Q8PmtFX57Q+23V+C3v11u0wzH73B6 UhybqzgXGej08pqWYJmGFhAbyXT1d5sWCvXgdM6XvBngzVHz9gNvwXcX39AkJ9JQFrMYrNmuR6dQ RW3QYCOJShzUEXo7r7fBo6TmG6B5vFrzGGi+x5849FoT4OsCyTsRvBVq3jvBu9CfNxGCk7Ll3isM wYPTuFDyzgbvAjXvLPCu8udlG2+8Jyy9RZL3QfDWq3kfAO9j/rxi0ET4N2G270Ycot7Rknc9eLep edeBd78+sdzh6E3jMZJ3F3hb1Lw7wXvUn1f4VlxHYo8PQ29euSGLh5suGin0lYrYTZ8avTglysUj TRYPrAONFE5W83aC96poF4+efIUsHi5ORydb6WvuayTzyCgXjzSreLj5WmjOV2rmQdA8LsrFI00W DzePBu+tat4i8E6NbvEQvp5k1Q8uRWea2tcT4Ov50a0fwtdFUvO90Fyj1jwTmn8W3QIiNC+1agjf j84jas210Lw1ujVEaB4jNa+F5ia15jXQvC/SIhLnvCsaI4ZL5h1GGnf9rCrFYkZrxJmQ82dV2FLh 7d7Fchefza04lGlunCPbjRGypPEBML6oNkZAzl9DKYijYYxV546D8XW1MQJqDzQm8gWAy5GbKXTI ipSLDhq96ajKnh4m9NbliJRLHSkXnQDjm2pjBPTe9xCpvlakXPQOGM+qjRHQZ2FHSvligwfyVB7C NcqHSPHABqgx+hyYW4OdRy2/pMFOAzunwV4G9pYGewrYUQ22Ddg+DbYKWJMGmw/sYQ02VSz+Ndit wMrtWA7uNJX0Xg6NRdP9Z0m5NJjH2x4k9ePJVMgzVA+S+vEkKuLFP6gHSd2/LfFjNMCc6XEjZaCj Wq4B6sfbncu1SGd61/c3Z3rcAt6Dat4W8B6K9jIRvOaT7lbwvqbmbQXvqQBeT2TTvMGF5pQHg5eC VzXlATQBvFGe8uTyM3SXOdHjJ2kiOqpVIqA7+dlorxJFdk0y57ZIoVJ0lKoboXq7U3Wkc9u8G4ab kx74dD3crVqxAVoHdztWbJGunHKRzBvMiR7Sdy06qvkWoDXI7H36DBOfw3H3BnN6C5+uRUdJ3Qjq 7U7q0Ke3/rfsvKLh8jbJx+kEv668Z/PLJqS4Z0c+oYkLiMEJOYdAYrfyYd+DObs9e03I+StxBXfo 9rgCAvNbOcHizXDCDrV/NpmQwj+RT7DGOe5uT1Np/7Kpk7KHZk8pu/m2cdklE8vG3V067ubykom3 iQNnUiN10C6vlb+wrBTtDBM6pPAatoH1MpJplrUJ9fIq6k3S2j5kJq1ZQEXfq6rrM7As7H3FYB7Z Zlnne1WLghiPdgDJVvTJ8kJ/j4/fOyZZY5GDK1kcZ3EEHB9krP7kP07/EPQ5Nx2Hzo/fqV9hm9iu rJdzBDFeBj6nePztcP5ax7sJTsHt1dFlB2li5QmMmcqm4Nla6l9bOpIGTkFelo7Tpmsllutf8yZv uj5upatoZ5vQE4HpGmmqal3glV4cvVQVW7B0/X9MVZ194aZqMBt1Po1GDqjsDZ7eP/FLbxfnFdx+ 3fjquUvvr8oeWTg0e9xDlQuXLKjKXjwne+zyB6uySxY9WHX/gqrKuupFc8V5zdzKd3LXHe2Ileyi 3WNCjjtaPPD4z0D0jmx7zJbO6OGRsx3vfoW1C7HCCV0YkaRynGNYgelRLIMrvhP4VR6fg8R5bttY AcfXSz7xc5BUT6BNLpvDVYnpHIvINp4IptjPS93xTdKelHo5ljdJnOOK4KdbWKo1rtcWO4/SBod+ 81zL72YMvEWxOFCrXbMTd1u7vS+OEwmfGUQLO3Zhj4hxl756f3+IsRKC6bMwZ1z99nqJq/LOnmPi Ys+kQNtDeQPrMt9e9/W9hU3nDup6dO//FrYvXyDHo3vVGrYbb2GbqbH7k3KsgGaaK2y6nSvQmaOY lAO6hybz8uiusPOMUnOJTdt5Bj3O81TE23k67eaVUX6ZQh3QLFbZ9AE0d6g1fwDNF5yaNR4PgbqS Z5lLTqqA6kq16gqovs+pOtIl5/UTzVU2HQDvETXvAfA+5+SNeJVNnfC2eLZAX8LbnWpvf8n3MDm9 HfGzBVoKarHipEWgXqqmXoRA1zmpI32hkmdMNFfZWMPNoNfU7m6Fu08FJLcnslU2wmw+WEjiGdxH yQtoOqc5eUN/sOBYRNImrpCLSKqHRxu5SrGIpFUm5KwkFP33KXk8US6x6QxC3+4Lvd2a0ybk/E9F CubQrXEusQcJ75iPILKQ6rlK7/BAE1J4p5uPIJrp56EV/xJaLIv/WFqAzkOqNB1L8+kO2hLd4p9L O2mhLP9NVINOnYq6iappl/MHcpGWf3FpmsX/fWj+UK35fWj+yKnZ7Ym0+M+EZrP4l0PzTLXmcmi+ 16k5WsW/BbwH1bwt4D3k5I20+Atfm6X/Enz9H7WvL8HXXzl9HXnpX4zUNkv/PFAvVlPPA/USJ3XE 79LpVYTZLP7H4O5X1e4+Bnd7AlLbE53i76YaTlHyAqrGGJuiXfzX0AKr+K+AT9fTMlW5XW5CzkpC 0S/+ufRnmm+V/z8iBm0+X9jtedOENl/+8p/HpVbxz6D5nKP0DvczIYV3Qin++Lemk/4HGO/uTQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAPAAMAAAAAAAAA AABEAABA8f8CAEQADAAIAFMAdABhAG4AZABhAHIAZAAAAAIAAAAgAENKFgBPSgIAUUoCAF9IAQRh ShgAbUgHBHNIBwR0SAcEAAAAAAAAAAAAAAAAAAAAAAAAQgBBQPL/oQBCAAwAGQBBAGIAcwBhAHQA egAtAFMAdABhAG4AZABhAHIAZABzAGMAaAByAGkAZgB0AGEAcgB0AAAAAAAAAAAAAAAAAAAAAAAC AAAABwAADAAAAAD/////AAAAAAQAAACYAAAAADAAAAAAAAAAgAAAAIAABAAAAgQAAAMAAAAABAAA AgQAAAQAAAAABAAAAgQAAAUAAAAAAAAABAAAAAcAAAAAAAQAAAAHAP//AgAAAA4ASgB1AGUAcgBn AGUAbgAgAEgAZQBpAGwAZQBzACQARAA6AFwATgBPAFIATQBFAE4AXABpAGUAdABmAFwAcwBvAG4A ZQB0AF8AaQBuAHQAZQByAGwAZQBhAHYAZQByAC4AZABvAGMAAAAAAAEAAAAEAAAAAAAAAAEAAAD/ QAGAAQABAAAAAQAAALx/3AXzAvMCAQAAAAAAAAABAAAAAAAAAAIQAAAAAAAAAAIAAABwAAAIAEAA AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAA AAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQ AAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAACIABADxCIgYAPDEAgAAqQEAAAAAzYtYps2LWKYAAAAA AQAAAAAAAAAAAAEAAAABAAEAAAAEAAMQAQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAADsAwDwEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIGBcjAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAAAAAAAAAAAAAyg1EA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ /xIAAAAAAAAAAQAgAAAAAAAAAA4ASgB1AGUAcgBnAGUAbgAgAEgAZQBpAGwAZQBzAA4ASgB1AGUA cgBnAGUAbgAgAEgAZQBpAGwAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA 4IWf8vlPaBCrkQgAKyez2TAAAAB4AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACw AAAABQAAAMgAAAAGAAAA1AAAAAcAAADgAAAACAAAAPQAAAAJAAAADAEAABIAAAAYAQAACgAAADQB AAAMAAAAQAEAAA0AAABMAQAADgAAAFgBAAAPAAAAYAEAABAAAABoAQAAEwAAAHABAAACAAAA5AQA AB4AAAACAAAAIABzAB4AAAABAAAAAABzAB4AAAAPAAAASnVlcmdlbiBIZWlsZXMAAB4AAAABAAAA AHVlch4AAAABAAAAAHVlch4AAAALAAAATm9ybWFsLmRvdABsHgAAAA8AAABKdWVyZ2VuIEhlaWxl cwAAHgAAAAIAAAAxAGVyHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAAEAAAAAAAAAAAAAAAEAA AAAAlrBWHifBAUAAAAAAlrBWHifBAQMAAAABAAAAAwAAAAAAAAADAAAAAQAAAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQ k5cIACss+a4wAAAA8AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIQAAAAGAAAAjAAAABEAAACU AAAAFwAAAJwAAAALAAAApAAAABAAAACsAAAAEwAAALQAAAAWAAAAvAAAAA0AAADEAAAADAAAANIA AAACAAAA5AQAAB4AAAAMAAAAU2llbWVucyBJJkMAAwAAAAEAAAADAAAAAQAAAAMAAAABAAAAAwAA ADIRCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAgAAACAADBAAAAIA AAAeAAAABgAAAFRpdGVsAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAD+////CQAAAAoAAAALAAAA DAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAAP7///8UAAAAFQAAABYAAAAXAAAAGAAAABkAAAAa AAAA/v///xwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAD+////JAAAACUAAAAmAAAAJwAAACgA AAApAAAAKgAAAP7////9////LQAAAP7////+/////v////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAA AAAAAAAA8BKaeB4nwQEvAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABnFQAAAAAAADEAVABhAGIAbABlAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAAAAAQAAAAAAAAVwBv AHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABsAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgECAAAABwAA AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIA agBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA8BKaeB4nwQHwEpp4HifBAQAA AAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZC1E b2t1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= ------=_NextPart_000_0000_01C15B0A.53696060-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 16:09:07 -0700 Message-ID: <3BD4A6DD.5C0D8223@sandburst.com> Date: Mon, 22 Oct 2001 19:08:13 -0400 From: Eric Gray MIME-Version: 1.0 To: Yangguang Xu Cc: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yangguang/Yakov, This seems to be getting all blown out of proportion, however it is probably at least partly my fault - for taking earlier discussions off of the list. Therefore, I will try to address these comments on the list - though I will almost certainly regret the attempt. :-) Back on October 1st, Lou Berger announced availability of new draft version of the signaling and RSVP-TE documents he had been working on. On October 3rd, Yangguang repeated some questions that had been asked previously on the list and Fong Liaw answered these questions. This much can be seen at the archival site - ftp://ops.ietf.org/pub/lists/ccamp.current (look for the subject line - "update GMPLS signaling documents"). This site is (unfortunately) not an HTML friendly site. I felt that Fong had answered these questions completely, but I tried to add a little to this in an off-line reply (I copied Fong as a courtesy). Most of my replies to the ccamp mailing list are off line, because usually replies I send to this list bounce (feel free to ask the list administrator why that happens). I did not realize at the time that (at least one of the) questions that Yangguang posted were actually asked by other people (the posting didn't include this information), or I would have included Gopal, at least. From this reply ensued an off-list discussion that lasted slightly less than a day. I will try to summarize this here (named participants, jump in if you think this summary is fundamentally inaccurate). ======================================================================== Yangguang (on list): There is an ordering issue during resynchronization since the LSPs would depend on other FA-LSPs the interface IDs for which would have been generated dynamically. So the mechanism described will not work, unless this information is preserved across restarts - in which case we might as well preserve other information as well, and avoid resynchronization. Fong (on list): We only need to consider the FA-LSP ingress and egress since the transit nodes do not see signaling for the hierarchical LSP. In the egress reset case, the egress can resolve the ordering based on the fact that it receives a 'recovery' label instead of a suggested label. In the ingress case, the ingress LSR will know the required ordering. You need to resynchronize no matter what because of the possibility of in-progress connection setup. Me (off-list from here on): Ordering problems should not arise because Path messages should not be sent until underlying LSPs are established and interface IDs are known. Resynchronization is both simpler and more likely to work than trying to preserve sufficient state to be able to avoid it. In any case, no implementation should be allowed to assume indefinitely that it has correctly preserved state. Yangguang: For FA-LSPs, are you suggesting the re-start happens between the ingress/egress nodes, instead of its physically adjacent neighbors? Me: 'Ingress', 'egress' and 'adjacent neighbors' are misleading when used with hierarchical LSPs without at least further qualification. Adjacent neighbors (WRT one LSP) have no state relative to 'higher-level' LSPs (these would be seen as lower-level labels by these LSRs). Adjacent neighbors in a higher-level LSP would be the ingress and egress LSRs for lower-level LSPs on which they are based. Fong: No, since the data plane of the FA may still function. The egress node of the FA may receive RSVP packets for the LSP that uses the FA. If the data plane does not function after the restart, we don't even have the dependency problem at all. Me: Yes, higher level LSPs labels can be exchanged before the lower level data plane is established - but cannot be used until the link has been re-established. Moreover, if the signaling for the higher level LSP depends on knowing in advance the way that the link is identified, then signaling will be delayed until the information is available even if the control plane remains active. Yangguang: My question and example all assume the data path is working normally and only the control entity fails. In the example below: ----A------B..B1....C1..C-----D------E----- B and C are FAs, if B's control entity fails and reboots, it has to re-sync with C for LSPs using the B-C tunnel (BC FA-LSP). B must re-sync with both its immediate neighbor B1 and FA C. Then B's re-sync process does have order issue. It should make sure all FA-LSPs are still working and then re-sync with FAs (if they have a way to keep these information and mapping after reboot) for LSPs using the FA-LSPs. Me: Using your example, suppose that the link between A and B goes down, imagine that the labels used by A and B for LSPs across this link are exchanged out of band, and suppose that a means exists by which both A and B expect this link to be restored. Under these circumstances, do not the exact same issues exist as in your example (between B and C)? Yet everyone must know that any labels negotiated between A and B will not be useful until the link is restored. Also, everyone must realize that - if the link IDs are lost as a result of the loss of the link between A & B - the signaling for LSP restoration MUST wait for the link IDs to be re-established. Me (continued): The key difference between a link failure between A and B and B's having a control plane restart (as in your example) is that (in your example) you assume the same technique is used to restore all LSPs involving B. It is not valid to assume - in a reasonable implementation - that all LSPS involving B will be re-established simultaneously. The ordering constraint is a naturally occurring one given that - in any recovery - links must first be re-established, then adjacencies across those links and then any higher level activity. The fact that - without of band signaling - it is possible to signal labels before the data plane is ready to be used in no way implies that it it makes sense to ignore the natural ordering of hierarchical link re-establishment. ======================================================================== I think it is not clear that anything further needs to be specified in the draft with respect to the issue of ordering of LSP re-establishment. Also, with respect to the backward compatibility issue below: it is not impossible for an implementation to be configurable to support either GMPLS based signaling or some existing scheme on a per-interface basis, if that is what you want to do. To my knowledge, there is not so much in the way of current 'lateral' compatibility to be worried that much about backward compatibility. Who in particular should we aim to be backward compatible with, given that few existing solutions are truly compatible with each other? :-) Yangguang wrote: > Yakov, > > Thanks for resenting me the message from Eric. > > Indeed, instead of looking for answers from you, my intention was just trying to > point out some holes in the current proposal and your previous response. And > thanks for just throwing them back to me. > > Again, not trying to add more smoke, just repeat my main point again: there are > existing solid solutions that can satisfy carriers' requirement of preserving > data path and re-create data path state after rebooting. I think many of us are > aware of that. If you are proposing a new mechanism, no matter good or bad, at > least you could consider some "backward" compatibility issues. Meanwhile, even I > have confidence that you can make it work well eventually, there are some corner > cases I'd like to point out. > > And also a piece of suggestion, before claiming a solution for a problem. It's > better to understand the problem well first. There is nothing can replace > working experience of either operating, designing and developing optical > transport network and NEs. > > Yangguang > > Yakov Rekhter wrote: > > > > Yangguang, > > > > > Indeed, you didn't answer my questions. > > > > Perhaps it would be more correct to say that I didn't answer > > your questions *to your satisfaction*. And if that is the case, then > > I hope that the attached e-mail from Eric Gray (that he let me repost > > to the list) would answer your questions to your satisfaction. > > > > > Instead of informed readers, more > > > important is to have better informed writers. > > > > See the attached. > > > > > BTW, I have no intention to let you design my product at all. > > > > Glad to hear this !!! > > > > Yakov. > > --------------------------------------------------------------------- > > Date: Fri, 19 Oct 2001 15:38:58 EDT > > To: Yangguang Xu > > cc: Yakov Rekhter > > From: Eric Gray > > Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) > > > > Yangguang, > > > > Careful, don't let this discussion descend into the nether regions of > > name calling and finger pointing. :-) > > > > The fact that the seeming remote neighbors use RSVP Hello is clear > > once you realize that - for the purposes of hierarchical LSP setup, they > > are adjacent. You may recall this from an off-line discussion we had. > > > > Yakov's comment was simply stating that it is not a part of standard's > > development to make an implementer's cook-book. He was not (I think) > > trying to imply that you could not write your own implementation. He was > > just saying that the effort of achieving interoperability falls on the people > > doing the implementation not on the people doing the standard. The bare > > information is there, but the work is up to you. > > > > As you know, the standard is not complete until several implementations > > have achieved interoperability independently. But the opportunity to get in > > the market stems from being one of those implementations - and there is > > zero motivation for any implementer to make this task easy for all others. > > One of the costs associated with the 'running code' part of IETF mistique > > is that standards are written by implementers. > > > > Unless and until that changes, you just have to learn to deal with it. :-) > > > > You wrote: > > > > > Indeed, you didn't answer my questions. Instead of informed readers, more > > > important is to have better informed writers. > > > > > > BTW, I have no intention to let you design my product at all. > > > > > > Yangguang > > > > > > Yakov Rekhter wrote: > > > > > > > > Yangguang, > > > > > > > > > Yakov, > > > > > > > > > > Further questions in-line. Regards, > > > > > > > > Further responses in-line... > > > > > > > > > Yangguang > > > > > > > > > > > Couple of points: > > > > > > > > > > > > (1) First of all, you do run RSVP Hello between C and F. > > > > > > > > > > Is this specified somewhere? Or it's your proposal. > > > > > > > > What I mentioned in the above should be abundantly obvious to the > > > > informed reader of RSVP and LSP Hierarchy specs. > > > > > > > > > Then, is there a scalability issue here? > > > > > > > > No. > > > > > > > > > Also, C and F could be thousands mile away (in the transport > > > > > network) and the control channel bandwidth is expensive. > > > > > > > > GMPLS assumes that control channel is more than just 56Kbits/sec link. > > > > > > > > Or to put it differently, control channels used by GMPLS have more than > > > > enough capacity for RSVP Hellos. > > > > > > > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > > > > > > be able to recover the Interface ID it assigns to L1 from > > > > > > a combination of (a) the OSPF/ISIS link state database that > > > > > > F would recover, and (b) the Forward Interface ID (the one > > > > > > assigned by C). > > > > > > > > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the > > n it > > > > > has to recover its FA info first. How? > > > > > > > > The answer should be abundantly obvious to the informed reader. > > > > > > > > And to make it crystal clear, I have no intention in designing your > > > > products for you. > > > > > > > > > > > Let us say the node can resynchronize its neighbor if > > > > > > > the neighbor restarts and requests state recovery. But > > > > > > > the issue is how a node can advertise that it does not > > > > > > > need recovery since all its state was preserved? > > > > > > > > > > > > By treating is the same way as the way the spec handles > > > > > > control channel fault. > > > > > > > > > > > > > > > > If a node can recover states from NVRAM or OS (this solution is > > > > > cheaper and have been implemented). It may not implement the spec. > > > > > How could a neighboring node, which implements the spec, not tear > > > > > down data connections mistakenly? Similar to a backward compatibility > > > > > problem, even not. > > > > > > > > Stating the obvious: interoperability with a node that doesn't implement > > > > the spec is outside the scope of the spec. > > > > > > > > > > > RECOVERY LABEL does not come into picture unless the node > > > > > > > that is upstream to the restarting node has already received > > > > > > > a Resv. > > > > > > > > > > > > Wrong. Quoting 9.5.3: > > > > > > > > > > > > Upon detecting a restart with a neighbor that supports state > > > > > > recovery, a node SHOULD refresh all Path state shared with that > > > > > > neighbor. > > > > > > > > > > > > So, as you can hopefully see from the above, the upstream node doesn't > > > > > > wait until it receives a Resv. > > > > > > > > > > > > > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirem > > ent) > > > > > Again, back to the telecom world (sorry about this, yet we are talking ab > > out > > > > > GMPLS), typically only the established pathes are preserved. Pending requ > > ests > > > > > may be purged/aborted. Then how? > > > > > > > > Note the verb is "SHOULD", not "MUST". The rest should be > > > > obvious to the informed reader. > > > > > > > > > > > In case of PSC devices, it may be OK to remove state that > > > > > > > is not resynchronized at the end of the recovery period, > > > > > > > and the recovery period advertised might reflect that. > > > > > > > But for LSPs in transport networks, one might want to > > > > > > > have a different recovery period to avoid any LSP from > > > > > > > going down because of recovery timer expiry. > > > > > > > > > > > > There is no requirement for a node to advertise exactly the > > > > > > same Restart_Cap on all the interfaces. So, on PSC interfaces > > > > > > the node could advertise that it will remove the state that > > > > > > isn't syncronized at the end of the recovery period, while > > > > > > on the TDM interface precisely the same node could advertise > > > > > > that the LSPs would be kept even after the recovery time expires. > > > > > > > > > > > > > > > > So, restart_cap is per interface based? > > > > > > > > yes. > > > > > > > > > Is the spec going to be enhanced/clarified? > > > > > > > > The current spec need not be enhanced/clarified - what I mentioned in the > > > > above should be abundantly obvious to the informed reader. > > > > > > > > > > > The first problems seems to be there still - consider two > > > > > > > adjacent nodes restarting. They both act both as the restarting > > > > > > > node as well as the neighbor to the restarting node. So, once > > > > > > > they learn the state from the upstream neighbor, do they use > > > > > > > suggested label or the recovery label when they send the path > > > > > > > message to the just restarted downstream neighbor? > > > > > > > > > > > > The recovery label. > > > > > > > > > > > > The following should be added to the existing text from the document: > > > > > > > > > > > > In the special case where a restarting node also has a restating > > > > > > downstream neighbor, a Recovery_Label object should be used instead > > > > > > of a Suggested_Label object. > > > > > > > > > > How does a recovering NE know that its neighbor is also recovering? it ma > > y > > > > > lose the instance number totally > > > > > > > > It's advertised in the neighbor's hellos. > > > > > > > > Yakov. > > > > -- > > Eric Gray (mailto:eric.gray@sandburst.com) > > http://www.mindspring.com/~ewgray -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 15:53:03 -0700 Message-ID: <710197BD5AF9D4119E4400508BCFA13601B5FFCA@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: Dimitri Papadimitriou Cc: lberger@movaz.com, ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Mon, 22 Oct 2001 18:51:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B4C.188647A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15B4C.188647A0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, One thing to bear in mind with the Bandwidth Encoding values is that they are nothing more than floating point numbers, so I do not see any need to necessarily update them for FiberChannel necessarily - hopefully people are capable of mapping bit rates to floating point without having the mapping explicitly stated in the document. So I infer from this that a FiberChannel LSP Encoding Type is acceptable to all? Ewart > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Monday, October 22, 2001 6:33 PM > To: Tempest, Ewart [SKY:XW44:EXCH] > Cc: lberger@movaz.com; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > Hi Ewart, > > As we speak as individual (or groups of individuals) here i would > rephrase your first sentence as "i think support of ..." the > importance of the support of FC doesn't depend on your private > affiliation. Also if FC is included we would have to update the > Bandwidth values as well. > > Concerning your question i think you have responded by yourself to > it; please check section 3.1.2 of GMPLS-SIG and 2.1.2 of Generalized > RSVP-TE (a mention could be considered). > > Regards, > Dimitri. > > > Ewart Tempest wrote: > > > > Dimitri, > > > > Yes, Nortel requires support for FiberChannel. There should be no > > issues with this - it is merely a different physical layer. > If not all > > LSRs within a network support it, then fine, it will not be > capable of > > setting up an LSP with this encoding type (unless a technology > > transformation is applied by an LSR, typically the ingress LSR or > > delegate device, to effectively tunnel through a network > that does not > > support this LSP Encoding Type). > > > > As far as GE goes, a GE port is not interoperable with a 100BaseT > > Ethernet port is not interoperable with a 10BaseT Ethernet port ... > > etc. So to have these all lumped in one generic Ethernet 802.3 > > umbrella may or may not make sense depending on the > original intent of > > the LSP Encoding Type (not clear from the document). If I were the > > destination of an LSP, I would want to make sure that the LSP > > requested was being terminated on an appropriately capable > port given > > the LSP Encoding Type and G-PID supplied. If all I am given is > > Ethernet 802.3, how do I know whether this refers to GE, 10BaseT or > > 100BaseT (or should this be inferred from the bandwidth specified in > > the SENDER_TSPEC object)? In fact, one could argue that the > egress LSR > > might need to know this information too, since it is the one that > > selects the port/link to the LSP destination. If the SENDER_TSPEC is > > to be used to distinguish between the various Ethernet > flavours, then > > a mention of this in section 3.1.1 would be helpful, and I > would then > > agree with you that a separate LSP Encoding Type for GE is not > > required. > > > > Ewart > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > > [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Monday, October 22, 2001 2:47 PM > > > To: Tempest, Ewart [SKY:XW44:EXCH] > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > > > > Hi Ewart, > > > > > > If you take a look on the IEEE Standards you will see > > > that GE is referred to as > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > > - 802.3ae for 10Gbps (see below [2]) > > > > > > So my question is what do you have in mind ? to separate > > > these values ? > > > > > > Thanks, > > > Dimitri. > > > > > > PS: for FiberChannel sorry i am not an expert but is someone > > > targeting to use GMPLS for FiberChannel LSP ? > > > > > > ------- > > > > > > [1] From - http://standards.ieee.org > > > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and > > minimal > > > augmentation of its operation, physical layer > > > characteristics, repeater > > > functions and management parameters for transfer of 802.3 and > > > Ethernet > > > format frames at 1,000 Mb/s. > > > > > > Project purpose: The purpose of this project is to extend > the 802.3 > > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > > significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of CSMA/CD nodes, previous investment in > > > research > > > and development, and principles of network operation and > management. > > > > > > > > [2] From - http://standards.ieee.org > > > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters > > and > > > minimal augmentation of its operation, physical layer > > characteristics > > > and management parameters for transfer of LLC and Ethernet format > > > frames at 10 Gb/s using full duplex operation as defined in the > > 802.3 > > > standard. In addition to the traditional LAN space, add > > > parameters and > > > mechanisms that enable deployment of Ethernet over the Wide > > > Area Network > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > > payload > > > rate. > > > > > > Project purpose: The purpose of this project is to extend > the 802.3 > > > protocol to an operating speed of 10 Gb/s and to expand > the Ethernet > > > > > application space to include Wide Area Network links in order > > > to provide > > > a significant increase in bandwidth while maintaining maximum > > > compatibility > > > with the installed base of 802.3 interfaces, previous > investment in > > > research > > > and development, and principles of network operation and > management. > > > > > > > > ------- > > > > > > > Ewart Tempest wrote: > > > > > > > > Lou, > > > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 > > can > > > > you please add additonal LSP Encoding Types for GE and > > FiberChannel. > > > > GE is not really covered by the existing Ethernet > related encoding > > > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > > > Ewart > > > > ------_=_NextPart_001_01C15B4C.188647A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Generalized Signaling - LSP Encoding Type expansion

Dimitri,

One thing to bear in mind with the Bandwidth Encoding = values is that they are nothing more than floating point numbers, so I = do not see any need to necessarily update them for FiberChannel = necessarily - hopefully people are capable of mapping bit rates to = floating point without having the mapping explicitly stated in the = document. So I infer from this that a FiberChannel LSP Encoding Type is = acceptable to all?

Ewart

> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:dimitri.papadimi= triou@alcatel.be]
> Sent: Monday, October 22, 2001 6:33 PM
> To: Tempest, Ewart [SKY:XW44:EXCH]
> Cc: lberger@movaz.com; = ccamp@ops.ietf.org
> Subject: Re: Generalized Signaling - LSP = Encoding Type expansion
>
>
> Hi Ewart,
>
> As we speak as individual (or groups of = individuals) here i would
> rephrase your first sentence as "i think = support of ..." the
> importance of the support of FC doesn't depend = on your private
> affiliation. Also if FC is included we would = have to update the
> Bandwidth values as well.
>
> Concerning your question i think you have = responded by yourself to
> it; please check section 3.1.2 of GMPLS-SIG and = 2.1.2 of Generalized
> RSVP-TE (a mention could be considered). =
>
> Regards,
> Dimitri.
>
> > Ewart Tempest wrote:
> >
> > Dimitri,
> >
> > Yes, Nortel requires support for = FiberChannel. There should be no
> > issues with this - it is merely a = different physical layer.
> If not all
> > LSRs within a network support it, then = fine, it will not be
> capable of
> > setting up an LSP with this encoding type = (unless a technology
> > transformation is applied by an LSR, = typically the ingress LSR or
> > delegate device, to effectively tunnel = through a network
> that does not
> > support this LSP Encoding Type).
> >
> > As far as GE goes, a GE port is not = interoperable with a 100BaseT
> > Ethernet port is not interoperable with a = 10BaseT Ethernet port ...
> > etc. So to have these all lumped in one = generic Ethernet 802.3
> > umbrella may or may not make sense = depending on the
> original intent of
> > the LSP Encoding Type (not clear from the = document). If I were the
> > destination of an LSP, I would want to = make sure that the LSP
> > requested was being terminated on an = appropriately capable
> port given
> > the LSP Encoding Type and G-PID supplied. = If all I am given is
> > Ethernet 802.3, how do I know whether this = refers to GE, 10BaseT or
> > 100BaseT (or should this be inferred from = the bandwidth specified in
> > the SENDER_TSPEC object)? In fact, one = could argue that the
> egress LSR
> > might need to know this information too, = since it is the one that
> > selects the port/link to the LSP = destination. If the SENDER_TSPEC is
> > to be used to distinguish between the = various Ethernet
> flavours, then
> > a mention of this in section 3.1.1 would = be helpful, and I
> would then
> > agree with you that a separate LSP = Encoding Type for GE is not
> > required.
> >
> > Ewart
> >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou
> > [mailto:dimitri.papadimi= triou@alcatel.be]
> > > Sent: Monday, October 22, 2001 2:47 = PM
> > > To: Tempest, Ewart = [SKY:XW44:EXCH]
> > > Cc: lberger@movaz.com; = ccamp@ops.ietf.org
> > > Subject: Re: Generalized Signaling - = LSP Encoding Type expansion
> > >
> > >
> > > Hi Ewart,
> > >
> > > If you take a look on the IEEE = Standards you will see
> > > that GE is referred to as
> > > - 802.3z for 1Gbps (see below [1]) = same exists for copper 802.3ab
> > > - 802.3ae for 10Gbps (see below = [2])
> > >
> > > So my question is what do you have in = mind ? to separate
> > > these values ?
> > >
> > > Thanks,
> > > Dimitri.
> > >
> > > PS: for FiberChannel sorry i am not = an expert but is someone
> > >     targeting to = use GMPLS for FiberChannel LSP ?
> > >
> > > -------
> > >
> > > [1] From - http://standards.ieee.org
> > >
> > > Project scope: Define Carrier Sense = Multiple Access with Collision
> > > Detection (CSMA/CD) Media Access = Control (MAC) parameters and
> > minimal
> > > augmentation of its operation, = physical layer
> > > characteristics, repeater
> > > functions and management parameters = for transfer of 802.3 and
> > > Ethernet
> > > format frames at 1,000 Mb/s.
> > >
> > > Project purpose: The purpose of this = project is to extend
> the 802.3
> > > protocol to an operating speed of = 1,000 Mb/s in order to provide a
> > > significant increase in bandwidth = while maintaining maximum
> > > compatibility
> > > with the installed base of CSMA/CD = nodes, previous investment in
> > > research
> > > and development, and principles of = network operation and
> management.
> >
> > >
> > > [2] From - http://standards.ieee.org
> > >
> > > Project scope: Define 802.3 Media = Access Control (MAC) parameters
> > and
> > > minimal augmentation of its = operation, physical layer
> > characteristics
> > > and management parameters for = transfer of LLC and Ethernet format
> > > frames at 10 Gb/s using full duplex = operation as defined in the
> > 802.3
> > > standard. In addition to the = traditional LAN space, add
> > > parameters and
> > > mechanisms that enable deployment of = Ethernet over the Wide
> > > Area Network
> > > operating at a data rate compatible = with OC-192c and SDH VC-4-64c
> > > payload
> > > rate.
> > >
> > > Project purpose: The purpose of this = project is to extend
> the 802.3
> > > protocol to an operating speed of 10 = Gb/s and to expand
> the Ethernet
> >
> > > application space to include Wide = Area Network links in order
> > > to provide
> > > a significant increase in bandwidth = while maintaining maximum
> > > compatibility
> > > with the installed base of 802.3 = interfaces, previous
> investment in
> > > research
> > > and development, and principles of = network operation and
> management.
> >
> > >
> > > -------
> > >
> > > > Ewart Tempest wrote:
> > > >
> > > > Lou,
> > > >
> > > > Within section 3.1.1 of = draft-ietf-mpls-generalized-signaling-06
> > can
> > > > you please add additonal LSP = Encoding Types for GE and
> > FiberChannel.
> > > > GE is not really covered by the = existing Ethernet
> related encoding
> >
> > > > types, and FiberChannel is not = covered at all. Thanks.
> > > >
> > > > Ewart
> > >
>

------_=_NextPart_001_01C15B4C.188647A0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 15:35:12 -0700 Message-ID: From: Yanhe Fan To: "'Maarten Vissers'" Cc: "'Zhi-Wei Lin'" , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Mon, 22 Oct 2001 18:34:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Maarten, A GMPLS label carries the info that can be used to configured the crossconnets on a node. If the GMPLS neighboring nodes are connected by normal links, the label identifies the time slots on both sides and therefore, it can be used without any conversion. If the links between the two nodes are not normal links, but a series compounded links (No matter how many no-switched nodes they traverse), the label, in this case, identifies the time slots only on one side, not both sides. This is what I mean by "breaking the label association". The other side will convert the label into the local time slots before configuring the hardware. In order to do this, some additional info is needed. This is what I mean by "rebuild the label association". This can be done by configuration, a protocol, etc. The connection tuples in your example can be used for this regarding as well. Regards, Yanhe -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Monday, October 22, 2001 5:07 PM To: Yanhe Fan Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... Yanhe, The situation Zhi describes is one that will be very typical in the optical (SDH/SONET) network in the coming years. We will most likely see islands of switched subnetworks interconnected via the existing SDH/SONET non-switched networks. By means of management actions, links (GMPLS: link bundles) will be setup between an edge node in one switched subnetwork and an other edge node in the next switched subnetwork. In G.805 terminology, these links are so called serial compound links. The switched subnetworks will treat these serial compound links as normal links, "ignoring" the intermediate non-switched nodes they traverse. These links will contain a fixed set of link connections, which are identified by their respective endpoints at nodes A and Z (i.e. SNPa - SNPz). The server signal that carries the e.g. 5 STS1 link connections in the link at A can be an OC12, whereas this can be an OC48 at Z. During discovery or by means of provisioning both A and Z nodes get aware of the 5 sTS1 link connections as tuples of e.g. SNPa SNPz ----------------------------------- - port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) - port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) - port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) - port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) - port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) As both ends of the link build up this same relation information, it is possible to use as link connection identifier only one of the two SNPs. E.g. node A identifies the STS1 link connection #1 by means of "Ai/T1" and sends this info to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". Vice versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when received by node A, this will be converted into Ai/T1. For GMPLS this implies that the GMPLS label doesn't identify the timeslot at both ends of the link connection, only the timeslot at the sending end. The receiving end needs to convert this then into its local timeslot number. Regards, Maarten Yanhe Fan wrote: > > Hi Zhi, > > What B does is breaking the label association between A and C by crossing > connect > the time slots. > > If the cross connect performed by B is fixed (in your case), what needs to > do is > just to rebuild the label association by configuration or a protocol such as > LMP; > If the cross connect is not fixed but dynamic, the best thing to do is to > make B > a GMPLS speaker. Tell this to the 1.000.000+ SDH/SONET network elements in today's transport network... no chance... those will stay non-switched... You maybe miss "If the cross connect is NOT fixed BUT dynamic" and please see the above respond. > > Yanhe > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Friday, October 19, 2001 6:01 PM > To: Yanhe Fan > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Hi Yanhe, > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > is simply part of the network that made up the "dumb" pipe. And because > the control plane control channel is separate, A and C can be adjacent > without ever knowing who B is or that even B existed. From A and C's > point of view, the network looks like: > > A ----- C > > Think of the case of how a BGP sees an area. If an area is made up of: > > A -- B -- C > > and B is internal router, does BGP "see" B? > > Zhi > > Yanhe Fan wrote: > > > Hi, Zhi > > > > > >>For the label value for SONET/SDH or the label description in the > >>generic draft, the label is defined as directly representing the > >>"timeslot". Now if I have a control plane controlled transport network > >>that goes through a ADM that is not control plane controlled, as: > >> > >> > >>+--------+ +--------+ +--------+ > >>| | ---1--------- | | ----1-------- | | > >>| | ---2--------- | | ----2-------- | | > >>| A | ---3--------- | B | ----3-------- | C | > >>| | ---4--------- | | ----4-------- | | > >>| | ---5--------- | | ----5-------- | | > >>+--------+ +--------+ +--------+ > >> > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C > >>has labels 1,2,3,4,5 incoming. > >> > >>Now imagine that at B, it actually has a fixed cross-connect that > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >> > >>Now when A GMPLS sends a message to C, the label it uses is "1". > >>However, the connection/LSP associated with timeslot "1" is actually the > >>label of timeslot "2" at C. > >> > > > > In this case, you're trying to use GMPLS to setup an LSP cross a node (B) > > which can't understand GMPLS. > > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > > GMPLS if B can't understand GMPLS? > > > > Now imagine A and B are LSRs, and B is a conventional router (can't > > understand > > MPLS), can you setup an LSP A-B-C? > > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > > understand PNNI at all? > > > > My point is that in order to make you case work, some additional work need > > to > > be done besie simply using GMPLS as singnaling protocol, becase some node > on > > the path is not GMPLS speakers. A and C needs the info of time slot > aligment > > > > between them. This can be done by some configurations, some link > management > > protocls (LMP maybe) etc. As long as A and C have this piece of info, > > eveything > > works fine. > > > > Yanhe > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 15:34:43 -0700 Message-ID: <3BD49E83.A0136A8@alcatel.be> Date: Tue, 23 Oct 2001 00:32:35 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Ewart Tempest CC: lberger@movaz.com, ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: multipart/mixed; boundary="------------3676A15E4158D2233563CF17" This is a multi-part message in MIME format. --------------3676A15E4158D2233563CF17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ewart, As we speak as individual (or groups of individuals) here i would rephrase your first sentence as "i think support of ..." the importance of the support of FC doesn't depend on your private affiliation. Also if FC is included we would have to update the Bandwidth values as well. Concerning your question i think you have responded by yourself to it; please check section 3.1.2 of GMPLS-SIG and 2.1.2 of Generalized RSVP-TE (a mention could be considered). Regards, Dimitri. > Ewart Tempest wrote: > > Dimitri, > > Yes, Nortel requires support for FiberChannel. There should be no > issues with this - it is merely a different physical layer. If not all > LSRs within a network support it, then fine, it will not be capable of > setting up an LSP with this encoding type (unless a technology > transformation is applied by an LSR, typically the ingress LSR or > delegate device, to effectively tunnel through a network that does not > support this LSP Encoding Type). > > As far as GE goes, a GE port is not interoperable with a 100BaseT > Ethernet port is not interoperable with a 10BaseT Ethernet port ... > etc. So to have these all lumped in one generic Ethernet 802.3 > umbrella may or may not make sense depending on the original intent of > the LSP Encoding Type (not clear from the document). If I were the > destination of an LSP, I would want to make sure that the LSP > requested was being terminated on an appropriately capable port given > the LSP Encoding Type and G-PID supplied. If all I am given is > Ethernet 802.3, how do I know whether this refers to GE, 10BaseT or > 100BaseT (or should this be inferred from the bandwidth specified in > the SENDER_TSPEC object)? In fact, one could argue that the egress LSR > might need to know this information too, since it is the one that > selects the port/link to the LSP destination. If the SENDER_TSPEC is > to be used to distinguish between the various Ethernet flavours, then > a mention of this in section 3.1.1 would be helpful, and I would then > agree with you that a separate LSP Encoding Type for GE is not > required. > > Ewart > > > -----Original Message----- > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Monday, October 22, 2001 2:47 PM > > To: Tempest, Ewart [SKY:XW44:EXCH] > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > > > Hi Ewart, > > > > If you take a look on the IEEE Standards you will see > > that GE is referred to as > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > - 802.3ae for 10Gbps (see below [2]) > > > > So my question is what do you have in mind ? to separate > > these values ? > > > > Thanks, > > Dimitri. > > > > PS: for FiberChannel sorry i am not an expert but is someone > > targeting to use GMPLS for FiberChannel LSP ? > > > > ------- > > > > [1] From - http://standards.ieee.org > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > Detection (CSMA/CD) Media Access Control (MAC) parameters and > minimal > > augmentation of its operation, physical layer > > characteristics, repeater > > functions and management parameters for transfer of 802.3 and > > Ethernet > > format frames at 1,000 Mb/s. > > > > Project purpose: The purpose of this project is to extend the 802.3 > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > significant increase in bandwidth while maintaining maximum > > compatibility > > with the installed base of CSMA/CD nodes, previous investment in > > research > > and development, and principles of network operation and management. > > > > > [2] From - http://standards.ieee.org > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters > and > > minimal augmentation of its operation, physical layer > characteristics > > and management parameters for transfer of LLC and Ethernet format > > frames at 10 Gb/s using full duplex operation as defined in the > 802.3 > > standard. In addition to the traditional LAN space, add > > parameters and > > mechanisms that enable deployment of Ethernet over the Wide > > Area Network > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > payload > > rate. > > > > Project purpose: The purpose of this project is to extend the 802.3 > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > > application space to include Wide Area Network links in order > > to provide > > a significant increase in bandwidth while maintaining maximum > > compatibility > > with the installed base of 802.3 interfaces, previous investment in > > research > > and development, and principles of network operation and management. > > > > > ------- > > > > > Ewart Tempest wrote: > > > > > > Lou, > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 > can > > > you please add additonal LSP Encoding Types for GE and > FiberChannel. > > > GE is not really covered by the existing Ethernet related encoding > > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > Ewart > > --------------3676A15E4158D2233563CF17 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------3676A15E4158D2233563CF17-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 15:13:37 -0700 Message-ID: <3BD49999.87DF1724@nayna.com> Date: Mon, 22 Oct 2001 15:11:37 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Zhi-Wei Lin CC: Yakov Rekhter , Yangguang Xu , ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi: draft-ietf-ccamp-gmpls-architecture-00.txt provides some of the information you may be looking for... Cheers, sudheer Zhi-Wei Lin wrote: > Hi Yakov, > > Thanks for your response. Very informative. Can I ask how an uninformed > reader get to become informed if the docs in question cannot give the > info (and I'm assuming there are no textbooks or university courses to > take)...? > > As for the response from Eric, thanks for that info. Can I also ask for > an uninformed implementor how exactly they go about getting informed? > Any pointers or documents that you can point to? > > Zhi > > Yakov Rekhter wrote: > > > Zhi-Wei, > > > > > >>Just to be clear, I am definitely one of the uninformed readers since I > >>have joined IETF not so long ago (not everyone is part of IETF when it > >>first started unfortunately). So Yakov, if you would be so kind as to > >>inform an uninformed reader that would be very very much appreciated. > >> > > > > There are few points I'd like to make to an uninformed reader: > > > > 1. As was pointed the other day by Dimitri Papadimitriou, > > GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG". > > > > 2. As was also pointed out in the same e-mail from Dimitri, > > "we can not wait until everybody in this world has no question anymore > > or a full understanding on any technical detail in order to go forward". > > > > 3. Finally, please read the attached e-mail from Eric Gray to your > > collegue from Lucent. > > > > Yakov. > > ------------------------------------------------------------------------- > > Date: Fri, 19 Oct 2001 15:38:58 EDT > > To: Yangguang Xu > > cc: Yakov Rekhter > > From: Eric Gray > > Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) > > > > Yangguang, > > > > Careful, don't let this discussion descend into the nether regions of > > name calling and finger pointing. :-) > > > > The fact that the seeming remote neighbors use RSVP Hello is clear > > once you realize that - for the purposes of hierarchical LSP setup, they > > are adjacent. You may recall this from an off-line discussion we had. > > > > Yakov's comment was simply stating that it is not a part of standard's > > development to make an implementer's cook-book. He was not (I think) > > trying to imply that you could not write your own implementation. He was > > just saying that the effort of achieving interoperability falls on the people > > doing the implementation not on the people doing the standard. The bare > > information is there, but the work is up to you. > > > > As you know, the standard is not complete until several implementations > > have achieved interoperability independently. But the opportunity to get in > > the market stems from being one of those implementations - and there is > > zero motivation for any implementer to make this task easy for all others. > > One of the costs associated with the 'running code' part of IETF mistique > > is that standards are written by implementers. > > > > Unless and until that changes, you just have to learn to deal with it. :-) > > > > You wrote: > > > > > >>Indeed, you didn't answer my questions. Instead of informed readers, more > >>important is to have better informed writers. > >> > >>BTW, I have no intention to let you design my product at all. > >> > >>Yangguang > >> > >>Yakov Rekhter wrote: > >> > >>>Yangguang, > >>> > >>> > >>>>Yakov, > >>>> > >>>>Further questions in-line. Regards, > >>>> > >>>Further responses in-line... > >>> > >>> > >>>>Yangguang > >>>> > >>>> > >>>>>Couple of points: > >>>>> > >>>>>(1) First of all, you do run RSVP Hello between C and F. > >>>>> > >>>>Is this specified somewhere? Or it's your proposal. > >>>> > >>>What I mentioned in the above should be abundantly obvious to the > >>>informed reader of RSVP and LSP Hierarchy specs. > >>> > >>> > >>>>Then, is there a scalability issue here? > >>>> > >>>No. > >>> > >>> > >>>>Also, C and F could be thousands mile away (in the transport > >>>>network) and the control channel bandwidth is expensive. > >>>> > >>>GMPLS assumes that control channel is more than just 56Kbits/sec link. > >>> > >>>Or to put it differently, control channels used by GMPLS have more than > >>>enough capacity for RSVP Hellos. > >>> > >>> > >>>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should > >>>>>be able to recover the Interface ID it assigns to L1 from > >>>>>a combination of (a) the OSPF/ISIS link state database that > >>>>>F would recover, and (b) the Forward Interface ID (the one > >>>>>assigned by C). > >>>>> > >>>>Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the > >>>> > > n it > > > >>>>has to recover its FA info first. How? > >>>> > >>>The answer should be abundantly obvious to the informed reader. > >>> > >>>And to make it crystal clear, I have no intention in designing your > >>>products for you. > >>> > >>> > >>>>>>Let us say the node can resynchronize its neighbor if > >>>>>>the neighbor restarts and requests state recovery. But > >>>>>>the issue is how a node can advertise that it does not > >>>>>>need recovery since all its state was preserved? > >>>>>> > >>>>>By treating is the same way as the way the spec handles > >>>>>control channel fault. > >>>>> > >>>>> > >>>>If a node can recover states from NVRAM or OS (this solution is > >>>>cheaper and have been implemented). It may not implement the spec. > >>>>How could a neighboring node, which implements the spec, not tear > >>>>down data connections mistakenly? Similar to a backward compatibility > >>>>problem, even not. > >>>> > >>>Stating the obvious: interoperability with a node that doesn't implement > >>>the spec is outside the scope of the spec. > >>> > >>> > >>>>>>RECOVERY LABEL does not come into picture unless the node > >>>>>>that is upstream to the restarting node has already received > >>>>>>a Resv. > >>>>>> > >>>>>Wrong. Quoting 9.5.3: > >>>>> > >>>>> Upon detecting a restart with a neighbor that supports state > >>>>> recovery, a node SHOULD refresh all Path state shared with that > >>>>> neighbor. > >>>>> > >>>>>So, as you can hopefully see from the above, the upstream node doesn't > >>>>>wait until it receives a Resv. > >>>>> > >>>>> > >>>>Then this may not meet carriers' requirement. (see IPO carriers' requirem > >>>> > > ent) > > > >>>>Again, back to the telecom world (sorry about this, yet we are talking ab > >>>> > > out > > > >>>>GMPLS), typically only the established pathes are preserved. Pending requ > >>>> > > ests > > > >>>>may be purged/aborted. Then how? > >>>> > >>>Note the verb is "SHOULD", not "MUST". The rest should be > >>>obvious to the informed reader. > >>> > >>> > >>>>>>In case of PSC devices, it may be OK to remove state that > >>>>>>is not resynchronized at the end of the recovery period, > >>>>>>and the recovery period advertised might reflect that. > >>>>>>But for LSPs in transport networks, one might want to > >>>>>>have a different recovery period to avoid any LSP from > >>>>>>going down because of recovery timer expiry. > >>>>>> > >>>>>There is no requirement for a node to advertise exactly the > >>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces > >>>>>the node could advertise that it will remove the state that > >>>>>isn't syncronized at the end of the recovery period, while > >>>>>on the TDM interface precisely the same node could advertise > >>>>>that the LSPs would be kept even after the recovery time expires. > >>>>> > >>>>> > >>>>So, restart_cap is per interface based? > >>>> > >>>yes. > >>> > >>> > >>>>Is the spec going to be enhanced/clarified? > >>>> > >>>The current spec need not be enhanced/clarified - what I mentioned in the > >>>above should be abundantly obvious to the informed reader. > >>> > >>> > >>>>>>The first problems seems to be there still - consider two > >>>>>>adjacent nodes restarting. They both act both as the restarting > >>>>>>node as well as the neighbor to the restarting node. So, once > >>>>>>they learn the state from the upstream neighbor, do they use > >>>>>>suggested label or the recovery label when they send the path > >>>>>>message to the just restarted downstream neighbor? > >>>>>> > >>>>>The recovery label. > >>>>> > >>>>>The following should be added to the existing text from the document: > >>>>> > >>>>> In the special case where a restarting node also has a restating > >>>>> downstream neighbor, a Recovery_Label object should be used instead > >>>>> of a Suggested_Label object. > >>>>> > >>>>How does a recovering NE know that its neighbor is also recovering? it ma > >>>> > > y > > > >>>>lose the instance number totally > >>>> > >>>It's advertised in the neighbor's hellos. > >>> > >>>Yakov. > >>> > > > > -- > > Eric Gray (mailto:eric.gray@sandburst.com) > > http://www.mindspring.com/~ewgray > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 15:01:49 -0700 Message-ID: <710197BD5AF9D4119E4400508BCFA13601B5FF95@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: Dimitri Papadimitriou Cc: lberger@movaz.com, ccamp@ops.ietf.org, "Ewart Tempest" Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Mon, 22 Oct 2001 17:58:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B44.BF6E1190" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15B44.BF6E1190 Content-Type: text/plain; charset="iso-8859-1" Dimitri, Yes, Nortel requires support for FiberChannel. There should be no issues with this - it is merely a different physical layer. If not all LSRs within a network support it, then fine, it will not be capable of setting up an LSP with this encoding type (unless a technology transformation is applied by an LSR, typically the ingress LSR or delegate device, to effectively tunnel through a network that does not support this LSP Encoding Type). As far as GE goes, a GE port is not interoperable with a 100BaseT Ethernet port is not interoperable with a 10BaseT Ethernet port ... etc. So to have these all lumped in one generic Ethernet 802.3 umbrella may or may not make sense depending on the original intent of the LSP Encoding Type (not clear from the document). If I were the destination of an LSP, I would want to make sure that the LSP requested was being terminated on an appropriately capable port given the LSP Encoding Type and G-PID supplied. If all I am given is Ethernet 802.3, how do I know whether this refers to GE, 10BaseT or 100BaseT (or should this be inferred from the bandwidth specified in the SENDER_TSPEC object)? In fact, one could argue that the egress LSR might need to know this information too, since it is the one that selects the port/link to the LSP destination. If the SENDER_TSPEC is to be used to distinguish between the various Ethernet flavours, then a mention of this in section 3.1.1 would be helpful, and I would then agree with you that a separate LSP Encoding Type for GE is not required. Ewart > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Monday, October 22, 2001 2:47 PM > To: Tempest, Ewart [SKY:XW44:EXCH] > Cc: lberger@movaz.com; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > Hi Ewart, > > If you take a look on the IEEE Standards you will see > that GE is referred to as > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > - 802.3ae for 10Gbps (see below [2]) > > So my question is what do you have in mind ? to separate > these values ? > > Thanks, > Dimitri. > > PS: for FiberChannel sorry i am not an expert but is someone > targeting to use GMPLS for FiberChannel LSP ? > > ------- > > [1] From - http://standards.ieee.org > > Project scope: Define Carrier Sense Multiple Access with Collision > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > augmentation of its operation, physical layer > characteristics, repeater > functions and management parameters for transfer of 802.3 and > Ethernet > format frames at 1,000 Mb/s. > > Project purpose: The purpose of this project is to extend the 802.3 > protocol to an operating speed of 1,000 Mb/s in order to provide a > significant increase in bandwidth while maintaining maximum > compatibility > with the installed base of CSMA/CD nodes, previous investment in > research > and development, and principles of network operation and management. > > [2] From - http://standards.ieee.org > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > minimal augmentation of its operation, physical layer characteristics > and management parameters for transfer of LLC and Ethernet format > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > standard. In addition to the traditional LAN space, add > parameters and > mechanisms that enable deployment of Ethernet over the Wide > Area Network > operating at a data rate compatible with OC-192c and SDH VC-4-64c > payload > rate. > > Project purpose: The purpose of this project is to extend the 802.3 > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > application space to include Wide Area Network links in order > to provide > a significant increase in bandwidth while maintaining maximum > compatibility > with the installed base of 802.3 interfaces, previous investment in > research > and development, and principles of network operation and management. > > ------- > > > Ewart Tempest wrote: > > > > Lou, > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > GE is not really covered by the existing Ethernet related encoding > > types, and FiberChannel is not covered at all. Thanks. > > > > Ewart > ------_=_NextPart_001_01C15B44.BF6E1190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Generalized Signaling - LSP Encoding Type expansion

Dimitri,

Yes, Nortel requires support for FiberChannel. There = should be no issues with this - it is merely a different physical = layer. If not all LSRs within a network support it, then fine, it will = not be capable of setting up an LSP with this encoding type (unless a = technology transformation is applied by an LSR, typically the ingress = LSR or delegate device, to effectively tunnel through a network that = does not support this LSP Encoding Type).

As far as GE goes, a GE port is not interoperable = with a 100BaseT Ethernet port is not interoperable with a 10BaseT = Ethernet port ... etc. So to have these all lumped in one generic = Ethernet 802.3 umbrella may or may not make sense depending on the = original intent of the LSP Encoding Type (not clear from the document). = If I were the destination of an LSP, I would want to make sure that the = LSP requested was being terminated on an appropriately capable port = given the LSP Encoding Type and G-PID supplied. If all I am given is = Ethernet 802.3, how do I know whether this refers to GE, 10BaseT or = 100BaseT (or should this be inferred from the bandwidth specified in = the SENDER_TSPEC object)? In fact, one could argue that the egress LSR = might need to know this information too, since it is the one that = selects the port/link to the LSP destination. If the SENDER_TSPEC is to = be used to distinguish between the various Ethernet flavours, then a = mention of this in section 3.1.1 would be helpful, and I would then = agree with you that a separate LSP Encoding Type for GE is not = required.

Ewart

> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:dimitri.papadimi= triou@alcatel.be]
> Sent: Monday, October 22, 2001 2:47 PM
> To: Tempest, Ewart [SKY:XW44:EXCH]
> Cc: lberger@movaz.com; = ccamp@ops.ietf.org
> Subject: Re: Generalized Signaling - LSP = Encoding Type expansion
>
>
> Hi Ewart,
>
> If you take a look on the IEEE Standards you = will see
> that GE is referred to as
> - 802.3z for 1Gbps (see below [1]) same exists = for copper 802.3ab
> - 802.3ae for 10Gbps (see below [2])
>
> So my question is what do you have in mind ? to = separate
> these values ?
>
> Thanks,
> Dimitri.
>
> PS: for FiberChannel sorry i am not an expert = but is someone
>     targeting to use GMPLS = for FiberChannel LSP ?
>
> -------
>
> [1] From - http://standards.ieee.org
>
> Project scope: Define Carrier Sense Multiple = Access with Collision
> Detection (CSMA/CD) Media Access Control (MAC) = parameters and minimal
> augmentation of its operation, physical layer =
> characteristics, repeater
> functions and management parameters for = transfer of 802.3 and
> Ethernet
> format frames at 1,000 Mb/s.
>
> Project purpose: The purpose of this project is = to extend the 802.3
> protocol to an operating speed of 1,000 Mb/s in = order to provide a
> significant increase in bandwidth while = maintaining maximum
> compatibility
> with the installed base of CSMA/CD nodes, = previous investment in
> research
> and development, and principles of network = operation and management.
>
> [2] From - http://standards.ieee.org
>
> Project scope: Define 802.3 Media Access = Control (MAC) parameters and
> minimal augmentation of its operation, physical = layer characteristics
> and management parameters for transfer of LLC = and Ethernet format
> frames at 10 Gb/s using full duplex operation = as defined in the 802.3
> standard. In addition to the traditional LAN = space, add
> parameters and
> mechanisms that enable deployment of Ethernet = over the Wide
> Area Network
> operating at a data rate compatible with = OC-192c and SDH VC-4-64c
> payload
> rate.
>
> Project purpose: The purpose of this project is = to extend the 802.3
> protocol to an operating speed of 10 Gb/s and = to expand the Ethernet
> application space to include Wide Area Network = links in order
> to provide
> a significant increase in bandwidth while = maintaining maximum
> compatibility
> with the installed base of 802.3 interfaces, = previous investment in
> research
> and development, and principles of network = operation and management.
>
> -------
>
> > Ewart Tempest wrote:
> >
> > Lou,
> >
> > Within section 3.1.1 of = draft-ietf-mpls-generalized-signaling-06 can
> > you please add additonal LSP Encoding = Types for GE and FiberChannel.
> > GE is not really covered by the existing = Ethernet related encoding
> > types, and FiberChannel is not covered at = all. Thanks.
> >
> > Ewart
>

------_=_NextPart_001_01C15B44.BF6E1190-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 14:43:50 -0700 Message-ID: <3BD492C5.3040107@lucent.com> Date: Mon, 22 Oct 2001 17:42:29 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yakov Rekhter CC: Yangguang Xu , ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Yakov, Thanks for your response. Very informative. Can I ask how an uninformed reader get to become informed if the docs in question cannot give the info (and I'm assuming there are no textbooks or university courses to take)...? As for the response from Eric, thanks for that info. Can I also ask for an uninformed implementor how exactly they go about getting informed? Any pointers or documents that you can point to? Zhi Yakov Rekhter wrote: > Zhi-Wei, > > >>Just to be clear, I am definitely one of the uninformed readers since I >>have joined IETF not so long ago (not everyone is part of IETF when it >>first started unfortunately). So Yakov, if you would be so kind as to >>inform an uninformed reader that would be very very much appreciated. >> > > There are few points I'd like to make to an uninformed reader: > > 1. As was pointed the other day by Dimitri Papadimitriou, > GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG". > > 2. As was also pointed out in the same e-mail from Dimitri, > "we can not wait until everybody in this world has no question anymore > or a full understanding on any technical detail in order to go forward". > > 3. Finally, please read the attached e-mail from Eric Gray to your > collegue from Lucent. > > Yakov. > ------------------------------------------------------------------------- > Date: Fri, 19 Oct 2001 15:38:58 EDT > To: Yangguang Xu > cc: Yakov Rekhter > From: Eric Gray > Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) > > Yangguang, > > Careful, don't let this discussion descend into the nether regions of > name calling and finger pointing. :-) > > The fact that the seeming remote neighbors use RSVP Hello is clear > once you realize that - for the purposes of hierarchical LSP setup, they > are adjacent. You may recall this from an off-line discussion we had. > > Yakov's comment was simply stating that it is not a part of standard's > development to make an implementer's cook-book. He was not (I think) > trying to imply that you could not write your own implementation. He was > just saying that the effort of achieving interoperability falls on the people > doing the implementation not on the people doing the standard. The bare > information is there, but the work is up to you. > > As you know, the standard is not complete until several implementations > have achieved interoperability independently. But the opportunity to get in > the market stems from being one of those implementations - and there is > zero motivation for any implementer to make this task easy for all others. > One of the costs associated with the 'running code' part of IETF mistique > is that standards are written by implementers. > > Unless and until that changes, you just have to learn to deal with it. :-) > > You wrote: > > >>Indeed, you didn't answer my questions. Instead of informed readers, more >>important is to have better informed writers. >> >>BTW, I have no intention to let you design my product at all. >> >>Yangguang >> >>Yakov Rekhter wrote: >> >>>Yangguang, >>> >>> >>>>Yakov, >>>> >>>>Further questions in-line. Regards, >>>> >>>Further responses in-line... >>> >>> >>>>Yangguang >>>> >>>> >>>>>Couple of points: >>>>> >>>>>(1) First of all, you do run RSVP Hello between C and F. >>>>> >>>>Is this specified somewhere? Or it's your proposal. >>>> >>>What I mentioned in the above should be abundantly obvious to the >>>informed reader of RSVP and LSP Hierarchy specs. >>> >>> >>>>Then, is there a scalability issue here? >>>> >>>No. >>> >>> >>>>Also, C and F could be thousands mile away (in the transport >>>>network) and the control channel bandwidth is expensive. >>>> >>>GMPLS assumes that control channel is more than just 56Kbits/sec link. >>> >>>Or to put it differently, control channels used by GMPLS have more than >>>enough capacity for RSVP Hellos. >>> >>> >>>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should >>>>>be able to recover the Interface ID it assigns to L1 from >>>>>a combination of (a) the OSPF/ISIS link state database that >>>>>F would recover, and (b) the Forward Interface ID (the one >>>>>assigned by C). >>>>> >>>>Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the >>>> > n it > >>>>has to recover its FA info first. How? >>>> >>>The answer should be abundantly obvious to the informed reader. >>> >>>And to make it crystal clear, I have no intention in designing your >>>products for you. >>> >>> >>>>>>Let us say the node can resynchronize its neighbor if >>>>>>the neighbor restarts and requests state recovery. But >>>>>>the issue is how a node can advertise that it does not >>>>>>need recovery since all its state was preserved? >>>>>> >>>>>By treating is the same way as the way the spec handles >>>>>control channel fault. >>>>> >>>>> >>>>If a node can recover states from NVRAM or OS (this solution is >>>>cheaper and have been implemented). It may not implement the spec. >>>>How could a neighboring node, which implements the spec, not tear >>>>down data connections mistakenly? Similar to a backward compatibility >>>>problem, even not. >>>> >>>Stating the obvious: interoperability with a node that doesn't implement >>>the spec is outside the scope of the spec. >>> >>> >>>>>>RECOVERY LABEL does not come into picture unless the node >>>>>>that is upstream to the restarting node has already received >>>>>>a Resv. >>>>>> >>>>>Wrong. Quoting 9.5.3: >>>>> >>>>> Upon detecting a restart with a neighbor that supports state >>>>> recovery, a node SHOULD refresh all Path state shared with that >>>>> neighbor. >>>>> >>>>>So, as you can hopefully see from the above, the upstream node doesn't >>>>>wait until it receives a Resv. >>>>> >>>>> >>>>Then this may not meet carriers' requirement. (see IPO carriers' requirem >>>> > ent) > >>>>Again, back to the telecom world (sorry about this, yet we are talking ab >>>> > out > >>>>GMPLS), typically only the established pathes are preserved. Pending requ >>>> > ests > >>>>may be purged/aborted. Then how? >>>> >>>Note the verb is "SHOULD", not "MUST". The rest should be >>>obvious to the informed reader. >>> >>> >>>>>>In case of PSC devices, it may be OK to remove state that >>>>>>is not resynchronized at the end of the recovery period, >>>>>>and the recovery period advertised might reflect that. >>>>>>But for LSPs in transport networks, one might want to >>>>>>have a different recovery period to avoid any LSP from >>>>>>going down because of recovery timer expiry. >>>>>> >>>>>There is no requirement for a node to advertise exactly the >>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces >>>>>the node could advertise that it will remove the state that >>>>>isn't syncronized at the end of the recovery period, while >>>>>on the TDM interface precisely the same node could advertise >>>>>that the LSPs would be kept even after the recovery time expires. >>>>> >>>>> >>>>So, restart_cap is per interface based? >>>> >>>yes. >>> >>> >>>>Is the spec going to be enhanced/clarified? >>>> >>>The current spec need not be enhanced/clarified - what I mentioned in the >>>above should be abundantly obvious to the informed reader. >>> >>> >>>>>>The first problems seems to be there still - consider two >>>>>>adjacent nodes restarting. They both act both as the restarting >>>>>>node as well as the neighbor to the restarting node. So, once >>>>>>they learn the state from the upstream neighbor, do they use >>>>>>suggested label or the recovery label when they send the path >>>>>>message to the just restarted downstream neighbor? >>>>>> >>>>>The recovery label. >>>>> >>>>>The following should be added to the existing text from the document: >>>>> >>>>> In the special case where a restarting node also has a restating >>>>> downstream neighbor, a Recovery_Label object should be used instead >>>>> of a Suggested_Label object. >>>>> >>>>How does a recovering NE know that its neighbor is also recovering? it ma >>>> > y > >>>>lose the instance number totally >>>> >>>It's advertised in the neighbor's hellos. >>> >>>Yakov. >>> > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 14:09:03 -0700 Cc: "'Zhi-Wei Lin'" , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Message-ID: <3BD48A65.37EB94D7@lucent.com> Date: Mon, 22 Oct 2001 23:06:45 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Yanhe Fan Original-CC: "'Zhi-Wei Lin'" , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------C13950118C107088CF25213B" This is a multi-part message in MIME format. --------------C13950118C107088CF25213B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yanhe, The situation Zhi describes is one that will be very typical in the optical (SDH/SONET) network in the coming years. We will most likely see islands of switched subnetworks interconnected via the existing SDH/SONET non-switched networks. By means of management actions, links (GMPLS: link bundles) will be setup between an edge node in one switched subnetwork and an other edge node in the next switched subnetwork. In G.805 terminology, these links are so called serial compound links. The switched subnetworks will treat these serial compound links as normal links, "ignoring" the intermediate non-switched nodes they traverse. These links will contain a fixed set of link connections, which are identified by their respective endpoints at nodes A and Z (i.e. SNPa - SNPz). The server signal that carries the e.g. 5 STS1 link connections in the link at A can be an OC12, whereas this can be an OC48 at Z. During discovery or by means of provisioning both A and Z nodes get aware of the 5 sTS1 link connections as tuples of e.g. SNPa SNPz ----------------------------------- - port Ai/trib T1 - port Zj/trib Ta (STS1 link connection #1) - port Ai/trib T2 - port Zj/trib Tb (STS1 link connection #2) - port Ai/trib T3 - port Zj/trib Tc (STS1 link connection #3) - port Ai/trib T4 - port Zj/trib Td (STS1 link connection #4) - port Ai/trib T5 - port Zj/trib Te (STS1 link connection #5) As both ends of the link build up this same relation information, it is possible to use as link connection identifier only one of the two SNPs. E.g. node A identifies the STS1 link connection #1 by means of "Ai/T1" and sends this info to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". Vice versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when received by node A, this will be converted into Ai/T1. For GMPLS this implies that the GMPLS label doesn't identify the timeslot at both ends of the link connection, only the timeslot at the sending end. The receiving end needs to convert this then into its local timeslot number. Regards, Maarten Yanhe Fan wrote: > > Hi Zhi, > > What B does is breaking the label association between A and C by crossing > connect > the time slots. > > If the cross connect performed by B is fixed (in your case), what needs to > do is > just to rebuild the label association by configuration or a protocol such as > LMP; > If the cross connect is not fixed but dynamic, the best thing to do is to > make B > a GMPLS speaker. Tell this to the 1.000.000+ SDH/SONET network elements in today's transport network... no chance... those will stay non-switched... > > Yanhe > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Friday, October 19, 2001 6:01 PM > To: Yanhe Fan > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Hi Yanhe, > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > is simply part of the network that made up the "dumb" pipe. And because > the control plane control channel is separate, A and C can be adjacent > without ever knowing who B is or that even B existed. From A and C's > point of view, the network looks like: > > A ----- C > > Think of the case of how a BGP sees an area. If an area is made up of: > > A -- B -- C > > and B is internal router, does BGP "see" B? > > Zhi > > Yanhe Fan wrote: > > > Hi, Zhi > > > > > >>For the label value for SONET/SDH or the label description in the > >>generic draft, the label is defined as directly representing the > >>"timeslot". Now if I have a control plane controlled transport network > >>that goes through a ADM that is not control plane controlled, as: > >> > >> > >>+--------+ +--------+ +--------+ > >>| | ---1--------- | | ----1-------- | | > >>| | ---2--------- | | ----2-------- | | > >>| A | ---3--------- | B | ----3-------- | C | > >>| | ---4--------- | | ----4-------- | | > >>| | ---5--------- | | ----5-------- | | > >>+--------+ +--------+ +--------+ > >> > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C > >>has labels 1,2,3,4,5 incoming. > >> > >>Now imagine that at B, it actually has a fixed cross-connect that > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >> > >>Now when A GMPLS sends a message to C, the label it uses is "1". > >>However, the connection/LSP associated with timeslot "1" is actually the > >>label of timeslot "2" at C. > >> > > > > In this case, you're trying to use GMPLS to setup an LSP cross a node (B) > > which can't understand GMPLS. > > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > > GMPLS if B can't understand GMPLS? > > > > Now imagine A and B are LSRs, and B is a conventional router (can't > > understand > > MPLS), can you setup an LSP A-B-C? > > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > > understand PNNI at all? > > > > My point is that in order to make you case work, some additional work need > > to > > be done besie simply using GMPLS as singnaling protocol, becase some node > on > > the path is not GMPLS speakers. A and C needs the info of time slot > aligment > > > > between them. This can be done by some configurations, some link > management > > protocls (LMP maybe) etc. As long as A and C have this piece of info, > > eveything > > works fine. > > > > Yanhe > > --------------C13950118C107088CF25213B Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------C13950118C107088CF25213B-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 13:16:22 -0700 Message-Id: <200110222012.f9MKCB050472@merlot.juniper.net> To: "Lazer, Monica A, NNAD" cc: ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91113.1003781531.1@juniper.net> Date: Mon, 22 Oct 2001 13:12:11 -0700 From: Yakov Rekhter Monica, > Dimitri, > Actually, it may be more accurate to put it differently - if GMPLS supports > only a handful of the services running on a given transport network, than > its value as a network's control plane component is diminished. To be even more accurate, GMPLS value is diminished *in the context* of that particular transport network. And unless *all* providers are going to run *all possible services* on their transport networks (which is a somewhat unrealistic scenario), that means that the value of GMPLS as a network's control plane component would be diminished for *some*, but not *all* service providers. At the same time, it is important to keep in mind that being "all things for all people" (aka as "perfect solution") is one of the *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a *particular* provider GMPLS would *not* support *all* the services that this provider runs on its transport network. Yakov. > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Monday, October 22, 2001 3:15 PM > To: Lazer, Monica A, NNAD > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > << File: Card for Dimitri Papadimitriou >> Hi Monica, > > Fine. Now we know the following: GMPLS is really attractive for > carriers when it supports all transport technologies so it has > to support Fiber Channel as well. > > I wasn't aware that Ewart was capable to read in your mind ;-) > > Regards, > Dimitri. > > "Lazer, Monica A, NNAD" wrote: > > > > Dimitri, > > I am just answering the PS question with this message. > > The short answer is yes. The long answer is that the GMPLS control plane > is > > really useful if it can support connection management for all the > transport > > services supported by the transport network using GMPLS. Therefore, the > > carrier services section for the NNI document to be posted on the OIF site > > within a few minutes and the next draft of the carrier requirements IETF > > draft will both contain references to support of Fiber Channel. > > Regards, > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Monday, October 22, 2001 2:47 PM > > To: Ewart Tempest > > Cc: lberger@movaz.com; ccamp@ops.ietf.org > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > > > If you take a look on the IEEE Standards you will see > > that GE is referred to as > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > > - 802.3ae for 10Gbps (see below [2]) > > > > So my question is what do you have in mind ? to separate > > these values ? > > > > Thanks, > > Dimitri. > > > > PS: for FiberChannel sorry i am not an expert but is someone > > targeting to use GMPLS for FiberChannel LSP ? > > > > ------- > > > > [1] From - http://standards.ieee.org > > > > Project scope: Define Carrier Sense Multiple Access with Collision > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > > augmentation of its operation, physical layer characteristics, repeater > > functions and management parameters for transfer of 802.3 and Ethernet > > format frames at 1,000 Mb/s. > > > > Project purpose: The purpose of this project is to extend the 802.3 > > protocol to an operating speed of 1,000 Mb/s in order to provide a > > significant increase in bandwidth while maintaining maximum > > compatibility > > with the installed base of CSMA/CD nodes, previous investment in > > research > > and development, and principles of network operation and management. > > > > [2] From - http://standards.ieee.org > > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > > minimal augmentation of its operation, physical layer characteristics > > and management parameters for transfer of LLC and Ethernet format > > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > > standard. In addition to the traditional LAN space, add parameters and > > mechanisms that enable deployment of Ethernet over the Wide Area Network > > operating at a data rate compatible with OC-192c and SDH VC-4-64c > > payload > > rate. > > > > Project purpose: The purpose of this project is to extend the 802.3 > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > > application space to include Wide Area Network links in order to provide > > a significant increase in bandwidth while maintaining maximum > > compatibility > > with the installed base of 802.3 interfaces, previous investment in > > research > > and development, and principles of network operation and management. > > > > ------- > > > > > Ewart Tempest wrote: > > > > > > Lou, > > > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > > GE is not really covered by the existing Ethernet related encoding > > > types, and FiberChannel is not covered at all. Thanks. > > > > > > Ewart > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 12:54:51 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBAD@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Dimitri Papadimitriou'" Cc: Ewart Tempest , lberger@movaz.com, ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Mon, 22 Oct 2001 15:51:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, Actually, it may be more accurate to put it differently - if GMPLS supports only a handful of the services running on a given transport network, than its value as a network's control plane component is diminished. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Monday, October 22, 2001 3:15 PM To: Lazer, Monica A, NNAD Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion << File: Card for Dimitri Papadimitriou >> Hi Monica, Fine. Now we know the following: GMPLS is really attractive for carriers when it supports all transport technologies so it has to support Fiber Channel as well. I wasn't aware that Ewart was capable to read in your mind ;-) Regards, Dimitri. "Lazer, Monica A, NNAD" wrote: > > Dimitri, > I am just answering the PS question with this message. > The short answer is yes. The long answer is that the GMPLS control plane is > really useful if it can support connection management for all the transport > services supported by the transport network using GMPLS. Therefore, the > carrier services section for the NNI document to be posted on the OIF site > within a few minutes and the next draft of the carrier requirements IETF > draft will both contain references to support of Fiber Channel. > Regards, > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Monday, October 22, 2001 2:47 PM > To: Ewart Tempest > Cc: lberger@movaz.com; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > If you take a look on the IEEE Standards you will see > that GE is referred to as > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > - 802.3ae for 10Gbps (see below [2]) > > So my question is what do you have in mind ? to separate > these values ? > > Thanks, > Dimitri. > > PS: for FiberChannel sorry i am not an expert but is someone > targeting to use GMPLS for FiberChannel LSP ? > > ------- > > [1] From - http://standards.ieee.org > > Project scope: Define Carrier Sense Multiple Access with Collision > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > augmentation of its operation, physical layer characteristics, repeater > functions and management parameters for transfer of 802.3 and Ethernet > format frames at 1,000 Mb/s. > > Project purpose: The purpose of this project is to extend the 802.3 > protocol to an operating speed of 1,000 Mb/s in order to provide a > significant increase in bandwidth while maintaining maximum > compatibility > with the installed base of CSMA/CD nodes, previous investment in > research > and development, and principles of network operation and management. > > [2] From - http://standards.ieee.org > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > minimal augmentation of its operation, physical layer characteristics > and management parameters for transfer of LLC and Ethernet format > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > standard. In addition to the traditional LAN space, add parameters and > mechanisms that enable deployment of Ethernet over the Wide Area Network > operating at a data rate compatible with OC-192c and SDH VC-4-64c > payload > rate. > > Project purpose: The purpose of this project is to extend the 802.3 > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > application space to include Wide Area Network links in order to provide > a significant increase in bandwidth while maintaining maximum > compatibility > with the installed base of 802.3 interfaces, previous investment in > research > and development, and principles of network operation and management. > > ------- > > > Ewart Tempest wrote: > > > > Lou, > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > GE is not really covered by the existing Ethernet related encoding > > types, and FiberChannel is not covered at all. Thanks. > > > > Ewart Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 12:18:30 -0700 Message-ID: <3BD4703B.C5D0C904@alcatel.be> Date: Mon, 22 Oct 2001 21:15:07 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: "Lazer, Monica A, NNAD" CC: Ewart Tempest , lberger@movaz.com, ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: multipart/mixed; boundary="------------51CD3388782DA225F085F3F9" This is a multi-part message in MIME format. --------------51CD3388782DA225F085F3F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Monica, Fine. Now we know the following: GMPLS is really attractive for carriers when it supports all transport technologies so it has to support Fiber Channel as well. I wasn't aware that Ewart was capable to read in your mind ;-) Regards, Dimitri. "Lazer, Monica A, NNAD" wrote: > > Dimitri, > I am just answering the PS question with this message. > The short answer is yes. The long answer is that the GMPLS control plane is > really useful if it can support connection management for all the transport > services supported by the transport network using GMPLS. Therefore, the > carrier services section for the NNI document to be posted on the OIF site > within a few minutes and the next draft of the carrier requirements IETF > draft will both contain references to support of Fiber Channel. > Regards, > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Monday, October 22, 2001 2:47 PM > To: Ewart Tempest > Cc: lberger@movaz.com; ccamp@ops.ietf.org > Subject: Re: Generalized Signaling - LSP Encoding Type expansion > > << File: Card for Dimitri Papadimitriou >> Hi Ewart, > > If you take a look on the IEEE Standards you will see > that GE is referred to as > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab > - 802.3ae for 10Gbps (see below [2]) > > So my question is what do you have in mind ? to separate > these values ? > > Thanks, > Dimitri. > > PS: for FiberChannel sorry i am not an expert but is someone > targeting to use GMPLS for FiberChannel LSP ? > > ------- > > [1] From - http://standards.ieee.org > > Project scope: Define Carrier Sense Multiple Access with Collision > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal > augmentation of its operation, physical layer characteristics, repeater > functions and management parameters for transfer of 802.3 and Ethernet > format frames at 1,000 Mb/s. > > Project purpose: The purpose of this project is to extend the 802.3 > protocol to an operating speed of 1,000 Mb/s in order to provide a > significant increase in bandwidth while maintaining maximum > compatibility > with the installed base of CSMA/CD nodes, previous investment in > research > and development, and principles of network operation and management. > > [2] From - http://standards.ieee.org > > Project scope: Define 802.3 Media Access Control (MAC) parameters and > minimal augmentation of its operation, physical layer characteristics > and management parameters for transfer of LLC and Ethernet format > frames at 10 Gb/s using full duplex operation as defined in the 802.3 > standard. In addition to the traditional LAN space, add parameters and > mechanisms that enable deployment of Ethernet over the Wide Area Network > operating at a data rate compatible with OC-192c and SDH VC-4-64c > payload > rate. > > Project purpose: The purpose of this project is to extend the 802.3 > protocol to an operating speed of 10 Gb/s and to expand the Ethernet > application space to include Wide Area Network links in order to provide > a significant increase in bandwidth while maintaining maximum > compatibility > with the installed base of 802.3 interfaces, previous investment in > research > and development, and principles of network operation and management. > > ------- > > > Ewart Tempest wrote: > > > > Lou, > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > > you please add additonal LSP Encoding Types for GE and FiberChannel. > > GE is not really covered by the existing Ethernet related encoding > > types, and FiberChannel is not covered at all. Thanks. > > > > Ewart --------------51CD3388782DA225F085F3F9 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------51CD3388782DA225F085F3F9-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 12:03:19 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9DBA9@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Dimitri Papadimitriou'" , Ewart Tempest Cc: lberger@movaz.com, ccamp@ops.ietf.org Subject: RE: Generalized Signaling - LSP Encoding Type expansion Date: Mon, 22 Oct 2001 15:02:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, I am just answering the PS question with this message. The short answer is yes. The long answer is that the GMPLS control plane is really useful if it can support connection management for all the transport services supported by the transport network using GMPLS. Therefore, the carrier services section for the NNI document to be posted on the OIF site within a few minutes and the next draft of the carrier requirements IETF draft will both contain references to support of Fiber Channel. Regards, Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Monday, October 22, 2001 2:47 PM To: Ewart Tempest Cc: lberger@movaz.com; ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion << File: Card for Dimitri Papadimitriou >> Hi Ewart, If you take a look on the IEEE Standards you will see that GE is referred to as - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab - 802.3ae for 10Gbps (see below [2]) So my question is what do you have in mind ? to separate these values ? Thanks, Dimitri. PS: for FiberChannel sorry i am not an expert but is someone targeting to use GMPLS for FiberChannel LSP ? ------- [1] From - http://standards.ieee.org Project scope: Define Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal augmentation of its operation, physical layer characteristics, repeater functions and management parameters for transfer of 802.3 and Ethernet format frames at 1,000 Mb/s. Project purpose: The purpose of this project is to extend the 802.3 protocol to an operating speed of 1,000 Mb/s in order to provide a significant increase in bandwidth while maintaining maximum compatibility with the installed base of CSMA/CD nodes, previous investment in research and development, and principles of network operation and management. [2] From - http://standards.ieee.org Project scope: Define 802.3 Media Access Control (MAC) parameters and minimal augmentation of its operation, physical layer characteristics and management parameters for transfer of LLC and Ethernet format frames at 10 Gb/s using full duplex operation as defined in the 802.3 standard. In addition to the traditional LAN space, add parameters and mechanisms that enable deployment of Ethernet over the Wide Area Network operating at a data rate compatible with OC-192c and SDH VC-4-64c payload rate. Project purpose: The purpose of this project is to extend the 802.3 protocol to an operating speed of 10 Gb/s and to expand the Ethernet application space to include Wide Area Network links in order to provide a significant increase in bandwidth while maintaining maximum compatibility with the installed base of 802.3 interfaces, previous investment in research and development, and principles of network operation and management. ------- > Ewart Tempest wrote: > > Lou, > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > you please add additonal LSP Encoding Types for GE and FiberChannel. > GE is not really covered by the existing Ethernet related encoding > types, and FiberChannel is not covered at all. Thanks. > > Ewart Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 11:54:49 -0700 Message-ID: <3BD469A0.362DCFA2@alcatel.be> Date: Mon, 22 Oct 2001 20:46:56 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Ewart Tempest CC: lberger@movaz.com, ccamp@ops.ietf.org Subject: Re: Generalized Signaling - LSP Encoding Type expansion Content-Type: multipart/mixed; boundary="------------E0956412F0390207C3F4403D" This is a multi-part message in MIME format. --------------E0956412F0390207C3F4403D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ewart, If you take a look on the IEEE Standards you will see that GE is referred to as - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab - 802.3ae for 10Gbps (see below [2]) So my question is what do you have in mind ? to separate these values ? Thanks, Dimitri. PS: for FiberChannel sorry i am not an expert but is someone targeting to use GMPLS for FiberChannel LSP ? ------- [1] From - http://standards.ieee.org Project scope: Define Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal augmentation of its operation, physical layer characteristics, repeater functions and management parameters for transfer of 802.3 and Ethernet format frames at 1,000 Mb/s. Project purpose: The purpose of this project is to extend the 802.3 protocol to an operating speed of 1,000 Mb/s in order to provide a significant increase in bandwidth while maintaining maximum compatibility with the installed base of CSMA/CD nodes, previous investment in research and development, and principles of network operation and management. [2] From - http://standards.ieee.org Project scope: Define 802.3 Media Access Control (MAC) parameters and minimal augmentation of its operation, physical layer characteristics and management parameters for transfer of LLC and Ethernet format frames at 10 Gb/s using full duplex operation as defined in the 802.3 standard. In addition to the traditional LAN space, add parameters and mechanisms that enable deployment of Ethernet over the Wide Area Network operating at a data rate compatible with OC-192c and SDH VC-4-64c payload rate. Project purpose: The purpose of this project is to extend the 802.3 protocol to an operating speed of 10 Gb/s and to expand the Ethernet application space to include Wide Area Network links in order to provide a significant increase in bandwidth while maintaining maximum compatibility with the installed base of 802.3 interfaces, previous investment in research and development, and principles of network operation and management. ------- > Ewart Tempest wrote: > > Lou, > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can > you please add additonal LSP Encoding Types for GE and FiberChannel. > GE is not really covered by the existing Ethernet related encoding > types, and FiberChannel is not covered at all. Thanks. > > Ewart --------------E0956412F0390207C3F4403D Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------E0956412F0390207C3F4403D-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 11:13:49 -0700 Message-ID: <710197BD5AF9D4119E4400508BCFA13601B5FBA6@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: lberger@movaz.com Cc: ccamp@ops.ietf.org, "Ewart Tempest" Subject: Generalized Signaling - LSP Encoding Type expansion Date: Mon, 22 Oct 2001 14:11:28 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B24.F7F93820" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15B24.F7F93820 Content-Type: text/plain; charset="iso-8859-1" Lou, Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can you please add additonal LSP Encoding Types for GE and FiberChannel. GE is not really covered by the existing Ethernet related encoding types, and FiberChannel is not covered at all. Thanks. Ewart ------_=_NextPart_001_01C15B24.F7F93820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Generalized Signaling - LSP Encoding Type expansion

Lou,

Within section 3.1.1 of = draft-ietf-mpls-generalized-signaling-06 can you please add additonal = LSP Encoding Types for GE and FiberChannel. GE is not really covered by = the existing Ethernet related encoding types, and FiberChannel is not = covered at all. Thanks.

Ewart

------_=_NextPart_001_01C15B24.F7F93820-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 10:54:33 -0700 Message-Id: <200110221751.NAA04692@telescope.cisco.com> To: lberger@movaz.com Cc: ccamp@ops.ietf.org Subject: Generalized Signaling - Underspecification of Switching Type Date: Mon, 22 Oct 2001 13:51:33 -0400 From: George Swallow Lou - The definition of the Switching Type field of the Generalized label does not specify the scope over which it operates. It is my understanding that for a given LSP it does not change, but is carried end-to-end and applies at all intermediate hops along the path. The Label Request Object is a hop by hop object. Further the description of the Switching Type includes the phrase "on a particular link", further implying that it may not be constant. (As an aside, I don't like the phrase anyway since I think of Switching Type applying mainly to the node at the end of the link ;-) I think some clarifying text is in order. Thanks, ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 10:51:45 -0700 Message-Id: <200110221745.f9MHjB041453@merlot.juniper.net> To: Zhi-Wei Lin cc: Yangguang Xu , ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <45173.1003772710.1@juniper.net> Date: Mon, 22 Oct 2001 10:45:11 -0700 From: Yakov Rekhter Zhi-Wei, > Just to be clear, I am definitely one of the uninformed readers since I > have joined IETF not so long ago (not everyone is part of IETF when it > first started unfortunately). So Yakov, if you would be so kind as to > inform an uninformed reader that would be very very much appreciated. There are few points I'd like to make to an uninformed reader: 1. As was pointed the other day by Dimitri Papadimitriou, GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG". 2. As was also pointed out in the same e-mail from Dimitri, "we can not wait until everybody in this world has no question anymore or a full understanding on any technical detail in order to go forward". 3. Finally, please read the attached e-mail from Eric Gray to your collegue from Lucent. Yakov. ------------------------------------------------------------------------- Date: Fri, 19 Oct 2001 15:38:58 EDT To: Yangguang Xu cc: Yakov Rekhter From: Eric Gray Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Yangguang, Careful, don't let this discussion descend into the nether regions of name calling and finger pointing. :-) The fact that the seeming remote neighbors use RSVP Hello is clear once you realize that - for the purposes of hierarchical LSP setup, they are adjacent. You may recall this from an off-line discussion we had. Yakov's comment was simply stating that it is not a part of standard's development to make an implementer's cook-book. He was not (I think) trying to imply that you could not write your own implementation. He was just saying that the effort of achieving interoperability falls on the people doing the implementation not on the people doing the standard. The bare information is there, but the work is up to you. As you know, the standard is not complete until several implementations have achieved interoperability independently. But the opportunity to get in the market stems from being one of those implementations - and there is zero motivation for any implementer to make this task easy for all others. One of the costs associated with the 'running code' part of IETF mistique is that standards are written by implementers. Unless and until that changes, you just have to learn to deal with it. :-) You wrote: > Indeed, you didn't answer my questions. Instead of informed readers, more > important is to have better informed writers. > > BTW, I have no intention to let you design my product at all. > > Yangguang > > Yakov Rekhter wrote: > > > > Yangguang, > > > > > Yakov, > > > > > > Further questions in-line. Regards, > > > > Further responses in-line... > > > > > Yangguang > > > > > > > Couple of points: > > > > > > > > (1) First of all, you do run RSVP Hello between C and F. > > > > > > Is this specified somewhere? Or it's your proposal. > > > > What I mentioned in the above should be abundantly obvious to the > > informed reader of RSVP and LSP Hierarchy specs. > > > > > Then, is there a scalability issue here? > > > > No. > > > > > Also, C and F could be thousands mile away (in the transport > > > network) and the control channel bandwidth is expensive. > > > > GMPLS assumes that control channel is more than just 56Kbits/sec link. > > > > Or to put it differently, control channels used by GMPLS have more than > > enough capacity for RSVP Hellos. > > > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > > > > be able to recover the Interface ID it assigns to L1 from > > > > a combination of (a) the OSPF/ISIS link state database that > > > > F would recover, and (b) the Forward Interface ID (the one > > > > assigned by C). > > > > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the n it > > > has to recover its FA info first. How? > > > > The answer should be abundantly obvious to the informed reader. > > > > And to make it crystal clear, I have no intention in designing your > > products for you. > > > > > > > Let us say the node can resynchronize its neighbor if > > > > > the neighbor restarts and requests state recovery. But > > > > > the issue is how a node can advertise that it does not > > > > > need recovery since all its state was preserved? > > > > > > > > By treating is the same way as the way the spec handles > > > > control channel fault. > > > > > > > > > > If a node can recover states from NVRAM or OS (this solution is > > > cheaper and have been implemented). It may not implement the spec. > > > How could a neighboring node, which implements the spec, not tear > > > down data connections mistakenly? Similar to a backward compatibility > > > problem, even not. > > > > Stating the obvious: interoperability with a node that doesn't implement > > the spec is outside the scope of the spec. > > > > > > > RECOVERY LABEL does not come into picture unless the node > > > > > that is upstream to the restarting node has already received > > > > > a Resv. > > > > > > > > Wrong. Quoting 9.5.3: > > > > > > > > Upon detecting a restart with a neighbor that supports state > > > > recovery, a node SHOULD refresh all Path state shared with that > > > > neighbor. > > > > > > > > So, as you can hopefully see from the above, the upstream node doesn't > > > > wait until it receives a Resv. > > > > > > > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirem ent) > > > Again, back to the telecom world (sorry about this, yet we are talking ab out > > > GMPLS), typically only the established pathes are preserved. Pending requ ests > > > may be purged/aborted. Then how? > > > > Note the verb is "SHOULD", not "MUST". The rest should be > > obvious to the informed reader. > > > > > > > In case of PSC devices, it may be OK to remove state that > > > > > is not resynchronized at the end of the recovery period, > > > > > and the recovery period advertised might reflect that. > > > > > But for LSPs in transport networks, one might want to > > > > > have a different recovery period to avoid any LSP from > > > > > going down because of recovery timer expiry. > > > > > > > > There is no requirement for a node to advertise exactly the > > > > same Restart_Cap on all the interfaces. So, on PSC interfaces > > > > the node could advertise that it will remove the state that > > > > isn't syncronized at the end of the recovery period, while > > > > on the TDM interface precisely the same node could advertise > > > > that the LSPs would be kept even after the recovery time expires. > > > > > > > > > > So, restart_cap is per interface based? > > > > yes. > > > > > Is the spec going to be enhanced/clarified? > > > > The current spec need not be enhanced/clarified - what I mentioned in the > > above should be abundantly obvious to the informed reader. > > > > > > > The first problems seems to be there still - consider two > > > > > adjacent nodes restarting. They both act both as the restarting > > > > > node as well as the neighbor to the restarting node. So, once > > > > > they learn the state from the upstream neighbor, do they use > > > > > suggested label or the recovery label when they send the path > > > > > message to the just restarted downstream neighbor? > > > > > > > > The recovery label. > > > > > > > > The following should be added to the existing text from the document: > > > > > > > > In the special case where a restarting node also has a restating > > > > downstream neighbor, a Recovery_Label object should be used instead > > > > of a Suggested_Label object. > > > > > > How does a recovering NE know that its neighbor is also recovering? it ma y > > > lose the instance number totally > > > > It's advertised in the neighbor's hellos. > > > > Yakov. -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 10:36:58 -0700 Message-Id: <200110221733.f9MHX3040642@merlot.juniper.net> To: Gopal Kailad cc: ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41453.1003771983.1@juniper.net> Date: Mon, 22 Oct 2001 10:33:03 -0700 From: Yakov Rekhter Gopal, > Thanks for the clarification. You are welcomed !!! > My comments are inline: My comments are inline: > Yakov Rekhter wrote: > > >Gopal, > > > >>>>I have some questions/concerns on the restart mechanism as > >>>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt. I > >>>>have listed them below. > >>>> > >>>>If a node that is terminating hierarchical LSPs restarts, > >>>>there is an ordering issue during resynchronization, since > >>>>the LSPs would depend on other FA-LSPs the interface IDs for > >>>>which would have been generated dynamically. So the > >>>>mechanism as described will not work, unless this > >>>>information is preserved across restarts - in which case we > >>>>might as well preserve other information as well, and avoid > >>>>resynchronization. > >>>> > >>>Since transit node of the FA-LSP does not see the RSVP > >>>messages that use the FA, we only need to consider > >>>the ingress and egress node. If the egress node restarts, > >>>the worst case is that its upstream node sends an ERO > >>>consisting a unrecognized interface address. Since the > >>>Path message will carry RECOVERY_LABEL (replacing > >>>SUGGESTED_LABEL), the egress node knows that it might > >>>not have complete information yet, and can hold on to > >>>the Path message until the FA-LSP is established. > >>>All the information is there, so implementation > >>>can be completely within the egress node. It does work, > >>>just not specified enough. > >>> > >>>Ingress node will have to know the dependency, so not > >>>a problem there. > >>> > >>Are you suggesting that in case of an ERO with an > >>unrecognized interface id, if the Path message also > >>carries a RECOVERY LABEL, the egress node can hold on > >>to it until later? Note that there may not be a > >>RECOVERY LABEL - since this Path message is for a > >>hierarchical LSP, and the previous node may not be > >>directly connected in the control plane. Here is an > >>example - There is an LSP L1 from C to F, and on top of > >>it there is an LSP L2 from A to G. > >> > >> L1: C --- D --- E --- F > >> L2: A --- B --- C --------------- F --- G > >> > >>When F restarts, C may not even know, unless HELLO > >>protocol is run between C and F. Note that the > >>HELLO mechanism is intended for immediate neighbors. > >> > >>And even if the HELLO mechanism is extended, there > >>is the issue of interface id assigned by F. F needs > >>to assign the same interface id upon restart so as > >>not to bring down the hierarchical LSPs set up on top > >>of L1 in > >>the reverse direction (say an LSP from G to > >>B set up on top of L1.) Where would F get this > >>information ? > >> > > > >Couple of points: > > > >(1) First of all, you do run RSVP Hello between C and F. > > O.K. > > >(2) Since L1 is advertised as an FA into OSPF/ISIS, F should > >be able to recover the Interface ID it assigns to L1 from > >a combination of (a) the OSPF/ISIS link state database that > >F would recover, and (b) the Forward Interface ID (the one > >assigned by C). > > > True. One could either use IGP restart mechanism to relearn > this (I have other concerns on RSVP restart being dependent on > IGP restart, but that for later) or preserve this across restarts. > In either case, you agree that RSVP restart depends on some > mechanism outside RSVP to help it along? So RSVP needs a new > interface to get this mapping upon restarts, right? This is not > clear in the draft. Couple of points: 1. As Dimitri Papadimitriou mentioned in his other e-mail to this list, an Internet Draft "is not a textbook on how to use GMPLS-SIG". 2. What I mentioned in the above should be abundantly obvious to the informed reader of RSVP and LSP Hierarchy specs. > >>>>Also, let us consider a node that can preserve state across > >>>>restarts, and hence does not need its state to be synced by > >>>>its peer. How will it advertise this in the RESTART_CAP > >>>>object? > >>>> > >>>We still need to resynchronize the state since the other > >>>side might have connections that are in progress. The > >>> > >>Let us say the node can resynchronize its neighbor if > >>the neighbor restarts and requests state recovery. But > >>the issue is how a node can advertise that it does not > >>need recovery since all its state was preserved? > >> > > > >By treating is the same way as the way the spec handles > >control channel fault. > > > > True, but this does not help. Help with what ? > See below. > > >>>reason for resynchronization is to make sure both side > >>>have done the same to the in-progress connections, not > >>>just to synchronize the established states. > >>> > >>>The value of the RESTART_CAP will set to non-zero values > >>> > >>RECOVERY LABEL does not come into picture unless the node > >>that is upstream to the restarting node has already received > >>a Resv. > >> > > > >Wrong. Quoting 9.5.3: > > > > Upon detecting a restart with a neighbor that supports state > > recovery, a node SHOULD refresh all Path state shared with that > > neighbor. > > > >So, as you can hopefully see from the above, the upstream node doesn't > >wait until it receives a Resv. > > > True - if you had read further, you would have noticed that > I have said the same thing that you have quoted :) - > but there will be no RECOVERY_LABEL unless a Resv has > been received, right? > > It is possible that the downstream node, after programming > its forwarding path, restarted before sending the Resv. > This would result in the upstream node refreshing the Path > message without the Recovery Label, and the downstream > node eventually allocating a different label. Correct. > So essentially it is a new LSP setup. It is a setup for a connection that is *in-progress*. > >>So it seems that the procedure is to resynchronize > >>established state? If Resv has not been received yet, there > >>will be a refresh of Path message, and the restarting node > >>will consider it as a new request, etc. So can you elaborate > >>on "to make sure both side have done the same to the in > >>progress connections" ? > >> > >>>>If a node supports PSC as well as TDM or LSC interfaces, it > >>>>might want to advertise different set of parameters in the > >>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM > >>>>LSPs which form bearer channels in transport networks. > >>>>Currently this is not possible. > >>>> > >>>Can you give us explicit examples as to why and what do > >>>you gain by giving different values for PSC, TDM ? > >>> > >>In case of PSC devices, it may be OK to remove state that > >>is not resynchronized at the end of the recovery period, > >>and the recovery period advertised might reflect that. > >>But for LSPs in transport networks, one might want to > >>have a different recovery period to avoid any LSP from > >>going down because of recovery timer expiry. > >> > > > >There is no requirement for a node to advertise exactly the > >same Restart_Cap on all the interfaces. So, on PSC interfaces > >the node could advertise that it will remove the state that > >isn't syncronized at the end of the recovery period, while > >on the TDM interface precisely the same node could advertise > >that the LSPs would be kept even after the recovery time expires. > > But to set up LSPs over TDM/LSC interfaces, the PSC interface > is going to be used for signaling - since control and data > planes are decoupled! So, how will this help? Help with what ? You asserted that it "is not possible" for "a node that supports PSC as well as TDM and LSC interfaces.. to advertise different set of parameters in the RESTART_CAP object for data LSPs as opposed to SONET/WDM LSPs." I pointed out to you that your assertion is incorrect, as there is no requirement for a node to advertise exactly the same Restart_Cap on all of its interfaces. > >>>>According to 9.5.1. (procedures for restarting LSR): "When > >>>>sending the corresponding outgoing Path message the node > >>>>SHOULD include a SUGGESTED_LABEL object with a label value > >>>>^^^^^^ > >>>>matching the outgoing label from the now restored forwarding > >>>>entry." > >>>> > >>>>This has a conflict with 9.5.2. Consider the case where > >>>>adjacent nodes B and C restart, and B has another adjacent > >>>>node A, and C has another adjacent node D. B and C will get > >>>>resynced by A and D, and during this process, they will > >>>>resync. each other. While resyncing each other, they act as > >>>>neighbors of a restarting LSR, and hence according to 9.5.2, > >>>>MUST include the SUGGESTED_LABEL. > >>>> > >>>>Also according to 9.5.2: "During the recovery period, new > >>>>Path state being advertised to the restarted neighbor SHOULD > >>>>not include the SUGGESTED_LABEL object in the corresponding > >>>>outgoing Path message. This will prevent the restarting > >>>>node > >>>> from erroneously reusing a saved forwarding entry." > >>>> > >>>>I guess this would mean that if suggested labels are used > >>>>during new LSP setup (as they are likely to be while > >>>>provisioning lightpaths - to reduce latency), then new LSP > >>>>setup will not be allowed during resyncing? > >>>> > >>>The use of RECOVERY_LABEL address all the above questions. > >>> > >>The first problems seems to be there still - consider two > >>adjacent nodes restarting. They both act both as the restarting > >>node as well as the neighbor to the restarting node. So, once > >>they learn the state from the upstream neighbor, do they use > >>suggested label or the recovery label when they send the path > >>message to the just restarted downstream neighbor? > >> > > > >The recovery label. > > > >The following should be added to the existing text from the document: > > > > In the special case where a restarting node also has a restating > > downstream neighbor, a Recovery_Label object should be used instead > > of a Suggested_Label object. > > > Since a restarting node may not be able to detect that a > downstream neighbor is restarting, I suggest it always use > a Recovery_Label object instead of a Suggested_Label object. Please see my reply to Yangguang on this topic. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 10:36:52 -0700 Message-ID: <3BD45817.DCD786BC@lucent.com> Date: Mon, 22 Oct 2001 13:32:07 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org, Eric Gray Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yakov, Thanks for resenting me the message from Eric. Indeed, instead of looking for answers from you, my intention was just trying to point out some holes in the current proposal and your previous response. And thanks for just throwing them back to me. Again, not trying to add more smoke, just repeat my main point again: there are existing solid solutions that can satisfy carriers' requirement of preserving data path and re-create data path state after rebooting. I think many of us are aware of that. If you are proposing a new mechanism, no matter good or bad, at least you could consider some "backward" compatibility issues. Meanwhile, even I have confidence that you can make it work well eventually, there are some corner cases I'd like to point out. And also a piece of suggestion, before claiming a solution for a problem. It's better to understand the problem well first. There is nothing can replace working experience of either operating, designing and developing optical transport network and NEs. Yangguang Yakov Rekhter wrote: > > Yangguang, > > > Indeed, you didn't answer my questions. > > Perhaps it would be more correct to say that I didn't answer > your questions *to your satisfaction*. And if that is the case, then > I hope that the attached e-mail from Eric Gray (that he let me repost > to the list) would answer your questions to your satisfaction. > > > Instead of informed readers, more > > important is to have better informed writers. > > See the attached. > > > BTW, I have no intention to let you design my product at all. > > Glad to hear this !!! > > Yakov. > --------------------------------------------------------------------- > Date: Fri, 19 Oct 2001 15:38:58 EDT > To: Yangguang Xu > cc: Yakov Rekhter > From: Eric Gray > Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) > > Yangguang, > > Careful, don't let this discussion descend into the nether regions of > name calling and finger pointing. :-) > > The fact that the seeming remote neighbors use RSVP Hello is clear > once you realize that - for the purposes of hierarchical LSP setup, they > are adjacent. You may recall this from an off-line discussion we had. > > Yakov's comment was simply stating that it is not a part of standard's > development to make an implementer's cook-book. He was not (I think) > trying to imply that you could not write your own implementation. He was > just saying that the effort of achieving interoperability falls on the people > doing the implementation not on the people doing the standard. The bare > information is there, but the work is up to you. > > As you know, the standard is not complete until several implementations > have achieved interoperability independently. But the opportunity to get in > the market stems from being one of those implementations - and there is > zero motivation for any implementer to make this task easy for all others. > One of the costs associated with the 'running code' part of IETF mistique > is that standards are written by implementers. > > Unless and until that changes, you just have to learn to deal with it. :-) > > You wrote: > > > Indeed, you didn't answer my questions. Instead of informed readers, more > > important is to have better informed writers. > > > > BTW, I have no intention to let you design my product at all. > > > > Yangguang > > > > Yakov Rekhter wrote: > > > > > > Yangguang, > > > > > > > Yakov, > > > > > > > > Further questions in-line. Regards, > > > > > > Further responses in-line... > > > > > > > Yangguang > > > > > > > > > Couple of points: > > > > > > > > > > (1) First of all, you do run RSVP Hello between C and F. > > > > > > > > Is this specified somewhere? Or it's your proposal. > > > > > > What I mentioned in the above should be abundantly obvious to the > > > informed reader of RSVP and LSP Hierarchy specs. > > > > > > > Then, is there a scalability issue here? > > > > > > No. > > > > > > > Also, C and F could be thousands mile away (in the transport > > > > network) and the control channel bandwidth is expensive. > > > > > > GMPLS assumes that control channel is more than just 56Kbits/sec link. > > > > > > Or to put it differently, control channels used by GMPLS have more than > > > enough capacity for RSVP Hellos. > > > > > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > > > > > be able to recover the Interface ID it assigns to L1 from > > > > > a combination of (a) the OSPF/ISIS link state database that > > > > > F would recover, and (b) the Forward Interface ID (the one > > > > > assigned by C). > > > > > > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the > n it > > > > has to recover its FA info first. How? > > > > > > The answer should be abundantly obvious to the informed reader. > > > > > > And to make it crystal clear, I have no intention in designing your > > > products for you. > > > > > > > > > Let us say the node can resynchronize its neighbor if > > > > > > the neighbor restarts and requests state recovery. But > > > > > > the issue is how a node can advertise that it does not > > > > > > need recovery since all its state was preserved? > > > > > > > > > > By treating is the same way as the way the spec handles > > > > > control channel fault. > > > > > > > > > > > > > If a node can recover states from NVRAM or OS (this solution is > > > > cheaper and have been implemented). It may not implement the spec. > > > > How could a neighboring node, which implements the spec, not tear > > > > down data connections mistakenly? Similar to a backward compatibility > > > > problem, even not. > > > > > > Stating the obvious: interoperability with a node that doesn't implement > > > the spec is outside the scope of the spec. > > > > > > > > > RECOVERY LABEL does not come into picture unless the node > > > > > > that is upstream to the restarting node has already received > > > > > > a Resv. > > > > > > > > > > Wrong. Quoting 9.5.3: > > > > > > > > > > Upon detecting a restart with a neighbor that supports state > > > > > recovery, a node SHOULD refresh all Path state shared with that > > > > > neighbor. > > > > > > > > > > So, as you can hopefully see from the above, the upstream node doesn't > > > > > wait until it receives a Resv. > > > > > > > > > > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirem > ent) > > > > Again, back to the telecom world (sorry about this, yet we are talking ab > out > > > > GMPLS), typically only the established pathes are preserved. Pending requ > ests > > > > may be purged/aborted. Then how? > > > > > > Note the verb is "SHOULD", not "MUST". The rest should be > > > obvious to the informed reader. > > > > > > > > > In case of PSC devices, it may be OK to remove state that > > > > > > is not resynchronized at the end of the recovery period, > > > > > > and the recovery period advertised might reflect that. > > > > > > But for LSPs in transport networks, one might want to > > > > > > have a different recovery period to avoid any LSP from > > > > > > going down because of recovery timer expiry. > > > > > > > > > > There is no requirement for a node to advertise exactly the > > > > > same Restart_Cap on all the interfaces. So, on PSC interfaces > > > > > the node could advertise that it will remove the state that > > > > > isn't syncronized at the end of the recovery period, while > > > > > on the TDM interface precisely the same node could advertise > > > > > that the LSPs would be kept even after the recovery time expires. > > > > > > > > > > > > > So, restart_cap is per interface based? > > > > > > yes. > > > > > > > Is the spec going to be enhanced/clarified? > > > > > > The current spec need not be enhanced/clarified - what I mentioned in the > > > above should be abundantly obvious to the informed reader. > > > > > > > > > The first problems seems to be there still - consider two > > > > > > adjacent nodes restarting. They both act both as the restarting > > > > > > node as well as the neighbor to the restarting node. So, once > > > > > > they learn the state from the upstream neighbor, do they use > > > > > > suggested label or the recovery label when they send the path > > > > > > message to the just restarted downstream neighbor? > > > > > > > > > > The recovery label. > > > > > > > > > > The following should be added to the existing text from the document: > > > > > > > > > > In the special case where a restarting node also has a restating > > > > > downstream neighbor, a Recovery_Label object should be used instead > > > > > of a Suggested_Label object. > > > > > > > > How does a recovering NE know that its neighbor is also recovering? it ma > y > > > > lose the instance number totally > > > > > > It's advertised in the neighbor's hellos. > > > > > > Yakov. > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 10:05:47 -0700 Message-Id: <200110221700.f9MH0b038491@merlot.juniper.net> To: Yangguang Xu cc: ccamp@ops.ietf.org, Eric Gray Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31237.1003770036.1@juniper.net> Date: Mon, 22 Oct 2001 10:00:37 -0700 From: Yakov Rekhter Yangguang, > Indeed, you didn't answer my questions. Perhaps it would be more correct to say that I didn't answer your questions *to your satisfaction*. And if that is the case, then I hope that the attached e-mail from Eric Gray (that he let me repost to the list) would answer your questions to your satisfaction. > Instead of informed readers, more > important is to have better informed writers. See the attached. > BTW, I have no intention to let you design my product at all. Glad to hear this !!! Yakov. --------------------------------------------------------------------- Date: Fri, 19 Oct 2001 15:38:58 EDT To: Yangguang Xu cc: Yakov Rekhter From: Eric Gray Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Yangguang, Careful, don't let this discussion descend into the nether regions of name calling and finger pointing. :-) The fact that the seeming remote neighbors use RSVP Hello is clear once you realize that - for the purposes of hierarchical LSP setup, they are adjacent. You may recall this from an off-line discussion we had. Yakov's comment was simply stating that it is not a part of standard's development to make an implementer's cook-book. He was not (I think) trying to imply that you could not write your own implementation. He was just saying that the effort of achieving interoperability falls on the people doing the implementation not on the people doing the standard. The bare information is there, but the work is up to you. As you know, the standard is not complete until several implementations have achieved interoperability independently. But the opportunity to get in the market stems from being one of those implementations - and there is zero motivation for any implementer to make this task easy for all others. One of the costs associated with the 'running code' part of IETF mistique is that standards are written by implementers. Unless and until that changes, you just have to learn to deal with it. :-) You wrote: > Indeed, you didn't answer my questions. Instead of informed readers, more > important is to have better informed writers. > > BTW, I have no intention to let you design my product at all. > > Yangguang > > Yakov Rekhter wrote: > > > > Yangguang, > > > > > Yakov, > > > > > > Further questions in-line. Regards, > > > > Further responses in-line... > > > > > Yangguang > > > > > > > Couple of points: > > > > > > > > (1) First of all, you do run RSVP Hello between C and F. > > > > > > Is this specified somewhere? Or it's your proposal. > > > > What I mentioned in the above should be abundantly obvious to the > > informed reader of RSVP and LSP Hierarchy specs. > > > > > Then, is there a scalability issue here? > > > > No. > > > > > Also, C and F could be thousands mile away (in the transport > > > network) and the control channel bandwidth is expensive. > > > > GMPLS assumes that control channel is more than just 56Kbits/sec link. > > > > Or to put it differently, control channels used by GMPLS have more than > > enough capacity for RSVP Hellos. > > > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > > > > be able to recover the Interface ID it assigns to L1 from > > > > a combination of (a) the OSPF/ISIS link state database that > > > > F would recover, and (b) the Forward Interface ID (the one > > > > assigned by C). > > > > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the n it > > > has to recover its FA info first. How? > > > > The answer should be abundantly obvious to the informed reader. > > > > And to make it crystal clear, I have no intention in designing your > > products for you. > > > > > > > Let us say the node can resynchronize its neighbor if > > > > > the neighbor restarts and requests state recovery. But > > > > > the issue is how a node can advertise that it does not > > > > > need recovery since all its state was preserved? > > > > > > > > By treating is the same way as the way the spec handles > > > > control channel fault. > > > > > > > > > > If a node can recover states from NVRAM or OS (this solution is > > > cheaper and have been implemented). It may not implement the spec. > > > How could a neighboring node, which implements the spec, not tear > > > down data connections mistakenly? Similar to a backward compatibility > > > problem, even not. > > > > Stating the obvious: interoperability with a node that doesn't implement > > the spec is outside the scope of the spec. > > > > > > > RECOVERY LABEL does not come into picture unless the node > > > > > that is upstream to the restarting node has already received > > > > > a Resv. > > > > > > > > Wrong. Quoting 9.5.3: > > > > > > > > Upon detecting a restart with a neighbor that supports state > > > > recovery, a node SHOULD refresh all Path state shared with that > > > > neighbor. > > > > > > > > So, as you can hopefully see from the above, the upstream node doesn't > > > > wait until it receives a Resv. > > > > > > > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirem ent) > > > Again, back to the telecom world (sorry about this, yet we are talking ab out > > > GMPLS), typically only the established pathes are preserved. Pending requ ests > > > may be purged/aborted. Then how? > > > > Note the verb is "SHOULD", not "MUST". The rest should be > > obvious to the informed reader. > > > > > > > In case of PSC devices, it may be OK to remove state that > > > > > is not resynchronized at the end of the recovery period, > > > > > and the recovery period advertised might reflect that. > > > > > But for LSPs in transport networks, one might want to > > > > > have a different recovery period to avoid any LSP from > > > > > going down because of recovery timer expiry. > > > > > > > > There is no requirement for a node to advertise exactly the > > > > same Restart_Cap on all the interfaces. So, on PSC interfaces > > > > the node could advertise that it will remove the state that > > > > isn't syncronized at the end of the recovery period, while > > > > on the TDM interface precisely the same node could advertise > > > > that the LSPs would be kept even after the recovery time expires. > > > > > > > > > > So, restart_cap is per interface based? > > > > yes. > > > > > Is the spec going to be enhanced/clarified? > > > > The current spec need not be enhanced/clarified - what I mentioned in the > > above should be abundantly obvious to the informed reader. > > > > > > > The first problems seems to be there still - consider two > > > > > adjacent nodes restarting. They both act both as the restarting > > > > > node as well as the neighbor to the restarting node. So, once > > > > > they learn the state from the upstream neighbor, do they use > > > > > suggested label or the recovery label when they send the path > > > > > message to the just restarted downstream neighbor? > > > > > > > > The recovery label. > > > > > > > > The following should be added to the existing text from the document: > > > > > > > > In the special case where a restarting node also has a restating > > > > downstream neighbor, a Recovery_Label object should be used instead > > > > of a Suggested_Label object. > > > > > > How does a recovering NE know that its neighbor is also recovering? it ma y > > > lose the instance number totally > > > > It's advertised in the neighbor's hellos. > > > > Yakov. -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 09:10:38 -0700 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F81360F5@baker.datcon.co.uk> From: Edward Harrison To: 'Lou Berger' Cc: ccamp@ops.ietf.org Subject: RE: update GMPLS signaling documents Date: Mon, 22 Oct 2001 17:04:54 +0100 Deferred-Delivery: Mon, 22 Oct 2001 17:07:00 +0100 MIME-Version: 1.0 Content-Type: text/plain Lou, I'm interested to know the rationale behind the two new flags introduced to the Admin Status object in draft-ietf-mpls-generalized-signaling-06. Unfortunately I can't seem to find any comments relating to them in the CCAMP or MPLS mailing lists. Is there any chance you could either point me to the appropriate mails or let me know what the relevant comments were (for example, if they were private emails or phone comments)? Thanks very much, Ed ---------- Edward Harrison mailto:eph@dataconnection.com Network Convergence Group Data Connection Ltd. http://www.dataconnection.com/ Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: 01 October 2001 07:48 To: ccamp@ops.ietf.org Subject: update GMPLS signaling documents FYI - Updated versions of the signaling and RSVP-TE documents have been submitted. The CR-LDP version is forthcoming. The updates address comments received during the August meeting and comment period. Here's a summary of changes: draft-ietf-mpls-generalized-signaling-06.txt Changes from previous version: o Removed redundant encoding type o Revised Admin Status Usage (per comments and also removed potential race condition) o Clarified text related to interface bundling (To be consistent with updated bundling draft.) o Minor editorial changes and clarifications o Revised G-PID (per comments on list) draft-ietf-mpls-generalized-rsvp-te-05.txt Changes from previous version: o Revised Admin Status Usage (per comments and also removed potential race condition) o Clarified text related to interface bundling (To be consistent with updated bundling draft.) o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel Separation by allowing identification of errored interface.) o Added U bit to Label RRO subobject (Per comment, to match defined ERO.) o Clarified usage of Restart_Cap o Replaced use of Suggested_Label during recovery with new Recovery_Label (Per last WG session) o Added IANA Considerations o Minor editorial changes and clarifications For those who don't want to wait, the drafts are available from: http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt Lou Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Oct 2001 08:41:12 -0700 Message-ID: From: Yanhe Fan To: "'Zhi-Wei Lin'" Cc: John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Mon, 22 Oct 2001 11:34:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Zhi, What B does is breaking the label association between A and C by crossing connect the time slots. If the cross connect performed by B is fixed (in your case), what needs to do is just to rebuild the label association by configuration or a protocol such as LMP; If the cross connect is not fixed but dynamic, the best thing to do is to make B a GMPLS speaker. Yanhe -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Friday, October 19, 2001 6:01 PM To: Yanhe Fan Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... Hi Yanhe, Maybe there is some misunderstanding. Node B is strictly not GMPLS. It is simply part of the network that made up the "dumb" pipe. And because the control plane control channel is separate, A and C can be adjacent without ever knowing who B is or that even B existed. From A and C's point of view, the network looks like: A ----- C Think of the case of how a BGP sees an area. If an area is made up of: A -- B -- C and B is internal router, does BGP "see" B? Zhi Yanhe Fan wrote: > Hi, Zhi > > >>For the label value for SONET/SDH or the label description in the >>generic draft, the label is defined as directly representing the >>"timeslot". Now if I have a control plane controlled transport network >>that goes through a ADM that is not control plane controlled, as: >> >> >>+--------+ +--------+ +--------+ >>| | ---1--------- | | ----1-------- | | >>| | ---2--------- | | ----2-------- | | >>| A | ---3--------- | B | ----3-------- | C | >>| | ---4--------- | | ----4-------- | | >>| | ---5--------- | | ----5-------- | | >>+--------+ +--------+ +--------+ >> >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >>has labels 1,2,3,4,5 incoming. >> >>Now imagine that at B, it actually has a fixed cross-connect that >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. >> >>Now when A GMPLS sends a message to C, the label it uses is "1". >>However, the connection/LSP associated with timeslot "1" is actually the >>label of timeslot "2" at C. >> > > In this case, you're trying to use GMPLS to setup an LSP cross a node (B) > which can't understand GMPLS. > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > GMPLS if B can't understand GMPLS? > > Now imagine A and B are LSRs, and B is a conventional router (can't > understand > MPLS), can you setup an LSP A-B-C? > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > understand PNNI at all? > > My point is that in order to make you case work, some additional work need > to > be done besie simply using GMPLS as singnaling protocol, becase some node on > the path is not GMPLS speakers. A and C needs the info of time slot aligment > > between them. This can be done by some configurations, some link management > protocls (LMP maybe) etc. As long as A and C have this piece of info, > eveything > works fine. > > Yanhe > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Oct 2001 05:02:24 -0700 Message-ID: <3BD2B802.3427F87B@alcatel.be> Date: Sun, 21 Oct 2001 13:56:50 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: manoj juneja CC: zwlin@lucent.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------DC51005CBB896A044C61013B" This is a multi-part message in MIME format. --------------DC51005CBB896A044C61013B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Manoj, My previous e-mail was a generic one, not only focused on your question concerning the conversion table. I personally think the following on this issue: > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table > as an addendum to the draft. This would apply to the SDH/Sonet document ... however i see it more adapted to the "SDH/Sonet framework" one. Personally i think that in such I-D it can be useful (please contact Eric for that purpose) and so i think we are in agreement here. Here the response to your other questions: > 1. Can someone please tell me the usage of bandwidth encoding > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > will be drived from the signal type field. How the bandwidth encoding > type will be interpreted in case of other LSP encoding types (lambda, > waveband, fiber etc) ? The draft should list down the cases in which > the bandwidth encoding type is to be filled. To which I-D do you refer here, in GMPLS-SIG this is well explained. For the SDH/Sonet one, we had this discussion sometime ago and the outcome was to "un-use" this value (even if i don't think it is the best solution but since discussion brought us to more complexity...) Remember that the resulting bandwidth is dependent on the application of the different field on the elementary Signal Type resulting in a final signal. Anyway, if it has to be detailed it would be in the SDH/Sonet and other technology dependent ones. > 2. Usage of Label Set : > There are cases mentioned in the draft which explains the usage > of label set. It should also mention that the range of labels in > SDH/SONET does not make sense. Ranges in label set are applicable in > case of waveband/lambda switching etc. The range in label set is valid > in SDH/SONET only if there is one element in the range i.e. start range > and end range should be same. Is it a question or an assertion ? I refer you also here to my previous e-mail > 3. There are couple of scenarios where there can be contention for > establishing bi-directional LSPs. All the scenarios are not listed in > the document. If it is not possible to list all the scenarios then the > draft should say that this is one of the example scenario. The > contention can also be possible in case where same label set and > upstream label are used in both the directions. This has been extensively discussed on this mailing list i am referring you to the outcome of this discussion > 4. As per OIF, the carrier requirement is that SDH LSPs should be > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS > has different set of carrier requirements in this regard ? The I-D is covering HO/STS SPE and LOVC/VT for completeness (as described in G.707 ANSI T1.105), OIF UNI 1.0 uses a subset. Why not. > 6. The relation between switching capability and LSP encoding type > should be clearly explained in the drafts. As the switching capability > field was added very late (just 2 months back) in the drafts, > specific reason should be mentioned for its addition. ... ? re-phrasing one of the remarks i saw this week can be applied here we are not discussing "requirement" document here Hope this will help you, Regards, Dimitri. manoj juneja wrote: > > Hi Dimitri, > I don't think there is any issue in including the > conversion table in the draft. Even this table can be kept in some > informational draft. The inclusion of conversion table is a valid thing and > probably nobody on ccamp mailing list would like oppose. I > still didn't get answers to other points in my mail. > > Regards, > manoj. > > >From: Dimitri Papadimitriou > >To: Zhi-Wei Lin > >CC: manoj juneja , kireeti@juniper.net, > >ccamp@ops.ietf.org > >Subject: Re: Moving right along ... > >Date: Sat, 20 Oct 2001 16:05:01 +0200 > > > >Hi Zhi, > > > >I would like to remember you something here: the SDH/Sonet I-D is not > >1) a textbook on how to use GMPLS-SIG but must be understood an > > additional document complementing the signalling one > >2) a tutorial on Sonet/SDH (a framework has been proposed for that > > purpose) > > > >We have spent hard time together with the SDH/Sonet I-D co-authors in > >order to find the best balance between reproducing well known SDH/Sonet > >concepts and paragraphs really providing an added value in this document > > > >Of course we can not make 100% people happy (even between the list of > >30 co-authors) some of us found there was too much explanations while > >others were requesting more content. > > > >Therefore for the non-covered content we are referencing the appropriate > >document either it comes from ITU or IETF. Please understand that we > >can not wait until everybody in this world has no question anymore or a > >full understanding on any technical detail in order to go forward with > >these documents. > > > >Thanks for your "virtual" understanding, > >Dimitri. > > > >Zhi-Wei Lin wrote: > > > > > > Hi Manoj, > > > > > > I agree with many of your points. I actually submitted an I-D several > > > months ago (I think it's expired) that proposes some text to add to the > > > GMPLS SONET/SDH on the rules for setting different values, such as for > > > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the > > > range of acceptable value of X, etc. > > > > > > My rationale at that time was that not everyone is a SONET/SDH expert > > > and instead of asking them to look somewhere else and dig through those > > > documents to find the answer, if we can provide them in the GMPLS set of > > > drafts it would be extremely useful for the entire IETF community and > > > would help clarify the usage of these parameters. But unfortunately if > > > you were at the meeting at the time, it wasn't accepted because some > > > folks thought that these were obvious or that this info is not needed > > > because they can find it in other places referenced... > > > > > > If you have the old drafts, the file was: > > > draft-lin-ccamp-ipo-common-label-request-01 > > > > > > But anyway...people will just have to read all the referenced documents > > > to understand how to use the different parameters... > > > > > > Zhi > > > > > > manoj juneja wrote: > > > > > > > Hi Kireeti, > > > > I am not an active member of IETF but a regular reader of > > > > GMPLS drafts. I am not sure how much weight my mail will carry but as > >a > > > > regular reader of these drafts, I recommend the following points > >should > > > > be made clear in the documents before proceeding to the last call. > > > > > > > > > > > > 1. Can someone please tell me the usage of bandwidth encoding > > > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > > > > will be drived from the signal type field. How the bandwidth encoding > > > > type will be interpreted in case of other LSP encoding types (lambda, > > > > waveband, fiber etc) ? The draft should list down the cases in which > >the > > > > bandwidth encoding type is to be filled. > > > > > > > > 2. Usage of Label Set : > > > > There are cases mentioned in the draft which explains the usage > > > > of label set. It should also mention that the range of labels in > > > > SDH/SONET does not make sense. Ranges in label set are applicable in > > > > case of waveband/lambda switching etc. The range in label set is valid > > > > in SDH/SONET only if there is one element in the range i.e. start > >range > > > > and end range should be same. > > > > > > > > 3. There are couple of scenarios where there can be contention for > > > > establishing bi-directional LSPs. All the scenarios are not listed in > > > > the document. If it is not possible to list all the scenarios then the > > > > draft should say that this is one of the example scenario. The > > > > contention can also be possible in case where same label set and > > > > upstream label are used in both the directions. > > > > > > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be > > > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > > > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean > >GMPLS > > > > has different set of carrier requirements in this regard ? > > > > > > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as > > > > an addendum to the draft. > > > > > > > > 6. The relation between switching capability and LSP encoding type > > > > should be clearly explained in the drafts. As the switching capability > > > > field was added very late (just 2 months back) in the drafts, > > > > specific reason should be mentioned for its addition. > > > > > > > > Regards, > > > > manoj. > > > > > > > > > > > > > > > >> From: Kireeti Kompella > > > >> To: ccamp@ops.ietf.org > > > >> Subject: Moving right along ... > > > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) > > > >> > > > >> Despite the energetic subject line, we the WG chairs have been > > > >> lax in our duties. So, here goes: > > > >> > > > >> Lou has submitted the latest versions of the generalized > > > >> signaling documents quite some time ago (thanks, Lou): > > > >> > > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > > >> draft-ietf-mpls-generalized-signaling-06.txt > > > >> > > > >> Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > >> > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > >> > > > >> All of these should have addressed the issues raised in the earlier > > > >> versions. Please read the new versions, and send your comments to > > > >> the list by Tuesday Oct 23. At that point, when the final round > > > >> of comments have been addressed, these docs will go to IESG Last > > > >> Call. If any one objects to sending these docs to IESG Last Call, > > > >> raise your issues now. > > > >> > > > >> I see that the GMPLS architecture document is a CCAMP WG doc, but > > > >> the minutes say that we should look for consensus on the list. So, > > > >> if you think this doc *shouldn't* be a WG doc, let us know. (If we > > > >> arrived at a consensus, remind me :-)) If nothing is heard, the doc > > > >> will progress to WG Last Call. > > > >> > > > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > > >> CCAMP WG docs; consensus at the meeting was Yes. Please let the > > > >> list know what your thinking is on these. (BTW, both these docs > > > >> were to have some edits done. If the authors could do that before > > > >> the next IETF, we can try to make more progress then.) > > > >> > > > >> The MIB overview doc was recently posted. Please read and comment > > > >> to the list. > > > >> > > > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > >> was generally thought to be useful; it will be published as a > > > >> CCAMP informational doc. This begins a two week Last Call on > > > >> the doc, ending Tuesday Oct 30. > > > >> > > > >> There was no consensus on whether the GMPLS framework should be > > > >> a CCAMP WG doc. Please indicate your pleasure. > > > >> > > > >> draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > > >> raised that this draft is close to ready for WG Last Call. Please > > > >> review it, and let us know if you disagree. > > > >> > > > >> The OLI requirements doc was broadly accepted. Please let the > > > >> list know if you think this doc should be a WG doc. > > > >> > > > >> It's still open whether we (the IETF) should be working on > > > >> LMP-WDM. I urge the authors to keep on working on the doc, and > > > >> keeping it in sync with LMP; however, we will postpone making it > > > >> a CCAMP WG doc until the issue is resolved. Hopefully that will > > > >> happen in Salt Lake City. > > > >> > > > >> There was reasonable interest in the tunnel trace requirements > > > >> doc. Let's formalize this: do you think this should be made a > > > >> CCAMP WG document? > > > >> > > > >> Summary: > > > >> > > > >> 1) Final comments and IESG Last Call readiness for: > > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > > >> draft-ietf-mpls-generalized-signaling-06.txt > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > >> > > > >> 2) Should the following documents be CCAMP WG docs? > > > >> draft-bonica-tunneltrace-02.txt > > > >> draft-fontana-ccamp-gmpls-g709-00.txt > > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > > >> draft-many-ccamp-gmpls-framework-00.txt > > > >> draft-many-oli-reqts-00.txt > > > >> > > > >> 3) Comment on MIB overview. > > > >> > > > >> 4) Two week Last Call comments on > > > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > >> > > > >> 5) Last Call readiness of > > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > > >> draft-ietf-ccamp-lmp-01.txt > > > >> > > > >> Thanks, > > > >> Kireeti. > > > >> > > > > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > > > > > > > > > ><< dimitri.papadimitriou.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------DC51005CBB896A044C61013B Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------DC51005CBB896A044C61013B-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Oct 2001 16:35:08 -0700 From: "manoj juneja" To: dimitri.papadimitriou@alcatel.be, zwlin@lucent.com Cc: kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: Moving right along ... Date: Sat, 20 Oct 2001 16:29:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dimitri, I don't think there is any issue in including the conversion table in the draft. Even this table can be kept in some informational draft. The inclusion of conversion table is a valid thing and probably nobody on ccamp mailing list would like oppose. I still didn't get answers to other points in my mail. Regards, manoj. >From: Dimitri Papadimitriou >To: Zhi-Wei Lin >CC: manoj juneja , kireeti@juniper.net, >ccamp@ops.ietf.org >Subject: Re: Moving right along ... >Date: Sat, 20 Oct 2001 16:05:01 +0200 > >Hi Zhi, > >I would like to remember you something here: the SDH/Sonet I-D is not >1) a textbook on how to use GMPLS-SIG but must be understood an > additional document complementing the signalling one >2) a tutorial on Sonet/SDH (a framework has been proposed for that > purpose) > >We have spent hard time together with the SDH/Sonet I-D co-authors in >order to find the best balance between reproducing well known SDH/Sonet >concepts and paragraphs really providing an added value in this document > >Of course we can not make 100% people happy (even between the list of >30 co-authors) some of us found there was too much explanations while >others were requesting more content. > >Therefore for the non-covered content we are referencing the appropriate >document either it comes from ITU or IETF. Please understand that we >can not wait until everybody in this world has no question anymore or a >full understanding on any technical detail in order to go forward with >these documents. > >Thanks for your "virtual" understanding, >Dimitri. > >Zhi-Wei Lin wrote: > > > > Hi Manoj, > > > > I agree with many of your points. I actually submitted an I-D several > > months ago (I think it's expired) that proposes some text to add to the > > GMPLS SONET/SDH on the rules for setting different values, such as for > > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the > > range of acceptable value of X, etc. > > > > My rationale at that time was that not everyone is a SONET/SDH expert > > and instead of asking them to look somewhere else and dig through those > > documents to find the answer, if we can provide them in the GMPLS set of > > drafts it would be extremely useful for the entire IETF community and > > would help clarify the usage of these parameters. But unfortunately if > > you were at the meeting at the time, it wasn't accepted because some > > folks thought that these were obvious or that this info is not needed > > because they can find it in other places referenced... > > > > If you have the old drafts, the file was: > > draft-lin-ccamp-ipo-common-label-request-01 > > > > But anyway...people will just have to read all the referenced documents > > to understand how to use the different parameters... > > > > Zhi > > > > manoj juneja wrote: > > > > > Hi Kireeti, > > > I am not an active member of IETF but a regular reader of > > > GMPLS drafts. I am not sure how much weight my mail will carry but as >a > > > regular reader of these drafts, I recommend the following points >should > > > be made clear in the documents before proceeding to the last call. > > > > > > > > > 1. Can someone please tell me the usage of bandwidth encoding > > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > > > will be drived from the signal type field. How the bandwidth encoding > > > type will be interpreted in case of other LSP encoding types (lambda, > > > waveband, fiber etc) ? The draft should list down the cases in which >the > > > bandwidth encoding type is to be filled. > > > > > > 2. Usage of Label Set : > > > There are cases mentioned in the draft which explains the usage > > > of label set. It should also mention that the range of labels in > > > SDH/SONET does not make sense. Ranges in label set are applicable in > > > case of waveband/lambda switching etc. The range in label set is valid > > > in SDH/SONET only if there is one element in the range i.e. start >range > > > and end range should be same. > > > > > > 3. There are couple of scenarios where there can be contention for > > > establishing bi-directional LSPs. All the scenarios are not listed in > > > the document. If it is not possible to list all the scenarios then the > > > draft should say that this is one of the example scenario. The > > > contention can also be possible in case where same label set and > > > upstream label are used in both the directions. > > > > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be > > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean >GMPLS > > > has different set of carrier requirements in this regard ? > > > > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as > > > an addendum to the draft. > > > > > > 6. The relation between switching capability and LSP encoding type > > > should be clearly explained in the drafts. As the switching capability > > > field was added very late (just 2 months back) in the drafts, > > > specific reason should be mentioned for its addition. > > > > > > Regards, > > > manoj. > > > > > > > > > > > >> From: Kireeti Kompella > > >> To: ccamp@ops.ietf.org > > >> Subject: Moving right along ... > > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) > > >> > > >> Despite the energetic subject line, we the WG chairs have been > > >> lax in our duties. So, here goes: > > >> > > >> Lou has submitted the latest versions of the generalized > > >> signaling documents quite some time ago (thanks, Lou): > > >> > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > >> draft-ietf-mpls-generalized-signaling-06.txt > > >> > > >> Also, Eric has posted the SONET/SDH documents (merci, Eric): > > >> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > >> > > >> All of these should have addressed the issues raised in the earlier > > >> versions. Please read the new versions, and send your comments to > > >> the list by Tuesday Oct 23. At that point, when the final round > > >> of comments have been addressed, these docs will go to IESG Last > > >> Call. If any one objects to sending these docs to IESG Last Call, > > >> raise your issues now. > > >> > > >> I see that the GMPLS architecture document is a CCAMP WG doc, but > > >> the minutes say that we should look for consensus on the list. So, > > >> if you think this doc *shouldn't* be a WG doc, let us know. (If we > > >> arrived at a consensus, remind me :-)) If nothing is heard, the doc > > >> will progress to WG Last Call. > > >> > > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > >> CCAMP WG docs; consensus at the meeting was Yes. Please let the > > >> list know what your thinking is on these. (BTW, both these docs > > >> were to have some edits done. If the authors could do that before > > >> the next IETF, we can try to make more progress then.) > > >> > > >> The MIB overview doc was recently posted. Please read and comment > > >> to the list. > > >> > > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > >> was generally thought to be useful; it will be published as a > > >> CCAMP informational doc. This begins a two week Last Call on > > >> the doc, ending Tuesday Oct 30. > > >> > > >> There was no consensus on whether the GMPLS framework should be > > >> a CCAMP WG doc. Please indicate your pleasure. > > >> > > >> draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > >> raised that this draft is close to ready for WG Last Call. Please > > >> review it, and let us know if you disagree. > > >> > > >> The OLI requirements doc was broadly accepted. Please let the > > >> list know if you think this doc should be a WG doc. > > >> > > >> It's still open whether we (the IETF) should be working on > > >> LMP-WDM. I urge the authors to keep on working on the doc, and > > >> keeping it in sync with LMP; however, we will postpone making it > > >> a CCAMP WG doc until the issue is resolved. Hopefully that will > > >> happen in Salt Lake City. > > >> > > >> There was reasonable interest in the tunnel trace requirements > > >> doc. Let's formalize this: do you think this should be made a > > >> CCAMP WG document? > > >> > > >> Summary: > > >> > > >> 1) Final comments and IESG Last Call readiness for: > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > >> draft-ietf-mpls-generalized-signaling-06.txt > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > >> > > >> 2) Should the following documents be CCAMP WG docs? > > >> draft-bonica-tunneltrace-02.txt > > >> draft-fontana-ccamp-gmpls-g709-00.txt > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > >> draft-many-ccamp-gmpls-framework-00.txt > > >> draft-many-oli-reqts-00.txt > > >> > > >> 3) Comment on MIB overview. > > >> > > >> 4) Two week Last Call comments on > > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > >> > > >> 5) Last Call readiness of > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > >> draft-ietf-ccamp-lmp-01.txt > > >> > > >> Thanks, > > >> Kireeti. > > >> > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp > > > > > > ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Oct 2001 16:34:55 -0700 From: "manoj juneja" To: dimitri.papadimitriou@alcatel.be, zwlin@lucent.com Cc: kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: Moving right along ... Date: Sat, 20 Oct 2001 16:29:45 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dimitri, I don't think there is any issue in including the conversion table in the draft. Even this table can be kept in some informational draft. The inclusion of conversion table is a valid thing and probably nobody on ccamp mailing list would like oppose. I still didn't get answers to other points in my mail. Regards, manoj. >From: Dimitri Papadimitriou >To: Zhi-Wei Lin >CC: manoj juneja , kireeti@juniper.net, >ccamp@ops.ietf.org >Subject: Re: Moving right along ... >Date: Sat, 20 Oct 2001 16:05:01 +0200 > >Hi Zhi, > >I would like to remember you something here: the SDH/Sonet I-D is not >1) a textbook on how to use GMPLS-SIG but must be understood an > additional document complementing the signalling one >2) a tutorial on Sonet/SDH (a framework has been proposed for that > purpose) > >We have spent hard time together with the SDH/Sonet I-D co-authors in >order to find the best balance between reproducing well known SDH/Sonet >concepts and paragraphs really providing an added value in this document > >Of course we can not make 100% people happy (even between the list of >30 co-authors) some of us found there was too much explanations while >others were requesting more content. > >Therefore for the non-covered content we are referencing the appropriate >document either it comes from ITU or IETF. Please understand that we >can not wait until everybody in this world has no question anymore or a >full understanding on any technical detail in order to go forward with >these documents. > >Thanks for your "virtual" understanding, >Dimitri. > >Zhi-Wei Lin wrote: > > > > Hi Manoj, > > > > I agree with many of your points. I actually submitted an I-D several > > months ago (I think it's expired) that proposes some text to add to the > > GMPLS SONET/SDH on the rules for setting different values, such as for > > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the > > range of acceptable value of X, etc. > > > > My rationale at that time was that not everyone is a SONET/SDH expert > > and instead of asking them to look somewhere else and dig through those > > documents to find the answer, if we can provide them in the GMPLS set of > > drafts it would be extremely useful for the entire IETF community and > > would help clarify the usage of these parameters. But unfortunately if > > you were at the meeting at the time, it wasn't accepted because some > > folks thought that these were obvious or that this info is not needed > > because they can find it in other places referenced... > > > > If you have the old drafts, the file was: > > draft-lin-ccamp-ipo-common-label-request-01 > > > > But anyway...people will just have to read all the referenced documents > > to understand how to use the different parameters... > > > > Zhi > > > > manoj juneja wrote: > > > > > Hi Kireeti, > > > I am not an active member of IETF but a regular reader of > > > GMPLS drafts. I am not sure how much weight my mail will carry but as >a > > > regular reader of these drafts, I recommend the following points >should > > > be made clear in the documents before proceeding to the last call. > > > > > > > > > 1. Can someone please tell me the usage of bandwidth encoding > > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > > > will be drived from the signal type field. How the bandwidth encoding > > > type will be interpreted in case of other LSP encoding types (lambda, > > > waveband, fiber etc) ? The draft should list down the cases in which >the > > > bandwidth encoding type is to be filled. > > > > > > 2. Usage of Label Set : > > > There are cases mentioned in the draft which explains the usage > > > of label set. It should also mention that the range of labels in > > > SDH/SONET does not make sense. Ranges in label set are applicable in > > > case of waveband/lambda switching etc. The range in label set is valid > > > in SDH/SONET only if there is one element in the range i.e. start >range > > > and end range should be same. > > > > > > 3. There are couple of scenarios where there can be contention for > > > establishing bi-directional LSPs. All the scenarios are not listed in > > > the document. If it is not possible to list all the scenarios then the > > > draft should say that this is one of the example scenario. The > > > contention can also be possible in case where same label set and > > > upstream label are used in both the directions. > > > > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be > > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean >GMPLS > > > has different set of carrier requirements in this regard ? > > > > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as > > > an addendum to the draft. > > > > > > 6. The relation between switching capability and LSP encoding type > > > should be clearly explained in the drafts. As the switching capability > > > field was added very late (just 2 months back) in the drafts, > > > specific reason should be mentioned for its addition. > > > > > > Regards, > > > manoj. > > > > > > > > > > > >> From: Kireeti Kompella > > >> To: ccamp@ops.ietf.org > > >> Subject: Moving right along ... > > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) > > >> > > >> Despite the energetic subject line, we the WG chairs have been > > >> lax in our duties. So, here goes: > > >> > > >> Lou has submitted the latest versions of the generalized > > >> signaling documents quite some time ago (thanks, Lou): > > >> > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > >> draft-ietf-mpls-generalized-signaling-06.txt > > >> > > >> Also, Eric has posted the SONET/SDH documents (merci, Eric): > > >> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > >> > > >> All of these should have addressed the issues raised in the earlier > > >> versions. Please read the new versions, and send your comments to > > >> the list by Tuesday Oct 23. At that point, when the final round > > >> of comments have been addressed, these docs will go to IESG Last > > >> Call. If any one objects to sending these docs to IESG Last Call, > > >> raise your issues now. > > >> > > >> I see that the GMPLS architecture document is a CCAMP WG doc, but > > >> the minutes say that we should look for consensus on the list. So, > > >> if you think this doc *shouldn't* be a WG doc, let us know. (If we > > >> arrived at a consensus, remind me :-)) If nothing is heard, the doc > > >> will progress to WG Last Call. > > >> > > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > >> CCAMP WG docs; consensus at the meeting was Yes. Please let the > > >> list know what your thinking is on these. (BTW, both these docs > > >> were to have some edits done. If the authors could do that before > > >> the next IETF, we can try to make more progress then.) > > >> > > >> The MIB overview doc was recently posted. Please read and comment > > >> to the list. > > >> > > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > >> was generally thought to be useful; it will be published as a > > >> CCAMP informational doc. This begins a two week Last Call on > > >> the doc, ending Tuesday Oct 30. > > >> > > >> There was no consensus on whether the GMPLS framework should be > > >> a CCAMP WG doc. Please indicate your pleasure. > > >> > > >> draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > >> raised that this draft is close to ready for WG Last Call. Please > > >> review it, and let us know if you disagree. > > >> > > >> The OLI requirements doc was broadly accepted. Please let the > > >> list know if you think this doc should be a WG doc. > > >> > > >> It's still open whether we (the IETF) should be working on > > >> LMP-WDM. I urge the authors to keep on working on the doc, and > > >> keeping it in sync with LMP; however, we will postpone making it > > >> a CCAMP WG doc until the issue is resolved. Hopefully that will > > >> happen in Salt Lake City. > > >> > > >> There was reasonable interest in the tunnel trace requirements > > >> doc. Let's formalize this: do you think this should be made a > > >> CCAMP WG document? > > >> > > >> Summary: > > >> > > >> 1) Final comments and IESG Last Call readiness for: > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > > >> draft-ietf-mpls-generalized-signaling-06.txt > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > >> > > >> 2) Should the following documents be CCAMP WG docs? > > >> draft-bonica-tunneltrace-02.txt > > >> draft-fontana-ccamp-gmpls-g709-00.txt > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > >> draft-many-ccamp-gmpls-framework-00.txt > > >> draft-many-oli-reqts-00.txt > > >> > > >> 3) Comment on MIB overview. > > >> > > >> 4) Two week Last Call comments on > > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > >> > > >> 5) Last Call readiness of > > >> draft-ietf-ccamp-gmpls-architecture-00.txt > > >> draft-ietf-ccamp-lmp-01.txt > > >> > > >> Thanks, > > >> Kireeti. > > >> > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp > > > > > > ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Oct 2001 07:09:52 -0700 Message-ID: <3BD1848D.62750AAA@alcatel.be> Date: Sat, 20 Oct 2001 16:05:01 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Zhi-Wei Lin CC: manoj juneja , kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------49A55E47AED14BB4283B6C9A" This is a multi-part message in MIME format. --------------49A55E47AED14BB4283B6C9A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Zhi, I would like to remember you something here: the SDH/Sonet I-D is not 1) a textbook on how to use GMPLS-SIG but must be understood an additional document complementing the signalling one 2) a tutorial on Sonet/SDH (a framework has been proposed for that purpose) We have spent hard time together with the SDH/Sonet I-D co-authors in order to find the best balance between reproducing well known SDH/Sonet concepts and paragraphs really providing an added value in this document Of course we can not make 100% people happy (even between the list of 30 co-authors) some of us found there was too much explanations while others were requesting more content. Therefore for the non-covered content we are referencing the appropriate document either it comes from ITU or IETF. Please understand that we can not wait until everybody in this world has no question anymore or a full understanding on any technical detail in order to go forward with these documents. Thanks for your "virtual" understanding, Dimitri. Zhi-Wei Lin wrote: > > Hi Manoj, > > I agree with many of your points. I actually submitted an I-D several > months ago (I think it's expired) that proposes some text to add to the > GMPLS SONET/SDH on the rules for setting different values, such as for > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the > range of acceptable value of X, etc. > > My rationale at that time was that not everyone is a SONET/SDH expert > and instead of asking them to look somewhere else and dig through those > documents to find the answer, if we can provide them in the GMPLS set of > drafts it would be extremely useful for the entire IETF community and > would help clarify the usage of these parameters. But unfortunately if > you were at the meeting at the time, it wasn't accepted because some > folks thought that these were obvious or that this info is not needed > because they can find it in other places referenced... > > If you have the old drafts, the file was: > draft-lin-ccamp-ipo-common-label-request-01 > > But anyway...people will just have to read all the referenced documents > to understand how to use the different parameters... > > Zhi > > manoj juneja wrote: > > > Hi Kireeti, > > I am not an active member of IETF but a regular reader of > > GMPLS drafts. I am not sure how much weight my mail will carry but as a > > regular reader of these drafts, I recommend the following points should > > be made clear in the documents before proceeding to the last call. > > > > > > 1. Can someone please tell me the usage of bandwidth encoding > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > > will be drived from the signal type field. How the bandwidth encoding > > type will be interpreted in case of other LSP encoding types (lambda, > > waveband, fiber etc) ? The draft should list down the cases in which the > > bandwidth encoding type is to be filled. > > > > 2. Usage of Label Set : > > There are cases mentioned in the draft which explains the usage > > of label set. It should also mention that the range of labels in > > SDH/SONET does not make sense. Ranges in label set are applicable in > > case of waveband/lambda switching etc. The range in label set is valid > > in SDH/SONET only if there is one element in the range i.e. start range > > and end range should be same. > > > > 3. There are couple of scenarios where there can be contention for > > establishing bi-directional LSPs. All the scenarios are not listed in > > the document. If it is not possible to list all the scenarios then the > > draft should say that this is one of the example scenario. The > > contention can also be possible in case where same label set and > > upstream label are used in both the directions. > > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS > > has different set of carrier requirements in this regard ? > > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as > > an addendum to the draft. > > > > 6. The relation between switching capability and LSP encoding type > > should be clearly explained in the drafts. As the switching capability > > field was added very late (just 2 months back) in the drafts, > > specific reason should be mentioned for its addition. > > > > Regards, > > manoj. > > > > > > > >> From: Kireeti Kompella > >> To: ccamp@ops.ietf.org > >> Subject: Moving right along ... > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) > >> > >> Despite the energetic subject line, we the WG chairs have been > >> lax in our duties. So, here goes: > >> > >> Lou has submitted the latest versions of the generalized > >> signaling documents quite some time ago (thanks, Lou): > >> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > >> draft-ietf-mpls-generalized-signaling-06.txt > >> > >> Also, Eric has posted the SONET/SDH documents (merci, Eric): > >> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > >> > >> All of these should have addressed the issues raised in the earlier > >> versions. Please read the new versions, and send your comments to > >> the list by Tuesday Oct 23. At that point, when the final round > >> of comments have been addressed, these docs will go to IESG Last > >> Call. If any one objects to sending these docs to IESG Last Call, > >> raise your issues now. > >> > >> I see that the GMPLS architecture document is a CCAMP WG doc, but > >> the minutes say that we should look for consensus on the list. So, > >> if you think this doc *shouldn't* be a WG doc, let us know. (If we > >> arrived at a consensus, remind me :-)) If nothing is heard, the doc > >> will progress to WG Last Call. > >> > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > >> CCAMP WG docs; consensus at the meeting was Yes. Please let the > >> list know what your thinking is on these. (BTW, both these docs > >> were to have some edits done. If the authors could do that before > >> the next IETF, we can try to make more progress then.) > >> > >> The MIB overview doc was recently posted. Please read and comment > >> to the list. > >> > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > >> was generally thought to be useful; it will be published as a > >> CCAMP informational doc. This begins a two week Last Call on > >> the doc, ending Tuesday Oct 30. > >> > >> There was no consensus on whether the GMPLS framework should be > >> a CCAMP WG doc. Please indicate your pleasure. > >> > >> draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > >> raised that this draft is close to ready for WG Last Call. Please > >> review it, and let us know if you disagree. > >> > >> The OLI requirements doc was broadly accepted. Please let the > >> list know if you think this doc should be a WG doc. > >> > >> It's still open whether we (the IETF) should be working on > >> LMP-WDM. I urge the authors to keep on working on the doc, and > >> keeping it in sync with LMP; however, we will postpone making it > >> a CCAMP WG doc until the issue is resolved. Hopefully that will > >> happen in Salt Lake City. > >> > >> There was reasonable interest in the tunnel trace requirements > >> doc. Let's formalize this: do you think this should be made a > >> CCAMP WG document? > >> > >> Summary: > >> > >> 1) Final comments and IESG Last Call readiness for: > >> draft-ietf-mpls-generalized-cr-ldp-04.txt > >> draft-ietf-mpls-generalized-rsvp-te-05.txt > >> draft-ietf-mpls-generalized-signaling-06.txt > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > >> > >> 2) Should the following documents be CCAMP WG docs? > >> draft-bonica-tunneltrace-02.txt > >> draft-fontana-ccamp-gmpls-g709-00.txt > >> draft-ietf-ccamp-gmpls-architecture-00.txt > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > >> draft-many-ccamp-gmpls-framework-00.txt > >> draft-many-oli-reqts-00.txt > >> > >> 3) Comment on MIB overview. > >> > >> 4) Two week Last Call comments on > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > >> > >> 5) Last Call readiness of > >> draft-ietf-ccamp-gmpls-architecture-00.txt > >> draft-ietf-ccamp-lmp-01.txt > >> > >> Thanks, > >> Kireeti. > >> > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > --------------49A55E47AED14BB4283B6C9A Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------49A55E47AED14BB4283B6C9A-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Oct 2001 04:37:33 -0700 Message-ID: <3BD160EA.9030502@lucent.com> Date: Sat, 20 Oct 2001 07:32:58 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: manoj juneja CC: kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Manoj, I agree with many of your points. I actually submitted an I-D several months ago (I think it's expired) that proposes some text to add to the GMPLS SONET/SDH on the rules for setting different values, such as for STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the range of acceptable value of X, etc. My rationale at that time was that not everyone is a SONET/SDH expert and instead of asking them to look somewhere else and dig through those documents to find the answer, if we can provide them in the GMPLS set of drafts it would be extremely useful for the entire IETF community and would help clarify the usage of these parameters. But unfortunately if you were at the meeting at the time, it wasn't accepted because some folks thought that these were obvious or that this info is not needed because they can find it in other places referenced... If you have the old drafts, the file was: draft-lin-ccamp-ipo-common-label-request-01 But anyway...people will just have to read all the referenced documents to understand how to use the different parameters... Zhi manoj juneja wrote: > Hi Kireeti, > I am not an active member of IETF but a regular reader of > GMPLS drafts. I am not sure how much weight my mail will carry but as a > regular reader of these drafts, I recommend the following points should > be made clear in the documents before proceeding to the last call. > > > 1. Can someone please tell me the usage of bandwidth encoding > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated > will be drived from the signal type field. How the bandwidth encoding > type will be interpreted in case of other LSP encoding types (lambda, > waveband, fiber etc) ? The draft should list down the cases in which the > bandwidth encoding type is to be filled. > > 2. Usage of Label Set : > There are cases mentioned in the draft which explains the usage > of label set. It should also mention that the range of labels in > SDH/SONET does not make sense. Ranges in label set are applicable in > case of waveband/lambda switching etc. The range in label set is valid > in SDH/SONET only if there is one element in the range i.e. start range > and end range should be same. > > 3. There are couple of scenarios where there can be contention for > establishing bi-directional LSPs. All the scenarios are not listed in > the document. If it is not possible to list all the scenarios then the > draft should say that this is one of the example scenario. The > contention can also be possible in case where same label set and > upstream label are used in both the directions. > > 4. As per OIF, the carrier requirement is that SDH LSPs should be > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS > has different set of carrier requirements in this regard ? > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as > an addendum to the draft. > > 6. The relation between switching capability and LSP encoding type > should be clearly explained in the drafts. As the switching capability > field was added very late (just 2 months back) in the drafts, > specific reason should be mentioned for its addition. > > Regards, > manoj. > > > >> From: Kireeti Kompella >> To: ccamp@ops.ietf.org >> Subject: Moving right along ... >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) >> >> Despite the energetic subject line, we the WG chairs have been >> lax in our duties. So, here goes: >> >> Lou has submitted the latest versions of the generalized >> signaling documents quite some time ago (thanks, Lou): >> >> draft-ietf-mpls-generalized-cr-ldp-04.txt >> draft-ietf-mpls-generalized-rsvp-te-05.txt >> draft-ietf-mpls-generalized-signaling-06.txt >> >> Also, Eric has posted the SONET/SDH documents (merci, Eric): >> >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt >> >> All of these should have addressed the issues raised in the earlier >> versions. Please read the new versions, and send your comments to >> the list by Tuesday Oct 23. At that point, when the final round >> of comments have been addressed, these docs will go to IESG Last >> Call. If any one objects to sending these docs to IESG Last Call, >> raise your issues now. >> >> I see that the GMPLS architecture document is a CCAMP WG doc, but >> the minutes say that we should look for consensus on the list. So, >> if you think this doc *shouldn't* be a WG doc, let us know. (If we >> arrived at a consensus, remind me :-)) If nothing is heard, the doc >> will progress to WG Last Call. >> >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be >> CCAMP WG docs; consensus at the meeting was Yes. Please let the >> list know what your thinking is on these. (BTW, both these docs >> were to have some edits done. If the authors could do that before >> the next IETF, we can try to make more progress then.) >> >> The MIB overview doc was recently posted. Please read and comment >> to the list. >> >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt >> was generally thought to be useful; it will be published as a >> CCAMP informational doc. This begins a two week Last Call on >> the doc, ending Tuesday Oct 30. >> >> There was no consensus on whether the GMPLS framework should be >> a CCAMP WG doc. Please indicate your pleasure. >> >> draft-ietf-ccamp-lmp-01.txt has been posted. The thought was >> raised that this draft is close to ready for WG Last Call. Please >> review it, and let us know if you disagree. >> >> The OLI requirements doc was broadly accepted. Please let the >> list know if you think this doc should be a WG doc. >> >> It's still open whether we (the IETF) should be working on >> LMP-WDM. I urge the authors to keep on working on the doc, and >> keeping it in sync with LMP; however, we will postpone making it >> a CCAMP WG doc until the issue is resolved. Hopefully that will >> happen in Salt Lake City. >> >> There was reasonable interest in the tunnel trace requirements >> doc. Let's formalize this: do you think this should be made a >> CCAMP WG document? >> >> Summary: >> >> 1) Final comments and IESG Last Call readiness for: >> draft-ietf-mpls-generalized-cr-ldp-04.txt >> draft-ietf-mpls-generalized-rsvp-te-05.txt >> draft-ietf-mpls-generalized-signaling-06.txt >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt >> >> 2) Should the following documents be CCAMP WG docs? >> draft-bonica-tunneltrace-02.txt >> draft-fontana-ccamp-gmpls-g709-00.txt >> draft-ietf-ccamp-gmpls-architecture-00.txt >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt >> draft-many-ccamp-gmpls-framework-00.txt >> draft-many-oli-reqts-00.txt >> >> 3) Comment on MIB overview. >> >> 4) Two week Last Call comments on >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt >> >> 5) Last Call readiness of >> draft-ietf-ccamp-gmpls-architecture-00.txt >> draft-ietf-ccamp-lmp-01.txt >> >> Thanks, >> Kireeti. >> > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 15:37:24 -0700 Message-ID: <3BD0AAAF.BE63739C@alcatel.be> Date: Sat, 20 Oct 2001 00:35:27 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Zhi-Wei Lin CC: Yanhe Fan , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------4D507C67C8AA36EDE4DFDCCC" This is a multi-part message in MIME format. --------------4D507C67C8AA36EDE4DFDCCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Just some months ago, you asked the same question but it was between AS's rather nodes. John Drake responded to your question at that time... (sorry i can't find it back otherwise i would have kindly refreshed your memory...). Thanks, Dimitri. Zhi-Wei Lin wrote: > > Hi Yanhe, > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It > is simply part of the network that made up the "dumb" pipe. And because > the control plane control channel is separate, A and C can be adjacent > without ever knowing who B is or that even B existed. From A and C's > point of view, the network looks like: > > A ----- C > > Think of the case of how a BGP sees an area. If an area is made up of: > > A -- B -- C > > and B is internal router, does BGP "see" B? > > Zhi > > Yanhe Fan wrote: > > > Hi, Zhi > > > > > >>For the label value for SONET/SDH or the label description in the > >>generic draft, the label is defined as directly representing the > >>"timeslot". Now if I have a control plane controlled transport network > >>that goes through a ADM that is not control plane controlled, as: > >> > >> > >>+--------+ +--------+ +--------+ > >>| | ---1--------- | | ----1-------- | | > >>| | ---2--------- | | ----2-------- | | > >>| A | ---3--------- | B | ----3-------- | C | > >>| | ---4--------- | | ----4-------- | | > >>| | ---5--------- | | ----5-------- | | > >>+--------+ +--------+ +--------+ > >> > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C > >>has labels 1,2,3,4,5 incoming. > >> > >>Now imagine that at B, it actually has a fixed cross-connect that > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >> > >>Now when A GMPLS sends a message to C, the label it uses is "1". > >>However, the connection/LSP associated with timeslot "1" is actually the > >>label of timeslot "2" at C. > >> > > > > In this case, you're trying to use GMPLS to setup an LSP cross a node (B) > > which can't understand GMPLS. > > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > > GMPLS if B can't understand GMPLS? > > > > Now imagine A and B are LSRs, and B is a conventional router (can't > > understand > > MPLS), can you setup an LSP A-B-C? > > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > > understand PNNI at all? > > > > My point is that in order to make you case work, some additional work need > > to > > be done besie simply using GMPLS as singnaling protocol, becase some node on > > the path is not GMPLS speakers. A and C needs the info of time slot aligment > > > > between them. This can be done by some configurations, some link management > > protocls (LMP maybe) etc. As long as A and C have this piece of info, > > eveything > > works fine. > > > > Yanhe > > --------------4D507C67C8AA36EDE4DFDCCC Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------4D507C67C8AA36EDE4DFDCCC-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 15:08:40 -0700 Message-ID: <3BD0A476.5010707@lucent.com> Date: Fri, 19 Oct 2001 18:08:54 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Dimitri Papadimitriou CC: John Drake , Maarten Vissers , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, Yes thank you. I wasn't saying implying that I want it now! I was just pointing out that this was something that I am working with Eric already to resolved (if you see my first email). Thanks for your help! I appreciate it! Zhi Dimitri Papadimitriou wrote: > All, > > Just to mention here that this request is under evaluation > we have never reject this proposal but only answer for some > time in order to check for consistency with the existing > content of the document. It is not because we are speaking > "optical" stuff that we can integrate content at the speed > of light ;-) > > It has been received when the document was just issued this > is why not included in the current version. I hope this > non-issue is closed. > > Thanks for your understanding and your patience, > Dimitri. > > Zhi-Wei Lin wrote: > >>Hi John, >> >>It wasn't that I wanted it without explanation. The explanation is that >>M0/M1 is carried transparently across the network without changes at any >>intermediate points. I thought it was obvious that under "transparent" >>attribute, specifying this is automatically assumed transparent unless >>there is some exception cases about them... >> >>Hope this explains. I wasn't trying to "ram" this down anyone's >>throat...BTW, you can just refer to me as "Zhi" :-) >> >>Zhi >> >>John Drake wrote: >> >> >>>Maarten, >>> >>>I'm sorry, my comment was more procedural than technical. If everyone >>>agrees that it is necessary, then obviously it should be added. Zhi-Wei >>>didn't try to gain consensus for adding it, he just said that he wanted it >>>with no explanation, as far as I could tell. >>> >>>Thanks, >>> >>>John >>> >>>-----Original Message----- >>>From: Maarten Vissers [mailto:mvissers@lucent.com] >>>Sent: Thursday, October 18, 2001 1:32 PM >>>To: John Drake >>>Cc: Zhi-Wei Lin; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... >>> >>> >>>John, >>> >>>Semi transparent STM-N signal transport is typically required to support the >>>following applications: >>> >>>* DCN application: D1-D3, D4-D12 >>>* MS protection application: J0, K1, K2, B2 >>>* Other: >>> [Orderwire] E1, E2, >>> [User Channel] F1, >>> [Single-ended MSn Performance Monitoring] M0, M1 (in addition to >>> J0, K2[6-8] and B2) >>> [RSn Performance Monitoring] B1 (in addition to J0) >>> >>>So M0/M1 transport is required in order to support single-ended MSn >>>performance >>>monitoring. >>> >>>Regards, >>> >>>Maarten >>> >>>John Drake wrote: >>> >>> >>>>-----Original Message----- >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >>>>Sent: Thursday, October 18, 2001 5:47 AM >>>>To: Kireeti Kompella >>>>Cc: ccamp@ops.ietf.org >>>>Subject: Re: Moving right along ... >>>> >>>>SNIPPED >>>> >>>> >>>> >>>>>As for the rest, let me juxtapose your comments on switching type >>>>>and M0/M1; I will say nothing, hoping that the juxtaposition will >>>>>speak for itself. >>>>> >>>>> >>>>> >>>>The switching type is in a "standard" document, while the M0/M1 is in >>>>the "non-standard" document. I will let that speak for itself as well. >>>>And by the way, when you made this comment are making it as a chair or >>>>as a contributor? >>>> >>>>JD: Actually, the signalling drafts are on exactly the same technical >>>>footing as the "non-standard" draft, >>>>so I think your attempt to draw a distinction between the two is specious >>>> >>>> >>>at >>> >>> >>>>best. Once again, a feature >>>>or capability is added if the community as a whole decides, through a >>>>process of rough consensus, that it >>>>should be added. No one other than you has indicated an issue with >>>>switching type and I haven't seen a groundswell >>>>of support for M0/M1. >>>> >>>> >>>> >>>>Zhi >>>> >>>> >>> >>> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 15:04:19 -0700 Message-ID: <3BD0A350.4010208@lucent.com> Date: Fri, 19 Oct 2001 18:04:00 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yangguang Xu CC: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Just to be clear, I am definitely one of the uninformed readers since I have joined IETF not so long ago (not everyone is part of IETF when it first started unfortunately). So Yakov, if you would be so kind as to inform an uninformed reader that would be very very much appreciated. Thanks in advance for your answers! Zhi Yangguang Xu wrote: > Indeed, you didn't answer my questions. Instead of informed readers, more > important is to have better informed writers. > > BTW, I have no intention to let you design my product at all. > > Yangguang > > Yakov Rekhter wrote: > >>Yangguang, >> >> >>>Yakov, >>> >>>Further questions in-line. Regards, >>> >>Further responses in-line... >> >> >>>Yangguang >>> >>> >>>>Couple of points: >>>> >>>>(1) First of all, you do run RSVP Hello between C and F. >>>> >>>Is this specified somewhere? Or it's your proposal. >>> >>What I mentioned in the above should be abundantly obvious to the >>informed reader of RSVP and LSP Hierarchy specs. >> >> >>>Then, is there a scalability issue here? >>> >>No. >> >> >>>Also, C and F could be thousands mile away (in the transport >>>network) and the control channel bandwidth is expensive. >>> >>GMPLS assumes that control channel is more than just 56Kbits/sec link. >> >>Or to put it differently, control channels used by GMPLS have more than >>enough capacity for RSVP Hellos. >> >> >>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should >>>>be able to recover the Interface ID it assigns to L1 from >>>>a combination of (a) the OSPF/ISIS link state database that >>>>F would recover, and (b) the Forward Interface ID (the one >>>>assigned by C). >>>> >>>Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it >>>has to recover its FA info first. How? >>> >>The answer should be abundantly obvious to the informed reader. >> >>And to make it crystal clear, I have no intention in designing your >>products for you. >> >> >>>>>Let us say the node can resynchronize its neighbor if >>>>>the neighbor restarts and requests state recovery. But >>>>>the issue is how a node can advertise that it does not >>>>>need recovery since all its state was preserved? >>>>> >>>>By treating is the same way as the way the spec handles >>>>control channel fault. >>>> >>>> >>>If a node can recover states from NVRAM or OS (this solution is >>>cheaper and have been implemented). It may not implement the spec. >>>How could a neighboring node, which implements the spec, not tear >>>down data connections mistakenly? Similar to a backward compatibility >>>problem, even not. >>> >>Stating the obvious: interoperability with a node that doesn't implement >>the spec is outside the scope of the spec. >> >> >>>>>RECOVERY LABEL does not come into picture unless the node >>>>>that is upstream to the restarting node has already received >>>>>a Resv. >>>>> >>>>Wrong. Quoting 9.5.3: >>>> >>>> Upon detecting a restart with a neighbor that supports state >>>> recovery, a node SHOULD refresh all Path state shared with that >>>> neighbor. >>>> >>>>So, as you can hopefully see from the above, the upstream node doesn't >>>>wait until it receives a Resv. >>>> >>>> >>>Then this may not meet carriers' requirement. (see IPO carriers' requirement) >>>Again, back to the telecom world (sorry about this, yet we are talking about >>>GMPLS), typically only the established pathes are preserved. Pending requests >>>may be purged/aborted. Then how? >>> >>Note the verb is "SHOULD", not "MUST". The rest should be >>obvious to the informed reader. >> >> >>>>>In case of PSC devices, it may be OK to remove state that >>>>>is not resynchronized at the end of the recovery period, >>>>>and the recovery period advertised might reflect that. >>>>>But for LSPs in transport networks, one might want to >>>>>have a different recovery period to avoid any LSP from >>>>>going down because of recovery timer expiry. >>>>> >>>>There is no requirement for a node to advertise exactly the >>>>same Restart_Cap on all the interfaces. So, on PSC interfaces >>>>the node could advertise that it will remove the state that >>>>isn't syncronized at the end of the recovery period, while >>>>on the TDM interface precisely the same node could advertise >>>>that the LSPs would be kept even after the recovery time expires. >>>> >>>> >>>So, restart_cap is per interface based? >>> >>yes. >> >> >>>Is the spec going to be enhanced/clarified? >>> >>The current spec need not be enhanced/clarified - what I mentioned in the >>above should be abundantly obvious to the informed reader. >> >> >>>>>The first problems seems to be there still - consider two >>>>>adjacent nodes restarting. They both act both as the restarting >>>>>node as well as the neighbor to the restarting node. So, once >>>>>they learn the state from the upstream neighbor, do they use >>>>>suggested label or the recovery label when they send the path >>>>>message to the just restarted downstream neighbor? >>>>> >>>>The recovery label. >>>> >>>>The following should be added to the existing text from the document: >>>> >>>> In the special case where a restarting node also has a restating >>>> downstream neighbor, a Recovery_Label object should be used instead >>>> of a Suggested_Label object. >>>> >>>How does a recovering NE know that its neighbor is also recovering? it may >>>lose the instance number totally >>> >>It's advertised in the neighbor's hellos. >> >>Yakov. >> > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 15:03:37 -0700 Message-ID: <3BD0A2AE.5080603@lucent.com> Date: Fri, 19 Oct 2001 18:01:18 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yanhe Fan CC: John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Yanhe, Maybe there is some misunderstanding. Node B is strictly not GMPLS. It is simply part of the network that made up the "dumb" pipe. And because the control plane control channel is separate, A and C can be adjacent without ever knowing who B is or that even B existed. From A and C's point of view, the network looks like: A ----- C Think of the case of how a BGP sees an area. If an area is made up of: A -- B -- C and B is internal router, does BGP "see" B? Zhi Yanhe Fan wrote: > Hi, Zhi > > >>For the label value for SONET/SDH or the label description in the >>generic draft, the label is defined as directly representing the >>"timeslot". Now if I have a control plane controlled transport network >>that goes through a ADM that is not control plane controlled, as: >> >> >>+--------+ +--------+ +--------+ >>| | ---1--------- | | ----1-------- | | >>| | ---2--------- | | ----2-------- | | >>| A | ---3--------- | B | ----3-------- | C | >>| | ---4--------- | | ----4-------- | | >>| | ---5--------- | | ----5-------- | | >>+--------+ +--------+ +--------+ >> >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >>has labels 1,2,3,4,5 incoming. >> >>Now imagine that at B, it actually has a fixed cross-connect that >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. >> >>Now when A GMPLS sends a message to C, the label it uses is "1". >>However, the connection/LSP associated with timeslot "1" is actually the >>label of timeslot "2" at C. >> > > In this case, you're trying to use GMPLS to setup an LSP cross a node (B) > which can't understand GMPLS. > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using > GMPLS if B can't understand GMPLS? > > Now imagine A and B are LSRs, and B is a conventional router (can't > understand > MPLS), can you setup an LSP A-B-C? > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't > understand PNNI at all? > > My point is that in order to make you case work, some additional work need > to > be done besie simply using GMPLS as singnaling protocol, becase some node on > the path is not GMPLS speakers. A and C needs the info of time slot aligment > > between them. This can be done by some configurations, some link management > protocls (LMP maybe) etc. As long as A and C have this piece of info, > eveything > works fine. > > Yanhe > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 13:04:26 -0700 Message-ID: From: Jonathan Lang To: "'Sameh M. Elsharkawy'" , ccamp@ops.ietf.org Cc: Jonathan Lang Subject: RE: LMP Question: fault management messages Date: Fri, 19 Oct 2001 12:58:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sameh, To address George's comment, we plan to modify the text as follows (new text in <>): Section 6.2 Fault Localization Procedure ... As part of the fault localization, a downstream node (downstream in terms of data flow) that detects data link failures will send a ChannelStatus message to its upstream neighbor <> (bundling together the notification of all of the failed data links). An upstream node that receives the ChannelStatus message MUST send a ChannelStatusAck message to the downstream node indicating it has received the ChannelStatus message. The upstream node should correlate the failure to see if the failure is also detected locally (including ingress side) for the corresponding LSP(s). If, for example, the failure is clear on the input of the upstream node or internally, then the upstream node will have localized the failure. <> Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures. Thanks, Jonathan > -----Original Message----- > From: Sameh M. Elsharkawy [mailto:selsharkawy@fwion.com] > Sent: Friday, October 19, 2001 12:46 PM > To: ccamp@ops.ietf.org > Subject: RE: LMP Question: fault management messages > > > > I fully agree with this comment since the removal of ChannelFailNack message > from the fault management procedure prevent downstream nodes from localizing > the failure on their input ports. If signaling is responsible for > propagating the information, this will delay the recovery process, until the > information is disseminated by signaling. > > Thanks > > Sameh M. Elsharkawy > Senior Member of Technical Staff > FirstWave Intelligent Optical Networks > 6301 Ivy Lane, Suite 700, Greenbelt, MD 20770 > (301) 345-2137 x1034 > > > > -----Original Message----- > From: George Young [mailto:george.young@edgeflow.com] > Sent: Tuesday, October 09, 2001 1:57 PM > To: ccamp@ops.ietf.org > Subject: LMP Question: fault management messages > > > I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus > message and its friends. > > In Section 6.2. Fault Localization Procedure, LMP states "Once the > failure has been localized, the signaling protocols can be used to > initiate span or path protection/restoration procedures". This is > workable and signalling can reroute around the link or the path, > releasing resources as appropriate. However, with the departure of the > ChannelFailNack, the node at the receive end of the faulty > link does not > find out about the fault from either the signalling protocol > or LMP. As > bidirectional paths are allocated, there is a chance that the failed > link will be allocated to a subsequent call through this node. > > Furthermore, assuming a signalling protocol has established paths, and > indicated their active or backup status with the Administrative Status > object in GMPLS, there does not appear to be any need in LMP for the > Active/Deactive indications in the CHANNEL_STATUS object. This > information has already been conveyed by the signalling > protocol during > path establishment. > > If my understanding is correct, ChannelFailNack functionality > is needed > and the Active and Deactive values of the CHANNEL_STATUS > object are not. > > Regards, > George R. Young > edgeflow Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 13:00:34 -0700 From: "manoj juneja" To: kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: Moving right along ... Date: Fri, 19 Oct 2001 12:57:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Kireeti, I am not an active member of IETF but a regular reader of GMPLS drafts. I am not sure how much weight my mail will carry but as a regular reader of these drafts, I recommend the following points should be made clear in the documents before proceeding to the last call. 1. Can someone please tell me the usage of bandwidth encoding parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated will be drived from the signal type field. How the bandwidth encoding type will be interpreted in case of other LSP encoding types (lambda, waveband, fiber etc) ? The draft should list down the cases in which the bandwidth encoding type is to be filled. 2. Usage of Label Set : There are cases mentioned in the draft which explains the usage of label set. It should also mention that the range of labels in SDH/SONET does not make sense. Ranges in label set are applicable in case of waveband/lambda switching etc. The range in label set is valid in SDH/SONET only if there is one element in the range i.e. start range and end range should be same. 3. There are couple of scenarios where there can be contention for establishing bi-directional LSPs. All the scenarios are not listed in the document. If it is not possible to list all the scenarios then the draft should say that this is one of the example scenario. The contention can also be possible in case where same label set and upstream label are used in both the directions. 4. As per OIF, the carrier requirement is that SDH LSPs should be either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS has different set of carrier requirements in this regard ? 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as an addendum to the draft. 6. The relation between switching capability and LSP encoding type should be clearly explained in the drafts. As the switching capability field was added very late (just 2 months back) in the drafts, specific reason should be mentioned for its addition. Regards, manoj. >From: Kireeti Kompella >To: ccamp@ops.ietf.org >Subject: Moving right along ... >Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) > >Despite the energetic subject line, we the WG chairs have been >lax in our duties. So, here goes: > >Lou has submitted the latest versions of the generalized >signaling documents quite some time ago (thanks, Lou): > >draft-ietf-mpls-generalized-cr-ldp-04.txt >draft-ietf-mpls-generalized-rsvp-te-05.txt >draft-ietf-mpls-generalized-signaling-06.txt > >Also, Eric has posted the SONET/SDH documents (merci, Eric): > >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt >draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > >All of these should have addressed the issues raised in the earlier >versions. Please read the new versions, and send your comments to >the list by Tuesday Oct 23. At that point, when the final round >of comments have been addressed, these docs will go to IESG Last >Call. If any one objects to sending these docs to IESG Last Call, >raise your issues now. > >I see that the GMPLS architecture document is a CCAMP WG doc, but >the minutes say that we should look for consensus on the list. So, >if you think this doc *shouldn't* be a WG doc, let us know. (If we >arrived at a consensus, remind me :-)) If nothing is heard, the doc >will progress to WG Last Call. > >The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and >draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be >CCAMP WG docs; consensus at the meeting was Yes. Please let the >list know what your thinking is on these. (BTW, both these docs >were to have some edits done. If the authors could do that before >the next IETF, we can try to make more progress then.) > >The MIB overview doc was recently posted. Please read and comment >to the list. > >The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt >was generally thought to be useful; it will be published as a >CCAMP informational doc. This begins a two week Last Call on >the doc, ending Tuesday Oct 30. > >There was no consensus on whether the GMPLS framework should be >a CCAMP WG doc. Please indicate your pleasure. > >draft-ietf-ccamp-lmp-01.txt has been posted. The thought was >raised that this draft is close to ready for WG Last Call. Please >review it, and let us know if you disagree. > >The OLI requirements doc was broadly accepted. Please let the >list know if you think this doc should be a WG doc. > >It's still open whether we (the IETF) should be working on >LMP-WDM. I urge the authors to keep on working on the doc, and >keeping it in sync with LMP; however, we will postpone making it >a CCAMP WG doc until the issue is resolved. Hopefully that will >happen in Salt Lake City. > >There was reasonable interest in the tunnel trace requirements >doc. Let's formalize this: do you think this should be made a >CCAMP WG document? > >Summary: > >1) Final comments and IESG Last Call readiness for: >draft-ietf-mpls-generalized-cr-ldp-04.txt >draft-ietf-mpls-generalized-rsvp-te-05.txt >draft-ietf-mpls-generalized-signaling-06.txt >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt >draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > >2) Should the following documents be CCAMP WG docs? >draft-bonica-tunneltrace-02.txt >draft-fontana-ccamp-gmpls-g709-00.txt >draft-ietf-ccamp-gmpls-architecture-00.txt >draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt >draft-many-ccamp-gmpls-framework-00.txt >draft-many-oli-reqts-00.txt > >3) Comment on MIB overview. > >4) Two week Last Call comments on >draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > >5) Last Call readiness of >draft-ietf-ccamp-gmpls-architecture-00.txt >draft-ietf-ccamp-lmp-01.txt > >Thanks, >Kireeti. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 12:49:53 -0700 Message-ID: From: "Sameh M. Elsharkawy" To: ccamp@ops.ietf.org Subject: RE: LMP Question: fault management messages Date: Fri, 19 Oct 2001 15:46:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I fully agree with this comment since the removal of ChannelFailNack message from the fault management procedure prevent downstream nodes from localizing the failure on their input ports. If signaling is responsible for propagating the information, this will delay the recovery process, until the information is disseminated by signaling. Thanks Sameh M. Elsharkawy Senior Member of Technical Staff FirstWave Intelligent Optical Networks 6301 Ivy Lane, Suite 700, Greenbelt, MD 20770 (301) 345-2137 x1034 -----Original Message----- From: George Young [mailto:george.young@edgeflow.com] Sent: Tuesday, October 09, 2001 1:57 PM To: ccamp@ops.ietf.org Subject: LMP Question: fault management messages I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus message and its friends. In Section 6.2. Fault Localization Procedure, LMP states "Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures". This is workable and signalling can reroute around the link or the path, releasing resources as appropriate. However, with the departure of the ChannelFailNack, the node at the receive end of the faulty link does not find out about the fault from either the signalling protocol or LMP. As bidirectional paths are allocated, there is a chance that the failed link will be allocated to a subsequent call through this node. Furthermore, assuming a signalling protocol has established paths, and indicated their active or backup status with the Administrative Status object in GMPLS, there does not appear to be any need in LMP for the Active/Deactive indications in the CHANNEL_STATUS object. This information has already been conveyed by the signalling protocol during path establishment. If my understanding is correct, ChannelFailNack functionality is needed and the Active and Deactive values of the CHANNEL_STATUS object are not. Regards, George R. Young edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 10:47:19 -0700 Message-ID: <3BD06689.7050309@acm.org> Date: Fri, 19 Oct 2001 13:44:41 -0400 From: Gopal Kailad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org, gkailad@acm.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yakov, Thanks for the clarification. My comments are inline: Yakov Rekhter wrote: >Gopal, > >>>>I have some questions/concerns on the restart mechanism as >>>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt. I >>>>have listed them below. >>>> >>>>If a node that is terminating hierarchical LSPs restarts, >>>>there is an ordering issue during resynchronization, since >>>>the LSPs would depend on other FA-LSPs the interface IDs for >>>>which would have been generated dynamically. So the >>>>mechanism as described will not work, unless this >>>>information is preserved across restarts - in which case we >>>>might as well preserve other information as well, and avoid >>>>resynchronization. >>>> >>>Since transit node of the FA-LSP does not see the RSVP >>>messages that use the FA, we only need to consider >>>the ingress and egress node. If the egress node restarts, >>>the worst case is that its upstream node sends an ERO >>>consisting a unrecognized interface address. Since the >>>Path message will carry RECOVERY_LABEL (replacing >>>SUGGESTED_LABEL), the egress node knows that it might >>>not have complete information yet, and can hold on to >>>the Path message until the FA-LSP is established. >>>All the information is there, so implementation >>>can be completely within the egress node. It does work, >>>just not specified enough. >>> >>>Ingress node will have to know the dependency, so not >>>a problem there. >>> >>Are you suggesting that in case of an ERO with an >>unrecognized interface id, if the Path message also >>carries a RECOVERY LABEL, the egress node can hold on >>to it until later? Note that there may not be a >>RECOVERY LABEL - since this Path message is for a >>hierarchical LSP, and the previous node may not be >>directly connected in the control plane. Here is an >>example - There is an LSP L1 from C to F, and on top of >>it there is an LSP L2 from A to G. >> >> L1: C --- D --- E --- F >> L2: A --- B --- C --------------- F --- G >> >>When F restarts, C may not even know, unless HELLO >>protocol is run between C and F. Note that the >>HELLO mechanism is intended for immediate neighbors. >> >>And even if the HELLO mechanism is extended, there >>is the issue of interface id assigned by F. F needs >>to assign the same interface id upon restart so as >>not to bring down the hierarchical LSPs set up on top >>of L1 in >>the reverse direction (say an LSP from G to >>B set up on top of L1.) Where would F get this >>information ? >> > >Couple of points: > >(1) First of all, you do run RSVP Hello between C and F. > O.K. > > >(2) Since L1 is advertised as an FA into OSPF/ISIS, F should >be able to recover the Interface ID it assigns to L1 from >a combination of (a) the OSPF/ISIS link state database that >F would recover, and (b) the Forward Interface ID (the one >assigned by C). > True. One could either use IGP restart mechanism to relearn this (I have other concerns on RSVP restart being dependent on IGP restart, but that for later) or preserve this across restarts. In either case, you agree that RSVP restart depends on some mechanism outside RSVP to help it along? So RSVP needs a new interface to get this mapping upon restarts, right? This is not clear in the draft. > > >>>>Also, let us consider a node that can preserve state across >>>>restarts, and hence does not need its state to be synced by >>>>its peer. How will it advertise this in the RESTART_CAP >>>>object? >>>> >>>We still need to resynchronize the state since the other >>>side might have connections that are in progress. The >>> >>Let us say the node can resynchronize its neighbor if >>the neighbor restarts and requests state recovery. But >>the issue is how a node can advertise that it does not >>need recovery since all its state was preserved? >> > >By treating is the same way as the way the spec handles >control channel fault. > True, but this does not help. See below. > > >>>reason for resynchronization is to make sure both side >>>have done the same to the in-progress connections, not >>>just to synchronize the established states. >>> >>>The value of the RESTART_CAP will set to non-zero values >>> >>RECOVERY LABEL does not come into picture unless the node >>that is upstream to the restarting node has already received >>a Resv. >> > >Wrong. Quoting 9.5.3: > > Upon detecting a restart with a neighbor that supports state > recovery, a node SHOULD refresh all Path state shared with that > neighbor. > >So, as you can hopefully see from the above, the upstream node doesn't >wait until it receives a Resv. > True - if you had read further, you would have noticed that I have said the same thing that you have quoted :) - but there will be no RECOVERY_LABEL unless a Resv has been received, right? It is possible that the downstream node, after programming its forwarding path, restarted before sending the Resv. This would result in the upstream node refreshing the Path message without the Recovery Label, and the downstream node eventually allocating a different label. So essentially it is a new LSP setup. > > >>So it seems that the procedure is to resynchronize >>established state? If Resv has not been received yet, there >>will be a refresh of Path message, and the restarting node >>will consider it as a new request, etc. So can you elaborate >>on "to make sure both side have done the same to the in >>progress connections" ? >> >>>>If a node supports PSC as well as TDM or LSC interfaces, it >>>>might want to advertise different set of parameters in the >>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM >>>>LSPs which form bearer channels in transport networks. >>>>Currently this is not possible. >>>> >>>Can you give us explicit examples as to why and what do >>>you gain by giving different values for PSC, TDM ? >>> >>In case of PSC devices, it may be OK to remove state that >>is not resynchronized at the end of the recovery period, >>and the recovery period advertised might reflect that. >>But for LSPs in transport networks, one might want to >>have a different recovery period to avoid any LSP from >>going down because of recovery timer expiry. >> > >There is no requirement for a node to advertise exactly the >same Restart_Cap on all the interfaces. So, on PSC interfaces >the node could advertise that it will remove the state that >isn't syncronized at the end of the recovery period, while >on the TDM interface precisely the same node could advertise >that the LSPs would be kept even after the recovery time expires. > But to set up LSPs over TDM/LSC interfaces, the PSC interface is going to be used for signaling - since control and data planes are decoupled! So, how will this help? > > >>>>According to 9.5.1. (procedures for restarting LSR): "When >>>>sending the corresponding outgoing Path message the node >>>>SHOULD include a SUGGESTED_LABEL object with a label value >>>>^^^^^^ >>>>matching the outgoing label from the now restored forwarding >>>>entry." >>>> >>>>This has a conflict with 9.5.2. Consider the case where >>>>adjacent nodes B and C restart, and B has another adjacent >>>>node A, and C has another adjacent node D. B and C will get >>>>resynced by A and D, and during this process, they will >>>>resync. each other. While resyncing each other, they act as >>>>neighbors of a restarting LSR, and hence according to 9.5.2, >>>>MUST include the SUGGESTED_LABEL. >>>> >>>>Also according to 9.5.2: "During the recovery period, new >>>>Path state being advertised to the restarted neighbor SHOULD >>>>not include the SUGGESTED_LABEL object in the corresponding >>>>outgoing Path message. This will prevent the restarting >>>>node >>>> from erroneously reusing a saved forwarding entry." >>>> >>>>I guess this would mean that if suggested labels are used >>>>during new LSP setup (as they are likely to be while >>>>provisioning lightpaths - to reduce latency), then new LSP >>>>setup will not be allowed during resyncing? >>>> >>>The use of RECOVERY_LABEL address all the above questions. >>> >>The first problems seems to be there still - consider two >>adjacent nodes restarting. They both act both as the restarting >>node as well as the neighbor to the restarting node. So, once >>they learn the state from the upstream neighbor, do they use >>suggested label or the recovery label when they send the path >>message to the just restarted downstream neighbor? >> > >The recovery label. > >The following should be added to the existing text from the document: > > In the special case where a restarting node also has a restating > downstream neighbor, a Recovery_Label object should be used instead > of a Suggested_Label object. > Since a restarting node may not be able to detect that a downstream neighbor is restarting, I suggest it always use a Recovery_Label object instead of a Suggested_Label object. Gopal > > >Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 08:42:19 -0700 Message-ID: <3BD049A4.79C885BD@lucent.com> Date: Fri, 19 Oct 2001 11:41:24 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Indeed, you didn't answer my questions. Instead of informed readers, more important is to have better informed writers. BTW, I have no intention to let you design my product at all. Yangguang Yakov Rekhter wrote: > > Yangguang, > > > Yakov, > > > > Further questions in-line. Regards, > > Further responses in-line... > > > Yangguang > > > > > Couple of points: > > > > > > (1) First of all, you do run RSVP Hello between C and F. > > > > Is this specified somewhere? Or it's your proposal. > > What I mentioned in the above should be abundantly obvious to the > informed reader of RSVP and LSP Hierarchy specs. > > > Then, is there a scalability issue here? > > No. > > > Also, C and F could be thousands mile away (in the transport > > network) and the control channel bandwidth is expensive. > > GMPLS assumes that control channel is more than just 56Kbits/sec link. > > Or to put it differently, control channels used by GMPLS have more than > enough capacity for RSVP Hellos. > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > > > be able to recover the Interface ID it assigns to L1 from > > > a combination of (a) the OSPF/ISIS link state database that > > > F would recover, and (b) the Forward Interface ID (the one > > > assigned by C). > > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it > > has to recover its FA info first. How? > > The answer should be abundantly obvious to the informed reader. > > And to make it crystal clear, I have no intention in designing your > products for you. > > > > > Let us say the node can resynchronize its neighbor if > > > > the neighbor restarts and requests state recovery. But > > > > the issue is how a node can advertise that it does not > > > > need recovery since all its state was preserved? > > > > > > By treating is the same way as the way the spec handles > > > control channel fault. > > > > > > > If a node can recover states from NVRAM or OS (this solution is > > cheaper and have been implemented). It may not implement the spec. > > How could a neighboring node, which implements the spec, not tear > > down data connections mistakenly? Similar to a backward compatibility > > problem, even not. > > Stating the obvious: interoperability with a node that doesn't implement > the spec is outside the scope of the spec. > > > > > RECOVERY LABEL does not come into picture unless the node > > > > that is upstream to the restarting node has already received > > > > a Resv. > > > > > > Wrong. Quoting 9.5.3: > > > > > > Upon detecting a restart with a neighbor that supports state > > > recovery, a node SHOULD refresh all Path state shared with that > > > neighbor. > > > > > > So, as you can hopefully see from the above, the upstream node doesn't > > > wait until it receives a Resv. > > > > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirement) > > Again, back to the telecom world (sorry about this, yet we are talking about > > GMPLS), typically only the established pathes are preserved. Pending requests > > may be purged/aborted. Then how? > > Note the verb is "SHOULD", not "MUST". The rest should be > obvious to the informed reader. > > > > > In case of PSC devices, it may be OK to remove state that > > > > is not resynchronized at the end of the recovery period, > > > > and the recovery period advertised might reflect that. > > > > But for LSPs in transport networks, one might want to > > > > have a different recovery period to avoid any LSP from > > > > going down because of recovery timer expiry. > > > > > > There is no requirement for a node to advertise exactly the > > > same Restart_Cap on all the interfaces. So, on PSC interfaces > > > the node could advertise that it will remove the state that > > > isn't syncronized at the end of the recovery period, while > > > on the TDM interface precisely the same node could advertise > > > that the LSPs would be kept even after the recovery time expires. > > > > > > > So, restart_cap is per interface based? > > yes. > > > Is the spec going to be enhanced/clarified? > > The current spec need not be enhanced/clarified - what I mentioned in the > above should be abundantly obvious to the informed reader. > > > > > The first problems seems to be there still - consider two > > > > adjacent nodes restarting. They both act both as the restarting > > > > node as well as the neighbor to the restarting node. So, once > > > > they learn the state from the upstream neighbor, do they use > > > > suggested label or the recovery label when they send the path > > > > message to the just restarted downstream neighbor? > > > > > > The recovery label. > > > > > > The following should be added to the existing text from the document: > > > > > > In the special case where a restarting node also has a restating > > > downstream neighbor, a Recovery_Label object should be used instead > > > of a Suggested_Label object. > > > > How does a recovering NE know that its neighbor is also recovering? it may > > lose the instance number totally > > It's advertised in the neighbor's hellos. > > Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 08:38:43 -0700 Message-Id: <200110191534.f9JFYm027028@merlot.juniper.net> To: Yangguang Xu cc: gkailad@acm.org, ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30622.1003505688.1@juniper.net> Date: Fri, 19 Oct 2001 08:34:48 -0700 From: Yakov Rekhter Yangguang, > Yakov, > > Further questions in-line. Regards, Further responses in-line... > Yangguang > > > Couple of points: > > > > (1) First of all, you do run RSVP Hello between C and F. > > Is this specified somewhere? Or it's your proposal. What I mentioned in the above should be abundantly obvious to the informed reader of RSVP and LSP Hierarchy specs. > Then, is there a scalability issue here? No. > Also, C and F could be thousands mile away (in the transport > network) and the control channel bandwidth is expensive. GMPLS assumes that control channel is more than just 56Kbits/sec link. Or to put it differently, control channels used by GMPLS have more than enough capacity for RSVP Hellos. > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > > be able to recover the Interface ID it assigns to L1 from > > a combination of (a) the OSPF/ISIS link state database that > > F would recover, and (b) the Forward Interface ID (the one > > assigned by C). > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it > has to recover its FA info first. How? The answer should be abundantly obvious to the informed reader. And to make it crystal clear, I have no intention in designing your products for you. > > > Let us say the node can resynchronize its neighbor if > > > the neighbor restarts and requests state recovery. But > > > the issue is how a node can advertise that it does not > > > need recovery since all its state was preserved? > > > > By treating is the same way as the way the spec handles > > control channel fault. > > > > If a node can recover states from NVRAM or OS (this solution is > cheaper and have been implemented). It may not implement the spec. > How could a neighboring node, which implements the spec, not tear > down data connections mistakenly? Similar to a backward compatibility > problem, even not. Stating the obvious: interoperability with a node that doesn't implement the spec is outside the scope of the spec. > > > RECOVERY LABEL does not come into picture unless the node > > > that is upstream to the restarting node has already received > > > a Resv. > > > > Wrong. Quoting 9.5.3: > > > > Upon detecting a restart with a neighbor that supports state > > recovery, a node SHOULD refresh all Path state shared with that > > neighbor. > > > > So, as you can hopefully see from the above, the upstream node doesn't > > wait until it receives a Resv. > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirement) > Again, back to the telecom world (sorry about this, yet we are talking about > GMPLS), typically only the established pathes are preserved. Pending requests > may be purged/aborted. Then how? Note the verb is "SHOULD", not "MUST". The rest should be obvious to the informed reader. > > > In case of PSC devices, it may be OK to remove state that > > > is not resynchronized at the end of the recovery period, > > > and the recovery period advertised might reflect that. > > > But for LSPs in transport networks, one might want to > > > have a different recovery period to avoid any LSP from > > > going down because of recovery timer expiry. > > > > There is no requirement for a node to advertise exactly the > > same Restart_Cap on all the interfaces. So, on PSC interfaces > > the node could advertise that it will remove the state that > > isn't syncronized at the end of the recovery period, while > > on the TDM interface precisely the same node could advertise > > that the LSPs would be kept even after the recovery time expires. > > > > So, restart_cap is per interface based? yes. > Is the spec going to be enhanced/clarified? The current spec need not be enhanced/clarified - what I mentioned in the above should be abundantly obvious to the informed reader. > > > The first problems seems to be there still - consider two > > > adjacent nodes restarting. They both act both as the restarting > > > node as well as the neighbor to the restarting node. So, once > > > they learn the state from the upstream neighbor, do they use > > > suggested label or the recovery label when they send the path > > > message to the just restarted downstream neighbor? > > > > The recovery label. > > > > The following should be added to the existing text from the document: > > > > In the special case where a restarting node also has a restating > > downstream neighbor, a Recovery_Label object should be used instead > > of a Suggested_Label object. > > How does a recovering NE know that its neighbor is also recovering? it may > lose the instance number totally It's advertised in the neighbor's hellos. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 08:16:07 -0700 Message-ID: From: Yanhe Fan To: "'Zhi-Wei Lin'" , John Drake Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Fri, 19 Oct 2001 11:14:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Zhi >For the label value for SONET/SDH or the label description in the >generic draft, the label is defined as directly representing the >"timeslot". Now if I have a control plane controlled transport network >that goes through a ADM that is not control plane controlled, as: > > >+--------+ +--------+ +--------+ >| | ---1--------- | | ----1-------- | | >| | ---2--------- | | ----2-------- | | >| A | ---3--------- | B | ----3-------- | C | >| | ---4--------- | | ----4-------- | | >| | ---5--------- | | ----5-------- | | >+--------+ +--------+ +--------+ > >Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at >A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C >has labels 1,2,3,4,5 incoming. > >Now imagine that at B, it actually has a fixed cross-connect that >connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to >C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. > >Now when A GMPLS sends a message to C, the label it uses is "1". >However, the connection/LSP associated with timeslot "1" is actually the >label of timeslot "2" at C. In this case, you're trying to use GMPLS to setup an LSP cross a node (B) which can't understand GMPLS. Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using GMPLS if B can't understand GMPLS? Now imagine A and B are LSRs, and B is a conventional router (can't understand MPLS), can you setup an LSP A-B-C? Now imagine A, B and C are ATM switches, can you setup a svc if B can't understand PNNI at all? My point is that in order to make you case work, some additional work need to be done besie simply using GMPLS as singnaling protocol, becase some node on the path is not GMPLS speakers. A and C needs the info of time slot aligment between them. This can be done by some configurations, some link management protocls (LMP maybe) etc. As long as A and C have this piece of info, eveything works fine. Yanhe Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 07:25:15 -0700 Message-ID: <3BD035BE.20F3F772@lucent.com> Date: Fri, 19 Oct 2001 10:16:30 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Yakov Rekhter CC: gkailad@acm.org, ccamp@ops.ietf.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yakov, Further questions in-line. Regards, Yangguang > > Couple of points: > > (1) First of all, you do run RSVP Hello between C and F. Is this specified somewhere? Or it's your proposal. Then, is there a scalability issue here? Also, C and F could be thousands mile away (in the transport network) and the control channel bandwidth is expensive. > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should > be able to recover the Interface ID it assigns to L1 from > a combination of (a) the OSPF/ISIS link state database that > F would recover, and (b) the Forward Interface ID (the one > assigned by C). Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it has to recover its FA info first. How? > > Let us say the node can resynchronize its neighbor if > > the neighbor restarts and requests state recovery. But > > the issue is how a node can advertise that it does not > > need recovery since all its state was preserved? > > By treating is the same way as the way the spec handles > control channel fault. > If a node can recover states from NVRAM or OS (this solution is cheaper and have been implemented). It may not implement the spec. How could a neighboring node, which implements the spec, not tear down data connections mistakenly? Similar to a backward compatibility problem, even not. > > > > RECOVERY LABEL does not come into picture unless the node > > that is upstream to the restarting node has already received > > a Resv. > > Wrong. Quoting 9.5.3: > > Upon detecting a restart with a neighbor that supports state > recovery, a node SHOULD refresh all Path state shared with that > neighbor. > > So, as you can hopefully see from the above, the upstream node doesn't > wait until it receives a Resv. > Then this may not meet carriers' requirement. (see IPO carriers' requirement) Again, back to the telecom world (sorry about this, yet we are talking about GMPLS), typically only the established pathes are preserved. Pending requests may be purged/aborted. Then how? > > In case of PSC devices, it may be OK to remove state that > > is not resynchronized at the end of the recovery period, > > and the recovery period advertised might reflect that. > > But for LSPs in transport networks, one might want to > > have a different recovery period to avoid any LSP from > > going down because of recovery timer expiry. > > There is no requirement for a node to advertise exactly the > same Restart_Cap on all the interfaces. So, on PSC interfaces > the node could advertise that it will remove the state that > isn't syncronized at the end of the recovery period, while > on the TDM interface precisely the same node could advertise > that the LSPs would be kept even after the recovery time expires. > So, restart_cap is per interface based? Is the spec going to be enhanced/clarified? > > The first problems seems to be there still - consider two > > adjacent nodes restarting. They both act both as the restarting > > node as well as the neighbor to the restarting node. So, once > > they learn the state from the upstream neighbor, do they use > > suggested label or the recovery label when they send the path > > message to the just restarted downstream neighbor? > > The recovery label. > > The following should be added to the existing text from the document: > > In the special case where a restarting node also has a restating > downstream neighbor, a Recovery_Label object should be used instead > of a Suggested_Label object. > How does a recovering NE know that its neighbor is also recovering? it may lose the instance number totally Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 05:00:11 -0700 Message-ID: <114DE1AABD7DD41189B600508BAF127104734C7B@nl0006exch005u.nl.lucent.com> From: "Mak, L (Leen)" To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Fri, 19 Oct 2001 13:58:04 +0200 MIME-Version: 1.0 Content-Type: text/plain Kireeti, > > Let's move the comment period to end Oct 30th. > Thanks a lot! Leen. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 02:34:44 -0700 Message-ID: <3BCFF346.321FF91F@alcatel.be> Date: Fri, 19 Oct 2001 11:32:54 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Zhi-Wei Lin CC: John Drake , Maarten Vissers , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------A1AA3999068C8D697212CD8E" This is a multi-part message in MIME format. --------------A1AA3999068C8D697212CD8E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Just to mention here that this request is under evaluation we have never reject this proposal but only answer for some time in order to check for consistency with the existing content of the document. It is not because we are speaking "optical" stuff that we can integrate content at the speed of light ;-) It has been received when the document was just issued this is why not included in the current version. I hope this non-issue is closed. Thanks for your understanding and your patience, Dimitri. Zhi-Wei Lin wrote: > > Hi John, > > It wasn't that I wanted it without explanation. The explanation is that > M0/M1 is carried transparently across the network without changes at any > intermediate points. I thought it was obvious that under "transparent" > attribute, specifying this is automatically assumed transparent unless > there is some exception cases about them... > > Hope this explains. I wasn't trying to "ram" this down anyone's > throat...BTW, you can just refer to me as "Zhi" :-) > > Zhi > > John Drake wrote: > > > Maarten, > > > > I'm sorry, my comment was more procedural than technical. If everyone > > agrees that it is necessary, then obviously it should be added. Zhi-Wei > > didn't try to gain consensus for adding it, he just said that he wanted it > > with no explanation, as far as I could tell. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Thursday, October 18, 2001 1:32 PM > > To: John Drake > > Cc: Zhi-Wei Lin; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... > > > > > > John, > > > > Semi transparent STM-N signal transport is typically required to support the > > following applications: > > > > * DCN application: D1-D3, D4-D12 > > * MS protection application: J0, K1, K2, B2 > > * Other: > > [Orderwire] E1, E2, > > [User Channel] F1, > > [Single-ended MSn Performance Monitoring] M0, M1 (in addition to > > J0, K2[6-8] and B2) > > [RSn Performance Monitoring] B1 (in addition to J0) > > > > So M0/M1 transport is required in order to support single-ended MSn > > performance > > monitoring. > > > > Regards, > > > > Maarten > > > > John Drake wrote: > > > >>-----Original Message----- > >>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > >>Sent: Thursday, October 18, 2001 5:47 AM > >>To: Kireeti Kompella > >>Cc: ccamp@ops.ietf.org > >>Subject: Re: Moving right along ... > >> > >>SNIPPED > >> > >> > >>>As for the rest, let me juxtapose your comments on switching type > >>>and M0/M1; I will say nothing, hoping that the juxtaposition will > >>>speak for itself. > >>> > >>> > >>The switching type is in a "standard" document, while the M0/M1 is in > >>the "non-standard" document. I will let that speak for itself as well. > >>And by the way, when you made this comment are making it as a chair or > >>as a contributor? > >> > >>JD: Actually, the signalling drafts are on exactly the same technical > >>footing as the "non-standard" draft, > >>so I think your attempt to draw a distinction between the two is specious > >> > > at > > > >>best. Once again, a feature > >>or capability is added if the community as a whole decides, through a > >>process of rough consensus, that it > >>should be added. No one other than you has indicated an issue with > >>switching type and I haven't seen a groundswell > >>of support for M0/M1. > >> > >> > >> > >>Zhi > >> --------------A1AA3999068C8D697212CD8E Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------A1AA3999068C8D697212CD8E-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Oct 2001 01:50:49 -0700 From: Mark.Jones@mail.sprint.com Date: Fri, 19 Oct 2001 03:47:57 -0500 Message-Id: Subject: RE: Moving right along ... MIME-Version: 1.0 TO: Eric.Mannie@ebone.com CC: ccamp@ops.ietf.org, dbrungard@att.com, Juergen.Heiles@icn.siemens.de, kireeti@juniper.net, mvissers@lucent.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 19 Oct 2001 03:47:55 -0500" Content-Transfer-Encoding: 7bit I agree with Deborah. It doesn't make any sense to me that the labels are different from the established standards. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com -----Original Message----- From: dbrungard [mailto:dbrungard@att.com] Sent: Thursday, October 18, 2001 5:57 PM To: mvissers; Eric.Mannie Cc: dbrungard; Juergen.Heiles; kireeti; ccamp Subject: RE: Moving right along ... Eric, I also have commented on this multiple times. My previous comments were that the labels are inaccurate (e.g. ITU SDH supports both SONET (AU-3 and AU-4) and ETSI SDH (AU-4)) and they introduce an unnecessary complexity as they are not aligned with the transport plane functionality. There already exists lots of mis-information on SDH/SONET interworking - let's not add to it for supporting GMPLS. For a carrier, this introduces unnecessary operational complexity. I have not seen any discussion of my comments. Can you please share with us your concerns as it is difficult to discuss technical issues if they are not identified. Deborah Brungard AT&T > -----Original Message----- > From: Maarten Vissers [SMTP:mvissers@lucent.com] > Sent: Thursday, October 18, 2001 4:42 PM > To: Mannie, Eric > Cc: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Eric, > > > At this very late stage, since this not bringing any new functionality, > and > > since the label structure is very stable since a long time, I would > prefer > > not to restart a long technical discussion to change and re-validate the > > draft. > > This label issue is brought up many months ago already and strongly > supported by > multiple people. So far it has been rejected by you, and thus not > included. The > label structure isn't stable as such since a long time... there was simply > a > rejection to properly adapt it. > > For me and other SDH/SONET folks it is of utmost importance to see SDH and > SONET > be treated similarly, as also reflected in the ITU-T and T1 specifications > for > these technologies. In my opinion the current text in the draft must be > adapted > as proposed by Juergen (and by me and others in the past as well). > > Regards, > > Maarten << File: Card for Maarten Vissers >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 16:06:52 -0700 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC6240FA670@OCCLUST02EVS1.ugd.att.com> From: "Brungard, Deborah A, ALCTA" To: "'Maarten Vissers'" , "Mannie, Eric" Cc: "'Heiles Juergen'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 18:57:06 -0400 MIME-Version: 1.0 Content-Type: text/plain Eric, I also have commented on this multiple times. My previous comments were that the labels are inaccurate (e.g. ITU SDH supports both SONET (AU-3 and AU-4) and ETSI SDH (AU-4)) and they introduce an unnecessary complexity as they are not aligned with the transport plane functionality. There already exists lots of mis-information on SDH/SONET interworking - let's not add to it for supporting GMPLS. For a carrier, this introduces unnecessary operational complexity. I have not seen any discussion of my comments. Can you please share with us your concerns as it is difficult to discuss technical issues if they are not identified. Deborah Brungard AT&T > -----Original Message----- > From: Maarten Vissers [SMTP:mvissers@lucent.com] > Sent: Thursday, October 18, 2001 4:42 PM > To: Mannie, Eric > Cc: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > Eric, > > > At this very late stage, since this not bringing any new functionality, > and > > since the label structure is very stable since a long time, I would > prefer > > not to restart a long technical discussion to change and re-validate the > > draft. > > This label issue is brought up many months ago already and strongly > supported by > multiple people. So far it has been rejected by you, and thus not > included. The > label structure isn't stable as such since a long time... there was simply > a > rejection to properly adapt it. > > For me and other SDH/SONET folks it is of utmost importance to see SDH and > SONET > be treated similarly, as also reflected in the ITU-T and T1 specifications > for > these technologies. In my opinion the current text in the draft must be > adapted > as proposed by Juergen (and by me and others in the past as well). > > Regards, > > Maarten << File: Card for Maarten Vissers >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 15:02:58 -0700 Message-Id: <200110182159.f9ILxT093766@merlot.juniper.net> To: gkailad@acm.org cc: ccamp@ops.ietf.org, fliaw@zaffire.com Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59389.1003442368.1@juniper.net> Date: Thu, 18 Oct 2001 14:59:29 -0700 From: Yakov Rekhter Gopal, > >>I have some questions/concerns on the restart mechanism as > >>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt. I > >>have listed them below. > >> > >>If a node that is terminating hierarchical LSPs restarts, > >>there is an ordering issue during resynchronization, since > >>the LSPs would depend on other FA-LSPs the interface IDs for > >>which would have been generated dynamically. So the > >>mechanism as described will not work, unless this > >>information is preserved across restarts - in which case we > >>might as well preserve other information as well, and avoid > >>resynchronization. > >> > > > >Since transit node of the FA-LSP does not see the RSVP > >messages that use the FA, we only need to consider > >the ingress and egress node. If the egress node restarts, > >the worst case is that its upstream node sends an ERO > >consisting a unrecognized interface address. Since the > >Path message will carry RECOVERY_LABEL (replacing > >SUGGESTED_LABEL), the egress node knows that it might > >not have complete information yet, and can hold on to > >the Path message until the FA-LSP is established. > >All the information is there, so implementation > >can be completely within the egress node. It does work, > >just not specified enough. > > > >Ingress node will have to know the dependency, so not > >a problem there. > > > Are you suggesting that in case of an ERO with an > unrecognized interface id, if the Path message also > carries a RECOVERY LABEL, the egress node can hold on > to it until later? Note that there may not be a > RECOVERY LABEL - since this Path message is for a > hierarchical LSP, and the previous node may not be > directly connected in the control plane. Here is an > example - There is an LSP L1 from C to F, and on top of > it there is an LSP L2 from A to G. > > L1: C --- D --- E --- F > L2: A --- B --- C --------------- F --- G > > When F restarts, C may not even know, unless HELLO > protocol is run between C and F. Note that the > HELLO mechanism is intended for immediate neighbors. > > And even if the HELLO mechanism is extended, there > is the issue of interface id assigned by F. F needs > to assign the same interface id upon restart so as > not to bring down the hierarchical LSPs set up on top > of L1 in the reverse direction (say an LSP from G to > B set up on top of L1.) Where would F get this > information ? Couple of points: (1) First of all, you do run RSVP Hello between C and F. (2) Since L1 is advertised as an FA into OSPF/ISIS, F should be able to recover the Interface ID it assigns to L1 from a combination of (a) the OSPF/ISIS link state database that F would recover, and (b) the Forward Interface ID (the one assigned by C). > >>Also, let us consider a node that can preserve state across > >>restarts, and hence does not need its state to be synced by > >>its peer. How will it advertise this in the RESTART_CAP > >>object? > >> > > > >We still need to resynchronize the state since the other > >side might have connections that are in progress. The > > > Let us say the node can resynchronize its neighbor if > the neighbor restarts and requests state recovery. But > the issue is how a node can advertise that it does not > need recovery since all its state was preserved? By treating is the same way as the way the spec handles control channel fault. > >reason for resynchronization is to make sure both side > >have done the same to the in-progress connections, not > >just to synchronize the established states. > > > >The value of the RESTART_CAP will set to non-zero values > > > > RECOVERY LABEL does not come into picture unless the node > that is upstream to the restarting node has already received > a Resv. Wrong. Quoting 9.5.3: Upon detecting a restart with a neighbor that supports state recovery, a node SHOULD refresh all Path state shared with that neighbor. So, as you can hopefully see from the above, the upstream node doesn't wait until it receives a Resv. > So it seems that the procedure is to resynchronize > established state? If Resv has not been received yet, there > will be a refresh of Path message, and the restarting node > will consider it as a new request, etc. So can you elaborate > on "to make sure both side have done the same to the in > progress connections" ? > > >>If a node supports PSC as well as TDM or LSC interfaces, it > >>might want to advertise different set of parameters in the > >>RESTART_CAP object for data LSPs as opposed to SONET/WDM > >>LSPs which form bearer channels in transport networks. > >>Currently this is not possible. > >> > > > >Can you give us explicit examples as to why and what do > >you gain by giving different values for PSC, TDM ? > > > In case of PSC devices, it may be OK to remove state that > is not resynchronized at the end of the recovery period, > and the recovery period advertised might reflect that. > But for LSPs in transport networks, one might want to > have a different recovery period to avoid any LSP from > going down because of recovery timer expiry. There is no requirement for a node to advertise exactly the same Restart_Cap on all the interfaces. So, on PSC interfaces the node could advertise that it will remove the state that isn't syncronized at the end of the recovery period, while on the TDM interface precisely the same node could advertise that the LSPs would be kept even after the recovery time expires. > >>According to 9.5.1. (procedures for restarting LSR): "When > >>sending the corresponding outgoing Path message the node > >>SHOULD include a SUGGESTED_LABEL object with a label value > >>^^^^^^ > >>matching the outgoing label from the now restored forwarding > >>entry." > >> > >>This has a conflict with 9.5.2. Consider the case where > >>adjacent nodes B and C restart, and B has another adjacent > >>node A, and C has another adjacent node D. B and C will get > >>resynced by A and D, and during this process, they will > >>resync. each other. While resyncing each other, they act as > >>neighbors of a restarting LSR, and hence according to 9.5.2, > >>MUST include the SUGGESTED_LABEL. > >> > >>Also according to 9.5.2: "During the recovery period, new > >>Path state being advertised to the restarted neighbor SHOULD > >>not include the SUGGESTED_LABEL object in the corresponding > >>outgoing Path message. This will prevent the restarting > >>node from erroneously reusing a saved forwarding entry." > >> > >>I guess this would mean that if suggested labels are used > >>during new LSP setup (as they are likely to be while > >>provisioning lightpaths - to reduce latency), then new LSP > >>setup will not be allowed during resyncing? > >> > > > >The use of RECOVERY_LABEL address all the above questions. > > > The first problems seems to be there still - consider two > adjacent nodes restarting. They both act both as the restarting > node as well as the neighbor to the restarting node. So, once > they learn the state from the upstream neighbor, do they use > suggested label or the recovery label when they send the path > message to the just restarted downstream neighbor? The recovery label. The following should be added to the existing text from the document: In the special case where a restarting node also has a restating downstream neighbor, a Recovery_Label object should be used instead of a Suggested_Label object. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 14:56:54 -0700 Message-ID: <3BCF4F83.AB42AD1B@juniper.net> Date: Thu, 18 Oct 2001 14:54:11 -0700 From: Ping Pan MIME-Version: 1.0 To: Zhi-Wei Lin CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi-Wei Lin wrote: > > From what I recall, one of the cases that I was having difficulty > seeing was how a source LSR control plane failed, how the states were > recovered. Since in this case, the Path message defined for restart cap > is only going downstream and not upstream to recover the upstream > (source) node. > At headend, it's more like a number of routes maps to each LSP to forward traffic. After a headend restart, the downstream nodes will feed the allocated labels to the headend router. Now depending on your implementation, the route-label mapping could be recovered. However, graceful restart is used to recover GMPLS operation only, but is not a magic pill to recover other functions in the network, such as route recovery, config recovery.... IMHO, this applied to all nodes in the network. I would like to see different tools used to recover different things on every node. I don't see why GMPLS graceful restart does not work. - Ping Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 14:30:24 -0700 Message-ID: <3BCF49F0.5020701@lucent.com> Date: Thu, 18 Oct 2001 17:30:24 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: Maarten Vissers , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, It wasn't that I wanted it without explanation. The explanation is that M0/M1 is carried transparently across the network without changes at any intermediate points. I thought it was obvious that under "transparent" attribute, specifying this is automatically assumed transparent unless there is some exception cases about them... Hope this explains. I wasn't trying to "ram" this down anyone's throat...BTW, you can just refer to me as "Zhi" :-) Zhi John Drake wrote: > Maarten, > > I'm sorry, my comment was more procedural than technical. If everyone > agrees that it is necessary, then obviously it should be added. Zhi-Wei > didn't try to gain consensus for adding it, he just said that he wanted it > with no explanation, as far as I could tell. > > Thanks, > > John > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Thursday, October 18, 2001 1:32 PM > To: John Drake > Cc: Zhi-Wei Lin; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > > John, > > Semi transparent STM-N signal transport is typically required to support the > following applications: > > * DCN application: D1-D3, D4-D12 > * MS protection application: J0, K1, K2, B2 > * Other: > [Orderwire] E1, E2, > [User Channel] F1, > [Single-ended MSn Performance Monitoring] M0, M1 (in addition to > J0, K2[6-8] and B2) > [RSn Performance Monitoring] B1 (in addition to J0) > > So M0/M1 transport is required in order to support single-ended MSn > performance > monitoring. > > Regards, > > Maarten > > John Drake wrote: > >>-----Original Message----- >>From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >>Sent: Thursday, October 18, 2001 5:47 AM >>To: Kireeti Kompella >>Cc: ccamp@ops.ietf.org >>Subject: Re: Moving right along ... >> >>SNIPPED >> >> >>>As for the rest, let me juxtapose your comments on switching type >>>and M0/M1; I will say nothing, hoping that the juxtaposition will >>>speak for itself. >>> >>> >>The switching type is in a "standard" document, while the M0/M1 is in >>the "non-standard" document. I will let that speak for itself as well. >>And by the way, when you made this comment are making it as a chair or >>as a contributor? >> >>JD: Actually, the signalling drafts are on exactly the same technical >>footing as the "non-standard" draft, >>so I think your attempt to draw a distinction between the two is specious >> > at > >>best. Once again, a feature >>or capability is added if the community as a whole decides, through a >>process of rough consensus, that it >>should be added. No one other than you has indicated an issue with >>switching type and I haven't seen a groundswell >>of support for M0/M1. >> >> >> >>Zhi >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 14:23:44 -0700 Message-ID: <3BCF4855.9070007@lucent.com> Date: Thu, 18 Oct 2001 17:23:33 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Maarten Vissers CC: "Mannie, Eric" , "'Heiles Juergen'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit At the risk of sounding like a "me-too" person, me-too agree with Maarten. :-) Zhi Maarten Vissers wrote: > Eric, > > >>At this very late stage, since this not bringing any new functionality, and >>since the label structure is very stable since a long time, I would prefer >>not to restart a long technical discussion to change and re-validate the >>draft. >> > > This label issue is brought up many months ago already and strongly supported by > multiple people. So far it has been rejected by you, and thus not included. The > label structure isn't stable as such since a long time... there was simply a > rejection to properly adapt it. > > For me and other SDH/SONET folks it is of utmost importance to see SDH and SONET > be treated similarly, as also reflected in the ITU-T and T1 specifications for > these technologies. In my opinion the current text in the draft must be adapted > as proposed by Juergen (and by me and others in the past as well). > > Regards, > > Maarten > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 14:22:29 -0700 Message-ID: From: John Drake To: Maarten Vissers Cc: Zhi-Wei Lin , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 14:21:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Maarten, I'm sorry, my comment was more procedural than technical. If everyone agrees that it is necessary, then obviously it should be added. Zhi-Wei didn't try to gain consensus for adding it, he just said that he wanted it with no explanation, as far as I could tell. Thanks, John -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Thursday, October 18, 2001 1:32 PM To: John Drake Cc: Zhi-Wei Lin; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... John, Semi transparent STM-N signal transport is typically required to support the following applications: * DCN application: D1-D3, D4-D12 * MS protection application: J0, K1, K2, B2 * Other: [Orderwire] E1, E2, [User Channel] F1, [Single-ended MSn Performance Monitoring] M0, M1 (in addition to J0, K2[6-8] and B2) [RSn Performance Monitoring] B1 (in addition to J0) So M0/M1 transport is required in order to support single-ended MSn performance monitoring. Regards, Maarten John Drake wrote: > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, October 18, 2001 5:47 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > SNIPPED > > > As for the rest, let me juxtapose your comments on switching type > > and M0/M1; I will say nothing, hoping that the juxtaposition will > > speak for itself. > > > > The switching type is in a "standard" document, while the M0/M1 is in > the "non-standard" document. I will let that speak for itself as well. > And by the way, when you made this comment are making it as a chair or > as a contributor? > > JD: Actually, the signalling drafts are on exactly the same technical > footing as the "non-standard" draft, > so I think your attempt to draw a distinction between the two is specious at > best. Once again, a feature > or capability is added if the community as a whole decides, through a > process of rough consensus, that it > should be added. No one other than you has indicated an issue with > switching type and I haven't seen a groundswell > of support for M0/M1. > > > > Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 14:22:18 -0700 Message-ID: <3BCF47E6.2020008@lucent.com> Date: Thu, 18 Oct 2001 17:21:42 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, > JD: If a valid technical issue is raised, the authors of a draft attempt > to deal with it and their efforts are documented in a subsequent version > of the draft. If the proposed solution is inadequate or someone has a > better solution, then the proposed solution is either changed or fixed. > > I don't think an exhaustive public discussion of every possible solution > is particularly useful. And as has been pointed out, we're dealing with > rough consensus; this means that we don't necessarily need to get your > approval for everything that we do. > I guess I'm giving you the wrong impression again and making you mad at me again...I didn't mean that it needs my approval or any such things. I merely bring up a point that some items have not been resolved, and was not really decided upon by the CCAMP group. Of course my understanding was that there was some inadequacy, and the explanation I've been given did not get through my thick skull yet... > JD: And Fong answered the questions completely. > I thinkg Yangguang replied to this, so we can continue the discussion on that thread instead. :-) > JD: The authors add it and invite comments and criticism. I have made > several attempts to explain switching type to you, with no apparent success. > I haven't had this problem explaining it to anyone else. > Yes, and I thank you for explaining to me. It's just that what I heard seems to say that "this seems like a good thing for multi-service nodes" without really concrete reason how this makes the protocol better or what problem it is solving. Maybe I'm been too academic in protocol design cleanliness??? For example, even the LSP encoding type is really not necessary if you think about it, since the port or interface that you use has been discovered as a certain type of signal there. But of course that's not the issue here... > JD: The attempt was made to address Juergen's comments. It would be nice > for him, rather than you, to indicate whether they were adequately > addressed. Yes, you're right. I should only care about my own comments and only reply to my own comments and not use other people's words in my email. > As for you second point, we'd love to see valid technical issues and good > technical solutions from you or anyone else. As St Francis said, he would > accept wisdom regardless of the source. > Good quote from St. Francis. I'll have to follow that more often. :-) As for technical issues, I won't repeat other arguments as they've been given (I'll let the others speak directly rather than speak for them -- I'm taking your advice!) :-) But I do have one issue that actually Maarten and Juergen brought up (since they haven't mentioned it yet in public I will paraphrase them): For the label value for SONET/SDH or the label description in the generic draft, the label is defined as directly representing the "timeslot". Now if I have a control plane controlled transport network that goes through a ADM that is not control plane controlled, as: +--------+ +--------+ +--------+ | | ---1--------- | | ----1-------- | | | | ---2--------- | | ----2-------- | | | A | ---3--------- | B | ----3-------- | C | | | ---4--------- | | ----4-------- | | | | ---5--------- | | ----5-------- | | +--------+ +--------+ +--------+ Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C has labels 1,2,3,4,5 incoming. Now imagine that at B, it actually has a fixed cross-connect that connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1. Now when A GMPLS sends a message to C, the label it uses is "1". However, the connection/LSP associated with timeslot "1" is actually the label of timeslot "2" at C. Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 13:59:14 -0700 Message-ID: <3BCF42B2.7030404@lucent.com> Date: Thu, 18 Oct 2001 16:59:30 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: John Drake CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, I didn't know that. I thought the "non-standard" draft was going to route of informational RFC and the "standard" draft was targeted for the regular process... As for M0/M1, I thought the decision for this transparency was to be able to support different available products (wasn't that the original intention of things like arbitrary concat and stuff??). And from what I (as an individual) understand, there are vendors doing this... You may know of other vendors that may not do this, and as I remember, those that don't use it simply don't set it or ignore it... Maybe I still don't understand the process (as I mentioned in another mail, I'm pretty slow). Zhi John Drake wrote: > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, October 18, 2001 5:47 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > SNIPPED > > > >>As for the rest, let me juxtapose your comments on switching type >>and M0/M1; I will say nothing, hoping that the juxtaposition will >>speak for itself. >> >> > > > The switching type is in a "standard" document, while the M0/M1 is in > the "non-standard" document. I will let that speak for itself as well. > And by the way, when you made this comment are making it as a chair or > as a contributor? > > > JD: Actually, the signalling drafts are on exactly the same technical > footing as the "non-standard" draft, > so I think your attempt to draw a distinction between the two is specious at > best. Once again, a feature > or capability is added if the community as a whole decides, through a > process of rough consensus, that it > should be added. No one other than you has indicated an issue with > switching type and I haven't seen a groundswell > of support for M0/M1. > > > > > > > Zhi > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 13:57:24 -0700 Message-ID: <3BCF41F0.6010006@lucent.com> Date: Thu, 18 Oct 2001 16:56:16 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Ping Pan CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ping, Maybe I misinterpreted or I am just dumb. In that case, I hope that you have some patience with me... From what I recall, one of the cases that I was having difficulty seeing was how a source LSR control plane failed, how the states were recovered. Since in this case, the Path message defined for restart cap is only going downstream and not upstream to recover the upstream (source) node. As I recall, when you asked what information is not resoverable, I mentioned information in the Session Attribute object which included information about routing constraints (such as the exclude/include list, holding priority and flag). I also mentioned that the restart cap did not handle some info in the Generalized_UNI object. Yes I know that that is strictly for OIF to deal with, but still if OIF is re-using and the authors are essentially working in both fora we should be able to look at it and not push to other groups. As you said, maybe you've provided me with enough info and I'm just not seeing the "big picture". If you could be so kind as to show me the way and be patient with me. I am slow... Thanks Zhi Ping Pan wrote: > Zhi-Wei, > > Zhi-Wei Lin wrote: > >> >>I apologize because I can't look back at all the emails (I'm at the >>ITU meeting and is connecting over a phone line). I will give you more >>details on this when I get back. >> >>Essentially I've had email exchanges with Ping Pan on this issue for a >>while and asked some questions that has still not been answered. I will >>dig those out and forward to this group probably the week of Oct. 29. >> > > Sigh ... unbelievable! > > If I recall, you had sent me some emails on how graceful restart works > several weeks ago. I had replied all but one, where you were asking > about how Session Attribute object would work here. I thought it was > best to read the RSVP-TE draft more carefully. > > I also recalled that I had told you enough without telling you exactly > how I was about to implement graceful restart. :-( Yes, there may have > some corner cases on restarting at ingress *depending* on how your > router works. However, I felt that the draft was generic enough to cover > all the cases. All the issues that you had asked had been worked out by > the authors, including the ones for OIF UNI.... > > So if you feel that it's broken, let all of us know. There is no point > of sending many private emails and expecting others to reply everyone of > them. If short of a reply, you start to put people's name all over the > place. > > - Ping > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 13:42:42 -0700 Cc: "'Heiles Juergen'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Message-ID: <3BCF3E97.D6048046@lucent.com> Date: Thu, 18 Oct 2001 22:41:59 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: "'Heiles Juergen'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------810C1A528C7BE82C2F1692F1" This is a multi-part message in MIME format. --------------810C1A528C7BE82C2F1692F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, > At this very late stage, since this not bringing any new functionality, and > since the label structure is very stable since a long time, I would prefer > not to restart a long technical discussion to change and re-validate the > draft. This label issue is brought up many months ago already and strongly supported by multiple people. So far it has been rejected by you, and thus not included. The label structure isn't stable as such since a long time... there was simply a rejection to properly adapt it. For me and other SDH/SONET folks it is of utmost importance to see SDH and SONET be treated similarly, as also reflected in the ITU-T and T1 specifications for these technologies. In my opinion the current text in the draft must be adapted as proposed by Juergen (and by me and others in the past as well). Regards, Maarten --------------810C1A528C7BE82C2F1692F1 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------810C1A528C7BE82C2F1692F1-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 13:37:50 -0700 Cc: Zhi-Wei Lin , Kireeti Kompella , ccamp@ops.ietf.org Message-ID: <3BCF3C54.E148C1D5@lucent.com> Date: Thu, 18 Oct 2001 22:32:20 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake Original-CC: Zhi-Wei Lin , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------96D22359B20548C75F52B1CA" This is a multi-part message in MIME format. --------------96D22359B20548C75F52B1CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, Semi transparent STM-N signal transport is typically required to support the following applications: * DCN application: D1-D3, D4-D12 * MS protection application: J0, K1, K2, B2 * Other: [Orderwire] E1, E2, [User Channel] F1, [Single-ended MSn Performance Monitoring] M0, M1 (in addition to J0, K2[6-8] and B2) [RSn Performance Monitoring] B1 (in addition to J0) So M0/M1 transport is required in order to support single-ended MSn performance monitoring. Regards, Maarten John Drake wrote: > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, October 18, 2001 5:47 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > SNIPPED > > > As for the rest, let me juxtapose your comments on switching type > > and M0/M1; I will say nothing, hoping that the juxtaposition will > > speak for itself. > > > > The switching type is in a "standard" document, while the M0/M1 is in > the "non-standard" document. I will let that speak for itself as well. > And by the way, when you made this comment are making it as a chair or > as a contributor? > > JD: Actually, the signalling drafts are on exactly the same technical > footing as the "non-standard" draft, > so I think your attempt to draw a distinction between the two is specious at > best. Once again, a feature > or capability is added if the community as a whole decides, through a > process of rough consensus, that it > should be added. No one other than you has indicated an issue with > switching type and I haven't seen a groundswell > of support for M0/M1. > > > > Zhi --------------96D22359B20548C75F52B1CA Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------96D22359B20548C75F52B1CA-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:58:46 -0700 Message-ID: From: "Mannie, Eric" To: 'Heiles Juergen' , 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 18:57:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Juergen, Your comments are addressed hereafter. Note that you didn't raised any technical problem or mistake in your comments (i.e. the draft "works" very well as it is). - the first comment is not about a technical issue but an "editorial" issue. - the second comment is about a change that will not bring any new capability. >Concerning the SDH/Sonet documents I want to raise a formal issue. >We have now two documents, a document that covers ITU/ANSI standard features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that covers non-standard features (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in Appendix 1 of the standard feature document a non standard feature (Group signals) is listed. It is even mentioned that the use of groups (AUG, STSG, ...) is not described in standards. So this feature should be moved to the non-standards document. Otherwise the split of the documents doesn't make sense. We spend a considerable amount of time speaking about this particular issue and I still don't see any technical justification for what you said. For those who are not SDH/SONET experts some quick explanation: We call a "super-circuit" a set of physical circuits in the transport plane all belonging to the same LSP in the signaling plane. We defined two kinds of super-circuits: "group circuits" and "multiplicative circuits". Multiplicative circuits are setup using the multiplier field that we defined (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no objection about these ones. Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG, TUG, VTG (we defined the equivalent signal type in the signaling). The comment of Juergen is about these group circuits. A group circuit represents some bandwidth at a given place in the SDH/SONET multiplex. The advantage of such a super-circuit is that the customer can re-structure its content as he/she likes. The operator doesn't care. Such an application is possible and is already implemented. SDH/SONET is self-describing, i.e. by looking at the signal one can understand how it is structured (like Juergen explained on the mailing list), so one can setup a circuit without describing the content (very very cool). The transport plane ignores that the signaling plane uses an "abstraction" (i.e. an LSP) representing several physical circuits. Note that restoration and management belong respectively to the signaling plane and to the management plane in the IETF view (not to the transport plane like in the ITU-T view). >From that point of view, group circuits are a GMPLS signaling plane feature and not a transport plane feature. We put the comment on the fact that this is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy. I could say clearly at the beginning of the draft that the signal types that we are defining in this document are not ITU-T signal types but GMPLS signal types (of course) whose have in some cases a direct relationship with the ITU-T signal types. Any objection ? >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I prefer to have the same coding for Sonet and SDH. That makes the implementation for Sonet and SDH simpler. Furthermore ITU and T1 have tried over the last years to align Sonet and SDH as much as possible. The definition of different labels for Sonet and SDH contradicts these activities. We discussed this one since a long time as well. Let me be clear: - labels are local to an interface (we all agree). - a link (interface) is operated at one point in the time as either SDH or SONET. - your proposal will require to re-evaluate many things. - and it took us a lot of time to fine-tune and to validate the current label structure. - we could have technical issues with your proposal that would impact more than this draft (Dimitri saw some of them, please see with him). - you never provided a complete analysis of your proposal. But more important: your proposal doesn't bring any additional functionality to the draft. At this very late stage, since this not bringing any new functionality, and since the label structure is very stable since a long time, I would prefer not to restart a long technical discussion to change and re-validate the draft. Kind regards, Eric > -----Ursprüngliche Nachricht----- > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > An: ccamp@ops.ietf.org > Betreff: Moving right along ... > > > Despite the energetic subject line, we the WG chairs have been > lax in our duties. So, here goes: > > Lou has submitted the latest versions of the generalized > signaling documents quite some time ago (thanks, Lou): > > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > All of these should have addressed the issues raised in the earlier > versions. Please read the new versions, and send your comments to > the list by Tuesday Oct 23. At that point, when the final round > of comments have been addressed, these docs will go to IESG Last > Call. If any one objects to sending these docs to IESG Last Call, > raise your issues now. > > I see that the GMPLS architecture document is a CCAMP WG doc, but > the minutes say that we should look for consensus on the list. So, > if you think this doc *shouldn't* be a WG doc, let us know. (If we > arrived at a consensus, remind me :-)) If nothing is heard, the doc > will progress to WG Last Call. > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > CCAMP WG docs; consensus at the meeting was Yes. Please let the > list know what your thinking is on these. (BTW, both these docs > were to have some edits done. If the authors could do that before > the next IETF, we can try to make more progress then.) > > The MIB overview doc was recently posted. Please read and comment > to the list. > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > was generally thought to be useful; it will be published as a > CCAMP informational doc. This begins a two week Last Call on > the doc, ending Tuesday Oct 30. > > There was no consensus on whether the GMPLS framework should be > a CCAMP WG doc. Please indicate your pleasure. > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > raised that this draft is close to ready for WG Last Call. Please > review it, and let us know if you disagree. > > The OLI requirements doc was broadly accepted. Please let the > list know if you think this doc should be a WG doc. > > It's still open whether we (the IETF) should be working on > LMP-WDM. I urge the authors to keep on working on the doc, and > keeping it in sync with LMP; however, we will postpone making it > a CCAMP WG doc until the issue is resolved. Hopefully that will > happen in Salt Lake City. > > There was reasonable interest in the tunnel trace requirements > doc. Let's formalize this: do you think this should be made a > CCAMP WG document? > > Summary: > > 1) Final comments and IESG Last Call readiness for: > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > 2) Should the following documents be CCAMP WG docs? > draft-bonica-tunneltrace-02.txt > draft-fontana-ccamp-gmpls-g709-00.txt > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > draft-many-ccamp-gmpls-framework-00.txt > draft-many-oli-reqts-00.txt > > 3) Comment on MIB overview. > > 4) Two week Last Call comments on > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > 5) Last Call readiness of > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-ietf-ccamp-lmp-01.txt > > Thanks, > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:54:26 -0700 Date: Thu, 18 Oct 2001 09:52:23 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110181652.JAA07444@kummer.juniper.net> To: pingpan@juniper.net, xuyg@lucent.com Subject: Re: Moving right along ... Cc: ccamp@ops.ietf.org, kireeti@juniper.net, zwlin@lucent.com > > Why not? > > Why why not? Okay, folks, let's step back, take a deep breath, and come back to this discussion when the blood rush is over. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:40:48 -0700 Date: Thu, 18 Oct 2001 09:39:23 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110181639.JAA07331@kummer.juniper.net> To: kireeti@juniper.net, sjtrowbridge@lucent.com Subject: Re: Moving right along ... Cc: ccamp@ops.ietf.org Hi Steve, > Yes, I have discussed this with the management team of ITU-T SG 15, and > we agree that these will be made available in our new public FTP area, That's super! Thanks for your efforts. > They do want to > wait for Friday 25 October so you can get the official word on our > decisions. No problem. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:13:13 -0700 Message-ID: <3BCEFF55.FB8C410D@juniper.net> Date: Thu, 18 Oct 2001 09:12:05 -0700 From: Ping Pan MIME-Version: 1.0 To: Debanjan Saha CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Debanjan Saha wrote: > > Ping Pan > >> > >> To me, what carriers want are (1) How to preserve data path when control > >> channel/entity fails? > > >Apply fast reroute. > > Why would you do fast reroute if your data channel is still up? > wrong reply for someone scans emails once in a long while and saw his name poping up. :-) > Debanjan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:11:56 -0700 Message-ID: <3BCEFF04.7D807B71@lucent.com> Date: Thu, 18 Oct 2001 10:10:44 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, Yes, I have discussed this with the management team of ITU-T SG 15, and we agree that these will be made available in our new public FTP area, with an email to you & ccamp to annouce their presence. They do want to wait for Friday 25 October so you can get the official word on our decisions. On the VBI work, as you say, the results are not so urgent. Regards, Steve Kireeti Kompella wrote: > > Hi Steve, > > > In addition to the time crunch, we have the issue that some comment may > > be derived from the status of related work in Study Group 15. This has > > been communicated before, but to summarize some results that are expected > > by 25 October: > > We expect consent on the following documents related to GMPLS: > > G.ason, now numbered G.8080/Y.1304 "Architecture for the Automatic Switched > > Optical Network" > > G.dcm, now numbered G.7713/Y.1704 "Distributed Connection Management" > > G.disc, now numbered G.7714/Y.1705 "Generalized Automatic Discovery" > > G.dcn, now numbered G.7712/Y.1703 "Architecture and Specification of > > Data Communications Network" > > That would be very useful. Would these be publicly available? > > > We expect also to be able to report progress relating to the VBI/New > > Equipment Partitioning work, related to OLI/LMP/NTIP work. > > > > While full harmonization of the ITU-T/IETF work may be out of reach > > for the first effort, people should at least have the opportunity to > > read the ITU-T documents and consider the impact. > > While this is also very useful (I've glanced at the documents, thanks > for the urls), as you point out, these relate to LMP-WDM, and that > document isn't under consideration even as a WG document until we > resolve whether the IETF or the ITU-T (or both or neither) should work > on it. Hopefully, we can get that resolved by the next IETF meeting. > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:08:38 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D0220404035CE815@mail1.tellium.com> From: Debanjan Saha To: 'Ping Pan' Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 12:08:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ping Pan >> >> To me, what carriers want are (1) How to preserve data path when control >> channel/entity fails? >Apply fast reroute. Why would you do fast reroute if your data channel is still up? Debanjan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 09:08:26 -0700 Message-ID: <3BCEFD68.583022A7@lucent.com> Date: Thu, 18 Oct 2001 12:03:52 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Ping Pan CC: Kireeti Kompella , zwlin@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > > To me, what carriers want are (1) How to preserve data path when control > > channel/entity fails? > > Apply fast reroute. > Doesn't work > > (2) How to resync/recover data path information after > > failure recovers? > > > > I still don't have good answers to (1), which is a hard requirement. I > > understand the solution may be a local decision. Yet, if local behavior may > > impact interworking, it's better be specified. For (2), I have a fundamental > > requirement question: does recover/resync from neighbor NE (what's being > > proposed by Ping Pan) acceptable to transport service providers? > > Why not? > Why why not? > > because this is > > not conventional done in transport network. > > > > How so? Feed us more. > See my previous emails. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 08:34:42 -0700 Message-ID: <3BCEF534.A6C470EB@juniper.net> Date: Thu, 18 Oct 2001 08:28:52 -0700 From: Ping Pan MIME-Version: 1.0 To: Yangguang Xu CC: Kireeti Kompella , zwlin@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yangguang Xu wrote: > > To me, what carriers want are (1) How to preserve data path when control > channel/entity fails? Apply fast reroute. > (2) How to resync/recover data path information after > failure recovers? > > I still don't have good answers to (1), which is a hard requirement. I > understand the solution may be a local decision. Yet, if local behavior may > impact interworking, it's better be specified. For (2), I have a fundamental > requirement question: does recover/resync from neighbor NE (what's being > proposed by Ping Pan) acceptable to transport service providers? Why not? > because this is > not conventional done in transport network. > How so? Feed us more. - Ping > Cheers, > > Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 08:18:03 -0700 Message-ID: <3BCEF1C5.FC439CBB@juniper.net> Date: Thu, 18 Oct 2001 08:14:13 -0700 From: Ping Pan MIME-Version: 1.0 To: Zhi-Wei Lin CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi-Wei, Zhi-Wei Lin wrote: > > > I apologize because I can't look back at all the emails (I'm at the > ITU meeting and is connecting over a phone line). I will give you more > details on this when I get back. > > Essentially I've had email exchanges with Ping Pan on this issue for a > while and asked some questions that has still not been answered. I will > dig those out and forward to this group probably the week of Oct. 29. > Sigh ... unbelievable! If I recall, you had sent me some emails on how graceful restart works several weeks ago. I had replied all but one, where you were asking about how Session Attribute object would work here. I thought it was best to read the RSVP-TE draft more carefully. I also recalled that I had told you enough without telling you exactly how I was about to implement graceful restart. :-( Yes, there may have some corner cases on restarting at ingress *depending* on how your router works. However, I felt that the draft was generic enough to cover all the cases. All the issues that you had asked had been worked out by the authors, including the ones for OIF UNI.... So if you feel that it's broken, let all of us know. There is no point of sending many private emails and expecting others to reply everyone of them. If short of a reply, you start to put people's name all over the place. - Ping Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 08:09:50 -0700 Message-ID: From: John Drake To: Yangguang Xu Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 08:05:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yes I did. I probably should have replied to it. -----Original Message----- From: Yangguang Xu [mailto:xuyg@lucent.com] Sent: Thursday, October 18, 2001 7:04 AM To: John Drake Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... > I think Yangguang mentioned some. If you look back at the email > archive, I think some folks from Netplane and others also made some > comments. And yes, these comments were made when the resync stuff was > first added. The comments were simply not addressed adequately (in my > opinion of course). > > JD: And Fong answered the questions completely. > Yea, probably in the scope of your knowledge. BTW, did you see Gopal's response to Fong's response. It was posted at MPLS WG. Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 07:53:16 -0700 Message-ID: From: John Drake To: Zhi-Wei Lin , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 07:49:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Thursday, October 18, 2001 5:47 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... SNIPPED > As for the rest, let me juxtapose your comments on switching type > and M0/M1; I will say nothing, hoping that the juxtaposition will > speak for itself. > The switching type is in a "standard" document, while the M0/M1 is in the "non-standard" document. I will let that speak for itself as well. And by the way, when you made this comment are making it as a chair or as a contributor? JD: Actually, the signalling drafts are on exactly the same technical footing as the "non-standard" draft, so I think your attempt to draw a distinction between the two is specious at best. Once again, a feature or capability is added if the community as a whole decides, through a process of rough consensus, that it should be added. No one other than you has indicated an issue with switching type and I haven't seen a groundswell of support for M0/M1. Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 07:05:29 -0700 Message-ID: <3BCEE13D.F5834673@lucent.com> Date: Thu, 18 Oct 2001 10:03:41 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: John Drake CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I think Yangguang mentioned some. If you look back at the email > archive, I think some folks from Netplane and others also made some > comments. And yes, these comments were made when the resync stuff was > first added. The comments were simply not addressed adequately (in my > opinion of course). > > JD: And Fong answered the questions completely. > Yea, probably in the scope of your knowledge. BTW, did you see Gopal's response to Fong's response. It was posted at MPLS WG. Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 06:56:33 -0700 Message-ID: From: John Drake To: Zhi-Wei Lin , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 06:52:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Thursday, October 18, 2001 12:31 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... SNIPPED Yes, I agree it is a strong statement. But I think it's warranted. Yes, it solves a problem, but there are many differnet solutions of which Yangguang mentioned one such. Who made these decisions to include? Is there a need to look at both these (and possibly other) methods first prior to including in a WG document? IETF is a public standards forum where discussions on what is chosen is done in public for everyone's benefit, and therefore this decision should be considered by everyone prior to adding anything... JD: If a valid technical issue is raised, the authors of a draft attempt to deal with it and their efforts are documented in a subsequent version of the draft. If the proposed solution is inadequate or someone has a better solution, then the proposed solution is either changed or fixed. I don't think an exhaustive public discussion of every possible solution is particularly useful. And as has been pointed out, we're dealing with rough consensus; this means that we don't necessarily need to get your approval for everything that we do. > > Is it correct to simply include content of individual drafts into > > a WG draft that is in last call without adequate data on whether it > > handles all the different cases? > > Clearly not. Are you suggesting that that was what was done? > > It is a judgment call to include significant new material into a > document in last call. In this instance, handling restart of the > control plane is of sufficient importance to warrant inclusion. > That said, this inclusion happened some time ago (late July); > your comment would have been more timely then. > > In any case, it would be more helpful if you pointed out > scenarios that are missing, and even better if you had concrete > suggestions to fix things. > I think Yangguang mentioned some. If you look back at the email archive, I think some folks from Netplane and others also made some comments. And yes, these comments were made when the resync stuff was first added. The comments were simply not addressed adequately (in my opinion of course). JD: And Fong answered the questions completely. Yes, I agree with "rough consensus" (in a way), but if things that are added are unclear or doesn't seem to address any requirements, and the private discussions are just that: a private discussion. I would think that the authors need to have these discussions in the open to get as much participation and "buy-in" as possible. For example, I've commented on the "switching type" as part of signaling for some time, and never really understand why this was added. Yes, there has been some explanations, but I don't think those are reasons for adding. It sounds like it is something that "seems" to be reasonable. If something can be added because it "seems" reasonable, then does that mean if I think there is something that "seems" reasonable, the authors would be compelled to add these or who makes the decision to add these? JD: The authors add it and invite comments and criticism. I have made several attempts to explain switching type to you, with no apparent success. I haven't had this problem explaining it to anyone else. Of course, Juergen has provided some examples of issues as well, so those still need to be resolved. And I believe they need to be resolved in the open public email list so that everyone understand the decisions. Let's open up the commenting and decision process to the "common folks" like myself! JD: The attempt was made to address Juergen's comments. It would be nice for him, rather than you, to indicate whether they were adequately addressed. As for you second point, we'd love to see valid technical issues and good technical solutions from you or anyone else. As St Francis said, he would accept wisdom regardless of the source. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 05:53:57 -0700 Message-ID: <3BCECF2F.508@lucent.com> Date: Thu, 18 Oct 2001 08:46:39 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Kireeti, > The docs that have a one week Last Call have been Last Called at least > twice previously. The process has to terminate at some point. Also, > the docs were posted some time ago. You don't have to wait for someone > to suggest that you comment -- please fire at will. > yes, of course. I've tried to work on some of the issues off-line with the authors prior to the last call process. But I figured since this is the last call, I need to send something to the mail list... > Alan Kullberg made a comment (and a valid one) on Sept 20. The > resync stuff was sent out July 24. Perhaps in your opinion, that > counts as "when the resync stuff was first added". > I apologize because I can't look back at all the emails (I'm at the ITU meeting and is connecting over a phone line). I will give you more details on this when I get back. Essentially I've had email exchanges with Ping Pan on this issue for a while and asked some questions that has still not been answered. I will dig those out and forward to this group probably the week of Oct. 29. > I don't know how to put this politely, so let me be blunt. Using > the fact that others had comments to put roadblocks in the process > is not kosher. If you said "Hey, there is an issue with ingress > LSRs", I buy that, and I too would like to see this fixed. I hate > to speak for Alan, but I believe he wants a fix, not to hold up > progress. > > I hate too to impute motives to you wrongly. It's very likely > that you got confused with the loooong discussion on NTIP resync. > However, this is a Last Call process; vague references to "the > comments were simply not addressed adequately" just do not cut it. > State crisply and definitely the issues you feel exist, and let's > resolve them if we can, or get rough consensus if we cannot, and > put this behind us. > I don't think my position was to put up roadblocks. What I am doing is trying to resolve issues that are still pending. If you equate the two, then that's your call. > As for the rest, let me juxtapose your comments on switching type > and M0/M1; I will say nothing, hoping that the juxtaposition will > speak for itself. > The switching type is in a "standard" document, while the M0/M1 is in the "non-standard" document. I will let that speak for itself as well. And by the way, when you made this comment are making it as a chair or as a contributor? Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 03:46:55 -0700 Date: Thu, 18 Oct 2001 03:45:43 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110181045.DAA05965@kummer.juniper.net> To: sjtrowbridge@lucent.com Subject: Re: Moving right along ... Cc: ccamp@ops.ietf.org Hi Steve, > In addition to the time crunch, we have the issue that some comment may > be derived from the status of related work in Study Group 15. This has > been communicated before, but to summarize some results that are expected > by 25 October: > We expect consent on the following documents related to GMPLS: > G.ason, now numbered G.8080/Y.1304 "Architecture for the Automatic Switched > Optical Network" > G.dcm, now numbered G.7713/Y.1704 "Distributed Connection Management" > G.disc, now numbered G.7714/Y.1705 "Generalized Automatic Discovery" > G.dcn, now numbered G.7712/Y.1703 "Architecture and Specification of > Data Communications Network" That would be very useful. Would these be publicly available? > We expect also to be able to report progress relating to the VBI/New > Equipment Partitioning work, related to OLI/LMP/NTIP work. > > While full harmonization of the ITU-T/IETF work may be out of reach > for the first effort, people should at least have the opportunity to > read the ITU-T documents and consider the impact. While this is also very useful (I've glanced at the documents, thanks for the urls), as you point out, these relate to LMP-WDM, and that document isn't under consideration even as a WG document until we resolve whether the IETF or the ITU-T (or both or neither) should work on it. Hopefully, we can get that resolved by the next IETF meeting. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 03:29:09 -0700 Date: Thu, 18 Oct 2001 03:28:05 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110181028.DAA05903@kummer.juniper.net> To: bwijnen@lucent.com, ccamp@ops.ietf.org, kireeti@juniper.net Subject: RE: Moving right along ... Hi Bert, > Since (as you claim above) the WG chairs have been a bit lax You're being kind -- there's little doubt that the chairs have been lax. > is a 1 week review peried not a bit aggressive? My recollection is that we had decided on a one week final Last Call. In any case, it is moot, since the SG 15 meeting is on, I think extending this to two weeks is justified. > It is named a "IETF Last Call"... but this is admin detail... Ah, thanks for the correction! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 03:05:31 -0700 Date: Thu, 18 Oct 2001 03:05:00 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110181005.DAA05813@kummer.juniper.net> To: kireeti@juniper.net, lmak@lucent.com Subject: RE: Moving right along ... Cc: ccamp@ops.ietf.org Hi Leen, > You might not have noticed that the week you allow for comment > falls exactly in the middle of the two week ITU-T SG15 meeting You're right, sorry. It would definitely be good to hear from the very folks who would be in that meeting. Let's move the comment period to end Oct 30th. Thanks for bringing this up, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 03:03:07 -0700 Date: Thu, 18 Oct 2001 02:59:30 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110180959.CAA05761@kummer.juniper.net> To: kireeti@juniper.net, zwlin@lucent.com Subject: Re: Moving right along ... Cc: ccamp@ops.ietf.org Hi Zhi, > Incidentally, what is the procedure for the length of time for last > call? The docs that have a one week Last Call have been Last Called at least twice previously. The process has to terminate at some point. Also, the docs were posted some time ago. You don't have to wait for someone to suggest that you comment -- please fire at will. > I think Yangguang mentioned some. If you look back at the email > archive, I think some folks from Netplane and others also made some > comments. And yes, these comments were made when the resync stuff was > first added. Alan Kullberg made a comment (and a valid one) on Sept 20. The resync stuff was sent out July 24. Perhaps in your opinion, that counts as "when the resync stuff was first added". > The comments were simply not addressed adequately (in my > opinion of course). I don't know how to put this politely, so let me be blunt. Using the fact that others had comments to put roadblocks in the process is not kosher. If you said "Hey, there is an issue with ingress LSRs", I buy that, and I too would like to see this fixed. I hate to speak for Alan, but I believe he wants a fix, not to hold up progress. I hate too to impute motives to you wrongly. It's very likely that you got confused with the loooong discussion on NTIP resync. However, this is a Last Call process; vague references to "the comments were simply not addressed adequately" just do not cut it. State crisply and definitely the issues you feel exist, and let's resolve them if we can, or get rough consensus if we cannot, and put this behind us. As for the rest, let me juxtapose your comments on switching type and M0/M1; I will say nothing, hoping that the juxtaposition will speak for itself. > For example, I've commented on the "switching type" as part of signaling > for some time, and never really understand why this was added. Yes, > there has been some explanations, but I don't think those are reasons > for adding. It sounds like it is something that "seems" to be > reasonable. If something can be added because it "seems" reasonable, > then does that mean if I think there is something that "seems" > reasonable, the authors would be compelled to add these or who makes the > decision to add these? > > flag 13: M0 > > flag 14: M1 ... > My understanding is if someone uses this, then it can be included. > Therefore the reason is that some company uses it. Hope this is reason > enough! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 01:53:35 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0DB87111@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 10:47:31 +0200 MIME-Version: 1.0 Content-Type: text/plain Kireeti writes > > Despite the energetic subject line, we the WG chairs have been > lax in our duties. So, here goes: > > Lou has submitted the latest versions of the generalized > signaling documents quite some time ago (thanks, Lou): > > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > All of these should have addressed the issues raised in the earlier > versions. Please read the new versions, and send your comments to > the list by Tuesday Oct 23. At that point, when the final round > Since (as you claim above) the WG chairs have been a bit lax in their duties... is a 1 week review peried not a bit aggressive? In fact I do like agressive schedules... but we should also be realistic and be sensitive to the fact that some people may have other (non-IETF) duties. I would suggest that if anyone requests for a normal 2 week review period that we should grant that, certainly if the requestor indeed intends to seriously review. > of comments have been addressed, these docs will go to IESG Last > Call. If any one objects to sending these docs to IESG Last Call, > raise your issues now. > It is named a "IETF Last Call"... but this is admin detail... Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 00:44:55 -0700 Message-ID: <3BCE8830.112798B6@lucent.com> Date: Thu, 18 Oct 2001 01:43:44 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mak, L (Leen)" CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Leen and Kireeti, In addition to the time crunch, we have the issue that some comment may be derived from the status of related work in Study Group 15. This has been communicated before, but to summarize some results that are expected by 25 October: We expect consent on the following documents related to GMPLS: G.ason, now numbered G.8080/Y.1304 "Architecture for the Automatic Switched Optical Network" G.dcm, now numbered G.7713/Y.1704 "Distributed Connection Management" G.disc, now numbered G.7714/Y.1705 "Generalized Automatic Discovery" G.dcn, now numbered G.7712/Y.1703 "Architecture and Specification of Data Communications Network" We expect also to be able to report progress relating to the VBI/New Equipment Partitioning work, related to OLI/LMP/NTIP work. While full harmonization of the ITU-T/IETF work may be out of reach for the first effort, people should at least have the opportunity to read the ITU-T documents and consider the impact. Regards, Steve Trowbridge Chair ITU-T WP3/15 "Mak, L (Leen)" wrote: > > Kireeti, > > You might not have noticed that the week you allow for comment > falls exactly in the middle of the two week ITU-T SG15 meeting > period. SG15 is the group where a.o. SDH and OTN are being > worked. > This implies that a lot of experts in these areas are fully occupied > in Geneva. Of course they are able to work at night and over the > weekend, however, a lot of them do already do that in editing > sessions etc. > > Wouldn't it be nice to give these people a break, and extend the > period for comment by another week, so until Oct. 30? > > Thanks for your consideration, > > Leen Mak. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 00:31:58 -0700 Message-ID: <3BCE8549.C8E492C8@lucent.com> Date: Thu, 18 Oct 2001 03:31:21 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kireeti, all, Kireeti Kompella wrote: > > Hi Zhi, > > > -- cr-ldp is in version 4, which means that the revisions done to > > rsvp-te05 has not been reflected there...how do we resolve this > > inconsistency? > > Would bumping the version number of the cr ldp draft work for you? :-) > > I see that Don has posted a new version -- thanks, Don. > :-) thanks. In that case, I assume that the -05 version is now that one going for IESG last call. Incidentally, what is the procedure for the length of time for last call? I hope you do realize that there are many people who are involved with this who are attending a SG 15 ITU meeting this and next week, and therefore do not have time. I would request that the last call deadline be extended to the end of the month, as many of the major individual players are currently tied down... > > -- rsvp-te-05 and signaling-06 has incorporated the restart capability > > as proposed by Ping Pan. However, that work was never looked at > > carefully and some issues remain on how this covers all the different > > cases. > > "that work was never looked at carefully" is a strong statement. > The work *was* looked at carefully, at least by some folks. There > may well be corner cases that have been missed; it would be an > excellent idea to point those out. > Yes, I agree it is a strong statement. But I think it's warranted. Yes, it solves a problem, but there are many differnet solutions of which Yangguang mentioned one such. Who made these decisions to include? Is there a need to look at both these (and possibly other) methods first prior to including in a WG document? IETF is a public standards forum where discussions on what is chosen is done in public for everyone's benefit, and therefore this decision should be considered by everyone prior to adding anything... > > Is it correct to simply include content of individual drafts into > > a WG draft that is in last call without adequate data on whether it > > handles all the different cases? > > Clearly not. Are you suggesting that that was what was done? > > It is a judgment call to include significant new material into a > document in last call. In this instance, handling restart of the > control plane is of sufficient importance to warrant inclusion. > That said, this inclusion happened some time ago (late July); > your comment would have been more timely then. > > In any case, it would be more helpful if you pointed out > scenarios that are missing, and even better if you had concrete > suggestions to fix things. > I think Yangguang mentioned some. If you look back at the email archive, I think some folks from Netplane and others also made some comments. And yes, these comments were made when the resync stuff was first added. The comments were simply not addressed adequately (in my opinion of course). > > -- signaling-06 also includes several new items in there that doesn't > > seem to be added because of a identified need (do a diff to find the > > differences). Why were they added to the document (I'm not questioning > > them, just asking for clarifying explanation)? > > Good question, but rather open-ended. Can you mention a few > specific items? At that point, Lou et al could mail the list > with answers. > As I said, that is easily seen by simply diff'ing the two versions. One is RR object. Again, I think I understand the reason for it, but this addition was never discussed in an open forum where everyone can make a decision. It would be useful (for my education) if I can hear what the reasons were for adding (why this is needed to support some requirements), and see if everyone agrees to this... > > -- in signaling-06, since we've decided that this set of I-Ds are to be > > consistent with the standards for the respective technologies, then > > "Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something > > that is used in G.709 or G.872 to describe the types of the signals... > > I like being consistent with G.709/872. Eric, Dimitri, others: > comments on terminology? > Thanks > > -- There are still some technical questions remaining on some content of > > the sonet-sdh-02 that are still been discussed in a private list (my > > understanding). Shouldn't these be resolved first before it goes for > > last call? > > Can you take them up with the authors? > > As a general comment, the operative phrase at the IETF is > "rough consensus". It would be ideal to have all comments > addressed, and all issues resolved, but there is a point at > which we have to declare that the remaining issues/comments > are not significant enough to halt progress. > Yes, I agree with "rough consensus" (in a way), but if things that are added are unclear or doesn't seem to address any requirements, and the private discussions are just that: a private discussion. I would think that the authors need to have these discussions in the open to get as much participation and "buy-in" as possible. For example, I've commented on the "switching type" as part of signaling for some time, and never really understand why this was added. Yes, there has been some explanations, but I don't think those are reasons for adding. It sounds like it is something that "seems" to be reasonable. If something can be added because it "seems" reasonable, then does that mean if I think there is something that "seems" reasonable, the authors would be compelled to add these or who makes the decision to add these? Of course, Juergen has provided some examples of issues as well, so those still need to be resolved. And I believe they need to be resolved in the open public email list so that everyone understand the decisions. Let's open up the commenting and decision process to the "common folks" like myself! > > -- in sonet-sdh-extension-00, we would like to add two new flags into > > the list of flags for transparency (I have spoken to Eric already, and > > I'm waiting to have these added in the next version): > > flag 13: M0 > > flag 14: M1 > > I don't believe that that should be an issue; however, can you offer > reasons for their inclusion, just so we know? > My understanding is if someone uses this, then it can be included. Therefore the reason is that some company uses it. Hope this is reason enough! > > -- I believe g709-00 is currently undergoing some changes to align with > > standards positions and to reflect the work on OTN TDM that is been > > discussed in ITU study group 15 meeting this week and next week. > > Excellent! > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Oct 2001 00:16:45 -0700 Message-ID: <114DE1AABD7DD41189B600508BAF1271047348A3@nl0006exch005u.nl.lucent.com> From: "Mak, L (Leen)" To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Thu, 18 Oct 2001 09:11:41 +0200 MIME-Version: 1.0 Content-Type: text/plain Kireeti, You might not have noticed that the week you allow for comment falls exactly in the middle of the two week ITU-T SG15 meeting period. SG15 is the group where a.o. SDH and OTN are being worked. This implies that a lot of experts in these areas are fully occupied in Geneva. Of course they are able to work at night and over the weekend, however, a lot of them do already do that in editing sessions etc. Wouldn't it be nice to give these people a break, and extend the period for comment by another week, so until Oct. 30? Thanks for your consideration, Leen Mak. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 15:01:54 -0700 Message-ID: <3BCDFF8D.CE2EF91@nayna.com> Date: Wed, 17 Oct 2001 15:00:45 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Yangguang Xu CC: Kireeti Kompella , ccamp@ops.ietf.org, zwlin@lucent.com Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yangguang: Yangguang Xu wrote: > Kireeti, > > > > > > I still don't have good answers to (1), which is a hard requirement. I > > > understand the solution may be a local decision. Yet, if local behavior may > > > impact interworking, it's better be specified. > > > > One could make a statement along the lines of: "please try to > > keep your data plane going if the control plane dies", if that > > helps. LMP talks about this ... > > > > I am talking about RSVP-TE. Both LMP and RSVP has work to do if a control plane dies. LMP on the neighbor related information and RSVP on connection related information. > > > > > For (2), I have a fundamental > > > requirement question: does recover/resync from neighbor NE (what's being > > > proposed by Ping Pan) acceptable to transport service providers? because this is > > > not conventional done in transport network. > > > > Is running GMPLS conventional in transport networks? :-) > > > > No, that's why GMPLS should learn some basic requirements first. > > > > What is the conventional behaviour in transport networks if the > > control plane goes down? How is recovery done? That would be > > a useful data point (for me, anyway). > > > > Retrieving from local NV storage or remote OS. > Retrieving from local storage will not satisfy global consistency. Synching with the remote OS is what is achieved by the additions made to RSVP. > > > As for the fundamental requirement, it is more like: do you > > want your data plane to keep going if the control plane crashes? > > Recovery/resync from neighbor is a mechanism, not a requirement. > > Of course, there is also the question whether such a mechanism > > is acceptable to carriers. > > > > It is a requirement. Here is the difference between transport network and IP > network. I agree with your point from the IP point of view. However, in > transport network, we are talking about more expensive and less dynamic pipes. > The data path information can be stored at multiple locations. Yet, there is > normally a single trusted point. So my question is a fundamental requirement > question. Is neighbor NE (may be a different vendor's NE) a trusted resource. > BTW, I happened to work for a carrier for several years. When I talking about > requirement, I used my previous experience and recent discussion with some other > carriers. > Paranoia should have restricted application :-) Here we are talking about existing connections in a single carrier domain. A carrier should trust all its NEs to do its job during path setup (and hence keeping its database up-to-date). All we are doing in the re-synch is querying the info in the database. For this reason, in my opinion, one should not vouch for a centralized approach. Cheers, sudheer > > Regards, > > Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 14:33:37 -0700 Message-ID: <3BCDF8ED.52A7C919@nayna.com> Date: Wed, 17 Oct 2001 14:32:29 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Yangguang Xu CC: Kireeti Kompella , zwlin@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Yangguang: Yangguang Xu wrote: > Kireeti, > > > > > > Is it correct to simply include content of individual drafts into > > > a WG draft that is in last call without adequate data on whether it > > > handles all the different cases? > > > > Clearly not. Are you suggesting that that was what was done? > > > > It is a judgment call to include significant new material into a > > document in last call. In this instance, handling restart of the > > control plane is of sufficient importance to warrant inclusion. > > That said, this inclusion happened some time ago (late July); > > your comment would have been more timely then. > > > > In any case, it would be more helpful if you pointed out > > scenarios that are missing, and even better if you had concrete > > suggestions to fix things. > > Besides some "corner" issues raised recently yet not answered or answered > publicly. I've some non-corner questions. > > To me, what carriers want are (1) How to preserve data path when control > channel/entity fails? (2) How to resync/recover data path information after > failure recovers? > Agreed on the requirements. > > I still don't have good answers to (1), which is a hard requirement. I > understand the solution may be a local decision. Yet, if local behavior may > impact interworking, it's better be specified. For (2), I have a fundamental > requirement question: does recover/resync from neighbor NE (what's being > proposed by Ping Pan) acceptable to transport service providers? because this is > not conventional done in transport network. > On (2) what other options do we have? With distributed control plane (GMPLS), the neighboring entities will preserve the information a failed NE needs. Yes this may be little scary if we donot trust our control plane... in that case we need to solve the scaring issues. - sudheer > > Cheers, > > Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 14:31:58 -0700 Message-ID: <3BCDF6C4.6046297F@lucent.com> Date: Wed, 17 Oct 2001 17:23:16 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org, zwlin@lucent.com Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, > > > I still don't have good answers to (1), which is a hard requirement. I > > understand the solution may be a local decision. Yet, if local behavior may > > impact interworking, it's better be specified. > > One could make a statement along the lines of: "please try to > keep your data plane going if the control plane dies", if that > helps. LMP talks about this ... > I am talking about RSVP-TE. > > For (2), I have a fundamental > > requirement question: does recover/resync from neighbor NE (what's being > > proposed by Ping Pan) acceptable to transport service providers? because this is > > not conventional done in transport network. > > Is running GMPLS conventional in transport networks? :-) > No, that's why GMPLS should learn some basic requirements first. > What is the conventional behaviour in transport networks if the > control plane goes down? How is recovery done? That would be > a useful data point (for me, anyway). > Retrieving from local NV storage or remote OS. > As for the fundamental requirement, it is more like: do you > want your data plane to keep going if the control plane crashes? > Recovery/resync from neighbor is a mechanism, not a requirement. > Of course, there is also the question whether such a mechanism > is acceptable to carriers. > It is a requirement. Here is the difference between transport network and IP network. I agree with your point from the IP point of view. However, in transport network, we are talking about more expensive and less dynamic pipes. The data path information can be stored at multiple locations. Yet, there is normally a single trusted point. So my question is a fundamental requirement question. Is neighbor NE (may be a different vendor's NE) a trusted resource. BTW, I happened to work for a carrier for several years. When I talking about requirement, I used my previous experience and recent discussion with some other carriers. Regards, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 14:07:25 -0700 Date: Wed, 17 Oct 2001 14:05:40 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110172105.OAA02915@kummer.juniper.net> To: kireeti@juniper.net, xuyg@lucent.com Subject: Re: Moving right along ... Cc: ccamp@ops.ietf.org, zwlin@lucent.com Hi Yangguang, > I still don't have good answers to (1), which is a hard requirement. I > understand the solution may be a local decision. Yet, if local behavior may > impact interworking, it's better be specified. One could make a statement along the lines of: "please try to keep your data plane going if the control plane dies", if that helps. LMP talks about this ... > For (2), I have a fundamental > requirement question: does recover/resync from neighbor NE (what's being > proposed by Ping Pan) acceptable to transport service providers? because this is > not conventional done in transport network. Is running GMPLS conventional in transport networks? :-) What is the conventional behaviour in transport networks if the control plane goes down? How is recovery done? That would be a useful data point (for me, anyway). As for the fundamental requirement, it is more like: do you want your data plane to keep going if the control plane crashes? Recovery/resync from neighbor is a mechanism, not a requirement. Of course, there is also the question whether such a mechanism is acceptable to carriers. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 13:42:57 -0700 Message-ID: From: Fugui Wang To: "'Jonathan Lang'" , "'Kireeti Kompella'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Moving right along ... Date: Wed, 17 Oct 2001 16:39:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Thanks for the answer. But still have questions regarding your answer. Please see in line. Fugui >> A couple of questions regarding the messages in the new >> LMP draft: >> >> (1) BeginVerifyAck message: >> Since REMOTE_LINK_ID is optional in the BeginVerify >> message, how could LOCAL_LINK_ID be a required object >> in the BeginVerifyAck message? When you compose the >> BeginVerifyAck message, you may not know the >> LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID >> in the BeginVerify message. >Assuming you don't receive the REMOTE_LINK_ID in BeginVerify message: >If you have locally assigned the Interface to a TE Link, then you will >know >the LOCAL_LINK_ID. If the Interface has not been assigned a TE link, >then >you put a value of zero in the LOCAL_LINK_ID (same rule as BeginVerify >message). But if the node which received the BeginVerify message has multiple TE links to the sender, how does it know which one to pick? >> >> REMOTE_LINK_ID object should be within the >> BeginVerifyAck message. Otherwise when receiving >> BeginVerifyAck, the node won't know for which >> TE link the BeginVerifyAck is for. >The Message_ID_ACK object is sufficient to know which TE link the >BeginVerifyAck is for. Well, theoretically I agree with you. But doesn't that mean that in the sender side, all TE links need to pick Message_ID from a global place? Also, in order to tell the TE link from the Message_ID_ACK, the sender side need to buffer all of the unacknowledged message_ID <==> TE link mapping info. This would be an additional requirement for the send side. Even if you decide to do so, you still need more sophisticated schemes to discard those lost messages from the mapping info list. However,if we simply add the REMOTE_LINK_ID in the BeginVerifyAck message, it would be much easier for the sender side to implement. Same problem also exists for the remaining two questions below. >> >> So maybe we should change the BeginVerifyAck message to: >> ::= >> [] >> >> >> >> >> Actually, I think LOCAL_LINK_ID could also be removed >> because it won't be useful for the receiver side >> except providing a redundant check. >> >> (2) LinkSummaryAck: >> Again, REMOTE_LINK_ID object should be there. >> Otherwise, the remote node won't know for which >> TE link the LinkSummaryAck is for. Using >> MESSAGE_ID_ACK to identify that is difficult >> since that will require the MESSAGE_ID to be >> unique over the node and we also need to use >> the MESSAGE_ID as an index to locate the TE link >> efficiently. (In the old LMP draft, I did see that >> "When combined with the Local TE Link Id ..., the >> MessageId field uniquely identifies a message.") >The MESSAGE_ID_ACK is unique within the scope of the LMP adjacency and >is >sufficient to identify the LinkSummaryAck message. >> Changing the message to the following >> format will make life much easier: >> ::= >> >> >> >> It would also be nice if we can add the REMOTE_LINK_ID >> object to LinkSummaryNack message. >> >> Thanks, >> Fugui >> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 13:28:26 -0700 Message-ID: <3BCDE8EF.F0471B1@lucent.com> Date: Wed, 17 Oct 2001 16:24:15 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Kireeti Kompella CC: zwlin@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, > > > Is it correct to simply include content of individual drafts into > > a WG draft that is in last call without adequate data on whether it > > handles all the different cases? > > Clearly not. Are you suggesting that that was what was done? > > It is a judgment call to include significant new material into a > document in last call. In this instance, handling restart of the > control plane is of sufficient importance to warrant inclusion. > That said, this inclusion happened some time ago (late July); > your comment would have been more timely then. > > In any case, it would be more helpful if you pointed out > scenarios that are missing, and even better if you had concrete > suggestions to fix things. Besides some "corner" issues raised recently yet not answered or answered publicly. I've some non-corner questions. To me, what carriers want are (1) How to preserve data path when control channel/entity fails? (2) How to resync/recover data path information after failure recovers? I still don't have good answers to (1), which is a hard requirement. I understand the solution may be a local decision. Yet, if local behavior may impact interworking, it's better be specified. For (2), I have a fundamental requirement question: does recover/resync from neighbor NE (what's being proposed by Ping Pan) acceptable to transport service providers? because this is not conventional done in transport network. Cheers, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 12:52:54 -0700 Message-ID: From: Heiles Juergen To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: AW: Moving right along ... Date: Wed, 17 Oct 2001 21:50:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Concerning draft-ietf-mpls-generalized-signaling-06.txt I am in discussion with the authors on the G-PID values. An update is = needed here. Concerning the SDH/Sonet documents I want to raise a formal issue. We have now two documents, a document that covers ITU/ANSI standard = features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that = covers non-standard features = (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in = Appendix 1 of the standard feature document a non standard feature = (Group signals) is listed. It is even mentioned that the use of groups = (AUG, STSG, ...) is not described in standards. So this feature should be moved to the non-standards document. = Otherwise the split of the documents doesn't make sense. For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt = I prefer to have the same coding for Sonet and SDH. That makes the = implementation for Sonet and SDH simpler. Furthermore ITU and T1 have = tried over the last years to align Sonet and SDH as much as possible. = The definition of different labels for Sonet and SDH contradicts these = activities. Juergen =20 > -----Urspr=FCngliche Nachricht----- > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > An: ccamp@ops.ietf.org > Betreff: Moving right along ... >=20 >=20 > Despite the energetic subject line, we the WG chairs have been > lax in our duties. So, here goes: >=20 > Lou has submitted the latest versions of the generalized > signaling documents quite some time ago (thanks, Lou): >=20 > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt >=20 > Also, Eric has posted the SONET/SDH documents (merci, Eric): >=20 > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt >=20 > All of these should have addressed the issues raised in the earlier > versions. Please read the new versions, and send your comments to > the list by Tuesday Oct 23. At that point, when the final round > of comments have been addressed, these docs will go to IESG Last > Call. If any one objects to sending these docs to IESG Last Call, > raise your issues now. >=20 > I see that the GMPLS architecture document is a CCAMP WG doc, but > the minutes say that we should look for consensus on the list. So, > if you think this doc *shouldn't* be a WG doc, let us know. (If we > arrived at a consensus, remind me :-)) If nothing is heard, the doc > will progress to WG Last Call. >=20 > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > CCAMP WG docs; consensus at the meeting was Yes. Please let the > list know what your thinking is on these. (BTW, both these docs > were to have some edits done. If the authors could do that before > the next IETF, we can try to make more progress then.) >=20 > The MIB overview doc was recently posted. Please read and comment > to the list. >=20 > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > was generally thought to be useful; it will be published as a > CCAMP informational doc. This begins a two week Last Call on > the doc, ending Tuesday Oct 30. >=20 > There was no consensus on whether the GMPLS framework should be > a CCAMP WG doc. Please indicate your pleasure. >=20 > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > raised that this draft is close to ready for WG Last Call. Please > review it, and let us know if you disagree. >=20 > The OLI requirements doc was broadly accepted. Please let the > list know if you think this doc should be a WG doc. >=20 > It's still open whether we (the IETF) should be working on > LMP-WDM. I urge the authors to keep on working on the doc, and > keeping it in sync with LMP; however, we will postpone making it > a CCAMP WG doc until the issue is resolved. Hopefully that will > happen in Salt Lake City. >=20 > There was reasonable interest in the tunnel trace requirements > doc. Let's formalize this: do you think this should be made a > CCAMP WG document? >=20 > Summary: >=20 > 1) Final comments and IESG Last Call readiness for: > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt >=20 > 2) Should the following documents be CCAMP WG docs? > draft-bonica-tunneltrace-02.txt > draft-fontana-ccamp-gmpls-g709-00.txt > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > draft-many-ccamp-gmpls-framework-00.txt > draft-many-oli-reqts-00.txt >=20 > 3) Comment on MIB overview. >=20 > 4) Two week Last Call comments on > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt >=20 > 5) Last Call readiness of > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-ietf-ccamp-lmp-01.txt >=20 > Thanks, > Kireeti. >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 12:12:47 -0700 Date: Wed, 17 Oct 2001 12:03:58 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110171903.MAA02170@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: GMPLS architecture draft I've been corrected twice already, so just so everyone knows: the GMPLS architecture document had good consensus on the list to make it a CCAMP WG document. Cross that off the list of things you have to do. Thanks, and apologies to Eric and the rest of the authors ... Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 12:00:52 -0700 Date: Wed, 17 Oct 2001 11:52:29 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110171852.LAA02063@kummer.juniper.net> To: kireeti@juniper.net, zwlin@lucent.com Subject: Re: Moving right along ... Cc: ccamp@ops.ietf.org Hi Zhi, > -- cr-ldp is in version 4, which means that the revisions done to > rsvp-te05 has not been reflected there...how do we resolve this > inconsistency? Would bumping the version number of the cr ldp draft work for you? :-) I see that Don has posted a new version -- thanks, Don. > -- rsvp-te-05 and signaling-06 has incorporated the restart capability > as proposed by Ping Pan. However, that work was never looked at > carefully and some issues remain on how this covers all the different > cases. "that work was never looked at carefully" is a strong statement. The work *was* looked at carefully, at least by some folks. There may well be corner cases that have been missed; it would be an excellent idea to point those out. > Is it correct to simply include content of individual drafts into > a WG draft that is in last call without adequate data on whether it > handles all the different cases? Clearly not. Are you suggesting that that was what was done? It is a judgment call to include significant new material into a document in last call. In this instance, handling restart of the control plane is of sufficient importance to warrant inclusion. That said, this inclusion happened some time ago (late July); your comment would have been more timely then. In any case, it would be more helpful if you pointed out scenarios that are missing, and even better if you had concrete suggestions to fix things. > -- signaling-06 also includes several new items in there that doesn't > seem to be added because of a identified need (do a diff to find the > differences). Why were they added to the document (I'm not questioning > them, just asking for clarifying explanation)? Good question, but rather open-ended. Can you mention a few specific items? At that point, Lou et al could mail the list with answers. > -- in signaling-06, since we've decided that this set of I-Ds are to be > consistent with the standards for the respective technologies, then > "Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something > that is used in G.709 or G.872 to describe the types of the signals... I like being consistent with G.709/872. Eric, Dimitri, others: comments on terminology? > -- There are still some technical questions remaining on some content of > the sonet-sdh-02 that are still been discussed in a private list (my > understanding). Shouldn't these be resolved first before it goes for > last call? Can you take them up with the authors? As a general comment, the operative phrase at the IETF is "rough consensus". It would be ideal to have all comments addressed, and all issues resolved, but there is a point at which we have to declare that the remaining issues/comments are not significant enough to halt progress. > -- in sonet-sdh-extension-00, we would like to add two new flags into > the list of flags for transparency (I have spoken to Eric already, and > I'm waiting to have these added in the next version): > flag 13: M0 > flag 14: M1 I don't believe that that should be an issue; however, can you offer reasons for their inclusion, just so we know? > -- I believe g709-00 is currently undergoing some changes to align with > standards positions and to reflect the work on OTN TDM that is been > discussed in ITU study group 15 meeting this week and next week. Excellent! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 11:58:43 -0700 Message-ID: From: Jonathan Lang To: 'Fugui Wang' , 'Kireeti Kompella' Cc: "'ccamp@ops.ietf.org'" Subject: RE: Moving right along ... Date: Wed, 17 Oct 2001 11:43:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Fugui, Sorry for missing this one. Please see inline. Thanks, Jonathan > -----Original Message----- > From: Fugui Wang [mailto:fwang@axiowave.com] > Sent: Wednesday, October 17, 2001 9:22 AM > To: 'Kireeti Kompella' > Cc: 'ccamp@ops.ietf.org' > Subject: RE: Moving right along ... > > > Kireeti, > > For LMP, the following questions regrading message format > has not been answered yet. > > Regards, > Fugui > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > raised that this draft is close to ready for WG Last Call. Please > > review it, and let us know if you disagree. > > A couple of questions regarding the messages in the new > LMP draft: > > (1) BeginVerifyAck message: > Since REMOTE_LINK_ID is optional in the BeginVerify > message, how could LOCAL_LINK_ID be a required object > in the BeginVerifyAck message? When you compose the > BeginVerifyAck message, you may not know the > LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID > in the BeginVerify message. Assuming you don't receive the REMOTE_LINK_ID in BeginVerify message: If you have locally assigned the Interface to a TE Link, then you will know the LOCAL_LINK_ID. If the Interface has not been assigned a TE link, then you put a value of zero in the LOCAL_LINK_ID (same rule as BeginVerify message). > > REMOTE_LINK_ID object should be within the > BeginVerifyAck message. Otherwise when receiving > BeginVerifyAck, the node won't know for which > TE link the BeginVerifyAck is for. The Message_ID_ACK object is sufficient to know which TE link the BeginVerifyAck is for. > > So maybe we should change the BeginVerifyAck message to: > ::= > [] > > > > > Actually, I think LOCAL_LINK_ID could also be removed > because it won't be useful for the receiver side > except providing a redundant check. > > (2) LinkSummaryAck: > Again, REMOTE_LINK_ID object should be there. > Otherwise, the remote node won't know for which > TE link the LinkSummaryAck is for. Using > MESSAGE_ID_ACK to identify that is difficult > since that will require the MESSAGE_ID to be > unique over the node and we also need to use > the MESSAGE_ID as an index to locate the TE link > efficiently. (In the old LMP draft, I did see that > "When combined with the Local TE Link Id ..., the > MessageId field uniquely identifies a message.") The MESSAGE_ID_ACK is unique within the scope of the LMP adjacency and is sufficient to identify the LinkSummaryAck message. > Changing the message to the following > format will make life much easier: > ::= > > > > It would also be nice if we can add the REMOTE_LINK_ID > object to LinkSummaryNack message. > > Thanks, > Fugui > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 10:35:39 -0700 Message-ID: From: "Don Fedyk" To: Zhi-Wei Lin , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Date: Wed, 17 Oct 2001 13:23:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15730.7646C240" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15730.7646C240 Content-Type: text/plain; charset="iso-8859-1" Hi > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, October 17, 2001 12:54 PM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... > > > Hi Kireeti, all, > > Regarding the GMPLS signaling set of I-Ds... > > -- cr-ldp is in version 4, which means that the revisions done to > rsvp-te05 has not been reflected there...how do we resolve this > inconsistency? I send Lou the updated CR-LDP version yesterday. This brings it in sync with RSVP-TE version 5. Don > > ------_=_NextPart_001_01C15730.7646C240 Content-Type: text/html; charset="iso-8859-1" RE: Moving right along ...

Hi

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Wednesday, October 17, 2001 12:54 PM
> To: Kireeti Kompella
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving right along ...
>
>
> Hi Kireeti, all,
>
> Regarding the GMPLS signaling set of I-Ds...
>
> -- cr-ldp is in version 4, which means that the revisions done to
> rsvp-te05 has not been reflected there...how do we resolve this
> inconsistency?
I send Lou the updated CR-LDP version yesterday.  This brings it in
sync with RSVP-TE version 5.

Don

>
>

------_=_NextPart_001_01C15730.7646C240-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 10:16:15 -0700 Message-ID: <3BCDBC4F.C2809621@alcatel.be> Date: Wed, 17 Oct 2001 19:13:51 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: multipart/mixed; boundary="------------F0A577EE669BA3C714A298D8" This is a multi-part message in MIME format. --------------F0A577EE669BA3C714A298D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kireeti, all. Concerning the doc draft-fontana-ccamp-gmpls-g709-00.txt the status is the following: - updates performed as discussed during last meeting and distributed to co-authors (as well as potentially interested people) since 2 weeks to get comments and feedback; - people having shown interest to proactively contribute have been included in the contributor list (if others are interested don't hesitate to contact us) - waiting for the ITU meeting plenary results for commitment wrt to the resulting draft-fontana-ccamp-gmpls-g709-01.txt version (for specific issues which shouldn't delay the process initiated during the last IETF meeting) and then re-submission Regards, Dimitri. Kireeti Kompella wrote: > > Despite the energetic subject line, we the WG chairs have been > lax in our duties. So, here goes: > > Lou has submitted the latest versions of the generalized > signaling documents quite some time ago (thanks, Lou): > > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > All of these should have addressed the issues raised in the earlier > versions. Please read the new versions, and send your comments to > the list by Tuesday Oct 23. At that point, when the final round > of comments have been addressed, these docs will go to IESG Last > Call. If any one objects to sending these docs to IESG Last Call, > raise your issues now. > > I see that the GMPLS architecture document is a CCAMP WG doc, but > the minutes say that we should look for consensus on the list. So, > if you think this doc *shouldn't* be a WG doc, let us know. (If we > arrived at a consensus, remind me :-)) If nothing is heard, the doc > will progress to WG Last Call. > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > CCAMP WG docs; consensus at the meeting was Yes. Please let the > list know what your thinking is on these. (BTW, both these docs > were to have some edits done. If the authors could do that before > the next IETF, we can try to make more progress then.) > > The MIB overview doc was recently posted. Please read and comment > to the list. > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > was generally thought to be useful; it will be published as a > CCAMP informational doc. This begins a two week Last Call on > the doc, ending Tuesday Oct 30. > > There was no consensus on whether the GMPLS framework should be > a CCAMP WG doc. Please indicate your pleasure. > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > raised that this draft is close to ready for WG Last Call. Please > review it, and let us know if you disagree. > > The OLI requirements doc was broadly accepted. Please let the > list know if you think this doc should be a WG doc. > > It's still open whether we (the IETF) should be working on > LMP-WDM. I urge the authors to keep on working on the doc, and > keeping it in sync with LMP; however, we will postpone making it > a CCAMP WG doc until the issue is resolved. Hopefully that will > happen in Salt Lake City. > > There was reasonable interest in the tunnel trace requirements > doc. Let's formalize this: do you think this should be made a > CCAMP WG document? > > Summary: > > 1) Final comments and IESG Last Call readiness for: > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > 2) Should the following documents be CCAMP WG docs? > draft-bonica-tunneltrace-02.txt > draft-fontana-ccamp-gmpls-g709-00.txt > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > draft-many-ccamp-gmpls-framework-00.txt > draft-many-oli-reqts-00.txt > > 3) Comment on MIB overview. > > 4) Two week Last Call comments on > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > 5) Last Call readiness of > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-ietf-ccamp-lmp-01.txt > > Thanks, > Kireeti. --------------F0A577EE669BA3C714A298D8 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------F0A577EE669BA3C714A298D8-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 09:57:16 -0700 Message-ID: <3BCDB795.9020108@lucent.com> Date: Wed, 17 Oct 2001 12:53:41 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Kireeti, all, Regarding the GMPLS signaling set of I-Ds... -- cr-ldp is in version 4, which means that the revisions done to rsvp-te05 has not been reflected there...how do we resolve this inconsistency? -- rsvp-te-05 and signaling-06 has incorporated the restart capability as proposed by Ping Pan. However, that work was never looked at carefully and some issues remain on how this covers all the different cases. Is it correct to simply include content of individual drafts into a WG draft that is in last call without adequate data on whether it handles all the different cases? -- signaling-06 also includes several new items in there that doesn't seem to be added because of a identified need (do a diff to find the differences). Why were they added to the document (I'm not questioning them, just asking for clarifying explanation)? -- in signaling-06, since we've decided that this set of I-Ds are to be consistent with the standards for the respective technologies, then "Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something that is used in G.709 or G.872 to describe the types of the signals... -- There are still some technical questions remaining on some content of the sonet-sdh-02 that are still been discussed in a private list (my understanding). Shouldn't these be resolved first before it goes for last call? -- in sonet-sdh-extension-00, we would like to add two new flags into the list of flags for transparency (I have spoken to Eric already, and I'm waiting to have these added in the next version): flag 13: M0 flag 14: M1 -- I believe g709-00 is currently undergoing some changes to align with standards positions and to reflect the work on OTN TDM that is been discussed in ITU study group 15 meeting this week and next week. Zhi Kireeti Kompella wrote: > Despite the energetic subject line, we the WG chairs have been > lax in our duties. So, here goes: > > Lou has submitted the latest versions of the generalized > signaling documents quite some time ago (thanks, Lou): > > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > All of these should have addressed the issues raised in the earlier > versions. Please read the new versions, and send your comments to > the list by Tuesday Oct 23. At that point, when the final round > of comments have been addressed, these docs will go to IESG Last > Call. If any one objects to sending these docs to IESG Last Call, > raise your issues now. > > I see that the GMPLS architecture document is a CCAMP WG doc, but > the minutes say that we should look for consensus on the list. So, > if you think this doc *shouldn't* be a WG doc, let us know. (If we > arrived at a consensus, remind me :-)) If nothing is heard, the doc > will progress to WG Last Call. > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > CCAMP WG docs; consensus at the meeting was Yes. Please let the > list know what your thinking is on these. (BTW, both these docs > were to have some edits done. If the authors could do that before > the next IETF, we can try to make more progress then.) > > The MIB overview doc was recently posted. Please read and comment > to the list. > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > was generally thought to be useful; it will be published as a > CCAMP informational doc. This begins a two week Last Call on > the doc, ending Tuesday Oct 30. > > There was no consensus on whether the GMPLS framework should be > a CCAMP WG doc. Please indicate your pleasure. > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > raised that this draft is close to ready for WG Last Call. Please > review it, and let us know if you disagree. > > The OLI requirements doc was broadly accepted. Please let the > list know if you think this doc should be a WG doc. > > It's still open whether we (the IETF) should be working on > LMP-WDM. I urge the authors to keep on working on the doc, and > keeping it in sync with LMP; however, we will postpone making it > a CCAMP WG doc until the issue is resolved. Hopefully that will > happen in Salt Lake City. > > There was reasonable interest in the tunnel trace requirements > doc. Let's formalize this: do you think this should be made a > CCAMP WG document? > > Summary: > > 1) Final comments and IESG Last Call readiness for: > draft-ietf-mpls-generalized-cr-ldp-04.txt > draft-ietf-mpls-generalized-rsvp-te-05.txt > draft-ietf-mpls-generalized-signaling-06.txt > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > 2) Should the following documents be CCAMP WG docs? > draft-bonica-tunneltrace-02.txt > draft-fontana-ccamp-gmpls-g709-00.txt > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > draft-many-ccamp-gmpls-framework-00.txt > draft-many-oli-reqts-00.txt > > 3) Comment on MIB overview. > > 4) Two week Last Call comments on > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > 5) Last Call readiness of > draft-ietf-ccamp-gmpls-architecture-00.txt > draft-ietf-ccamp-lmp-01.txt > > Thanks, > Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 09:25:10 -0700 Message-ID: From: Fugui Wang To: "'Kireeti Kompella'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Moving right along ... Date: Wed, 17 Oct 2001 12:22:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti, For LMP, the following questions regrading message format has not been answered yet. Regards, Fugui > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > raised that this draft is close to ready for WG Last Call. Please > review it, and let us know if you disagree. A couple of questions regarding the messages in the new LMP draft: (1) BeginVerifyAck message: Since REMOTE_LINK_ID is optional in the BeginVerify message, how could LOCAL_LINK_ID be a required object in the BeginVerifyAck message? When you compose the BeginVerifyAck message, you may not know the LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID in the BeginVerify message. REMOTE_LINK_ID object should be within the BeginVerifyAck message. Otherwise when receiving BeginVerifyAck, the node won't know for which TE link the BeginVerifyAck is for. So maybe we should change the BeginVerifyAck message to: ::= [] Actually, I think LOCAL_LINK_ID could also be removed because it won't be useful for the receiver side except providing a redundant check. (2) LinkSummaryAck: Again, REMOTE_LINK_ID object should be there. Otherwise, the remote node won't know for which TE link the LinkSummaryAck is for. Using MESSAGE_ID_ACK to identify that is difficult since that will require the MESSAGE_ID to be unique over the node and we also need to use the MESSAGE_ID as an index to locate the TE link efficiently. (In the old LMP draft, I did see that "When combined with the Local TE Link Id ..., the MessageId field uniquely identifies a message.") Changing the message to the following format will make life much easier: ::= It would also be nice if we can add the REMOTE_LINK_ID object to LinkSummaryNack message. Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 09:09:53 -0700 Message-ID: <3BCDAC4B.9834B368@nayna.com> Date: Wed, 17 Oct 2001 09:05:31 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti: My opinion on some of your questions are inline. Regards, sudheer Kireeti Kompella wrote: > > 2) Should the following documents be CCAMP WG docs? > draft-bonica-tunneltrace-02.txt - Yes > > draft-fontana-ccamp-gmpls-g709-00.txt - Yes > draft-ietf-ccamp-gmpls-architecture-00.txt - Yes > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - No opinion > draft-many-ccamp-gmpls-framework-00.txt - No opinion > draft-many-oli-reqts-00.txt - Yes > > 3) Comment on MIB overview. > > 4) Two week Last Call comments on > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt - No opinion > > 5) Last Call readiness of > draft-ietf-ccamp-gmpls-architecture-00.txt - Not ready yet > draft-ietf-ccamp-lmp-01.txt - Yes > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Oct 2001 02:26:16 -0700 Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT) From: Kireeti Kompella Message-Id: <200110170925.CAA29703@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Moving right along ... Despite the energetic subject line, we the WG chairs have been lax in our duties. So, here goes: Lou has submitted the latest versions of the generalized signaling documents quite some time ago (thanks, Lou): draft-ietf-mpls-generalized-cr-ldp-04.txt draft-ietf-mpls-generalized-rsvp-te-05.txt draft-ietf-mpls-generalized-signaling-06.txt Also, Eric has posted the SONET/SDH documents (merci, Eric): draft-ietf-ccamp-gmpls-sonet-sdh-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt All of these should have addressed the issues raised in the earlier versions. Please read the new versions, and send your comments to the list by Tuesday Oct 23. At that point, when the final round of comments have been addressed, these docs will go to IESG Last Call. If any one objects to sending these docs to IESG Last Call, raise your issues now. I see that the GMPLS architecture document is a CCAMP WG doc, but the minutes say that we should look for consensus on the list. So, if you think this doc *shouldn't* be a WG doc, let us know. (If we arrived at a consensus, remind me :-)) If nothing is heard, the doc will progress to WG Last Call. The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be CCAMP WG docs; consensus at the meeting was Yes. Please let the list know what your thinking is on these. (BTW, both these docs were to have some edits done. If the authors could do that before the next IETF, we can try to make more progress then.) The MIB overview doc was recently posted. Please read and comment to the list. The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt was generally thought to be useful; it will be published as a CCAMP informational doc. This begins a two week Last Call on the doc, ending Tuesday Oct 30. There was no consensus on whether the GMPLS framework should be a CCAMP WG doc. Please indicate your pleasure. draft-ietf-ccamp-lmp-01.txt has been posted. The thought was raised that this draft is close to ready for WG Last Call. Please review it, and let us know if you disagree. The OLI requirements doc was broadly accepted. Please let the list know if you think this doc should be a WG doc. It's still open whether we (the IETF) should be working on LMP-WDM. I urge the authors to keep on working on the doc, and keeping it in sync with LMP; however, we will postpone making it a CCAMP WG doc until the issue is resolved. Hopefully that will happen in Salt Lake City. There was reasonable interest in the tunnel trace requirements doc. Let's formalize this: do you think this should be made a CCAMP WG document? Summary: 1) Final comments and IESG Last Call readiness for: draft-ietf-mpls-generalized-cr-ldp-04.txt draft-ietf-mpls-generalized-rsvp-te-05.txt draft-ietf-mpls-generalized-signaling-06.txt draft-ietf-ccamp-gmpls-sonet-sdh-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt 2) Should the following documents be CCAMP WG docs? draft-bonica-tunneltrace-02.txt draft-fontana-ccamp-gmpls-g709-00.txt draft-ietf-ccamp-gmpls-architecture-00.txt draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt draft-many-ccamp-gmpls-framework-00.txt draft-many-oli-reqts-00.txt 3) Comment on MIB overview. 4) Two week Last Call comments on draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt 5) Last Call readiness of draft-ietf-ccamp-gmpls-architecture-00.txt draft-ietf-ccamp-lmp-01.txt Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Oct 2001 16:13:14 -0700 Message-ID: <20011016230949.73341.qmail@web21003.mail.yahoo.com> Date: Tue, 16 Oct 2001 16:09:49 -0700 (PDT) From: Vik Anantha Subject: re: soft state To: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I would like to highlight a issue about GMPLS protocols in general and hopefully the community will give me some insights and/or set me straight. OSPF-TE/IS-IS-TE, RSVP-TE etc (with GMPLS extensions) are all soft-state protocols. They all depend on a state that would degrade in the absence of a refresh message. The advantages of soft state being a> Provides built-in fault recovery (implicit fault recovery). b> Allows for easier interoperabilty. However, the periodicity of the refresh messages is too small for most high bandwidth applications and so explicit fault recovery is also being proposed in the signalling protocols for restoration features. In this context, would there be any big argument against going towards a hard-state approach to ensure database consistency. Let me qualify what I mean by this. First of all I would hate to get into a TCP vs UDP debate because thats not what I mean here. I also appreciate the usefulness of soft state in something like the neighbor discovery aspect of LMP and I would not like to get into that either. What I do mean is, can we have a transaction mechanism that can ensure that the RSVP and OSPF MIBs on all the nodes in the network/domain are always consistent. Operations like setting up new paths and changes to the link state database would always be transactioned. There are a number of distributed database transactions documented in literature (like the two-phase commit etc), and I would assume some good implementations too. This can potentially reduce path setup/restoration time. I would like to hear some views about the pros and cons of replacing or augmenting the soft state refresh mechanism with a transaction mechansim. This would be useful when using GMPLS with high bandwidth pipes like DWDM/SONET etc. Thanks Vik __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Oct 2001 10:10:59 -0700 Message-ID: From: Jonathan Lang To: 'George Young' Cc: ccamp@ops.ietf.org, Jonathan Lang Subject: RE: LMP Question: TE link FSM Date: Tue, 16 Oct 2001 09:48:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, Please see inline. Thanks, Jonathan > -----Original Message----- > From: George Young [mailto:george.young@edgeflow.com] > Sent: Tuesday, October 16, 2001 6:45 AM > To: Jonathan Lang > Cc: ccamp@ops.ietf.org > Subject: RE: LMP Question: TE link FSM > > > Hello Jonathan, > > The new Init state seems useful and I have no difficulties with it. > However, I still have a couple of problems with the TE FSM: > > 1) It appears that the DOWN state has a functioning CC but no links. > Transition #9 moves from DEGRADED, where there are links but no CC, to > DOWN, where there is a CC but no links. This looks like 2 transitions to > me, because 2 independent things happened. At least it's different from > transition #9 from UP, which has CC and links, to DOWN, which has CC and > no links. The DOWN state does not assume there is/isn't a functioning CC. Transition #9 moves from a state where there are links (but no CC) to DOWN where there are no links (and in this case no CC). > > 2) It seems to me that if there is an INIT state, the CC could go down > there too. I'm not sure I understand this comment. The CC has its own FSM that it goes through to come back up. > > My goal here is to have a state machine which is useful (i.e. > explanatory and representative) and has feasible transitions between > states. I don't care about the labels of the states. > > So here's another proposal which I believe keeps everything > in your Oct > 15th version and addresses the two points above: > > -------------------- > Off: No control channel, no data links > Down: There are no data links allocated to the TE link. > Init: Data links have been allocated to the TE link, but the > > configuration has not yet been synchronized with the LMP > neighbor. > Up: This is the normal operational state of the TE link. At > least > one primary CC is required to be operational between the > nodes > sharing the TE link. > Degraded: In this state, all primary CCs are down, but the TE > link still > includes some allocated data links. > Inactive: No control channel, some data links locally allocated to TE. > > 1 : evDCUp: One or more data channels have been added to > the TE Link > 2 : evSumAck: LinkSummary message received and positively > acknowledged. > 3 : evSumNack: LinkSummary message received and negatively > acknowledged. > 4 : evRcvAck: LinkSummaryAck message received acknowledging > the TE Link > Configuration. > 5 : evRcvNack: LinkSummaryNack message received. > 6 : evSumRet: Retransmission timer has expired and > LinkSummary message > is > resent. > 7 : evCCUp: First active control channel goes up. > 8 : evCCDown: Last active control channel goes down. > 9 : evDCDown: Last data channel of TE Link has been removed. > > +--------+ > | | > +------------>| Off | > | | | > | +--------+ > | | ^ > | 7| |8 > | v | > | +--------+ > | | | > | | Down |<---------+ > 9| | | | > | +--------+ | > | | ^ | > | 1| |9 | > | v | | > +--------+ 7 +--------+ | > | |------>| |<-+ | > | Inact | | Init | |3,5,6 |9 > | |<------| |--+ | > +--------+ 8 +--------+ | > | | > 2,4| | > v | > +--------+ 7 +--------+ | > | |------>| |----------+ > | Deg | | Up | > | |<------| | > +--------+ 8 +--------+ > | ^ > | | > +--+ > 2,3,4,5,6 > > > > Regards, > George R. Young > edgeflow Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > > >-----Original Message----- > >From: Jonathan Lang [mailto:jplang@calient.net] > >Sent: Monday, October 15, 2001 2:17 PM > >To: George Young > >Cc: Jonathan Lang > >Subject: RE: LMP Question: TE link FSM > > > > > >George, > > I agree that we need an intermediate state, but I don't > >think it should be > >the Empty state. We have modified the document as follows: > > > >Updated description > >-------------------- > >Down: There are no data links allocated to the TE link. > >Init: Data links have been allocated to the TE link, but the > >configuration > >has not > > yet been synchronized with the LMP neighbor. > >Up: This is the normal operational state of the TE link. At > least one > >primary > > CC is required to be operational between the nodes sharing > >the TE link. > >Degraded: In this state, all primary CCs are down, but the TE > >link still > >includes > > some allocated data links. > > > >1 : evDCUp: One or more data channels have been added to > the TE Link > >2 : evSumAck: LinkSummary message received and positively > >acknowledged. > >3 : evSumNack: LinkSummary message received and negatively > >acknowledged. > >4 : evRcvAck: LinkSummaryAck message received acknowledging > >the TE Link > >Configuration. > >5 : evRcvNack: LinkSummaryNack message received. > >6 : evSumRet: Retransmission timer has expired and > >LinkSummary message is > >resent. > >7 : evCCUp: First active control channel goes up. > >8 : evCCDown: Last active control channel goes down. > >9 : evDCDown: Last data channel of TE Link has been removed. > > > > +--------+ > > | | > > +------------>| Down |<---------+ > > | | | | > > | +--------+ | > > | | ^ | > > | 1| |9 | > > | v | | > > | +--------+ | > > | | |<-+ | > > | | Init | |3,5,6 |9 > > | | |--+ | > > 9| +--------+ | > > | | | > > | 2,4| | > > | v | > > +--------+ 7 +--------+ | > > | |------>| |----------+ > > | Deg | | Up | > > | |<------| | > > +--------+ 8 +--------+ > > | ^ > > | | > > +--+ > > 2,3,4,5,6 > > > > > >> -----Original Message----- > >> From: George Young [mailto:george.young@edgeflow.com] > >> Sent: Tuesday, October 09, 2001 12:24 PM > >> To: ccamp@ops.ietf.org > >> Subject: LMP Question: TE link FSM > >> > >> > >> I have some problems with the TE FSM in > draft-ietf-ccamp-lmp-01.txt. > >> > >> There are 4 combinations of CC UP/Down and None/Some Data Channels > >> Allocated, but only 3 states in the FSM. Also, the TE Link > >> Events should > >> be related to whether the links are allocated to the TE, > not whether > >> they are currently carrying data. Transition 4 is shown > but the note > >> indicates it should not happen. > >> > >> Here is a proposal for a modified TE Link FSM. > >> > >> 11.2.1. TE Link States > >> > >> An LMP TE link can be in one of the states described > below. Every > >> state corresponds to a certain condition of the TE link and is > >> usually associated with a specific type of LMP message that is > >> periodically transmitted to the far end via the > >associated control > >> channel or in-band via the data links. > >> > >> Down: There are no control channels available and no data > >> links are allocated to the TE link. > >> > >> Empty: At least one control channel is available > and no data > >> links are allocated to the TE link. > >> > >> Up: This is the normal operational state of the TE > >> link. At > >> least one primary CC and one or more data-bearing links > >> is > >> required to be operational between the nodes sharing > >> the TE > >> link. > >> > >> Degraded: In this state, all primary CCs are down, but > >> the TE link > >> still includes some allocated data links. > >> > >> 11.2.2. TE Link Events > >> > >> Operation of the LMP TE link is described in terms of FSM > >> states and > >> events. TE Link events are generated by the packet processing > >> routines and by the FSMs of the associated primary control > >> channel(s) and the data links. Every event has its number and a > >> symbolic name. Description of possible control channel > events is > >> given below. > >> > >> 1 : evCCUp: First active CC goes Up. > >> 2 : evDCUp: One or more data channels are UP and > >> LinkSummaryAck message has been received > >> acknowledging the TE link configuration. > >> 3 : evDCDown: Last data channel of TE link has been > >> removed. > >> 4 : evCCDown: Last active CC goes Down. > >> 5 : evReconfig: Successful TE reconfiguration, > LinkSummaryAck > >> message > >> 6 : evReconfigFail: Unsuccessful TE reconfiguration attempt, > >> LinkSummaryNack > >> message > >> > >> 11.2.3. TE Link FSM Description > >> > >> Figure 4 illustrates operation of the LMP TE Link FSM in > >a form of > >> a state transition diagram. > >> > >> > >> +--------+ > >> | | > >> | Down | > >> | | > >> +--------+ > >> | ^ > >> 1| 4| > >> | | > >> v | > >> +--------+ > >> | |<---+ > >> | Empty | | 6 > >> | |----+ > >> +--------+ > >> | ^ > >> 2| 3| > >> | | > >> v | > >> +--------+ 1 +--------+ > >> | |------>| |<---+ > >> | Deg | | Up | | 6 > >> | |<------| |----+ > >> +--------+ 4 +--------+ > >> | ^ > >> | | > >> +---+ > >> 5 > >> > >> Figure 4: LMP TE Link FSM > >> > >> In the above FSM, the sub-states that may be > implemented when the > >> link verification procedure is used have been omitted. > >> > >> Regards, > >> George R. Young > >> edgeflow Inc. > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 > >> phone: +1 613-270-9279 Ext 287 > >> fax: +1 613-270-9268 > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Oct 2001 06:49:03 -0700 content-class: urn:content-classes:message Subject: RE: LMP Question: TE link FSM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Oct 2001 09:45:10 -0400 Message-ID: Thread-Topic: LMP Question: TE link FSM Thread-Index: AcFVpfDXuoJIT0eWQxaxmsOY0VDwSAAodrqA From: "George Young" To: "Jonathan Lang" Cc: Hello Jonathan, The new Init state seems useful and I have no difficulties with it. However, I still have a couple of problems with the TE FSM: 1) It appears that the DOWN state has a functioning CC but no links. Transition #9 moves from DEGRADED, where there are links but no CC, to DOWN, where there is a CC but no links. This looks like 2 transitions to me, because 2 independent things happened. At least it's different from transition #9 from UP, which has CC and links, to DOWN, which has CC and no links. 2) It seems to me that if there is an INIT state, the CC could go down there too. My goal here is to have a state machine which is useful (i.e. explanatory and representative) and has feasible transitions between states. I don't care about the labels of the states. So here's another proposal which I believe keeps everything in your Oct 15th version and addresses the two points above: -------------------- Off: No control channel, no data links Down: There are no data links allocated to the TE link. Init: Data links have been allocated to the TE link, but the configuration has not yet been synchronized with the LMP neighbor. Up: This is the normal operational state of the TE link. At least=20 one primary CC is required to be operational between the nodes=20 sharing the TE link. Degraded: In this state, all primary CCs are down, but the TE link still includes some allocated data links. Inactive: No control channel, some data links locally allocated to TE. 1 : evDCUp: One or more data channels have been added to the TE Link 2 : evSumAck: LinkSummary message received and positively acknowledged. 3 : evSumNack: LinkSummary message received and negatively acknowledged. 4 : evRcvAck: LinkSummaryAck message received acknowledging the TE Link Configuration. 5 : evRcvNack: LinkSummaryNack message received. 6 : evSumRet: Retransmission timer has expired and LinkSummary message is resent. 7 : evCCUp: First active control channel goes up. 8 : evCCDown: Last active control channel goes down. 9 : evDCDown: Last data channel of TE Link has been removed. +--------+ | | +------------>| Off | | | | | +--------+ | | ^=20 | 7| |8 | v | | +--------+ | | | | | Down |<---------+ 9| | | | | +--------+ | | | ^ | | 1| |9 | | v | | +--------+ 7 +--------+ | | |------>| |<-+ | | Inact | | Init | |3,5,6 |9 | |<------| |--+ | +--------+ 8 +--------+ | | | 2,4| | v | +--------+ 7 +--------+ | | |------>| |----------+ | Deg | | Up | | |<------| | +--------+ 8 +--------+ | ^ | | +--+ 2,3,4,5,6 Regards, George R. Young edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 >-----Original Message----- >From: Jonathan Lang [mailto:jplang@calient.net] >Sent: Monday, October 15, 2001 2:17 PM >To: George Young >Cc: Jonathan Lang >Subject: RE: LMP Question: TE link FSM > > >George, > I agree that we need an intermediate state, but I don't=20 >think it should be >the Empty state. We have modified the document as follows: > >Updated description >-------------------- >Down: There are no data links allocated to the TE link. >Init: Data links have been allocated to the TE link, but the=20 >configuration >has not > yet been synchronized with the LMP neighbor. >Up: This is the normal operational state of the TE link. At least one >primary > CC is required to be operational between the nodes sharing=20 >the TE link. >Degraded: In this state, all primary CCs are down, but the TE=20 >link still >includes > some allocated data links. > >1 : evDCUp: One or more data channels have been added to the TE Link >2 : evSumAck: LinkSummary message received and positively=20 >acknowledged. >3 : evSumNack: LinkSummary message received and negatively=20 >acknowledged. >4 : evRcvAck: LinkSummaryAck message received acknowledging=20 >the TE Link >Configuration. >5 : evRcvNack: LinkSummaryNack message received. >6 : evSumRet: Retransmission timer has expired and=20 >LinkSummary message is >resent. >7 : evCCUp: First active control channel goes up. >8 : evCCDown: Last active control channel goes down. >9 : evDCDown: Last data channel of TE Link has been removed. > =20 > +--------+ > | | > +------------>| Down |<---------+ > | | | | > | +--------+ | > | | ^ | > | 1| |9 | > | v | | > | +--------+ | > | | |<-+ | > | | Init | |3,5,6 |9 > | | |--+ | > 9| +--------+ | > | | | > | 2,4| | > | v | > +--------+ 7 +--------+ | > | |------>| |----------+ > | Deg | | Up | > | |<------| | > +--------+ 8 +--------+ > | ^ > | | > +--+ > 2,3,4,5,6 > > >> -----Original Message----- >> From: George Young [mailto:george.young@edgeflow.com] >> Sent: Tuesday, October 09, 2001 12:24 PM >> To: ccamp@ops.ietf.org >> Subject: LMP Question: TE link FSM >>=20 >>=20 >> I have some problems with the TE FSM in draft-ietf-ccamp-lmp-01.txt. >>=20 >> There are 4 combinations of CC UP/Down and None/Some Data Channels >> Allocated, but only 3 states in the FSM. Also, the TE Link=20 >> Events should >> be related to whether the links are allocated to the TE, not whether >> they are currently carrying data. Transition 4 is shown but the note >> indicates it should not happen. >>=20 >> Here is a proposal for a modified TE Link FSM. >>=20 >> 11.2.1. TE Link States=20 >> =20 >> An LMP TE link can be in one of the states described below. Every=20 >> state corresponds to a certain condition of the TE link and is=20 >> usually associated with a specific type of LMP message that is=20 >> periodically transmitted to the far end via the=20 >associated control=20 >> channel or in-band via the data links.=20 >> =20 >> Down: There are no control channels available and no data=20 >> links are allocated to the TE link.=20 >> =20 >> Empty: At least one control channel is available and no data=20 >> links are allocated to the TE link.=20 >> =20 >> Up: This is the normal operational state of the TE=20 >> link. At=20 >> least one primary CC and one or more data-bearing links >> is >> required to be operational between the nodes sharing >> the TE >> link.=20 >> =20 >> Degraded: In this state, all primary CCs are down, but=20 >> the TE link=20 >> still includes some allocated data links.=20 >>=20 >> 11.2.2. TE Link Events=20 >> =20 >> Operation of the LMP TE link is described in terms of FSM=20 >> states and=20 >> events. TE Link events are generated by the packet processing=20 >> routines and by the FSMs of the associated primary control=20 >> channel(s) and the data links. Every event has its number and a=20 >> symbolic name. Description of possible control channel events is=20 >> given below.=20 >> =20 >> 1 : evCCUp: First active CC goes Up.=20 >> 2 : evDCUp: One or more data channels are UP and=20 >> LinkSummaryAck message has been received=20 >> acknowledging the TE link configuration.=20 >> 3 : evDCDown: Last data channel of TE link has been=20 >> removed. =20 >> 4 : evCCDown: Last active CC goes Down.=20 >> 5 : evReconfig: Successful TE reconfiguration, LinkSummaryAck >> message >> 6 : evReconfigFail: Unsuccessful TE reconfiguration attempt, >> LinkSummaryNack=20 >> message >>=20 >> 11.2.3. TE Link FSM Description=20 >> =20 >> Figure 4 illustrates operation of the LMP TE Link FSM in=20 >a form of=20 >> a state transition diagram.=20 >> =20 >> =20 >> +--------+=20 >> | | >> | Down | >> | | >> +--------+=20 >> | ^ =20 >> 1| 4| =20 >> | | =20 >> v | =20 >> +--------+=20 >> | |<---+ >> | Empty | | 6 >> | |----+ >> +--------+=20 >> | ^ =20 >> 2| 3| =20 >> | | =20 >> v | =20 >> +--------+ 1 +--------+=20 >> | |------>| |<---+ >> | Deg | | Up | | 6 >> | |<------| |----+ >> +--------+ 4 +--------+=20 >> | ^=20 >> | |=20 >> +---+=20 >> 5=20 >> =20 >> Figure 4: LMP TE Link FSM=20 >> =20 >> In the above FSM, the sub-states that may be implemented when the=20 >> link verification procedure is used have been omitted. >>=20 >> Regards, >> George R. Young >> edgeflow Inc. >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 >> phone: +1 613-270-9279 Ext 287 >> fax: +1 613-270-9268 >>=20 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Oct 2001 01:17:57 -0700 Message-ID: From: "Roberto Mameli (ERI)" To: "Lista CCAMP (E-mail)" , "Lista Mpls (E-mail)" , "Lista TE-WG (E-mail)" Cc: "Paola Iovanna (ERI)" , "Roberto Mameli (ERI)" , "Giovanna Piantanida (ERI)" , "Stefano Salsano (E-mail)" Subject: Submission of draft-iovanna-rsvp-mpls-flowspec-00.txt Date: Tue, 16 Oct 2001 10:11:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello all, a new Internet-Draft is available from the on-line Internet-Drafts directories (http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt). Title : Definition of the MPLS FlowSpec for RSVP-TE Author(s) : P. Iovanna, R. Mameli, G. Piantanida, S. Salsano Filename : draft-iovanna-rsvp-mpls-flowspec-00.txt Pages : 12 Date : 15-Oct-01 The abstract is reported below. Of course comments and suggestions are welcome. Regards The authors Abstract The support of QoS Differentiation in MPLS is based on the definition of two types of LSP, respectively E-LSP and L-LSP (see [11]). Both E-LSP and L-LSP can be established with bandwidth reservation. In this case bandwidth requirements for the LSP must be signaled at LSP establishment time, in order to perform admission control in the LSRs in the path. If RSVP-TE is used as setup protocol, it has to support the signaling of bandwidth requirements for the LSPs. In this document we extend the RSVP-TE capability by defining a new type of Sender_Tspec (and FlowSpec), explicitly designed to allow signaling of bandwidth requirements for E-LSP and L-LSP set up. This new type, called MPLS Sender_Tspec (MPLS FlowSpec), can include bandwidth requirements for different classes inside the LSP. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Oct 2001 10:29:27 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D022040403573D80@mail1.tellium.com> From: Dimitrios Pendarakis To: "'Bradford, Richard'" , nooreghazi@dacafe.com Cc: CCAMP Subject: RE: LMP Procedure in UNI 1.0 - Doubts Date: Mon, 15 Oct 2001 13:25:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, The mapping between IPCC and CCID should indeed be one-to-one. IPCC is a term for the data channel that is used to exchange IP control messages between a UNI-C and UNI-N. CCID is the identifier for the IPCC. So, its basically a matter of definition. Of course, as pointed out in the document, the CCID may be different in each direction. Thanks, Dimitris > -----Original Message----- > From: Bradford, Richard [mailto:rbradfor@cisco.com] > Sent: Monday, October 15, 2001 12:19 PM > To: nooreghazi@dacafe.com > Cc: CCAMP > Subject: Re: LMP Procedure in UNI 1.0 - Doubts > > > At 01:54 AM 10/15/2001 -0800, Dipnarayan Guha wrote: > >Hello Ramesh, > > > > Rather you may say that a > >corresponding IPCC may have one or more CCID's. > > I do not believe this last statement is correct. It seems > that an IPCC > should (must?) have one and only one node-wide unique CCID. Having a > many-to-one mapping leads to problems. For example, there is > a one-to-one > correspondence between MessageID fields and CCIDs (See > section 2, paragraph 5). > > >For in-fibre signalling, Interface ID has to be assigned by > the initiating > >node. This can be done > >and then the CCID will again change (provided in-fibre signalling is > >present again), but the original CC that is already > established will NOT > >change. > I believe there is a flaw in this interpretation. If the CCID > is reassigned > then the old CCID would no longer be valid. In the case > described, the old > Interface ID for the data link has been changed so an in-band > CCID using > the old value would be invalid, since it would no longer > match the TE-link ID. > > Sincerely, > Rich > > > > > -- > Rich Bradford Email: rbradfor@cisco.com > Cisco Systems, Inc. Tel: 978-244-3079 > 300 Apollo Drive Fax: 978-244-3079 > Chelmsford, Mass 01824 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Oct 2001 09:23:50 -0700 Message-Id: <4.3.2.7.2.20011015095807.01d837d0@pilgrim.cisco.com> Date: Mon, 15 Oct 2001 12:18:54 -0400 To: nooreghazi@dacafe.com From: "Bradford, Richard" Subject: Re: LMP Procedure in UNI 1.0 - Doubts Cc: "CCAMP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:54 AM 10/15/2001 -0800, Dipnarayan Guha wrote: >Hello Ramesh, > > Rather you may say that a >corresponding IPCC may have one or more CCID's. I do not believe this last statement is correct. It seems that an IPCC should (must?) have one and only one node-wide unique CCID. Having a many-to-one mapping leads to problems. For example, there is a one-to-one correspondence between MessageID fields and CCIDs (See section 2, paragraph 5). >For in-fibre signalling, Interface ID has to be assigned by the initiating >node. This can be done >and then the CCID will again change (provided in-fibre signalling is >present again), but the original CC that is already established will NOT >change. I believe there is a flaw in this interpretation. If the CCID is reassigned then the old CCID would no longer be valid. In the case described, the old Interface ID for the data link has been changed so an in-band CCID using the old value would be invalid, since it would no longer match the TE-link ID. Sincerely, Rich -- Rich Bradford Email: rbradfor@cisco.com Cisco Systems, Inc. Tel: 978-244-3079 300 Apollo Drive Fax: 978-244-3079 Chelmsford, Mass 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 15 Oct 2001 07:32:49 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D02204040363429C@mail1.tellium.com> From: Bala Rajagopalan To: 'S Ramesh' , CCAMP Cc: mpls@UU.NET Subject: RE: LMP Procedure in UNI 1.0 - Doubts Date: Mon, 15 Oct 2001 10:23:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesh: At least the 1st question of your message belongs to the OIF lists and not to the IETF lists. If you want to follow up, please post to oif-signal@oiforum.com or send private mail. In any case, let me just briefly answer the questions: (1) Neighbor discovery runs only between network elements and not proxies. If there is a proxy, information must be configured. (2) Node ID refers to the single unique Id of the node (an IP address) Interface ID is an ID for a data link interface. E.g., could be a locally unique index. CCID is an ID for the control channel. One CC could be used to control interactions over multiple link interfaces. In the in-fiber case, a one-to-one association between CC and data link is assumed, hence the relation CCID = interface ID. regards, Bala -----Original Message----- From: S Ramesh [mailto:rashanmu@npd.hcltech.com] Sent: Sunday, October 14, 2001 3:40 PM To: CCAMP; GMPLS Cc: mpls@UU.NET Subject: LMP Procedure in UNI 1.0 - Doubts Hi, I have some doubts in UNI 1.0 Whitepaper published by OIF. 1. IN section 8.2 it is given the UNI neighbour discovery mechanism is based on the LMP protocol mechanism. It is defined some three identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST be equal to the Interface ID. if this is the case then under direct service invocation model which supports In-fiber method, there exists a proxy UNI-N on the TNE side. So here the CCID cannot be the the same as the interface id because interface id is the port address for data transfer and the CCID is the IP control channel which can be a seperate point to point link between the UNI-C and the proxy UNI-N. Then how comes the criteria CCID == Interface ID ( MUST in in-fiber case) can be satisfied. 2. Also there is some confusion exists regarding the three IDs as i mentioned above. When Config messages are sent under IP encapsulation they use the destination address as the Node ID of the destination. So what is the interface ID. Can anybody kindly explain these three IDs with a specific scenario. Thanks, Ramesh Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 14 Oct 2001 01:51:30 -0700 Message-ID: <01e301c154f5$7ee51e70$4564a8c0@hcltech.com> From: "S Ramesh" To: "CCAMP" , "GMPLS" Cc: Subject: Fw: LMP Procedure in UNI 1.0 - Doubts Date: Sun, 14 Oct 2001 14:16:17 -0700 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E0_01C154BA.C9EF54C0" This is a multi-part message in MIME format. ------=_NextPart_000_01E0_01C154BA.C9EF54C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry in the second question it is not config messages.. it is the = Hello messages. Ramesh ----- Original Message -----=20 From: S Ramesh=20 To: CCAMP ; GMPLS=20 Cc: mpls@UU.NET=20 Sent: Sunday, October 14, 2001 12:39 PM Subject: LMP Procedure in UNI 1.0 - Doubts Hi, I have some doubts in UNI 1.0 Whitepaper published by OIF. 1. IN section 8.2 it is given the UNI neighbour discovery mechanism is = based on the LMP protocol mechanism. It is defined some three = identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber = case the CCID MUST be equal to the Interface ID. if this is the case = then under direct service invocation model which supports In-fiber = method, there exists a proxy UNI-N on the TNE side. So here the CCID = cannot be the the same as the interface id because interface id is the = port address for data transfer and the CCID is the IP control channel = which can be a seperate point to point link between the UNI-C and the = proxy UNI-N. Then how comes the criteria CCID =3D=3D Interface ID ( MUST in in-fiber case) can be satisfied. 2. Also there is some confusion exists regarding the three IDs as i = mentioned above. When Config messages are sent under IP encapsulation = they use the destination address as the Node ID of the destination. So = what is the interface ID. Can anybody kindly explain these three IDs = with a specific scenario. Thanks, Ramesh ------=_NextPart_000_01E0_01C154BA.C9EF54C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry in the second question it is not config messages.. it is the = Hello=20 messages.
 
Ramesh
 
----- Original Message -----=20
From: S=20 Ramesh
To: CCAMP ; GMPLS
Cc: mpls@UU.NET=20
Sent: Sunday, October 14, 2001 12:39 PM
Subject: LMP Procedure in UNI 1.0 - Doubts

Hi,
 
I have some doubts in UNI 1.0 Whitepaper published by OIF.
 
1. IN section 8.2 it is given the UNI neighbour discovery  = mechanism=20 is based on the LMP protocol mechanism. It is defined some three = identifiers for=20 LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST = be=20 equal to the Interface ID. if this is the case then under direct service = invocation model which supports In-fiber method, there exists a proxy = UNI-N on=20 the TNE side. So here the CCID cannot be the the same as the interface = id=20 because interface id is the port address for data transfer and the=20 CCID is the IP control channel which can be a seperate point to = point link=20 between the UNI-C and the proxy UNI-N. Then how comes the criteria
 
CCID =3D=3D Interface ID ( MUST in in-fiber case) = can be=20 satisfied.
 
2. Also there is some confusion exists regarding the three IDs as i = mentioned above. When Config messages are sent under IP encapsulation = they use=20 the destination address as the Node ID of the destination. So what is = the=20 interface ID. Can anybody kindly explain these three IDs with a specific = scenario.
 
Thanks,
Ramesh
 
------=_NextPart_000_01E0_01C154BA.C9EF54C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 14 Oct 2001 00:19:11 -0700 Message-ID: <016501c154e8$010c8c70$4564a8c0@hcltech.com> From: "S Ramesh" To: "CCAMP" , "GMPLS" Cc: Subject: LMP Procedure in UNI 1.0 - Doubts Date: Sun, 14 Oct 2001 12:39:53 -0700 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01C154AD.52DD1320" This is a multi-part message in MIME format. ------=_NextPart_000_0162_01C154AD.52DD1320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have some doubts in UNI 1.0 Whitepaper published by OIF. 1. IN section 8.2 it is given the UNI neighbour discovery mechanism is = based on the LMP protocol mechanism. It is defined some three = identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber = case the CCID MUST be equal to the Interface ID. if this is the case = then under direct service invocation model which supports In-fiber = method, there exists a proxy UNI-N on the TNE side. So here the CCID = cannot be the the same as the interface id because interface id is the = port address for data transfer and the CCID is the IP control channel = which can be a seperate point to point link between the UNI-C and the = proxy UNI-N. Then how comes the criteria CCID =3D=3D Interface ID ( MUST in in-fiber case) can be satisfied. 2. Also there is some confusion exists regarding the three IDs as i = mentioned above. When Config messages are sent under IP encapsulation = they use the destination address as the Node ID of the destination. So = what is the interface ID. Can anybody kindly explain these three IDs = with a specific scenario. Thanks, Ramesh ------=_NextPart_000_0162_01C154AD.52DD1320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have some doubts in UNI 1.0 Whitepaper published by OIF.
 
1. IN section 8.2 it is given the UNI neighbour discovery  = mechanism=20 is based on the LMP protocol mechanism. It is defined some three = identifiers for=20 LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST = be=20 equal to the Interface ID. if this is the case then under direct service = invocation model which supports In-fiber method, there exists a proxy = UNI-N on=20 the TNE side. So here the CCID cannot be the the same as the interface = id=20 because interface id is the port address for data transfer and the=20 CCID is the IP control channel which can be a seperate point to = point link=20 between the UNI-C and the proxy UNI-N. Then how comes the criteria
 
CCID =3D=3D Interface ID ( MUST in in-fiber case) = can be=20 satisfied.
 
2. Also there is some confusion exists regarding the three IDs as i = mentioned above. When Config messages are sent under IP encapsulation = they use=20 the destination address as the Node ID of the destination. So what is = the=20 interface ID. Can anybody kindly explain these three IDs with a specific = scenario.
 
Thanks,
Ramesh
 
------=_NextPart_000_0162_01C154AD.52DD1320-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Oct 2001 20:20:42 -0700 Date: Thu, 11 Oct 2001 23:18:10 -0400 (EDT) From: Jim Boyle To: Subject: draft-ietf-tewg-restore-hierarchy-00.txt => CCAMP Attention Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This message is to announce that the document: draft-ietf-tewg-restore-hierarchy-00.txt which was originated out of a service provider focussed design team, and then discussed within the TEWG and adopted as a WG item is ready for consideration by CCAMP. IPO members were also solicited for feedback on this document via the TEWG mailing list. The requirements for restoration and hieararchy that are expressly needed at this time are summarized in the introduction of the document. A. Survivability Requirements @ need to define a small set of interoperable survivability approaches in packet and non-packet networks @ suggested survivability mechanisms include - 1:1 path protection with pre-established backup capacity (non- shared) - 1:1 path protection with pre-planned backup capacity (shared) - local restoration with repairs in proximity to the network fault - path restoration through source-based rerouting @ timing bounds for service restoration to support voice call cutoff (140 msec to 2 sec), protocol timer requirements in premium data services, and mission critical applications @ use of restoration priority for service differentiation B. Hierarchy Requirements B.1. Horizontally Oriented Hierarchy (Intra-Domain) @ ability to set up many LSPs in a service provider network with hierarchical IGP, for the support layer 2 and layer 3 VPN services @ requirements for multi-area traffic engineering need to be developed to provide guidance for any necessary protocol extensions B.2. Vertically Oriented Hierarchy The following functionality for survivability is common on most routing equipment today. @ near-term need is some loose form of coordination and communication based on the use of nested hold-off timers, instead of direct exchange of signaling and routing between vertical layers @ means for an upper layer to immediately begin recovery actions in the event that a lower layer is not configured to perform recovery C. Survivability Requirements in Horizontal Hierarchy @ protection of end-to-end connection is based on a concatenated set of connections, each protected within their area @ mechanisms for connection routing may include (1) a network element that participates on both sides of a boundary (e.g., OSPF ABR) - note that this is a common point of failure; (2) route server @ need for inter-area signaling of survivability information (1) to enable a "least common denominator" survivability mechanism at the boundary; (2) to convey the success or failure of the service restoration action; e.g., if a part of a "connection" is down on one side of a boundary, there is no need for the other side to recover from failures Regards, Jim Boyle, Ed Kern, & TEWG Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Oct 2001 15:54:39 -0700 Message-ID: From: Fugui Wang To: "'ccamp@ops.ietf.org'" Subject: Questions for draft-ietf-ccamp-lmp-01.txt Date: Thu, 11 Oct 2001 18:49:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" A couple of questions regarding the messages in the new LMP draft: (1) BeginVerifyAck message: Since REMOTE_LINK_ID is optional in the BeginVerify message, how could LOCAL_LINK_ID be a required object in the BeginVerifyAck message? When you compose the BeginVerifyAck message, you may not know the LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID in the BeginVerify message. REMOTE_LINK_ID object should be within the BeginVerifyAck message. Otherwise when receiving BeginVerifyAck, the node won't know for which TE link the BeginVerifyAck is for. So maybe we should change the BeginVerifyAck message to: ::= [] Actually, I think LOCAL_LINK_ID could also be removed because it won't be useful for the receiver side except providing a redundant check. (2) LinkSummaryAck: Again, REMOTE_LINK_ID object should be there. Otherwise, the remote node won't know for which TE link the LinkSummaryAck is for. Using MESSAGE_ID_ACK to identify that is difficult since that will require the MESSAGE_ID to be unique over the node and we also need to use the MESSAGE_ID as an index to locate the TE link efficiently. (In the old LMP draft, I did see that "When combined with the Local TE Link Id ..., the MessageId field uniquely identifies a message.") Changing the message to the following format will make life much easier: ::= It would also be nice if we can add the REMOTE_LINK_ID object to LinkSummaryNack message. Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Oct 2001 13:19:55 -0700 Message-ID: From: "Sameh M. Elsharkawy" To: ccamp@ops.ietf.org Subject: LMP Addressing Date: Tue, 9 Oct 2001 16:17:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I have a couple of questions regarding the Addressing section (section 9) in the latest LMP draft (draft-ietf-ccamp-lmp-01.txt). 1. The draft states that: "The destination address of the IP packet MUST be the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the received Config message)" I think that LOCAL_NODE_ID field in the Config message should be used for this purpose instead of the IP header information. 2. Why is RAW IP used for LMP and not UDP for example ? Thanks, Sameh M. Elsharkawy Senior Member of Technical Staff FirstWave Intelligent Optical Networks 6301 Ivy Lane, Suite 700, Greenbelt, MD 20770 (301) 345-2137 x1034 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Oct 2001 12:30:12 -0700 content-class: urn:content-classes:message Subject: LMP Question: TE link FSM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2001 15:23:39 -0400 Message-ID: Thread-Topic: Question: purpose of LMP ChannelActive message (was relationship of RSVP-TE and LMP) Thread-Index: AcFF3KgKXVTv/7NDQuGYPnt8JJ8mlQLGs+sg From: "George Young" To: I have some problems with the TE FSM in draft-ietf-ccamp-lmp-01.txt. There are 4 combinations of CC UP/Down and None/Some Data Channels Allocated, but only 3 states in the FSM. Also, the TE Link Events should be related to whether the links are allocated to the TE, not whether they are currently carrying data. Transition 4 is shown but the note indicates it should not happen. Here is a proposal for a modified TE Link FSM. 11.2.1. TE Link States=20 =20 An LMP TE link can be in one of the states described below. Every=20 state corresponds to a certain condition of the TE link and is=20 usually associated with a specific type of LMP message that is=20 periodically transmitted to the far end via the associated control=20 channel or in-band via the data links.=20 =20 Down: There are no control channels available and no data=20 links are allocated to the TE link.=20 =20 Empty: At least one control channel is available and no data=20 links are allocated to the TE link.=20 =20 Up: This is the normal operational state of the TE link. At=20 least one primary CC and one or more data-bearing links is required to be operational between the nodes sharing the TE link.=20 =20 Degraded: In this state, all primary CCs are down, but the TE link=20 still includes some allocated data links.=20 11.2.2. TE Link Events=20 =20 Operation of the LMP TE link is described in terms of FSM states and=20 events. TE Link events are generated by the packet processing=20 routines and by the FSMs of the associated primary control=20 channel(s) and the data links. Every event has its number and a=20 symbolic name. Description of possible control channel events is=20 given below.=20 =20 1 : evCCUp: First active CC goes Up.=20 2 : evDCUp: One or more data channels are UP and=20 LinkSummaryAck message has been received=20 acknowledging the TE link configuration.=20 3 : evDCDown: Last data channel of TE link has been removed. =20 4 : evCCDown: Last active CC goes Down.=20 5 : evReconfig: Successful TE reconfiguration, LinkSummaryAck message 6 : evReconfigFail: Unsuccessful TE reconfiguration attempt, LinkSummaryNack=20 message 11.2.3. TE Link FSM Description=20 =20 Figure 4 illustrates operation of the LMP TE Link FSM in a form of=20 a state transition diagram.=20 =20 =20 +--------+=20 | | | Down | | | +--------+=20 | ^ =20 1| 4| =20 | | =20 v | =20 +--------+=20 | |<---+ | Empty | | 6 | |----+ +--------+=20 | ^ =20 2| 3| =20 | | =20 v | =20 +--------+ 1 +--------+=20 | |------>| |<---+ | Deg | | Up | | 6 | |<------| |----+ +--------+ 4 +--------+=20 | ^=20 | |=20 +---+=20 5=20 =20 Figure 4: LMP TE Link FSM=20 =20 In the above FSM, the sub-states that may be implemented when the=20 link verification procedure is used have been omitted. Regards, George R. Young edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Oct 2001 11:28:51 -0700 content-class: urn:content-classes:message Subject: LMP Question: data link FSMs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2001 14:22:49 -0400 Message-ID: Thread-Topic: Question: purpose of LMP ChannelActive message (was relationship of RSVP-TE and LMP) Thread-Index: AcFF3KgKXVTv/7NDQuGYPnt8JJ8mlQLEkTDQ From: "George Young" To: I have a couple of problems with the Data Link FSMs in draft-ietf-ccamp-lmp-01.txt. Event 14:evdcDown appears to be an administrative action, as opposed to the failure event 13:evLocalizeFail. That being the case, event 14:evdcDown should only transit from Up/Free to Down. If this understanding is correct, suggested FSMs are included below. In the passive case, transition 13 would need something like ChannelFailNack to trigger it. Figure 5 illustrates operation of the LMP active data link FSM in a=20 form of FSM state transition diagram.=20 =20 +------+=20 +------------->| | =20 | +--------->| Down |<---------+ | | +----| |<-----+ | | | | +------+ | | | | |5b 3| ^ | | | | | | |2,7 | | | | | v | | | | | | +------+ | | | | | | |<-+ | | | | | | Test | |11 | | | | | | |--+ | | | | | +------+ | | | | | 5a| 3^ | | | | | | | | | | | | v | | | | |2,12 | +---------+ | | | | +-->| |14 | | | | | Up/Free |----+ | | +---------| | | | +---------+ | | 9| ^ | | | | | |10 v |10 | +-----+ 2 +---------+ | | |<--------| | 13 | | Deg | |Up/Alloc |--------+ | |-------->| |=20 +-----+ 1 +---------+=20 =20 Figure 5: Active LMP Data Link FSM=20 =20 Figure 6 illustrates operation of the LMP passive data link FSM in a=20 form of FSM state transition diagram.=20 =20 +------+=20 +------------->| |=20 | +---------->| Down |<---------+ | | +-----| |<----+ | | | | +------+ | | | | |5b 4| ^ | | | | | | |2,8 | | | | | v | | | | | | +----------+ | | | | | | PasvTest | | | | | | +----------+ | | | | | 6| 4^ | | | | | | | |14 | | | | v | | | | |2,12 | +---------+ | | | | +--->| Up/Free | | | | | | |---+ | | +----------| | | | +---------+ | | 9| ^ | | | | | |10 v |10 | +-----+ +---------+ | | | 2 | | 13 | | Deg |<--------|Up/Alloc |--------+ | |-------->| |=20 +-----+ 1 +---------+=20 =20 Figure 6: Passive LMP Data Link FSM=20 Regards, George R. Young edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Oct 2001 11:05:27 -0700 content-class: urn:content-classes:message Subject: LMP Question: fault management messages MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2001 13:56:31 -0400 Message-ID: Thread-Topic: Question: purpose of LMP ChannelActive message (was relationship of RSVP-TE and LMP) Thread-Index: AcFF3KgKXVTv/7NDQuGYPnt8JJ8mlQLDj7jA From: "George Young" To: I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus message and its friends. In Section 6.2. Fault Localization Procedure, LMP states "Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures". This is workable and signalling can reroute around the link or the path, releasing resources as appropriate. However, with the departure of the ChannelFailNack, the node at the receive end of the faulty link does not find out about the fault from either the signalling protocol or LMP. As bidirectional paths are allocated, there is a chance that the failed link will be allocated to a subsequent call through this node. Furthermore, assuming a signalling protocol has established paths, and indicated their active or backup status with the Administrative Status object in GMPLS, there does not appear to be any need in LMP for the Active/Deactive indications in the CHANNEL_STATUS object. This information has already been conveyed by the signalling protocol during path establishment. =20 If my understanding is correct, ChannelFailNack functionality is needed and the Active and Deactive values of the CHANNEL_STATUS object are not. Regards, George R. Young edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Oct 2001 08:56:43 -0700 Message-Id: <4.3.2.7.2.20011004113726.01f85b90@pilgrim.cisco.com> Date: Thu, 04 Oct 2001 11:52:58 -0400 To: "Balasubramania N. Pillai" From: "Bradford, Richard" Subject: Re: LMP Messages Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Comments inline. At 06:06 PM 10/2/2001 -0400, Balasubramania N. Pillai wrote: >Hi > >I have a basic doubt regarding LMP Messages based on the latest LMP draft. > >Section 3, paragraph 5 of the draft says > > > There are four LMP messages that are used to manage individual > > control channels. They are the Config, ConfigAck, ConfigNack, and > > Hello messages. These messages MUST be transmitted on the channel to > > which they refer. All other LMP messages may be transmitted over > > any of the active control channels between a pair of LMP adjacent > > nodes. > >Why is it that these messages MUST be transmitted on the channel to which >they refer. I can understand why LMP Hello messages need to be sent over the >control channel, which it refers to. But is it necessary to force the other >messages. > > > > ---------- ---------- > | | C1 | | > | |--------------------| | > | Switch 1 | | Switch 1 | > | |--------------------| | > | | C2 | | > ---------- ---------- > > >Based on the above picture assume that there are 2 control channels between >Switches 1 & 2. LMP messages are sent over IP. If I have to force messages >over individual channels then I need to get down to Layer 2. If I don't have >to force it, I can let IP routing pick any one of the available channels to >carry the message. Here's my take. You COULD do what you want by defining a single control channel, where that IPCC is routed (Note following argument applies to a single IPCC where underlying links are load shared/bundled). What you would lose is an indication that either C1 or C2 was no longer passing data. Let's say routing prefers C1 and somewhere along C2 there's a disruption. At this point the switches have no backups but have no indication that there are no backups. If LMP is configured with multiple IPCCs and IFF hello's are going over those IPCCs, then you will know if there's a problem with one of the IPCCs. Another reason is that the CONFIG for inband IPCC can be used in lieu of LinkVerify for determining the mapping of links between the switches, but only if the CONFIG message goes over the correct link. -- rich -- Rich Bradford Email: rbradfor@cisco.com Cisco Systems, Inc. Tel: 978-244-3079 300 Apollo Drive Fax: 978-244-3079 Chelmsford, Mass 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Oct 2001 02:16:55 -0700 To: ccamp , "t1x1.5" , oif-architecture-group Cc: q11/15 Message-ID: <3BBC28A4.A160C44@lucent.com> Date: Thu, 04 Oct 2001 11:15:16 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 Original-To: ccamp , "t1x1.5" , oif-architecture-group Original-CC: q11/15 Subject: OLI/LMP-WDM/NTIP => next step in ITU-T SG15 Content-Type: multipart/mixed; boundary="------------25E5C527A558CF0435049F1B" This is a multi-part message in MIME format. --------------25E5C527A558CF0435049F1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I am pleased to announce the availability of 4 contributions for the upcoming SG15 meeting addressing the rationale/architecture, applications, physical and performance aspects of the interface between an OLS and an PXC. These contributions resulted from interaction with key players(*) in the IETF ccamp WG concerning the OLI, LMP-WDM and NTIP activities. (*) Osama Aboul-Magd, Curtis Brownmiller, John Drake, Andre Fredette and Jonathan Lang You will find the contributions (in word97 and pdf formats) in ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q11/0110 This interface is referred to by many names so far: LMP-WDM, OLI, NTIP, OTM-LF. In the contributions, it is referred to as Virtual Backplane Interface (VBI), but a better name is urgently needed... This interface is a true transport plane interface and once standardized by ITU-T SG15 it should be usable for the purposes needed by ITU-T/T1, IETF ccamp WG and OIF. Please review the contributions and provide comment either during the upcoming SG15 meeting in Geneva (Oct. 15-26) or via correspondence. These contributions are intended to provide a framework for the new interface specification. The specification work itself is obviously the next step and a united ITU-T/T1/IETF CCAMP/OIF effort to progress this specification would be an excellent way forward. Regards, Maarten --------------25E5C527A558CF0435049F1B Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------25E5C527A558CF0435049F1B-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Oct 2001 17:49:25 -0700 Reply-To: From: "Vishal Sharma" To: "CCAMP" Subject: Separation of IP control and data channels Date: Wed, 3 Oct 2001 17:44:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, There appears to be an issue about how to separate IP control channels from IP data channels within OSPF-TE for GMPLS, when one focuses on the peer model. In the peer model, a router/switch will get OSPF-TE opaque LSAs from the the entire network, and needs a way to distinguish between data-capable IP links in the network from IP control channels. This is to prevent the calculation of routes for IP data packets that traverse any IP control channels. While draft-ietf-ccamp-routing-00.txt mentions a couple of ways to try to avoid this, they may not be enough, especially if one does not have the flexibility to seggregate control and data channel address spaces, and/or if one is focusing only on the IGP case. A simple way to achieve this goal is to extend the Switching Cap field in the Interface Switching Capability Descriptor to separate an "IP Data packet switch capable" link/interface from an "IP control packet swich capable" link. We would like to propose that this be added to the relevant drafts. Thanks, -Vishal _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Oct 2001 13:27:09 -0700 From: "Fong Liaw" To: "Yangguang Xu" , "Lou Berger" Cc: Subject: RE: update GMPLS signaling documents Date: Wed, 3 Oct 2001 13:20:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yanguang I am jumping in here, Lou can certainly add or clarify further. see below. > This one was sent to MPLS WG. > > /////////////////////////////////////////////////////////// > I have some questions/concerns on the restart mechanism as > specified in draft-ietf-mpls-generalized-rsvp-te-04.txt. I > have listed them below. > > If a node that is terminating hierarchical LSPs restarts, > there is an ordering issue during resynchronization, since > the LSPs would depend on other FA-LSPs the interface IDs for > which would have been generated dynamically. So the > mechanism as described will not work, unless this > information is preserved across restarts - in which case we > might as well preserve other information as well, and avoid > resynchronization. Since transit node of the FA-LSP does not see the RSVP messages that use the FA, we only need to consider the ingress and egress node. If the egress node restarts, the worst case is that its upstream node sends an ERO consisting a unrecognized interface address. Since the Path message will carry RECOVERY_LABEL (replacing SUGGESTED_LABEL), the egress node knows that it might not have complete information yet, and can hold on to the Path message until the FA-LSP is established. All the information is there, so implementation can be completely within the egress node. It does work, just not specified enough. Ingress node will have to know the dependency, so not a problem there. > > Also, let us consider a node that can preserve state across > restarts, and hence does not need its state to be synced by > its peer. How will it advertise this in the RESTART_CAP > object? > We still need to resynchronize the state since the other side might have connections that are in progress. The reason for resynchronization is to make sure both side have done the same to the in-progress connections, not just to synchronize the established states. The value of the RESTART_CAP will set to non-zero values. > If a node supports PSC as well as TDM or LSC interfaces, it > might want to advertise different set of parameters in the > RESTART_CAP object for data LSPs as opposed to SONET/WDM > LSPs which form bearer channels in transport networks. > Currently this is not possible. Can you give us explicit examples as to why and what do you gain by giving different values for PSC, TDM ? > > According to 9.5.1. (procedures for restarting LSR): "When > sending the corresponding outgoing Path message the node > SHOULD include a SUGGESTED_LABEL object with a label value > ^^^^^^ > matching the outgoing label from the now restored forwarding > entry." > > This has a conflict with 9.5.2. Consider the case where > adjacent nodes B and C restart, and B has another adjacent > node A, and C has another adjacent node D. B and C will get > resynced by A and D, and during this process, they will > resync. each other. While resyncing each other, they act as > neighbors of a restarting LSR, and hence according to 9.5.2, > MUST include the SUGGESTED_LABEL. > > Also according to 9.5.2: "During the recovery period, new > Path state being advertised to the restarted neighbor SHOULD > not include the SUGGESTED_LABEL object in the corresponding > outgoing Path message. This will prevent the restarting > node from erroneously reusing a saved forwarding entry." > > I guess this would mean that if suggested labels are used > during new LSP setup (as they are likely to be while > provisioning lightpaths - to reduce latency), then new LSP > setup will not be allowed during resyncing? > The use of RECOVERY_LABEL address all the above questions. > In section 9.3: "When a new Hello message is received from > the neighbor, the LSR must determine if the fault was > limited to the control channel or was a nodal fault. This > determination is based on the Src_Instance received from the > neighbor. If the value is different than the value that was > received from the neighbor prior to the fault, then the > neighbor should be treated as if it has restarted. > Otherwise, the the fault was limited control channel." > > If two adjacent nodes restart, how can each of them > determine that the other also just restarted? This would > need that the src_instance received from the neighbor is > preserved across restarts - was that the intent? > The use of same src_instance is just to help speed up the resynchronization using Srefresh message. If the instance number is different, the resynchronization uses Path message. Both procedure will recover to the same state. > > Another one > > /////////////////////////////////////////////////////// > I think I've found a problem with the nodal fault recovery mechanism > in draft-ietf-mpls-generalized-rsvp-te-04.txt, section 9.5. > > If the node that fails is the ingress node (i.e., an LER), then the LSP > won't recover since there is no upstream neighbor from which this > restarting LER will receive a PATH message. Therefore, the LER > won't send a PATH message to its downstream neighbor, and the > LSP recovery fails. > > In other words, recovery only seems to work if an LSR or an Egress > LER experiences nodal failure. > > Perhaps this could be fixed by having neighbors of the restarting > node send a RESV for any Resv state held? > > This has been discussed in the initial restart draft and was decided that if an ingress node wants to preserve the LSP, it needs to remember enough information in the configuaration file/storage. I believe any developer will be able to figure out what to save in the configuration store to make this happen if the vendor decides to offer this as a feature. Not sure there is much to be specified if we take this approach. If people want to allow configuration-file-less procedure, would they care to give explicit application examples ? Regards, -Fong > > > > > Lou Berger wrote: > > > > FYI - > > > > Updated versions of the signaling and RSVP-TE documents have been > > submitted. The CR-LDP version is forthcoming. The updates > address comments > > received during the August meeting and comment period. > > > > Here's a summary of changes: > > > > draft-ietf-mpls-generalized-signaling-06.txt > > Changes from previous version: > > o Removed redundant encoding type > > o Revised Admin Status Usage (per comments and also removed > potential race > > condition) o Clarified text related to interface bundling (To > be consistent > > with updated bundling draft.) > > o Minor editorial changes and clarifications > > o Revised G-PID (per comments on list) > > > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > Changes from previous version: > > o Revised Admin Status Usage (per comments and also removed > potential race > > condition) > > o Clarified text related to interface bundling (To be consistent with > > updated bundling draft.) > > o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel > > Separation by allowing identification of errored interface.) > > o Added U bit to Label RRO subobject (Per comment, to match > defined ERO.) > > o Clarified usage of Restart_Cap o Replaced use of > Suggested_Label during > > recovery with new Recovery_Label (Per last WG session) > > o Added IANA Considerations > > o Minor editorial changes and clarifications > > > > For those who don't want to wait, the drafts are available from: > > http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt > > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt > > > > Lou _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Oct 2001 07:01:58 -0700 Message-ID: <3BBB1964.E022231@lucent.com> Date: Wed, 03 Oct 2001 09:57:56 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org Subject: Re: update GMPLS signaling documents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lou, There were two emails (see below) raising some good questions about the re-start procedure for RSVP-TE. I haven't seen any open discussion on these two emails, nor changes in the new drafts. Are those issues solved? Would you please update us? Thanks, Yangguang This one was sent to MPLS WG. /////////////////////////////////////////////////////////// I have some questions/concerns on the restart mechanism as specified in draft-ietf-mpls-generalized-rsvp-te-04.txt. I have listed them below. If a node that is terminating hierarchical LSPs restarts, there is an ordering issue during resynchronization, since the LSPs would depend on other FA-LSPs the interface IDs for which would have been generated dynamically. So the mechanism as described will not work, unless this information is preserved across restarts - in which case we might as well preserve other information as well, and avoid resynchronization. Also, let us consider a node that can preserve state across restarts, and hence does not need its state to be synced by its peer. How will it advertise this in the RESTART_CAP object? If a node supports PSC as well as TDM or LSC interfaces, it might want to advertise different set of parameters in the RESTART_CAP object for data LSPs as opposed to SONET/WDM LSPs which form bearer channels in transport networks. Currently this is not possible. According to 9.5.1. (procedures for restarting LSR): "When sending the corresponding outgoing Path message the node SHOULD include a SUGGESTED_LABEL object with a label value ^^^^^^ matching the outgoing label from the now restored forwarding entry." This has a conflict with 9.5.2. Consider the case where adjacent nodes B and C restart, and B has another adjacent node A, and C has another adjacent node D. B and C will get resynced by A and D, and during this process, they will resync. each other. While resyncing each other, they act as neighbors of a restarting LSR, and hence according to 9.5.2, MUST include the SUGGESTED_LABEL. Also according to 9.5.2: "During the recovery period, new Path state being advertised to the restarted neighbor SHOULD not include the SUGGESTED_LABEL object in the corresponding outgoing Path message. This will prevent the restarting node from erroneously reusing a saved forwarding entry." I guess this would mean that if suggested labels are used during new LSP setup (as they are likely to be while provisioning lightpaths - to reduce latency), then new LSP setup will not be allowed during resyncing? In section 9.3: "When a new Hello message is received from the neighbor, the LSR must determine if the fault was limited to the control channel or was a nodal fault. This determination is based on the Src_Instance received from the neighbor. If the value is different than the value that was received from the neighbor prior to the fault, then the neighbor should be treated as if it has restarted. Otherwise, the the fault was limited control channel." If two adjacent nodes restart, how can each of them determine that the other also just restarted? This would need that the src_instance received from the neighbor is preserved across restarts - was that the intent? Another one /////////////////////////////////////////////////////// I think I've found a problem with the nodal fault recovery mechanism in draft-ietf-mpls-generalized-rsvp-te-04.txt, section 9.5. If the node that fails is the ingress node (i.e., an LER), then the LSP won't recover since there is no upstream neighbor from which this restarting LER will receive a PATH message. Therefore, the LER won't send a PATH message to its downstream neighbor, and the LSP recovery fails. In other words, recovery only seems to work if an LSR or an Egress LER experiences nodal failure. Perhaps this could be fixed by having neighbors of the restarting node send a RESV for any Resv state held? Lou Berger wrote: > > FYI - > > Updated versions of the signaling and RSVP-TE documents have been > submitted. The CR-LDP version is forthcoming. The updates address comments > received during the August meeting and comment period. > > Here's a summary of changes: > > draft-ietf-mpls-generalized-signaling-06.txt > Changes from previous version: > o Removed redundant encoding type > o Revised Admin Status Usage (per comments and also removed potential race > condition) o Clarified text related to interface bundling (To be consistent > with updated bundling draft.) > o Minor editorial changes and clarifications > o Revised G-PID (per comments on list) > > draft-ietf-mpls-generalized-rsvp-te-05.txt > Changes from previous version: > o Revised Admin Status Usage (per comments and also removed potential race > condition) > o Clarified text related to interface bundling (To be consistent with > updated bundling draft.) > o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel > Separation by allowing identification of errored interface.) > o Added U bit to Label RRO subobject (Per comment, to match defined ERO.) > o Clarified usage of Restart_Cap o Replaced use of Suggested_Label during > recovery with new Recovery_Label (Per last WG session) > o Added IANA Considerations > o Minor editorial changes and clarifications > > For those who don't want to wait, the drafts are available from: > http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt > > Lou Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Oct 2001 15:05:45 -0700 Message-ID: From: "Balasubramania N. Pillai" To: ccamp@ops.ietf.org Subject: LMP Messages Date: Tue, 2 Oct 2001 18:06:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi I have a basic doubt regarding LMP Messages based on the latest LMP draft. Section 3, paragraph 5 of the draft says > There are four LMP messages that are used to manage individual > control channels. They are the Config, ConfigAck, ConfigNack, and > Hello messages. These messages MUST be transmitted on the channel to > which they refer. All other LMP messages may be transmitted over > any of the active control channels between a pair of LMP adjacent > nodes. Why is it that these messages MUST be transmitted on the channel to which they refer. I can understand why LMP Hello messages need to be sent over the control channel, which it refers to. But is it necessary to force the other messages. ---------- ---------- | | C1 | | | |--------------------| | | Switch 1 | | Switch 1 | | |--------------------| | | | C2 | | ---------- ---------- Based on the above picture assume that there are 2 control channels between Switches 1 & 2. LMP messages are sent over IP. If I have to force messages over individual channels then I need to get down to Layer 2. If I don't have to force it, I can let IP routing pick any one of the available channels to carry the message. Thanks Balu Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Oct 2001 08:34:09 -0700 Message-ID: <3BB9DA4A.67684D6E@alcatel.be> Date: Tue, 02 Oct 2001 17:16:26 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG-NA MIME-Version: 1.0 To: "Saha, Sayandeb" CC: "'ccamp@ops.ietf.org'" Subject: Re: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt query Content-Type: multipart/mixed; boundary="------------2FD3A4E6CD933087CBB1F979" This is a multi-part message in MIME format. --------------2FD3A4E6CD933087CBB1F979 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Just notice that Note 2: when requesting a transparent STM-N/STS-N signal limited to a single contiguously concatenated VC-4-Nc/STS-Nc- SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and NCC set to 1. The reference you have made applies to non-transparent signals. Regards, Dimitri. "Saha, Sayandeb" wrote: > > Shouldn't the following examples in draft > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > 3. An STS-48c signal with LOH DCC and E2 transparency is formed by the > application of RCC with flag 1, NCC with value 1, NVC with value 0, MT with > value 1 and T with flag 5 and 10 to an STS-48 Elementary Signal. > > be > > An STS-48c signal with LOH DCC and E2 transparency is formed by the > application of RCC with flag 1, NCC with value 16, NVC with value 0, MT with > value 1 and T with flag 5 and 10 to an STS-3c SPE elementary signal, > according to the following ... > > "when requesting a SONET STS-Nc SPE with N=3*X, the elementary signal to use > must always be an STS-3c SPE signal type and the value of NCC must always be > equal to X. This allows also facilitating the interworking between SONET and > SDH. In particular, it means that the contiguous concatenation of three > STS-1 SPEs cannot not be requested because according to this specification, > this type of signal must be coded using the STS-3c SPE signal type. " > > in the draft-ietf-ccamp-gmpls-sonet-sdh-02.txt . > There's a similar problem with example 4 too. > -Sayan --------------2FD3A4E6CD933087CBB1F979 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NSG - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------2FD3A4E6CD933087CBB1F979-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Oct 2001 07:46:39 -0700 Message-ID: <87009604743AD411B1F600508BA0F95971BB67@XOVER.dedham.mindspeed.com> From: "Saha, Sayandeb" To: "'ccamp@ops.ietf.org'" Subject: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt query Date: Tue, 2 Oct 2001 10:44:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Shouldn't the following examples in draft draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt 3. An STS-48c signal with LOH DCC and E2 transparency is formed by the application of RCC with flag 1, NCC with value 1, NVC with value 0, MT with value 1 and T with flag 5 and 10 to an STS-48 Elementary Signal. be An STS-48c signal with LOH DCC and E2 transparency is formed by the application of RCC with flag 1, NCC with value 16, NVC with value 0, MT with value 1 and T with flag 5 and 10 to an STS-3c SPE elementary signal, according to the following ... "when requesting a SONET STS-Nc SPE with N=3*X, the elementary signal to use must always be an STS-3c SPE signal type and the value of NCC must always be equal to X. This allows also facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs cannot not be requested because according to this specification, this type of signal must be coded using the STS-3c SPE signal type. " in the draft-ietf-ccamp-gmpls-sonet-sdh-02.txt . There's a similar problem with example 4 too. -Sayan Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Oct 2001 04:04:47 -0700 Message-Id: <200110021101.HAA03145@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-02.txt Date: Tue, 02 Oct 2001 07:01:55 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Extensions for SONET and SDH Control Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-sonet-sdh-02.txt Pages : 20 Date : 01-Oct-01 This document is a companion to the Generalized MPLS signaling documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines the SONET/SDH technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-sonet-sdh-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011001112628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001112628.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Oct 2001 04:04:41 -0700 Message-Id: <200110021102.HAA03161@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt Date: Tue, 02 Oct 2001 07:02:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Extensions to Control Non-Standard SONET and SDH Features Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt Pages : 11 Date : 01-Oct-01 This document is a companion to the GMPLS signaling extensions to control SONET and SDH document [GMPLS-SONET-SDH] that defines the SONET/SDH technology specific information needed when using GMPLS signaling. This informational document defines GMPLS signaling extensions to control three optional non-standard (i.e. proprietary) SONET and SDH features: arbitrary concatenation, per byte transparency and the virtual concatenation of contiguously concatenated signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011001112648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001112648.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Oct 2001 04:04:34 -0700 Message-Id: <200110021102.HAA03179@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lmp-01.txt Date: Tue, 02 Oct 2001 07:02:06 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang et al. Filename : draft-ietf-ccamp-lmp-01.txt Pages : 62 Date : 01-Oct-01 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels and data links. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lmp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lmp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011001112700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001112700.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Oct 2001 12:59:24 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bi-directional LSPs [Contention Resolution] Date: Mon, 01 Oct 2001 12:55:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have a basic doubt regarding contention resolution. The draft explains the example with upstream label and suggested label. Suggested label is optional. If a node is not able to allocate the suggested label then it may override the suggestged label. The actual contention arises when it is the last label. Am I right ? Another case, the contention will also occur when say request for two bi-directional LSPs are initiated in opposite directions and both the requests include same upstream label. In addition to this, the label set contains one label, same as upstream label (i.e. sender wants to have samelabel in both the directions). Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Oct 2001 12:58:03 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Doubt Related to SDH/SONET interface : GMPLS Date: Mon, 01 Oct 2001 12:51:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If minimum reservable bandwidth of an STM-16 link in interface switching capability TLV is VC-3, does this mean it can't switch VC -2/VC-11 etc ? In other words, if a request comes for establishing an LSP with signal type as VC-11, it can't establish this LSP ? STM-16 has 16 branches, if each of these branches support different min. reservable bandwidth then does this mean it will be having 16 interface switching capability TLVs ? Is this a deviation from SDH/SONET where u can't assume that if minimum reservable bandwidth is say VC-2 and max. reservable bandwidth is say STM-1, it doesn't mean that all the signals viz. VC-4, VC-12, VC-3 etc.(i.e. that fall under STM-1 and VC-2) are supported ? Please correct me if I am wrong. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp