Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 15:00:03 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B14B@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Yakov Rekhter'" Cc: "'Jonathan Lang'" , "'Martin Dubuc'" , Michiel van Everdingen , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Fri, 31 May 2002 14:58:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Of course I comment on text I don't read :-). I get down load the updates check the abstract, TOC intro for changes and if I don't see something that impacts me there I don't dig into the details looking for new features... But I'm still confused about whether "automatic discovery" is in the spec. Michiel seems to have done a lot more complete recent scrubing and can't find it. It's standard in OSPF and IS-IS to be able to discover neighbors. With the OIF UNI we added this for SONET/SDH in the "in-band" case. I'm assuming any vendor that has deployed a fair amount of optical control plane enable equipment has put in discovery to avoid the need to "configure" TE links. The carriers I know "wouldn't leave home without it". Since it wasn't in LMP, this was taken up by ITU for the SDH/G.709 case with the work in progress on G.7714.1. One issue does cross my mind on control channel management is why not use something like SCTP? It seems to have nice redundancy capabilities, assured delivery, etc... A portion of its functionality could just be used. Greg *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Friday, May 31, 2002 2:29 PM To: Bernstein, Greg Cc: 'Jonathan Lang'; 'Martin Dubuc'; Michiel van Everdingen; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Greg, > Hmm, Jonathan it seems the spec never stops changing. It seems to have been > a "one size fits all" as long as its my flavor of PXC. Am I supposed to > implement just part of the spec in the case of SONET/SDH? Yes. > How does a carrier specify this? I am sure carriers can figure this out. After all, LMP is not the only protocol that has optional parts. > It seems better if it was broken up in multiple specs or you get very > specific concerning the technology you are addressing. It > doesn't make sense for a technology that already provides fault management > and performance monitoring to repeat this functionality. I certainly agree with the point you made in the last sentence. And that is why fault management functionality in LMP is optional. > So you're now telling me that after constantly fighting me to keep "true > discovery" out of LMP, you've now put it in? Can you update the > introduction to the draft to reflect this. Most of us don't have the time > to read through the details after the intro portion says it > doesn't have the functionality we desire. Are you trying to say that you commented on the text that you didn't even read ? Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 14:48:47 -0700 Message-ID: <58BE468BAC66D511AFE6000347251A2D012D77B1@morpheus.lanterncom.com> From: Anoop Ghanwani To: ccamp@ops.ietf.org Subject: A question on draft-ietf-ccamp-gmpls-architecture-02.txt Date: Fri, 31 May 2002 14:37:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I'm referring to Section 3.2 of the document: .. 2. Layer-2 Switch Capable (L2SC) interfaces: Interfaces that recognize frame/cell boundaries and can forward data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that forward data based on the content of the MAC header and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI. .. Why is an Ethernet bridge of any interest to GMPLS? There's nothing in the bridged frame that can be used to control forwarding using GMPLS. Would appreciate it if any of the authors could shed some light on this. Thanks, -Anoop Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 14:30:19 -0700 Message-Id: <200205312128.g4VLSrm95262@merlot.juniper.net> To: "Bernstein, Greg" cc: "'Jonathan Lang'" , "'Martin Dubuc'" , Michiel van Everdingen , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38494.1022880533.1@juniper.net> Date: Fri, 31 May 2002 14:28:53 -0700 From: Yakov Rekhter Greg, > Hmm, Jonathan it seems the spec never stops changing. It seems to have been > a "one size fits all" as long as its my flavor of PXC. Am I supposed to > implement just part of the spec in the case of SONET/SDH? Yes. > How does a carrier specify this? I am sure carriers can figure this out. After all, LMP is not the only protocol that has optional parts. > It seems better if it was broken up in multiple specs or you get very > specific concerning the technology you are addressing. It > doesn't make sense for a technology that already provides fault management > and performance monitoring to repeat this functionality. I certainly agree with the point you made in the last sentence. And that is why fault management functionality in LMP is optional. > So you're now telling me that after constantly fighting me to keep "true > discovery" out of LMP, you've now put it in? Can you update the > introduction to the draft to reflect this. Most of us don't have the time > to read through the details after the intro portion says it > doesn't have the functionality we desire. Are you trying to say that you commented on the text that you didn't even read ? Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 13:42:52 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B149@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Jonathan Lang'" , "'Martin Dubuc'" , Michiel van Everdingen , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Fri, 31 May 2002 13:40:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hmm, Jonathan it seems the spec never stops changing. It seems to have been a "one size fits all" as long as its my flavor of PXC. Am I supposed to implement just part of the spec in the case of SONET/SDH? How does a carrier specify this? It seems better if it was broken up in multiple specs or you get very specific concerning the technology you are addressing. It doesn't make sense for a technology that already provides fault management and performance monitoring to repeat this functionality. So you're now telling me that after constantly fighting me to keep "true discovery" out of LMP, you've now put it in? Can you update the introduction to the draft to reflect this. Most of us don't have the time to read through the details after the intro portion says it doesn't have the functionality we desire. Greg *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Friday, May 31, 2002 12:15 PM To: Bernstein, Greg; 'Martin Dubuc'; Michiel van Everdingen; Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Friday, May 31, 2002 10:14 AM > To: 'Martin Dubuc'; Michiel van Everdingen; Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: RE: LMP & neighbor discovery > > > Martin, I thought the latest LMP draft is very clear concerning LMP functionality. > Link verification is included. This assumes a control channel has already > been established between the nodes. The definition of "discovery" that > we've been working with (and also in G.7714) has the equipment automatically > discovering its neighbor without any control channel configuration. G.7714 talks about physical media discovery (i.e., learning the data port mapping) and control entity discovery (i.e., learning the address of the control entity). LMP provides physical media discovery with the assumption that the control entity is known. For the special case of in-band signaling, LMP also provides control entity discovery. If you would like to further extend the functionality, I suggest you write an ID on Control Channel Address Auto Discovery. > > We added/modified to LMP in the OIF UNI to give it discovery functionality > in the SONET/SDH case. LMP per the draft does not include this functionality. you should read the LMP spec. > > The main problem I still see with LMP is that it claims to be applicable to > a wide variety of technologies when in fact it is aimed at PXCs. For > example, its fault management capabilities are much slower and less reliable > than those in either SDH/SONET or G.709 which use extremely fast dedicated > mechanisms such as AIS and RDI signals for fault isolation and use other > measures of signal degradation rather than just "loss of light" (LOL). LMP can use technology specific (SDH/SONET/G.709) fault management procedures if they're present. In the event that they are absent, LMP provides such a mechanism. The LMP-based fault management procedures are optional. -Jonathan > > Most routers with optical interfaces should be able to support the basic > SONET/SDH Section or line layer AIS/RDI signals and fault detection > capabilities (such as section layer LOF). It seems the need for most of LMP > really comes from the lack of capabilities of the current crop of PXCs. > > Greg B. > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > > -----Original Message----- > From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] > Sent: Thursday, May 30, 2002 6:41 AM > To: Michiel van Everdingen; Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: RE: LMP & neighbor discovery > > > Michiel, > > Neighbor discovery, through use of appropriate control > channel management > (see Section 3 and 9), is supported with the current LMP > draft. There is no > need for any extension to the draft for this purpose. > > Regards, > > Martin > > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Thursday, May 30, 2002 7:31 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: LMP & neighbor discovery > > > Hello Kireeti, > > Thanks for your answer. > > > Reading over the threads again, it appears that "neighbor discovery" > > may be a useful function. > > Agreed. Non manual, fully automatic "neighbor discovery" is > an important > requirement as also stated in ITU-T G.7714.1. > > Including neighbor discovery in LMP would also remove the confusion > that currently appears to exist on whether or not LMP does specify > neighbor discovery. In > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html > Jonathan seems to state that LMP *does* include neighbor discovery. > However, this type of neighbor discovery is rather manual and not > in line with ITU-T G.7714.1. > > > > However, LMP is a *link* management protocol, > > where neighbors are configured (at least as a starting point), and > > *links* are discovered, and link properties correlated. > > I guess you are here referring to TE-links as opposed to dataLinks ? > > The proposed addition to LMP discovers dataLinks. I don't see it as > a problem that subsequent link property correlation groups all > dataLinks together and correlates the full TE-link in one IP message. > Compared to correlating individual dataLinks, correlating a full > TE-link has advantages performance wise. > > Why do you see it as a problem that the described neighbor discovery > procedure discovers the neighbor on an individual dataLink ? For > example, the existing LMP function "Fault Management" is built on > discovering the faults on individual dataLinks. > > > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > > think that neighbor management is a useful function, then they can > > write a draft, perhaps building on LMP, and we'll judge WG interest > > in this function. > > As you might have noted, my neighbor discovery proposal does *not* > include a *single* IP message. It is simply making use of an existing > function in the transport layer: reading the access point identifier. > > In my mind, it would therefore be strange to write a separate ID to > define this neighbor discovery function. > > Moreover, this new ID would indeed be heavily building on LMP > to provide > the subsequent link correlation. > > Could you please let me know what you see as advantages of defining > neighbor discovery in a separate ID ? > > > > To my mind (as implementor), the notion of control channel > seems simple > > enough; a control network is one instantiation of a control channel. > > This statement seems to be in conflict with an earlier statement that > a "control channel" runs on top of an existing "control network" (it > is a "routed control channel"). > > Related to your assessment of "control channels" being simple: did you > include in that assessment the need to carefully provision the timers > related to RSVP-TE hellos, LMP control channel hellos and the "control > network" IGP hellos ? > > You might want to re-read > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > > > > If this proposal is not in line with your view, I'm > looking forward > > > to a continued discussion on the three indicated email threads ! > > > > Excellent idea! As I said, if there is interest, the best > way to proceed > > is to follow up with an ID. > > In my mind there are two ways to proceed: > 1. Don't accept the proposed changes in LMP. > 2. Accept the proposed changes in LMP. > > If option (1) is chosen, I would at least like to have within the LMP > draft: > - Clarification on "control channel" (thread "Question on LMP") > - Clarification on when the link verification procedure is > applicable (thread "applicability of LMP's verify procedure") > - Clarification on whether or not LMP includes neighbor > discovery. > > Of course my preference would be option (2). > > > Best regards, > > Michiel > > > > Kireeti Kompella wrote: > > > > On Thu, 23 May 2002, Michiel van Everdingen wrote: > > > > > Hello Jonathan, Kireeti, Ron, > > > > > > Judging on the information in three e-mail threads (first > and last email > > > indicated): > > > - Question on LMP > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > > - LMP & neighbor discovery > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > > - applicability of LMP's verify procedure > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > > > > I would propose to make the following modifications to > the LMP draft, > > > version 03: > > > - Include a section on neighbor discovery > > > Details can be found in > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html > > > > Reading over the threads again, it appears that "neighbor discovery" > > may be a useful function. However, LMP is a *link* > management protocol, > > where neighbors are configured (at least as a starting point), and > > *links* are discovered, and link properties correlated. > > > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > > think that neighbor management is a useful function, then they can > > write a draft, perhaps building on LMP, and we'll judge WG interest > > in this function. > > > > > - Remove the concept of "control channel" and accept that > signalling > > > messages are carried over the "control network". > > > > To my mind (as implementor), the notion of control channel > seems simple > > enough; a control network is one instantiation of a control channel. > > > > > If this proposal is not in line with your view, I'm > looking forward > > > to a continued discussion on the three indicated email threads ! > > > > Excellent idea! As I said, if there is interest, the best > way to proceed > > is to follow up with an ID. > > > > Kireeti. > > -- > +------------------------------------------------------------------+ > | Michiel van Everdingen | > | Systems Engineer | > | Lucent Technologies - Optical Networking Group | > | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | > | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | > | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 12:25:03 -0700 Message-ID: From: Jonathan Lang To: "'Bernstein, Greg'" , 'Martin Dubuc' , Michiel van Everdingen , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Fri, 31 May 2002 12:15:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Friday, May 31, 2002 10:14 AM > To: 'Martin Dubuc'; Michiel van Everdingen; Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: RE: LMP & neighbor discovery > > > Martin, I thought the latest LMP draft is very clear concerning LMP functionality. > Link verification is included. This assumes a control channel has already > been established between the nodes. The definition of "discovery" that > we've been working with (and also in G.7714) has the equipment automatically > discovering its neighbor without any control channel configuration. G.7714 talks about physical media discovery (i.e., learning the data port mapping) and control entity discovery (i.e., learning the address of the control entity). LMP provides physical media discovery with the assumption that the control entity is known. For the special case of in-band signaling, LMP also provides control entity discovery. If you would like to further extend the functionality, I suggest you write an ID on Control Channel Address Auto Discovery. > > We added/modified to LMP in the OIF UNI to give it discovery functionality > in the SONET/SDH case. LMP per the draft does not include this functionality. you should read the LMP spec. > > The main problem I still see with LMP is that it claims to be applicable to > a wide variety of technologies when in fact it is aimed at PXCs. For > example, its fault management capabilities are much slower and less reliable > than those in either SDH/SONET or G.709 which use extremely fast dedicated > mechanisms such as AIS and RDI signals for fault isolation and use other > measures of signal degradation rather than just "loss of light" (LOL). LMP can use technology specific (SDH/SONET/G.709) fault management procedures if they're present. In the event that they are absent, LMP provides such a mechanism. The LMP-based fault management procedures are optional. -Jonathan > > Most routers with optical interfaces should be able to support the basic > SONET/SDH Section or line layer AIS/RDI signals and fault detection > capabilities (such as section layer LOF). It seems the need for most of LMP > really comes from the lack of capabilities of the current crop of PXCs. > > Greg B. > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > > -----Original Message----- > From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] > Sent: Thursday, May 30, 2002 6:41 AM > To: Michiel van Everdingen; Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: RE: LMP & neighbor discovery > > > Michiel, > > Neighbor discovery, through use of appropriate control > channel management > (see Section 3 and 9), is supported with the current LMP > draft. There is no > need for any extension to the draft for this purpose. > > Regards, > > Martin > > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Thursday, May 30, 2002 7:31 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: LMP & neighbor discovery > > > Hello Kireeti, > > Thanks for your answer. > > > Reading over the threads again, it appears that "neighbor discovery" > > may be a useful function. > > Agreed. Non manual, fully automatic "neighbor discovery" is > an important > requirement as also stated in ITU-T G.7714.1. > > Including neighbor discovery in LMP would also remove the confusion > that currently appears to exist on whether or not LMP does specify > neighbor discovery. In > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html > Jonathan seems to state that LMP *does* include neighbor discovery. > However, this type of neighbor discovery is rather manual and not > in line with ITU-T G.7714.1. > > > > However, LMP is a *link* management protocol, > > where neighbors are configured (at least as a starting point), and > > *links* are discovered, and link properties correlated. > > I guess you are here referring to TE-links as opposed to dataLinks ? > > The proposed addition to LMP discovers dataLinks. I don't see it as > a problem that subsequent link property correlation groups all > dataLinks together and correlates the full TE-link in one IP message. > Compared to correlating individual dataLinks, correlating a full > TE-link has advantages performance wise. > > Why do you see it as a problem that the described neighbor discovery > procedure discovers the neighbor on an individual dataLink ? For > example, the existing LMP function "Fault Management" is built on > discovering the faults on individual dataLinks. > > > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > > think that neighbor management is a useful function, then they can > > write a draft, perhaps building on LMP, and we'll judge WG interest > > in this function. > > As you might have noted, my neighbor discovery proposal does *not* > include a *single* IP message. It is simply making use of an existing > function in the transport layer: reading the access point identifier. > > In my mind, it would therefore be strange to write a separate ID to > define this neighbor discovery function. > > Moreover, this new ID would indeed be heavily building on LMP > to provide > the subsequent link correlation. > > Could you please let me know what you see as advantages of defining > neighbor discovery in a separate ID ? > > > > To my mind (as implementor), the notion of control channel > seems simple > > enough; a control network is one instantiation of a control channel. > > This statement seems to be in conflict with an earlier statement that > a "control channel" runs on top of an existing "control network" (it > is a "routed control channel"). > > Related to your assessment of "control channels" being simple: did you > include in that assessment the need to carefully provision the timers > related to RSVP-TE hellos, LMP control channel hellos and the "control > network" IGP hellos ? > > You might want to re-read > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > > > > If this proposal is not in line with your view, I'm > looking forward > > > to a continued discussion on the three indicated email threads ! > > > > Excellent idea! As I said, if there is interest, the best > way to proceed > > is to follow up with an ID. > > In my mind there are two ways to proceed: > 1. Don't accept the proposed changes in LMP. > 2. Accept the proposed changes in LMP. > > If option (1) is chosen, I would at least like to have within the LMP > draft: > - Clarification on "control channel" (thread "Question on LMP") > - Clarification on when the link verification procedure is > applicable (thread "applicability of LMP's verify procedure") > - Clarification on whether or not LMP includes neighbor > discovery. > > Of course my preference would be option (2). > > > Best regards, > > Michiel > > > > Kireeti Kompella wrote: > > > > On Thu, 23 May 2002, Michiel van Everdingen wrote: > > > > > Hello Jonathan, Kireeti, Ron, > > > > > > Judging on the information in three e-mail threads (first > and last email > > > indicated): > > > - Question on LMP > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > > - LMP & neighbor discovery > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > > - applicability of LMP's verify procedure > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > > > > I would propose to make the following modifications to > the LMP draft, > > > version 03: > > > - Include a section on neighbor discovery > > > Details can be found in > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html > > > > Reading over the threads again, it appears that "neighbor discovery" > > may be a useful function. However, LMP is a *link* > management protocol, > > where neighbors are configured (at least as a starting point), and > > *links* are discovered, and link properties correlated. > > > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > > think that neighbor management is a useful function, then they can > > write a draft, perhaps building on LMP, and we'll judge WG interest > > in this function. > > > > > - Remove the concept of "control channel" and accept that > signalling > > > messages are carried over the "control network". > > > > To my mind (as implementor), the notion of control channel > seems simple > > enough; a control network is one instantiation of a control channel. > > > > > If this proposal is not in line with your view, I'm > looking forward > > > to a continued discussion on the three indicated email threads ! > > > > Excellent idea! As I said, if there is interest, the best > way to proceed > > is to follow up with an ID. > > > > Kireeti. > > -- > +------------------------------------------------------------------+ > | Michiel van Everdingen | > | Systems Engineer | > | Lucent Technologies - Optical Networking Group | > | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | > | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | > | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 11:48:33 -0700 Message-ID: <3CF7C542.70F8E119@alcatel.be> Date: Fri, 31 May 2002 20:47:30 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: "Bernstein, Greg" Cc: "'Martin Dubuc'" , Michiel van Everdingen , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii as said before OIF UNI and LMP per draft do not fundamentally differ from this "discovery" perspective - i invite you to re- read section 8.5.8 and 8.5.9 of this specification both are related to the Config/Ack/Nack message exchange - while link verification (per definition) relies on these (or this) previous exchange(s) except if ipcc is already available. if the corresponding "mechanism" (we speak then upon link discovery) was possible without the Config message exchange then the requirement of G.7714 would have been achieved (i.e. independence of the "control channel" signalling transport mechanism and (neighbor) link discovery) that G.7714 has implicitly translated to a dependence (i should say a glue) between the "transport" and "discovery", this is the reason why some people on this mailing list come always with the terminology of itu-t functional specifications; thus the only thing to allude from this perspective, is to define the "glue" in LMP between the discovery function and the transmission technology to which it applies; therefore i suggest rather to clarify the glue for each of these technologies in other specific as we did for signalling for instance. - dimitri. "Bernstein, Greg" wrote: > > Martin, I thought the latest LMP draft is very clear concerning LMP > functionality. > Link verification is included. This assumes a control channel has already > been established between the nodes. The definition of "discovery" that > we've been working with (and also in G.7714) has the equipment automatically > discovering its neighbor without any control channel configuration. > > We added/modified to LMP in the OIF UNI to give it discovery functionality > in the SONET/SDH case. LMP per the draft does not include this > functionality. > > The main problem I still see with LMP is that it claims to be applicable to > a wide variety of technologies when in fact it is aimed at PXCs. For > example, its fault management capabilities are much slower and less reliable > than those in either SDH/SONET or G.709 which use extremely fast dedicated > mechanisms such as AIS and RDI signals for fault isolation and use other > measures of signal degradation rather than just "loss of light" (LOL). > > Most routers with optical interfaces should be able to support the basic > SONET/SDH Section or line layer AIS/RDI signals and fault detection > capabilities (such as section layer LOF). It seems the need for most of LMP > really comes from the lack of capabilities of the current crop of PXCs. > > Greg B. > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > -----Original Message----- > From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] > Sent: Thursday, May 30, 2002 6:41 AM > To: Michiel van Everdingen; Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: RE: LMP & neighbor discovery > > Michiel, > > Neighbor discovery, through use of appropriate control channel management > (see Section 3 and 9), is supported with the current LMP draft. There is no > need for any extension to the draft for this purpose. > > Regards, > > Martin > > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Thursday, May 30, 2002 7:31 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: LMP & neighbor discovery > > Hello Kireeti, > > Thanks for your answer. > > > Reading over the threads again, it appears that "neighbor discovery" > > may be a useful function. > > Agreed. Non manual, fully automatic "neighbor discovery" is an important > requirement as also stated in ITU-T G.7714.1. > > Including neighbor discovery in LMP would also remove the confusion > that currently appears to exist on whether or not LMP does specify > neighbor discovery. In > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html > Jonathan seems to state that LMP *does* include neighbor discovery. > However, this type of neighbor discovery is rather manual and not > in line with ITU-T G.7714.1. > > > However, LMP is a *link* management protocol, > > where neighbors are configured (at least as a starting point), and > > *links* are discovered, and link properties correlated. > > I guess you are here referring to TE-links as opposed to dataLinks ? > > The proposed addition to LMP discovers dataLinks. I don't see it as > a problem that subsequent link property correlation groups all > dataLinks together and correlates the full TE-link in one IP message. > Compared to correlating individual dataLinks, correlating a full > TE-link has advantages performance wise. > > Why do you see it as a problem that the described neighbor discovery > procedure discovers the neighbor on an individual dataLink ? For > example, the existing LMP function "Fault Management" is built on > discovering the faults on individual dataLinks. > > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > > think that neighbor management is a useful function, then they can > > write a draft, perhaps building on LMP, and we'll judge WG interest > > in this function. > > As you might have noted, my neighbor discovery proposal does *not* > include a *single* IP message. It is simply making use of an existing > function in the transport layer: reading the access point identifier. > > In my mind, it would therefore be strange to write a separate ID to > define this neighbor discovery function. > > Moreover, this new ID would indeed be heavily building on LMP to provide > the subsequent link correlation. > > Could you please let me know what you see as advantages of defining > neighbor discovery in a separate ID ? > > > To my mind (as implementor), the notion of control channel seems simple > > enough; a control network is one instantiation of a control channel. > > This statement seems to be in conflict with an earlier statement that > a "control channel" runs on top of an existing "control network" (it > is a "routed control channel"). > > Related to your assessment of "control channels" being simple: did you > include in that assessment the need to carefully provision the timers > related to RSVP-TE hellos, LMP control channel hellos and the "control > network" IGP hellos ? > > You might want to re-read > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > > > If this proposal is not in line with your view, I'm looking forward > > > to a continued discussion on the three indicated email threads ! > > > > Excellent idea! As I said, if there is interest, the best way to proceed > > is to follow up with an ID. > > In my mind there are two ways to proceed: > 1. Don't accept the proposed changes in LMP. > 2. Accept the proposed changes in LMP. > > If option (1) is chosen, I would at least like to have within the LMP > draft: > - Clarification on "control channel" (thread "Question on LMP") > - Clarification on when the link verification procedure is > applicable (thread "applicability of LMP's verify procedure") > - Clarification on whether or not LMP includes neighbor > discovery. > > Of course my preference would be option (2). > > Best regards, > > Michiel > > Kireeti Kompella wrote: > > > > On Thu, 23 May 2002, Michiel van Everdingen wrote: > > > > > Hello Jonathan, Kireeti, Ron, > > > > > > Judging on the information in three e-mail threads (first and last email > > > indicated): > > > - Question on LMP > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > > - LMP & neighbor discovery > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > > - applicability of LMP's verify procedure > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > > > > I would propose to make the following modifications to the LMP draft, > > > version 03: > > > - Include a section on neighbor discovery > > > Details can be found in > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html > > > > Reading over the threads again, it appears that "neighbor discovery" > > may be a useful function. However, LMP is a *link* management protocol, > > where neighbors are configured (at least as a starting point), and > > *links* are discovered, and link properties correlated. > > > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > > think that neighbor management is a useful function, then they can > > write a draft, perhaps building on LMP, and we'll judge WG interest > > in this function. > > > > > - Remove the concept of "control channel" and accept that signalling > > > messages are carried over the "control network". > > > > To my mind (as implementor), the notion of control channel seems simple > > enough; a control network is one instantiation of a control channel. > > > > > If this proposal is not in line with your view, I'm looking forward > > > to a continued discussion on the three indicated email threads ! > > > > Excellent idea! As I said, if there is interest, the best way to proceed > > is to follow up with an ID. > > > > Kireeti. > > -- > +------------------------------------------------------------------+ > | Michiel van Everdingen | > | Systems Engineer | > | Lucent Technologies - Optical Networking Group | > | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | > | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | > | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 11:02:54 -0700 Message-ID: <3CF7BA6E.6FB68E86@nayna.com> Date: Fri, 31 May 2002 11:01:18 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: v.sharma@ieee.org CC: Zhi-Wei Lin , Suresh Katukam , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vishal: I agree that representation, path computation and path setup are three problems that we need to solve here. Please refer to the paper I refered to address the first two problems. In the GMPLS P&R design team we are looking at some of the issues related to the path setup. In the current version we are not looking at rings, which we will do later if there is clear consensus to address them. Extra traffic is one of the subjects we will be addressing (again for linear topologies) in the first release. - sudheer Vishal Sharma wrote: > Sudheer, > > While I agree that representing nodes/domains/rings etc. is an important > problem, I think there are two issues being mixed below. > > One is the problem of the initial configuration of the UPSR/BLSR ring, > which is clearly (today) an NMS/EMS operation. > > The other is of dynamically setting up trails on the ring. It is this > latter problem that falls under the purview of an automated control > plane, and is the one being discussed. This will involve the control plane, > and the issue there, as Suresh pointed out, is how does one deal with > mixed mesh-ring networks, similar, for example, to the topology drawn by > Nik Langrind. > > In that case, I don't think the GMPLS specifications are complete enough > to enable one to accomplish path setup. There are several issues > there, including the difficulty of deciding exactly the process by > which path setup on rings will be handled, and how the various items > that Zhi outlined in an earlier email (ring/span switching supported?, > extra traffic supported? etc.) will be handled. > > I see the issue of representation as somewhat tied to how one does > path setup above. That will dictate how the rings and their nodes/links > should be represented in the routing protocols, and how path computation > will take them into account. > > Some of these issues were discussed by us in a draft a while back > http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx > t > > -Vishal > > > -----Original Message----- > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > Sent: Friday, May 31, 2002 10:32 AM > > To: v.sharma@ieee.org > > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg; > > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi All: > > > > This is very interesting discussion. > > > > Some of the people on this discussion list already looked > > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt > > for more information. > > > > Here is my opinion: > > > > Transport networks provide their own protection mechanisms such > > as the rings under discussion. As others pointed out it makes good > > sense to use them for faster restoration times. These rings may > > be created through NMS/EMS - this is not a concern to the control > > plane. > > > > The real problem is how to represent this ring topology in the control > > plane for the path computation. Well one proposal as mentioned by > > Zhi was to represent by a logical node with node capability being > > "highly protected node" (inheriting the property of the ring). Another > > way to see this, as mentioned in the srg draft is to represent by > > point-to-multi point links with the exit points to the ring as the > > terminating points of the links and define the same "highly protected" > > property on the links (unlike on the node). Now that we have the > > links and link property we can use it in the path computation. > > Once path is computed it is the nodes, which are on the ring and > > participate in the control plane, to make a connection between > > the end points. Please refer to the above draft or > > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf > > > > - sudheer > > > > > > > > Vishal Sharma wrote: > > > > > Zhi and all, > > > > > > Great discussion! I'm glad we're finally discussing some of these > > > issues, and highlighting that mix inherent ring protection with > > > the control domain mechanisms is non-trivial. > > > > > > Comments in-line. > > > > > > -Vishal > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > > Behalf Of Zhi-Wei Lin > > > > Sent: Thursday, May 30, 2002 11:54 AM > > > > To: Suresh Katukam > > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > > > > mpls@UU. NET (E-mail) > > > > Subject: Re: Sonet Ring provisioning > > > > > > > > > > > > Hi Suresh, > > > > > > > > Yes agree this is very complex if you try to create too much > > > > dependencies between control plane and transport plane protection > > > > interactions. That is why my simplistic approach: > > > > > > > > * Control plane sees the entire ring as offering "highly > > available" > > > > connections > > > > * Control plane sets up a single connection across this ring > > > > "sub-network" (if you think this about this, the entire ring can > > > > actually be treated by a control plane controller as a > > single node > > > > where the BLSR ring nodes may be thought of as > > aggregate ports on > > > > the single node) > > > > * The ring sub-network, by virtue of providing the protection and > > > > knowing *exactly* how protection is provided can set up the > > > > protection channel automatically (but control plane > > need not know > > > > this as it is irrelevant to the control plane -- it > > only needs to > > > > know that the single connection is protected) > > > > > > What mechanism will the ring use to setup the internal > > protection channel? > > > > > > Will it require EMS/NMS intervention, as proposed on this > > thread earlier, > > > or will there be another sequence of control plane messages (initiated > > > internal to the ring) to set this path up. The latter would be > > prefereable > > > if the objective is to have fully-automated path setup (otherwise, we > > > have EMS/NMS intervention for the ring), but it does complicate the > > > control plane protocols (since a new sequence of setup steps may > > > have to be initiated internal to each ring on the path of the end-to-end > > > circuit/trail that is being setup. > > > > > > -Vishal > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 10:49:55 -0700 Reply-To: From: "Vishal Sharma" To: "Sudheer Dharanikota" Cc: "Zhi-Wei Lin" , "Suresh Katukam" , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" Subject: RE: Sonet Ring provisioning Date: Fri, 31 May 2002 10:54:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sudheer, While I agree that representing nodes/domains/rings etc. is an important problem, I think there are two issues being mixed below. One is the problem of the initial configuration of the UPSR/BLSR ring, which is clearly (today) an NMS/EMS operation. The other is of dynamically setting up trails on the ring. It is this latter problem that falls under the purview of an automated control plane, and is the one being discussed. This will involve the control plane, and the issue there, as Suresh pointed out, is how does one deal with mixed mesh-ring networks, similar, for example, to the topology drawn by Nik Langrind. In that case, I don't think the GMPLS specifications are complete enough to enable one to accomplish path setup. There are several issues there, including the difficulty of deciding exactly the process by which path setup on rings will be handled, and how the various items that Zhi outlined in an earlier email (ring/span switching supported?, extra traffic supported? etc.) will be handled. I see the issue of representation as somewhat tied to how one does path setup above. That will dictate how the rings and their nodes/links should be represented in the routing protocols, and how path computation will take them into account. Some of these issues were discussed by us in a draft a while back http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx t -Vishal > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Friday, May 31, 2002 10:32 AM > To: v.sharma@ieee.org > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg; > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi All: > > This is very interesting discussion. > > Some of the people on this discussion list already looked > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt > for more information. > > Here is my opinion: > > Transport networks provide their own protection mechanisms such > as the rings under discussion. As others pointed out it makes good > sense to use them for faster restoration times. These rings may > be created through NMS/EMS - this is not a concern to the control > plane. > > The real problem is how to represent this ring topology in the control > plane for the path computation. Well one proposal as mentioned by > Zhi was to represent by a logical node with node capability being > "highly protected node" (inheriting the property of the ring). Another > way to see this, as mentioned in the srg draft is to represent by > point-to-multi point links with the exit points to the ring as the > terminating points of the links and define the same "highly protected" > property on the links (unlike on the node). Now that we have the > links and link property we can use it in the path computation. > Once path is computed it is the nodes, which are on the ring and > participate in the control plane, to make a connection between > the end points. Please refer to the above draft or > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf > > - sudheer > > > > Vishal Sharma wrote: > > > Zhi and all, > > > > Great discussion! I'm glad we're finally discussing some of these > > issues, and highlighting that mix inherent ring protection with > > the control domain mechanisms is non-trivial. > > > > Comments in-line. > > > > -Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Zhi-Wei Lin > > > Sent: Thursday, May 30, 2002 11:54 AM > > > To: Suresh Katukam > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > > > mpls@UU. NET (E-mail) > > > Subject: Re: Sonet Ring provisioning > > > > > > > > > Hi Suresh, > > > > > > Yes agree this is very complex if you try to create too much > > > dependencies between control plane and transport plane protection > > > interactions. That is why my simplistic approach: > > > > > > * Control plane sees the entire ring as offering "highly > available" > > > connections > > > * Control plane sets up a single connection across this ring > > > "sub-network" (if you think this about this, the entire ring can > > > actually be treated by a control plane controller as a > single node > > > where the BLSR ring nodes may be thought of as > aggregate ports on > > > the single node) > > > * The ring sub-network, by virtue of providing the protection and > > > knowing *exactly* how protection is provided can set up the > > > protection channel automatically (but control plane > need not know > > > this as it is irrelevant to the control plane -- it > only needs to > > > know that the single connection is protected) > > > > What mechanism will the ring use to setup the internal > protection channel? > > > > Will it require EMS/NMS intervention, as proposed on this > thread earlier, > > or will there be another sequence of control plane messages (initiated > > internal to the ring) to set this path up. The latter would be > prefereable > > if the objective is to have fully-automated path setup (otherwise, we > > have EMS/NMS intervention for the ring), but it does complicate the > > control plane protocols (since a new sequence of setup steps may > > have to be initiated internal to each ring on the path of the end-to-end > > circuit/trail that is being setup. > > > > -Vishal > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 10:35:07 -0700 Message-ID: <3CF7B429.F861B66A@cisco.com> Date: Fri, 31 May 2002 10:34:33 -0700 From: Suresh Katukam Organization: Cisco Systems MIME-Version: 1.0 To: v.sharma@ieee.org CC: Zhi-Wei Lin , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Comments in-line.. > > Hi Suresh, > > > > Yes agree this is very complex if you try to create too much > > dependencies between control plane and transport plane protection > > interactions. That is why my simplistic approach: > > > > * Control plane sees the entire ring as offering "highly available" > > connections > > * Control plane sets up a single connection across this ring > > "sub-network" (if you think this about this, the entire ring can > > actually be treated by a control plane controller as a single node > > where the BLSR ring nodes may be thought of as aggregate ports on > > the single node) > > * The ring sub-network, by virtue of providing the protection and > > knowing *exactly* how protection is provided can set up the > > protection channel automatically (but control plane need not know > > this as it is irrelevant to the control plane -- it only needs to > > know that the single connection is protected) > > What mechanism will the ring use to setup the internal protection channel? > > Will it require EMS/NMS intervention, as proposed on this thread earlier, > or will there be another sequence of control plane messages (initiated > internal to the ring) to set this path up. The latter would be prefereable > if the objective is to have fully-automated path setup (otherwise, we > have EMS/NMS intervention for the ring), but it does complicate the > control plane protocols (since a new sequence of setup steps may > have to be initiated internal to each ring on the path of the end-to-end > circuit/trail that is being setup. Yes, this is where the most of the problems are. I was referring to this where GMPLS based messages will be used to setup a path around the ring. I was trying to bring up the issues that may come up during the path setup in the ring. Zhi and Maartin, Please let us know your thoughts on this. Thanks, Suresh > > -Vishal > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 10:33:30 -0700 Message-ID: <3CF7B381.C43BF07E@nayna.com> Date: Fri, 31 May 2002 10:31:45 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: v.sharma@ieee.org CC: Zhi-Wei Lin , Suresh Katukam , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All: This is very interesting discussion. Some of the people on this discussion list already looked at some of these issues. Please refer to draft-many-ccamp-srg-01.txt for more information. Here is my opinion: Transport networks provide their own protection mechanisms such as the rings under discussion. As others pointed out it makes good sense to use them for faster restoration times. These rings may be created through NMS/EMS - this is not a concern to the control plane. The real problem is how to represent this ring topology in the control plane for the path computation. Well one proposal as mentioned by Zhi was to represent by a logical node with node capability being "highly protected node" (inheriting the property of the ring). Another way to see this, as mentioned in the srg draft is to represent by point-to-multi point links with the exit points to the ring as the terminating points of the links and define the same "highly protected" property on the links (unlike on the node). Now that we have the links and link property we can use it in the path computation. Once path is computed it is the nodes, which are on the ring and participate in the control plane, to make a connection between the end points. Please refer to the above draft or http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf - sudheer Vishal Sharma wrote: > Zhi and all, > > Great discussion! I'm glad we're finally discussing some of these > issues, and highlighting that mix inherent ring protection with > the control domain mechanisms is non-trivial. > > Comments in-line. > > -Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Zhi-Wei Lin > > Sent: Thursday, May 30, 2002 11:54 AM > > To: Suresh Katukam > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > > mpls@UU. NET (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi Suresh, > > > > Yes agree this is very complex if you try to create too much > > dependencies between control plane and transport plane protection > > interactions. That is why my simplistic approach: > > > > * Control plane sees the entire ring as offering "highly available" > > connections > > * Control plane sets up a single connection across this ring > > "sub-network" (if you think this about this, the entire ring can > > actually be treated by a control plane controller as a single node > > where the BLSR ring nodes may be thought of as aggregate ports on > > the single node) > > * The ring sub-network, by virtue of providing the protection and > > knowing *exactly* how protection is provided can set up the > > protection channel automatically (but control plane need not know > > this as it is irrelevant to the control plane -- it only needs to > > know that the single connection is protected) > > What mechanism will the ring use to setup the internal protection channel? > > Will it require EMS/NMS intervention, as proposed on this thread earlier, > or will there be another sequence of control plane messages (initiated > internal to the ring) to set this path up. The latter would be prefereable > if the objective is to have fully-automated path setup (otherwise, we > have EMS/NMS intervention for the ring), but it does complicate the > control plane protocols (since a new sequence of setup steps may > have to be initiated internal to each ring on the path of the end-to-end > circuit/trail that is being setup. > > -Vishal > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 10:14:55 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B147@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Martin Dubuc'" , Michiel van Everdingen , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Date: Fri, 31 May 2002 10:13:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Martin, I thought the latest LMP draft is very clear concerning LMP functionality. Link verification is included. This assumes a control channel has already been established between the nodes. The definition of "discovery" that we've been working with (and also in G.7714) has the equipment automatically discovering its neighbor without any control channel configuration. We added/modified to LMP in the OIF UNI to give it discovery functionality in the SONET/SDH case. LMP per the draft does not include this functionality. The main problem I still see with LMP is that it claims to be applicable to a wide variety of technologies when in fact it is aimed at PXCs. For example, its fault management capabilities are much slower and less reliable than those in either SDH/SONET or G.709 which use extremely fast dedicated mechanisms such as AIS and RDI signals for fault isolation and use other measures of signal degradation rather than just "loss of light" (LOL). Most routers with optical interfaces should be able to support the basic SONET/SDH Section or line layer AIS/RDI signals and fault detection capabilities (such as section layer LOF). It seems the need for most of LMP really comes from the lack of capabilities of the current crop of PXCs. Greg B. *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] Sent: Thursday, May 30, 2002 6:41 AM To: Michiel van Everdingen; Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Michiel, Neighbor discovery, through use of appropriate control channel management (see Section 3 and 9), is supported with the current LMP draft. There is no need for any extension to the draft for this purpose. Regards, Martin -----Original Message----- From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] Sent: Thursday, May 30, 2002 7:31 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Hello Kireeti, Thanks for your answer. > Reading over the threads again, it appears that "neighbor discovery" > may be a useful function. Agreed. Non manual, fully automatic "neighbor discovery" is an important requirement as also stated in ITU-T G.7714.1. Including neighbor discovery in LMP would also remove the confusion that currently appears to exist on whether or not LMP does specify neighbor discovery. In http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html Jonathan seems to state that LMP *does* include neighbor discovery. However, this type of neighbor discovery is rather manual and not in line with ITU-T G.7714.1. > However, LMP is a *link* management protocol, > where neighbors are configured (at least as a starting point), and > *links* are discovered, and link properties correlated. I guess you are here referring to TE-links as opposed to dataLinks ? The proposed addition to LMP discovers dataLinks. I don't see it as a problem that subsequent link property correlation groups all dataLinks together and correlates the full TE-link in one IP message. Compared to correlating individual dataLinks, correlating a full TE-link has advantages performance wise. Why do you see it as a problem that the described neighbor discovery procedure discovers the neighbor on an individual dataLink ? For example, the existing LMP function "Fault Management" is built on discovering the faults on individual dataLinks. > My suggestion (as co-chair) is that LMP proceed as is, and if folks > think that neighbor management is a useful function, then they can > write a draft, perhaps building on LMP, and we'll judge WG interest > in this function. As you might have noted, my neighbor discovery proposal does *not* include a *single* IP message. It is simply making use of an existing function in the transport layer: reading the access point identifier. In my mind, it would therefore be strange to write a separate ID to define this neighbor discovery function. Moreover, this new ID would indeed be heavily building on LMP to provide the subsequent link correlation. Could you please let me know what you see as advantages of defining neighbor discovery in a separate ID ? > To my mind (as implementor), the notion of control channel seems simple > enough; a control network is one instantiation of a control channel. This statement seems to be in conflict with an earlier statement that a "control channel" runs on top of an existing "control network" (it is a "routed control channel"). Related to your assessment of "control channels" being simple: did you include in that assessment the need to carefully provision the timers related to RSVP-TE hellos, LMP control channel hellos and the "control network" IGP hellos ? You might want to re-read http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > If this proposal is not in line with your view, I'm looking forward > > to a continued discussion on the three indicated email threads ! > > Excellent idea! As I said, if there is interest, the best way to proceed > is to follow up with an ID. In my mind there are two ways to proceed: 1. Don't accept the proposed changes in LMP. 2. Accept the proposed changes in LMP. If option (1) is chosen, I would at least like to have within the LMP draft: - Clarification on "control channel" (thread "Question on LMP") - Clarification on when the link verification procedure is applicable (thread "applicability of LMP's verify procedure") - Clarification on whether or not LMP includes neighbor discovery. Of course my preference would be option (2). Best regards, Michiel Kireeti Kompella wrote: > > On Thu, 23 May 2002, Michiel van Everdingen wrote: > > > Hello Jonathan, Kireeti, Ron, > > > > Judging on the information in three e-mail threads (first and last email > > indicated): > > - Question on LMP > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > - LMP & neighbor discovery > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > - applicability of LMP's verify procedure > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > > I would propose to make the following modifications to the LMP draft, > > version 03: > > - Include a section on neighbor discovery > > Details can be found in > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html > > Reading over the threads again, it appears that "neighbor discovery" > may be a useful function. However, LMP is a *link* management protocol, > where neighbors are configured (at least as a starting point), and > *links* are discovered, and link properties correlated. > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > think that neighbor management is a useful function, then they can > write a draft, perhaps building on LMP, and we'll judge WG interest > in this function. > > > - Remove the concept of "control channel" and accept that signalling > > messages are carried over the "control network". > > To my mind (as implementor), the notion of control channel seems simple > enough; a control network is one instantiation of a control channel. > > > If this proposal is not in line with your view, I'm looking forward > > to a continued discussion on the three indicated email threads ! > > Excellent idea! As I said, if there is interest, the best way to proceed > is to follow up with an ID. > > Kireeti. -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 09:45:33 -0700 Reply-To: From: "Vishal Sharma" To: "Zhi-Wei Lin" , "Suresh Katukam" Cc: "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" Subject: RE: Sonet Ring provisioning Date: Fri, 31 May 2002 09:49:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Zhi and all, Great discussion! I'm glad we're finally discussing some of these issues, and highlighting that mix inherent ring protection with the control domain mechanisms is non-trivial. Comments in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Zhi-Wei Lin > Sent: Thursday, May 30, 2002 11:54 AM > To: Suresh Katukam > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); > mpls@UU. NET (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi Suresh, > > Yes agree this is very complex if you try to create too much > dependencies between control plane and transport plane protection > interactions. That is why my simplistic approach: > > * Control plane sees the entire ring as offering "highly available" > connections > * Control plane sets up a single connection across this ring > "sub-network" (if you think this about this, the entire ring can > actually be treated by a control plane controller as a single node > where the BLSR ring nodes may be thought of as aggregate ports on > the single node) > * The ring sub-network, by virtue of providing the protection and > knowing *exactly* how protection is provided can set up the > protection channel automatically (but control plane need not know > this as it is irrelevant to the control plane -- it only needs to > know that the single connection is protected) What mechanism will the ring use to setup the internal protection channel? Will it require EMS/NMS intervention, as proposed on this thread earlier, or will there be another sequence of control plane messages (initiated internal to the ring) to set this path up. The latter would be prefereable if the objective is to have fully-automated path setup (otherwise, we have EMS/NMS intervention for the ring), but it does complicate the control plane protocols (since a new sequence of setup steps may have to be initiated internal to each ring on the path of the end-to-end circuit/trail that is being setup. -Vishal > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 06:32:21 -0700 Message-ID: <015301c208a7$72920cd0$681810ac@movaz.com> From: "Adrian Farrel" To: Cc: "Cheng-Yin Lee" Subject: Fw: I-D ACTION:draft-lee-ccamp-rsvp-te-exclude-route-00.txt Date: Fri, 31 May 2002 09:31:19 -0400 As you can see, Cheng-Yin and I have posted a new draft. This replaces draft-lee-rsvp-te-exclude-route-00.txt which was discussed at the CCAMP meeting at the last IETF. The changes since the previous draft are (in summary): - refine the description of the Exclude Route Object (XRO) - introduce a new subobject to convey SRLGs for exclusion - describe a way of inserting exclusions at specific points in EROs. As always, we would welcome a discussion of the value of this draft as well as the appropriateness of the protocol changes suggested. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Friday, May 31, 2002 7:20 AM Subject: I-D ACTION:draft-lee-ccamp-rsvp-te-exclude-route-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Exclude Routes - Extension to RSVP-TE > Author(s) : C. Lee, A. Farrel > Filename : draft-lee-ccamp-rsvp-te-exclude-route-00.txt > Pages : 10 > Date : 30-May-02 > > The current RSVP-TE specification [RSVP-TE] and GMPLS extensions > [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly > included in a path setup, but not to be explicitly excluded. > In some systems where precise explicit paths are not computed at the > head end it may be useful to specify and signal abstract nodes and > resources that are to be explicitly excluded from routes. These > exclusions may apply to the whole of a path, or to parts of a path > between two abstract nodes specified in an explicit route. > Shared Risk Link Groups (SRLGs) allow the definition of resources or > groups of resources that share the same risk of failure. The > knowledge of SRLGs may be used to compute diverse paths that can be > used for protection. In systems where it is useful to signal > exclusions, it may be useful to signal SRLGs to indicate groups of > resources that should be excluded on the whole of a path or between > two abstract nodes specified in an explicit path. > This draft specifies ways to communicate route exclusions during path > setup using RSVP-TE. > These approaches are equally applicable to other MPLS TE signaling > protocols such as CR-LDP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-00.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 05:47:49 -0700 Cc: Zhi-Wei Lin , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Message-ID: <3CF77082.498B6D7B@lucent.com> Date: Fri, 31 May 2002 14:45:54 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Suresh Katukam Original-CC: Zhi-Wei Lin , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: multipart/mixed; boundary="------------B7651B94689241FB6E15BF5B" This is a multi-part message in MIME format. --------------B7651B94689241FB6E15BF5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Suresh, >From the HOVC [STS] layer network the ring provides for HOVC unprotected connections. I.e. you set up the connection A-B-C-D and inform the MS SPring [BLSR] ring manager of this connection, and that is it. Some ring managers only need to be given the ingress and egress nodes, and they will set up the connection true the ring at the same time as they configure the necessary MS SPring information in the intermediate switching nodes on the ring. Because the ring is a MS SPring [BLSR] ring, the HOVC connections are protected. This MS SPing configuration is however established before any HOVC connection is routed over it. I.e. it is set up and ready to provide connectivity between its nodes on the ring. Assume that the ring is a sTM-64 ring. In this case the HOVC links between any two nodes will have a 32 VC-4 link connections (or 96 VC-3, or 8 VC-4-4c, or 2 VC-4-16c link connections or a mix). If extra traffic is supported on this ring then there will be another HOVC link between any two nodes with the same number of link connections. In this case, there is a choice to put a connection via the regular HOVC links, or via the extra traffic HOVC links. In the latter case the connection may get interrupted when there is a fault in the ring (extra traffic is dropped). If the ring supports selective MS SPring (NUT feature), then a third HOVC link between the nodes will exist and the size of the HOVC links is not longer fixed (in the example to 32). I.e. for a sTM-N ring with MS SPring protection - HOVC link #1 - protected traffic: 0 .. N/2 VC4 link connections - HOVC link #2 - preemptable traffic: 0 .. N/2 VC4 link connections - HOVC link #3 - unprotected traffic: 0 .. N VC-4 link connections Combinations for e.g. STM-64 ring include [link#1, #2, #3]: [32,32,0], [31,31,2], [30,30,4], etc. See also the functional model of a MS SPring node in G.783. Regards, Maarten Suresh Katukam wrote: > > Let us say that the BLSR ring topology is as follows: > > A --- B --- C > | | > H D > | | > G --- F --- E > > If one wants to create a LSP from A to D via B, C, then A > signals to B, B to C, C to D. Everything is fine. > > If B -- C link fails, what happens next? > > 1. Should B and C keep quite and do not tear down > LSP (because these know that B - C line is protected)? > How about H, G, F, E, D, C nodes? > Do these need to know that these are protecting an LSP that > goes through A to D? What happens if another link G - F fails? > Do these nodes need to inform B or C or A indicating that > these cannot protect B - C link anymore so that B can do > Fast Reroute? > > 2. Should B and C setup a backup LSP (when link fails) around the > ring? Traffic is not affected during this period. This provides > a mechanism for nodes involved in LSP can get information > from nodes that are in backup LSPs. > > I think that there are quite a few issues are not resolved in > this area and taking a simple view is not going to be sufficient > when Fast Reroute and other things come into play. > > Thanks, > Suresh > > Zhi-Wei Lin wrote: > > > > Hi all, > > > > Seems we have mixed up a "ring topology" from "ring protection mechanism". > > > > * In a general ring topology, *any* recovery mechanism may be used. > > This may be the underlying transport's BLSR/MSSPRING or > > UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. > > * In a BLSR/MSSPRING ring, the type of protection has already been > > decided (i.e., BLSR *is* the name of the protection mechanism). > > Similarly for UPSR/SNCPRING. > > > > Thus if we're talking about BLSR/UPSR rings, then the question is: how > > does the control plane protocols interact (do they interact?) with the > > underlying BLSR/UPSR, e.g., does the control plane simply treat the > > *entire* ring as a single node and thus interfaces to existing EMSs to > > ask for a sub-network connection across the "node", or does the control > > plane actually see all nodes of the ring and ask individual nodes for an > > STS-1/VC-3 connection (but note it only asks for the normal channel i.e. > > one connection, since the protection channel comes by default -- the > > service is either protected or unprotected but one connection in either > > case)... > > > > Zhi > > > > R. Muralidharan wrote: > > > > >Hi All, > > > > > >My understanding is as follows: > > > > > > BLSR or UPSR rings may be already provisioned in the SONET network. The > > >task using GMPLS is to set up an end to end virtual path, may be > > >encompassing multiple SONET rings. This virtual path set up is dynamic in > > >nature and the life of the path may be only for a fixed interval, after > > >which it would be tore down. When one wants to set up a path through a SONET > > >ring, one may have to specify whether one wants a 1+1 protection path or a > > >1:N protection path or just an unprotected path. Based on this specification > > >the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR > > >ring as the case may be and hence the cost would be optimum. ( assuming that > > >a 1+1 path would cost more than an unprotected path). As Greg pointed out, I > > >also believe that the BLSR and UPSR ring configurations would already have > > >been set up by associated NMS or EMS and advertised. The granularity of the > > >path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT > > >Path) or STS-1s (STS Path). > > > > > >I have used the words "path" and "virtual path" in generic terms and not in > > >the SONET or SDH domain definitions. > > > > > >Does the above make sense ? > > >regards, > > >murali > > >OSS Systems India > > > > > >----- Original Message ----- > > >From: "Bernstein, Greg" > > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > > > >Cc: "mpls@UU. NET (E-mail)" > > >Sent: Wednesday, May 29, 2002 10:28 PM > > >Subject: RE: Sonet Ring provisioning > > > > > > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that > > >> > > >> > > >you > > > > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their > > >> > > >> > > >SDH > > > > > > > > >>equivalent. > > >>Then > > >>(1) In the BLSR case the protection is at the SONET line layer, i.e., > > >> > > >> > > >below > > > > > > > > >>the layer of the connection that you are setting up(SONET/SDH are layered > > >>networks). In this case no special action needs to be taken unless of > > >>course the entity requesting the connection asked for "enhanced" > > >> > > >> > > >protection > > > > > > > > >>in the setup request. > > >> > > >>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the > > >>redundant paths taking different routes around the ring. Hence you are > > >>actually setting up two connections that have a special relationship with > > >>each other. This would have to be indicated somehow (tunnel ID or > > >>something). Some UPSRs may put constraints on the timeslots used too. One > > >>meta question is why bother signaling around a UPSR versus talking to a > > >> > > >> > > >UPSR > > > > > > > > >>as a separate "protection domain"? There is no way mesh restoration could > > >>come close to a UPSR's restoration speed (it just selects the better of > > >> > > >> > > >two > > > > > > > > >>signals). Hence I don't understand the benefit signaling around the ring > > >> > > >> > > >in > > > > > > > > >>this case, all vendors have methods for setting up their UPSRs via EMS's > > >> > > >> > > >why > > > > > > > > >>not just interface to those rather than to the individual ring elements... > > >> > > >>Greg B. > > >> > > >>*********************************** > > >>Dr. Greg M. Bernstein > > >>Senior Technology Director, Ciena Corporation > > >> > > >> > > >>-----Original Message----- > > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > > >>Sent: Wednesday, May 29, 2002 2:01 AM > > >>To: 'Ccamp (E-mail) > > >>Cc: mpls@UU. NET (E-mail) > > >>Subject: Sonet Ring provisioning > > >> > > >> > > >>Hi , > > >> Do we use GMPLS signaling protocol for configuring Sonet Rings ( > > >> > > >> > > >UPSR > > > > > > > > >>/ BLSR ( 2 fiber/4 > > >> fiber ) ? > > >> > > >> I was going through certain white papers where there was a mention > > >>that GMPLS is used as > > >> a signaling protocol for provisioning mesh topologies only > > >>.Traditional Sonet rings will be > > >> replaced by mesh topologies in future . > > >> > > >> But there is a section 12.( LSP protection and restoration) in GMPLS > > >>Architecture which says > > >> that " Both mesh and ring like topologies are supported " > > >> > > >> How do we provision nodes in Sonet ring using GMPLS ? > > >> Or GMPLS has been designed to provision mesh topologies only. > > >> > > >>Regards , > > >>Manoj > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > --------------B7651B94689241FB6E15BF5B 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 --------------B7651B94689241FB6E15BF5B-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 04:23:30 -0700 Message-Id: <200205311120.HAA11270@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-02.txt Date: Fri, 31 May 2002 07:20:17 -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 Author(s) : M. Dubuc et al. Filename : draft-ietf-ccamp-lmp-mib-02.txt Pages : 83 Date : 30-May-02 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-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-lmp-mib-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-lmp-mib-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: <20020530103344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103344.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 04:23:23 -0700 Message-Id: <200205311120.HAA11325@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-lee-ccamp-rsvp-te-exclude-route-00.txt Date: Fri, 31 May 2002 07:20:30 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Exclude Routes - Extension to RSVP-TE Author(s) : C. Lee, A. Farrel Filename : draft-lee-ccamp-rsvp-te-exclude-route-00.txt Pages : 10 Date : 30-May-02 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some systems where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole of a path, or to parts of a path between two abstract nodes specified in an explicit route. Shared Risk Link Groups (SRLGs) allow the definition of resources or groups of resources that share the same risk of failure. The knowledge of SRLGs may be used to compute diverse paths that can be used for protection. In systems where it is useful to signal exclusions, it may be useful to signal SRLGs to indicate groups of resources that should be excluded on the whole of a path or between two abstract nodes specified in an explicit path. This draft specifies ways to communicate route exclusions during path setup using RSVP-TE. These approaches are equally applicable to other MPLS TE signaling protocols such as CR-LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-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-lee-ccamp-rsvp-te-exclude-route-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-lee-ccamp-rsvp-te-exclude-route-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: <20020530103421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lee-ccamp-rsvp-te-exclude-route-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103421.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 03:01:49 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CF7497A.6CE4F51E@lucent.com> Date: Fri, 31 May 2002 11:59:22 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Martin Dubuc Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Martin, You seem to only be able to make bold statements without following up on them: - On your statement that we don't need TTP and CTP terminology because you find these concepts complex: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html Please follow up on my question for alternative terminology: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html - On your statement that my proposal for neighbor discovery is tailored specifically for Sonet/SDH: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html Please follow up on my reply that it is more general applicable: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html - On your statement that we don't need to enhance the discovery aspects of LMP: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html Please follow up on Carmine's question in: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html Would the background of your annoyance be that for your specific product, 7200 OADX, you are only interested in LMP-WDM (i.e. not LMP) ? I can understand that in a product that integrates OADM and OXC, it is no problem to have a fixed (not operator provisioned) control channel between the OADM and the OXC. However, your specific product is not the only product on this earth... Best regards, Michiel Martin Dubuc wrote: > > Michiel, > > Neighbor discovery, through use of appropriate control channel management > (see Section 3 and 9), is supported with the current LMP draft. There is > no need for any extension to the draft for this purpose. > > Regards, > > Martin > [...snip...] -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 31 May 2002 01:02:00 -0700 Cc: "'Nik Langrind'" , "'Zhi-Wei Lin'" , "R. Muralidharan" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Message-ID: <3CF72D74.AA33B74F@lucent.com> Date: Fri, 31 May 2002 09:59:48 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Bernstein, Greg" Original-CC: "'Nik Langrind'" , "'Zhi-Wei Lin'" , "R. Muralidharan" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: multipart/mixed; boundary="------------2019723B2ED73142B4D1A066" This is a multi-part message in MIME format. --------------2019723B2ED73142B4D1A066 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nik, This issue is totally unrelated to GMPLS/ASON. The same situation is already present for years in SDH/SONET networks (with connection management under control of NMS). It has been analysed in great details and the conclusion was that hold off timers provide the only solution. Furthermore, in your example you have overall knowledge of the network architecutre and its protection. In practice a connection often is through more than one network operator's domain. And then you don't have overall knowledge. I.e. the outer operator doesn't know if there is protection (and which type(s)) in the inner domain(s). The implication of nested protection for GMPLS/ASON is that the restoration process in GMPLS/ASON must support hold off timers as well. If an operator will use these and what values it will give is outside the scope of GMPLS/ASON work. Furthermore, when a protected connection is to be set up via GMPLS/ASON, GMPLS/ASON must set up the: - working connection, - protection connection, - appropriate monitoring of working connection - appropriate monitoring of protection connection - bridge and selector at A end - bridge and selector at Z end - provisioning of protection related management information as defined in the equipment standards (e.g. G.705, G.783, G.798, I.732) and protection swithcing recommendations (e.g. G.841, G.gps.1); this includes hold off time, wait to restore time, etc. Regards, Maarten "Bernstein, Greg" wrote: > > Hi Nick good points. The interaction of protection types can be tricky. The > typical technique is to use "hold off timers" to first give a "faster" > protection type a chance to respond. This works well when say source > reroute mesh (at say the SONET path layer) is used to back up a connection > that traverses say a number of rings (say BLSRs). However, in your example > below it would also imply waiting an extra time period before kicking of the > mesh. > > Greg > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > -----Original Message----- > From: Nik Langrind [mailto:nik@equipecom.com] > Sent: Thursday, May 30, 2002 7:06 AM > To: 'Zhi-Wei Lin'; R. Muralidharan > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > (E-mail) > Subject: RE: Sonet Ring provisioning > > Hi, > > If a path that is set up via GMPLS signaling traverses a SONET ring, and the > SONET ring is managed via an EMS as Greg suggests, how do the two protection > domains interact? The two protection domains I am thinking of are as > follows: > > 1) The Ring protection domain - failures in the ring itself are protected, > by ring-specific mechanisms > > 2) The end-to-end protection domain - failures anywhere along the path are > protected, presumably by failing over to a diversely routed path > > J------K > / \ > A ------B------H------I L-------O-------Y--------Z > \ \ / / > \ N------M F------G > \ / > C---------------D---------E > > Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the > ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path > C-D-E. Presumably, the nodes B and Y provide a path monitoring function, > similar to UPSR, that they can use to initiate a switch to the protect LSP. > > If a failure happens in the ring, it will be recovered from, via > line-switching or ring-switching inside the ring. But the path monitoring > function at nodes B and Y will invoke an LSP protection switch. This is > marginally bad, because it extends the outage by some number of > milliseconds, and it complicates the revert later. > > If the path monitoring function has a holddown timer, such that it does not > invoke a switch until 50 ms of outage, then failures at H or O will not be > reacted to as quickly as possible. > > Instead of performing path monitoring to trigger an LSP-switch, B and Y > could perform line monitoring, and only switch if failures occur on their > local segments? But this seems like it opens up a class of failures which > would not be recovered from. > > So it seems to me that the mixing of protection schemes creates a small > problem, and I wonder what people think about this? > > Nik > > > -----Original Message----- > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > Sent: Thursday, May 30, 2002 8:20 AM > > To: R. Muralidharan > > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > > (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi all, > > > > Seems we have mixed up a "ring topology" from "ring > > protection mechanism". > > > > * In a general ring topology, *any* recovery mechanism > > may be used. > > This may be the underlying transport's BLSR/MSSPRING or > > UPSR/SNCPRING, or it may be using control plane to set > > up 1+1 or 1:1. > > * In a BLSR/MSSPRING ring, the type of protection has already been > > decided (i.e., BLSR *is* the name of the protection mechanism). > > Similarly for UPSR/SNCPRING. > > > > Thus if we're talking about BLSR/UPSR rings, then the > > question is: how > > does the control plane protocols interact (do they interact?) > > with the > > underlying BLSR/UPSR, e.g., does the control plane simply treat the > > *entire* ring as a single node and thus interfaces to > > existing EMSs to > > ask for a sub-network connection across the "node", or does > > the control > > plane actually see all nodes of the ring and ask individual > > nodes for an > > STS-1/VC-3 connection (but note it only asks for the normal > > channel i.e. > > one connection, since the protection channel comes by default -- the > > service is either protected or unprotected but one connection > > in either > > case)... > > > > Zhi > > > > > > R. Muralidharan wrote: > > > > >Hi All, > > > > > >My understanding is as follows: > > > > > > BLSR or UPSR rings may be already provisioned in the > > SONET network. The > > >task using GMPLS is to set up an end to end virtual path, may be > > >encompassing multiple SONET rings. This virtual path set up > > is dynamic in > > >nature and the life of the path may be only for a fixed > > interval, after > > >which it would be tore down. When one wants to set up a path > > through a SONET > > >ring, one may have to specify whether one wants a 1+1 > > protection path or a > > >1:N protection path or just an unprotected path. Based on > > this specification > > >the GMPLS can discover and set up an appropriate path in a > > BLSR or an UPSR > > >ring as the case may be and hence the cost would be optimum. > > ( assuming that > > >a 1+1 path would cost more than an unprotected path). As > > Greg pointed out, I > > >also believe that the BLSR and UPSR ring configurations > > would already have > > >been set up by associated NMS or EMS and advertised. The > > granularity of the > > >path that can be set up using GMPLS could a VT1.5 or > > multiples of them ( VT > > >Path) or STS-1s (STS Path). > > > > > >I have used the words "path" and "virtual path" in generic > > terms and not in > > >the SONET or SDH domain definitions. > > > > > >Does the above make sense ? > > >regards, > > >murali > > >OSS Systems India > > > > > >----- Original Message ----- > > >From: "Bernstein, Greg" > > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > > > >Cc: "mpls@UU. NET (E-mail)" > > >Sent: Wednesday, May 29, 2002 10:28 PM > > >Subject: RE: Sonet Ring provisioning > > > > > > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm > > assuming that > > >> > > >> > > >you > > > > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... > > STS-192c or their > > >> > > >> > > >SDH > > > > > > > > >>equivalent. > > >>Then > > >>(1) In the BLSR case the protection is at the SONET line > > layer, i.e., > > >> > > >> > > >below > > > > > > > > >>the layer of the connection that you are setting > > up(SONET/SDH are layered > > >>networks). In this case no special action needs to be > > taken unless of > > >>course the entity requesting the connection asked for "enhanced" > > >> > > >> > > >protection > > > > > > > > >>in the setup request. > > >> > > >>(2) A UPSR works at the path layer, i.e., like a path layer > > 1+1, with the > > >>redundant paths taking different routes around the ring. > > Hence you are > > >>actually setting up two connections that have a special > > relationship with > > >>each other. This would have to be indicated somehow (tunnel ID or > > >>something). Some UPSRs may put constraints on the timeslots > > used too. One > > >>meta question is why bother signaling around a UPSR versus > > talking to a > > >> > > >> > > >UPSR > > > > > > > > >>as a separate "protection domain"? There is no way mesh > > restoration could > > >>come close to a UPSR's restoration speed (it just selects > > the better of > > >> > > >> > > >two > > > > > > > > >>signals). Hence I don't understand the benefit signaling > > around the ring > > >> > > >> > > >in > > > > > > > > >>this case, all vendors have methods for setting up their > > UPSRs via EMS's > > >> > > >> > > >why > > > > > > > > >>not just interface to those rather than to the individual > > ring elements... > > >> > > >>Greg B. > > >> > > >>*********************************** > > >>Dr. Greg M. Bernstein > > >>Senior Technology Director, Ciena Corporation > > >> > > >> > > >>-----Original Message----- > > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > > >>Sent: Wednesday, May 29, 2002 2:01 AM > > >>To: 'Ccamp (E-mail) > > >>Cc: mpls@UU. NET (E-mail) > > >>Subject: Sonet Ring provisioning > > >> > > >> > > >>Hi , > > >> Do we use GMPLS signaling protocol for configuring > > Sonet Rings ( > > >> > > >> > > >UPSR > > > > > > > > >>/ BLSR ( 2 fiber/4 > > >> fiber ) ? > > >> > > >> I was going through certain white papers where there > > was a mention > > >>that GMPLS is used as > > >> a signaling protocol for provisioning mesh topologies only > > >>.Traditional Sonet rings will be > > >> replaced by mesh topologies in future . > > >> > > >> But there is a section 12.( LSP protection and > > restoration) in GMPLS > > >>Architecture which says > > >> that " Both mesh and ring like topologies are supported " > > >> > > >> How do we provision nodes in Sonet ring using GMPLS ? > > >> Or GMPLS has been designed to provision mesh topologies only. > > >> > > >>Regards , > > >>Manoj > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > --------------2019723B2ED73142B4D1A066 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 --------------2019723B2ED73142B4D1A066-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 11:54:49 -0700 Message-ID: <3CF6755D.5010508@lucent.com> Date: Thu, 30 May 2002 14:54:21 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523 MIME-Version: 1.0 To: Suresh Katukam CC: "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Suresh, Yes agree this is very complex if you try to create too much dependencies between control plane and transport plane protection interactions. That is why my simplistic approach: * Control plane sees the entire ring as offering "highly available" connections * Control plane sets up a single connection across this ring "sub-network" (if you think this about this, the entire ring can actually be treated by a control plane controller as a single node where the BLSR ring nodes may be thought of as aggregate ports on the single node) * The ring sub-network, by virtue of providing the protection and knowing *exactly* how protection is provided can set up the protection channel automatically (but control plane need not know this as it is irrelevant to the control plane -- it only needs to know that the single connection is protected) Of course there will be additional constraints placed by the ring, such as a flag to indicate the availability of "highly available" connections, whether or not to enable this highly available connection (if not enabled then you may be using the NUT feature of BLSR e.g.), whether the same timeslot must be used, whether ring switching or span switching is supported (and enabled), whether traffic should be carried as "best effort" (e.g., as extra traffic on the BLSR), etc. etc. Thus in your example, if link B-C fails, so what? the underlying BLSR protects this connection. The control plane sees its A-D connection as been up all the time (the little transport plane interruption probably translates to a packet delay). Also by virtue that this is a BLSR ring, nodes H, G, F, E knows exactly which link it is protecting (it's part of the BLSR protocol operation). If another link G-F fails, then the entire ring has become segmented, and thus *any* traffic going through this ring is shot (except those that are contained within each segment). Then you either declare the connection "dead" or if you're offering an end-to-end restoration on top of the ring, you might try re-routing the LSP. But this is a separate issue from how the rings work (all the ring nodes would know that the ring is segmented from the K1/K2 byte info exchanges in a BLSR -- doesn't need control plane to tell it anything), but more to do with what mechanisms control plane has for restoration. The interactions of course may be the holdoff timer that Greg mentioned. Zhi Suresh Katukam wrote: >Let us say that the BLSR ring topology is as follows: > > A --- B --- C > | | > H D > | | > G --- F --- E > >If one wants to create a LSP from A to D via B, C, then A >signals to B, B to C, C to D. Everything is fine. > >If B -- C link fails, what happens next? > >1. Should B and C keep quite and do not tear down >LSP (because these know that B - C line is protected)? >How about H, G, F, E, D, C nodes? >Do these need to know that these are protecting an LSP that >goes through A to D? What happens if another link G - F fails? >Do these nodes need to inform B or C or A indicating that >these cannot protect B - C link anymore so that B can do >Fast Reroute? > >2. Should B and C setup a backup LSP (when link fails) around the >ring? Traffic is not affected during this period. This provides >a mechanism for nodes involved in LSP can get information >from nodes that are in backup LSPs. > >I think that there are quite a few issues are not resolved in >this area and taking a simple view is not going to be sufficient >when Fast Reroute and other things come into play. > >Thanks, >Suresh > >Zhi-Wei Lin wrote: > > >>Hi all, >> >>Seems we have mixed up a "ring topology" from "ring protection mechanism". >> >> * In a general ring topology, *any* recovery mechanism may be used. >> This may be the underlying transport's BLSR/MSSPRING or >> UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. >> * In a BLSR/MSSPRING ring, the type of protection has already been >> decided (i.e., BLSR *is* the name of the protection mechanism). >> Similarly for UPSR/SNCPRING. >> >>Thus if we're talking about BLSR/UPSR rings, then the question is: how >>does the control plane protocols interact (do they interact?) with the >>underlying BLSR/UPSR, e.g., does the control plane simply treat the >>*entire* ring as a single node and thus interfaces to existing EMSs to >>ask for a sub-network connection across the "node", or does the control >>plane actually see all nodes of the ring and ask individual nodes for an >>STS-1/VC-3 connection (but note it only asks for the normal channel i.e. >>one connection, since the protection channel comes by default -- the >>service is either protected or unprotected but one connection in either >>case)... >> >>Zhi >> >>R. Muralidharan wrote: >> >> >> >>>Hi All, >>> >>>My understanding is as follows: >>> >>> BLSR or UPSR rings may be already provisioned in the SONET network. The >>>task using GMPLS is to set up an end to end virtual path, may be >>>encompassing multiple SONET rings. This virtual path set up is dynamic in >>>nature and the life of the path may be only for a fixed interval, after >>>which it would be tore down. When one wants to set up a path through a SONET >>>ring, one may have to specify whether one wants a 1+1 protection path or a >>>1:N protection path or just an unprotected path. Based on this specification >>>the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR >>>ring as the case may be and hence the cost would be optimum. ( assuming that >>>a 1+1 path would cost more than an unprotected path). As Greg pointed out, I >>>also believe that the BLSR and UPSR ring configurations would already have >>>been set up by associated NMS or EMS and advertised. The granularity of the >>>path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT >>>Path) or STS-1s (STS Path). >>> >>>I have used the words "path" and "virtual path" in generic terms and not in >>>the SONET or SDH domain definitions. >>> >>>Does the above make sense ? >>>regards, >>>murali >>>OSS Systems India >>> >>>----- Original Message ----- >>>From: "Bernstein, Greg" >>>To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" >>> >>>Cc: "mpls@UU. NET (E-mail)" >>>Sent: Wednesday, May 29, 2002 10:28 PM >>>Subject: RE: Sonet Ring provisioning >>> >>> >>> >>> >>> >>> >>>>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that >>>> >>>> >>>> >>>> >>>you >>> >>> >>> >>> >>>>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their >>>> >>>> >>>> >>>> >>>SDH >>> >>> >>> >>> >>>>equivalent. >>>>Then >>>>(1) In the BLSR case the protection is at the SONET line layer, i.e., >>>> >>>> >>>> >>>> >>>below >>> >>> >>> >>> >>>>the layer of the connection that you are setting up(SONET/SDH are layered >>>>networks). In this case no special action needs to be taken unless of >>>>course the entity requesting the connection asked for "enhanced" >>>> >>>> >>>> >>>> >>>protection >>> >>> >>> >>> >>>>in the setup request. >>>> >>>>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the >>>>redundant paths taking different routes around the ring. Hence you are >>>>actually setting up two connections that have a special relationship with >>>>each other. This would have to be indicated somehow (tunnel ID or >>>>something). Some UPSRs may put constraints on the timeslots used too. One >>>>meta question is why bother signaling around a UPSR versus talking to a >>>> >>>> >>>> >>>> >>>UPSR >>> >>> >>> >>> >>>>as a separate "protection domain"? There is no way mesh restoration could >>>>come close to a UPSR's restoration speed (it just selects the better of >>>> >>>> >>>> >>>> >>>two >>> >>> >>> >>> >>>>signals). Hence I don't understand the benefit signaling around the ring >>>> >>>> >>>> >>>> >>>in >>> >>> >>> >>> >>>>this case, all vendors have methods for setting up their UPSRs via EMS's >>>> >>>> >>>> >>>> >>>why >>> >>> >>> >>> >>>>not just interface to those rather than to the individual ring elements... >>>> >>>>Greg B. >>>> >>>>*********************************** >>>>Dr. Greg M. Bernstein >>>>Senior Technology Director, Ciena Corporation >>>> >>>> >>>>-----Original Message----- >>>>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] >>>>Sent: Wednesday, May 29, 2002 2:01 AM >>>>To: 'Ccamp (E-mail) >>>>Cc: mpls@UU. NET (E-mail) >>>>Subject: Sonet Ring provisioning >>>> >>>> >>>>Hi , >>>> Do we use GMPLS signaling protocol for configuring Sonet Rings ( >>>> >>>> >>>> >>>> >>>UPSR >>> >>> >>> >>> >>>>/ BLSR ( 2 fiber/4 >>>> fiber ) ? >>>> >>>> I was going through certain white papers where there was a mention >>>>that GMPLS is used as >>>> a signaling protocol for provisioning mesh topologies only >>>>.Traditional Sonet rings will be >>>> replaced by mesh topologies in future . >>>> >>>> But there is a section 12.( LSP protection and restoration) in GMPLS >>>>Architecture which says >>>> that " Both mesh and ring like topologies are supported " >>>> >>>> How do we provision nodes in Sonet ring using GMPLS ? >>>> Or GMPLS has been designed to provision mesh topologies only. >>>> >>>>Regards , >>>>Manoj >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 11:24:45 -0700 Message-ID: <3CF66E05.F5DB0E93@cisco.com> Date: Thu, 30 May 2002 11:23:01 -0700 From: Suresh Katukam Organization: Cisco Systems MIME-Version: 1.0 To: Zhi-Wei Lin CC: "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Let us say that the BLSR ring topology is as follows: A --- B --- C | | H D | | G --- F --- E If one wants to create a LSP from A to D via B, C, then A signals to B, B to C, C to D. Everything is fine. If B -- C link fails, what happens next? 1. Should B and C keep quite and do not tear down LSP (because these know that B - C line is protected)? How about H, G, F, E, D, C nodes? Do these need to know that these are protecting an LSP that goes through A to D? What happens if another link G - F fails? Do these nodes need to inform B or C or A indicating that these cannot protect B - C link anymore so that B can do Fast Reroute? 2. Should B and C setup a backup LSP (when link fails) around the ring? Traffic is not affected during this period. This provides a mechanism for nodes involved in LSP can get information from nodes that are in backup LSPs. I think that there are quite a few issues are not resolved in this area and taking a simple view is not going to be sufficient when Fast Reroute and other things come into play. Thanks, Suresh Zhi-Wei Lin wrote: > > Hi all, > > Seems we have mixed up a "ring topology" from "ring protection mechanism". > > * In a general ring topology, *any* recovery mechanism may be used. > This may be the underlying transport's BLSR/MSSPRING or > UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. > * In a BLSR/MSSPRING ring, the type of protection has already been > decided (i.e., BLSR *is* the name of the protection mechanism). > Similarly for UPSR/SNCPRING. > > Thus if we're talking about BLSR/UPSR rings, then the question is: how > does the control plane protocols interact (do they interact?) with the > underlying BLSR/UPSR, e.g., does the control plane simply treat the > *entire* ring as a single node and thus interfaces to existing EMSs to > ask for a sub-network connection across the "node", or does the control > plane actually see all nodes of the ring and ask individual nodes for an > STS-1/VC-3 connection (but note it only asks for the normal channel i.e. > one connection, since the protection channel comes by default -- the > service is either protected or unprotected but one connection in either > case)... > > Zhi > > R. Muralidharan wrote: > > >Hi All, > > > >My understanding is as follows: > > > > BLSR or UPSR rings may be already provisioned in the SONET network. The > >task using GMPLS is to set up an end to end virtual path, may be > >encompassing multiple SONET rings. This virtual path set up is dynamic in > >nature and the life of the path may be only for a fixed interval, after > >which it would be tore down. When one wants to set up a path through a SONET > >ring, one may have to specify whether one wants a 1+1 protection path or a > >1:N protection path or just an unprotected path. Based on this specification > >the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR > >ring as the case may be and hence the cost would be optimum. ( assuming that > >a 1+1 path would cost more than an unprotected path). As Greg pointed out, I > >also believe that the BLSR and UPSR ring configurations would already have > >been set up by associated NMS or EMS and advertised. The granularity of the > >path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT > >Path) or STS-1s (STS Path). > > > >I have used the words "path" and "virtual path" in generic terms and not in > >the SONET or SDH domain definitions. > > > >Does the above make sense ? > >regards, > >murali > >OSS Systems India > > > >----- Original Message ----- > >From: "Bernstein, Greg" > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > >Cc: "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 29, 2002 10:28 PM > >Subject: RE: Sonet Ring provisioning > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that > >> > >> > >you > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their > >> > >> > >SDH > > > > > >>equivalent. > >>Then > >>(1) In the BLSR case the protection is at the SONET line layer, i.e., > >> > >> > >below > > > > > >>the layer of the connection that you are setting up(SONET/SDH are layered > >>networks). In this case no special action needs to be taken unless of > >>course the entity requesting the connection asked for "enhanced" > >> > >> > >protection > > > > > >>in the setup request. > >> > >>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the > >>redundant paths taking different routes around the ring. Hence you are > >>actually setting up two connections that have a special relationship with > >>each other. This would have to be indicated somehow (tunnel ID or > >>something). Some UPSRs may put constraints on the timeslots used too. One > >>meta question is why bother signaling around a UPSR versus talking to a > >> > >> > >UPSR > > > > > >>as a separate "protection domain"? There is no way mesh restoration could > >>come close to a UPSR's restoration speed (it just selects the better of > >> > >> > >two > > > > > >>signals). Hence I don't understand the benefit signaling around the ring > >> > >> > >in > > > > > >>this case, all vendors have methods for setting up their UPSRs via EMS's > >> > >> > >why > > > > > >>not just interface to those rather than to the individual ring elements... > >> > >>Greg B. > >> > >>*********************************** > >>Dr. Greg M. Bernstein > >>Senior Technology Director, Ciena Corporation > >> > >> > >>-----Original Message----- > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > >>Sent: Wednesday, May 29, 2002 2:01 AM > >>To: 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Sonet Ring provisioning > >> > >> > >>Hi , > >> Do we use GMPLS signaling protocol for configuring Sonet Rings ( > >> > >> > >UPSR > > > > > >>/ BLSR ( 2 fiber/4 > >> fiber ) ? > >> > >> I was going through certain white papers where there was a mention > >>that GMPLS is used as > >> a signaling protocol for provisioning mesh topologies only > >>.Traditional Sonet rings will be > >> replaced by mesh topologies in future . > >> > >> But there is a section 12.( LSP protection and restoration) in GMPLS > >>Architecture which says > >> that " Both mesh and ring like topologies are supported " > >> > >> How do we provision nodes in Sonet ring using GMPLS ? > >> Or GMPLS has been designed to provision mesh topologies only. > >> > >>Regards , > >>Manoj > >> > >> > >> > >> > >> > >> > >> > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 09:59:10 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B13B@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Nik Langrind'" , "'Zhi-Wei Lin'" , "R. Muralidharan" Cc: "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: RE: Sonet Ring provisioning Date: Thu, 30 May 2002 09:56:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Nick good points. The interaction of protection types can be tricky. The typical technique is to use "hold off timers" to first give a "faster" protection type a chance to respond. This works well when say source reroute mesh (at say the SONET path layer) is used to back up a connection that traverses say a number of rings (say BLSRs). However, in your example below it would also imply waiting an extra time period before kicking of the mesh. Greg *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Nik Langrind [mailto:nik@equipecom.com] Sent: Thursday, May 30, 2002 7:06 AM To: 'Zhi-Wei Lin'; R. Muralidharan Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Sonet Ring provisioning Hi, If a path that is set up via GMPLS signaling traverses a SONET ring, and the SONET ring is managed via an EMS as Greg suggests, how do the two protection domains interact? The two protection domains I am thinking of are as follows: 1) The Ring protection domain - failures in the ring itself are protected, by ring-specific mechanisms 2) The end-to-end protection domain - failures anywhere along the path are protected, presumably by failing over to a diversely routed path J------K / \ A ------B------H------I L-------O-------Y--------Z \ \ / / \ N------M F------G \ / C---------------D---------E Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path C-D-E. Presumably, the nodes B and Y provide a path monitoring function, similar to UPSR, that they can use to initiate a switch to the protect LSP. If a failure happens in the ring, it will be recovered from, via line-switching or ring-switching inside the ring. But the path monitoring function at nodes B and Y will invoke an LSP protection switch. This is marginally bad, because it extends the outage by some number of milliseconds, and it complicates the revert later. If the path monitoring function has a holddown timer, such that it does not invoke a switch until 50 ms of outage, then failures at H or O will not be reacted to as quickly as possible. Instead of performing path monitoring to trigger an LSP-switch, B and Y could perform line monitoring, and only switch if failures occur on their local segments? But this seems like it opens up a class of failures which would not be recovered from. So it seems to me that the mixing of protection schemes creates a small problem, and I wonder what people think about this? Nik > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, May 30, 2002 8:20 AM > To: R. Muralidharan > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi all, > > Seems we have mixed up a "ring topology" from "ring > protection mechanism". > > * In a general ring topology, *any* recovery mechanism > may be used. > This may be the underlying transport's BLSR/MSSPRING or > UPSR/SNCPRING, or it may be using control plane to set > up 1+1 or 1:1. > * In a BLSR/MSSPRING ring, the type of protection has already been > decided (i.e., BLSR *is* the name of the protection mechanism). > Similarly for UPSR/SNCPRING. > > Thus if we're talking about BLSR/UPSR rings, then the > question is: how > does the control plane protocols interact (do they interact?) > with the > underlying BLSR/UPSR, e.g., does the control plane simply treat the > *entire* ring as a single node and thus interfaces to > existing EMSs to > ask for a sub-network connection across the "node", or does > the control > plane actually see all nodes of the ring and ask individual > nodes for an > STS-1/VC-3 connection (but note it only asks for the normal > channel i.e. > one connection, since the protection channel comes by default -- the > service is either protected or unprotected but one connection > in either > case)... > > Zhi > > > R. Muralidharan wrote: > > >Hi All, > > > >My understanding is as follows: > > > > BLSR or UPSR rings may be already provisioned in the > SONET network. The > >task using GMPLS is to set up an end to end virtual path, may be > >encompassing multiple SONET rings. This virtual path set up > is dynamic in > >nature and the life of the path may be only for a fixed > interval, after > >which it would be tore down. When one wants to set up a path > through a SONET > >ring, one may have to specify whether one wants a 1+1 > protection path or a > >1:N protection path or just an unprotected path. Based on > this specification > >the GMPLS can discover and set up an appropriate path in a > BLSR or an UPSR > >ring as the case may be and hence the cost would be optimum. > ( assuming that > >a 1+1 path would cost more than an unprotected path). As > Greg pointed out, I > >also believe that the BLSR and UPSR ring configurations > would already have > >been set up by associated NMS or EMS and advertised. The > granularity of the > >path that can be set up using GMPLS could a VT1.5 or > multiples of them ( VT > >Path) or STS-1s (STS Path). > > > >I have used the words "path" and "virtual path" in generic > terms and not in > >the SONET or SDH domain definitions. > > > >Does the above make sense ? > >regards, > >murali > >OSS Systems India > > > >----- Original Message ----- > >From: "Bernstein, Greg" > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > >Cc: "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 29, 2002 10:28 PM > >Subject: RE: Sonet Ring provisioning > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm > assuming that > >> > >> > >you > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... > STS-192c or their > >> > >> > >SDH > > > > > >>equivalent. > >>Then > >>(1) In the BLSR case the protection is at the SONET line > layer, i.e., > >> > >> > >below > > > > > >>the layer of the connection that you are setting > up(SONET/SDH are layered > >>networks). In this case no special action needs to be > taken unless of > >>course the entity requesting the connection asked for "enhanced" > >> > >> > >protection > > > > > >>in the setup request. > >> > >>(2) A UPSR works at the path layer, i.e., like a path layer > 1+1, with the > >>redundant paths taking different routes around the ring. > Hence you are > >>actually setting up two connections that have a special > relationship with > >>each other. This would have to be indicated somehow (tunnel ID or > >>something). Some UPSRs may put constraints on the timeslots > used too. One > >>meta question is why bother signaling around a UPSR versus > talking to a > >> > >> > >UPSR > > > > > >>as a separate "protection domain"? There is no way mesh > restoration could > >>come close to a UPSR's restoration speed (it just selects > the better of > >> > >> > >two > > > > > >>signals). Hence I don't understand the benefit signaling > around the ring > >> > >> > >in > > > > > >>this case, all vendors have methods for setting up their > UPSRs via EMS's > >> > >> > >why > > > > > >>not just interface to those rather than to the individual > ring elements... > >> > >>Greg B. > >> > >>*********************************** > >>Dr. Greg M. Bernstein > >>Senior Technology Director, Ciena Corporation > >> > >> > >>-----Original Message----- > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > >>Sent: Wednesday, May 29, 2002 2:01 AM > >>To: 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Sonet Ring provisioning > >> > >> > >>Hi , > >> Do we use GMPLS signaling protocol for configuring > Sonet Rings ( > >> > >> > >UPSR > > > > > >>/ BLSR ( 2 fiber/4 > >> fiber ) ? > >> > >> I was going through certain white papers where there > was a mention > >>that GMPLS is used as > >> a signaling protocol for provisioning mesh topologies only > >>.Traditional Sonet rings will be > >> replaced by mesh topologies in future . > >> > >> But there is a section 12.( LSP protection and > restoration) in GMPLS > >>Architecture which says > >> that " Both mesh and ring like topologies are supported " > >> > >> How do we provision nodes in Sonet ring using GMPLS ? > >> Or GMPLS has been designed to provision mesh topologies only. > >> > >>Regards , > >>Manoj > >> > >> > >> > >> > >> > >> > >> > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 07:07:04 -0700 Message-ID: <666478FCC801D6118E3600D0B781FC16159C00@eccexch01.equipecom.com> From: Nik Langrind To: "'Zhi-Wei Lin'" , "R. Muralidharan" Cc: "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: RE: Sonet Ring provisioning Date: Thu, 30 May 2002 10:05:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, If a path that is set up via GMPLS signaling traverses a SONET ring, and the SONET ring is managed via an EMS as Greg suggests, how do the two protection domains interact? The two protection domains I am thinking of are as follows: 1) The Ring protection domain - failures in the ring itself are protected, by ring-specific mechanisms 2) The end-to-end protection domain - failures anywhere along the path are protected, presumably by failing over to a diversely routed path J------K / \ A ------B------H------I L-------O-------Y--------Z \ \ / / \ N------M F------G \ / C---------------D---------E Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path C-D-E. Presumably, the nodes B and Y provide a path monitoring function, similar to UPSR, that they can use to initiate a switch to the protect LSP. If a failure happens in the ring, it will be recovered from, via line-switching or ring-switching inside the ring. But the path monitoring function at nodes B and Y will invoke an LSP protection switch. This is marginally bad, because it extends the outage by some number of milliseconds, and it complicates the revert later. If the path monitoring function has a holddown timer, such that it does not invoke a switch until 50 ms of outage, then failures at H or O will not be reacted to as quickly as possible. Instead of performing path monitoring to trigger an LSP-switch, B and Y could perform line monitoring, and only switch if failures occur on their local segments? But this seems like it opens up a class of failures which would not be recovered from. So it seems to me that the mixing of protection schemes creates a small problem, and I wonder what people think about this? Nik > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Thursday, May 30, 2002 8:20 AM > To: R. Muralidharan > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET > (E-mail) > Subject: Re: Sonet Ring provisioning > > > Hi all, > > Seems we have mixed up a "ring topology" from "ring > protection mechanism". > > * In a general ring topology, *any* recovery mechanism > may be used. > This may be the underlying transport's BLSR/MSSPRING or > UPSR/SNCPRING, or it may be using control plane to set > up 1+1 or 1:1. > * In a BLSR/MSSPRING ring, the type of protection has already been > decided (i.e., BLSR *is* the name of the protection mechanism). > Similarly for UPSR/SNCPRING. > > Thus if we're talking about BLSR/UPSR rings, then the > question is: how > does the control plane protocols interact (do they interact?) > with the > underlying BLSR/UPSR, e.g., does the control plane simply treat the > *entire* ring as a single node and thus interfaces to > existing EMSs to > ask for a sub-network connection across the "node", or does > the control > plane actually see all nodes of the ring and ask individual > nodes for an > STS-1/VC-3 connection (but note it only asks for the normal > channel i.e. > one connection, since the protection channel comes by default -- the > service is either protected or unprotected but one connection > in either > case)... > > Zhi > > > R. Muralidharan wrote: > > >Hi All, > > > >My understanding is as follows: > > > > BLSR or UPSR rings may be already provisioned in the > SONET network. The > >task using GMPLS is to set up an end to end virtual path, may be > >encompassing multiple SONET rings. This virtual path set up > is dynamic in > >nature and the life of the path may be only for a fixed > interval, after > >which it would be tore down. When one wants to set up a path > through a SONET > >ring, one may have to specify whether one wants a 1+1 > protection path or a > >1:N protection path or just an unprotected path. Based on > this specification > >the GMPLS can discover and set up an appropriate path in a > BLSR or an UPSR > >ring as the case may be and hence the cost would be optimum. > ( assuming that > >a 1+1 path would cost more than an unprotected path). As > Greg pointed out, I > >also believe that the BLSR and UPSR ring configurations > would already have > >been set up by associated NMS or EMS and advertised. The > granularity of the > >path that can be set up using GMPLS could a VT1.5 or > multiples of them ( VT > >Path) or STS-1s (STS Path). > > > >I have used the words "path" and "virtual path" in generic > terms and not in > >the SONET or SDH domain definitions. > > > >Does the above make sense ? > >regards, > >murali > >OSS Systems India > > > >----- Original Message ----- > >From: "Bernstein, Greg" > >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > > > >Cc: "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 29, 2002 10:28 PM > >Subject: RE: Sonet Ring provisioning > > > > > > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm > assuming that > >> > >> > >you > > > > > >>are setting up SONET paths such as STS-1, STS-3c, ... > STS-192c or their > >> > >> > >SDH > > > > > >>equivalent. > >>Then > >>(1) In the BLSR case the protection is at the SONET line > layer, i.e., > >> > >> > >below > > > > > >>the layer of the connection that you are setting > up(SONET/SDH are layered > >>networks). In this case no special action needs to be > taken unless of > >>course the entity requesting the connection asked for "enhanced" > >> > >> > >protection > > > > > >>in the setup request. > >> > >>(2) A UPSR works at the path layer, i.e., like a path layer > 1+1, with the > >>redundant paths taking different routes around the ring. > Hence you are > >>actually setting up two connections that have a special > relationship with > >>each other. This would have to be indicated somehow (tunnel ID or > >>something). Some UPSRs may put constraints on the timeslots > used too. One > >>meta question is why bother signaling around a UPSR versus > talking to a > >> > >> > >UPSR > > > > > >>as a separate "protection domain"? There is no way mesh > restoration could > >>come close to a UPSR's restoration speed (it just selects > the better of > >> > >> > >two > > > > > >>signals). Hence I don't understand the benefit signaling > around the ring > >> > >> > >in > > > > > >>this case, all vendors have methods for setting up their > UPSRs via EMS's > >> > >> > >why > > > > > >>not just interface to those rather than to the individual > ring elements... > >> > >>Greg B. > >> > >>*********************************** > >>Dr. Greg M. Bernstein > >>Senior Technology Director, Ciena Corporation > >> > >> > >>-----Original Message----- > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > >>Sent: Wednesday, May 29, 2002 2:01 AM > >>To: 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Sonet Ring provisioning > >> > >> > >>Hi , > >> Do we use GMPLS signaling protocol for configuring > Sonet Rings ( > >> > >> > >UPSR > > > > > >>/ BLSR ( 2 fiber/4 > >> fiber ) ? > >> > >> I was going through certain white papers where there > was a mention > >>that GMPLS is used as > >> a signaling protocol for provisioning mesh topologies only > >>.Traditional Sonet rings will be > >> replaced by mesh topologies in future . > >> > >> But there is a section 12.( LSP protection and > restoration) in GMPLS > >>Architecture which says > >> that " Both mesh and ring like topologies are supported " > >> > >> How do we provision nodes in Sonet ring using GMPLS ? > >> Or GMPLS has been designed to provision mesh topologies only. > >> > >>Regards , > >>Manoj > >> > >> > >> > >> > >> > >> > >> > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 06:45:22 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LMP & neighbor discovery Date: Thu, 30 May 2002 09:41:15 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C915C8B4@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: LMP & neighbor discovery Thread-Index: AcIHz1iAZdl6pv1RQ96u84HwbmVrrAADGmYA From: "Martin Dubuc" To: "Michiel van Everdingen" , "Kireeti Kompella" Cc: Michiel, Neighbor discovery, through use of appropriate control channel = management (see Section 3 and 9), is supported with the current LMP = draft. There is no need for any extension to the draft for this purpose. Regards, Martin -----Original Message----- From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] Sent: Thursday, May 30, 2002 7:31 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Hello Kireeti, Thanks for your answer. > Reading over the threads again, it appears that "neighbor discovery" > may be a useful function. Agreed. Non manual, fully automatic "neighbor discovery" is an important requirement as also stated in ITU-T G.7714.1. Including neighbor discovery in LMP would also remove the confusion that currently appears to exist on whether or not LMP does specify neighbor discovery. In http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html Jonathan seems to state that LMP *does* include neighbor discovery. However, this type of neighbor discovery is rather manual and not in line with ITU-T G.7714.1. > However, LMP is a *link* management protocol, > where neighbors are configured (at least as a starting point), and > *links* are discovered, and link properties correlated. I guess you are here referring to TE-links as opposed to dataLinks ? The proposed addition to LMP discovers dataLinks. I don't see it as a problem that subsequent link property correlation groups all dataLinks together and correlates the full TE-link in one IP message. Compared to correlating individual dataLinks, correlating a full TE-link has advantages performance wise. Why do you see it as a problem that the described neighbor discovery procedure discovers the neighbor on an individual dataLink ? For example, the existing LMP function "Fault Management" is built on discovering the faults on individual dataLinks.=20 > My suggestion (as co-chair) is that LMP proceed as is, and if folks > think that neighbor management is a useful function, then they can > write a draft, perhaps building on LMP, and we'll judge WG interest > in this function. As you might have noted, my neighbor discovery proposal does *not* include a *single* IP message. It is simply making use of an existing function in the transport layer: reading the access point identifier. In my mind, it would therefore be strange to write a separate ID to define this neighbor discovery function. Moreover, this new ID would indeed be heavily building on LMP to provide the subsequent link correlation. Could you please let me know what you see as advantages of defining neighbor discovery in a separate ID ? > To my mind (as implementor), the notion of control channel seems = simple > enough; a control network is one instantiation of a control channel. This statement seems to be in conflict with an earlier statement that a "control channel" runs on top of an existing "control network" (it is a "routed control channel"). Related to your assessment of "control channels" being simple: did you include in that assessment the need to carefully provision the timers related to RSVP-TE hellos, LMP control channel hellos and the "control network" IGP hellos ? You might want to re-read http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > If this proposal is not in line with your view, I'm looking forward > > to a continued discussion on the three indicated email threads ! >=20 > Excellent idea! As I said, if there is interest, the best way to = proceed > is to follow up with an ID. In my mind there are two ways to proceed: 1. Don't accept the proposed changes in LMP. 2. Accept the proposed changes in LMP. If option (1) is chosen, I would at least like to have within the LMP draft: - Clarification on "control channel" (thread "Question on LMP") - Clarification on when the link verification procedure is applicable (thread "applicability of LMP's verify procedure") - Clarification on whether or not LMP includes neighbor discovery. Of course my preference would be option (2). Best regards, Michiel Kireeti Kompella wrote: >=20 > On Thu, 23 May 2002, Michiel van Everdingen wrote: >=20 > > Hello Jonathan, Kireeti, Ron, > > > > Judging on the information in three e-mail threads (first and last = email > > indicated): > > - Question on LMP > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > - LMP & neighbor discovery > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > - applicability of LMP's verify procedure > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > > I would propose to make the following modifications to the LMP = draft, > > version 03: > > - Include a section on neighbor discovery > > Details can be found in > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html >=20 > Reading over the threads again, it appears that "neighbor discovery" > may be a useful function. However, LMP is a *link* management = protocol, > where neighbors are configured (at least as a starting point), and > *links* are discovered, and link properties correlated. >=20 > My suggestion (as co-chair) is that LMP proceed as is, and if folks > think that neighbor management is a useful function, then they can > write a draft, perhaps building on LMP, and we'll judge WG interest > in this function. >=20 > > - Remove the concept of "control channel" and accept that signalling > > messages are carried over the "control network". >=20 > To my mind (as implementor), the notion of control channel seems = simple > enough; a control network is one instantiation of a control channel. >=20 > > If this proposal is not in line with your view, I'm looking forward > > to a continued discussion on the three indicated email threads ! >=20 > Excellent idea! As I said, if there is interest, the best way to = proceed > is to follow up with an ID. >=20 > Kireeti. --=20 +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 05:21:30 -0700 Message-ID: <3CF61904.40109@lucent.com> Date: Thu, 30 May 2002 08:20:20 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523 MIME-Version: 1.0 To: "R. Muralidharan" CC: "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Seems we have mixed up a "ring topology" from "ring protection mechanism". * In a general ring topology, *any* recovery mechanism may be used. This may be the underlying transport's BLSR/MSSPRING or UPSR/SNCPRING, or it may be using control plane to set up 1+1 or 1:1. * In a BLSR/MSSPRING ring, the type of protection has already been decided (i.e., BLSR *is* the name of the protection mechanism). Similarly for UPSR/SNCPRING. Thus if we're talking about BLSR/UPSR rings, then the question is: how does the control plane protocols interact (do they interact?) with the underlying BLSR/UPSR, e.g., does the control plane simply treat the *entire* ring as a single node and thus interfaces to existing EMSs to ask for a sub-network connection across the "node", or does the control plane actually see all nodes of the ring and ask individual nodes for an STS-1/VC-3 connection (but note it only asks for the normal channel i.e. one connection, since the protection channel comes by default -- the service is either protected or unprotected but one connection in either case)... Zhi R. Muralidharan wrote: >Hi All, > >My understanding is as follows: > > BLSR or UPSR rings may be already provisioned in the SONET network. The >task using GMPLS is to set up an end to end virtual path, may be >encompassing multiple SONET rings. This virtual path set up is dynamic in >nature and the life of the path may be only for a fixed interval, after >which it would be tore down. When one wants to set up a path through a SONET >ring, one may have to specify whether one wants a 1+1 protection path or a >1:N protection path or just an unprotected path. Based on this specification >the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR >ring as the case may be and hence the cost would be optimum. ( assuming that >a 1+1 path would cost more than an unprotected path). As Greg pointed out, I >also believe that the BLSR and UPSR ring configurations would already have >been set up by associated NMS or EMS and advertised. The granularity of the >path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT >Path) or STS-1s (STS Path). > >I have used the words "path" and "virtual path" in generic terms and not in >the SONET or SDH domain definitions. > >Does the above make sense ? >regards, >murali >OSS Systems India > >----- Original Message ----- >From: "Bernstein, Greg" >To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" > >Cc: "mpls@UU. NET (E-mail)" >Sent: Wednesday, May 29, 2002 10:28 PM >Subject: RE: Sonet Ring provisioning > > > > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that >> >> >you > > >>are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their >> >> >SDH > > >>equivalent. >>Then >>(1) In the BLSR case the protection is at the SONET line layer, i.e., >> >> >below > > >>the layer of the connection that you are setting up(SONET/SDH are layered >>networks). In this case no special action needs to be taken unless of >>course the entity requesting the connection asked for "enhanced" >> >> >protection > > >>in the setup request. >> >>(2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the >>redundant paths taking different routes around the ring. Hence you are >>actually setting up two connections that have a special relationship with >>each other. This would have to be indicated somehow (tunnel ID or >>something). Some UPSRs may put constraints on the timeslots used too. One >>meta question is why bother signaling around a UPSR versus talking to a >> >> >UPSR > > >>as a separate "protection domain"? There is no way mesh restoration could >>come close to a UPSR's restoration speed (it just selects the better of >> >> >two > > >>signals). Hence I don't understand the benefit signaling around the ring >> >> >in > > >>this case, all vendors have methods for setting up their UPSRs via EMS's >> >> >why > > >>not just interface to those rather than to the individual ring elements... >> >>Greg B. >> >>*********************************** >>Dr. Greg M. Bernstein >>Senior Technology Director, Ciena Corporation >> >> >>-----Original Message----- >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com] >>Sent: Wednesday, May 29, 2002 2:01 AM >>To: 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Sonet Ring provisioning >> >> >>Hi , >> Do we use GMPLS signaling protocol for configuring Sonet Rings ( >> >> >UPSR > > >>/ BLSR ( 2 fiber/4 >> fiber ) ? >> >> I was going through certain white papers where there was a mention >>that GMPLS is used as >> a signaling protocol for provisioning mesh topologies only >>.Traditional Sonet rings will be >> replaced by mesh topologies in future . >> >> But there is a section 12.( LSP protection and restoration) in GMPLS >>Architecture which says >> that " Both mesh and ring like topologies are supported " >> >> How do we provision nodes in Sonet ring using GMPLS ? >> Or GMPLS has been designed to provision mesh topologies only. >> >>Regards , >>Manoj >> >> >> >> >> >> >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 04:33:15 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CF60D83.BF5D3171@lucent.com> Date: Thu, 30 May 2002 13:31:15 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Kireeti, Thanks for your answer. > Reading over the threads again, it appears that "neighbor discovery" > may be a useful function. Agreed. Non manual, fully automatic "neighbor discovery" is an important requirement as also stated in ITU-T G.7714.1. Including neighbor discovery in LMP would also remove the confusion that currently appears to exist on whether or not LMP does specify neighbor discovery. In http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html Jonathan seems to state that LMP *does* include neighbor discovery. However, this type of neighbor discovery is rather manual and not in line with ITU-T G.7714.1. > However, LMP is a *link* management protocol, > where neighbors are configured (at least as a starting point), and > *links* are discovered, and link properties correlated. I guess you are here referring to TE-links as opposed to dataLinks ? The proposed addition to LMP discovers dataLinks. I don't see it as a problem that subsequent link property correlation groups all dataLinks together and correlates the full TE-link in one IP message. Compared to correlating individual dataLinks, correlating a full TE-link has advantages performance wise. Why do you see it as a problem that the described neighbor discovery procedure discovers the neighbor on an individual dataLink ? For example, the existing LMP function "Fault Management" is built on discovering the faults on individual dataLinks. > My suggestion (as co-chair) is that LMP proceed as is, and if folks > think that neighbor management is a useful function, then they can > write a draft, perhaps building on LMP, and we'll judge WG interest > in this function. As you might have noted, my neighbor discovery proposal does *not* include a *single* IP message. It is simply making use of an existing function in the transport layer: reading the access point identifier. In my mind, it would therefore be strange to write a separate ID to define this neighbor discovery function. Moreover, this new ID would indeed be heavily building on LMP to provide the subsequent link correlation. Could you please let me know what you see as advantages of defining neighbor discovery in a separate ID ? > To my mind (as implementor), the notion of control channel seems simple > enough; a control network is one instantiation of a control channel. This statement seems to be in conflict with an earlier statement that a "control channel" runs on top of an existing "control network" (it is a "routed control channel"). Related to your assessment of "control channels" being simple: did you include in that assessment the need to carefully provision the timers related to RSVP-TE hellos, LMP control channel hellos and the "control network" IGP hellos ? You might want to re-read http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > If this proposal is not in line with your view, I'm looking forward > > to a continued discussion on the three indicated email threads ! > > Excellent idea! As I said, if there is interest, the best way to proceed > is to follow up with an ID. In my mind there are two ways to proceed: 1. Don't accept the proposed changes in LMP. 2. Accept the proposed changes in LMP. If option (1) is chosen, I would at least like to have within the LMP draft: - Clarification on "control channel" (thread "Question on LMP") - Clarification on when the link verification procedure is applicable (thread "applicability of LMP's verify procedure") - Clarification on whether or not LMP includes neighbor discovery. Of course my preference would be option (2). Best regards, Michiel Kireeti Kompella wrote: > > On Thu, 23 May 2002, Michiel van Everdingen wrote: > > > Hello Jonathan, Kireeti, Ron, > > > > Judging on the information in three e-mail threads (first and last email > > indicated): > > - Question on LMP > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > > - LMP & neighbor discovery > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > - applicability of LMP's verify procedure > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > > I would propose to make the following modifications to the LMP draft, > > version 03: > > - Include a section on neighbor discovery > > Details can be found in > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html > > Reading over the threads again, it appears that "neighbor discovery" > may be a useful function. However, LMP is a *link* management protocol, > where neighbors are configured (at least as a starting point), and > *links* are discovered, and link properties correlated. > > My suggestion (as co-chair) is that LMP proceed as is, and if folks > think that neighbor management is a useful function, then they can > write a draft, perhaps building on LMP, and we'll judge WG interest > in this function. > > > - Remove the concept of "control channel" and accept that signalling > > messages are carried over the "control network". > > To my mind (as implementor), the notion of control channel seems simple > enough; a control network is one instantiation of a control channel. > > > If this proposal is not in line with your view, I'm looking forward > > to a continued discussion on the three indicated email threads ! > > Excellent idea! As I said, if there is interest, the best way to proceed > is to follow up with an ID. > > Kireeti. -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 30 May 2002 02:14:58 -0700 Message-ID: <003601c207b6$cf4bf860$1000a8c0@ossi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "R. Muralidharan" To: "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: Re: Sonet Ring provisioning Date: Thu, 30 May 2002 14:18:46 +0530 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi All, My understanding is as follows: BLSR or UPSR rings may be already provisioned in the SONET network. The task using GMPLS is to set up an end to end virtual path, may be encompassing multiple SONET rings. This virtual path set up is dynamic in nature and the life of the path may be only for a fixed interval, after which it would be tore down. When one wants to set up a path through a SONET ring, one may have to specify whether one wants a 1+1 protection path or a 1:N protection path or just an unprotected path. Based on this specification the GMPLS can discover and set up an appropriate path in a BLSR or an UPSR ring as the case may be and hence the cost would be optimum. ( assuming that a 1+1 path would cost more than an unprotected path). As Greg pointed out, I also believe that the BLSR and UPSR ring configurations would already have been set up by associated NMS or EMS and advertised. The granularity of the path that can be set up using GMPLS could a VT1.5 or multiples of them ( VT Path) or STS-1s (STS Path). I have used the words "path" and "virtual path" in generic terms and not in the SONET or SDH domain definitions. Does the above make sense ? regards, murali OSS Systems India ----- Original Message ----- From: "Bernstein, Greg" To: "'Manoj Agiwal'" ; "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Sent: Wednesday, May 29, 2002 10:28 PM Subject: RE: Sonet Ring provisioning > Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that you > are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their SDH > equivalent. > Then > (1) In the BLSR case the protection is at the SONET line layer, i.e., below > the layer of the connection that you are setting up(SONET/SDH are layered > networks). In this case no special action needs to be taken unless of > course the entity requesting the connection asked for "enhanced" protection > in the setup request. > > (2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the > redundant paths taking different routes around the ring. Hence you are > actually setting up two connections that have a special relationship with > each other. This would have to be indicated somehow (tunnel ID or > something). Some UPSRs may put constraints on the timeslots used too. One > meta question is why bother signaling around a UPSR versus talking to a UPSR > as a separate "protection domain"? There is no way mesh restoration could > come close to a UPSR's restoration speed (it just selects the better of two > signals). Hence I don't understand the benefit signaling around the ring in > this case, all vendors have methods for setting up their UPSRs via EMS's why > not just interface to those rather than to the individual ring elements... > > Greg B. > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > > -----Original Message----- > From: Manoj Agiwal [mailto:ManojA@netbrahma.com] > Sent: Wednesday, May 29, 2002 2:01 AM > To: 'Ccamp (E-mail) > Cc: mpls@UU. NET (E-mail) > Subject: Sonet Ring provisioning > > > Hi , > Do we use GMPLS signaling protocol for configuring Sonet Rings ( UPSR > / BLSR ( 2 fiber/4 > fiber ) ? > > I was going through certain white papers where there was a mention > that GMPLS is used as > a signaling protocol for provisioning mesh topologies only > .Traditional Sonet rings will be > replaced by mesh topologies in future . > > But there is a section 12.( LSP protection and restoration) in GMPLS > Architecture which says > that " Both mesh and ring like topologies are supported " > > How do we provision nodes in Sonet ring using GMPLS ? > Or GMPLS has been designed to provision mesh topologies only. > > Regards , > Manoj > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 May 2002 10:01:49 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B126@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Manoj Agiwal'" , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Sonet Ring provisioning Date: Wed, 29 May 2002 09:58:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Manoj, the UPSR and BLSR cases are very different. I'm assuming that you are setting up SONET paths such as STS-1, STS-3c, ... STS-192c or their SDH equivalent. Then (1) In the BLSR case the protection is at the SONET line layer, i.e., below the layer of the connection that you are setting up(SONET/SDH are layered networks). In this case no special action needs to be taken unless of course the entity requesting the connection asked for "enhanced" protection in the setup request. (2) A UPSR works at the path layer, i.e., like a path layer 1+1, with the redundant paths taking different routes around the ring. Hence you are actually setting up two connections that have a special relationship with each other. This would have to be indicated somehow (tunnel ID or something). Some UPSRs may put constraints on the timeslots used too. One meta question is why bother signaling around a UPSR versus talking to a UPSR as a separate "protection domain"? There is no way mesh restoration could come close to a UPSR's restoration speed (it just selects the better of two signals). Hence I don't understand the benefit signaling around the ring in this case, all vendors have methods for setting up their UPSRs via EMS's why not just interface to those rather than to the individual ring elements... Greg B. *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Manoj Agiwal [mailto:ManojA@netbrahma.com] Sent: Wednesday, May 29, 2002 2:01 AM To: 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Sonet Ring provisioning Hi , Do we use GMPLS signaling protocol for configuring Sonet Rings ( UPSR / BLSR ( 2 fiber/4 fiber ) ? I was going through certain white papers where there was a mention that GMPLS is used as a signaling protocol for provisioning mesh topologies only .Traditional Sonet rings will be replaced by mesh topologies in future . But there is a section 12.( LSP protection and restoration) in GMPLS Architecture which says that " Both mesh and ring like topologies are supported " How do we provision nodes in Sonet ring using GMPLS ? Or GMPLS has been designed to provision mesh topologies only. Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 29 May 2002 03:56:19 -0700 Date: Wed, 29 May 2002 03:53:57 -0700 (PDT) From: Kireeti Kompella To: Michiel van Everdingen cc: Subject: Re: LMP & neighbor discovery Message-ID: <20020529034226.I27567-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 23 May 2002, Michiel van Everdingen wrote: > Hello Jonathan, Kireeti, Ron, > > Judging on the information in three e-mail threads (first and last email > indicated): > - Question on LMP > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html > - LMP & neighbor discovery > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > - applicability of LMP's verify procedure > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > I would propose to make the following modifications to the LMP draft, > version 03: > - Include a section on neighbor discovery > Details can be found in > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html Reading over the threads again, it appears that "neighbor discovery" may be a useful function. However, LMP is a *link* management protocol, where neighbors are configured (at least as a starting point), and *links* are discovered, and link properties correlated. My suggestion (as co-chair) is that LMP proceed as is, and if folks think that neighbor management is a useful function, then they can write a draft, perhaps building on LMP, and we'll judge WG interest in this function. > - Remove the concept of "control channel" and accept that signalling > messages are carried over the "control network". To my mind (as implementor), the notion of control channel seems simple enough; a control network is one instantiation of a control channel. > If this proposal is not in line with your view, I'm looking forward > to a continued discussion on the three indicated email threads ! Excellent idea! As I said, if there is interest, the best way to proceed is to follow up with an ID. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 May 2002 16:32:25 -0700 Message-Id: <4.3.2.7.2.20020528191825.0222b6a8@mo-ex1> Date: Tue, 28 May 2002 19:24:27 -0400 To: ccamp@ops.ietf.org From: Lou Berger Subject: gmpls signaling survey update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In the next couple of days we'll be submitting an update to the gmpls signaling survey. If you'd like to add your implementation to the survey, please complete http://www.labn.net/gmpls-survey/sig-survey.txt. Thanks, Lou Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 28 May 2002 03:37:38 -0700 Message-ID: <3CF35CE1.3307B147@wipro.com> Date: Tue, 28 May 2002 16:03:05 +0530 From: Vinay Vernekar MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: mpls@UU.NET Subject: Identifying a kind of LSP in GMPLS. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The draft "draft-ietf-mpls-generalized-signalling-08.txt" specifies the LSP encoding type, switching type and the payload being carried in the Generalized Label Request. It is not clear on how to identify the LSP kind by looking at the values mentioned. Consider the following cases - 1) What are the typical values if a LSP traversing ATM switches is to be established? Is it like - LSP Encoding type - Packet Switching type - L2SC GPID - ATM Mapping. (But the draft specifies ATM mapping for SDH/SONET technologies). 2) What are the values if a LSP traversing FR switches is to be established? There is nothing like GPID - FR?? Please clarify on the above. Regards Vinay Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 27 May 2002 06:06:48 -0700 Message-Id: <4.3.2.7.2.20020527090022.01bf0e40@bucket.cisco.com> Date: Mon, 27 May 2002 09:00:27 -0400 To: "Michael I Mandelberg(Isaac)" From: "Thomas D. Nadeau" Subject: Re: Link Bundle MIB is AWOL Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-02.txt >I can't seem to get the latest version of the Link Bundle MIB from the IETF >site. Is it available? > >Thanks > >Michael Mandelberg ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 24 May 2002 04:23:36 -0700 Message-Id: <200205241121.HAA23303@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-sdhsonet-control-01.txt Date: Fri, 24 May 2002 07:21: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 : Framework for GMPLS-based Control of SDH/SONET Networks Author(s) : G. Bernstein, E. Mannie, V. Sharma Filename : draft-ietf-ccamp-sdhsonet-control-01.txt Pages : 26 Date : 23-May-02 The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. One area of prime consideration is to use these generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to MPLS protocols that are directed towards controlling SONET/SDH networks. SONET/SDH networks make very good examples of this process since they possess a rich multiplex structure, a variety of protection/restoration options, are well defined, and are widely deployed. The document discusses extensions to MPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to MPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an MPLS control plane would bring to SONET/SDH networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-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-sdhsonet-control-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-sdhsonet-control-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: <20020523132534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-sdhsonet-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132534.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 May 2002 15:47:59 -0700 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Subject: Link Bundle MIB is AWOL Date: Thu, 23 May 2002 18:42:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I can't seem to get the latest version of the Link Bundle MIB from the IETF site. Is it available? Thanks Michael Mandelberg Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 May 2002 09:23:22 -0700 Message-Id: <4.3.2.7.2.20020523121311.0275acf8@sword.cisco.com> Date: Thu, 23 May 2002 12:21:02 -0400 To: "Liran Siglat" , From: Zafar Ali Subject: RE: IGPs and LMP's TE-link Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8045198==_.ALT" --=====================_8045198==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:33 AM 5/23/2002 +0300, Liran Siglat wrote: >Hi, > >I'll try to clarify the question with an example: > >We have 4 data-links a,b,c,d. >We define 2 TE-links: TEL1 containing a&b, TEL2 containing c&d. >Which components may the UNI use? for which purposes? >Which components may the IGP use? for which purposes? >Which components may the TE engine use for CSPF? for which purposes? >Which 'logical' interfaces will the local UNI-C have towards the remote >UNI-C? a,b,c &d or TEL1 & TEL2? > >Thanks, Liran. Hi Liran, Unless I miss-understood your question again, the answer to your question depends on how the users would like to configure the TE link TEL1 and TEL2, i.e., with UNI 1.0 or G-MPLS. The only restriction would be that all component links of a TE link belong to the same application the TE link is configured with. Also, CSPF works at the TE link level. Thanks Regards... Zafar >-----Original Message----- >From: Zafar Ali [mailto:zali@cisco.com] >Sent: Wednesday, May 22, 2002 8:40 PM >To: Liran Siglat; ccamp@ops.ietf.org >Subject: Re: IGPs and LMP's TE-link > >Dear Liran, > >BTW, I've found your questions rather confusing. Any way, the following >are the related comments, > * There is no difference (as such) between the way a TE link is > represented by LMP and within IGP (with the exception of the level of > details each protocol is concerned with). > * There is no direct relation between UNI 1.0 and IGP. However, once > UNI connection(s) is (are) established, one may run IGPs on that (these) > connections (either in a bundled or unbundled configuration). But this > case does not require any standard specification. > * Multiple component links between UNI-C and UNI-N can be regarded as > TE links without an IGP adjacency. But one can run LMP on such TE Links. >Hope this helps. > >Thanks > >Regards... Zafar > >At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote: >>Hi, >> >>I have a question regarding the way LMP's TE-link is observed by IGPs. >> >>In case a connection was established between 2 UNI-Cs over a TE-link >>(aggregating multiple data-bearing links), does an IGP running on the >>UNI-C see the TE-link as a new interface (with the capacity of all the >>data-links) or does it see multiple interfaces (each one corresponds to a >>data-link) ? > >=============================================== >Zafar Ali >Cisco Systems >100 S Main St. #200 >Ann Arbor, MI 48104. >Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190 >email: zali@cisco.com --=====================_8045198==_.ALT Content-Type: text/html; charset="us-ascii" At 09:33 AM 5/23/2002 +0300, Liran Siglat wrote:
Hi,
 
I'll try to clarify the question with an example:
 
We have 4 data-links a,b,c,d.
We define 2 TE-links: TEL1 containing a&b, TEL2 containing c&d.
Which components may the UNI use? for which purposes?
Which components may the IGP use? for which purposes?
Which components may the TE engine use for CSPF? for which purposes?
Which 'logical' interfaces will the local UNI-C have towards the remote UNI-C? a,b,c &d or TEL1 & TEL2?
 
Thanks, Liran.

Hi Liran,

Unless I miss-understood your question again, the answer to your question depends on how the users would like to configure the TE link TEL1 and TEL2, i.e., with UNI 1.0 or G-MPLS. The only restriction would be that all component links of a TE link belong to the same application the TE link is configured with. Also, CSPF works at the TE link level.

Thanks

Regards... Zafar 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 22, 2002 8:40 PM
To: Liran Siglat; ccamp@ops.ietf.org
Subject: Re: IGPs and LMP's TE-link
Dear Liran,

BTW, I've found your questions rather confusing. Any way, the following are the related comments,
  • There is no difference (as such) between the way a TE link is represented by LMP and within IGP (with the exception of the level of details each protocol is concerned with).
  • There is no direct relation between UNI 1.0 and IGP. However, once UNI connection(s) is (are) established, one may run IGPs on that (these) connections (either in a bundled or unbundled configuration). But this case does not require any standard specification.
  • Multiple component links between UNI-C and UNI-N can be regarded as TE links without an IGP adjacency. But one can run LMP on such TE Links.
Hope this helps.

Thanks

Regards... Zafar 

At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote:
Hi,

I have a question regarding the way LMP's TE-link is observed by IGPs.

In case a connection was established between 2 UNI-Cs over a TE-link (aggregating multiple data-bearing links), does an IGP running on the UNI-C see the TE-link as a new interface (with the capacity of all the data-links) or does it see multiple interfaces (each one corresponds to a data-link) ?

===============================================
Zafar Ali
Cisco Systems
100 S Main St. #200
Ann Arbor, MI 48104.
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190
email: zali@cisco.com
--=====================_8045198==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 23 May 2002 05:54:35 -0700 To: Ron Bonica , Kireeti Kompella , Jonathan Lang Cc: ccamp@ops.ietf.org, Scott Bradner , Bert Wijnen Message-ID: <3CECE5E4.A18B38C2@lucent.com> Date: Thu, 23 May 2002 14:51:48 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 Original-To: Ron Bonica , Kireeti Kompella , Jonathan Lang Original-CC: ccamp@ops.ietf.org, Scott Bradner , Bert Wijnen Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, Kireeti, Ron, Judging on the information in three e-mail threads (first and last email indicated): - Question on LMP http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html - LMP & neighbor discovery http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html - applicability of LMP's verify procedure http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html I would propose to make the following modifications to the LMP draft, version 03: - Include a section on neighbor discovery Details can be found in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html - Remove the concept of "control channel" and accept that signalling messages are carried over the "control network". If this proposal would be followed, this would lead to: - A simplification of the LMP draft: control channel management is not needed anymore. - Enhancement of the LMP draft: automatic neighbor discovery is possible without any assumptions on the configuration of the control network. Your ideas on how to proceed would be appreciated. If this proposal is not in line with your view, I'm looking forward to a continued discussion on the three indicated email threads ! Best regards, Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 23:33:38 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20223.B3C6599B" Subject: RE: IGPs and LMP's TE-link Date: Thu, 23 May 2002 09:33:08 +0300 Message-ID: Thread-Topic: IGPs and LMP's TE-link Thread-Index: AcIBt7a37zSFe3/0SKSSW8PAbQHAhAAa5Owg From: "Liran Siglat" To: "Zafar Ali" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C20223.B3C6599B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I'll try to clarify the question with an example: =20 We have 4 data-links a,b,c,d.=20 We define 2 TE-links: TEL1 containing a&b, TEL2 containing c&d. Which components may the UNI use? for which purposes? Which components may the IGP use? for which purposes? Which components may the TE engine use for CSPF? for which purposes? Which 'logical' interfaces will the local UNI-C have towards the remote = UNI-C? a,b,c &d or TEL1 & TEL2? =20 Thanks, Liran. -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 22, 2002 8:40 PM To: Liran Siglat; ccamp@ops.ietf.org Subject: Re: IGPs and LMP's TE-link Dear Liran,=20 BTW, I've found your questions rather confusing. Any way, the following = are the related comments,=20 * There is no difference (as such) between the way a TE link is = represented by LMP and within IGP (with the exception of the level of = details each protocol is concerned with).=20 * There is no direct relation between UNI 1.0 and IGP. However, once UNI = connection(s) is (are) established, one may run IGPs on that (these) = connections (either in a bundled or unbundled configuration). But this = case does not require any standard specification.=20 * Multiple component links between UNI-C and UNI-N can be regarded as TE = links without an IGP adjacency. But one can run LMP on such TE Links.=20 Hope this helps.=20 Thanks Regards... Zafar =20 At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote: Hi, I have a question regarding the way LMP's TE-link is observed by IGPs. In case a connection was established between 2 UNI-Cs over a TE-link = (aggregating multiple data-bearing links), does an IGP running on the = UNI-C see the TE-link as a new interface (with the capacity of all the = data-links) or does it see multiple interfaces (each one corresponds to = a data-link) ? =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 Zafar Ali Cisco Systems 100 S Main St. #200 Ann Arbor, MI 48104. Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190 email: zali@cisco.com=20 ------_=_NextPart_001_01C20223.B3C6599B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'll=20 try to clarify the question with an example:
 
We=20 have 4 data-links a,b,c,d.
We=20 define 2 TE-links: TEL1 containing a&b, TEL2 containing=20 c&d.
Which=20 components may the = UNI use? for=20 which purposes?
Which=20 components may the = IGP use? for=20 which purposes?
Which=20 components may the TE = engine use=20 for CSPF? for which purposes?
Which=20 'logical' interfaces will = the local=20 UNI-C have towards the remote UNI-C? a,b,c &d or TEL1 &=20 TEL2?
 
Thanks, = Liran.
-----Original Message-----
From: Zafar Ali=20 [mailto:zali@cisco.com]
Sent: Wednesday, May 22, 2002 8:40=20 PM
To: Liran Siglat; ccamp@ops.ietf.org
Subject: = Re: IGPs=20 and LMP's TE-link

Dear Liran, =

BTW,=20 I've found your questions rather confusing. Any way, the following are = the=20 related comments,=20
  • There is no difference (as such) between the way a TE link is=20 represented by LMP and within IGP (with the exception of the level = of=20 details each protocol is concerned with).=20
  • There is no direct relation between UNI 1.0 and IGP. However, = once UNI=20 connection(s) is (are) established, one may run IGPs on that (these) = connections (either in a bundled or unbundled configuration). But = this case=20 does not require any standard specification.=20
  • Multiple component links between UNI-C and UNI-N can be regarded = as TE=20 links without an IGP adjacency. But one can run LMP on such TE = Links.=20
Hope this helps.

Thanks

Regards... = Zafar =20

At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote:
Hi,

I have a question regarding = the way=20 LMP's TE-link is observed by IGPs.

In case a connection was=20 established between 2 UNI-Cs over a TE-link (aggregating multiple=20 data-bearing links), does an IGP running on the UNI-C see the = TE-link as a=20 new interface (with the capacity of all the data-links) or does it = see=20 multiple interfaces (each one corresponds to a data-link)=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=3D= =3D=3D=3D
Zafar=20 Ali
Cisco Systems
100 S Main St. #200
Ann Arbor, MI=20 48104.
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734)=20 302-4190
email: zali@cisco.com
------_=_NextPart_001_01C20223.B3C6599B-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 23:18:22 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: LMP's TE-link FSM Date: Thu, 23 May 2002 09:15:44 +0300 Message-ID: Thread-Topic: LMP's TE-link FSM Thread-Index: AcICIUD0qUyHVGK6RZm+irV9lKKlEg== From: "Liran Siglat" To: Hi, Can someone clarify the two following states of the TE-link FSM (as = defined in draft-ietf-ccamp-lmp-03.txt) :=20 Up - Does this state mean: a. The Te-link is now ready to carry data meaning the signaling protocol = has successfully established a=20 connection and the two UNI-Cs are connected. b. Only the negotiation between the UNI-C and the UNI-N has finished = (and now the signaling protocol=20 can try to establish a connection between both UNI-Cs). c. Other option - ? Degraded - Does this state mean: a. The TE-link is actually carrying data traffic now, but all primary = CCs are down. b. The TE-link still includes some data-links that are allocated to data = traffic (but, they might not be=20 actually carrying data traffic since the signaling protocol failed to = establish a connection between both UNI-Cs) and all primary CCs are down. c. Other option - ? Thanks, Liran. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 14:57:02 -0700 Message-ID: From: "Juneja, Manoj" To: "'v.sharma@ieee.org'" , manoj juneja, george.young@meriton.com Cc: ccamp@ops.ietf.org Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 14:55:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Vishal, I want to get the information about those error conditions which trigger the generation of PathErr/ResvErr or both at a node along with the Notify Message. Are these error conditions related to Invalid label errors etc ? Regards, manoj. -----Original Message----- From: Vishal Sharma [mailto:v.sharma@ieee.org] Sent: Wednesday, May 22, 2002 2:30 PM To: manoj juneja; george.young@meriton.com Cc: ccamp@ops.ietf.org Subject: RE: Notify Message Doubt Manoj, I am not sure why you would want to use the Notify for "general" failures, for which failures codes and procedures already exist using standard RSVP-TE or CR-LDP mechanisms? -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of manoj juneja > Sent: Wednesday, May 22, 2002 1:59 PM > To: v.sharma@ieee.org; george.young@meriton.com > Cc: ccamp@ops.ietf.org > Subject: RE: Notify Message Doubt > > > Hi Vishal/George, > > What are the possible failure cases in which the notify > message should > be sent ? Can I assume generic failure conditions like > NO_ROUTE_TO_DESTINATION, ADMISSION_CONTROL_FAILURE etc. during the LSP > establishment also lead to transmission of notify message (assuming > notify_request object has been received) ? > OR Is it that failures occuring in the data path (optical layer) > can lead to > trnasmission of notify message ? > > Regards, > manoj. > > > >From: "Vishal Sharma" > >Reply-To: > >To: "manoj juneja" , > > > >CC: > >Subject: RE: Notify Message Doubt > >Date: Wed, 22 May 2002 11:30:16 -0700 > > > >Manoj, > > > >I don't think that inference is correct. The Notify message > >could be used at any time, but one would probably not use it > >as a replacement for Path/Resv Err messages, since the Notify > >would not cause a change in the state of the intermediate nodes, > >where as the Path/Resv Err would. > > > >Furthermore, the Notify is not guaranteed to follow the exact same > >path as that followed by the LSP. (That, in fact, is one of > >the features that would allow it to get to the intended node > >in the event of failure.) > > > >-Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of manoj juneja > > > Sent: Wednesday, May 22, 2002 10:54 AM > > > To: george.young@meriton.com > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: Notify Message Doubt > > > > > > > > > Hi George, > > > If this is the only reason then does this mean that Notify > > > Message has a significance only after the primary LSP is established > >and > > > this message can't be used during the primary LSP estblishment/setup. > > > > > > Regards, > > > manoj. > > > > > > >From: "George Young" > > > >To: "manoj juneja" > > > >CC: > > > >Subject: RE: Notify Message Doubt > > > >Date: Wed, 22 May 2002 09:30:32 -0400 > > > > > > > >Hello Manoj, > > > > > > > >Path restoration (i.e. switching over to an existing back-up path at > >the > > > >head and the tail) is one mechanism for quick optical protection. > > > > > > > >I think the RSVP NOTIFY message is a suitable mechanism to > trigger path > > > >restoration. Then RSVP messages (e.g. PathTEAR) can be used to take > >down > > > >the broken path. > > > > > > > >Regards, > > > >George R. Young > > > >Meriton Networks Inc. > > > >3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 > > > >phone: +1 613-270-9279 Ext 287 > > > >fax: +1 613-270-9628 > > > >email: george.young@meriton.com > > > > > > > > >-----Original Message----- > > > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > >Sent: Tuesday, May 21, 2002 6:52 PM > > > > >To: ccamp@ops.ietf.org > > > > >Subject: Notify Message Doubt > > > > > > > > > > > > > > >Hi All, > > > > > It is mentioned in drft > > > > >draft-ietf-mpls-generalized-rsvp-te-07.txt > > > > >(sec. 4.3) that Notify Message provides a mechanism to inform > > > > >non-adjacent > > > > >nodes of LSP related events. > > > > > > > > > >I think the generation of PathErr or ResvErr at a node will > > > > >also trigger the > > > > >generation of Notify message to the notify address as received > > > > >in Path or > > > > >Resv Message. What will the end node need to do when it > > > > >receives the notify > > > > >message prior to path/resv err ? > > > > > > > > > >What will the advantage of sending Notify message to the end > > > > >node before it > > > > >receives path/resv err ? > > > > > > > > > >Please help me in understanding its advantage/significance in > > > > >the optical > > > > >domain. > > > > > > > > > >Regards, > > > > >manoj. > > > > > > > > > >_________________________________________________________________ > > > > >MSN Photos is the easiest way to share and print your photos: > > > > >http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp. > > > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 14:23:35 -0700 Reply-To: From: "Vishal Sharma" To: "manoj juneja" , Cc: Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 14:29:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, I am not sure why you would want to use the Notify for "general" failures, for which failures codes and procedures already exist using standard RSVP-TE or CR-LDP mechanisms? -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of manoj juneja > Sent: Wednesday, May 22, 2002 1:59 PM > To: v.sharma@ieee.org; george.young@meriton.com > Cc: ccamp@ops.ietf.org > Subject: RE: Notify Message Doubt > > > Hi Vishal/George, > > What are the possible failure cases in which the notify > message should > be sent ? Can I assume generic failure conditions like > NO_ROUTE_TO_DESTINATION, ADMISSION_CONTROL_FAILURE etc. during the LSP > establishment also lead to transmission of notify message (assuming > notify_request object has been received) ? > OR Is it that failures occuring in the data path (optical layer) > can lead to > trnasmission of notify message ? > > Regards, > manoj. > > > >From: "Vishal Sharma" > >Reply-To: > >To: "manoj juneja" , > > > >CC: > >Subject: RE: Notify Message Doubt > >Date: Wed, 22 May 2002 11:30:16 -0700 > > > >Manoj, > > > >I don't think that inference is correct. The Notify message > >could be used at any time, but one would probably not use it > >as a replacement for Path/Resv Err messages, since the Notify > >would not cause a change in the state of the intermediate nodes, > >where as the Path/Resv Err would. > > > >Furthermore, the Notify is not guaranteed to follow the exact same > >path as that followed by the LSP. (That, in fact, is one of > >the features that would allow it to get to the intended node > >in the event of failure.) > > > >-Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of manoj juneja > > > Sent: Wednesday, May 22, 2002 10:54 AM > > > To: george.young@meriton.com > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: Notify Message Doubt > > > > > > > > > Hi George, > > > If this is the only reason then does this mean that Notify > > > Message has a significance only after the primary LSP is established > >and > > > this message can't be used during the primary LSP estblishment/setup. > > > > > > Regards, > > > manoj. > > > > > > >From: "George Young" > > > >To: "manoj juneja" > > > >CC: > > > >Subject: RE: Notify Message Doubt > > > >Date: Wed, 22 May 2002 09:30:32 -0400 > > > > > > > >Hello Manoj, > > > > > > > >Path restoration (i.e. switching over to an existing back-up path at > >the > > > >head and the tail) is one mechanism for quick optical protection. > > > > > > > >I think the RSVP NOTIFY message is a suitable mechanism to > trigger path > > > >restoration. Then RSVP messages (e.g. PathTEAR) can be used to take > >down > > > >the broken path. > > > > > > > >Regards, > > > >George R. Young > > > >Meriton Networks Inc. > > > >3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 > > > >phone: +1 613-270-9279 Ext 287 > > > >fax: +1 613-270-9628 > > > >email: george.young@meriton.com > > > > > > > > >-----Original Message----- > > > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > >Sent: Tuesday, May 21, 2002 6:52 PM > > > > >To: ccamp@ops.ietf.org > > > > >Subject: Notify Message Doubt > > > > > > > > > > > > > > >Hi All, > > > > > It is mentioned in drft > > > > >draft-ietf-mpls-generalized-rsvp-te-07.txt > > > > >(sec. 4.3) that Notify Message provides a mechanism to inform > > > > >non-adjacent > > > > >nodes of LSP related events. > > > > > > > > > >I think the generation of PathErr or ResvErr at a node will > > > > >also trigger the > > > > >generation of Notify message to the notify address as received > > > > >in Path or > > > > >Resv Message. What will the end node need to do when it > > > > >receives the notify > > > > >message prior to path/resv err ? > > > > > > > > > >What will the advantage of sending Notify message to the end > > > > >node before it > > > > >receives path/resv err ? > > > > > > > > > >Please help me in understanding its advantage/significance in > > > > >the optical > > > > >domain. > > > > > > > > > >Regards, > > > > >manoj. > > > > > > > > > >_________________________________________________________________ > > > > >MSN Photos is the easiest way to share and print your photos: > > > > >http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp. > > > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 13:59:01 -0700 From: "manoj juneja" To: v.sharma@ieee.org, george.young@meriton.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 13:58:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Vishal/George, What are the possible failure cases in which the notify message should be sent ? Can I assume generic failure conditions like NO_ROUTE_TO_DESTINATION, ADMISSION_CONTROL_FAILURE etc. during the LSP establishment also lead to transmission of notify message (assuming notify_request object has been received) ? OR Is it that failures occuring in the data path (optical layer) can lead to trnasmission of notify message ? Regards, manoj. >From: "Vishal Sharma" >Reply-To: >To: "manoj juneja" , > >CC: >Subject: RE: Notify Message Doubt >Date: Wed, 22 May 2002 11:30:16 -0700 > >Manoj, > >I don't think that inference is correct. The Notify message >could be used at any time, but one would probably not use it >as a replacement for Path/Resv Err messages, since the Notify >would not cause a change in the state of the intermediate nodes, >where as the Path/Resv Err would. > >Furthermore, the Notify is not guaranteed to follow the exact same >path as that followed by the LSP. (That, in fact, is one of >the features that would allow it to get to the intended node >in the event of failure.) > >-Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of manoj juneja > > Sent: Wednesday, May 22, 2002 10:54 AM > > To: george.young@meriton.com > > Cc: ccamp@ops.ietf.org > > Subject: RE: Notify Message Doubt > > > > > > Hi George, > > If this is the only reason then does this mean that Notify > > Message has a significance only after the primary LSP is established >and > > this message can't be used during the primary LSP estblishment/setup. > > > > Regards, > > manoj. > > > > >From: "George Young" > > >To: "manoj juneja" > > >CC: > > >Subject: RE: Notify Message Doubt > > >Date: Wed, 22 May 2002 09:30:32 -0400 > > > > > >Hello Manoj, > > > > > >Path restoration (i.e. switching over to an existing back-up path at >the > > >head and the tail) is one mechanism for quick optical protection. > > > > > >I think the RSVP NOTIFY message is a suitable mechanism to trigger path > > >restoration. Then RSVP messages (e.g. PathTEAR) can be used to take >down > > >the broken path. > > > > > >Regards, > > >George R. Young > > >Meriton Networks Inc. > > >3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 > > >phone: +1 613-270-9279 Ext 287 > > >fax: +1 613-270-9628 > > >email: george.young@meriton.com > > > > > > >-----Original Message----- > > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > >Sent: Tuesday, May 21, 2002 6:52 PM > > > >To: ccamp@ops.ietf.org > > > >Subject: Notify Message Doubt > > > > > > > > > > > >Hi All, > > > > It is mentioned in drft > > > >draft-ietf-mpls-generalized-rsvp-te-07.txt > > > >(sec. 4.3) that Notify Message provides a mechanism to inform > > > >non-adjacent > > > >nodes of LSP related events. > > > > > > > >I think the generation of PathErr or ResvErr at a node will > > > >also trigger the > > > >generation of Notify message to the notify address as received > > > >in Path or > > > >Resv Message. What will the end node need to do when it > > > >receives the notify > > > >message prior to path/resv err ? > > > > > > > >What will the advantage of sending Notify message to the end > > > >node before it > > > >receives path/resv err ? > > > > > > > >Please help me in understanding its advantage/significance in > > > >the optical > > > >domain. > > > > > > > >Regards, > > > >manoj. > > > > > > > >_________________________________________________________________ > > > >MSN Photos is the easiest way to share and print your photos: > > > >http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 13:56:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200205221711.NAA19655@ietf.org> To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: The IESG SUBJECT: Last Call: Generalized MPLS Signaling - CR-LDP Extensions to Proposed Standard Date: Wed, 22 May 2002 13:11:03 -0400 The IESG has received a request from the Common Control and Measurement Plane Working Group to consider Generalized MPLS Signaling - CR-LDP Extensions as a Proposed Standard. The IESG will also consider publication of the following Internet-Drafts as Proposed Standards: o Generalized MPLS Signaling - RSVP-TE Extensions o Generalized MPLS - Signaling Functional Description The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-08.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 11:24:04 -0700 Reply-To: From: "Vishal Sharma" To: "manoj juneja" , Cc: Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 11:30:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, I don't think that inference is correct. The Notify message could be used at any time, but one would probably not use it as a replacement for Path/Resv Err messages, since the Notify would not cause a change in the state of the intermediate nodes, where as the Path/Resv Err would. Furthermore, the Notify is not guaranteed to follow the exact same path as that followed by the LSP. (That, in fact, is one of the features that would allow it to get to the intended node in the event of failure.) -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of manoj juneja > Sent: Wednesday, May 22, 2002 10:54 AM > To: george.young@meriton.com > Cc: ccamp@ops.ietf.org > Subject: RE: Notify Message Doubt > > > Hi George, > If this is the only reason then does this mean that Notify > Message has a significance only after the primary LSP is established and > this message can't be used during the primary LSP estblishment/setup. > > Regards, > manoj. > > >From: "George Young" > >To: "manoj juneja" > >CC: > >Subject: RE: Notify Message Doubt > >Date: Wed, 22 May 2002 09:30:32 -0400 > > > >Hello Manoj, > > > >Path restoration (i.e. switching over to an existing back-up path at the > >head and the tail) is one mechanism for quick optical protection. > > > >I think the RSVP NOTIFY message is a suitable mechanism to trigger path > >restoration. Then RSVP messages (e.g. PathTEAR) can be used to take down > >the broken path. > > > >Regards, > >George R. Young > >Meriton Networks Inc. > >3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 > >phone: +1 613-270-9279 Ext 287 > >fax: +1 613-270-9628 > >email: george.young@meriton.com > > > > >-----Original Message----- > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > >Sent: Tuesday, May 21, 2002 6:52 PM > > >To: ccamp@ops.ietf.org > > >Subject: Notify Message Doubt > > > > > > > > >Hi All, > > > It is mentioned in drft > > >draft-ietf-mpls-generalized-rsvp-te-07.txt > > >(sec. 4.3) that Notify Message provides a mechanism to inform > > >non-adjacent > > >nodes of LSP related events. > > > > > >I think the generation of PathErr or ResvErr at a node will > > >also trigger the > > >generation of Notify message to the notify address as received > > >in Path or > > >Resv Message. What will the end node need to do when it > > >receives the notify > > >message prior to path/resv err ? > > > > > >What will the advantage of sending Notify message to the end > > >node before it > > >receives path/resv err ? > > > > > >Please help me in understanding its advantage/significance in > > >the optical > > >domain. > > > > > >Regards, > > >manoj. > > > > > >_________________________________________________________________ > > >MSN Photos is the easiest way to share and print your photos: > > >http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 11:20:07 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 14:17:19 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C9164DFB@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: Notify Message Doubt Thread-Index: AcIBuXH/PTeY344pQSexkpI+HvnQkAAAmisw From: "George Young" To: "manoj juneja" Cc: Hello Manoj, The path restoration application I described is where my (company's) = interests lie. This possible application is identified in Section 2 of = draft-ietf-mpls-generalized-signaling-08.txt. Others may have other uses for the RSVP NOTIFY message, either after or = during generalized LSP establishment. Regards, George R. Young Meriton Networks Inc. 3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9628 email: george.young@meriton.com >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Wednesday, May 22, 2002 1:54 PM >To: George Young >Cc: ccamp@ops.ietf.org >Subject: RE: Notify Message Doubt > > >Hi George, > If this is the only reason then does this mean that Notify=20 >Message has a significance only after the primary LSP is=20 >established and=20 >this message can't be used during the primary LSP estblishment/setup. > >Regards, >manoj. > >>From: "George Young" >>To: "manoj juneja" >>CC: >>Subject: RE: Notify Message Doubt >>Date: Wed, 22 May 2002 09:30:32 -0400 >> >>Hello Manoj, >> >>Path restoration (i.e. switching over to an existing back-up=20 >path at the=20 >>head and the tail) is one mechanism for quick optical protection. >> >>I think the RSVP NOTIFY message is a suitable mechanism to=20 >trigger path=20 >>restoration. Then RSVP messages (e.g. PathTEAR) can be used=20 >to take down=20 >>the broken path. >> >>Regards, >>George R. Young >>Meriton Networks Inc. >>3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 >>phone: +1 613-270-9279 Ext 287 >>fax: +1 613-270-9628 >>email: george.young@meriton.com >> >> >-----Original Message----- >> >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >> >Sent: Tuesday, May 21, 2002 6:52 PM >> >To: ccamp@ops.ietf.org >> >Subject: Notify Message Doubt >> > >> > >> >Hi All, >> > It is mentioned in drft >> >draft-ietf-mpls-generalized-rsvp-te-07.txt >> >(sec. 4.3) that Notify Message provides a mechanism to inform >> >non-adjacent >> >nodes of LSP related events. >> > >> >I think the generation of PathErr or ResvErr at a node will >> >also trigger the >> >generation of Notify message to the notify address as received >> >in Path or >> >Resv Message. What will the end node need to do when it >> >receives the notify >> >message prior to path/resv err ? >> > >> >What will the advantage of sending Notify message to the end >> >node before it >> >receives path/resv err ? >> > >> >Please help me in understanding its advantage/significance in >> >the optical >> >domain. >> > >> >Regards, >> >manoj. >> > >> >_________________________________________________________________ >> >MSN Photos is the easiest way to share and print your photos: >> >http://photos.msn.com/support/worldwide.aspx >> > >> > >> > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at=20 >http://explorer.msn.com/intl.asp. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 10:55:12 -0700 From: "manoj juneja" To: george.young@meriton.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 10:54:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi George, If this is the only reason then does this mean that Notify Message has a significance only after the primary LSP is established and this message can't be used during the primary LSP estblishment/setup. Regards, manoj. >From: "George Young" >To: "manoj juneja" >CC: >Subject: RE: Notify Message Doubt >Date: Wed, 22 May 2002 09:30:32 -0400 > >Hello Manoj, > >Path restoration (i.e. switching over to an existing back-up path at the >head and the tail) is one mechanism for quick optical protection. > >I think the RSVP NOTIFY message is a suitable mechanism to trigger path >restoration. Then RSVP messages (e.g. PathTEAR) can be used to take down >the broken path. > >Regards, >George R. Young >Meriton Networks Inc. >3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 >phone: +1 613-270-9279 Ext 287 >fax: +1 613-270-9628 >email: george.young@meriton.com > > >-----Original Message----- > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > >Sent: Tuesday, May 21, 2002 6:52 PM > >To: ccamp@ops.ietf.org > >Subject: Notify Message Doubt > > > > > >Hi All, > > It is mentioned in drft > >draft-ietf-mpls-generalized-rsvp-te-07.txt > >(sec. 4.3) that Notify Message provides a mechanism to inform > >non-adjacent > >nodes of LSP related events. > > > >I think the generation of PathErr or ResvErr at a node will > >also trigger the > >generation of Notify message to the notify address as received > >in Path or > >Resv Message. What will the end node need to do when it > >receives the notify > >message prior to path/resv err ? > > > >What will the advantage of sending Notify message to the end > >node before it > >receives path/resv err ? > > > >Please help me in understanding its advantage/significance in > >the optical > >domain. > > > >Regards, > >manoj. > > > >_________________________________________________________________ > >MSN Photos is the easiest way to share and print your photos: > >http://photos.msn.com/support/worldwide.aspx > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 10:40:55 -0700 Message-Id: <4.3.2.7.2.20020522132515.050050c8@sword.cisco.com> Date: Wed, 22 May 2002 13:39:43 -0400 To: "Liran Siglat" , From: Zafar Ali Subject: Re: IGPs and LMP's TE-link Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10977685==_.ALT" --=====================_10977685==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Liran, BTW, I've found your questions rather confusing. Any way, the following are the related comments, * There is no difference (as such) between the way a TE link is represented by LMP and within IGP (with the exception of the level of details each protocol is concerned with). * There is no direct relation between UNI 1.0 and IGP. However, once UNI connection(s) is (are) established, one may run IGPs on that (these) connections (either in a bundled or unbundled configuration). But this case does not require any standard specification. * Multiple component links between UNI-C and UNI-N can be regarded as TE links without an IGP adjacency. But one can run LMP on such TE Links. Hope this helps. Thanks Regards... Zafar At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote: >Hi, > >I have a question regarding the way LMP's TE-link is observed by IGPs. > >In case a connection was established between 2 UNI-Cs over a TE-link >(aggregating multiple data-bearing links), does an IGP running on the >UNI-C see the TE-link as a new interface (with the capacity of all the >data-links) or does it see multiple interfaces (each one corresponds to a >data-link) ? =============================================== Zafar Ali Cisco Systems 100 S Main St. #200 Ann Arbor, MI 48104. Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190 email: zali@cisco.com --=====================_10977685==_.ALT Content-Type: text/html; charset="us-ascii" Dear Liran,

BTW, I've found your questions rather confusing. Any way, the following are the related comments,
  • There is no difference (as such) between the way a TE link is represented by LMP and within IGP (with the exception of the level of details each protocol is concerned with).
  • There is no direct relation between UNI 1.0 and IGP. However, once UNI connection(s) is (are) established, one may run IGPs on that (these) connections (either in a bundled or unbundled configuration). But this case does not require any standard specification.
  • Multiple component links between UNI-C and UNI-N can be regarded as TE links without an IGP adjacency. But one can run LMP on such TE Links.
Hope this helps.

Thanks

Regards... Zafar 

At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote:
Hi,

I have a question regarding the way LMP's TE-link is observed by IGPs.

In case a connection was established between 2 UNI-Cs over a TE-link (aggregating multiple data-bearing links), does an IGP running on the UNI-C see the TE-link as a new interface (with the capacity of all the data-links) or does it see multiple interfaces (each one corresponds to a data-link) ?

===============================================
Zafar Ali
Cisco Systems
100 S Main St. #200
Ann Arbor, MI 48104.
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190
email: zali@cisco.com --=====================_10977685==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 10:09:35 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: IGPs and LMP's TE-link Date: Wed, 22 May 2002 20:06:08 +0300 Message-ID: Thread-Topic: IGPs and LMP's TE-link Thread-Index: AcIBsvMaLdBheJlsRm2wUfDaMpEfdw== From: "Liran Siglat" To: Hi, I have a question regarding the way LMP's TE-link is observed by IGPs. In case a connection was established between 2 UNI-Cs over a TE-link = (aggregating multiple data-bearing links), does an IGP running on the = UNI-C see the TE-link as a new interface (with the capacity of all the = data-links) or does it see multiple interfaces (each one corresponds to = a data-link) ? Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 22 May 2002 06:35:13 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Notify Message Doubt Date: Wed, 22 May 2002 09:30:32 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C9164DF9@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: Notify Message Doubt Thread-Index: AcIBG8y+ydm0hxRlQT6SD1XHhFLzrQAd4FHw From: "George Young" To: "manoj juneja" Cc: Hello Manoj, Path restoration (i.e. switching over to an existing back-up path at the = head and the tail) is one mechanism for quick optical protection.=20 I think the RSVP NOTIFY message is a suitable mechanism to trigger path = restoration. Then RSVP messages (e.g. PathTEAR) can be used to take down = the broken path. Regards, George R. Young Meriton Networks Inc. 3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9628 email: george.young@meriton.com >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Tuesday, May 21, 2002 6:52 PM >To: ccamp@ops.ietf.org >Subject: Notify Message Doubt > > >Hi All, > It is mentioned in drft=20 >draft-ietf-mpls-generalized-rsvp-te-07.txt=20 >(sec. 4.3) that Notify Message provides a mechanism to inform=20 >non-adjacent=20 >nodes of LSP related events. > >I think the generation of PathErr or ResvErr at a node will=20 >also trigger the=20 >generation of Notify message to the notify address as received=20 >in Path or=20 >Resv Message. What will the end node need to do when it=20 >receives the notify=20 >message prior to path/resv err ? > >What will the advantage of sending Notify message to the end=20 >node before it=20 >receives path/resv err ? > >Please help me in understanding its advantage/significance in=20 >the optical=20 >domain. > >Regards, >manoj. > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos:=20 >http://photos.msn.com/support/worldwide.aspx > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 May 2002 22:23:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "Raju Venkatraman" To: mpls@UU.NET Cc: ccamp@ops.ietf.org Subject: IPv6 RSVP Issue Date: Tue, 21 May 2002 19:51:29 +0000 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi All, I was wondering whether you are aware of some socket options for IPV6 to intercept RSVP protocol messages with router alert option on Sun-Solaris OS. Any help, pointer would be appreciated. Is there any other way to intercept RSVP IPv6 messages on Sun-Solaris? Thanks in advance. Raju _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 May 2002 15:52:59 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Notify Message Doubt Date: Tue, 21 May 2002 15:52:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, It is mentioned in drft draft-ietf-mpls-generalized-rsvp-te-07.txt (sec. 4.3) that Notify Message provides a mechanism to inform non-adjacent nodes of LSP related events. I think the generation of PathErr or ResvErr at a node will also trigger the generation of Notify message to the notify address as received in Path or Resv Message. What will the end node need to do when it receives the notify message prior to path/resv err ? What will the advantage of sending Notify message to the end node before it receives path/resv err ? Please help me in understanding its advantage/significance in the optical domain. Regards, manoj. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 May 2002 15:10:47 -0700 Message-ID: <39469E08BD83D411A3D900204840EC557631AE@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Kireeti Kompella'" , "'yakov@juniper.net'" Cc: ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Tue, 21 May 2002 18:02:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Yakov, Kireeti: -> > 1. First of all, your suggestion might not fit well -> > with draft draft-lefaucheur-te-metric-igp-01.txt. -> > That is, just changing TE metric might help you to -> > stop _some_ unwanted LSPs being setup in restart -> > period but not all. (example, LSPs that use IGP metric -> > in OSPF regular LSAs) -> -> Turn that around: Yakov's proposal helps in all the cases that can -> be helped. Do you have a proposal to stop/discourage the setup of -> LSPs that use the IGP metric? You might want to consider RFC3137 in GMPLS restart section. RFC3137 - OSPF Stub Router Advertisement section "1. Motivation" reads, ... o Graceful introduction and removal of the router to/from the network. ... -- Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 21 May 2002 06:41:38 -0700 Date: Tue, 21 May 2002 09:36:45 -0400 From: Dave McDysan Subject: MPLS 2002: Oct. 27-29, Washington D.C. To: Ppvpn , Ccamp , Mpls , Pwe3 Cc: TPC@mpls2002.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Dear Colleagues, The MPLS 2002 Conference will be held in Washington D.C. from October 27 through October 29. See www.mpls2002.com for more information. A group of industry experts on the Technical Program Committee is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a brief proposal to the attention of the Technical Program Committee atTPC@mpls2002.com by June 21, 2002. See above web site for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting edge topics. They are solicting presentations from both the vendor and service provider community on new technologies and operational experience. Regards, David E. McDysan WorldCom Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 20 May 2002 02:59:13 -0700 Message-ID: <3CE8C834.AFACC4D7@alcatel.be> Date: Mon, 20 May 2002 11:56:04 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: venkat CC: ccamp@ops.ietf.org Subject: Re: Label Set Object/Tlv Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii see inline Venkat Dabbara wrote: > > comments inline......... > > ----- Original Message ----- > From: > To: "venkat" > Cc: > Sent: Thursday, May 16, 2002 8:56 PM > Subject: Re: Label Set Object/Tlv > > > hi see in-line > > > > > Venkat Dabbara wrote: > > > > > > > > > hai , > > > > > > In draft-ietf-mpls-generalized-cr-ldp-06.txt > > > 2.5.1. Procedures > > > A Label Set is defined via one or more Label Set TLVs. > > > Specific > > > labels/subchannels can be added to or excluded from a > > > Label > > > Set via > > > Action zero (0) and one (1) TLVs respectively. Ranges > > > of > > > labels/subchannels can be added to or excluded from a > > > Label > > > Set via > > > Action two (2) and three (3) TLVs respectively. > > > > > > The first line of the sec 2.5.1 says a label set is defined via > > > one or > > > more LabelSet TLVs. My interpretation > > > about this is that a label request can have multiple Label Set > > > TLVs in > > > it with different action types corresponding > > > to each label set TLV. Am i right ?? > > > > i think so > > > > > If i am wrong please do clarify ... > > > > > > If yes, then assume i get a request with one label set TLV with > > > action > > > type 0 which has a list of labels > > > and other Label set TLV with action type 1 which has a range of > > > Labels. > > > Now in this case i go about > > > picking up a label from the second label set TLV only if i am not > > > able > > > to pick up a label from the first > > > label set TLV....Is that true ?? > > > > i think the operation is > > label set := label set tlv[1] AND label set tlv[2] AND ... label set > > tlv[n] > > and not, if not label set tlv[1] then label set tlv[2] etc. think > > because > > the action refer to the whole label set as indicated in gmpls-sig > > Sir, as per my understanding action type refers to individual label set TLV > in a > label set. > Your argument is confusing. Suppose i go with ur argument and > when i have two disjoint label set TLV as a part of label set, then my valid > label set > becomes all the labels in the first label set TLV plus all the labels in the > label set TLV. > This is what u meant ?? yes see below > N consider the same situation now with two intersecting label set TLVs as a > part of label set. > As per ur argument, now the valid label set will be the intersection of the > two or the bigger label > set TLV ?? the label set is defined as the union of the labels each of the label set tlvs/objects refers to, processing is performed on the resulting label set > Infact i would consider this situation to be misleading one. Some thing > similar to the situations > u have listed below. misleading in which sense, the point is to be capable to tackle all the potential cases, if one of these cases has no meaning at all one generates an error (see below) > Please do clarify . i would have better use the term UNION instead of the above to explain this; the point is to be capable to list an individual list UNION an inclusive range for instance: 1,3,5,7-11 would be include individual[1,3,5] UNION include range[7-11]; thus one expect here to see disjoint label values (in each set) or if this happen a common action such that no problems as the ones explained here below would occur (ie different actions with non-disjoint value) once again, when situation such as the following occurs: - include label x and exclude label x - include label x and exclude label range [k,..,z] - include label range [t,..,y] and exclude label range [k,..,z] thus when the exclude set is larger than include set (ie over a non-disjoint value set) an error should be generated. hope this clarifies. > thanks > venkat > > > > > > Now situation may get even worse when i have a Label set TLV with > > > action > > > type to include a label > > > set and other Label Set TLV with action type exclude. I knoe such > > > situations are not practical but > > > sure needs to be handled someway. > > > > when conditions such as > > - include label x AND exclude label x > > - include label x AND exclude label range [k,..,z] > > - include label range [t,..,y] AND exclude label range [k,..,z] > > > > thus when the exclude set is larger and include the include > > set, an error should be generated. > > > > - dimitri. > > > > > Please do clarify > > > > > > venkat > > > > > > PS: Please don't bother about the disclaimer which come attached with > > > this > > > mail. > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Website: http://www.rc.bel.alcatel.be/~papadimd/index.html > > Address: Alcatel - Optical NA, Fr. Wellesplein, 1 > > B-2018 Antwerpen, Belgium > > Phone: Work: +32 3 2408491 - Home: +32 2 3434361 > > Name: Wipro_Disclaimer.txt > Wipro_Disclaimer.txt Type: Text Document (application/x-unknown-content-type-txtfile) > Encoding: x-uuencode -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 19 May 2002 23:17:30 -0700 Message-ID: <00af01c1ffa0$03716d60$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: Cc: Subject: Re: Label Set Object/Tlv Date: Mon, 20 May 2002 11:45:25 +1000 Organization: wipro technologies comments inline......... ----- Original Message ----- From: To: "venkat" Cc: Sent: Thursday, May 16, 2002 8:56 PM Subject: Re: Label Set Object/Tlv > hi see in-line > > > Venkat Dabbara wrote: > > > > > > hai , > > > > In draft-ietf-mpls-generalized-cr-ldp-06.txt > > 2.5.1. Procedures > > A Label Set is defined via one or more Label Set TLVs. > > Specific > > labels/subchannels can be added to or excluded from a > > Label > > Set via > > Action zero (0) and one (1) TLVs respectively. Ranges > > of > > labels/subchannels can be added to or excluded from a > > Label > > Set via > > Action two (2) and three (3) TLVs respectively. > > > > The first line of the sec 2.5.1 says a label set is defined via > > one or > > more LabelSet TLVs. My interpretation > > about this is that a label request can have multiple Label Set > > TLVs in > > it with different action types corresponding > > to each label set TLV. Am i right ?? > > i think so > > > If i am wrong please do clarify ... > > > > If yes, then assume i get a request with one label set TLV with > > action > > type 0 which has a list of labels > > and other Label set TLV with action type 1 which has a range of > > Labels. > > Now in this case i go about > > picking up a label from the second label set TLV only if i am not > > able > > to pick up a label from the first > > label set TLV....Is that true ?? > > i think the operation is > label set := label set tlv[1] AND label set tlv[2] AND ... label set > tlv[n] > and not, if not label set tlv[1] then label set tlv[2] etc. think > because > the action refer to the whole label set as indicated in gmpls-sig Sir, as per my understanding action type refers to individual label set TLV in a label set. Your argument is confusing. Suppose i go with ur argument and when i have two disjoint label set TLV as a part of label set, then my valid label set becomes all the labels in the first label set TLV plus all the labels in the label set TLV. This is what u meant ?? N consider the same situation now with two intersecting label set TLVs as a part of label set. As per ur argument, now the valid label set will be the intersection of the two or the bigger label set TLV ?? Infact i would consider this situation to be misleading one. Some thing similar to the situations u have listed below. Please do clarify . thanks venkat > > > Now situation may get even worse when i have a Label set TLV with > > action > > type to include a label > > set and other Label Set TLV with action type exclude. I knoe such > > situations are not practical but > > sure needs to be handled someway. > > when conditions such as > - include label x AND exclude label x > - include label x AND exclude label range [k,..,z] > - include label range [t,..,y] AND exclude label range [k,..,z] > > thus when the exclude set is larger and include the include > set, an error should be generated. > > - dimitri. > > > Please do clarify > > > > venkat > > > > PS: Please don't bother about the disclaimer which come attached with > > this > > mail. > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Website: http://www.rc.bel.alcatel.be/~papadimd/index.html > Address: Alcatel - Optical NA, Fr. Wellesplein, 1 > B-2018 Antwerpen, Belgium > Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 17 May 2002 02:50:04 -0700 Cc: "'Jonathan Lang'" , "'Bhavesh Patel'" , "'ccamp@ops.ietf.org'" Message-ID: <3CE4D1B7.DFC33303@lucent.com> Date: Fri, 17 May 2002 11:47:35 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Nik Langrind Original-CC: "'Jonathan Lang'" , "'Bhavesh Patel'" , "'ccamp@ops.ietf.org'" Subject: Re: Regarding J0 byte in LMP test message Content-Type: multipart/mixed; boundary="------------0400F0498BB68FF22B67BC38" This is a multi-part message in MIME format. --------------0400F0498BB68FF22B67BC38 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, the use of an ascii string with CR/LF termination for trace identifiers (e.g. J1) is not longer the recommended approach in SONET. Refer to T1.269-2000. As per annex B/T1.269 the ascii string with CR/LF termination is to be supported for interworking with older SONET equipment that only supports the CR/LF format. Regards, Maarten Nik Langrind wrote: > > Hi, > > One aspect of Bhavesh's question that sparked my interest: CR/LF. I don't > know whether the IP packet should be followed with a CR/LF or not. It seems > to me that one ought to follow up the packet with a CR/LF, so that if the > other end's SONET framer syncs to it, the IP packet will end up sitting in > the received section trace buffer with the IP Vers/Header Length field in > the first byte of the buffer. > > On the other hand, one's receive code can't necessarily rely on this, right? > So when I am testing, anytime I get a stable section trace messages, I ought > to rotate through every byte, looking for IPV4, and calculating the IP > header checksum to ensure that I've found the right starting point. > > What are others doing? > > Thanks, > Nik > > > -----Original Message----- > > From: Jonathan Lang [mailto:jplang@calient.net] > > Sent: Thursday, May 16, 2002 1:39 PM > > To: 'Bhavesh Patel'; 'ccamp@ops.ietf.org' > > Subject: RE: Regarding J0 byte in LMP test message > > > > > > Bhavesh, > > The answers to your questions can be found in Section 14.9 > > of the LMP > > draft. Please look at the Verify Transport Mechanism. > > > > Thanks, > > Jonathan > > > > > -----Original Message----- > > > From: Bhavesh Patel [mailto:bpatel@fwion.com] > > > Sent: Thursday, May 16, 2002 5:53 AM > > > To: 'ccamp@ops.ietf.org' > > > Cc: Bhavesh Patel > > > Subject: Regarding J0 byte in LMP test message > > > > > > > > > > > > Hi, > > > > > > I have a question regarding LMP link verification. > > > > > > 1)Why did the authors of LMP protocol choose J0 byte for > > sending test > > > message when encodingType=sonet? Is it because the OXC/PXC > > falls in the > > > section portion of sonet network? > > > 2) Why the need to make J0 byte IP encoded message? why it > > cannot be an > > > ascii string with CR/LF termination similar to J1 byte? > > > 2) In a metro network application where one deploys PXCs > > connected point > > to > > > point, what does it fall under section/line/path (assume > > PXC is doing some > > > O-E-O for lmp test message needs for sending over data > > bearing links)? > > > Why not use J1 byte for lmp test message? > > > > > > Your replies are appreciated. > > > > > > Bhavesh Patel > > > Embedded Software > > > bpatel@fwion.com > > > 732-946-7400, ext 2087 > > > > > > > > --------------0400F0498BB68FF22B67BC38 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 --------------0400F0498BB68FF22B67BC38-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 16:25:04 -0700 Message-ID: From: Jonathan Lang To: 'Bhavesh Patel' , "'ccamp@ops.ietf.org'" Subject: RE: Regarding J0 byte in LMP test message Date: Thu, 16 May 2002 16:16:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bhavesh, In Section 14.9, it gives 6 different options for encoding the Test message when the encoding type is SONET/SDH, one of which is the 16-byte J0. The Test messages are IP encoded so that it is common across various transport mechanisms (not to mention the fact that ALL other LMP messages are IP encoded). The 16-byte J0 is an exception because of the byte limitation. Thanks, Jonathan -----Original Message----- From: Bhavesh Patel [mailto:bpatel@fwion.com] Sent: Thursday, May 16, 2002 2:14 PM To: Jonathan Lang; 'ccamp@ops.ietf.org' Subject: RE: Regarding J0 byte in LMP test message Jonathan, I have read section 14.9, my question is precisely why choose J0 byte messages and why the restriction on test message to be IP encoded? Thanks. bhavesh -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Thursday, May 16, 2002 1:39 PM To: 'Bhavesh Patel'; 'ccamp@ops.ietf.org' Subject: RE: Regarding J0 byte in LMP test message Bhavesh, The answers to your questions can be found in Section 14.9 of the LMP draft. Please look at the Verify Transport Mechanism. Thanks, Jonathan > -----Original Message----- > From: Bhavesh Patel [mailto:bpatel@fwion.com] > Sent: Thursday, May 16, 2002 5:53 AM > To: 'ccamp@ops.ietf.org' > Cc: Bhavesh Patel > Subject: Regarding J0 byte in LMP test message > > > > Hi, > > I have a question regarding LMP link verification. > > 1)Why did the authors of LMP protocol choose J0 byte for sending test > message when encodingType=sonet? Is it because the OXC/PXC falls in the > section portion of sonet network? > 2) Why the need to make J0 byte IP encoded message? why it cannot be an > ascii string with CR/LF termination similar to J1 byte? > 2) In a metro network application where one deploys PXCs connected point to > point, what does it fall under section/line/path (assume PXC is doing some > O-E-O for lmp test message needs for sending over data bearing links)? > Why not use J1 byte for lmp test message? > > Your replies are appreciated. > > Bhavesh Patel > Embedded Software > bpatel@fwion.com > 732-946-7400, ext 2087 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 14:26:42 -0700 Message-ID: From: Bhavesh Patel To: 'Jonathan Lang' , "'ccamp@ops.ietf.org'" Subject: RE: Regarding J0 byte in LMP test message Date: Thu, 16 May 2002 17:13:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, I have read section 14.9, my question is precisely why choose J0 byte messages and why the restriction on test message to be IP encoded? Thanks. bhavesh -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Thursday, May 16, 2002 1:39 PM To: 'Bhavesh Patel'; 'ccamp@ops.ietf.org' Subject: RE: Regarding J0 byte in LMP test message Bhavesh, The answers to your questions can be found in Section 14.9 of the LMP draft. Please look at the Verify Transport Mechanism. Thanks, Jonathan > -----Original Message----- > From: Bhavesh Patel [mailto:bpatel@fwion.com] > Sent: Thursday, May 16, 2002 5:53 AM > To: 'ccamp@ops.ietf.org' > Cc: Bhavesh Patel > Subject: Regarding J0 byte in LMP test message > > > > Hi, > > I have a question regarding LMP link verification. > > 1)Why did the authors of LMP protocol choose J0 byte for sending test > message when encodingType=sonet? Is it because the OXC/PXC falls in the > section portion of sonet network? > 2) Why the need to make J0 byte IP encoded message? why it cannot be an > ascii string with CR/LF termination similar to J1 byte? > 2) In a metro network application where one deploys PXCs connected point to > point, what does it fall under section/line/path (assume PXC is doing some > O-E-O for lmp test message needs for sending over data bearing links)? > Why not use J1 byte for lmp test message? > > Your replies are appreciated. > > Bhavesh Patel > Embedded Software > bpatel@fwion.com > 732-946-7400, ext 2087 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 12:15:51 -0700 Message-ID: <666478FCC801D6118E3600D0B781FC16159BD4@eccexch01.equipecom.com> From: Nik Langrind To: Nik Langrind , "'Jonathan Lang'" , "'Bhavesh Patel'" , "'ccamp@ops.ietf.org'" Subject: RE: Regarding J0 byte in LMP test message Date: Thu, 16 May 2002 15:14:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, What I said was silly... if there was a CR/LF in the binary data of the 64-byte checksum, then adding a CR/LF is not going to help. Nik > -----Original Message----- > From: Nik Langrind [mailto:nik@equipecom.com] > Sent: Thursday, May 16, 2002 2:04 PM > To: 'Jonathan Lang'; 'Bhavesh Patel'; 'ccamp@ops.ietf.org' > Subject: RE: Regarding J0 byte in LMP test message > > > Hi, > > One aspect of Bhavesh's question that sparked my interest: > CR/LF. I don't > know whether the IP packet should be followed with a CR/LF or > not. It seems > to me that one ought to follow up the packet with a CR/LF, so > that if the > other end's SONET framer syncs to it, the IP packet will end > up sitting in > the received section trace buffer with the IP Vers/Header > Length field in > the first byte of the buffer. > > On the other hand, one's receive code can't necessarily rely > on this, right? > So when I am testing, anytime I get a stable section trace > messages, I ought > to rotate through every byte, looking for IPV4, and calculating the IP > header checksum to ensure that I've found the right starting point. > > What are others doing? > > Thanks, > Nik > > > -----Original Message----- > > From: Jonathan Lang [mailto:jplang@calient.net] > > Sent: Thursday, May 16, 2002 1:39 PM > > To: 'Bhavesh Patel'; 'ccamp@ops.ietf.org' > > Subject: RE: Regarding J0 byte in LMP test message > > > > > > Bhavesh, > > The answers to your questions can be found in Section 14.9 > > of the LMP > > draft. Please look at the Verify Transport Mechanism. > > > > Thanks, > > Jonathan > > > > > -----Original Message----- > > > From: Bhavesh Patel [mailto:bpatel@fwion.com] > > > Sent: Thursday, May 16, 2002 5:53 AM > > > To: 'ccamp@ops.ietf.org' > > > Cc: Bhavesh Patel > > > Subject: Regarding J0 byte in LMP test message > > > > > > > > > > > > Hi, > > > > > > I have a question regarding LMP link verification. > > > > > > 1)Why did the authors of LMP protocol choose J0 byte for > > sending test > > > message when encodingType=sonet? Is it because the OXC/PXC > > falls in the > > > section portion of sonet network? > > > 2) Why the need to make J0 byte IP encoded message? why it > > cannot be an > > > ascii string with CR/LF termination similar to J1 byte? > > > 2) In a metro network application where one deploys PXCs > > connected point > > to > > > point, what does it fall under section/line/path (assume > > PXC is doing some > > > O-E-O for lmp test message needs for sending over data > > bearing links)? > > > Why not use J1 byte for lmp test message? > > > > > > Your replies are appreciated. > > > > > > Bhavesh Patel > > > Embedded Software > > > bpatel@fwion.com > > > 732-946-7400, ext 2087 > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 11:04:48 -0700 Message-ID: <666478FCC801D6118E3600D0B781FC16159BD2@eccexch01.equipecom.com> From: Nik Langrind To: "'Jonathan Lang'" , "'Bhavesh Patel'" , "'ccamp@ops.ietf.org'" Subject: RE: Regarding J0 byte in LMP test message Date: Thu, 16 May 2002 14:04:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, One aspect of Bhavesh's question that sparked my interest: CR/LF. I don't know whether the IP packet should be followed with a CR/LF or not. It seems to me that one ought to follow up the packet with a CR/LF, so that if the other end's SONET framer syncs to it, the IP packet will end up sitting in the received section trace buffer with the IP Vers/Header Length field in the first byte of the buffer. On the other hand, one's receive code can't necessarily rely on this, right? So when I am testing, anytime I get a stable section trace messages, I ought to rotate through every byte, looking for IPV4, and calculating the IP header checksum to ensure that I've found the right starting point. What are others doing? Thanks, Nik > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: Thursday, May 16, 2002 1:39 PM > To: 'Bhavesh Patel'; 'ccamp@ops.ietf.org' > Subject: RE: Regarding J0 byte in LMP test message > > > Bhavesh, > The answers to your questions can be found in Section 14.9 > of the LMP > draft. Please look at the Verify Transport Mechanism. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Bhavesh Patel [mailto:bpatel@fwion.com] > > Sent: Thursday, May 16, 2002 5:53 AM > > To: 'ccamp@ops.ietf.org' > > Cc: Bhavesh Patel > > Subject: Regarding J0 byte in LMP test message > > > > > > > > Hi, > > > > I have a question regarding LMP link verification. > > > > 1)Why did the authors of LMP protocol choose J0 byte for > sending test > > message when encodingType=sonet? Is it because the OXC/PXC > falls in the > > section portion of sonet network? > > 2) Why the need to make J0 byte IP encoded message? why it > cannot be an > > ascii string with CR/LF termination similar to J1 byte? > > 2) In a metro network application where one deploys PXCs > connected point > to > > point, what does it fall under section/line/path (assume > PXC is doing some > > O-E-O for lmp test message needs for sending over data > bearing links)? > > Why not use J1 byte for lmp test message? > > > > Your replies are appreciated. > > > > Bhavesh Patel > > Embedded Software > > bpatel@fwion.com > > 732-946-7400, ext 2087 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 10:49:49 -0700 Message-ID: From: Jonathan Lang To: 'Bhavesh Patel' , "'ccamp@ops.ietf.org'" Subject: RE: Regarding J0 byte in LMP test message Date: Thu, 16 May 2002 10:38:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bhavesh, The answers to your questions can be found in Section 14.9 of the LMP draft. Please look at the Verify Transport Mechanism. Thanks, Jonathan > -----Original Message----- > From: Bhavesh Patel [mailto:bpatel@fwion.com] > Sent: Thursday, May 16, 2002 5:53 AM > To: 'ccamp@ops.ietf.org' > Cc: Bhavesh Patel > Subject: Regarding J0 byte in LMP test message > > > > Hi, > > I have a question regarding LMP link verification. > > 1)Why did the authors of LMP protocol choose J0 byte for sending test > message when encodingType=sonet? Is it because the OXC/PXC falls in the > section portion of sonet network? > 2) Why the need to make J0 byte IP encoded message? why it cannot be an > ascii string with CR/LF termination similar to J1 byte? > 2) In a metro network application where one deploys PXCs connected point to > point, what does it fall under section/line/path (assume PXC is doing some > O-E-O for lmp test message needs for sending over data bearing links)? > Why not use J1 byte for lmp test message? > > Your replies are appreciated. > > Bhavesh Patel > Embedded Software > bpatel@fwion.com > 732-946-7400, ext 2087 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 06:07:16 -0700 Message-ID: From: Bhavesh Patel To: "'ccamp@ops.ietf.org'" Cc: Bhavesh Patel Subject: Regarding J0 byte in LMP test message Date: Thu, 16 May 2002 08:53:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a question regarding LMP link verification. 1)Why did the authors of LMP protocol choose J0 byte for sending test message when encodingType=sonet? Is it because the OXC/PXC falls in the section portion of sonet network? 2) Why the need to make J0 byte IP encoded message? why it cannot be an ascii string with CR/LF termination similar to J1 byte? 2) In a metro network application where one deploys PXCs connected point to point, what does it fall under section/line/path (assume PXC is doing some O-E-O for lmp test message needs for sending over data bearing links)? Why not use J1 byte for lmp test message? Your replies are appreciated. Bhavesh Patel Embedded Software bpatel@fwion.com 732-946-7400, ext 2087 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 16 May 2002 03:58:37 -0700 Message-ID: <3CE3904D.F738A699@alcatel.be> Date: Thu, 16 May 2002 12:56:13 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: venkat CC: ccamp@ops.ietf.org Subject: Re: Label Set Object/Tlv Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi see in-line > Venkat Dabbara wrote: > > > hai , > > In draft-ietf-mpls-generalized-cr-ldp-06.txt > 2.5.1. Procedures > A Label Set is defined via one or more Label Set TLVs. > Specific > labels/subchannels can be added to or excluded from a > Label > Set via > Action zero (0) and one (1) TLVs respectively. Ranges > of > labels/subchannels can be added to or excluded from a > Label > Set via > Action two (2) and three (3) TLVs respectively. > > The first line of the sec 2.5.1 says a label set is defined via > one or > more LabelSet TLVs. My interpretation > about this is that a label request can have multiple Label Set > TLVs in > it with different action types corresponding > to each label set TLV. Am i right ?? i think so > If i am wrong please do clarify ... > > If yes, then assume i get a request with one label set TLV with > action > type 0 which has a list of labels > and other Label set TLV with action type 1 which has a range of > Labels. > Now in this case i go about > picking up a label from the second label set TLV only if i am not > able > to pick up a label from the first > label set TLV....Is that true ?? i think the operation is label set := label set tlv[1] AND label set tlv[2] AND ... label set tlv[n] and not, if not label set tlv[1] then label set tlv[2] etc. think because the action refer to the whole label set as indicated in gmpls-sig > Now situation may get even worse when i have a Label set TLV with > action > type to include a label > set and other Label Set TLV with action type exclude. I knoe such > situations are not practical but > sure needs to be handled someway. when conditions such as - include label x AND exclude label x - include label x AND exclude label range [k,..,z] - include label range [t,..,y] AND exclude label range [k,..,z] thus when the exclude set is larger and include the include set, an error should be generated. - dimitri. > Please do clarify > > venkat > > PS: Please don't bother about the disclaimer which come attached with > this > mail. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 15 May 2002 21:35:37 -0700 Message-ID: <005801c1fc6c$d6607e00$8d03750a@wipro.com> Reply-To: "venkat" From: "Venkat Dabbara" To: Subject: Label Set Object/Tlv Date: Thu, 16 May 2002 10:01:31 +1000 Organization: wipro technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8c8293fb-5ccc-11d6-ba7c-006067005148" This is a multi-part message in MIME format. ------=_NextPartTM-000-8c8293fb-5ccc-11d6-ba7c-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C1FCC0.A75B8D80" ------=_NextPart_000_0055_01C1FCC0.A75B8D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hai , In draft-ietf-mpls-generalized-cr-ldp-06.txt 2.5.1. Procedures A Label Set is defined via one or more Label Set TLVs. Specific labels/subchannels can be added to or excluded from a = Label Set via Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from a = Label Set via Action two (2) and three (3) TLVs respectively. The first line of the sec 2.5.1 says a label set is defined via one = or more LabelSet TLVs. My interpretation about this is that a label request can have multiple Label Set TLVs = in it with different action types corresponding to each label set TLV. Am i right ?? If i am wrong please do clarify ... If yes, then assume i get a request with one label set TLV with = action type 0 which has a list of labels and other Label set TLV with action type 1 which has a range of = Labels. Now in this case i go about picking up a label from the second label set TLV only if i am not = able to pick up a label from the first label set TLV....Is that true ?? Now situation may get even worse when i have a Label set TLV with = action type to include a label set and other Label Set TLV with action type exclude. I knoe such situations are not practical but sure needs to be handled someway. Please do clarify venkat PS: Please don't bother about the disclaimer which come attached with = this mail. ------=_NextPart_000_0055_01C1FCC0.A75B8D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
hai=20 ,

          &nbs= p; In=20 draft-ietf-mpls-generalized-cr-ldp-06.txt
    &nbs= p;=20 2.5.1.=20 Procedures
          = ;     =20 A Label Set is defined via one or more Label Set=20 TLVs.
Specific
        &nbs= p;     =20 labels/subchannels can be added to or excluded from a Label
Set=20 via
           =    =20 Action zero (0) and one (1) TLVs respectively.  Ranges=20 of
           &= nbsp;  =20 labels/subchannels can be added to or excluded from a Label
Set=20 via
           =    =20 Action two (2) and three (3) TLVs = respectively.

    The=20 first line of the sec 2.5.1 says a label set is defined via one = or
more=20 LabelSet TLVs. My interpretation
    about this is = that a=20 label request can have multiple Label Set TLVs in
it with different = action=20 types corresponding
     to each label set TLV. = Am i=20 right ??
     If  i am wrong please do = clarify=20 ...

     If yes, then assume i get a request = with one=20 label set TLV with action
type 0 which has a list of=20 labels
    and other Label set TLV with action type 1 = which=20 has a range of Labels.
Now in this case i go = about
   =20 picking up a label from the second label set TLV only if i am not = able
to=20 pick up a label from the first
    label set TLV....Is = that=20 true ??

    Now situation may get even worse when = i have a=20 Label set TLV with action
type to include a = label
    set=20 and other Label Set TLV with action type exclude. I knoe = such
situations are=20 not practical but
    sure needs to be handled=20 someway.

    Please do = clarify

venkat

PS:=20 Please don't bother about the disclaimer which come attached with=20 this
mail.

------=_NextPart_000_0055_01C1FCC0.A75B8D80-- ------=_NextPartTM-000-8c8293fb-5ccc-11d6-ba7c-006067005148-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 May 2002 08:51:45 -0700 Message-ID: <3CDFE205.27366454@lucent.com> Date: Mon, 13 May 2002 11:55:49 -0400 From: Carmine Daloia Organization: Lucent Technologies MIME-Version: 1.0 To: Martin Dubuc CC: Michiel van Everdingen , Jonathan Lang , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery (verify_id) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin, See below. Carmine Martin Dubuc wrote: > > Michiel, > > Current LMP draft allows implementors to: > > - Automatically associate control channels with interfaces. [CD]Could you please explain how this is done automatically (not just for a point-to-point control network, but any control network)? > - Automatically bring up control channels over the control network between node pairs. [CD]Could you please explain how this is done automatically (not just for a point-to-point control network, but any control network)? > > Control channel management is an important aspect of LMP. It is is one of the tools that is required to discover the connectivity of the data ports. > > I don't see a need for change in messages to enhance the discovery aspects of LMP. > > Martin > > -----Original Message----- > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > Sent: Friday, May 10, 2002 4:34 AM > To: Jonathan Lang > Cc: ccamp@ops.ietf.org > Subject: Re: LMP & neighbor discovery (verify_id) > > Hello Jonathan, > > It seems that the whole control channel concept is *only* useful for this > new description to "discover the connectivity of the data ports". By means > of the control channel, the node knows where to send the beginVerify message > to. > > Please let me know if the control channel is needed for other things as > well. > > The described approach for neighbor discovery seems quite manual to me. > - The operator needs to manually "associate control channels with > interfaces" (see http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00609.html) > - The operator needs to manually provision control channels over the control > network between node pairs. > > In case above tasks can be done automatically, please let me know how. > > To my opinion, things get much simpler if we would > - remove the concept of "control channel" and accept that signalling > messages are carried over the "control network". > - include a section on neighbor discovery; see the proposal in > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html > - keep initial discovery and subsequent verification separate. > > Best regards, > > Michiel > > Jonathan Lang wrote: > > > > Yanguang, > > > > To clarify things, we've added a few lines of text to the example of Section > > 5.1 explaining how VerifyId is bound to the remote node. > > > > Thanks, > > Jonathan > > > > 5.1. Example of Link Connectivity Verification > > > > Figure 1 shows an example of the link verification scenario that is > > executed when a link between Node A and Node B is added. In this > > example, the TE link consists of three free ports (each transmitted > > along a separate fiber) and is associated with a bi-directional > > control channel (indicated by a "c"). The verification process is as > > follows: > > o A sends a BeginVerify message over the control channel to B > > indicating it will begin verifying the ports that form the TE link. > > The LOCAL_LINK_ID object carried in the BeginVerify message > > carries the identifier (IP address or interface index) that A > > assigns to the link. > > o Upon receipt of the BeginVerify message, B creates a VerifyId and > > binds it to the TE Link from A. This binding is used later when B > > receives the Test messages from A, and these messages carry the > > VerifyId. B discovers the identifier (IP address or interface index) > > that A assigns to the TE link by examining the LOCAL_LINK_ID object > > carried in the received BeginVerify message. (If the data ports are > > not yet assigned to the TE Link, the binding is limited to the Node Id > > of A.) In response to the BeginVerify message, B sends to A the > > BeginVerifyAck message. The LOCAL_LINK_ID object carried in the > > BeginVerifyAck message is used to carry the identifier (IP address or > > interface index) that B assigns to the TE link. The REMOTE_LINK_ID > > object > > carried in the BeginVerifyAck message is used to bind the TE link Ids > > assigned by both A and B. The VerifyId is returned to A in the > > BeginVerifyAck message over the control channel. > > o When A receives the BeginVerifyAck message, it begins transmitting > > periodic Test messages over the first port (Interface Id=1). The Test > > message includes the Interface Id for the port and the VerifyId that > > was > > assigned by B. > > o When B receives the Test messages, it maps the received Interface Id > > to its own local Interface Id = 10 and transmits a TestStatusSuccess > > message over the control channel back to PXC A. The TestStatusSuccess > > message includes both the local and received Interface Ids for the > > port > > as well as the VerifyId. The VerifyId is used to determine the > > local/remote > > TE link identifiers (IP addresses or interface indices) for which the > > data > > links belong. > > o A will send a TestStatusAck message over the control channel back to > > B indicating it received the TestStatusSuccess message. > > o The process is repeated until all of the ports are verified. > > o At this point, A will send an EndVerify message over the control > > channel to B to indicate that testing is complete. > > o B will respond by sending an EndVerifyAck message over the control > > channel back to A. > > Note that this procedure can be used to "discover" the connectivity of > > the data > > ports. > > > > <...snip...> > > -- > +------------------------------------------------------------------+ > | Michiel van Everdingen | > | Systems Engineer | > | Lucent Technologies - Optical Networking Group | > | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | > | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | > | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 May 2002 05:10:00 -0700 Cc: "'Suresh Katukam'" , Zafar Ali , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Message-ID: <3CDFAC96.A6252471@lucent.com> Date: Mon, 13 May 2002 14:07:50 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake Original-CC: "'Suresh Katukam'" , Zafar Ali , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: Re: Label Set Object Content-Type: multipart/mixed; boundary="------------FCE08ED3BE10CF3BA1EB5722" This is a multi-part message in MIME format. --------------FCE08ED3BE10CF3BA1EB5722 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, John Drake wrote: > > Is it the case that ALL current SONET/SDH equipment has the restriction that > the labels (timeslots) must be the same in both directions? Nobody can answer this question, while none of us has a complete overview of equipment in the field and under design :-). SDH/SONET (and OTN) networks are networks optimised for bi-directional connectivity. Uni-directional connections are supported as kind of "exception" on the generic bidirectional rule. SDH standards are assuming bidirectional connectivity. Sometimes a unidirectional connection causes the set up of a bidirectional connection of which only one direction is used (and alarming in the other direction is disabled). People are asking questions with respect to unidirectional connection support in SDH standards. The use of functional modelling method supports so far the specific unidirectional connection issues (e.g. no RDI/REI return) raised; but it is only at this point where you can show how a unidir connection would/should behave. > If this is the > case, then it's really simple; for an SONET/SDH LSP, only the upstream label > needs to be specified, and the downstream label MUST be the same. > > One the other hand, if not all current SONET/SDH equipment has this > restriction or the current SONET/SDH standards allow the labels (timeslots) SDH/SONET networks are build with the requirement that the timeslots in the two directions are the same. (Note - same requirement applies to ATM networks in which VPI/VCI for the two directions must be the same). Regards, Maarten > to be different in each direction, then label set with one value or explicit > label control would be useful for equipment that does have this restriction. > > -----Original Message----- > From: Suresh Katukam [mailto:skatukam@cisco.com] > Sent: Wednesday, May 08, 2002 3:23 PM > To: Zafar Ali > Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > Subject: RE: Label Set Object > > For TDM, since you have to use same labels in both directions, why do you > have to specify anything at all? > How can a downstream TDM node pick a label that does not match with > Upstream label for > a bidirectional LSP? If it picks any other label, LSP is not functional. > > If there are Uni-directional LSPs in TDM and if you have different types of > time slots available > in both directions, then one may be able to setup bidirectional LSP on > different links or > different labels. This is in theory and not in practice. > > So in practice, one does not need to specify LABEL SET or Suggested label > for TDM links. > > Thanks, > Suresh > > At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: > >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: > >>Hi , > >> I guess in that case we can use Suggested Label , Label Set still can > >> still be avoided . > > > >Hi Manoj, > > > >No, the use of suggested label in this case would NOT be correct, as the > >suggested labels can be ignored/ overridden by the receiving node. > > > >Thanks > > > >Regards... Zafar > > > >>Regards , > >>Manoj > >>-----Original Message----- > >>From: Zafar Ali [mailto:zali@cisco.com] > >>Sent: Wednesday, May 08, 2002 11:05 AM > >>To: Manoj Agiwal; 'Ccamp (E-mail) > >>Cc: mpls@UU. NET (E-mail) > >>Subject: Re: Label Set Object > >> > >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: > >>>Hi , > >>> In gmpls signaling extensionsions for RSVP-TE , ccamp > >>> architecture on > >>>gmpls has described Label Set object usage > >>> only for the "optical" domain viz. for carrying wavelengths ( > Section > >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . > >>> > >>> Do we require to send Label set(i.e. time slots) for TDM > >>> switching as > >>>well . In what way it can be useful . > >>Dear Manoj, > >> > >>Yes, label set object is also useful in TDM case. E.g., SONET poses an > >>additional requirement that the two interfaces of a bidirectional LSP > >>SHOULD traverse the exact same link with the same SUKLM values for the > >>two directions. > >> The label set object can be used to constrain the downstream label to > >> the same as the upstream label. > >> > >>Thanks > >> > >>Regards... Zafar > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>>Regards , > >>>Manoj > >>=============== > >>Zafar Ali > >>Cisco Systems > >>(734) 276-2459 > >>100 S Main St. #200 > >>Ann Arbor, MI 48104. > >>email: zali@cisco.com > > > >=============== > >Zafar Ali > >Cisco Systems > >(734) 276-2459 > >100 S Main St. #200 > >Ann Arbor, MI 48104. > >email: zali@cisco.com --------------FCE08ED3BE10CF3BA1EB5722 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 --------------FCE08ED3BE10CF3BA1EB5722-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 13 May 2002 00:15:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "sushantm" To: "John Drake" Cc: "Manoj Agiwal" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" , "'Suresh Katukam'" , "Zafar Ali" Subject: RE: Label Set Object Date: Thu, 9 May 2002 10:45:11 +0530 Hi John , I agree to the first case but in the second case, suppose the ERO is not used , why would we have to restrict the Label set to only one label value ? -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John Drake Sent: Thursday, May 09, 2002 7:08 AM To: 'Suresh Katukam'; Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object Is it the case that ALL current SONET/SDH equipment has the restriction that the labels (timeslots) must be the same in both directions? If this is the case, then it's really simple; for an SONET/SDH LSP, only the upstream label needs to be specified, and the downstream label MUST be the same. One the other hand, if not all current SONET/SDH equipment has this restriction or the current SONET/SDH standards allow the labels (timeslots) to be different in each direction, then label set with one value or explicit label control would be useful for equipment that does have this restriction. -----Original Message----- From: Suresh Katukam [mailto:skatukam@cisco.com] Sent: Wednesday, May 08, 2002 3:23 PM To: Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 12 May 2002 23:41:28 -0700 Subject: Re: How many can administrative groups assigned? To: Curtis Villamizar Cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org, Dimitri.Papadimitriou@alcatel.be Message-ID: From: sven.van_den_bosch@alcatel.be Date: Mon, 13 May 2002 08:36:54 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Curtis, I agree with you that the current interpretation is clear. It brings, however, some difficulties regarding Forwarding Adjacency (FA) LSPs. Suppose you have an LSP that includes gold as a resource class. It goes through links A-B (gold), B-C (gold, north) and C-D (gold, south). Imho, the current FA specification would make this a non-coloured FA-link, or alternatively, it could be coloured gold. In both cases, depending on the interpretation of uncoloured links, it could be used for an LSP that specifies e.g. exclude north, which is not what you want. This problem is due to the bitmask operation. We feel that at least one more TLV would be needed (speciying the OR operation on the bit-mask for the FA-LSP). We will document this in the next version of draft-vandenbosch-mpls-fa-considerations-00.txt. Sven. Curtis Villamizar on 08/05/2002 20:22:11 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject Re: How many can administrative groups : assigned? [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message , sven.van_d en_bosch@alcatel.be writes: > Naidu, Kim, > > I think it depends a little bit on the interpretation. In principle the > resource classes can be interpreted either as a bit mask (in which case 32 > 'base' classes can be defined) or as an integer value (in which case 2^32 > values can be used). Even with the bit mask interpretation, derived > resource classes can be built by combining multiple non-mutually exclusive > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > and then build your resource classes on top of those). The problem lies of > course in the processing of the resource class information. If they are not > used in a simple bitmask, an AND operation is not sufficient to determine > the resource class of a link. Also, if a link would have multiple derived > classes, different TLVs would be needed. It would make sense to expand a > little bit on these issues in the appropriate documents. In my opinion, > this is a general issue with the TE extensions, so it should be explained > there. > > Sven. The definitions are currently very clear. What you have described differs from the current definitions and therefore would not be a clarification to the use of admin class but a change in semantics. I do not know of anyone using more than a handful of admin class bits and many who do not use them at all. Lets not take any MPLS capability and make it any more complicated than it needs to be or introduce arbitrary change for no good reason. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 May 2002 08:36:42 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LMP & neighbor discovery (verify_id) Date: Fri, 10 May 2002 11:30:10 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C915C898@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: LMP & neighbor discovery (verify_id) Thread-Index: AcH4APF+5daYKm/GQUuhkv/Mcl15NwANVH2g From: "Martin Dubuc" To: "Michiel van Everdingen" , "Jonathan Lang" Cc: Michiel, Current LMP draft allows implementors to: - Automatically associate control channels with interfaces. - Automatically bring up control channels over the control network = between node pairs. Control channel management is an important aspect of LMP. It is is one = of the tools that is required to discover the connectivity of the data = ports. I don't see a need for change in messages to enhance the discovery = aspects of LMP. Martin -----Original Message----- From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] Sent: Friday, May 10, 2002 4:34 AM To: Jonathan Lang Cc: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery (verify_id) Hello Jonathan, It seems that the whole control channel concept is *only* useful for = this new description to "discover the connectivity of the data ports". By = means of the control channel, the node knows where to send the beginVerify = message to. Please let me know if the control channel is needed for other things as well. The described approach for neighbor discovery seems quite manual to me. - The operator needs to manually "associate control channels with interfaces" (see = http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00609.html) - The operator needs to manually provision control channels over the = control network between node pairs. In case above tasks can be done automatically, please let me know how. To my opinion, things get much simpler if we would - remove the concept of "control channel" and accept that signalling messages are carried over the "control network". - include a section on neighbor discovery; see the proposal in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html - keep initial discovery and subsequent verification separate. Best regards, Michiel Jonathan Lang wrote: >=20 > Yanguang, >=20 > To clarify things, we've added a few lines of text to the example of = Section > 5.1 explaining how VerifyId is bound to the remote node. >=20 > Thanks, > Jonathan >=20 > 5.1. Example of Link Connectivity Verification >=20 > Figure 1 shows an example of the link verification scenario that is > executed when a link between Node A and Node B is added. In this > example, the TE link consists of three free ports (each transmitted > along a separate fiber) and is associated with a bi-directional > control channel (indicated by a "c"). The verification process is = as > follows: > o A sends a BeginVerify message over the control channel to B > indicating it will begin verifying the ports that form the TE = link. > The LOCAL_LINK_ID object carried in the BeginVerify message > carries the identifier (IP address or interface index) that A > assigns to the link. > o Upon receipt of the BeginVerify message, B creates a VerifyId = and > binds it to the TE Link from A. This binding is used later when = B > receives the Test messages from A, and these messages carry the > VerifyId. B discovers the identifier (IP address or interface = index) > that A assigns to the TE link by examining the LOCAL_LINK_ID = object > carried in the received BeginVerify message. (If the data ports = are > not yet assigned to the TE Link, the binding is limited to the = Node Id > of A.) In response to the BeginVerify message, B sends to A the > BeginVerifyAck message. The LOCAL_LINK_ID object carried in the > BeginVerifyAck message is used to carry the identifier (IP = address or > interface index) that B assigns to the TE link. The = REMOTE_LINK_ID > object > carried in the BeginVerifyAck message is used to bind the TE = link Ids > assigned by both A and B. The VerifyId is returned to A in the > BeginVerifyAck message over the control channel. > o When A receives the BeginVerifyAck message, it begins = transmitting > periodic Test messages over the first port (Interface Id=3D1). = The Test > message includes the Interface Id for the port and the VerifyId = that > was > assigned by B. > o When B receives the Test messages, it maps the received = Interface Id > to its own local Interface Id =3D 10 and transmits a = TestStatusSuccess > message over the control channel back to PXC A. The = TestStatusSuccess > message includes both the local and received Interface Ids for = the > port > as well as the VerifyId. The VerifyId is used to determine the > local/remote > TE link identifiers (IP addresses or interface indices) for = which the > data > links belong. > o A will send a TestStatusAck message over the control channel = back to > B indicating it received the TestStatusSuccess message. > o The process is repeated until all of the ports are verified. > o At this point, A will send an EndVerify message over the control > channel to B to indicate that testing is complete. > o B will respond by sending an EndVerifyAck message over the = control > channel back to A. > Note that this procedure can be used to "discover" the connectivity = of > the data > ports. >=20 > <...snip...> --=20 +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 May 2002 05:49:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c" From: "Ravi, Attili" To: "Kireeti Kompella" , "Don Fedyk" , Cc: , "CCAMP" , , "Ravi Attili" Subject: Policy based management for MPLS Date: Fri, 10 May 2002 18:01:23 +0530 This is a multi-part message in MIME format. ------=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi, I have one query. Assume the case where we have policy based management system that manages the complete network that supports MPLS . my question is, when LER (PEP) sends a request to PDP for LSP setup what are all the different type of capabilities/limitations that LER (PEP) needs to send to PDP. Is there any PIB which is having this information. If there is no PIB, how to send this information to PDP ? Could any body throw light on it ? Thanks in advance Ravi ------=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-2462bd17-63fa-11d6-84a6-0000e2293f7c-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 May 2002 01:57:16 -0700 Cc: Zhi-Wei Lin , ccamp@ops.ietf.org Message-ID: <3CDB8B40.D7ED10AB@lucent.com> Date: Fri, 10 May 2002 10:56:32 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Martin Dubuc Original-CC: Zhi-Wei Lin , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin, > We have to be aware that LMP is a generic protocol not tailored > specifically for SONET/SDH. It is very dangerous to start adding > protocol specific concepts in the spec. The neighbor discovery description in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html is valid for any technique that allows for sending and reading an in-band "access point identifier" that can contain at least 15 T.50 characters. I.e. it is at least applicable to SONET/SDH and OTN. It is also applicable to transparant optical cross connects that are capable to generate a "test signal". This makes the description general enough - in my mind - to include it as an optional procedure in the LMP draft. We might indeed want to remove the first byte (the CRC) from the described format of the access point identifier. This leaves us with 15 T.50 characters and allows the addition of the CRC to be specific for the protocol in the transmission layer (the layer of the data links). > To represent TTPs and CTPs, one can use the generic concepts > of ports and component links (see Introduction for a definition > of port and component link). There are already a number of > Internet drafts that use these concepts. Please let me know how you would describe - with these terms - the point I made in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html Best regards, Michiel Martin Dubuc wrote: > > Zhi-Wei, > > We have to be aware that LMP is a generic protocol not tailored specifically for SONET/SDH. It is very dangerous to start adding protocol specific concepts in the spec. > > To represent TTPs and CTPs, one can use the generic concepts of ports and component links (see Introduction for a definition of port and component link). There are already a number of Internet drafts that use these concepts. > > Switching to CTPs and TTPs at this point would be very dangerous in that it would require changes in several drafts and would also alienate implementations that are not SONET centric. > > LMP is very closely linked with GMPLS. I am not sure why you single-handedly discard the GMPLS argument for adequacy. > > I still believe that the current draft allows vendors to implement automatic discovery. The link connectivity verification described in the draft can be used to fulfill this requirement. There is no need for extension of the messages to support this. > > Martin > > <...snip...> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 May 2002 01:35:26 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CDB85F6.C8E19278@lucent.com> Date: Fri, 10 May 2002 10:33:58 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery (verify_id) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, It seems that the whole control channel concept is *only* useful for this new description to "discover the connectivity of the data ports". By means of the control channel, the node knows where to send the beginVerify message to. Please let me know if the control channel is needed for other things as well. The described approach for neighbor discovery seems quite manual to me. - The operator needs to manually "associate control channels with interfaces" (see http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00609.html) - The operator needs to manually provision control channels over the control network between node pairs. In case above tasks can be done automatically, please let me know how. To my opinion, things get much simpler if we would - remove the concept of "control channel" and accept that signalling messages are carried over the "control network". - include a section on neighbor discovery; see the proposal in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html - keep initial discovery and subsequent verification separate. Best regards, Michiel Jonathan Lang wrote: > > Yanguang, > > To clarify things, we've added a few lines of text to the example of Section > 5.1 explaining how VerifyId is bound to the remote node. > > Thanks, > Jonathan > > 5.1. Example of Link Connectivity Verification > > Figure 1 shows an example of the link verification scenario that is > executed when a link between Node A and Node B is added. In this > example, the TE link consists of three free ports (each transmitted > along a separate fiber) and is associated with a bi-directional > control channel (indicated by a "c"). The verification process is as > follows: > o A sends a BeginVerify message over the control channel to B > indicating it will begin verifying the ports that form the TE link. > The LOCAL_LINK_ID object carried in the BeginVerify message > carries the identifier (IP address or interface index) that A > assigns to the link. > o Upon receipt of the BeginVerify message, B creates a VerifyId and > binds it to the TE Link from A. This binding is used later when B > receives the Test messages from A, and these messages carry the > VerifyId. B discovers the identifier (IP address or interface index) > that A assigns to the TE link by examining the LOCAL_LINK_ID object > carried in the received BeginVerify message. (If the data ports are > not yet assigned to the TE Link, the binding is limited to the Node Id > of A.) In response to the BeginVerify message, B sends to A the > BeginVerifyAck message. The LOCAL_LINK_ID object carried in the > BeginVerifyAck message is used to carry the identifier (IP address or > interface index) that B assigns to the TE link. The REMOTE_LINK_ID > object > carried in the BeginVerifyAck message is used to bind the TE link Ids > assigned by both A and B. The VerifyId is returned to A in the > BeginVerifyAck message over the control channel. > o When A receives the BeginVerifyAck message, it begins transmitting > periodic Test messages over the first port (Interface Id=1). The Test > message includes the Interface Id for the port and the VerifyId that > was > assigned by B. > o When B receives the Test messages, it maps the received Interface Id > to its own local Interface Id = 10 and transmits a TestStatusSuccess > message over the control channel back to PXC A. The TestStatusSuccess > message includes both the local and received Interface Ids for the > port > as well as the VerifyId. The VerifyId is used to determine the > local/remote > TE link identifiers (IP addresses or interface indices) for which the > data > links belong. > o A will send a TestStatusAck message over the control channel back to > B indicating it received the TestStatusSuccess message. > o The process is repeated until all of the ports are verified. > o At this point, A will send an EndVerify message over the control > channel to B to indicate that testing is complete. > o B will respond by sending an EndVerifyAck message over the control > channel back to A. > Note that this procedure can be used to "discover" the connectivity of > the data > ports. > > <...snip...> -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 10 May 2002 01:24:54 -0700 Subject: Re: Label Set Object To: "Anca Zamfir Cc: ""Adrian Farrel" , ""John Drake" , ""Zafar Ali" , ""'Juneja@marconi.com, "Manoj'\" , ""Vinay Vernekar" , ""Manoj Agiwal" , "\"\"'Ccamp \(E-mail\)\" , ", ""mpls" "@marconi.com From: "Diego Caviglia" Date: Fri, 10 May 2002 10:21:35 +0200 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Anca, comment in line. Regards, Diego. ---------------------------------------------------------------- Diego Caviglia Optical Network - ASON strategy E-mail: diego.caviglia@marconi.com Tel: +39 0 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Anca Zamfir @ops.ietf.org on 09/05/2002 22.44.28 Sent by: owner-ccamp@ops.ietf.org To: "Adrian Farrel" cc: "John Drake" , "Zafar Ali" , "'Juneja, Manoj'" , "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp \(E-mail\)" , , "mpls@UU. NET \(E-mail\)" Subject: Re: Label Set Object [CUT] >Could we say that bidirectional uses Upstream Label only, and unidirectional >uses Label Set only? >Yes. This is probably true for SONET LSPs. For other types this restriction may be undesirable. [dc] I'd like to add a comment on the use of Label Set and Upstream Label in case of bidirectional SDH circuit. In bidirectional SDH LSP, both the Upstream and the Downstream label must be the same. Therefore request message must contain an Upstream Label (with say value A) and a Label Set with the single value A to express the specific SDH restriction. [CUT] Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 20:07:46 -0700 Reply-To: From: "Fong Liaw" To: "'manoj juneja'" Cc: Subject: RE: Connection Deletion in GMPLS Date: Thu, 9 May 2002 20:11:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Manoj > > Fong, > I don't have any specific application requirement as of now but I > doubt why the admin status is kept as a part Path Message. Admin status > is nothing but some event notification related to a call/LSP. It is > most likely that if admin status need to be changed then no other > parameter of the PATH message is to be changed viz ERO, Gen. Label > Request, Protection information etc. Why CCAMP has made the admin > status object as a part of PATH Message ? We can say the same thing about traffic parameters, so why don't we Invent another message just for this purpose. There are so many ways To design a protocol, you described one way which will work, but how Much we gain is not clear ... When that is the case, there is no compelling reason to change the current way of doing things. Notify message was introduced because notification of fault needs to be super-fast so bypassing the per-node processing is very important. I think we don't have the same level of requirement here. > This could be done by keeping a small message with session and admin > status object. > The admin status object should not be considered as a Path message > attribute. > Rsvp-07 does say that if an admin status object does not exist in Path, its value should be assumed to be zero (this applies to all RSVP objects, BTW). So, strictly speaking admin status object is part of Path even in establish phase. > While establishing the path state, I don't think we need to pass the > admin status object then why to send the path message if there is some > change in the admin status attribute. See above. > > Path message should be sent if there is any change in the objects > previously transmitted and admin status is not a mandatory parameter in > connection establisment. > > Regards, > manoj. > > Regards, > manoj. > > >From: "Fong Liaw" > >To: "manoj juneja" , > >CC: , > >Subject: RE: Connection Deletion in GMPLS > >Date: Wed, 8 May 2002 21:19:20 -0700 > > > >Hi Manoj > > > > > > > Is it mandatory to send admin status as down in PATH > message > > > prior to connection deletion ? If yes, then the PATH message will > > > >THe -rsvp-07.txt says "SHOULD". > > > > > carry the > > > objects like ERO, Generalized Label Request which are not > > > necessary at the > > > stage of connection deletion. But one need send these as these > > > are mandatory > > > parameters (at least Gen. Label Request) in the PATH message. I > > > think, that > > > these parameters are redundant at this stage as the only > > > parameter that is > > > going to be changed is admin status. What is the use of sending > > > the complete > > > PATH message at this stage ? This goal can be achieved by just > > > having a new > > > message which will carry the session object, admin status object (but > >not > > > the parameters like Gen. Label Request, Protection Information, ERO > >etc.). > > > >The administrative state is to change a connection's state, so its > >use is not just for deletion, although that is what's defined now. > >The object needs to be processed on every node of the path, so Path > >and Resv is a nature choice and is what RSVP do to > >change/modify parameters or a connection/reservation. > > > >As I said in my last email, deletion performance > >in a normal deletion scenario is not a major concern. > >Do you have a real performance target that you can not > >achieve because of the extra objects in the Path and Resv? > >If so, can you share with us what they are ? > >Otherwise, I guess we have to agree on this disagreement. > >Or others can speak up :-) > > > >Regards, > >-Fong > > > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 13:53:39 -0700 Message-ID: <3CDAE194.D97898EA@alcatel.be> Date: Thu, 09 May 2002 22:52:36 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: "Bernstein, Greg" Cc: "'Martin Dubuc'" , Zhi-Wei Lin , ccamp@ops.ietf.org, Michiel van Everdingen Subject: Re: LMP & neighbor discovery Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi, the "discovery" process is perfectly coverable by LMP if one allows for some specific enhancements such as the ones proposed in this thread ... the important point is that even at oif the "merge between the config and the in-band" discovery is not in perfect alignment w/ the strong demand we have today as such i would suggest that the ccamp community solves this "decoupling" issue once for all - since in the absolute this decoupling is com- pletely independent of the transport plane technology - Hint: "decoupling" simply means discover your neighbour interfaces ID independently of the control channel trans- port mechanisms; and as far as i understand it the scope is to be capable to cover two non-negotiated verification 1) TTP: send test messages continuously (no interrupt) 2) CTP: send test messages continuously until receive a link summary message. the test message being: ...is it really infeasible ? i don't think so, we have already specific i-d for technology specific lmp exten- sions and an ongoing gmpls profile for g.ason so i don't think there is no room for such enhancement within the ccamp community effort. - dimitri. "Bernstein, Greg" wrote: > > Hi Martin and Zhi, I was thinking about a little overall perspective on the > general LMP topic and some recent agreements concerning LMP-WDM. > As someone presently very interested in SDH and OTN functionality I found > the motivation for LMP understandable but out of scope for the problem I was > interested in solving. > > LMP is good for transparent optical switches that do not terminate either > "in-band" overhead such as BIP-8 (error monitoring), J0 (section trace), DCC > (SDH data communication channels -- MS and RS), or GCC (G.709 equivalent), > etc.; or optical support channels such as those commonly used in DWDM > systems and described in the overall OTN architecture. > > As such this leaves a few gaps which LMP fills in the transparent optical > case: > (a) Fault isolation -- in SDH, OTN we've got extremely fast mechanisms built > in for AIS (Alarm Indication Signals -- for upstream to tell downstream of > problems) and RDI (remote defect indication -- for bidirectional signals to > indicate a far end receive problem). In transparent optical this is not the > case. > (b) Performance monitoring -- in SDH at the RS (regenerator section), MS > (multiplex section) and path (higher and lower order) we've got the B1, B2, > MS-M0/M1, and B3 overhead that lets one accurately ascertain the received > signal quality and also in some cases the far end receive quality. > (c) Communication Channels for Control -- in SDH we've got the RS and MS DCC > channels and in G.709 the GCC. > > Now for SDH and G.709, per standards and customer requirements, I must > provide this overhead processing simultaneously for each and every line > (some leeway on how much DCC). With transparent optical switches this is > not the case. In particular, we are always transmitting and receiving this > overhead on every line. > > Hence for SDH and G.709, I don't really have a need for the bulk of LMP > functionality and won't use it since I already have mechanisms that deliver > this functionality (and more) that I'm required to furnish. In the area of > "discovery", there is a strong demand to provide discovery per the > definition in G.7714, i.e., without requiring any pre-configuration of > adjacent node information. This was reflected in the modifications to LMP > for the "in-band" case that appear in the OIF's UNI 1.0. > > Hence, I'd recommend, that LMP be applied to the pre-OTN transparent optical > case similar to the agreement reached on LMP-WDM. For existing optical > technologies it doesn't really make any sense to use it. For efforts > concerned with discovery applied to SDH and G.709 ITU and OIF have projects > with these particular technology specific focuses. > > Greg B. > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > -----Original Message----- > From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] > Sent: Thursday, May 09, 2002 6:44 AM > To: Zhi-Wei Lin > Cc: Michiel van Everdingen; ccamp@ops.ietf.org > Subject: RE: LMP & neighbor discovery > > Zhi-Wei, > > We have to be aware that LMP is a generic protocol not tailored specifically > for SONET/SDH. It is very dangerous to start adding protocol specific > concepts in the spec. > > To represent TTPs and CTPs, one can use the generic concepts of ports and > component links (see Introduction for a definition of port and component > link). There are already a number of Internet drafts that use these > concepts. > > Switching to CTPs and TTPs at this point would be very dangerous in that it > would require changes in several drafts and would also alienate > implementations that are not SONET centric. > > LMP is very closely linked with GMPLS. I am not sure why you single-handedly > discard the GMPLS argument for adequacy. > > I still believe that the current draft allows vendors to implement automatic > discovery. The link connectivity verification described in the draft can be > used to fulfill this requirement. There is no need for extension of the > messages to support this. > > Martin > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Tuesday, May 07, 2002 5:16 PM > To: Martin Dubuc > Cc: Michiel van Everdingen; ccamp@ops.ietf.org > Subject: Re: LMP & neighbor discovery > > Hi Martin, > > Given the discussions thus far on this thread, there seems to be (from > my reading) a need for auto discovery as the LMP as is currently do not > support this capability. If you see otherwise, maybe you can point to > the section and text that suggests this? > > As for the language of ITU-T vs. IETF, let's not get into turf war here > but simply state why you think it's not necessary. If IETF has a set of > language that describes it the same way and it's equivalent then that's > fine, but if it's not equivalent then we obviously should look at it > more carefully instead of making some general statement. Since you think > the IETF document's language are adequate, then may I ask how IETF > differentiates some of the aspects expressed by a TTP and a CTP, because > clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its > info model (and since we are applying these to a SDH network, I'm > assuming you are also using these info models??). Of course this applies > to the OTN network as well...so the same argument is relevant... > > The fact that GMPLS may not use CTP and TTP is because GMPLS is looking > at these from the control plane perspective, while the LMP is actually > involved with tracking of the actual transport plane resources (so not > the same scope as GMPLS in terms of resource description), so can't > really use the GMPLS argument for adequacy... > > Your comments (as well as from others) are greatly appreciated. But > let's NOT get into turf battles, and stay strictly technical... > > Zhi > > Martin Dubuc wrote: > > >We don't need any update to the LMP draft to address automatic discovery. > It is possible to implement automatic discovery with the current draft. > > > >I would also like to warn CCAMP that the TTP and CTP concepts used in ITU-T > specs are very complex and I do not see a reason to change any IETF > documents to comply with this terminology/framework. > > > >Martin > > > >-----Original Message----- > >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > >Sent: Tuesday, May 07, 2002 11:42 AM > >To: ccamp@ops.ietf.org > >Subject: Re: LMP & neighbor discovery > > > > > >Hello all, > > > >Please find below two proposed updates of the LMP draft. These > >updates are based on the thoughts expressed in emails > >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > >Your comments are appreciated ! > > > >Thanks, > > > >Michiel > > > > > >1. Insert an additional section on "Automatic neighbor discovery" > > ============================================================== > >In this section, an optional LMP procedure is described to automatically > >detect the identification of the other end of the data link. Basically, > >automatic neighbor discovery is implemented by reading the incoming > >'access point identifier' [ITU-T G.707]. > > > >A Sub-Network Point (TTP or CTP) that implements the automatic neighbor > >discovery procedure MUST send its identification in the access point > >identifier. The identification SHOULD be formatted into 16 bytes as > >follows ([OIF 2000.159.01]): > > > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >|CRC|Typ|Dis| Node Identifier | Port Identifier | > >+---+---+---+-------------------------------+-------------------+ > > Figure 1: format of the access point identifier > > to enable automatic neighbor discovery > > > >The format as specified in figure 1 is in line with the specification > >in [ITU-T G707]. This SDH standard places the most stringent constraints > >on the contents of the access point identifiers. > > > >All entries in the access point identifier, except for the CRC > >field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. > > > >CRC > > The CRC-7 code of the previous frame as specified in G.707. > > > >Typ > > The "type indicator" informs the receiver of the sender's role. > > values are: > > "T": Trail Termination Point > > "C": Connection Termination Point > > > >Dis > > The "distinguishing identifier" avoids the proposed format to be > > confused with some other optional format, e.g. the format specified > > in G.831, Appendix I. > > value: > > "@" > > > >Node Identifier > > The "node identifier" is the IPv4 address that identifies the > > sending Node_Id. The IPv4 address is encoded in 8 hex characters. > > > >Port Identifier > > The "Port Identifier" identifies the sender's Interface_Id in hex > > format. This gives port numbers 0-FFFFF (1,048,575) which should > > be enough for all types of Network Elements. > > > > > >As an example, a node with IP address 192.168.2.23 would sent out > >the following access point identifier (excluding the CRC) from a TTP > >with local interface id 421: > > T@C0A802170001A5 > > > >A sending TTP that implements the automatic neighbor discovery scheme > >will continuously send out its own identification. This is according to > >ITU-T G.831, "the access point identifier should not change while the > >access point remains in existence". > > > >A sending CTP that implements the automatic neighbor discovery scheme > >MUST send its identification as long as it has not received a > >linkSummary message indicating that the associated receiver has > >discovered this sending CTP. The CTP MAY send its identification > >continuously, until it is discovered. The CTP MAY also send its > >identification in intervals, until it is discovered. > > > > > >Example: figure 2 shows 4 network elements (NEs) and a single data > >link between these NEs. Two NEs terminate the data link on interfaces > >marked with 'T' (TTP). Two other NEs are transparent to the data link > >on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH > >multiplexers; NE-2 and NE-3 are transparent optical cross connects; > >the data link is STM-N/OC-N. > > > >Note that neighbor discovery is defined per datalink, so the actual > >number of datalinks per NE is not relevant. > > > >+------+ +------+ +------+ +------+ > >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | > >| | A | | B | | C | | > >| | | | | | | | > >| NE-1 | | NE-2 | | NE-3 | | NE-4 | > >+------+ +------+ +------+ +------+ > > Figure 2: automatic discovery example - 1 > > > >NE-2 should, when it wants to discover data link B, connect > >a test-set that sends an access point identifier to identify > >the sending connection point C in NE-2. This test-signal should > >be send long enough for NE-3 to detect and read the test-signal. > >NE-3 will continuously scan all its not discovered input ports > >for a discovery signal. > > > >At some point, NE-3 will detect the test-signal on data link B. > >See figure 3. > > > >+------+ +------+ +------+ +------+ > >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | > >| | A | / | B | \ | C | | > >| | | T | | T | | | > >| NE-1 | | NE-2 | | NE-3 | | NE-4 | > >+------+ +------+ +------+ +------+ > > Figure 3: automatic discovery example - 2 > > > >When NE-3 has read the access point identifier in the test signal, > >data link B is discovered. Subsequent link property correlation can > >then be invoked. > > > >Discovery of data link A is similar, except that the access point > >identifier is continuously sent. Discovery of data link C is also > >similar, except that the access point identifier is continuously > >monitored. In other words, there is no need for a sending respectively > >monitoring 'test-set' in NE-1 and NE-4. > > > >Data link type Access point identifier to be used > >-------------- ---------------------------------- > >STM-N, OC-N J0 > >STS-1/3/.../VC-3/4/... J1 > >VT-1.5/VC-11/12 J2 > > > > > > > >A Sub-Network Point (TTP or CTP) MAY also use an alternative format > >for the access point identifier, e.g. the one specified in > >G.831, Appendix I. In this case, discovery of the address of the > >sending access point will need involvement of a 'name server'. Using > >an alternative format is, for example, needed in case the address > >of the access point can not be encoded in the limited length of > >the access point identifier, e.g. because IPv6 is used in > >the control plane. > > > > > >2. Add Additional text to section 4, "Link Property Correlation" > > ============================================================= > >Note that the verify procedure is only applicable for CTP-->--CTP > >and CTP-->--TTP dataLinks. The verify procedure is not applicable > >for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send > >out their identification; the receiver can therefore at any time > >verify the connectivity of the dataLink. > > > > > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 13:49:32 -0700 Message-Id: <4.3.2.7.2.20020509161752.01d0a488@toque.cisco.com> Date: Thu, 09 May 2002 16:44:28 -0400 To: "Adrian Farrel" From: Anca Zamfir Subject: Re: Label Set Object Cc: "John Drake" , "Zafar Ali" , "'Juneja, Manoj'" , "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp \(E-mail\)" , , "mpls@UU. NET \(E-mail\)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:53 PM 5/9/2002 -0400, Adrian Farrel wrote: >Suppose (just suppose) that I want a unidirectional sonet LSP and that I >want to >constrain the label choice to a specific value. Note that this is >distinct from >the question of what labels to use in each direction for bidirectional. >It is clear how I signal it. No issues. Label Request, Label Set with one >member... You can also allow the downstream node to pick one (maybe complex) label from a set with more than one member by including multiple labels in the Label Set. >Now suppose I also want a bidirectional sonet LSP. >How do I indicate that it is bidirectional? >I believe the only method is to include an Upstream Label. Correct. >Could we say that bidirectional uses Upstream Label only, and unidirectional >uses Label Set only? >Yes. This is probably true for SONET LSPs. For other types this restriction may be undesirable. >Would that be a good idea? >I don't see think that having multiple choices of presence of objects is >useful. IMO, assuming most GMPLS implementations are meant to cover more than one type of LSP domain, for the reason of maximizing the code re-use, it would be nice to have as few domain specific restrictions as possible. >Could an implementation choose to ignore one of the objects and act only >on the >other? >Of course. > >Adrian > >----- Original Message ----- >From: "John Drake" >To: "'Anca Zamfir'" ; "Zafar Ali" >Cc: "'Juneja, Manoj'" ; "Vinay Vernekar" >; "Manoj Agiwal" ; "'Ccamp >(E-mail)" ; ; "mpls@UU. NET (E-mail)" > >Sent: Wednesday, May 08, 2002 10:42 PM >Subject: RE: Label Set Object > > > > Lou and I just reviewed section 5.1.1 of > > draft-ietf-mpls-generalized-rsvp-te-07.txt (rather than > > draft-ietf-mpls-generalized-signaling-08.txt, which is what I looked at > this > > morning), and it's pretty clear. > > > > The upstream node processing the ERO for the outgoing link checks whether > > there are explicit label control subobjects for upstream or downstream. An > > explicit label control for upstream is replaced in the ERO with an upstream > > label and an explicit label control for downstream is replaced with a label > > set with the same label. This is so done so that there is only one > > mechanism for an upstream node to specify the downstream label; explicit > > label control is only used by a remote node. > > > > So the only question is whether for SONET/SDH LSPs, this mechanism is > > required. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 12:55:02 -0700 Message-ID: <046601c1f793$34a7a620$2200120a@movaz.com> From: "Adrian Farrel" To: "John Drake" , "'Anca Zamfir'" , "Zafar Ali" Cc: "'Juneja, Manoj'" , "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp \(E-mail\)" , , "mpls@UU. NET \(E-mail\)" Subject: Re: Label Set Object Date: Thu, 9 May 2002 15:53:35 -0400 Suppose (just suppose) that I want a unidirectional sonet LSP and that I want to constrain the label choice to a specific value. Note that this is distinct from the question of what labels to use in each direction for bidirectional. It is clear how I signal it. No issues. Label Request, Label Set with one member... Now suppose I also want a bidirectional sonet LSP. How do I indicate that it is bidirectional? I believe the only method is to include an Upstream Label. Could we say that bidirectional uses Upstream Label only, and unidirectional uses Label Set only? Yes. Would that be a good idea? I don't see think that having multiple choices of presence of objects is useful. Could an implementation choose to ignore one of the objects and act only on the other? Of course. Adrian ----- Original Message ----- From: "John Drake" To: "'Anca Zamfir'" ; "Zafar Ali" Cc: "'Juneja, Manoj'" ; "Vinay Vernekar" ; "Manoj Agiwal" ; "'Ccamp (E-mail)" ; ; "mpls@UU. NET (E-mail)" Sent: Wednesday, May 08, 2002 10:42 PM Subject: RE: Label Set Object > Lou and I just reviewed section 5.1.1 of > draft-ietf-mpls-generalized-rsvp-te-07.txt (rather than > draft-ietf-mpls-generalized-signaling-08.txt, which is what I looked at this > morning), and it's pretty clear. > > The upstream node processing the ERO for the outgoing link checks whether > there are explicit label control subobjects for upstream or downstream. An > explicit label control for upstream is replaced in the ERO with an upstream > label and an explicit label control for downstream is replaced with a label > set with the same label. This is so done so that there is only one > mechanism for an upstream node to specify the downstream label; explicit > label control is only used by a remote node. > > So the only question is whether for SONET/SDH LSPs, this mechanism is > required. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 11:44:40 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LMP & neighbor discovery Date: Thu, 9 May 2002 14:41:14 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C9164DF7@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: LMP & neighbor discovery Thread-Index: AcH3hp/cvft2/1YwQ1q145iIdolOjQAAKY4Q From: "George Young" To: Cc: "Bernstein, Greg" Hello Greg, Not wishing to disagree with you, please see comment below. Regards, George R. Young Meriton Networks Inc. 3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9628 email: george.young@meriton.com >-----Original Message----- >From: Bernstein, Greg [mailto:GregB@ciena.com] >Sent: Thursday, May 09, 2002 1:53 PM >To: Martin Dubuc; Zhi-Wei Lin; ccamp@ops.ietf.org >Cc: Michiel van Everdingen; Bernstein, Greg >Subject: RE: LMP & neighbor discovery > > >Hi Martin and Zhi, I was thinking about a little overall=20 >perspective on the >general LMP topic and some recent agreements concerning LMP-WDM. >As someone presently very interested in SDH and OTN=20 >functionality I found >the motivation for LMP understandable but out of scope for the=20 >problem I was >interested in solving. > >LMP is good for transparent optical switches that do not=20 >terminate either >"in-band" overhead such as BIP-8 (error monitoring), J0=20 >(section trace), DCC >(SDH data communication channels -- MS and RS), or GCC (G.709=20 >equivalent), >etc.; or optical support channels such as those commonly used in DWDM >systems and described in the overall OTN architecture. > >As such this leaves a few gaps which LMP fills in the=20 >transparent optical >case: >(a) Fault isolation -- in SDH, OTN we've got extremely fast=20 >mechanisms built >in for AIS (Alarm Indication Signals -- for upstream to tell=20 >downstream of >problems) and RDI (remote defect indication -- for=20 >bidirectional signals to >indicate a far end receive problem). In transparent optical=20 >this is not the >case. I agree that, by itself, LMP does not have such a mechanism. But in = cooperation with RSVP, there is a mechanism, namely the RSVP NOTIFY message. What we need = is a way to quantify it's speediness. FYI, I've submitted an internet draft http://www.ietf.org/internet-drafts/draft-young-optical-prot-ext-rsvp-00.= txt proposing an RSVP-TE extension which addresses this shortcoming. >(b) Performance monitoring -- in SDH at the RS (regenerator=20 >section), MS >(multiplex section) and path (higher and lower order) we've=20 >got the B1, B2, >MS-M0/M1, and B3 overhead that lets one accurately ascertain=20 >the received >signal quality and also in some cases the far end receive quality. >(c) Communication Channels for Control -- in SDH we've got the=20 >RS and MS DCC >channels and in G.709 the GCC. > >Now for SDH and G.709, per standards and customer requirements, I must >provide this overhead processing simultaneously for each and every line >(some leeway on how much DCC). With transparent optical=20 >switches this is >not the case. In particular, we are always transmitting and=20 >receiving this >overhead on every line. > >Hence for SDH and G.709, I don't really have a need for the bulk of LMP >functionality and won't use it since I already have mechanisms=20 >that deliver >this functionality (and more) that I'm required to furnish. =20 >In the area of >"discovery", there is a strong demand to provide discovery per the >definition in G.7714, i.e., without requiring any pre-configuration of >adjacent node information. This was reflected in the=20 >modifications to LMP >for the "in-band" case that appear in the OIF's UNI 1.0. > >Hence, I'd recommend, that LMP be applied to the pre-OTN=20 >transparent optical >case similar to the agreement reached on LMP-WDM. For existing optical >technologies it doesn't really make any sense to use it. For efforts >concerned with discovery applied to SDH and G.709 ITU and OIF=20 >have projects >with these particular technology specific focuses. > >Greg B. >*********************************** >Dr. Greg M. Bernstein >Senior Technology Director, Ciena Corporation=20 > >-----Original Message----- >From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] >Sent: Thursday, May 09, 2002 6:44 AM >To: Zhi-Wei Lin >Cc: Michiel van Everdingen; ccamp@ops.ietf.org >Subject: RE: LMP & neighbor discovery > > >Zhi-Wei, > >We have to be aware that LMP is a generic protocol not=20 >tailored specifically >for SONET/SDH. It is very dangerous to start adding protocol specific >concepts in the spec. > >To represent TTPs and CTPs, one can use the generic concepts=20 >of ports and >component links (see Introduction for a definition of port and=20 >component >link). There are already a number of Internet drafts that use these >concepts. > >Switching to CTPs and TTPs at this point would be very=20 >dangerous in that it >would require changes in several drafts and would also alienate >implementations that are not SONET centric. > >LMP is very closely linked with GMPLS. I am not sure why you=20 >single-handedly >discard the GMPLS argument for adequacy. > >I still believe that the current draft allows vendors to=20 >implement automatic >discovery. The link connectivity verification described in the=20 >draft can be >used to fulfill this requirement. There is no need for extension of the >messages to support this. > >Martin > >-----Original Message----- >From: Zhi-Wei Lin [mailto:zwlin@lucent.com] >Sent: Tuesday, May 07, 2002 5:16 PM >To: Martin Dubuc >Cc: Michiel van Everdingen; ccamp@ops.ietf.org >Subject: Re: LMP & neighbor discovery > > >Hi Martin, > >Given the discussions thus far on this thread, there seems to be (from=20 >my reading) a need for auto discovery as the LMP as is=20 >currently do not=20 >support this capability. If you see otherwise, maybe you can point to=20 >the section and text that suggests this? > >As for the language of ITU-T vs. IETF, let's not get into turf=20 >war here=20 >but simply state why you think it's not necessary. If IETF has=20 >a set of=20 >language that describes it the same way and it's equivalent=20 >then that's=20 >fine, but if it's not equivalent then we obviously should look at it=20 >more carefully instead of making some general statement. Since=20 >you think=20 >the IETF document's language are adequate, then may I ask how IETF=20 >differentiates some of the aspects expressed by a TTP and a=20 >CTP, because=20 >clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its=20 >info model (and since we are applying these to a SDH network, I'm=20 >assuming you are also using these info models??). Of course=20 >this applies=20 >to the OTN network as well...so the same argument is relevant... > >The fact that GMPLS may not use CTP and TTP is because GMPLS=20 >is looking=20 >at these from the control plane perspective, while the LMP is actually=20 >involved with tracking of the actual transport plane resources (so not=20 >the same scope as GMPLS in terms of resource description), so can't=20 >really use the GMPLS argument for adequacy... > >Your comments (as well as from others) are greatly appreciated. But=20 >let's NOT get into turf battles, and stay strictly technical... > >Zhi > > >Martin Dubuc wrote: > >>We don't need any update to the LMP draft to address=20 >automatic discovery. >It is possible to implement automatic discovery with the current draft. >> >>I would also like to warn CCAMP that the TTP and CTP concepts=20 >used in ITU-T >specs are very complex and I do not see a reason to change any IETF >documents to comply with this terminology/framework. >> >>Martin >> >>-----Original Message----- >>From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] >>Sent: Tuesday, May 07, 2002 11:42 AM >>To: ccamp@ops.ietf.org >>Subject: Re: LMP & neighbor discovery >> >> >>Hello all, >> >>Please find below two proposed updates of the LMP draft. These >>updates are based on the thoughts expressed in emails >>http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html >>http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html >> >>Your comments are appreciated ! >> >>Thanks, >> >>Michiel >> >> >>1. Insert an additional section on "Automatic neighbor discovery" >> = =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=3D=3D=3D=3D=3D=3D=3D=3D >>In this section, an optional LMP procedure is described to=20 >automatically >>detect the identification of the other end of the data link.=20 >Basically, >>automatic neighbor discovery is implemented by reading the incoming >>'access point identifier' [ITU-T G.707]. >> >>A Sub-Network Point (TTP or CTP) that implements the=20 >automatic neighbor >>discovery procedure MUST send its identification in the access point >>identifier. The identification SHOULD be formatted into 16 bytes as >>follows ([OIF 2000.159.01]): >> >>+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| >>+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>|CRC|Typ|Dis| Node Identifier | Port Identifier | >>+---+---+---+-------------------------------+-------------------+ >> Figure 1: format of the access point identifier >> to enable automatic neighbor discovery >> >>The format as specified in figure 1 is in line with the specification >>in [ITU-T G707]. This SDH standard places the most stringent=20 >constraints >>on the contents of the access point identifiers. >> >>All entries in the access point identifier, except for the CRC >>field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. >> >>CRC >> The CRC-7 code of the previous frame as specified in G.707. >> >>Typ >> The "type indicator" informs the receiver of the sender's role. >> values are: >> "T": Trail Termination Point >> "C": Connection Termination Point >> >>Dis >> The "distinguishing identifier" avoids the proposed format to be >> confused with some other optional format, e.g. the format specified >> in G.831, Appendix I. >> value: >> "@" >> >>Node Identifier >> The "node identifier" is the IPv4 address that identifies the >> sending Node_Id. The IPv4 address is encoded in 8 hex characters. >> >>Port Identifier >> The "Port Identifier" identifies the sender's Interface_Id in hex >> format. This gives port numbers 0-FFFFF (1,048,575) which should >> be enough for all types of Network Elements. >> >> >>As an example, a node with IP address 192.168.2.23 would sent out >>the following access point identifier (excluding the CRC) from a TTP >>with local interface id 421: >> T@C0A802170001A5 >> >>A sending TTP that implements the automatic neighbor discovery scheme >>will continuously send out its own identification. This is=20 >according to >>ITU-T G.831, "the access point identifier should not change while the >>access point remains in existence". >> >>A sending CTP that implements the automatic neighbor discovery scheme >>MUST send its identification as long as it has not received a >>linkSummary message indicating that the associated receiver has >>discovered this sending CTP. The CTP MAY send its identification >>continuously, until it is discovered. The CTP MAY also send its >>identification in intervals, until it is discovered. >> >> >>Example: figure 2 shows 4 network elements (NEs) and a single data >>link between these NEs. Two NEs terminate the data link on interfaces >>marked with 'T' (TTP). Two other NEs are transparent to the data link >>on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH >>multiplexers; NE-2 and NE-3 are transparent optical cross connects; >>the data link is STM-N/OC-N. >> >>Note that neighbor discovery is defined per datalink, so the actual >>number of datalinks per NE is not relevant. >> >>+------+ +------+ +------+ +------+ >>| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >>| | A | | B | | C | | >>| | | | | | | | >>| NE-1 | | NE-2 | | NE-3 | | NE-4 | >>+------+ +------+ +------+ +------+ >> Figure 2: automatic discovery example - 1 >> >>NE-2 should, when it wants to discover data link B, connect >>a test-set that sends an access point identifier to identify >>the sending connection point C in NE-2. This test-signal should >>be send long enough for NE-3 to detect and read the test-signal. >>NE-3 will continuously scan all its not discovered input ports >>for a discovery signal. >> >>At some point, NE-3 will detect the test-signal on data link B. >>See figure 3. >> >>+------+ +------+ +------+ +------+ >>| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >>| | A | / | B | \ | C | | >>| | | T | | T | | | >>| NE-1 | | NE-2 | | NE-3 | | NE-4 | >>+------+ +------+ +------+ +------+ >> Figure 3: automatic discovery example - 2 >> >>When NE-3 has read the access point identifier in the test signal, >>data link B is discovered. Subsequent link property correlation can >>then be invoked. >> >>Discovery of data link A is similar, except that the access point >>identifier is continuously sent. Discovery of data link C is also >>similar, except that the access point identifier is continuously >>monitored. In other words, there is no need for a sending respectively >>monitoring 'test-set' in NE-1 and NE-4. >> >>Data link type Access point identifier to be used >>-------------- ---------------------------------- >>STM-N, OC-N J0 >>STS-1/3/.../VC-3/4/... J1 >>VT-1.5/VC-11/12 J2 >> >> >> >>A Sub-Network Point (TTP or CTP) MAY also use an alternative format >>for the access point identifier, e.g. the one specified in >>G.831, Appendix I. In this case, discovery of the address of the >>sending access point will need involvement of a 'name server'. Using >>an alternative format is, for example, needed in case the address >>of the access point can not be encoded in the limited length of >>the access point identifier, e.g. because IPv6 is used in >>the control plane. >> >> >>2. Add Additional text to section 4, "Link Property Correlation" >> = =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=3D=3D=3D=3D=3D=3D=3D >>Note that the verify procedure is only applicable for CTP-->--CTP >>and CTP-->--TTP dataLinks. The verify procedure is not applicable >>for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send >>out their identification; the receiver can therefore at any time >>verify the connectivity of the dataLink. >> >> >> =20 >> > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 10:56:08 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B085@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Martin Dubuc'" , Zhi-Wei Lin , ccamp@ops.ietf.org Cc: Michiel van Everdingen , "Bernstein, Greg" Subject: RE: LMP & neighbor discovery Date: Thu, 9 May 2002 10:53:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Martin and Zhi, I was thinking about a little overall perspective on the general LMP topic and some recent agreements concerning LMP-WDM. As someone presently very interested in SDH and OTN functionality I found the motivation for LMP understandable but out of scope for the problem I was interested in solving. LMP is good for transparent optical switches that do not terminate either "in-band" overhead such as BIP-8 (error monitoring), J0 (section trace), DCC (SDH data communication channels -- MS and RS), or GCC (G.709 equivalent), etc.; or optical support channels such as those commonly used in DWDM systems and described in the overall OTN architecture. As such this leaves a few gaps which LMP fills in the transparent optical case: (a) Fault isolation -- in SDH, OTN we've got extremely fast mechanisms built in for AIS (Alarm Indication Signals -- for upstream to tell downstream of problems) and RDI (remote defect indication -- for bidirectional signals to indicate a far end receive problem). In transparent optical this is not the case. (b) Performance monitoring -- in SDH at the RS (regenerator section), MS (multiplex section) and path (higher and lower order) we've got the B1, B2, MS-M0/M1, and B3 overhead that lets one accurately ascertain the received signal quality and also in some cases the far end receive quality. (c) Communication Channels for Control -- in SDH we've got the RS and MS DCC channels and in G.709 the GCC. Now for SDH and G.709, per standards and customer requirements, I must provide this overhead processing simultaneously for each and every line (some leeway on how much DCC). With transparent optical switches this is not the case. In particular, we are always transmitting and receiving this overhead on every line. Hence for SDH and G.709, I don't really have a need for the bulk of LMP functionality and won't use it since I already have mechanisms that deliver this functionality (and more) that I'm required to furnish. In the area of "discovery", there is a strong demand to provide discovery per the definition in G.7714, i.e., without requiring any pre-configuration of adjacent node information. This was reflected in the modifications to LMP for the "in-band" case that appear in the OIF's UNI 1.0. Hence, I'd recommend, that LMP be applied to the pre-OTN transparent optical case similar to the agreement reached on LMP-WDM. For existing optical technologies it doesn't really make any sense to use it. For efforts concerned with discovery applied to SDH and G.709 ITU and OIF have projects with these particular technology specific focuses. Greg B. *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com] Sent: Thursday, May 09, 2002 6:44 AM To: Zhi-Wei Lin Cc: Michiel van Everdingen; ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery Zhi-Wei, We have to be aware that LMP is a generic protocol not tailored specifically for SONET/SDH. It is very dangerous to start adding protocol specific concepts in the spec. To represent TTPs and CTPs, one can use the generic concepts of ports and component links (see Introduction for a definition of port and component link). There are already a number of Internet drafts that use these concepts. Switching to CTPs and TTPs at this point would be very dangerous in that it would require changes in several drafts and would also alienate implementations that are not SONET centric. LMP is very closely linked with GMPLS. I am not sure why you single-handedly discard the GMPLS argument for adequacy. I still believe that the current draft allows vendors to implement automatic discovery. The link connectivity verification described in the draft can be used to fulfill this requirement. There is no need for extension of the messages to support this. Martin -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, May 07, 2002 5:16 PM To: Martin Dubuc Cc: Michiel van Everdingen; ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Hi Martin, Given the discussions thus far on this thread, there seems to be (from my reading) a need for auto discovery as the LMP as is currently do not support this capability. If you see otherwise, maybe you can point to the section and text that suggests this? As for the language of ITU-T vs. IETF, let's not get into turf war here but simply state why you think it's not necessary. If IETF has a set of language that describes it the same way and it's equivalent then that's fine, but if it's not equivalent then we obviously should look at it more carefully instead of making some general statement. Since you think the IETF document's language are adequate, then may I ask how IETF differentiates some of the aspects expressed by a TTP and a CTP, because clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its info model (and since we are applying these to a SDH network, I'm assuming you are also using these info models??). Of course this applies to the OTN network as well...so the same argument is relevant... The fact that GMPLS may not use CTP and TTP is because GMPLS is looking at these from the control plane perspective, while the LMP is actually involved with tracking of the actual transport plane resources (so not the same scope as GMPLS in terms of resource description), so can't really use the GMPLS argument for adequacy... Your comments (as well as from others) are greatly appreciated. But let's NOT get into turf battles, and stay strictly technical... Zhi Martin Dubuc wrote: >We don't need any update to the LMP draft to address automatic discovery. It is possible to implement automatic discovery with the current draft. > >I would also like to warn CCAMP that the TTP and CTP concepts used in ITU-T specs are very complex and I do not see a reason to change any IETF documents to comply with this terminology/framework. > >Martin > >-----Original Message----- >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] >Sent: Tuesday, May 07, 2002 11:42 AM >To: ccamp@ops.ietf.org >Subject: Re: LMP & neighbor discovery > > >Hello all, > >Please find below two proposed updates of the LMP draft. These >updates are based on the thoughts expressed in emails >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > >Your comments are appreciated ! > >Thanks, > >Michiel > > >1. Insert an additional section on "Automatic neighbor discovery" > ============================================================== >In this section, an optional LMP procedure is described to automatically >detect the identification of the other end of the data link. Basically, >automatic neighbor discovery is implemented by reading the incoming >'access point identifier' [ITU-T G.707]. > >A Sub-Network Point (TTP or CTP) that implements the automatic neighbor >discovery procedure MUST send its identification in the access point >identifier. The identification SHOULD be formatted into 16 bytes as >follows ([OIF 2000.159.01]): > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >|CRC|Typ|Dis| Node Identifier | Port Identifier | >+---+---+---+-------------------------------+-------------------+ > Figure 1: format of the access point identifier > to enable automatic neighbor discovery > >The format as specified in figure 1 is in line with the specification >in [ITU-T G707]. This SDH standard places the most stringent constraints >on the contents of the access point identifiers. > >All entries in the access point identifier, except for the CRC >field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. > >CRC > The CRC-7 code of the previous frame as specified in G.707. > >Typ > The "type indicator" informs the receiver of the sender's role. > values are: > "T": Trail Termination Point > "C": Connection Termination Point > >Dis > The "distinguishing identifier" avoids the proposed format to be > confused with some other optional format, e.g. the format specified > in G.831, Appendix I. > value: > "@" > >Node Identifier > The "node identifier" is the IPv4 address that identifies the > sending Node_Id. The IPv4 address is encoded in 8 hex characters. > >Port Identifier > The "Port Identifier" identifies the sender's Interface_Id in hex > format. This gives port numbers 0-FFFFF (1,048,575) which should > be enough for all types of Network Elements. > > >As an example, a node with IP address 192.168.2.23 would sent out >the following access point identifier (excluding the CRC) from a TTP >with local interface id 421: > T@C0A802170001A5 > >A sending TTP that implements the automatic neighbor discovery scheme >will continuously send out its own identification. This is according to >ITU-T G.831, "the access point identifier should not change while the >access point remains in existence". > >A sending CTP that implements the automatic neighbor discovery scheme >MUST send its identification as long as it has not received a >linkSummary message indicating that the associated receiver has >discovered this sending CTP. The CTP MAY send its identification >continuously, until it is discovered. The CTP MAY also send its >identification in intervals, until it is discovered. > > >Example: figure 2 shows 4 network elements (NEs) and a single data >link between these NEs. Two NEs terminate the data link on interfaces >marked with 'T' (TTP). Two other NEs are transparent to the data link >on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH >multiplexers; NE-2 and NE-3 are transparent optical cross connects; >the data link is STM-N/OC-N. > >Note that neighbor discovery is defined per datalink, so the actual >number of datalinks per NE is not relevant. > >+------+ +------+ +------+ +------+ >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >| | A | | B | | C | | >| | | | | | | | >| NE-1 | | NE-2 | | NE-3 | | NE-4 | >+------+ +------+ +------+ +------+ > Figure 2: automatic discovery example - 1 > >NE-2 should, when it wants to discover data link B, connect >a test-set that sends an access point identifier to identify >the sending connection point C in NE-2. This test-signal should >be send long enough for NE-3 to detect and read the test-signal. >NE-3 will continuously scan all its not discovered input ports >for a discovery signal. > >At some point, NE-3 will detect the test-signal on data link B. >See figure 3. > >+------+ +------+ +------+ +------+ >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >| | A | / | B | \ | C | | >| | | T | | T | | | >| NE-1 | | NE-2 | | NE-3 | | NE-4 | >+------+ +------+ +------+ +------+ > Figure 3: automatic discovery example - 2 > >When NE-3 has read the access point identifier in the test signal, >data link B is discovered. Subsequent link property correlation can >then be invoked. > >Discovery of data link A is similar, except that the access point >identifier is continuously sent. Discovery of data link C is also >similar, except that the access point identifier is continuously >monitored. In other words, there is no need for a sending respectively >monitoring 'test-set' in NE-1 and NE-4. > >Data link type Access point identifier to be used >-------------- ---------------------------------- >STM-N, OC-N J0 >STS-1/3/.../VC-3/4/... J1 >VT-1.5/VC-11/12 J2 > > > >A Sub-Network Point (TTP or CTP) MAY also use an alternative format >for the access point identifier, e.g. the one specified in >G.831, Appendix I. In this case, discovery of the address of the >sending access point will need involvement of a 'name server'. Using >an alternative format is, for example, needed in case the address >of the access point can not be encoded in the limited length of >the access point identifier, e.g. because IPv6 is used in >the control plane. > > >2. Add Additional text to section 4, "Link Property Correlation" > ============================================================= >Note that the verify procedure is only applicable for CTP-->--CTP >and CTP-->--TTP dataLinks. The verify procedure is not applicable >for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send >out their identification; the receiver can therefore at any time >verify the connectivity of the dataLink. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 09 May 2002 06:51:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LMP & neighbor discovery Date: Thu, 9 May 2002 09:43:38 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C915C897@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: LMP & neighbor discovery Thread-Index: AcH2DCP/8uHsx7ZySFKDTtQgx8++mwBTiOlw From: "Martin Dubuc" To: "Zhi-Wei Lin" Cc: "Michiel van Everdingen" , Zhi-Wei, We have to be aware that LMP is a generic protocol not tailored = specifically for SONET/SDH. It is very dangerous to start adding = protocol specific concepts in the spec. To represent TTPs and CTPs, one can use the generic concepts of ports = and component links (see Introduction for a definition of port and = component link). There are already a number of Internet drafts that use = these concepts. Switching to CTPs and TTPs at this point would be very dangerous in that = it would require changes in several drafts and would also alienate = implementations that are not SONET centric. LMP is very closely linked with GMPLS. I am not sure why you = single-handedly discard the GMPLS argument for adequacy. I still believe that the current draft allows vendors to implement = automatic discovery. The link connectivity verification described in the = draft can be used to fulfill this requirement. There is no need for = extension of the messages to support this. Martin -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, May 07, 2002 5:16 PM To: Martin Dubuc Cc: Michiel van Everdingen; ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Hi Martin, Given the discussions thus far on this thread, there seems to be (from=20 my reading) a need for auto discovery as the LMP as is currently do not=20 support this capability. If you see otherwise, maybe you can point to=20 the section and text that suggests this? As for the language of ITU-T vs. IETF, let's not get into turf war here=20 but simply state why you think it's not necessary. If IETF has a set of=20 language that describes it the same way and it's equivalent then that's=20 fine, but if it's not equivalent then we obviously should look at it=20 more carefully instead of making some general statement. Since you think = the IETF document's language are adequate, then may I ask how IETF=20 differentiates some of the aspects expressed by a TTP and a CTP, because = clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its=20 info model (and since we are applying these to a SDH network, I'm=20 assuming you are also using these info models??). Of course this applies = to the OTN network as well...so the same argument is relevant... The fact that GMPLS may not use CTP and TTP is because GMPLS is looking=20 at these from the control plane perspective, while the LMP is actually=20 involved with tracking of the actual transport plane resources (so not=20 the same scope as GMPLS in terms of resource description), so can't=20 really use the GMPLS argument for adequacy... Your comments (as well as from others) are greatly appreciated. But=20 let's NOT get into turf battles, and stay strictly technical... Zhi Martin Dubuc wrote: >We don't need any update to the LMP draft to address automatic = discovery. It is possible to implement automatic discovery with the = current draft. > >I would also like to warn CCAMP that the TTP and CTP concepts used in = ITU-T specs are very complex and I do not see a reason to change any = IETF documents to comply with this terminology/framework. > >Martin > >-----Original Message----- >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] >Sent: Tuesday, May 07, 2002 11:42 AM >To: ccamp@ops.ietf.org >Subject: Re: LMP & neighbor discovery > > >Hello all, > >Please find below two proposed updates of the LMP draft. These >updates are based on the thoughts expressed in emails >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > >Your comments are appreciated ! > >Thanks, > >Michiel > > >1. Insert an additional section on "Automatic neighbor discovery" > = =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=3D=3D=3D=3D=3D=3D=3D=3D >In this section, an optional LMP procedure is described to = automatically >detect the identification of the other end of the data link. Basically, >automatic neighbor discovery is implemented by reading the incoming >'access point identifier' [ITU-T G.707]. > >A Sub-Network Point (TTP or CTP) that implements the automatic neighbor >discovery procedure MUST send its identification in the access point >identifier. The identification SHOULD be formatted into 16 bytes as >follows ([OIF 2000.159.01]): > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >|CRC|Typ|Dis| Node Identifier | Port Identifier | >+---+---+---+-------------------------------+-------------------+ > Figure 1: format of the access point identifier > to enable automatic neighbor discovery > >The format as specified in figure 1 is in line with the specification >in [ITU-T G707]. This SDH standard places the most stringent = constraints >on the contents of the access point identifiers. > >All entries in the access point identifier, except for the CRC >field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. > >CRC > The CRC-7 code of the previous frame as specified in G.707. > >Typ > The "type indicator" informs the receiver of the sender's role. > values are: > "T": Trail Termination Point > "C": Connection Termination Point > >Dis > The "distinguishing identifier" avoids the proposed format to be > confused with some other optional format, e.g. the format specified > in G.831, Appendix I. > value: > "@" > >Node Identifier > The "node identifier" is the IPv4 address that identifies the > sending Node_Id. The IPv4 address is encoded in 8 hex characters. > >Port Identifier > The "Port Identifier" identifies the sender's Interface_Id in hex > format. This gives port numbers 0-FFFFF (1,048,575) which should > be enough for all types of Network Elements. > > >As an example, a node with IP address 192.168.2.23 would sent out >the following access point identifier (excluding the CRC) from a TTP >with local interface id 421: > T@C0A802170001A5 > >A sending TTP that implements the automatic neighbor discovery scheme >will continuously send out its own identification. This is according to >ITU-T G.831, "the access point identifier should not change while the >access point remains in existence". > >A sending CTP that implements the automatic neighbor discovery scheme >MUST send its identification as long as it has not received a >linkSummary message indicating that the associated receiver has >discovered this sending CTP. The CTP MAY send its identification >continuously, until it is discovered. The CTP MAY also send its >identification in intervals, until it is discovered. > > >Example: figure 2 shows 4 network elements (NEs) and a single data >link between these NEs. Two NEs terminate the data link on interfaces >marked with 'T' (TTP). Two other NEs are transparent to the data link >on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH >multiplexers; NE-2 and NE-3 are transparent optical cross connects; >the data link is STM-N/OC-N. > >Note that neighbor discovery is defined per datalink, so the actual >number of datalinks per NE is not relevant. > >+------+ +------+ +------+ +------+ >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >| | A | | B | | C | | >| | | | | | | | >| NE-1 | | NE-2 | | NE-3 | | NE-4 | >+------+ +------+ +------+ +------+ > Figure 2: automatic discovery example - 1 > >NE-2 should, when it wants to discover data link B, connect >a test-set that sends an access point identifier to identify >the sending connection point C in NE-2. This test-signal should >be send long enough for NE-3 to detect and read the test-signal. >NE-3 will continuously scan all its not discovered input ports >for a discovery signal. > >At some point, NE-3 will detect the test-signal on data link B. >See figure 3. > >+------+ +------+ +------+ +------+ >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >| | A | / | B | \ | C | | >| | | T | | T | | | >| NE-1 | | NE-2 | | NE-3 | | NE-4 | >+------+ +------+ +------+ +------+ > Figure 3: automatic discovery example - 2 > >When NE-3 has read the access point identifier in the test signal, >data link B is discovered. Subsequent link property correlation can >then be invoked. > >Discovery of data link A is similar, except that the access point >identifier is continuously sent. Discovery of data link C is also >similar, except that the access point identifier is continuously >monitored. In other words, there is no need for a sending respectively >monitoring 'test-set' in NE-1 and NE-4. > >Data link type Access point identifier to be used >-------------- ---------------------------------- >STM-N, OC-N J0 >STS-1/3/.../VC-3/4/... J1 >VT-1.5/VC-11/12 J2 > > > >A Sub-Network Point (TTP or CTP) MAY also use an alternative format >for the access point identifier, e.g. the one specified in >G.831, Appendix I. In this case, discovery of the address of the >sending access point will need involvement of a 'name server'. Using >an alternative format is, for example, needed in case the address >of the access point can not be encoded in the limited length of >the access point identifier, e.g. because IPv6 is used in >the control plane. > > >2. Add Additional text to section 4, "Link Property Correlation" > = =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=3D=3D=3D=3D=3D=3D=3D >Note that the verify procedure is only applicable for CTP-->--CTP >and CTP-->--TTP dataLinks. The verify procedure is not applicable >for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send >out their identification; the receiver can therefore at any time >verify the connectivity of the dataLink. > > > =20 > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 23:21:14 -0700 Date: Wed, 8 May 2002 23:18:41 -0700 (PDT) From: Kireeti Kompella To: Don Fedyk cc: , CCAMP , Subject: RE: How many can administrative groups assigned? Message-ID: <20020508231129.C61949-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 May 2002, Don Fedyk wrote: > You state the definitions are clear Here's what the OSPF TE doc says: 2.5.9. Resource Class/Color The Resource Class/Color sub-TLV specifies administrative group membership for this link, in terms of a bit mask. The ISIS TE doc has: 4.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. Seems perfectly clear to me that both are talking about *bits*; the OSPF doc uses the term 'bit mask', which makes it crystal clear. > but last time I read a couple of > implementations > from vendor specification they were different. Since when does a vendor's "specification" define a standard? > While I agree we should keep the complexity to a minimum, > when I floated a simple request to define the bits the > pushback we got was it was too inflexible. Different issue altogether. The semantics of *bits* is perfectly clear. The *use* of bits should be left completely up to the user. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 23:10:51 -0700 Message-Id: <4.3.2.7.2.20020509015811.02b737e8@sword.cisco.com> Date: Thu, 09 May 2002 02:07:48 -0400 To: Nik Langrind , "'ccamp@ops.ietf.org'" From: Zafar Ali Subject: Re: TransmissionRate in LMP BeginVery Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_59790133==_.ALT" --=====================_59790133==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:37 PM 5/8/2002 -0400, Nik Langrind wrote: >Hi, > >What is the purpose of including the Transmission Rate field in the Begin >Verify message? Dear Nik, An example case where this field is useful is the case of an optical cross connect, where you have limited (or one) LMP termination units (unit). In this case the LMP neighbor is suggesting the transmission rate at which the verification message will be sent, rather than expecting the receiver's termination unit to "hunt" for it. >If a group of ports will be verified in one pass verification, and the >ports have different transmission speeds... then what? The transmission rate should always be set to the rate at which the actual verification message will be sent. Thanks Regards... Zafar > > >Thanks, >Nik =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_59790133==_.ALT Content-Type: text/html; charset="us-ascii" At 04:37 PM 5/8/2002 -0400, Nik Langrind wrote:
Hi,
 
What is the purpose of including the Transmission Rate field in the Begin Verify message?

Dear Nik,

An example case where this field is useful is the case of an optical cross connect, where you have limited (or one) LMP termination units (unit). In this case the LMP neighbor is suggesting the transmission rate at which the verification message will be sent, rather than expecting the receiver's termination unit to "hunt" for it.

If a group of ports will be verified in one pass verification, and the ports have different transmission speeds... then what?

The transmission rate should always be set to the rate at which the actual verification message will be sent.

Thanks

Regards... Zafar
 
 
Thanks,
Nik

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com

 --=====================_59790133==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 22:25:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "sushantm" To: "John Drake" Cc: "Manoj Agiwal" , "'Ccamp \(E-mail\)" , "mpls@UU. NET \(E-mail\)" , "'Suresh Katukam'" , "Zafar Ali" Subject: RE: Label Set Object Date: Thu, 9 May 2002 10:45:11 +0530 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi John , I agree to the first case but in the second case, suppose the ERO is not used , why would we have to restrict the Label set to only one label value ? -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John Drake Sent: Thursday, May 09, 2002 7:08 AM To: 'Suresh Katukam'; Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object Is it the case that ALL current SONET/SDH equipment has the restriction that the labels (timeslots) must be the same in both directions? If this is the case, then it's really simple; for an SONET/SDH LSP, only the upstream label needs to be specified, and the downstream label MUST be the same. One the other hand, if not all current SONET/SDH equipment has this restriction or the current SONET/SDH standards allow the labels (timeslots) to be different in each direction, then label set with one value or explicit label control would be useful for equipment that does have this restriction. -----Original Message----- From: Suresh Katukam [mailto:skatukam@cisco.com] Sent: Wednesday, May 08, 2002 3:23 PM To: Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 21:21:07 -0700 From: "Fong Liaw" To: "manoj juneja" , Cc: , Subject: RE: Connection Deletion in GMPLS Date: Wed, 8 May 2002 21:19:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Manoj > Is it mandatory to send admin status as down in PATH message > prior to connection deletion ? If yes, then the PATH message will THe -rsvp-07.txt says "SHOULD". > carry the > objects like ERO, Generalized Label Request which are not > necessary at the > stage of connection deletion. But one need send these as these > are mandatory > parameters (at least Gen. Label Request) in the PATH message. I > think, that > these parameters are redundant at this stage as the only > parameter that is > going to be changed is admin status. What is the use of sending > the complete > PATH message at this stage ? This goal can be achieved by just > having a new > message which will carry the session object, admin status object (but not > the parameters like Gen. Label Request, Protection Information, ERO etc.). The administrative state is to change a connection's state, so its use is not just for deletion, although that is what's defined now. The object needs to be processed on every node of the path, so Path and Resv is a nature choice and is what RSVP do to change/modify parameters or a connection/reservation. As I said in my last email, deletion performance in a normal deletion scenario is not a major concern. Do you have a real performance target that you can not achieve because of the extra objects in the Path and Resv? If so, can you share with us what they are ? Otherwise, I guess we have to agree on this disagreement. Or others can speak up :-) Regards, -Fong Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 19:44:02 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F6A2@nimbus> From: John Drake To: 'Anca Zamfir' , Zafar Ali Cc: "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com, "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 19:42:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Lou and I just reviewed section 5.1.1 of draft-ietf-mpls-generalized-rsvp-te-07.txt (rather than draft-ietf-mpls-generalized-signaling-08.txt, which is what I looked at this morning), and it's pretty clear. The upstream node processing the ERO for the outgoing link checks whether there are explicit label control subobjects for upstream or downstream. An explicit label control for upstream is replaced in the ERO with an upstream label and an explicit label control for downstream is replaced with a label set with the same label. This is so done so that there is only one mechanism for an upstream node to specify the downstream label; explicit label control is only used by a remote node. So the only question is whether for SONET/SDH LSPs, this mechanism is required. -----Original Message----- From: Anca Zamfir [mailto:ancaz@cisco.com] Sent: Wednesday, May 08, 2002 4:48 PM To: Zafar Ali Cc: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail); skatukam@cisco.com; mpls@UU. NET (E-mail) Subject: RE: Label Set Object Trying to find the answer to the original question. If a node wants to use Label Set to make sure the downstream label has the same value as the upstream one, then, I don't see why it cannot fill in the Label Set in the same way it fills in the Upstream Label, as described in draft-ietf-ccamp-gmpls-sonet-sdh-03.txt, section 3, for the case NVC=n and MT=m case. (Theoretically a node could apply this algorithm p times) A node that receives and chooses to interpret LabelSet would know how to interpret its content by looking at the traffic parameters (in particular for this example at the NVC and MT values) which would provide a way to "decode" the ordered set of SUKLM labels present in Label Set. I may be wrong, but I think in theory it is possible to use Label Set for this case. As others pointed out, not sure how practical it is. Anca At 07:04 PM 5/8/2002 -0400, Zafar Ali wrote: >At 01:07 PM 5/8/2002 -0700, John Drake wrote: >>Label Set and Explicit Label Control are used for different purposes, and >>as I understand it, Explicit Label Control is more natural for >>establishing SONET/SDH LSPs, while Label Set is more natural for >>establishing wavelength LSPs. >>You could, however, use Label Set for SONET/SDH LSPs and Explicit Label >>Control for wavelength LSPs. > >Hi John, > >While I agree with the last statement, I didn't understand why you >mentioned that explicit label control is more natural for SONET/ SDH. IMHO >the label set is a more natural way of constraining labels in all scenarios. > >Any way, this is a non-debate, in the light of the email sent by Suresh in >which he suggested that the constraints are implied by the nature of the >TDM circuits. I agree with Suresh that there is no point of copying the >same parameters using the other means, if they can be implied. > >Thanks > >Regards... Zafar >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:57 AM >>To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; >>'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi Jonh, >> Sorry for creating the confusion. Should the label set be >> used for establishing the SDH/SONET LSPs ? >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:50 AM >>To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp >>(E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>I didn't say that. >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:48 AM >>To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi John, >> Did u mean Explicit label control is used only for >> SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case >> then it should be clearly mentioned in the draft. Furthermore, it should >> also be mentioned that label set is not used for SDH/SONET LSPs. >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:26 AM >>To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Explicit Label Control is used to handle the SONET/SDH case. Its >>semantics are different than Label Set, in the sense that there is one >>and only one value, rather than a set that is manipulated end-end >> >>Thanks, >> >>John >> >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 10:31 AM >>To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>Dear Vinay, >> >>Please see comments in-lined. >> >>Thanks >> >>Regards... Zafar >>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >>>Hi Zafar, >>>The Label Set Object can't be sent to constrain the downstream label >>>when the LSP encoding type is Sonet/SDH. Consider the example where a >>>request is sent to downstream with SONET/SDH traffic parameters as NVC=n >>>and MT=m. The label expected from the downstream would be 'm' set of >>>labels each set consisting of 'n' labels further that identify each of >>>the virtual concatenated components. So a Label Set in this scenario >>>would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. >>>Such a Label Set cannot be encoded using the object/TLV structure of >>>Label Set as in "Generalized MPLS - Signalling Functional Description - >>>draft-ietf-mpls-generalized-signaling-08.txt". >>I think, this would be a second level question/ issue. IMO, we should be >>able to build on the concept of a label set to incorporate technologies >>other than WDM. Can we, in principle, agree on this or you are aware of >>an alternative for the case you mentioned above? >>>Label Set Object can be sent only in WDM scenario where a single >>>wavelength is requested as a label and the upstream has a restriction on >>>the usable wavelengths. >>IMHO this would be an undesirable restriction. Why its cannot cover the >>single label case in SONET? >> >>>Correct me if I am going wrong anywhere. >>> >>>Regards >>>Vinay >>>>----- Original Message ----- >>>>From: Zafar Ali >>>>To: Manoj Agiwal ; >>>>'Ccamp (E-mail) >>>>Cc: mpls@UU. NET (E-mail) >>>>Sent: Wednesday, May 08, 2002 11:04 AM >>>>Subject: Re: Label Set Object >>>> >>>>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>>>Hi , >>>>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>>>> architecture on >>>>>gmpls has described Label Set object usage >>>>> only for the "optical" domain viz. for carrying wavelengths ( >>>>> Section >>>>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>>>> >>>>> Do we require to send Label set(i.e. time slots) for TDM >>>>> switching as >>>>>well . In what way it can be useful . >>>>Dear Manoj, >>>> >>>>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>>>additional requirement that the two interfaces of a bidirectional LSP >>>>SHOULD traverse the exact same link with the same SUKLM values for the >>>>two directions. >>>> The label set object can be used to constrain the downstream label to >>>> the same as the upstream label. >>>> >>>>Thanks >>>> >>>>Regards... Zafar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Regards , >>>>>Manoj >>>>=============== >>>>Zafar Ali >>>>Cisco Systems >>>>(734) 276-2459 >>>>100 S Main St. #200 >>>>Ann Arbor, MI 48104. >>>>email: zali@cisco.com > > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 18:39:08 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F69F@nimbus> From: John Drake To: 'Suresh Katukam' , Zafar Ali Cc: Manoj Agiwal , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 18:37:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Is it the case that ALL current SONET/SDH equipment has the restriction that the labels (timeslots) must be the same in both directions? If this is the case, then it's really simple; for an SONET/SDH LSP, only the upstream label needs to be specified, and the downstream label MUST be the same. One the other hand, if not all current SONET/SDH equipment has this restriction or the current SONET/SDH standards allow the labels (timeslots) to be different in each direction, then label set with one value or explicit label control would be useful for equipment that does have this restriction. -----Original Message----- From: Suresh Katukam [mailto:skatukam@cisco.com] Sent: Wednesday, May 08, 2002 3:23 PM To: Zafar Ali Cc: Manoj Agiwal; Manoj Agiwal; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: RE: Label Set Object For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 16:49:02 -0700 Message-Id: <4.3.2.7.2.20020508192337.01dd6130@toque.cisco.com> Date: Wed, 08 May 2002 19:47:51 -0400 To: Zafar Ali From: Anca Zamfir Subject: RE: Label Set Object Cc: John Drake , "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com, "mpls@UU. NET (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Trying to find the answer to the original question. If a node wants to use Label Set to make sure the downstream label has the same value as the upstream one, then, I don't see why it cannot fill in the Label Set in the same way it fills in the Upstream Label, as described in draft-ietf-ccamp-gmpls-sonet-sdh-03.txt, section 3, for the case NVC=n and MT=m case. (Theoretically a node could apply this algorithm p times) A node that receives and chooses to interpret LabelSet would know how to interpret its content by looking at the traffic parameters (in particular for this example at the NVC and MT values) which would provide a way to "decode" the ordered set of SUKLM labels present in Label Set. I may be wrong, but I think in theory it is possible to use Label Set for this case. As others pointed out, not sure how practical it is. Anca At 07:04 PM 5/8/2002 -0400, Zafar Ali wrote: >At 01:07 PM 5/8/2002 -0700, John Drake wrote: >>Label Set and Explicit Label Control are used for different purposes, and >>as I understand it, Explicit Label Control is more natural for >>establishing SONET/SDH LSPs, while Label Set is more natural for >>establishing wavelength LSPs. >>You could, however, use Label Set for SONET/SDH LSPs and Explicit Label >>Control for wavelength LSPs. > >Hi John, > >While I agree with the last statement, I didn't understand why you >mentioned that explicit label control is more natural for SONET/ SDH. IMHO >the label set is a more natural way of constraining labels in all scenarios. > >Any way, this is a non-debate, in the light of the email sent by Suresh in >which he suggested that the constraints are implied by the nature of the >TDM circuits. I agree with Suresh that there is no point of copying the >same parameters using the other means, if they can be implied. > >Thanks > >Regards... Zafar >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:57 AM >>To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; >>'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi Jonh, >> Sorry for creating the confusion. Should the label set be >> used for establishing the SDH/SONET LSPs ? >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:50 AM >>To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp >>(E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>I didn't say that. >>-----Original Message----- >>From: Juneja, Manoj [mailto:m_juneja@trillium.com] >>Sent: Wednesday, May 08, 2002 11:48 AM >>To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Hi John, >> Did u mean Explicit label control is used only for >> SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case >> then it should be clearly mentioned in the draft. Furthermore, it should >> also be mentioned that label set is not used for SDH/SONET LSPs. >> >>Regards, >>manoj. >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Wednesday, May 08, 2002 11:26 AM >>To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: RE: Label Set Object >> >>Explicit Label Control is used to handle the SONET/SDH case. Its >>semantics are different than Label Set, in the sense that there is one >>and only one value, rather than a set that is manipulated end-end >> >>Thanks, >> >>John >> >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 10:31 AM >>To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>Dear Vinay, >> >>Please see comments in-lined. >> >>Thanks >> >>Regards... Zafar >>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >>>Hi Zafar, >>>The Label Set Object can't be sent to constrain the downstream label >>>when the LSP encoding type is Sonet/SDH. Consider the example where a >>>request is sent to downstream with SONET/SDH traffic parameters as NVC=n >>>and MT=m. The label expected from the downstream would be 'm' set of >>>labels each set consisting of 'n' labels further that identify each of >>>the virtual concatenated components. So a Label Set in this scenario >>>would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. >>>Such a Label Set cannot be encoded using the object/TLV structure of >>>Label Set as in "Generalized MPLS - Signalling Functional Description - >>>draft-ietf-mpls-generalized-signaling-08.txt". >>I think, this would be a second level question/ issue. IMO, we should be >>able to build on the concept of a label set to incorporate technologies >>other than WDM. Can we, in principle, agree on this or you are aware of >>an alternative for the case you mentioned above? >>>Label Set Object can be sent only in WDM scenario where a single >>>wavelength is requested as a label and the upstream has a restriction on >>>the usable wavelengths. >>IMHO this would be an undesirable restriction. Why its cannot cover the >>single label case in SONET? >> >>>Correct me if I am going wrong anywhere. >>> >>>Regards >>>Vinay >>>>----- Original Message ----- >>>>From: Zafar Ali >>>>To: Manoj Agiwal ; >>>>'Ccamp (E-mail) >>>>Cc: mpls@UU. NET (E-mail) >>>>Sent: Wednesday, May 08, 2002 11:04 AM >>>>Subject: Re: Label Set Object >>>> >>>>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>>>Hi , >>>>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>>>> architecture on >>>>>gmpls has described Label Set object usage >>>>> only for the "optical" domain viz. for carrying wavelengths ( >>>>> Section >>>>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>>>> >>>>> Do we require to send Label set(i.e. time slots) for TDM >>>>> switching as >>>>>well . In what way it can be useful . >>>>Dear Manoj, >>>> >>>>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>>>additional requirement that the two interfaces of a bidirectional LSP >>>>SHOULD traverse the exact same link with the same SUKLM values for the >>>>two directions. >>>> The label set object can be used to constrain the downstream label to >>>> the same as the upstream label. >>>> >>>>Thanks >>>> >>>>Regards... Zafar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Regards , >>>>>Manoj >>>>=============== >>>>Zafar Ali >>>>Cisco Systems >>>>(734) 276-2459 >>>>100 S Main St. #200 >>>>Ann Arbor, MI 48104. >>>>email: zali@cisco.com > > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 16:28:16 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F69D@nimbus> From: John Drake To: 'Zafar Ali' , "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 16:26:58 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6E7.D93A00E0" 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_01C1F6E7.D93A00E0 Content-Type: text/plain; charset="iso-8859-1" In the SONET/SDH case, there's always one and only one label, so isn't label set overkill? That's what I meant by 'more natural'. As George pointed out, in the downstream direction either explicit label control or a label set with one value is a useful thing in the manner of 'belt and suspenders' -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 4:05 PM To: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail); skatukam@cisco.com Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object At 01:07 PM 5/8/2002 -0700, John Drake wrote: Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs. Hi John, While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios. Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied. Thanks Regards... Zafar -----Original Message----- From: Juneja, Manoj [ mailto:m_juneja@trillium.com ] Sent: Wednesday, May 08, 2002 11:57 AM To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [ mailto:jdrake@calient.net ] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [ mailto:m_juneja@trillium.com ] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [ mailto:jdrake@calient.net ] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [ mailto:zali@cisco.com ] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6E7.D93A00E0 Content-Type: text/html; charset="iso-8859-1"
In the SONET/SDH case, there's always one and only one label, so isn't label set overkill?  That's what I meant by 'more natural'.
 
As George pointed out, in the downstream direction either explicit label control or a label set with one value is a useful thing in the manner of 'belt and suspenders'
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 4:05 PM
To: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail); skatukam@cisco.com
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

At 01:07 PM 5/8/2002 -0700, John Drake wrote:
Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural  for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. 
You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs.

Hi John,

While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios.

Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied.

Thanks

Regards... Zafar
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:57 AM
To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end
Thanks,
John
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object
Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".
I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.
IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .
Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar





Regards ,
Manoj
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6E7.D93A00E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 16:06:23 -0700 Message-Id: <4.3.2.7.2.20020508181334.058a4258@sword.cisco.com> Date: Wed, 08 May 2002 19:04:57 -0400 To: John Drake , "'Juneja, Manoj'" , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" , skatukam@cisco.com From: Zafar Ali Subject: RE: Label Set Object Cc: "mpls@UU. NET (E-mail)" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34419362==_.ALT" --=====================_34419362==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:07 PM 5/8/2002 -0700, John Drake wrote: >Label Set and Explicit Label Control are used for different purposes, and >as I understand it, Explicit Label Control is more natural for >establishing SONET/SDH LSPs, while Label Set is more natural for >establishing wavelength LSPs. >You could, however, use Label Set for SONET/SDH LSPs and Explicit Label >Control for wavelength LSPs. Hi John, While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios. Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied. Thanks Regards... Zafar >-----Original Message----- >From: Juneja, Manoj [mailto:m_juneja@trillium.com] >Sent: Wednesday, May 08, 2002 11:57 AM >To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; >'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >Hi Jonh, > Sorry for creating the confusion. Should the label set be > used for establishing the SDH/SONET LSPs ? > >Regards, >manoj. >-----Original Message----- >From: John Drake [mailto:jdrake@calient.net] >Sent: Wednesday, May 08, 2002 11:50 AM >To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp >(E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >I didn't say that. >-----Original Message----- >From: Juneja, Manoj [mailto:m_juneja@trillium.com] >Sent: Wednesday, May 08, 2002 11:48 AM >To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >Hi John, > Did u mean Explicit label control is used only for > SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case > then it should be clearly mentioned in the draft. Furthermore, it should > also be mentioned that label set is not used for SDH/SONET LSPs. > >Regards, >manoj. >-----Original Message----- >From: John Drake [mailto:jdrake@calient.net] >Sent: Wednesday, May 08, 2002 11:26 AM >To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: RE: Label Set Object > >Explicit Label Control is used to handle the SONET/SDH case. Its >semantics are different than Label Set, in the sense that there is one and >only one value, rather than a set that is manipulated end-end > >Thanks, > >John > >-----Original Message----- >From: Zafar Ali [mailto:zali@cisco.com] >Sent: Wednesday, May 08, 2002 10:31 AM >To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: Re: Label Set Object > >Dear Vinay, > >Please see comments in-lined. > >Thanks > >Regards... Zafar >At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >>Hi Zafar, >>The Label Set Object can't be sent to constrain the downstream label when >>the LSP encoding type is Sonet/SDH. Consider the example where a request >>is sent to downstream with SONET/SDH traffic parameters as NVC=n and >>MT=m. The label expected from the downstream would be 'm' set of labels >>each set consisting of 'n' labels further that identify each of the >>virtual concatenated components. So a Label Set in this scenario would >>consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a >>Label Set cannot be encoded using the object/TLV structure of Label Set >>as in "Generalized MPLS - Signalling Functional Description - >>draft-ietf-mpls-generalized-signaling-08.txt". >I think, this would be a second level question/ issue. IMO, we should be >able to build on the concept of a label set to incorporate technologies >other than WDM. Can we, in principle, agree on this or you are aware of an >alternative for the case you mentioned above? > >>Label Set Object can be sent only in WDM scenario where a single >>wavelength is requested as a label and the upstream has a restriction on >>the usable wavelengths. >IMHO this would be an undesirable restriction. Why its cannot cover the >single label case in SONET? > >>Correct me if I am going wrong anywhere. >> >>Regards >>Vinay >>>----- Original Message ----- >>>From: Zafar Ali >>>To: Manoj Agiwal ; >>>'Ccamp (E-mail) >>>Cc: mpls@UU. NET (E-mail) >>>Sent: Wednesday, May 08, 2002 11:04 AM >>>Subject: Re: Label Set Object >>> >>>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>>Hi , >>>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>>> architecture on >>>>gmpls has described Label Set object usage >>>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>>> >>>> Do we require to send Label set(i.e. time slots) for TDM >>>> switching as >>>>well . In what way it can be useful . >>>Dear Manoj, >>> >>>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>>additional requirement that the two interfaces of a bidirectional LSP >>>SHOULD traverse the exact same link with the same SUKLM values for the >>>two directions. >>> The label set object can be used to constrain the downstream label to >>> the same as the upstream label. >>> >>>Thanks >>> >>>Regards... Zafar >>> >>> >>> >>> >>> >>>>Regards , >>>>Manoj >>>=============== >>>Zafar Ali >>>Cisco Systems >>>(734) 276-2459 >>>100 S Main St. #200 >>>Ann Arbor, MI 48104. >>>email: zali@cisco.com =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_34419362==_.ALT Content-Type: text/html; charset="us-ascii" At 01:07 PM 5/8/2002 -0700, John Drake wrote:
Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural  for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. 
You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs.

Hi John,

While I agree with the last statement, I didn't understand why you mentioned that explicit label control is more natural for SONET/ SDH. IMHO the label set is a more natural way of constraining labels in all scenarios.

Any way, this is a non-debate, in the light of the email sent by Suresh in which he suggested that the constraints are implied by the nature of the TDM circuits. I agree with Suresh that there is no point of copying the same parameters using the other means, if they can be implied.

Thanks

Regards... Zafar
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:57 AM
To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object
Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object
Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".
I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.
IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .
Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar





Regards ,
Manoj
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
 --=====================_34419362==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 15:34:01 -0700 Message-Id: <200205082233.SAA14703@bifocal.cisco.com> To: Suresh Katukam cc: Zafar Ali , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" , swallow@cisco.com Subject: Re: Label Set Object Date: Wed, 08 May 2002 18:33:32 -0400 From: George Swallow > So in practice, one does not need to specify LABEL SET or Suggested label > for TDM links. While I agree with your assessment of what is necessary, it might help interoperability by including a label set with one label which is the same label as the upstream label. This covers you if someone else changes their practice (for some stange and/or broken reason). ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 15:24:41 -0700 Message-Id: <4.3.2.7.2.20020508151825.0328c598@mira1.cisco.com> Date: Wed, 08 May 2002 15:23:04 -0700 To: Zafar Ali From: Suresh Katukam Subject: RE: Label Set Object Cc: Manoj Agiwal , Manoj Agiwal , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed For TDM, since you have to use same labels in both directions, why do you have to specify anything at all? How can a downstream TDM node pick a label that does not match with Upstream label for a bidirectional LSP? If it picks any other label, LSP is not functional. If there are Uni-directional LSPs in TDM and if you have different types of time slots available in both directions, then one may be able to setup bidirectional LSP on different links or different labels. This is in theory and not in practice. So in practice, one does not need to specify LABEL SET or Suggested label for TDM links. Thanks, Suresh At 01:53 AM 5/8/2002 -0400, Zafar Ali wrote: >At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> I guess in that case we can use Suggested Label , Label Set still can >> still be avoided . > >Hi Manoj, > >No, the use of suggested label in this case would NOT be correct, as the >suggested labels can be ignored/ overridden by the receiving node. > >Thanks > >Regards... Zafar > >>Regards , >>Manoj >>-----Original Message----- >>From: Zafar Ali [mailto:zali@cisco.com] >>Sent: Wednesday, May 08, 2002 11:05 AM >>To: Manoj Agiwal; 'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >> >> >> >> >> >> >>>Regards , >>>Manoj >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com > >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 14:15:24 -0700 Message-ID: From: Jonathan Lang To: 'Yangguang Xu' , Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Subject: RE: LMP & neighbor discovery (verify_id) Date: Wed, 8 May 2002 14:06:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yanguang, To clarify things, we've added a few lines of text to the example of Section 5.1 explaining how VerifyId is bound to the remote node. Thanks, Jonathan 5.1. Example of Link Connectivity Verification Figure 1 shows an example of the link verification scenario that is executed when a link between Node A and Node B is added. In this example, the TE link consists of three free ports (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows: o A sends a BeginVerify message over the control channel to B indicating it will begin verifying the ports that form the TE link. The LOCAL_LINK_ID object carried in the BeginVerify message carries the identifier (IP address or interface index) that A assigns to the link. o Upon receipt of the BeginVerify message, B creates a VerifyId and binds it to the TE Link from A. This binding is used later when B receives the Test messages from A, and these messages carry the VerifyId. B discovers the identifier (IP address or interface index) that A assigns to the TE link by examining the LOCAL_LINK_ID object carried in the received BeginVerify message. (If the data ports are not yet assigned to the TE Link, the binding is limited to the Node Id of A.) In response to the BeginVerify message, B sends to A the BeginVerifyAck message. The LOCAL_LINK_ID object carried in the BeginVerifyAck message is used to carry the identifier (IP address or interface index) that B assigns to the TE link. The REMOTE_LINK_ID object carried in the BeginVerifyAck message is used to bind the TE link Ids assigned by both A and B. The VerifyId is returned to A in the BeginVerifyAck message over the control channel. o When A receives the BeginVerifyAck message, it begins transmitting periodic Test messages over the first port (Interface Id=1). The Test message includes the Interface Id for the port and the VerifyId that was assigned by B. o When B receives the Test messages, it maps the received Interface Id to its own local Interface Id = 10 and transmits a TestStatusSuccess message over the control channel back to PXC A. The TestStatusSuccess message includes both the local and received Interface Ids for the port as well as the VerifyId. The VerifyId is used to determine the local/remote TE link identifiers (IP addresses or interface indices) for which the data links belong. o A will send a TestStatusAck message over the control channel back to B indicating it received the TestStatusSuccess message. o The process is repeated until all of the ports are verified. o At this point, A will send an EndVerify message over the control channel to B to indicate that testing is complete. o B will respond by sending an EndVerifyAck message over the control channel back to A. Note that this procedure can be used to "discover" the connectivity of the data ports. > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Wednesday, May 08, 2002 7:46 AM > To: Yangguang Xu > Cc: ccamp@ops.ietf.org > Subject: Re: LMP & neighbor discovery (verify_id) > > > Yangguang, > > That's seems more than clear from the definition of the VERIFY_ID > object but Michiel mentioned he wants a node ID as indicated in > the frame format he provided (for "discovery" purposes): > > > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| > > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > |CRC|Typ|Dis| Node Identifier | Port Identifier | > > +---+---+---+-------------------------------+-------------------+ > > If this is not the case (ie the node id is not a node unique > value), then please provide more information on how the node > id is defined in the above frame this from the definition we > have received from him: > > > Node Identifier > > The "node identifier" is the IPv4 address that identifies the > > sending Node_Id. The IPv4 address is encoded in 8 hex characters. > > Link Property Correlation message related exchanges are not > coupled with the above information exchange - this also part > of the global request as far as i understand it - so i don't > clearly see your point with respect to "discovery" (moreover > nothing precludes the subsequent usage of the Verify ID as > currently defined when TE Links are build up and wanted to be > verified). > > thanks, > - dimitri. > > Yangguang Xu wrote: > > > > Dimitri, > > > > > In LMP the VERIFY ID object seems to correspond to the > > > Node ID that you require; in fact from its definition: > > > > > > "The VERIFY_ID object contains a node-unique value that is > > > assigned by the generator of the BeginVerifyAck message. > > > This value is used to uniquely identify the Verification > > > process from multiple LMP neighbors and/or parallel Test > > > procedures between the same LMP neighbors." > > > > > > This i-d can be used for the purpose you have mentioned. > > > p54 of the same document gives also you more information > > > on this. > > > > I thought about this, yet, it doesn't seem to work. Indeed, > both Michiel and > > Jonathan pointed me the case that when two NEs have > parallel TE links, you need > > different verify IDs. > > > > Yangguang > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Website: http://www.rc.bel.alcatel.be/~papadimd/index.html > Address: Alcatel - Optical NA, Fr. Wellesplein, 1 > B-2018 Antwerpen, Belgium > Phone: Work: +32 3 2408491 - Home: +32 2 3434361 > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 13:38:12 -0700 Message-ID: <666478FCC801D6118E3600D0B781FC16159B9E@eccexch01.equipecom.com> From: Nik Langrind To: "'ccamp@ops.ietf.org'" Subject: TransmissionRate in LMP BeginVery Date: Wed, 8 May 2002 16:37:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6D0.23A91AC0" 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_01C1F6D0.23A91AC0 Content-Type: text/plain; charset="iso-8859-1" Hi, What is the purpose of including the Transmission Rate field in the Begin Verify message? If a group of ports will be verified in one pass verification, and the ports have different transmission speeds... then what? Thanks, Nik ------_=_NextPart_001_01C1F6D0.23A91AC0 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
What is the purpose of including the Transmission Rate field in the Begin Verify message? If a group of ports will be verified in one pass verification, and the ports have different transmission speeds... then what?
 
Thanks,
Nik
------_=_NextPart_001_01C1F6D0.23A91AC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 13:15:29 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6023F1085@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Curtis Villamizar , sven.van_den_bosch@alcatel.be Cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject: RE: How many can administrative groups assigned? Date: Wed, 8 May 2002 16:14:40 -0400 Curtis You state the definitions are clear but last time I read a couple of implementations from vendor specification they were different. While I agree we should keep the complexity to a minimum, when I floated a simple request to define the bits the pushback we got was it was too inflexible. So in my opinion administrative bits are purposely under specified by design and hence not so clear. Don > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Subject: Re: How many can administrative groups assigned? > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. so fix subscription > addresses! ] > > In message > , sven.van_d > en_bosch@alcatel.be writes: > > Naidu, Kim, > > > > I think it depends a little bit on the interpretation. In principle the > > resource classes can be interpreted either as a bit mask (in which case 32 > > 'base' classes can be defined) or as an integer value (in which case 2^32 > > values can be used). Even with the bit mask interpretation, derived > > resource classes can be built by combining multiple non-mutually exclusive > > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > > and then build your resource classes on top of those). The problem lies of > > course in the processing of the resource class information. If they are not > > used in a simple bitmask, an AND operation is not sufficient to determine > > the resource class of a link. Also, if a link would have multiple derived > > classes, different TLVs would be needed. It would make sense to expand a > > little bit on these issues in the appropriate documents. In my opinion, > > this is a general issue with the TE extensions, so it should be explained > > there. > > > > Sven. > > > The definitions are currently very clear. What you have described > differs from the current definitions and therefore would not be a > clarification to the use of admin class but a change in semantics. > > I do not know of anyone using more than a handful of admin class bits > and many who do not use them at all. Lets not take any MPLS > capability and make it any more complicated than it needs to be or > introduce arbitrary change for no good reason. > > Curtis > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 13:09:16 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F69A@nimbus> From: John Drake To: "'Juneja, Manoj'" , 'Zafar Ali' , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 13:07:22 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6CB.F6C16CF0" 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_01C1F6CB.F6C16CF0 Content-Type: text/plain; charset="iso-8859-1" Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs. You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:57 AM To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6CB.F6C16CF0 Content-Type: text/html; charset="iso-8859-1"
Label Set and Explicit Label Control are used for different purposes, and as I understand it, Explicit Label Control is more natural  for establishing SONET/SDH LSPs, while Label Set is more natural for establishing wavelength LSPs.  You could, however, use Label Set for SONET/SDH LSPs and Explicit Label Control for wavelength LSPs.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:57 AM
To: John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6CB.F6C16CF0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 11:59:02 -0700 Message-ID: From: "Juneja, Manoj" To: "'John Drake'" , "Juneja, Manoj", "'Zafar Ali'" , Vinay Vernekar, Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:57:06 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C2.263154A0" 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_01C1F6C2.263154A0 Content-Type: text/plain; charset="iso-8859-1" Hi Jonh, Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ? Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:50 AM To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6C2.263154A0 Content-Type: text/html; charset="iso-8859-1"
Hi Jonh,
              Sorry for creating the confusion. Should the label set be used for establishing the SDH/SONET LSPs ?
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:50 AM
To: 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6C2.263154A0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 11:49:49 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F699@nimbus> From: John Drake To: "'Juneja, Manoj'" , 'Zafar Ali' , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:49:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C1.18E89020" 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_01C1F6C1.18E89020 Content-Type: text/plain; charset="iso-8859-1" I didn't say that. -----Original Message----- From: Juneja, Manoj [mailto:m_juneja@trillium.com] Sent: Wednesday, May 08, 2002 11:48 AM To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6C1.18E89020 Content-Type: text/html; charset="iso-8859-1"
I didn't say that.
-----Original Message-----
From: Juneja, Manoj [mailto:m_juneja@trillium.com]
Sent: Wednesday, May 08, 2002 11:48 AM
To: John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6C1.18E89020-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 11:48:51 -0700 Message-ID: From: "Juneja, Manoj" To: "'John Drake'" , "'Zafar Ali'" , Vinay Vernekar , Manoj Agiwal, "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:48:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C0.E72A7E40" 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_01C1F6C0.E72A7E40 Content-Type: text/plain; charset="iso-8859-1" Hi John, Did u mean Explicit label control is used only for SDH/SONET case and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs. Regards, manoj. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 08, 2002 11:26 AM To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: RE: Label Set Object Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6C0.E72A7E40 Content-Type: text/html; charset="iso-8859-1"
Hi John,
               Did u mean Explicit label control is used only for SDH/SONET case  and is not used for FSC/LSC LSPs ? If this is the case then it should be clearly mentioned in the draft. Furthermore, it should also be mentioned that label set is not used for SDH/SONET LSPs.
 
Regards,
manoj.
-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Wednesday, May 08, 2002 11:26 AM
To: 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: RE: Label Set Object

Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6C0.E72A7E40-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 11:41:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200205081822.OAA54056@workhorse.fictitious.org> To: sven.van_den_bosch@alcatel.be cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject: Re: How many can administrative groups assigned? Date: Wed, 08 May 2002 14:22:11 -0400 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message , sven.van_d en_bosch@alcatel.be writes: > Naidu, Kim, > > I think it depends a little bit on the interpretation. In principle the > resource classes can be interpreted either as a bit mask (in which case 32 > 'base' classes can be defined) or as an integer value (in which case 2^32 > values can be used). Even with the bit mask interpretation, derived > resource classes can be built by combining multiple non-mutually exclusive > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > and then build your resource classes on top of those). The problem lies of > course in the processing of the resource class information. If they are not > used in a simple bitmask, an AND operation is not sufficient to determine > the resource class of a link. Also, if a link would have multiple derived > classes, different TLVs would be needed. It would make sense to expand a > little bit on these issues in the appropriate documents. In my opinion, > this is a general issue with the TE extensions, so it should be explained > there. > > Sven. The definitions are currently very clear. What you have described differs from the current definitions and therefore would not be a clarification to the use of admin class but a change in semantics. I do not know of anyone using more than a handful of admin class bits and many who do not use them at all. Lets not take any MPLS capability and make it any more complicated than it needs to be or introduce arbitrary change for no good reason. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 11:27:42 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F698@nimbus> From: John Drake To: 'Zafar Ali' , Vinay Vernekar , Manoj Agiwal , "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: RE: Label Set Object Date: Wed, 8 May 2002 11:25:57 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6BD.CC167440" 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_01C1F6BD.CC167440 Content-Type: text/plain; charset="iso-8859-1" Explicit Label Control is used to handle the SONET/SDH case. Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end Thanks, John -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Wednesday, May 08, 2002 10:31 AM To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Subject: Re: Label Set Object Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: Hi Zafar, The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? Correct me if I am going wrong anywhere. Regards Vinay ----- Original Message ----- From: Zafar Ali To: Manoj Agiwal ; 'Ccamp (E-mail) Cc: mpls@UU. NET (E-mail) Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar Regards , Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com ------_=_NextPart_001_01C1F6BD.CC167440 Content-Type: text/html; charset="iso-8859-1"
Explicit Label Control is used to handle the SONET/SDH case.  Its semantics are different than Label Set, in the sense that there is one and only one value, rather than a set that is manipulated end-end 
 
Thanks,
 
John
 
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 10:31 AM
To: Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object

Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
------_=_NextPart_001_01C1F6BD.CC167440-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 10:33:14 -0700 Message-Id: <4.3.2.7.2.20020508130634.02b77ec0@sword.cisco.com> Date: Wed, 08 May 2002 13:31:09 -0400 To: "Vinay Vernekar" , "Manoj Agiwal" , "'Ccamp (E-mail)" From: Zafar Ali Subject: Re: Label Set Object Cc: "mpls@UU. NET (E-mail)" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14391804==_.ALT" --=====================_14391804==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Vinay, Please see comments in-lined. Thanks Regards... Zafar At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote: >Hi Zafar, >The Label Set Object can't be sent to constrain the downstream label when >the LSP encoding type is Sonet/SDH. Consider the example where a request >is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. >The label expected from the downstream would be 'm' set of labels each set >consisting of 'n' labels further that identify each of the virtual >concatenated components. So a Label Set in this scenario would consist of >say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set >cannot be encoded using the object/TLV structure of Label Set as in >"Generalized MPLS - Signalling Functional Description - >draft-ietf-mpls-generalized-signaling-08.txt". I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above? >Label Set Object can be sent only in WDM scenario where a single >wavelength is requested as a label and the upstream has a restriction on >the usable wavelengths. IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET? >Correct me if I am going wrong anywhere. > >Regards >Vinay >>----- Original Message ----- >>From: Zafar Ali >>To: Manoj Agiwal ; >>'Ccamp (E-mail) >>Cc: mpls@UU. NET (E-mail) >>Sent: Wednesday, May 08, 2002 11:04 AM >>Subject: Re: Label Set Object >> >>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>>Hi , >>> In gmpls signaling extensionsions for RSVP-TE , ccamp >>> architecture on >>>gmpls has described Label Set object usage >>> only for the "optical" domain viz. for carrying wavelengths ( Section >>>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >>> >>> Do we require to send Label set(i.e. time slots) for TDM >>> switching as >>>well . In what way it can be useful . >> >>Dear Manoj, >> >>Yes, label set object is also useful in TDM case. E.g., SONET poses an >>additional requirement that the two interfaces of a bidirectional LSP >>SHOULD traverse the exact same link with the same SUKLM values for the >>two directions. >> The label set object can be used to constrain the downstream label to >> the same as the upstream label. >> >>Thanks >> >>Regards... Zafar >> >> >> >>>Regards , >>>Manoj >> >>=============== >>Zafar Ali >>Cisco Systems >>(734) 276-2459 >>100 S Main St. #200 >>Ann Arbor, MI 48104. >>email: zali@cisco.com --=====================_14391804==_.ALT Content-Type: text/html; charset="us-ascii" Dear Vinay,

Please see comments in-lined.

Thanks

Regards... Zafar
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:
Hi Zafar,
The Label Set Object can't be sent to constrain the downstream label when the LSP encoding type is Sonet/SDH. Consider the example where a request is sent to downstream with SONET/SDH traffic parameters as NVC=n and MT=m. The label expected from the downstream would be 'm' set of labels each set consisting of 'n' labels further that identify each of the virtual concatenated components. So a Label Set in this scenario would consist of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label Set cannot be encoded using the object/TLV structure of Label Set as in "Generalized MPLS - Signalling Functional Description - draft-ietf-mpls-generalized-signaling-08.txt".

I think, this would be a second level question/ issue. IMO, we should be able to build on the concept of a label set to incorporate technologies other than WDM. Can we, in principle, agree on this or you are aware of an alternative for the case you mentioned above?

Label Set Object can be sent only in WDM scenario where a single wavelength is requested as a label and the upstream has a restriction on the usable wavelengths.

IMHO this would be an undesirable restriction. Why its cannot cover the single label case in SONET?

Correct me if I am going wrong anywhere.
 
Regards
Vinay   
----- Original Message -----
From: Zafar Ali
To: Manoj Agiwal ; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Sent: Wednesday, May 08, 2002 11:04 AM
Subject: Re: Label Set Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
--=====================_14391804==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 10:08:58 -0700 Message-ID: From: "Wijnen, Bert (Bert)" To: ccamp-wg Cc: "Alex Zinin (E-mail)" Subject: new Technical Advisor Date: Wed, 8 May 2002 19:05:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" It has taken a while, but we have found anew Technical Advisor for the WG. Alex Zinin will be that Advisor. Thanks Alex. I have asked the IETF secretariat to update the WG charter page with that new info. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 07:47:14 -0700 Message-ID: <3CD93A30.48EEDD79@alcatel.be> Date: Wed, 08 May 2002 16:46:08 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: Yangguang Xu CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery (verify_id) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Yangguang, That's seems more than clear from the definition of the VERIFY_ID object but Michiel mentioned he wants a node ID as indicated in the frame format he provided (for "discovery" purposes): > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > |CRC|Typ|Dis| Node Identifier | Port Identifier | > +---+---+---+-------------------------------+-------------------+ If this is not the case (ie the node id is not a node unique value), then please provide more information on how the node id is defined in the above frame this from the definition we have received from him: > Node Identifier > The "node identifier" is the IPv4 address that identifies the > sending Node_Id. The IPv4 address is encoded in 8 hex characters. Link Property Correlation message related exchanges are not coupled with the above information exchange - this also part of the global request as far as i understand it - so i don't clearly see your point with respect to "discovery" (moreover nothing precludes the subsequent usage of the Verify ID as currently defined when TE Links are build up and wanted to be verified). thanks, - dimitri. Yangguang Xu wrote: > > Dimitri, > > > In LMP the VERIFY ID object seems to correspond to the > > Node ID that you require; in fact from its definition: > > > > "The VERIFY_ID object contains a node-unique value that is > > assigned by the generator of the BeginVerifyAck message. > > This value is used to uniquely identify the Verification > > process from multiple LMP neighbors and/or parallel Test > > procedures between the same LMP neighbors." > > > > This i-d can be used for the purpose you have mentioned. > > p54 of the same document gives also you more information > > on this. > > I thought about this, yet, it doesn't seem to work. Indeed, both Michiel and > Jonathan pointed me the case that when two NEs have parallel TE links, you need > different verify IDs. > > Yangguang -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 07:31:43 -0700 Message-ID: <010001c1f69c$5bfe2d40$8c03750a@wipro.com> From: "Vinay Vernekar" To: "Manoj Agiwal" , "'Ccamp (E-mail)" , "Zafar Ali" Cc: "mpls@UU. NET (E-mail)" Subject: Re: Label Set Object Date: Wed, 8 May 2002 19:56:34 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-272b2dcd-11ef-42e2-8bf9-f48cf99d720f" This is a multi-part message in MIME format. ------=_NextPartTM-000-272b2dcd-11ef-42e2-8bf9-f48cf99d720f Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01C1F6CA.74917140" ------=_NextPart_000_00FD_01C1F6CA.74917140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, The Label Set Object can't be sent to constrain the downstream label = when the LSP encoding type is Sonet/SDH. Consider the example where a = request is sent to downstream with SONET/SDH traffic parameters as = NVC=3Dn and MT=3Dm. The label expected from the downstream would be 'm' = set of labels each set consisting of 'n' labels further that identify = each of the virtual concatenated components. So a Label Set in this = scenario would consist of say 'p' sets each consisting of 'm' sets of = 'n' labels. Such a Label Set cannot be encoded using the object/TLV = structure of Label Set as in "Generalized MPLS - Signalling Functional = Description - draft-ietf-mpls-generalized-signaling-08.txt".=20 Label Set Object can be sent only in WDM scenario where a single = wavelength is requested as a label and the upstream has a restriction on = the usable wavelengths. Correct me if I am going wrong anywhere. Regards Vinay =20 ----- Original Message -----=20 From: Zafar Ali=20 To: Manoj Agiwal ; 'Ccamp (E-mail)=20 Cc: mpls@UU. NET (E-mail)=20 Sent: Wednesday, May 08, 2002 11:04 AM Subject: Re: Label Set Object At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp = architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( = Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .=20 Do we require to send Label set(i.e. time slots) for TDM = switching as well . In what way it can be useful .=20 Dear Manoj,=20 Yes, label set object is also useful in TDM case. E.g., SONET poses an = additional requirement that the two interfaces of a bidirectional LSP = SHOULD traverse the exact same link with the same SUKLM values for the = two directions. The label set object can be used to constrain the downstream label to = the same as the upstream label.=20 Thanks Regards... Zafar=20 Regards , Manoj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com=20 ------=_NextPart_000_00FD_01C1F6CA.74917140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Zafar,
The Label Set Object can't be sent to = constrain the=20 downstream label when the LSP encoding type is Sonet/SDH. Consider = the=20 example where a request is sent to downstream with SONET/SDH traffic = parameters=20 as NVC=3Dn and MT=3Dm. The label expected from the downstream would be = 'm' set of=20 labels each set consisting of 'n' labels further that identify each of = the=20 virtual concatenated components. So a Label Set in this scenario would = consist=20 of say 'p' sets each consisting of 'm' sets of 'n' labels. Such a Label = Set=20 cannot be encoded using the object/TLV structure of Label Set as in = "Generalized MPLS - Signalling Functional Description -=20 draft-ietf-mpls-generalized-signaling-08.txt". 
Label Set Object can be sent only in WDM = scenario where a=20 single wavelength is requested as a label and the upstream has a = restriction on=20 the usable wavelengths.
Correct me if I am going wrong = anywhere.
 
Regards
Vinay   
----- Original Message -----
From:=20 Zafar Ali =
To: Manoj Agiwal ; 'Ccamp = (E-mail)=20
Cc: mpls@UU. NET = (E-mail)
Sent: Wednesday, May 08, 2002 = 11:04=20 AM
Subject: Re: Label Set = Object

At 10:00 AM 5/8/2002 +0530, Manoj Agiwal = wrote:
Hi = ,
       In=20 gmpls signaling extensionsions for RSVP-TE , ccamp architecture = on
gmpls=20 has described Label Set object usage
    only for = the=20 "optical" domain viz. for carrying wavelengths ( Section
9.9=20 draft-ietf-ccamp-gmpls-architecture-02.txt) .=20

       Do we require to send = Label=20 set(i.e. time slots) for TDM switching as
well . In what way it = can be=20 useful .

Dear Manoj, =

Yes, label=20 set object is also useful in TDM case. E.g., SONET poses an additional = requirement that the two interfaces of a bidirectional LSP SHOULD = traverse the=20 exact same link with the same SUKLM values for the two=20 directions.
 The label set object can be used to constrain the = downstream label to the same as the upstream label.=20

Thanks

Regards... Zafar



Regards=20 = ,
Manoj

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= BR>Zafar Ali
Cisco=20 Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI=20 48104.
email: zali@cisco.com ------=_NextPart_000_00FD_01C1F6CA.74917140-- ------=_NextPartTM-000-272b2dcd-11ef-42e2-8bf9-f48cf99d720f Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-272b2dcd-11ef-42e2-8bf9-f48cf99d720f-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 07:02:16 -0700 Message-ID: <3CD92F96.AF6FC474@lucent.com> Date: Wed, 08 May 2002 10:00:54 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, > In LMP the VERIFY ID object seems to correspond to the > Node ID that you require; in fact from its definition: > > "The VERIFY_ID object contains a node-unique value that is > assigned by the generator of the BeginVerifyAck message. > This value is used to uniquely identify the Verification > process from multiple LMP neighbors and/or parallel Test > procedures between the same LMP neighbors." > > This i-d can be used for the purpose you have mentioned. > p54 of the same document gives also you more information > on this. I thought about this, yet, it doesn't seem to work. Indeed, both Michiel and Jonathan pointed me the case that when two NEs have parallel TE links, you need different verify IDs. Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 06:17:26 -0700 Message-ID: <001d01c1f66b$7855b160$9103750a@wipro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-01ac3072-148e-471c-9ee7-bf2200cf3bed" From: "Ravi Sankar Mantha" To: , "Naidu Venkata" Cc: "'???'" , , "CCAMP" , Subject: RE: How many can administrative groups assigned? Date: Wed, 8 May 2002 14:06:38 +0530 This is a multi-part message in MIME format. ------=_NextPartTM-000-01ac3072-148e-471c-9ee7-bf2200cf3bed Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] According to RFC 3212 (Constraint-Based LSP Setup using LDP ), the definition of "RsCls " (32bit) field of the Resource Class TLV is, 'The Resource Class bit mask indicating which of the 32 "administrative groupsö or "colorsö of links the CR-LSP can traverse. ' That should mean that the resource classes should be linterpreted as a bit mask. regards, Ravi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of sven.van_den_bosch@alcatel.be Sent: Wednesday, May 08, 2002 1:46 PM To: Naidu, Venkata Cc: '???'; mpls@UU.NET; CCAMP; te-wg@ops.ietf.org Subject: RE: How many can administrative groups assigned? Naidu, Kim, I think it depends a little bit on the interpretation. In principle the resource classes can be interpreted either as a bit mask (in which case 32 'base' classes can be defined) or as an integer value (in which case 2^32 values can be used). Even with the bit mask interpretation, derived resource classes can be built by combining multiple non-mutually exclusive 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on and then build your resource classes on top of those). The problem lies of course in the processing of the resource class information. If they are not used in a simple bitmask, an AND operation is not sufficient to determine the resource class of a link. Also, if a link would have multiple derived classes, different TLVs would be needed. It would make sense to expand a little bit on these issues in the appropriate documents. In my opinion, this is a general issue with the TE extensions, so it should be explained there. Sven. "Naidu, Venkata" on 07/05/2002 16:16:29 To: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: How many can administrative groups : assigned? Kim, -> If so, how many can administrative groups assigned? 32 or 2^32 ? 32. A link can me member of multiple admin groups. -- Venkata. ------=_NextPartTM-000-01ac3072-148e-471c-9ee7-bf2200cf3bed Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" **************************Disclaimer********************************************************* Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ************************************************************************************************ ------=_NextPartTM-000-01ac3072-148e-471c-9ee7-bf2200cf3bed-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 03:27:21 -0700 Message-ID: <3CD8FCF7.88C3CC26@alcatel.be> Date: Wed, 08 May 2002 12:24:55 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: Zhi-Wei Lin Cc: Martin Dubuc , Michiel van Everdingen , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Zhi, all, Let's try to have a more structured way to see this pending issue: Preliminaire: the document to which you refer tends to clearly separate the control channel issues from the discovery function(s) - this is not so obvious to be understood through the e-mails sent by your colleague for CCAMP'ers not following the G.ASON activities (and in particular having a detailed knowledge of G.7714). Please take this into account (terminology and moreover semantic in standards is much more important than what i can infer from your last e-mail) So i suggest also that people that want to have the corresponding concerns addressed provides the right input in order for our community to provide the right answer (a good example would be for instance to provide a clear explanation of what CTP and TTP means from this perspective) >From my side, i have also tried to see how we can more effectively proceed with this issue using the following approach: 1) What's currently defined in LMP In LMP the VERIFY ID object seems to correspond to the Node ID that you require; in fact from its definition: "The VERIFY_ID object contains a node-unique value that is assigned by the generator of the BeginVerifyAck message. This value is used to uniquely identify the Verification process from multiple LMP neighbors and/or parallel Test procedures between the same LMP neighbors." This i-d can be used for the purpose you have mentioned. p54 of the same document gives also you more information on this. 2) What can be expected as enhancement/update ? All the other policing usage it's up to the configuration of the LMP controller as such there are two elements that have to be clarified (1) provide content telling that in some particular circumstances the "verification" procedure can be performed without verification negotiation as such this is inline with the neighbor discovery (2) that two (optional) fields (T and D) when using in-band transport see again page 54 since there is some reserved space there so i believe it shouldn't be so dramatic to include these changes; Typ=T meaning send continuously. Also the CRC is there by definition of the pattern. Last is there something else to be expected from the 1) the last version of G.7714 and 2) last ITU-T plenary meeting discussions (i would expect a liaison statement here that would help us). 3) How does it affect the current LMP i-d ? What's the impact of these updates on the current LMP document ? A careful analysis must be performed in order to keep the global consistency of the protocol, in most cases it doesn't just suffice to say add two objects and one sentence to achieve the expected objective. 4) Last question how to deliver these updates: Do we have to include these updates into the current LMP document or into a specific GMPLS Profile document ? The question is clear but the response is not so obvious because it might very helpful to have all the ASON specifics into the same document but on the other side one should also keep some consistency ? Best regards, - dimitri. Zhi-Wei Lin wrote: > > Hi Martin, > > Given the discussions thus far on this thread, there seems to be (from > my reading) a need for auto discovery as the LMP as is currently do not > support this capability. If you see otherwise, maybe you can point to > the section and text that suggests this? > > As for the language of ITU-T vs. IETF, let's not get into turf war here > but simply state why you think it's not necessary. If IETF has a set of > language that describes it the same way and it's equivalent then that's > fine, but if it's not equivalent then we obviously should look at it > more carefully instead of making some general statement. Since you think > the IETF document's language are adequate, then may I ask how IETF > differentiates some of the aspects expressed by a TTP and a CTP, because > clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its > info model (and since we are applying these to a SDH network, I'm > assuming you are also using these info models??). Of course this applies > to the OTN network as well...so the same argument is relevant... > > The fact that GMPLS may not use CTP and TTP is because GMPLS is looking > at these from the control plane perspective, while the LMP is actually > involved with tracking of the actual transport plane resources (so not > the same scope as GMPLS in terms of resource description), so can't > really use the GMPLS argument for adequacy... > > Your comments (as well as from others) are greatly appreciated. But > let's NOT get into turf battles, and stay strictly technical... > > Zhi > > Martin Dubuc wrote: > > >We don't need any update to the LMP draft to address automatic discovery. It is possible to implement automatic discovery with the current draft. > > > >I would also like to warn CCAMP that the TTP and CTP concepts used in ITU-T specs are very complex and I do not see a reason to change any IETF documents to comply with this terminology/framework. > > > >Martin > > > >-----Original Message----- > >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] > >Sent: Tuesday, May 07, 2002 11:42 AM > >To: ccamp@ops.ietf.org > >Subject: Re: LMP & neighbor discovery > > > > > >Hello all, > > > >Please find below two proposed updates of the LMP draft. These > >updates are based on the thoughts expressed in emails > >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html > >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > > > >Your comments are appreciated ! > > > >Thanks, > > > >Michiel > > > > > >1. Insert an additional section on "Automatic neighbor discovery" > > ============================================================== > >In this section, an optional LMP procedure is described to automatically > >detect the identification of the other end of the data link. Basically, > >automatic neighbor discovery is implemented by reading the incoming > >'access point identifier' [ITU-T G.707]. > > > >A Sub-Network Point (TTP or CTP) that implements the automatic neighbor > >discovery procedure MUST send its identification in the access point > >identifier. The identification SHOULD be formatted into 16 bytes as > >follows ([OIF 2000.159.01]): > > > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > >|CRC|Typ|Dis| Node Identifier | Port Identifier | > >+---+---+---+-------------------------------+-------------------+ > > Figure 1: format of the access point identifier > > to enable automatic neighbor discovery > > > >The format as specified in figure 1 is in line with the specification > >in [ITU-T G707]. This SDH standard places the most stringent constraints > >on the contents of the access point identifiers. > > > >All entries in the access point identifier, except for the CRC > >field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. > > > >CRC > > The CRC-7 code of the previous frame as specified in G.707. > > > >Typ > > The "type indicator" informs the receiver of the sender's role. > > values are: > > "T": Trail Termination Point > > "C": Connection Termination Point > > > >Dis > > The "distinguishing identifier" avoids the proposed format to be > > confused with some other optional format, e.g. the format specified > > in G.831, Appendix I. > > value: > > "@" > > > >Node Identifier > > The "node identifier" is the IPv4 address that identifies the > > sending Node_Id. The IPv4 address is encoded in 8 hex characters. > > > >Port Identifier > > The "Port Identifier" identifies the sender's Interface_Id in hex > > format. This gives port numbers 0-FFFFF (1,048,575) which should > > be enough for all types of Network Elements. > > > > > >As an example, a node with IP address 192.168.2.23 would sent out > >the following access point identifier (excluding the CRC) from a TTP > >with local interface id 421: > > T@C0A802170001A5 > > > >A sending TTP that implements the automatic neighbor discovery scheme > >will continuously send out its own identification. This is according to > >ITU-T G.831, "the access point identifier should not change while the > >access point remains in existence". > > > >A sending CTP that implements the automatic neighbor discovery scheme > >MUST send its identification as long as it has not received a > >linkSummary message indicating that the associated receiver has > >discovered this sending CTP. The CTP MAY send its identification > >continuously, until it is discovered. The CTP MAY also send its > >identification in intervals, until it is discovered. > > > > > >Example: figure 2 shows 4 network elements (NEs) and a single data > >link between these NEs. Two NEs terminate the data link on interfaces > >marked with 'T' (TTP). Two other NEs are transparent to the data link > >on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH > >multiplexers; NE-2 and NE-3 are transparent optical cross connects; > >the data link is STM-N/OC-N. > > > >Note that neighbor discovery is defined per datalink, so the actual > >number of datalinks per NE is not relevant. > > > >+------+ +------+ +------+ +------+ > >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | > >| | A | | B | | C | | > >| | | | | | | | > >| NE-1 | | NE-2 | | NE-3 | | NE-4 | > >+------+ +------+ +------+ +------+ > > Figure 2: automatic discovery example - 1 > > > >NE-2 should, when it wants to discover data link B, connect > >a test-set that sends an access point identifier to identify > >the sending connection point C in NE-2. This test-signal should > >be send long enough for NE-3 to detect and read the test-signal. > >NE-3 will continuously scan all its not discovered input ports > >for a discovery signal. > > > >At some point, NE-3 will detect the test-signal on data link B. > >See figure 3. > > > >+------+ +------+ +------+ +------+ > >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | > >| | A | / | B | \ | C | | > >| | | T | | T | | | > >| NE-1 | | NE-2 | | NE-3 | | NE-4 | > >+------+ +------+ +------+ +------+ > > Figure 3: automatic discovery example - 2 > > > >When NE-3 has read the access point identifier in the test signal, > >data link B is discovered. Subsequent link property correlation can > >then be invoked. > > > >Discovery of data link A is similar, except that the access point > >identifier is continuously sent. Discovery of data link C is also > >similar, except that the access point identifier is continuously > >monitored. In other words, there is no need for a sending respectively > >monitoring 'test-set' in NE-1 and NE-4. > > > >Data link type Access point identifier to be used > >-------------- ---------------------------------- > >STM-N, OC-N J0 > >STS-1/3/.../VC-3/4/... J1 > >VT-1.5/VC-11/12 J2 > > > > > > > >A Sub-Network Point (TTP or CTP) MAY also use an alternative format > >for the access point identifier, e.g. the one specified in > >G.831, Appendix I. In this case, discovery of the address of the > >sending access point will need involvement of a 'name server'. Using > >an alternative format is, for example, needed in case the address > >of the access point can not be encoded in the limited length of > >the access point identifier, e.g. because IPv6 is used in > >the control plane. > > > > > >2. Add Additional text to section 4, "Link Property Correlation" > > ============================================================= > >Note that the verify procedure is only applicable for CTP-->--CTP > >and CTP-->--TTP dataLinks. The verify procedure is not applicable > >for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send > >out their identification; the receiver can therefore at any time > >verify the connectivity of the dataLink. > > > > > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 08 May 2002 01:17:23 -0700 Subject: RE: How many can administrative groups assigned? To: "Naidu, Venkata" Cc: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Message-ID: From: sven.van_den_bosch@alcatel.be Date: Wed, 8 May 2002 10:15:50 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Naidu, Kim, I think it depends a little bit on the interpretation. In principle the resource classes can be interpreted either as a bit mask (in which case 32 'base' classes can be defined) or as an integer value (in which case 2^32 values can be used). Even with the bit mask interpretation, derived resource classes can be built by combining multiple non-mutually exclusive 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on and then build your resource classes on top of those). The problem lies of course in the processing of the resource class information. If they are not used in a simple bitmask, an AND operation is not sufficient to determine the resource class of a link. Also, if a link would have multiple derived classes, different TLVs would be needed. It would make sense to expand a little bit on these issues in the appropriate documents. In my opinion, this is a general issue with the TE extensions, so it should be explained there. Sven. "Naidu, Venkata" on 07/05/2002 16:16:29 To: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: How many can administrative groups : assigned? Kim, -> If so, how many can administrative groups assigned? 32 or 2^32 ? 32. A link can me member of multiple admin groups. -- Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 22:53:59 -0700 Message-ID: <9027F68B07E7D511AE9400B0D0787DC00704A9@BRAHMA01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "mpls@UU. NET (E-mail)" Subject: Label Set Object Date: Wed, 8 May 2002 10:00:52 +0530 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi , In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on gmpls has described Label Set object usage only for the "optical" domain viz. for carrying wavelengths ( Section 9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . Do we require to send Label set(i.e. time slots) for TDM switching as well . In what way it can be useful . Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 22:53:53 -0700 Message-Id: <4.3.2.7.2.20020508014732.04577e60@sword.cisco.com> Date: Wed, 08 May 2002 01:53:05 -0400 To: Manoj Agiwal , Manoj Agiwal , "'Ccamp (E-mail)" From: Zafar Ali Subject: RE: Label Set Object Cc: "mpls@UU. NET (E-mail)" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11732159==_.ALT" --=====================_11732159==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote: >Hi , > I guess in that case we can use Suggested Label , Label Set still can > still be avoided . Hi Manoj, No, the use of suggested label in this case would NOT be correct, as the suggested labels can be ignored/ overridden by the receiving node. Thanks Regards... Zafar >Regards , >Manoj >-----Original Message----- >From: Zafar Ali [mailto:zali@cisco.com] >Sent: Wednesday, May 08, 2002 11:05 AM >To: Manoj Agiwal; 'Ccamp (E-mail) >Cc: mpls@UU. NET (E-mail) >Subject: Re: Label Set Object > >At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >>Hi , >> In gmpls signaling extensionsions for RSVP-TE , ccamp >> architecture on >>gmpls has described Label Set object usage >> only for the "optical" domain viz. for carrying wavelengths ( Section >>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . >> >> Do we require to send Label set(i.e. time slots) for TDM >> switching as >>well . In what way it can be useful . >Dear Manoj, > >Yes, label set object is also useful in TDM case. E.g., SONET poses an >additional requirement that the two interfaces of a bidirectional LSP >SHOULD traverse the exact same link with the same SUKLM values for the two >directions. > The label set object can be used to constrain the downstream label to > the same as the upstream label. > >Thanks > >Regards... Zafar > > > > > >>Regards , >>Manoj >=============== >Zafar Ali >Cisco Systems >(734) 276-2459 >100 S Main St. #200 >Ann Arbor, MI 48104. >email: zali@cisco.com =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_11732159==_.ALT Content-Type: text/html; charset="us-ascii" At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
   I guess in that case we can use Suggested Label , Label Set still can still be avoided .

Hi Manoj,

No, the use of suggested label in this case would NOT be correct, as the suggested labels can be ignored/ overridden by the receiving node.

Thanks

Regards... Zafar

Regards ,
Manoj
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Wednesday, May 08, 2002 11:05 AM
To: Manoj Agiwal; 'Ccamp (E-mail)
Cc: mpls@UU. NET (E-mail)
Subject: Re: Label Set Object
At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .
Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar





Regards ,
Manoj
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com
 --=====================_11732159==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 22:36:30 -0700 Message-Id: <4.3.2.7.2.20020508013112.04570cc8@sword.cisco.com> Date: Wed, 08 May 2002 01:34:43 -0400 To: Manoj Agiwal , "'Ccamp (E-mail)" From: Zafar Ali Subject: Re: Label Set Object Cc: "mpls@UU. NET (E-mail)" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10629654==_.ALT" --=====================_10629654==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote: >Hi , > In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on >gmpls has described Label Set object usage > only for the "optical" domain viz. for carrying wavelengths ( Section >9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . > > Do we require to send Label set(i.e. time slots) for TDM switching as >well . In what way it can be useful . Dear Manoj, Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions. The label set object can be used to constrain the downstream label to the same as the upstream label. Thanks Regards... Zafar >Regards , >Manoj =============== Zafar Ali Cisco Systems (734) 276-2459 100 S Main St. #200 Ann Arbor, MI 48104. email: zali@cisco.com --=====================_10629654==_.ALT Content-Type: text/html; charset="us-ascii" At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
Hi ,
       In gmpls signaling extensionsions for RSVP-TE , ccamp architecture on
gmpls has described Label Set object usage
    only for the "optical" domain viz. for carrying wavelengths ( Section
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) .

       Do we require to send Label set(i.e. time slots) for TDM switching as
well . In what way it can be useful .

Dear Manoj,

Yes, label set object is also useful in TDM case. E.g., SONET poses an additional requirement that the two interfaces of a bidirectional LSP SHOULD traverse the exact same link with the same SUKLM values for the two directions.
 The label set object can be used to constrain the downstream label to the same as the upstream label.

Thanks

Regards... Zafar



Regards ,
Manoj

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com --=====================_10629654==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 17:42:07 -0700 Message-ID: <20020508003855.58476.qmail@web14704.mail.yahoo.com> Date: Tue, 7 May 2002 17:38:55 -0700 (PDT) From: Fong Liaw Subject: Re: Connection Deletion in GMPLS To: manoj juneja , ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Manoj When controlling optical cross connects, it is felt that the performance target for a non-fault triggered deletion does not need to be superfast therefore message processing time is not a major concern Instead, to preserve the semantic of RSVP protocol and be compatible to majority of the deployed MPLS networks is the goal. If you are concerned about failure situation, Notify is the correct (and first) message to use. It would likely trigger protection first and then deletion can happen (slowly) after that. Regards, -Fong --- manoj juneja wrote: > [ post by non-subscriber. with the massive amount > of spam, it is easy to > miss and therefore delete mis-posts. so fix > subscription addresses! ] > > Hi All, > In GMPLS, the graceful connection deletion is > done by first > sending the Path message with admin status as down > (D & R bits on) and > then the egress node can send the PathErr message > with cause 'Path > State Removed'. > What is the requirement of sending the complete PATH > message ? This > message could (possibly a new message type) have > been kept very simple > with session and admin status objects. There are > many parameters in > path message which are not required for connection > deletion viz > TIME_VALUE, ERO, RSVP_HOP, PROTECTION, LABEL > REQUEST, SESSION > ATTRIBUTES, POLICY DATA etc. If one calculates the > size of these > parameters for a connection it can run in to more > than 50 bytes. This > means the control channel bandwidth is being wasted > for each and every > connection at the time of graceful connection > deletion by transmitting > such large messages. > Is there any reason for not keeping different > (possibly new or could > have made use of Notify message) message type for > connection deletion ? > > Furthermore, as the complete PATH message need to go > through all the nodes > in the path, more processing time will be required > to parse/process the > large message like PATH as compared to some small > message like Notify etc. > This type of processing overhead will be there for > each and every call/LSP > in GMPLS. > > Please help me in understanding this issue. > > Regards, > manoj. > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN > Hotmail. > http://www.hotmail.com > > > > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 14:17:23 -0700 Message-ID: <3CD843F7.8020901@lucent.com> Date: Tue, 07 May 2002 17:15:35 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417 MIME-Version: 1.0 To: Martin Dubuc CC: Michiel van Everdingen , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, Given the discussions thus far on this thread, there seems to be (from my reading) a need for auto discovery as the LMP as is currently do not support this capability. If you see otherwise, maybe you can point to the section and text that suggests this? As for the language of ITU-T vs. IETF, let's not get into turf war here but simply state why you think it's not necessary. If IETF has a set of language that describes it the same way and it's equivalent then that's fine, but if it's not equivalent then we obviously should look at it more carefully instead of making some general statement. Since you think the IETF document's language are adequate, then may I ask how IETF differentiates some of the aspects expressed by a TTP and a CTP, because clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its info model (and since we are applying these to a SDH network, I'm assuming you are also using these info models??). Of course this applies to the OTN network as well...so the same argument is relevant... The fact that GMPLS may not use CTP and TTP is because GMPLS is looking at these from the control plane perspective, while the LMP is actually involved with tracking of the actual transport plane resources (so not the same scope as GMPLS in terms of resource description), so can't really use the GMPLS argument for adequacy... Your comments (as well as from others) are greatly appreciated. But let's NOT get into turf battles, and stay strictly technical... Zhi Martin Dubuc wrote: >We don't need any update to the LMP draft to address automatic discovery. It is possible to implement automatic discovery with the current draft. > >I would also like to warn CCAMP that the TTP and CTP concepts used in ITU-T specs are very complex and I do not see a reason to change any IETF documents to comply with this terminology/framework. > >Martin > >-----Original Message----- >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] >Sent: Tuesday, May 07, 2002 11:42 AM >To: ccamp@ops.ietf.org >Subject: Re: LMP & neighbor discovery > > >Hello all, > >Please find below two proposed updates of the LMP draft. These >updates are based on the thoughts expressed in emails >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html > >Your comments are appreciated ! > >Thanks, > >Michiel > > >1. Insert an additional section on "Automatic neighbor discovery" > ============================================================== >In this section, an optional LMP procedure is described to automatically >detect the identification of the other end of the data link. Basically, >automatic neighbor discovery is implemented by reading the incoming >'access point identifier' [ITU-T G.707]. > >A Sub-Network Point (TTP or CTP) that implements the automatic neighbor >discovery procedure MUST send its identification in the access point >identifier. The identification SHOULD be formatted into 16 bytes as >follows ([OIF 2000.159.01]): > >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >|CRC|Typ|Dis| Node Identifier | Port Identifier | >+---+---+---+-------------------------------+-------------------+ > Figure 1: format of the access point identifier > to enable automatic neighbor discovery > >The format as specified in figure 1 is in line with the specification >in [ITU-T G707]. This SDH standard places the most stringent constraints >on the contents of the access point identifiers. > >All entries in the access point identifier, except for the CRC >field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. > >CRC > The CRC-7 code of the previous frame as specified in G.707. > >Typ > The "type indicator" informs the receiver of the sender's role. > values are: > "T": Trail Termination Point > "C": Connection Termination Point > >Dis > The "distinguishing identifier" avoids the proposed format to be > confused with some other optional format, e.g. the format specified > in G.831, Appendix I. > value: > "@" > >Node Identifier > The "node identifier" is the IPv4 address that identifies the > sending Node_Id. The IPv4 address is encoded in 8 hex characters. > >Port Identifier > The "Port Identifier" identifies the sender's Interface_Id in hex > format. This gives port numbers 0-FFFFF (1,048,575) which should > be enough for all types of Network Elements. > > >As an example, a node with IP address 192.168.2.23 would sent out >the following access point identifier (excluding the CRC) from a TTP >with local interface id 421: > T@C0A802170001A5 > >A sending TTP that implements the automatic neighbor discovery scheme >will continuously send out its own identification. This is according to >ITU-T G.831, "the access point identifier should not change while the >access point remains in existence". > >A sending CTP that implements the automatic neighbor discovery scheme >MUST send its identification as long as it has not received a >linkSummary message indicating that the associated receiver has >discovered this sending CTP. The CTP MAY send its identification >continuously, until it is discovered. The CTP MAY also send its >identification in intervals, until it is discovered. > > >Example: figure 2 shows 4 network elements (NEs) and a single data >link between these NEs. Two NEs terminate the data link on interfaces >marked with 'T' (TTP). Two other NEs are transparent to the data link >on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH >multiplexers; NE-2 and NE-3 are transparent optical cross connects; >the data link is STM-N/OC-N. > >Note that neighbor discovery is defined per datalink, so the actual >number of datalinks per NE is not relevant. > >+------+ +------+ +------+ +------+ >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >| | A | | B | | C | | >| | | | | | | | >| NE-1 | | NE-2 | | NE-3 | | NE-4 | >+------+ +------+ +------+ +------+ > Figure 2: automatic discovery example - 1 > >NE-2 should, when it wants to discover data link B, connect >a test-set that sends an access point identifier to identify >the sending connection point C in NE-2. This test-signal should >be send long enough for NE-3 to detect and read the test-signal. >NE-3 will continuously scan all its not discovered input ports >for a discovery signal. > >At some point, NE-3 will detect the test-signal on data link B. >See figure 3. > >+------+ +------+ +------+ +------+ >| T-|--->--|-C C-|--->--|-C C-|--->--|-T | >| | A | / | B | \ | C | | >| | | T | | T | | | >| NE-1 | | NE-2 | | NE-3 | | NE-4 | >+------+ +------+ +------+ +------+ > Figure 3: automatic discovery example - 2 > >When NE-3 has read the access point identifier in the test signal, >data link B is discovered. Subsequent link property correlation can >then be invoked. > >Discovery of data link A is similar, except that the access point >identifier is continuously sent. Discovery of data link C is also >similar, except that the access point identifier is continuously >monitored. In other words, there is no need for a sending respectively >monitoring 'test-set' in NE-1 and NE-4. > >Data link type Access point identifier to be used >-------------- ---------------------------------- >STM-N, OC-N J0 >STS-1/3/.../VC-3/4/... J1 >VT-1.5/VC-11/12 J2 > > > >A Sub-Network Point (TTP or CTP) MAY also use an alternative format >for the access point identifier, e.g. the one specified in >G.831, Appendix I. In this case, discovery of the address of the >sending access point will need involvement of a 'name server'. Using >an alternative format is, for example, needed in case the address >of the access point can not be encoded in the limited length of >the access point identifier, e.g. because IPv6 is used in >the control plane. > > >2. Add Additional text to section 4, "Link Property Correlation" > ============================================================= >Note that the verify procedure is only applicable for CTP-->--CTP >and CTP-->--TTP dataLinks. The verify procedure is not applicable >for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send >out their identification; the receiver can therefore at any time >verify the connectivity of the dataLink. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 11:30:45 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A799@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" Cc: Sudheer Dharanikota , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Tue, 7 May 2002 11:28:48 -0700 MIME-Version: 1.0 Content-Type: text/plain What is the physical architecture? Is it still a ring? a single ring? -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, May 06, 2002 8:46 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; Sudheer Dharanikota; Gary Tam; > Ajay Simha; > Ron Bonica; Brijesh Kumar; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > > > In message > <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > links under their MPLS network cutting some costs > significantly (but > > > with all things considered, not in half). > > > > What mechanism will they use to detect the failure then? > > SONET framing is still used. What is not used is a SONET protect > path. SONET is involved in the detection, but plays no role in the > recovery. It seems a few providers did buildouts in recent years > costing lots of money, and used SONET protect paths while there was > excess capacity. Not the most efficient, but it works great. Then as > the capacity filled but revenue had not yet met the demands of incured > debt, decided that they don't want the increased debt of a further > buildout and are seeking a more cost effective way to meet their SLAs. > > Curtis > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 10:05:32 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LMP & neighbor discovery Date: Tue, 7 May 2002 13:02:13 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C915C893@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: LMP & neighbor discovery Thread-Index: AcH14K6krqi3Q8VPSHefAkGm3Ly7CAABuctw From: "Martin Dubuc" To: "Michiel van Everdingen" , We don't need any update to the LMP draft to address automatic = discovery. It is possible to implement automatic discovery with the = current draft. I would also like to warn CCAMP that the TTP and CTP concepts used in = ITU-T specs are very complex and I do not see a reason to change any = IETF documents to comply with this terminology/framework. Martin -----Original Message----- From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] Sent: Tuesday, May 07, 2002 11:42 AM To: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Hello all, Please find below two proposed updates of the LMP draft. These updates are based on the thoughts expressed in emails http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html Your comments are appreciated ! Thanks, Michiel 1. Insert an additional section on "Automatic neighbor discovery" = =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=3D=3D=3D=3D=3D=3D=3D=3D In this section, an optional LMP procedure is described to automatically detect the identification of the other end of the data link. Basically, automatic neighbor discovery is implemented by reading the incoming 'access point identifier' [ITU-T G.707]. A Sub-Network Point (TTP or CTP) that implements the automatic neighbor discovery procedure MUST send its identification in the access point identifier. The identification SHOULD be formatted into 16 bytes as follows ([OIF 2000.159.01]): +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |CRC|Typ|Dis| Node Identifier | Port Identifier | +---+---+---+-------------------------------+-------------------+ Figure 1: format of the access point identifier to enable automatic neighbor discovery The format as specified in figure 1 is in line with the specification in [ITU-T G707]. This SDH standard places the most stringent constraints on the contents of the access point identifiers. All entries in the access point identifier, except for the CRC field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. CRC The CRC-7 code of the previous frame as specified in G.707. Typ The "type indicator" informs the receiver of the sender's role. values are: "T": Trail Termination Point "C": Connection Termination Point Dis The "distinguishing identifier" avoids the proposed format to be confused with some other optional format, e.g. the format specified in G.831, Appendix I. value: "@" Node Identifier The "node identifier" is the IPv4 address that identifies the sending Node_Id. The IPv4 address is encoded in 8 hex characters. Port Identifier The "Port Identifier" identifies the sender's Interface_Id in hex format. This gives port numbers 0-FFFFF (1,048,575) which should be enough for all types of Network Elements. As an example, a node with IP address 192.168.2.23 would sent out the following access point identifier (excluding the CRC) from a TTP with local interface id 421: T@C0A802170001A5 A sending TTP that implements the automatic neighbor discovery scheme will continuously send out its own identification. This is according to ITU-T G.831, "the access point identifier should not change while the access point remains in existence". A sending CTP that implements the automatic neighbor discovery scheme MUST send its identification as long as it has not received a linkSummary message indicating that the associated receiver has discovered this sending CTP. The CTP MAY send its identification continuously, until it is discovered. The CTP MAY also send its identification in intervals, until it is discovered. Example: figure 2 shows 4 network elements (NEs) and a single data link between these NEs. Two NEs terminate the data link on interfaces marked with 'T' (TTP). Two other NEs are transparent to the data link on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are transparent optical cross connects; the data link is STM-N/OC-N. Note that neighbor discovery is defined per datalink, so the actual number of datalinks per NE is not relevant. +------+ +------+ +------+ +------+ | T-|--->--|-C C-|--->--|-C C-|--->--|-T | | | A | | B | | C | | | | | | | | | | | NE-1 | | NE-2 | | NE-3 | | NE-4 | +------+ +------+ +------+ +------+ Figure 2: automatic discovery example - 1 NE-2 should, when it wants to discover data link B, connect a test-set that sends an access point identifier to identify the sending connection point C in NE-2. This test-signal should be send long enough for NE-3 to detect and read the test-signal. NE-3 will continuously scan all its not discovered input ports for a discovery signal. At some point, NE-3 will detect the test-signal on data link B. See figure 3. +------+ +------+ +------+ +------+ | T-|--->--|-C C-|--->--|-C C-|--->--|-T | | | A | / | B | \ | C | | | | | T | | T | | | | NE-1 | | NE-2 | | NE-3 | | NE-4 | +------+ +------+ +------+ +------+ Figure 3: automatic discovery example - 2 When NE-3 has read the access point identifier in the test signal, data link B is discovered. Subsequent link property correlation can then be invoked. Discovery of data link A is similar, except that the access point identifier is continuously sent. Discovery of data link C is also similar, except that the access point identifier is continuously monitored. In other words, there is no need for a sending respectively monitoring 'test-set' in NE-1 and NE-4. Data link type Access point identifier to be used -------------- ---------------------------------- STM-N, OC-N J0 STS-1/3/.../VC-3/4/... J1 VT-1.5/VC-11/12 J2 A Sub-Network Point (TTP or CTP) MAY also use an alternative format for the access point identifier, e.g. the one specified in G.831, Appendix I. In this case, discovery of the address of the sending access point will need involvement of a 'name server'. Using an alternative format is, for example, needed in case the address of the access point can not be encoded in the limited length of the access point identifier, e.g. because IPv6 is used in the control plane. 2. Add Additional text to section 4, "Link Property Correlation" = =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=3D=3D=3D=3D=3D=3D=3D Note that the verify procedure is only applicable for CTP-->--CTP and CTP-->--TTP dataLinks. The verify procedure is not applicable for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send out their identification; the receiver can therefore at any time verify the connectivity of the dataLink. --=20 +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 08:43:38 -0700 Message-ID: <3CD7F5B1.898D0EBE@lucent.com> Date: Tue, 07 May 2002 17:41:37 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, Please find below two proposed updates of the LMP draft. These updates are based on the thoughts expressed in emails http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html Your comments are appreciated ! Thanks, Michiel 1. Insert an additional section on "Automatic neighbor discovery" ============================================================== In this section, an optional LMP procedure is described to automatically detect the identification of the other end of the data link. Basically, automatic neighbor discovery is implemented by reading the incoming 'access point identifier' [ITU-T G.707]. A Sub-Network Point (TTP or CTP) that implements the automatic neighbor discovery procedure MUST send its identification in the access point identifier. The identification SHOULD be formatted into 16 bytes as follows ([OIF 2000.159.01]): +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |CRC|Typ|Dis| Node Identifier | Port Identifier | +---+---+---+-------------------------------+-------------------+ Figure 1: format of the access point identifier to enable automatic neighbor discovery The format as specified in figure 1 is in line with the specification in [ITU-T G707]. This SDH standard places the most stringent constraints on the contents of the access point identifiers. All entries in the access point identifier, except for the CRC field, are printable 7 bit encoded ASCII characters [ITU-T T.50]. CRC The CRC-7 code of the previous frame as specified in G.707. Typ The "type indicator" informs the receiver of the sender's role. values are: "T": Trail Termination Point "C": Connection Termination Point Dis The "distinguishing identifier" avoids the proposed format to be confused with some other optional format, e.g. the format specified in G.831, Appendix I. value: "@" Node Identifier The "node identifier" is the IPv4 address that identifies the sending Node_Id. The IPv4 address is encoded in 8 hex characters. Port Identifier The "Port Identifier" identifies the sender's Interface_Id in hex format. This gives port numbers 0-FFFFF (1,048,575) which should be enough for all types of Network Elements. As an example, a node with IP address 192.168.2.23 would sent out the following access point identifier (excluding the CRC) from a TTP with local interface id 421: T@C0A802170001A5 A sending TTP that implements the automatic neighbor discovery scheme will continuously send out its own identification. This is according to ITU-T G.831, "the access point identifier should not change while the access point remains in existence". A sending CTP that implements the automatic neighbor discovery scheme MUST send its identification as long as it has not received a linkSummary message indicating that the associated receiver has discovered this sending CTP. The CTP MAY send its identification continuously, until it is discovered. The CTP MAY also send its identification in intervals, until it is discovered. Example: figure 2 shows 4 network elements (NEs) and a single data link between these NEs. Two NEs terminate the data link on interfaces marked with 'T' (TTP). Two other NEs are transparent to the data link on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are transparent optical cross connects; the data link is STM-N/OC-N. Note that neighbor discovery is defined per datalink, so the actual number of datalinks per NE is not relevant. +------+ +------+ +------+ +------+ | T-|--->--|-C C-|--->--|-C C-|--->--|-T | | | A | | B | | C | | | | | | | | | | | NE-1 | | NE-2 | | NE-3 | | NE-4 | +------+ +------+ +------+ +------+ Figure 2: automatic discovery example - 1 NE-2 should, when it wants to discover data link B, connect a test-set that sends an access point identifier to identify the sending connection point C in NE-2. This test-signal should be send long enough for NE-3 to detect and read the test-signal. NE-3 will continuously scan all its not discovered input ports for a discovery signal. At some point, NE-3 will detect the test-signal on data link B. See figure 3. +------+ +------+ +------+ +------+ | T-|--->--|-C C-|--->--|-C C-|--->--|-T | | | A | / | B | \ | C | | | | | T | | T | | | | NE-1 | | NE-2 | | NE-3 | | NE-4 | +------+ +------+ +------+ +------+ Figure 3: automatic discovery example - 2 When NE-3 has read the access point identifier in the test signal, data link B is discovered. Subsequent link property correlation can then be invoked. Discovery of data link A is similar, except that the access point identifier is continuously sent. Discovery of data link C is also similar, except that the access point identifier is continuously monitored. In other words, there is no need for a sending respectively monitoring 'test-set' in NE-1 and NE-4. Data link type Access point identifier to be used -------------- ---------------------------------- STM-N, OC-N J0 STS-1/3/.../VC-3/4/... J1 VT-1.5/VC-11/12 J2 A Sub-Network Point (TTP or CTP) MAY also use an alternative format for the access point identifier, e.g. the one specified in G.831, Appendix I. In this case, discovery of the address of the sending access point will need involvement of a 'name server'. Using an alternative format is, for example, needed in case the address of the access point can not be encoded in the limited length of the access point identifier, e.g. because IPv6 is used in the control plane. 2. Add Additional text to section 4, "Link Property Correlation" ============================================================= Note that the verify procedure is only applicable for CTP-->--CTP and CTP-->--TTP dataLinks. The verify procedure is not applicable for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send out their identification; the receiver can therefore at any time verify the connectivity of the dataLink. -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 08:14:07 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: draft submitted - "Optical Path Protection Signalling Performance Extension to RSVP" Date: Tue, 7 May 2002 11:11:13 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C9164DF4@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: draft submitted - "Optical Path Protection Signalling Performance Extension to RSVP" Thread-Index: AcH12aLDNeeF/8lSSL2SNyiKgkLueg== From: "George Young" To: Cc: "Kireeti Kompella" , "Ron Bonica" Ccamp mailing list, I've submitted an internet draft related to optical restoration control = performance. Here's the abstract: "With this extension to the RSVP-TE protocol, an optical path can be = initiated with a requested maximum path restoration notification time, = and signalling nodes which make up the path can determine compliance = with this requirement and then establish the path." and here's the pointer: http://www.ietf.org/internet-drafts/draft-young-optical-prot-ext-rsvp-00.= txt Comments appreciated. Regards, George R. Young Meriton Networks Inc. 3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9628 email: george.young@meriton.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 07:19:02 -0700 Message-ID: <39469E08BD83D411A3D900204840EC55763178@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject: RE: How many can administrative groups assigned? Date: Tue, 7 May 2002 10:16:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Kim, -> If so, how many can administrative groups assigned? 32 or 2^32 ? 32. A link can me member of multiple admin groups. -- Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 07 May 2002 04:15:34 -0700 Message-ID: <3CD7ADFB.5B6DA85D@alcatel.be> Date: Tue, 07 May 2002 12:35:39 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: Vinay Vernekar CC: ccamp@ops.ietf.org Subject: Re: Doubt in applying the transforms in SONET/SDH traffic parameters. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Read this sentence as "Each transform application is optional=20 and must be ignored if zero, except MT that cannot be zero and=20 is ignored if equal to one" during the traffic parameter=20 processing at each hop.=20 This means 1) when zero ignore the transform application 2)=20 when non zero optional transform application except for the MT field (at least equal to one) 1) when one ignore the=20 transform application 2) when > 1 optional transform appli- cation. In a sense 0 or 1 (for the MT) doesn't change the number of Signal Type field occurrence. In the example you gave here below, if such hypothetical behavior occurs it is up to the upstream node policy to decide whether or not the label (and thus the corresponding bandwidth) allocation is acceptable for this ongoing request. Hope this somehow clarifies, Best regards, - dimitri. > Vinay Vernekar wrote: >=20 > Hi, > The draft "draft-ietf-ccamp-gmpls-sonet-sdh-04.txt" specifies as > follows for the traffic parameters - >=20 > "Each transform is optional and must be ignored if zero, except MT > that cannot be zero and is ignored if equal to one" >=20 > Is'nt it that the transform should be "mandatory" applied and not > optionally as mentioned above. Consider for example, a request is > received from an upstream peer with Signal Type as 6 indicating STS-3c > SPE and NVC as 4 indicating a final signal which comprises of 4 > virtually concatenated STS-3c SPEs. This would mean a bandwidth of > (155.5*4)Mbps requested by the upstream. Now if the LSR decides not to > apply virtual concatenation, as inferred from the draft and gives back > a mapping corresponding to STS-3c SPE, it would result in net > bandwidth allocation of 155.5 Mbps only. Instead the LSR should reject > the LSP request. > The same argument holds good for other traffic parameters also. > Kindly reqly back if I am missing something.... > Thanks in advance. >=20 > Regards > Vinay > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Yesterday is history. Tomorrow is mystery. > Today is a gift. That=92s why it=92s called the Present!! > *************************************************************************= **** > Vinay H. Vernekar > Sr. Software Engineer - Global R&D Solutions > Wipro Technologies > No.26, Hosur Main Road, Bommanahalli, > Bangalore-560 068, India. > Tel: 91-80-5722293/5722296 Extn. 4019 > Fax: 91-80-5722696 > Email: vinay.vernekar@wipro.com > The World's First SEI CMM Level 5 Software Services Company > *************************************************************************= **** >=20 > Name: Wipro=5FDisclaimer.txt > Wipro=5FDisclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit --=20 Papadimitriou Dimitri=20 E-mail : dimitri.papadimitriou@alcatel.be=20 Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1=20 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 21:02:30 -0700 Message-id: <002b01c1f565$b997f450$2a8cd5a5@jhkim> MIME-version: 1.0 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Date: Tue, 07 May 2002 10:22:54 +0900 From: =?ks_c_5601-1987?B?sejB+Mf8?= Subject: How many can administrative groups assigned? To: mpls@UU.NET, CCAMP , te-wg@ops.ietf.org [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi. My name is Kim. In draft-katz-yeung-ospf-traffic-06.txt , "Traffic Engineering Extensions to OSPF", sub-TLV is defined for Administrative group referred to Resource color/class. 4 octets are assigned for this sub-TLV. This draft says, "The Resource Class/Color sub-TLV specifies administrative group membership for this link, in terms of a bit mask." If so, how many can administrative groups assigned? 32 or 2^32 ? May I help you? Regards All. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 21:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200205070048.UAA47786@workhorse.fictitious.org> To: Sudheer Dharanikota cc: Shahram Davari , "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration Date: Mon, 06 May 2002 20:48:59 -0400 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message <3CD6F53E.52779883@nayna.com>, Sudheer Dharanikota writes: > > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > links under their MPLS network cutting some costs significantly (but > > > with all things considered, not in half). > > > > What mechanism will they use to detect the failure then? > > With most of the *recent* L2/L1 technologies, failure dection is not the > only problem. > Without APS-like mechanisms (sub-second) failure reporting is also a major > problem. > In my opinion, for the sake of the underlying technologies which does not > have > APS-like reporting mechanisms, we need to optimize our signaling protocols > and propose sensible control plane topologies. > > Regards, > > sudheer SONET detection is used. SONET APS protection is not. FRR yields <50msec restroation is needed, and standby LSPs yields a few seconds at worst (consistently sub second is certainly possible with standby, but not yet acheived by today's implementations afaik). Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 20:59:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200205070045.UAA47770@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@fictitious.org'" , Sudheer Dharanikota , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration Date: Mon, 06 May 2002 20:45:41 -0400 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca > > > > I do know of providers who want to eliminate the APS on the sonet > > links under their MPLS network cutting some costs significantly (but > > with all things considered, not in half). > > What mechanism will they use to detect the failure then? SONET framing is still used. What is not used is a SONET protect path. SONET is involved in the detection, but plays no role in the recovery. It seems a few providers did buildouts in recent years costing lots of money, and used SONET protect paths while there was excess capacity. Not the most efficient, but it works great. Then as the capacity filled but revenue had not yet met the demands of incured debt, decided that they don't want the increased debt of a further buildout and are seeking a more cost effective way to meet their SLAs. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 20:59:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be Subject: Connection Deletion in GMPLS Date: Mon, 06 May 2002 17:36:34 -0700 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi All, In GMPLS, the graceful connection deletion is done by first sending the Path message with admin status as down (D & R bits on) and then the egress node can send the PathErr message with cause 'Path State Removed'. What is the requirement of sending the complete PATH message ? This message could (possibly a new message type) have been kept very simple with session and admin status objects. There are many parameters in path message which are not required for connection deletion viz TIME_VALUE, ERO, RSVP_HOP, PROTECTION, LABEL REQUEST, SESSION ATTRIBUTES, POLICY DATA etc. If one calculates the size of these parameters for a connection it can run in to more than 50 bytes. This means the control channel bandwidth is being wasted for each and every connection at the time of graceful connection deletion by transmitting such large messages. Is there any reason for not keeping different (possibly new or could have made use of Notify message) message type for connection deletion ? Furthermore, as the complete PATH message need to go through all the nodes in the path, more processing time will be required to parse/process the large message like PATH as compared to some small message like Notify etc. This type of processing overhead will be there for each and every call/LSP in GMPLS. Please help me in understanding this issue. Regards, manoj. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 20:44:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200205062031.QAA47087@workhorse.fictitious.org> To: Sudheer Dharanikota cc: Gary Tam , Ajay Simha , curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration Date: Mon, 06 May 2002 16:31:11 -0400 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > Transport networks are *built* to provide 50 msec recovery > times (e.g., rings, span, 1+1 etc). Hence a failures are scoped to be > within a domain (typically a ring or a span or in the worst case > end-to-end[1+1 case]). Excluding failure detection time in this > 50 msec (taking from SONET knowledge), failure reporting > and recovery should take 50 msec. Obviously this cannot > be done with OSS intervention. One can use SONET's > inband signaling mechanisms for failure reporting or use > *directed notification* mechanisms such as the ones proposed > for signaling protocols. Note that if we assume a ring topology then > the messages are only one hop away (with the assumption that > only the DCS are the intelligent devices). So your worry of 5-10 > hop path is not valid in my opinion. > > Regards, > > sudheer The discussion was about MPLS but an underlying assumption seemded to enter into the thread with that last email that either APS was running under MPLS or L2 was the application and APS was running over MPLS provided over multiple end to end L2 tunnels. I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS backbone. I do know of providers who want to eliminate the APS on the sonet links under their MPLS network cutting some costs significantly (but with all things considered, not in half). MPLS restoration needs to work quite well to do this and still meet SLAs and carrying L2 service is even more demanding. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 16:14:34 -0700 Message-ID: <4490F7068AC0D111A7120008C72878EC0EB6E27F@nj7460exch003u.ho.lucent.com> From: "Nagarajan, Ramesh (Ramesh)" To: "'Sudheer Dharanikota'" Cc: Shahram Davari , "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 19:13:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sudheer, I am taking the liberty of attaching e-mail (on MPLS WG) from Neil = Harrison of BT on the proposal. He has some excellent comments/perspective = (among others) on the 2x BW issue (see his point 1). I share these viewpoints. = Failure detection/reporting avoidance is only one of the advantages of = the proposal (and highlighted in the context of the discussion on this = thread). There are many other advantages that we can discuss at length. ramesh. > > From: Harrison,N,Neil,IKO1 R > > Sent: 24 April 2002 13:20 > > To: IETF MPLS WG (E-mail) > > Subject: comments on nagarajan-ccamp-mpls-packet-protection-00.txt > >=20 > > I noted George S asked for comments on > > nagarajan-ccamp-mpls-packet-protection-00.txt to be taken=20 > on the list in his > > notes of the MPLS WG mtg.....so here are some 1st pass comments: > >=20 > > 1 I noted a criticism in the mtg notes that it uses=20 > 2x the BW of one > > LSP....well yes it is 1+1 so I'd say that's obvious. =20 > However, I think we > > have to place any such criticism of BW efficiency in=20 > context. For example, > > if I compare it with LDP as a server layer to (say) rfc2547=20 > VPNs, then > > because there is no relationship between a pkt's up-state=20 > QoS forwarding > > treatment and a pkt's survivability requirements (vis-=E0-vis same = or > > different DS-coded pkts of *any* VPN), operators are forced=20 > to over-engineer > > such networks and *hope* (because there is no assurance)=20 > that traffic > > survives under failures....a factor of 2x over-engineering=20 > on some DS > > classes is not uncommon. > >=20 > > Hence, the point I want to make here is that using BW wisely to > > reduce/remove a complexity/problem is one thing (which I=20 > support), but > > asking an operator to throw BW at a problem that should not=20 > really exist > > (because the application/problem in question has only been = partially > > defined, eg just the connectivity bit of VPNs) is something=20 > else. So any > > criticism of BW efficiency only makes sense against the=20 > context of the > > application/problem it is addressing IMO. > >=20 > > 2 I noted in section 6.2 you address the practical=20 > issue of carrying > > the sequence number (if implemented in such a way), and=20 > suggest that it sits > > directly below the shim header (1st 4 octets of payload). =20 > This is possible. > > 2 things spring to mind here: > >=20 > > - IMO you really need some way to be sure you have correct = A-B > > connectivity....and this includes defects where perhaps=20 > another LSP, LSP X > > say, gets merged unintentionally into the LSP Y between=20 > A-B. In this case > > you would get some unexpected results looking for a=20 > sequence number in such > > mismerged pkts. I would therefore recommend you run a=20 > periodic data-plane > > LSP CV OAM flow on each of the LSPs to verify correct=20 > connectivity, since > > these contain unique LSP source identifiers and will detect=20 > all defects, not > > just simple breaks (and if following Y.1711, it will also=20 > invoke the correct > > consequent actions on failure). > >=20 > > - You will need to configure the LSP sink points to=20 > expect LSPs > > containing sequence numbers. This can be done manually of=20 > course, but you > > may want to consider some auto signalling config...and I=20 > later noted that > > you have considered this aspect in section 6.4 wrt RSVP=20 > say. A further way > > to achieve this signalling function could be by the use of=20 > special OAM > > pkts....and its something being considered by those who are=20 > working on MPLS > > OAM in Y.1711 for automatic CV activation/deactivation. > >=20 > > 3 Given that the scheme you are proposing seems to=20 > fit where one has a > > critical LSP connectivity application (like a=20 > control/management-channel > > say), then I think you ought to be running some solid OAM fault > > detection/handling function on it in any case....I gave one=20 > example above > > wrt mismerging and seeing arbitrary sequence number=20 > effects. Moreover, I > > noted later you gave an algorithm for processing the sequence = number > > implementation case at the egress that is associated with a=20 > sliding window. > > I would suggest that this needs coupling with defect=20 > detection mechanisms in > > order to make the correct processing decisions.....one=20 > obvious cut-off point > > is when you would consider one of the LSPs to have become=20 > 'unavailable' > > (this is also defined in Y.1711). > >=20 > > 4 Final comment....simple ideas are often the best,=20 > and this idea is > > certainly simple in principle. I think it could find=20 > excellent uses for > > critical applications. > >=20 > > regards, Neil > > >=20 ------------------------------------------------------------------------= ---- -------------------------------------------------- Room 3M-335, Bell labs Tel: 732-949-2761 101 Crawfords Corner Road Fax: 732-834-5906 Holmdel, NJ 07733. e-mail: rameshn@lucent.com. ------------------------------------------------------------------------= ---- --------------------------------------------------- > ---------- > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > Sent: Monday, May 06, 2002 6:41 PM > To: Nagarajan, Ramesh (Ramesh) > Cc: Shahram Davari; 'curtis@fictitious.org'; Gary Tam; Ajay Simha; = Ron > Bonica; Brijesh Kumar; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration >=20 > Hi Ramesh: >=20 >=20 >=20 > "Nagarajan, Ramesh (Ramesh)" wrote: >=20 > > Sudheer, Shahram, > > > > I agree. *Fast* failure detection and reporting are challenging = issues > even > > when we consider physical layer failures (fiber cut etc.,) only. If = you > > throw in soft failures of many kinds it becomes even more = challenging. > > This was one of the motivations, among many others, in developing a > > restoration scheme/proposal (link below for convenience) which = provides > > broad coverage for many failures without requiring failure = detection and > > reporting. This will work across the recent L2/L1 technologies that = you > > refer to which lack either proper failure detection and/or = reporting. > > > > ramesh. > > > > > = http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-pr= ot > ec > > tion-00.txt > > >=20 > Although I agree that 1+1 mechanisms may solve (to be precise avoid) > such problems, they are very resource intensive. Also most of the > data applications do not need the recovery times that you can support > by 1+1. In my opinion, the challenge is to support less resource = intensive > but reasinably faster restoration times for data applications by = reusing > the under-lying technologies. >=20 > Regards, >=20 > sudheer >=20 > > > > > = ------------------------------------------------------------------------= -- > -- > > -------------------------------------------------- > > Room 3M-335, Bell labs > > Tel: 732-949-2761 > > 101 Crawfords Corner Road > > Fax: 732-834-5906 > > Holmdel, NJ 07733. > > e-mail: rameshn@lucent.com. > > > = ------------------------------------------------------------------------= -- > -- > > --------------------------------------------------- > > > > > ---------- > > > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > > > Sent: Monday, May 06, 2002 5:27 PM > > > To: Shahram Davari > > > Cc: 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; > Brijesh > > > Kumar; mpls@UU.NET; CCAMP WG > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > Curtis, > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar = [mailto:curtis@workhorse.fictitious.org] > > > > > Sent: Monday, May 06, 2002 4:31 PM > > > > > To: Sudheer Dharanikota > > > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; > Brijesh > > > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota > writes: > > > > > > > > > > > > Transport networks are *built* to provide 50 msec recovery > > > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > > > > scoped to be > > > > > > within a domain (typically a ring or a span or in the worst = case > > > > > > end-to-end[1+1 case]). Excluding failure detection time in = this > > > > > > 50 msec (taking from SONET knowledge), failure reporting > > > > > > and recovery should take 50 msec. Obviously this cannot > > > > > > be done with OSS intervention. One can use SONET's > > > > > > inband signaling mechanisms for failure reporting or use > > > > > > *directed notification* mechanisms such as the ones = proposed > > > > > > for signaling protocols. Note that if we assume a ring = topology > then > > > > > > the messages are only one hop away (with the assumption = that > > > > > > only the DCS are the intelligent devices). So your worry of = 5-10 > > > > > > hop path is not valid in my opinion. > > > > > > > > > > > > Regards, > > > > > > > > > > > > sudheer > > > > > > > > > > > > > > > The discussion was about MPLS but an underlying assumption = seemded > to > > > > > enter into the thread with that last email that either APS = was > running > > > > > under MPLS or L2 was the application and APS was running over = MPLS > > > > > provided over multiple end to end L2 tunnels. > > > > > > > > > > I don't know of anyone doing SONET APS over the L2 tunnels of = an > MPLS > > > > > backbone. > > > > > > > > > > I do know of providers who want to eliminate the APS on the = sonet > > > > > links under their MPLS network cutting some costs = significantly > (but > > > > > with all things considered, not in half). > > > > > > > > What mechanism will they use to detect the failure then? > > > > > > With most of the *recent* L2/L1 technologies, failure dection is = not > the > > > only problem. > > > Without APS-like mechanisms (sub-second) failure reporting is = also a > major > > > problem. > > > In my opinion, for the sake of the underlying technologies which = does > not > > > have > > > APS-like reporting mechanisms, we need to optimize our signaling > protocols > > > and propose sensible control plane topologies. > > > > > > Regards, > > > > > > sudheer > > > > > > > > > > > > > > > -Shahram > > > > > > > > MPLS restoration needs to > > > > > work quite well to do this and still meet SLAs and carrying = L2 > service > > > > > is even more demanding. > > > > > > > > > > Curtis > > > > > > > > > > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 15:48:55 -0700 Message-ID: <3CD706A6.BF752E1C@nayna.com> Date: Mon, 06 May 2002 15:41:42 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: "Nagarajan, Ramesh (Ramesh)" CC: Shahram Davari , "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ramesh: "Nagarajan, Ramesh (Ramesh)" wrote: > Sudheer, Shahram, > > I agree. *Fast* failure detection and reporting are challenging issues even > when we consider physical layer failures (fiber cut etc.,) only. If you > throw in soft failures of many kinds it becomes even more challenging. > This was one of the motivations, among many others, in developing a > restoration scheme/proposal (link below for convenience) which provides > broad coverage for many failures without requiring failure detection and > reporting. This will work across the recent L2/L1 technologies that you > refer to which lack either proper failure detection and/or reporting. > > ramesh. > > http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec > tion-00.txt > Although I agree that 1+1 mechanisms may solve (to be precise avoid) such problems, they are very resource intensive. Also most of the data applications do not need the recovery times that you can support by 1+1. In my opinion, the challenge is to support less resource intensive but reasinably faster restoration times for data applications by reusing the under-lying technologies. Regards, sudheer > > ---------------------------------------------------------------------------- > -------------------------------------------------- > Room 3M-335, Bell labs > Tel: 732-949-2761 > 101 Crawfords Corner Road > Fax: 732-834-5906 > Holmdel, NJ 07733. > e-mail: rameshn@lucent.com. > ---------------------------------------------------------------------------- > --------------------------------------------------- > > > ---------- > > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > > Sent: Monday, May 06, 2002 5:27 PM > > To: Shahram Davari > > Cc: 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh > > Kumar; mpls@UU.NET; CCAMP WG > > Subject: Re: Static LSP Configuration > > > > > > > > Shahram Davari wrote: > > > > > Curtis, > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > > > Sent: Monday, May 06, 2002 4:31 PM > > > > To: Sudheer Dharanikota > > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > > > > > > > Transport networks are *built* to provide 50 msec recovery > > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > > > scoped to be > > > > > within a domain (typically a ring or a span or in the worst case > > > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > > > 50 msec (taking from SONET knowledge), failure reporting > > > > > and recovery should take 50 msec. Obviously this cannot > > > > > be done with OSS intervention. One can use SONET's > > > > > inband signaling mechanisms for failure reporting or use > > > > > *directed notification* mechanisms such as the ones proposed > > > > > for signaling protocols. Note that if we assume a ring topology then > > > > > the messages are only one hop away (with the assumption that > > > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > > > hop path is not valid in my opinion. > > > > > > > > > > Regards, > > > > > > > > > > sudheer > > > > > > > > > > > > The discussion was about MPLS but an underlying assumption seemded to > > > > enter into the thread with that last email that either APS was running > > > > under MPLS or L2 was the application and APS was running over MPLS > > > > provided over multiple end to end L2 tunnels. > > > > > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > > > > backbone. > > > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > > links under their MPLS network cutting some costs significantly (but > > > > with all things considered, not in half). > > > > > > What mechanism will they use to detect the failure then? > > > > With most of the *recent* L2/L1 technologies, failure dection is not the > > only problem. > > Without APS-like mechanisms (sub-second) failure reporting is also a major > > problem. > > In my opinion, for the sake of the underlying technologies which does not > > have > > APS-like reporting mechanisms, we need to optimize our signaling protocols > > and propose sensible control plane topologies. > > > > Regards, > > > > sudheer > > > > > > > > > > > -Shahram > > > > > > MPLS restoration needs to > > > > work quite well to do this and still meet SLAs and carrying L2 service > > > > is even more demanding. > > > > > > > > Curtis > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 15:06:02 -0700 Message-ID: <4490F7068AC0D111A7120008C72878EC0EB6E27D@nj7460exch003u.ho.lucent.com> From: "Nagarajan, Ramesh (Ramesh)" To: Shahram Davari , "'Sudheer Dharanikota'" Cc: "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 18:04:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sudheer, Shahram, I agree. *Fast* failure detection and reporting are challenging issues even when we consider physical layer failures (fiber cut etc.,) only. If you throw in soft failures of many kinds it becomes even more challenging. This was one of the motivations, among many others, in developing a restoration scheme/proposal (link below for convenience) which provides broad coverage for many failures without requiring failure detection and reporting. This will work across the recent L2/L1 technologies that you refer to which lack either proper failure detection and/or reporting. ramesh. http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec tion-00.txt ---------------------------------------------------------------------------- -------------------------------------------------- Room 3M-335, Bell labs Tel: 732-949-2761 101 Crawfords Corner Road Fax: 732-834-5906 Holmdel, NJ 07733. e-mail: rameshn@lucent.com. ---------------------------------------------------------------------------- --------------------------------------------------- > ---------- > From: Sudheer Dharanikota[SMTP:sudheer@nayna.com] > Sent: Monday, May 06, 2002 5:27 PM > To: Shahram Davari > Cc: 'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh > Kumar; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > > > Shahram Davari wrote: > > > Curtis, > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > > Sent: Monday, May 06, 2002 4:31 PM > > > To: Sudheer Dharanikota > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > > Subject: Re: Static LSP Configuration > > > > > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > > > > > Transport networks are *built* to provide 50 msec recovery > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > > scoped to be > > > > within a domain (typically a ring or a span or in the worst case > > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > > 50 msec (taking from SONET knowledge), failure reporting > > > > and recovery should take 50 msec. Obviously this cannot > > > > be done with OSS intervention. One can use SONET's > > > > inband signaling mechanisms for failure reporting or use > > > > *directed notification* mechanisms such as the ones proposed > > > > for signaling protocols. Note that if we assume a ring topology then > > > > the messages are only one hop away (with the assumption that > > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > > hop path is not valid in my opinion. > > > > > > > > Regards, > > > > > > > > sudheer > > > > > > > > > The discussion was about MPLS but an underlying assumption seemded to > > > enter into the thread with that last email that either APS was running > > > under MPLS or L2 was the application and APS was running over MPLS > > > provided over multiple end to end L2 tunnels. > > > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > > > backbone. > > > > > > I do know of providers who want to eliminate the APS on the sonet > > > links under their MPLS network cutting some costs significantly (but > > > with all things considered, not in half). > > > > What mechanism will they use to detect the failure then? > > With most of the *recent* L2/L1 technologies, failure dection is not the > only problem. > Without APS-like mechanisms (sub-second) failure reporting is also a major > problem. > In my opinion, for the sake of the underlying technologies which does not > have > APS-like reporting mechanisms, we need to optimize our signaling protocols > and propose sensible control plane topologies. > > Regards, > > sudheer > > > > > > > -Shahram > > > > MPLS restoration needs to > > > work quite well to do this and still meet SLAs and carrying L2 service > > > is even more demanding. > > > > > > Curtis > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 14:35:56 -0700 Message-ID: <3CD6F53E.52779883@nayna.com> Date: Mon, 06 May 2002 14:27:26 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Shahram Davari CC: "'curtis@fictitious.org'" , Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shahram Davari wrote: > Curtis, > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Sent: Monday, May 06, 2002 4:31 PM > > To: Sudheer Dharanikota > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > > Subject: Re: Static LSP Configuration > > > > > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > > > Transport networks are *built* to provide 50 msec recovery > > > times (e.g., rings, span, 1+1 etc). Hence a failures are > > scoped to be > > > within a domain (typically a ring or a span or in the worst case > > > end-to-end[1+1 case]). Excluding failure detection time in this > > > 50 msec (taking from SONET knowledge), failure reporting > > > and recovery should take 50 msec. Obviously this cannot > > > be done with OSS intervention. One can use SONET's > > > inband signaling mechanisms for failure reporting or use > > > *directed notification* mechanisms such as the ones proposed > > > for signaling protocols. Note that if we assume a ring topology then > > > the messages are only one hop away (with the assumption that > > > only the DCS are the intelligent devices). So your worry of 5-10 > > > hop path is not valid in my opinion. > > > > > > Regards, > > > > > > sudheer > > > > > > The discussion was about MPLS but an underlying assumption seemded to > > enter into the thread with that last email that either APS was running > > under MPLS or L2 was the application and APS was running over MPLS > > provided over multiple end to end L2 tunnels. > > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > > backbone. > > > > I do know of providers who want to eliminate the APS on the sonet > > links under their MPLS network cutting some costs significantly (but > > with all things considered, not in half). > > What mechanism will they use to detect the failure then? With most of the *recent* L2/L1 technologies, failure dection is not the only problem. Without APS-like mechanisms (sub-second) failure reporting is also a major problem. In my opinion, for the sake of the underlying technologies which does not have APS-like reporting mechanisms, we need to optimize our signaling protocols and propose sensible control plane topologies. Regards, sudheer > > > -Shahram > > MPLS restoration needs to > > work quite well to do this and still meet SLAs and carrying L2 service > > is even more demanding. > > > > Curtis > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 13:58:11 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A795@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@fictitious.org'" , Sudheer Dharanikota Cc: Gary Tam , Ajay Simha , Ron Bonica , Brijesh Kumar , mpls@UU.NET, CCAMP WG Subject: RE: Static LSP Configuration Date: Mon, 6 May 2002 13:56:23 -0700 MIME-Version: 1.0 Content-Type: text/plain Curtis, > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, May 06, 2002 4:31 PM > To: Sudheer Dharanikota > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG > Subject: Re: Static LSP Configuration > > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes: > > > > Transport networks are *built* to provide 50 msec recovery > > times (e.g., rings, span, 1+1 etc). Hence a failures are > scoped to be > > within a domain (typically a ring or a span or in the worst case > > end-to-end[1+1 case]). Excluding failure detection time in this > > 50 msec (taking from SONET knowledge), failure reporting > > and recovery should take 50 msec. Obviously this cannot > > be done with OSS intervention. One can use SONET's > > inband signaling mechanisms for failure reporting or use > > *directed notification* mechanisms such as the ones proposed > > for signaling protocols. Note that if we assume a ring topology then > > the messages are only one hop away (with the assumption that > > only the DCS are the intelligent devices). So your worry of 5-10 > > hop path is not valid in my opinion. > > > > Regards, > > > > sudheer > > > The discussion was about MPLS but an underlying assumption seemded to > enter into the thread with that last email that either APS was running > under MPLS or L2 was the application and APS was running over MPLS > provided over multiple end to end L2 tunnels. > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS > backbone. > > I do know of providers who want to eliminate the APS on the sonet > links under their MPLS network cutting some costs significantly (but > with all things considered, not in half). What mechanism will they use to detect the failure then? -Shahram MPLS restoration needs to > work quite well to do this and still meet SLAs and carrying L2 service > is even more demanding. > > Curtis > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 11:07:38 -0700 Message-ID: <3CD6C43C.94BACCEE@nayna.com> Date: Mon, 06 May 2002 10:58:20 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Gary Tam CC: Ajay Simha , curtis@fictitious.org, Ron Bonica , Brijesh Kumar , "'Curtis Villamizar '" , mpls@UU.NET, CCAMP WG Subject: Re: Static LSP Configuration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Gary: Gary Tam wrote: > yes, you can rely on the Physical Optical driver to > monitor the incoming signal/power level, and/or > synchornization (using PLL/CDR). But without a fast > propagation mechanism, you cannot archieve sub 50ms > global protection. I do not see how you can do it with > RSVP or LDP over 5-10 hop path. > > --- Ajay Simha wrote: > > On Mon, 6 May 2002, Gary I thought the discussion was about data networks. This suddenly became transport network discusion :-) As you have noted, there are multiple phases in recovery here. Transport networks are *built* to provide 50 msec recovery times (e.g., rings, span, 1+1 etc). Hence a failures are scoped to be within a domain (typically a ring or a span or in the worst case end-to-end[1+1 case]). Excluding failure detection time in this 50 msec (taking from SONET knowledge), failure reporting and recovery should take 50 msec. Obviously this cannot be done with OSS intervention. One can use SONET's inband signaling mechanisms for failure reporting or use *directed notification* mechanisms such as the ones proposed for signaling protocols. Note that if we assume a ring topology then the messages are only one hop away (with the assumption that only the DCS are the intelligent devices). So your worry of 5-10 hop path is not valid in my opinion. Regards, sudheer > Tam wrote: > > > > GT>Hi Curtis, > > GT> > > GT>You have some good points. I agree with you that > > GT>dynamic signaling is good and essential. > > GT> > > GT>But for protection, you do not have to have > > dynamic > > GT>signaling protocol. You need 2 disjointed LSPs, > > and a > > GT>fast fault detection / propagation mechanism > > (could be > > GT>an OAM control flow or other means for the > > targeted > > GT>DA). In this case, when there is a link/fiber > > cut, the > > GT>failure can be detected at where the fault occurs > > and > > GT>be propagated to where the switch takes place. In > > GT>terms of global/segmented protection, the > > local-node > > GT>detects the failure instantly and propagates > > failure > > GT>condition to the targeted DA of the switch node. > > The > > GT>switch-node performs the switch-over activity as > > soon > > GT>as it gets the switch-over message. In the entire > > GT>proceess, there is no dynamic signaling here. > > Besides, > > GT>it will be too slow and costly to do protection > > with > > GT>RSVP-signaling - ie 50ms protection. Even if you > > scale > > > > Not true. > > GT>the RSVP/LDP Hello intervals to 5ms, there are > > lots of > > GT>issues such as link flapping, lots of hellos. > > etc. > > GT> > > > > You could use sonet alarms for detection. Any how > > would OAM control flow > > solve any lost pkts? > > > > -ajay > > GT>In the Access domain, ie 802.1Q, VLAN/SVLAN is > > widely > > GT>used for data forwarding and customer data > > separation. > > GT>There is no urgent need for an Ethernet network > > to > > GT>implement RSVP-TE or CR-LDP. So static > > LSP-Stitching > > GT>will be a cheap and inexpensive solution for L2 > > VPN. > > GT> > > GT>Gary > > GT> > > GT> > > GT>--- Curtis Villamizar > > GT> wrote: > > GT>> > > GT>> In message > > GT>> > > > GT><20020506135949.87793.qmail@web11208.mail.yahoo.com>, > > GT>> Gary Tam write > > GT>> s: > > GT>> > > > GT>> > In the core network ( between port 2 and 3), > > it > > GT>> can be > > GT>> > nested LSP trunking setup by CR-LDP/RSVP-TE. > > This > > GT>> will > > GT>> > not change anything in case of failure > > between 2 > > GT>> and 3 > > GT>> > with the obvious exception of port 2 and 3. > > GT>> > > > GT>> > The static LSP (1,2,3,4) will likely be > > GT>> > Martini-encapsulated Tunnel for some L2 > > VLAN/MPLS > > GT>> VCs > > GT>> > as well. The L2 FEC can be either MAC DA, > > VLAN, > > GT>> > Coustomer ID, and ATM VC, etc. > > GT>> > > > GT>> > Gary > > GT>> > > GT>> > > GT>> Gary, > > GT>> > > GT>> I didn't think I was going to have to answer my > > own > > GT>> retorical question > > GT>> "what happens with static LSPs if a link goes > > down". > > GT>> If any link > > GT>> fails you're sunk. You could in principle > > create a > > GT>> second static LSP > > GT>> (a static standby) but with no signaling there > > is no > > GT>> way to tell the > > GT>> ingress to use it. > > GT>> > > GT>> Even with a prmary and standby (regardless of > > GT>> whether the primary > > GT>> and/or standby are static or dynamic), > > occassionally > > GT>> multiple faults > > GT>> occur for which SRLGs do not cover the > > possibility > > GT>> and where it would > > GT>> be prohibitively expensive to do so. A > > examples > > GT>> examples from my > > GT>> experience are power outage in Manhattan during > > GT>> generator maintenance > > GT>> (famous for taking the FAA network down), > > Amtrak > > GT>> train wreck in NJ > > GT>> (famous for nearly taking out NYC due to > > damaged > > GT>> fiber on both sides > > GT>> of the track), hurricane brushing NC and VA > > causing > > GT>> damage and > > GT>> flooding (famous for taking out MAE-E > > connectivity > > GT>> to Europe during an > > GT>> IETF), extensive flooding in US midwest, > > earthquake > > GT>> in San Diego, > > GT>> Raritan River bridge failure in NJ, gas main > > leak in > > GT>> LA forcing CO to > > GT>> cut power, exploding rat in SF power transfer > > GT>> switch, and the list > > GT>> goes on and on. You can't write SRLGs to cover > > GT>> this. The only viable > > GT>> solution is to dynamically route. > > GT>> > > GT>> Some providers talk about using an > > explicit-path > > GT>> specified at the > > GT>> ingress with a dynamically routed backup > > (disjoint > > GT>> and either > > GT>> pre-signaled or just pre-computed, or > > dynamically > > GT>> rerouted after > > GT>> failure). This does not use static insegments > > and > > GT>> outsegments, it > > GT>> uses singaled LSPs with configured paths. Even > > talk > > GT>> of this approach > > GT>> (explicit primary path) is becoming more rare > > GT>> because when failure > > GT>> occurs and when optimal layout is most needed > > it > > GT>> often makes sense to > > GT>> allow primaries were not broken by the fault to > > pick > > GT>> alternate less > > GT>> congested paths. > > GT>> > > GT>> second retorical question - Why don't IP > > providers > > GT>> build their > > GT>> backbones out of static routes? I'm hope we > > don't > > GT>> get any > GT>> don't know why they don't do that IP static > > routes > > GT>> would seem like a > > GT>> really great idea> responses. > > GT>> > > GT>> Curtis > > GT> > > GT> > > > GT>______________________________________________________________________ > > GT>Games, Movies, Music & Sports! > > http://entertainment.yahoo.ca > > GT> > > > > -- > > > > ______________________________________________________________________ > Games, Movies, Music & Sports! http://entertainment.yahoo.ca Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 02:26:05 -0700 Cc: "ccamp@ops.ietf.org" Message-ID: <3CD64C01.C6457335@lucent.com> Date: Mon, 06 May 2002 11:25:21 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: "ccamp@ops.ietf.org" Subject: Re: Question on LMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, Based on the information put forward in this thread, I think some clarification is needed in the LMP draft. - Please make clear that "control channels" are established *over* a "control network". - Please make clear that some signaling messages are carried over "control channels" and that some signaling messages are carried directly over the "control network" (example of the latter: the RSVP-TE notify message). - Add some text on the relationship, configuration dependency between RSVP-TE hellos, LMP hellos and the "control network" IGP hellos. See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html. This probably causes the need to introduce + "signaling channels" + "signaling network" / "signaling plane" See for definitions of these terms: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html - Add some text to explain why there a (mandatory) need to distinguish between a failure of the RSVP-TE process and a failure of the LMP process. See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html - Chapter 1: "To enable communication between nodes for routing, signaling, and link management, control channels must be established between the node pair ..." Please add some explanation why the "control network" is not sufficient to enable communication. You could refer to http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html - Chapter 2: "... the control channel MUST terminate on the same two nodes that the TE link spans" Please add an explanation on exactly what is meant here. Compare e.g. LSP termination (in which an MPLS label is terminated/removed), TCP termination (in which the TCP header is terminated/removed) and STS-1 termination (in which STS-1 line overhead is terminated/ removed). What is terminated/removed at the end of a control channel ? - Chapter 3: "The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link- state adjacencies are not removed unnecessarily." Please be precise on what IGP is meant here; the IGP of which plane/ network ? The control plane, the signaling plane or the transmission plane ? Thanks ! Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 06 May 2002 02:05:55 -0700 Message-ID: <002c01c1f4dc$64f45080$8c03750a@wipro.com> From: "Vinay Vernekar" To: Subject: Doubt in applying the transforms in SONET/SDH traffic parameters. Date: Mon, 6 May 2002 14:29:55 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-dafbcefa-60cb-11d6-af80-0080c8048dde" This is a multi-part message in MIME format. ------=_NextPartTM-000-dafbcefa-60cb-11d6-af80-0080c8048dde Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C1F50A.7E0DDB80" ------=_NextPart_000_0029_01C1F50A.7E0DDB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The draft "draft-ietf-ccamp-gmpls-sonet-sdh-04.txt" specifies as follows = for the traffic parameters - "Each transform is optional and must be ignored if zero, except MT = that cannot be zero and is ignored if equal to one" Is'nt it that the transform should be "mandatory" applied and not = optionally as mentioned above. Consider for example, a request is = received from an upstream peer with Signal Type as 6 indicating STS-3c = SPE and NVC as 4 indicating a final signal which comprises of 4 = virtually concatenated STS-3c SPEs. This would mean a bandwidth of = (155.5*4)Mbps requested by the upstream. Now if the LSR decides not to = apply virtual concatenation, as inferred from the draft and gives back a = mapping corresponding to STS-3c SPE, it would result in net bandwidth = allocation of 155.5 Mbps only. Instead the LSR should reject the LSP = request.=20 The same argument holds good for other traffic parameters also.=20 Kindly reqly back if I am missing something....=20 Thanks in advance. Regards Vinay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yesterday is history. Tomorrow is mystery. Today is a gift. That's why it's called the Present!! *************************************************************************= **** Vinay H. Vernekar Sr. Software Engineer - Global R&D Solutions Wipro Technologies No.26, Hosur Main Road, Bommanahalli, Bangalore-560 068, India. Tel: 91-80-5722293/5722296 Extn. 4019 Fax: 91-80-5722696 Email: vinay.vernekar@wipro.com The World's First SEI CMM Level 5 Software Services Company *************************************************************************= **** ------=_NextPart_000_0029_01C1F50A.7E0DDB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
The draft = "draft-ietf-ccamp-gmpls-sonet-sdh-04.txt"=20 specifies as follows for the traffic parameters -
 
  "Each transform is optional and must be = ignored if=20 zero, except MT that cannot be zero and is ignored if equal to=20 one"
 
Is'nt it that the transform should be = "mandatory" applied=20 and not optionally as mentioned above. Consider for example, a request = is=20 received from an upstream peer with Signal Type as 6 indicating STS-3c = SPE and=20 NVC as 4 indicating a final signal which comprises of 4 virtually = concatenated=20 STS-3c SPEs. This would mean a bandwidth of (155.5*4)Mbps requested by = the=20 upstream. Now if the LSR decides not to apply virtual concatenation,=20 as inferred from the draft and gives back a mapping corresponding = to STS-3c=20 SPE, it would result in net bandwidth allocation of 155.5 Mbps only. = Instead the=20 LSR should reject the LSP request.
The same argument holds good for other traffic = parameters=20 also.
Kindly reqly back if I am missing something....=20
Thanks in advance.
 
Regards
Vinay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesterda= y is=20 history. Tomorrow is mystery.
Today is a gift. That’s why = it’s called the=20 Present!!
************************************************************= *****************
Vinay=20 H. Vernekar
Sr. Software Engineer - Global R&D Solutions
Wipro = Technologies
No.26, Hosur Main Road, Bommanahalli,
Bangalore-560 = 068,=20 India.
Tel: 91-80-5722293/5722296 Extn. 4019
Fax: = 91-80-5722696
Email:=20 vinay.vernekar@wipro.com
= The=20 World's First SEI CMM Level 5 Software Services=20 Company
**************************************************************= ***************
------=_NextPart_000_0029_01C1F50A.7E0DDB80-- ------=_NextPartTM-000-dafbcefa-60cb-11d6-af80-0080c8048dde Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-dafbcefa-60cb-11d6-af80-0080c8048dde-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 04 May 2002 10:29:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org Subject: Connection Deletion in GMPLS Date: Fri, 03 May 2002 17:34:31 -0700 [ post by non-subscriber ] Hi All, In GMPLS, the graceful connection deletion is done by first sending the Path message with admin status as down (D & R bits on) and then the egress node can send the PathErr message with cause 'Path State Removed'. What is the requirement of sending the complete PATH message ? This message could (possibly a new message type) have been kept very simple with session and admin status objects. There are many parameters in path message which are not required for connection deletion viz TIME_VALUE, ERO, RSVP_HOP, PROTECTION, LABEL REQUEST, SESSION ATTRIBUTES, POLICY DATA etc. If one calculates the size of these parameters for a connection it can run in to more than 50 bytes. This means the control channel bandwidth is being wasted for each and every connection at the time of graceful connection deletion by transmitting such large messages. Is there any reason for not keeping different (possibly new or could have made use of Notify message) message type for connection deletion ? Furthermore, as the complete PATH message need to go through all the nodes in the path, more processing time will be required to parse/process the large message like PATH as compared to some small message like Notify etc. This type of processing overhead will be there for each and every call/LSP in GMPLS. Please help me in understanding this issue. Regards, manoj. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 May 2002 07:07:24 -0700 Message-Id: <200205031404.g43E4tT77001@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: -07 version MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53112.1020434695.1@juniper.net> Date: Fri, 03 May 2002 07:04:55 -0700 From: Yakov Rekhter Folks, the -07 version includes setting the TE metric during graceful restart. Yakov. ------- Forwarded Message Date: Fri, 03 May 2002 07:28:51 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-07.txt - --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 G roup of the IETF. Title : OSPF Extensions in Support of Generalized MPLS Author(s) : K. Kompella et al. Filename : draft-ietf-ccamp-ospf-gmpls-extensions-07.txt Pages : 11 Date : 02-May-02 This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-07.t xt 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-ospf-gmpls-extensions-07.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-ospf-gmpls-extensions-07.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: <20020502145027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-07.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ospf-gmpls-extensions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502145027.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 May 2002 04:30:34 -0700 Message-Id: <200205031128.HAA09733@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-ospf-gmpls-extensions-07.txt Date: Fri, 03 May 2002 07:28:51 -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 : OSPF Extensions in Support of Generalized MPLS Author(s) : K. Kompella et al. Filename : draft-ietf-ccamp-ospf-gmpls-extensions-07.txt Pages : 11 Date : 02-May-02 This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-07.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-ospf-gmpls-extensions-07.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-ospf-gmpls-extensions-07.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: <20020502145027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ospf-gmpls-extensions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502145027.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 May 2002 01:52:13 -0700 To: "Gino Carrozzo" Cc: "Zafar Ali" , kireeti@juniper.net, "ccamp" , eric.mannie@gts.com, Dimitri.Papadimitriou@alcatel.be Message-ID: From: sven.van_den_bosch@alcatel.be Date: Fri, 3 May 2002 10:50:42 +0200 Subject: Re: Path TLV MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256BAE003034648f9e8a93df938690918cC1256BAE00303464" Content-Disposition: inline --0__=C1256BAE003034648f9e8a93df938690918cC1256BAE00303464 Content-type: text/plain; charset=us-ascii Gino, The draft points out the issues but the presentation in Minneapolis already contained some possible suggestions to resolve some of them. These will be documented in the next version of the draft. Sven. "Gino Carrozzo" on 03/05/2002 10:30:02 To: "Zafar Ali" cc: kireeti@juniper.net, "ccamp" , eric.mannie@gts.com, Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL Subject Re: Path TLV : Dear Zafar, if I'm not wrong, draft-ietf-ccamp-gmpls-architecture-02.txt is going to be ready for IETF Last Call, but some points seems to be without a full consensus yet. Anyway, is there any action in IETF now to solve "preliminary" FA-LSPs issues (e.g. Pah TLV, FA color/metric assignment)? IMO, draft-vandenbosch-mpls-fa-considerations-00.txt just points out these issues! Thanks Gino ----- Original Message ----- From: Zafar Ali To: Gino Carrozzo ; eric.mannie@gts.com Cc: kireeti@juniper.net ; ccamp Sent: Thursday, May 02, 2002 9:21 PM Subject: Re: Path TLV At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote: Hi all, in draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an OSPF/ISIS Path TLV is proposed to handle the info about the path taken by an FA-LSP associated with a TE-Link (FA). But the new versions of the GMPLS routing and hierarchy drafts (i.e. lsp-hierarchy-05.txt / ospf-gmpls-extensions-06.txt / isis-gmpls-extensions-10.txt) does not describe this TLV. Is this an editorial bug for the architecture-02 draft? Dear Gino, No; you may like to refer to the following draft for some "preliminary " details on this subject. http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-considerations-00.txt Thanks Regards... Zafar Thanks Gino (See attached file: att1.htm) --0__=C1256BAE003034648f9e8a93df938690918cC1256BAE00303464 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDgwNy4yMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5EZWFyIFphZmFyLDwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+aWYgSSdtIG5vdCB3cm9uZywmbmJzcDtkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLWFyY2hpdGVjdHVyZS0wMi50eHQmbmJzcDsgaXMgDQpnb2luZyB0byBiZSByZWFkeSBm b3ImbmJzcDtJRVRGIExhc3QgQ2FsbCwgPC9ESVY+DQo8RElWPmJ1dCBzb21lJm5ic3A7cG9pbnRz IHNlZW1zIHRvIGJlIHdpdGhvdXQmbmJzcDthIGZ1bGwgY29uc2Vuc3VzIHlldC48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkFueXdheSwmbmJzcDsmbmJzcDtpcyB0aGVyZSBhbnkgYWN0 aW9uIGluIElFVEYgbm93IHRvIA0Kc29sdmUmbmJzcDsicHJlbGltaW5hcnkiIEZBLUxTUHMmbmJz cDtpc3N1ZXMgKGUuZy4gUGFoIFRMViwmbmJzcDtGQSBjb2xvci9tZXRyaWMgDQphc3NpZ25tZW50 KT8gSU1PLCBkcmFmdC12YW5kZW5ib3NjaC1tcGxzLWZhLWNvbnNpZGVyYXRpb25zLTAwLnR4dCAN Cmp1c3QmbmJzcDtwb2ludHMgb3V0IHRoZXNlIGlzc3VlcyE8L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzIDwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+R2lubyZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxl PSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4 OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAg PERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEZPTlQgc2l6ZT0zPi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQogIDwvRk9OVD48L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VO RDogI2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsgZm9udC1jb2xvcjogYmxhY2siPjxGT05UIA0K ICBzaXplPTM+PEI+RnJvbTo8L0I+IDwvRk9OVD48QSB0aXRsZT16YWxpQGNpc2NvLmNvbSANCiAg aHJlZj0ibWFpbHRvOnphbGlAY2lzY28uY29tIj48Rk9OVCBzaXplPTM+WmFmYXIgQWxpPC9GT05U PjwvQT48Rk9OVCBzaXplPTM+IA0KICA8L0ZPTlQ+PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDEwcHQgYXJpYWwiPjxGT05UIHNpemU9Mz48Qj5Ubzo8L0I+IDwvRk9OVD48QSANCiAgdGl0bGU9 Zy5jYXJyb3p6b0BjcHIuaXQgaHJlZj0ibWFpbHRvOmcuY2Fycm96em9AY3ByLml0Ij48Rk9OVCBz aXplPTM+R2lubyANCiAgQ2Fycm96em88L0ZPTlQ+PC9BPjxGT05UIHNpemU9Mz4gOyA8L0ZPTlQ+ PEEgdGl0bGU9ZXJpYy5tYW5uaWVAZ3RzLmNvbSANCiAgaHJlZj0ibWFpbHRvOmVyaWMubWFubmll QGd0cy5jb20iPjxGT05UIA0KICBzaXplPTM+ZXJpYy5tYW5uaWVAZ3RzLmNvbTwvRk9OVD48L0E+ PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJp YWwiPjxGT05UIHNpemU9Mz48Qj5DYzo8L0I+IDwvRk9OVD48QSANCiAgdGl0bGU9a2lyZWV0aUBq dW5pcGVyLm5ldCBocmVmPSJtYWlsdG86a2lyZWV0aUBqdW5pcGVyLm5ldCI+PEZPTlQgDQogIHNp emU9Mz5raXJlZXRpQGp1bmlwZXIubmV0PC9GT05UPjwvQT48Rk9OVCBzaXplPTM+IDsgPC9GT05U PjxBIA0KICB0aXRsZT1jY2FtcEBvcHMuaWV0Zi5vcmcgaHJlZj0ibWFpbHRvOmNjYW1wQG9wcy5p ZXRmLm9yZyI+PEZPTlQgDQogIHNpemU9Mz5jY2FtcDwvRk9OVD48L0E+PEZPTlQgc2l6ZT0zPiA8 L0ZPTlQ+PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxGT05UIHNpemU9 Mz48Qj5TZW50OjwvQj4gVGh1cnNkYXksIE1heSAwMiwgMjAwMiANCiAgOToyMSBQTTwvRk9OVD48 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEZPTlQgc2l6ZT0zPjxCPlN1 YmplY3Q6PC9CPiBSZTogUGF0aCANCiAgVExWPC9GT05UPjwvRElWPg0KICA8RElWPjxCUj48L0RJ Vj5BdCAwNDoyMiBQTSA1LzIvMjAwMiArMDIwMCwgR2lubyBDYXJyb3p6byB3cm90ZTo8QlI+DQog IDxCTE9DS1FVT1RFIGNpdGUgdHlwZT0iY2l0ZSI+SGkgYWxsLDxCUj48QlI+aW4mbmJzcDsgDQog ICAgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hcmNoaXRlY3R1cmUtMDIudHh0IChTZWMuIDEwLjEp IGFuIE9TUEYvSVNJUzxCUj5QYXRoIA0KICAgIFRMViBpcyBwcm9wb3NlZCB0byBoYW5kbGUgdGhl IGluZm8gYWJvdXQgdGhlIHBhdGggdGFrZW4gYnkgYW4gDQogICAgRkEtTFNQPEJSPmFzc29jaWF0 ZWQgd2l0aCBhIFRFLUxpbmsgKEZBKS48QlI+PEJSPkJ1dCB0aGUgbmV3IHZlcnNpb25zIG9mIHRo ZSANCiAgICBHTVBMUyByb3V0aW5nIGFuZCBoaWVyYXJjaHkgZHJhZnRzPEJSPihpLmUuIGxzcC1o aWVyYXJjaHktMDUudHh0IC8gDQogICAgb3NwZi1nbXBscy1leHRlbnNpb25zLTA2LnR4dCAvPEJS PmlzaXMtZ21wbHMtZXh0ZW5zaW9ucy0xMC50eHQpPEJSPmRvZXMgbm90IA0KICAgIGRlc2NyaWJl IHRoaXMgVExWLjxCUj48QlI+SXMgdGhpcyBhbiBlZGl0b3JpYWwgYnVnIGZvciB0aGUgYXJjaGl0 ZWN0dXJlLTAyIA0KICAgIGRyYWZ0PzwvQkxPQ0tRVU9URT48QlI+RGVhciBHaW5vLCA8QlI+PEJS Pk5vOyB5b3UgbWF5IGxpa2UgdG8gcmVmZXIgdG8gdGhlIA0KICBmb2xsb3dpbmcgZHJhZnQgZm9y IHNvbWUgInA8Rk9OVCANCiAgZmFjZT0iQXJpYWwsIEhlbHZldGljYSI+cmVsaW1pbmFyeTwvRk9O VD48Rk9OVCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhIj4gDQogIDwvRk9OVD4iIGRldGFpbHMgb24g dGhpcyBzdWJqZWN0LiA8QlI+PEJSPjxBIA0KICBocmVmPSJodHRwOi8vc2VhcmNoLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC12YW5kZW5ib3NjaC1tcGxzLWZhLWNvbnNpZGVyYXRpb25z LTAwLnR4dCIgDQogIGV1ZG9yYT0iYXV0b3VybCI+aHR0cDovL3NlYXJjaC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtdmFuZGVuYm9zY2gtbXBscy1mYS1jb25zaWRlcmF0aW9ucy0wMC48 L0E+PEEgDQogIGhyZWY9Imh0dHA6Ly9zZWFyY2guaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXZhbmRlbmJvc2NoLW1wbHMtZmEtY29uc2lkZXJhdGlvbnMtMDAudHh0IiANCiAgZXVkb3Jh PSJhdXRvdXJsIj50eHQ8QlI+PEJSPjwvQT5UaGFua3M8QlI+PEJSPlJlZ2FyZHMuLi4gWmFmYXIg PEJSPjxCUj48QlI+DQogIDxCTE9DS1FVT1RFIGNpdGUgDQp0eXBlPSJjaXRlIj5UaGFua3M8QlI+ R2lubzwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --0__=C1256BAE003034648f9e8a93df938690918cC1256BAE00303464-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 03 May 2002 01:30:47 -0700 Message-ID: <007501c1f27c$b90fa000$d7217283@meta.cpr.it> From: "Gino Carrozzo" To: "Zafar Ali" Cc: , "ccamp" , , Subject: Re: Path TLV Date: Fri, 3 May 2002 10:30:02 +0200 Organization: META-CPR MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C1F28D.7BCEB760" This is a multi-part message in MIME format. ------=_NextPart_000_0072_01C1F28D.7BCEB760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Zafar, if I'm not wrong, draft-ietf-ccamp-gmpls-architecture-02.txt is going = to be ready for IETF Last Call,=20 but some points seems to be without a full consensus yet. Anyway, is there any action in IETF now to solve "preliminary" FA-LSPs = issues (e.g. Pah TLV, FA color/metric assignment)? IMO, = draft-vandenbosch-mpls-fa-considerations-00.txt just points out these = issues! Thanks=20 Gino=20 ----- Original Message -----=20 From: Zafar Ali=20 To: Gino Carrozzo ; eric.mannie@gts.com=20 Cc: kireeti@juniper.net ; ccamp=20 Sent: Thursday, May 02, 2002 9:21 PM Subject: Re: Path TLV At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote: Hi all, in draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an = OSPF/ISIS Path TLV is proposed to handle the info about the path taken by an = FA-LSP associated with a TE-Link (FA). But the new versions of the GMPLS routing and hierarchy drafts (i.e. lsp-hierarchy-05.txt / ospf-gmpls-extensions-06.txt / isis-gmpls-extensions-10.txt) does not describe this TLV. Is this an editorial bug for the architecture-02 draft? Dear Gino,=20 No; you may like to refer to the following draft for some "preliminary = " details on this subject.=20 = http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-consider= ations-00.txt Thanks Regards... Zafar=20 Thanks Gino ------=_NextPart_000_0072_01C1F28D.7BCEB760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Zafar,
 
if I'm not = wrong, draft-ietf-ccamp-gmpls-architecture-02.txt  is=20 going to be ready for IETF Last Call,
but some points seems to be without a full consensus = yet.
 
Anyway,  is there any action in IETF now to=20 solve "preliminary" FA-LSPs issues (e.g. Pah TLV, FA = color/metric=20 assignment)? IMO, draft-vandenbosch-mpls-fa-considerations-00.txt=20 just points out these issues!
 
Thanks
 
Gino 
----- Original Message = -----=20
From: Zafar = Ali=20
To: Gino=20 Carrozzo ; eric.mannie@gts.com
Cc: kireeti@juniper.net ; ccamp
Sent: Thursday, = May 02, 2002=20 9:21 PM
Subject: Re: = Path=20 TLV

At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote:
Hi all,

in =20 draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an = OSPF/ISIS
Path=20 TLV is proposed to handle the info about the path taken by an=20 FA-LSP
associated with a TE-Link (FA).

But the new = versions of the=20 GMPLS routing and hierarchy drafts
(i.e. lsp-hierarchy-05.txt /=20 ospf-gmpls-extensions-06.txt = /
isis-gmpls-extensions-10.txt)
does not=20 describe this TLV.

Is this an editorial bug for the = architecture-02=20 draft?

Dear Gino,

No; you may like to refer = to the=20 following draft for some "preliminary=20 " details on this subject.

http://search.ietf.org/internet-drafts/draft-vandenbos= ch-mpls-fa-considerations-00.txt

Thanks

Regards... Zafar =


Thanks
Gino
------=_NextPart_000_0072_01C1F28D.7BCEB760-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 May 2002 12:22:08 -0700 Message-Id: <4.3.2.7.2.20020502151208.02aead10@sword.cisco.com> Date: Thu, 02 May 2002 15:21:22 -0400 To: "Gino Carrozzo" , From: Zafar Ali Subject: Re: Path TLV Cc: , "ccamp" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_24732052==_.ALT" --=====================_24732052==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote: >Hi all, > >in draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an OSPF/ISIS >Path TLV is proposed to handle the info about the path taken by an FA-LSP >associated with a TE-Link (FA). > >But the new versions of the GMPLS routing and hierarchy drafts >(i.e. lsp-hierarchy-05.txt / ospf-gmpls-extensions-06.txt / >isis-gmpls-extensions-10.txt) >does not describe this TLV. > >Is this an editorial bug for the architecture-02 draft? Dear Gino, No; you may like to refer to the following draft for some "preliminary " details on this subject. http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-considerations-00.txt Thanks Regards... Zafar >Thanks >Gino --=====================_24732052==_.ALT Content-Type: text/html; charset="us-ascii" At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote:
Hi all,

in  draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an OSPF/ISIS
Path TLV is proposed to handle the info about the path taken by an FA-LSP
associated with a TE-Link (FA).

But the new versions of the GMPLS routing and hierarchy drafts
(i.e. lsp-hierarchy-05.txt / ospf-gmpls-extensions-06.txt /
isis-gmpls-extensions-10.txt)
does not describe this TLV.

Is this an editorial bug for the architecture-02 draft?

Dear Gino,

No; you may like to refer to the following draft for some "preliminary " details on this subject.

http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-considerations-00.txt

Thanks

Regards... Zafar


Thanks
Gino
--=====================_24732052==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 May 2002 12:08:00 -0700 Date: Thu, 02 May 2002 15:05:26 -0400 From: Dave McDysan Subject: FYI: WorldCom Vote/Comments - ITU-T Y.1710 (Corr. 1) and Y.1711 To: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com, ccamp@ops.ietf.org, pwe3-admin@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit WorldCom has submmited comments on draft recommendations ITU-T Y.1710 (Corr. 1) and Y.1711 to the ITU-T with a vote of "We do not support this text. Reasons are given in the attachment." It is not yet clear whether these comments will be handled at the Japan meeting in July or at the next SG13 meeting in Oct-Nov'02. WorldCom is trying to get clarification. These comments have been posted by the ITU-T secretariat at: http://www.itu.int/itudoc/itu-t/aap/sg13aap/recaap/y.1710c1/arc/ar1.html and http://www.itu.int/itudoc/itu-t/aap/sg13aap/recaap/y.1711/arc/ar1.html However, access require a TIES account which an ITU member can request by sending a form to the ITU-T. After getting the TIES access, you may sign up for ITU-T SG13, Question 3, email list "tsg13q3@itu.int" at http://www.itu.int/ITU-T/studygroups/com13/edh/subscribe.html if you want to be part of email discussion on these and other related comments. WorldCom has also advised ITU-T SG13,Question 3 participants of these comments who are responsible for development of these recommendations in SG13. If your company is an ITU-T member and is interested in this subject, we encourage you to participate in the process. The WorldCom comments on the subject documents are reproduced below for your information. Dave ============================================================================ = ITU-T Draft Recommendations Y.1710 (Corr. 1) (WorldCom Comments - Additional Review) 1. General Comments Although never clearly stated in Y.1710, based upon related discussion and documents submitted to the IETF, this recommendation appears to assume that MPLS is a layer two service, requiring OAM functionality that exists independently of any layer three technology. This assumption is not consistent with the cited IETF references of RFC 3031 and 3032, which only address IP over MPLS. Furthermore, as detailed below, some requirements strive to preclude OAM mechanisms that rely upon IP. The IETF has no efforts in place to define MPLS as a layered network service in its own right. It is incumbent upon those who would augment MPLS so that it can become a layered service on its own to explain why existing services, for example, FR and ATM, do not suffice. This must be done with the concurrence and cooperation of the IETF, since two bodies developing standards for the same protocol will likely result in a lack of interoperability. We suggest that those seeking to use MPLS to deliver multiple services should explore the IETF PWE3 work. It may be more appropriate to build OAM functionality into the PWE endpoints than in the MPLS layer as proposed in Y.1710 and Y.1711. We also have a number of questions. Can the proposed mechanisms be implemented without fundamental changes to the deployed MPLS base? Will the proposed mechanisms provide any useful functionality in the face of penultimate hop popping? Will the proposed mechanisms provide any useful functionality in the face of LSP merging? Will the proposed mechanisms provide any useful functionality in the face of unidirectional LSPs? Finally, we believe that there are several process issues with these proposals: a. First, in general defining OAM prior to the standardization of a service appears to be the wrong order of doing things. b. Second, defining requirements and a proposed solution to them in parallel is an approach that seems to preclude the critical examination of alternative solutions. We strongly recommend that the ITU-T focus on defining the problem scope and associated requirements BEFORE taking up any specific solution. c. Finally, in the IETF way of doing things it is perfectly acceptable for vendors or service providers to develop experimental implementations of the protocol(s) defined in Y.1711 and bring the results of this work back to the IETF. 2. Detailed Comments 2.1 Section 1 Scope - Since the plural is used in "MPLS networks," does the scope include MPLS LSPs that traverse multiple service providers? If so, this should be explicitly stated. - Since only RFC 3031 and 3032 are cited as references for MPLS, the scope is restricted to IP over MPLS networks. Although other efforts are in progress to standardize other services over MPLS, until these standards are complete and stable, definition of the means to operate and maintain (OAM) them are premature. 2.2 Section 3 Definitions - Why is control information excluded from these definitions? How relevant are definitions to IP over MPLS from the cited M.20 Recommendation intended to define migration from analogue to digital circuits? 2.3 Section 5 Introduction - What is the basis of determining whether a solution is "architecturally correct?" Suggest that the reference for a correct architecture be cited and agreed to,or strike this phrase. - Suggest that instead of "maintain correct connectivity," what is actually required is to "maintain and confirm configured connectivity." This should also be stated in the bulleted list in the second paragraph. - The claim in the last sentence that an LSP is tied to availability and QoS SLAs for customer traffic is suspect. An LSP is only part of an IP service. For example, IP traffic may be load balanced across more than one LSP, or may traverse router hops that do not use MPLS. Even in a pseudo-wire over MPLS application, the entire customer service may not be over MPLS. The fact that MPLS is often only part of the overall service needs to be stated in the scope and carried throughout the requirements structure. 2.4 Section 6 Motivation for MPLS Functions - General Comment * A number of terms used in this section are not used in the MPLS standards cited in section 2, and should be replaced with standard terminology. For example, the Y.1710 terminology in quotes should be replaced as follows with terminology from RFCs 3031 and 3032: > "client" = packet or network layer > "server" = link layer > "MPLS nesting capability" = label stacking > "control-plane" = control protocol > "user-plane" = forwarding * It is unclear why much of this text and reasoning is needed in a requirements document. If retained, this text needs definitions of all terms and better explanation of the concepts addressed. Some detailed comments below attempt to draw out some of the issues with this text. - Item 1 * First paragraph: The level of MPLS label stacking is limited by at least the MTU size of the link layer. * Second paragraph: Need better description or an example of a "MPLS control-plane OAM function" in order to provide appropriate motivation. . First dash: What is "user-plane" for customer traffic and signalling? If these do not have the same processing or failure conditions, then is this an implementation issue that is outside the scope of standards? Wouldn't the same argument of the last sentence apply equally to MPLS OAM packets? . Second dash: This is outside the scope of RFC 3031. . Third dash: This is not worded as a problem. . Next to last paragraph: The assertion that well defined and interoperable MPLS control protocols and (as yet undefined) MPLS OAM mechanisms be defined independently so that they can evolve independently is questionable. For example, as stated earlier, it seems highly desirable that in order for MPLS OAM mechanisms to confirm configured connectivity that a dependence of OAM on control protocol configuration makes sense. The last paragraph of item 1 that the solution is control-plane independent appears to be in contradiction with RFC 3031, which requires and IP control plane in every MPLS LSR. - Item 2 * See comment in section 5. An LSP is not necessarily directly related to a customer service. - Items 3 & 5 * Seem to be making the same point. Also, most of this information is repeated in section 7. - Item 6 * The example of "squelching of traffic" is unclear. Wouldn't the preferred solution be to correctly direct the traffic? Is squelching an intermediate step toward this goal? - Item 8 * Interaction of protection and restoration between multiple technological layers operating under different paradigms is a complex and as yet not completely understood subject. 2.5 Section 7 Requirements for MPLS OAM Functions - Item 1 * "on-demand" and "continuous" are not defined. - Item 2 * Why is notification of a control protocol not mentioned? - Item 3 * This requirement is vague. How would one determine whether a particular solution met this requirement? Last sentence is redundant with item 4. - Item 4 * The terms "fabric", "swapped" and "self-replication" are not defined in the document or any of the references cited. Need a definition of "simple loss of LSP connectivity". - Item 5 * A very general statement which leaves it unclear as to what the specific requirement is on MPLS OAM. Needs clarification. - Item 9 * Where is the definition for a LSN? RFC 3032 defines a Label Switching Router LSR), and suggest use of this term. It appears that this requirement would apply to the egress LSR. What happens when penultimate hop popping is implemented? - Item 10 * As mentioned earlier, MPLS is not currently defined as a service and hence availability and QoS are not meaningful in the conventional sense. Also, the reference to Y.1711 should be removed. A requirement should not be defined in terms of a specific solution. - Item 11 * Since only RFC 3031 and 3032 are cited as normative references for MPLS, the scope is restricted to IP over MPLS networks. Since only support for an IP "client" network is all that is defined, this requirement for OAM is premature until protocols (or at least the architecture for them) for support of other "client" networks are standardized. - Item 12 * Since only RFC 3031 and 3032 are cited as normative references for MPLS, the scope is restricted to IP over MPLS networks. This requirement has no architectural or protocol standards basis. - Item 14 * Why preclude observance of normal operation as part of OAM? - Item 16 * Second sentence is stated as a solution. Delete. 3. Additional Comments Several important requirements are also missing. We note at least the following: - Since MPLS LSPs are unidirectional, OAM mechanisms that require communication in the opposite direction cannot rely on the existence of an LSP in the opposite direction between the ingress and egress LSR. - Depending upon interpretation of the scope, support for MPLS OAM across multiple service providers may be a requirement. - When MPLS label stacking is employed, the OAM mechanisms must operate correctly at each level of label stacking. - MPLS OAM must work correctly with and without penultimate hop popping. - There needs to be some requirements that scope how large the MPLS OAM identifier space needs to be. For IP over MPLS, the number of LSPs that can exist can be quite large. If other services are considered (e.g., IP VPN, PWE3), then the identifier space needs to be correspondingly large. - It is highly desirable to be able to determine the actual path that an LSP takes. ============================================================================ = ITU-T Draft Recommendations Y.1711 (WorldCom Comments - Additional Review) Since the MPLS OAM mechanisms described in this recommendation are based on the requirements defined in recommendation Y.1710 (Corr. 1), it will be premature to approve Y.1711 until the comments submitted by WorldCom on Y.1710 (Corr. 1) are resolved. WorldCom's general comments on Y.1710 (Corr. 1) are also applicable to Y.1711, and are repeated below for the sake of completeness. Although never clearly stated in Y.1711, based upon related discussion and documents submitted to the IETF, this recommendation appears to assume that MPLS is a layer two service, requiring OAM functionality that exists independently of any layer three technology. This assumption is not consistent with the cited IETF references of RFC 3031 and 3032, which only address IP over MPLS. Furthermore, as detailed below, some requirements strive to preclude OAM mechanisms that rely upon IP. The IETF has no efforts in place to define MPLS as a layered network service in its own right. It is incumbent upon those who would augment MPLS so that it can become a layered service on its own to explain why existing services, for example, FR and ATM, do not suffice. This must be done with the concurrence and cooperation of the IETF, since two bodies developing standards for the same protocol will likely result in a lack of interoperability. We suggest that those seeking to use MPLS to deliver multiple services should explore the IETF PWE3 work. It may be more appropriate to build OAM functionality into the PWE endpoints than in the MPLS layer as proposed in Y.1711. We also have a number of questions. Can the proposed mechanisms be implemented without fundamental changes to the deployed MPLS base? Will the proposed mechanisms provide any useful functionality in the face of penultimate hop popping? Will the proposed mechanisms provide any useful functionality in the face of LSP merging? Will the proposed mechanisms provide any useful functionality in the face of unidirectional LSPs? Finally, we believe that there are several process issues with these proposals: a. First, in general defining OAM prior to the standardization of a service appears to be the wrong order of doing things. b. Second, defining requirements and a proposed solution to them in parallel is an approach that seems to preclude the critical examination of alternative solutions. We strongly recommend that the ITU-T focus on defining the problem scope and associated requirements BEFORE taking up any specific solution. c. Finally, in the IETF way of doing things it is perfectly acceptable for vendors or service providers to develop experimental implementations of the protocol(s) defined in Y.1711 and bring the results of this work back to the IETF. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 May 2002 07:24:03 -0700 Message-ID: <00d501c1f1e4$bd6b7c20$d7217283@meta.cpr.it> From: "Gino Carrozzo" To: Cc: , "ccamp" Subject: Path TLV Date: Thu, 2 May 2002 16:22:06 +0200 Organization: META-CPR MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, in draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an OSPF/ISIS Path TLV is proposed to handle the info about the path taken by an FA-LSP associated with a TE-Link (FA). But the new versions of the GMPLS routing and hierarchy drafts (i.e. lsp-hierarchy-05.txt / ospf-gmpls-extensions-06.txt / isis-gmpls-extensions-10.txt) does not describe this TLV. Is this an editorial bug for the architecture-02 draft? Thanks Gino Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 02 May 2002 01:59:29 -0700 Message-ID: <3CD0FF4B.E9084A37@alcatel.be> Date: Thu, 02 May 2002 10:56:43 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: Michiel van Everdingen Cc: Jonathan Lang , "ccamp@ops.ietf.org" Subject: Re: Question on LMP Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi michiel, all, i will respond to this one because i think some clarification would be useful: --- 2. Is there a mandatory need to distinguish between a failure of the RSVP-TE process and a failure of the LMP process ? http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html You wrote: > standard "ping" only tells you reachability. It does not tell you if the LMP > component is functioning or not. This is similar to why Hellos are used in > other protocols (e.g., RSVP Hello). I'm not sure why we need *both* RSVP-TE Hellos as well as LMP hellos. See also question 2 above. --- Yes, we need to maintain both for the following reasons you can run rsvp-te w/o lmp, lmp w/o rsvp or both (lmp and rsvp), in the latter case there is a need to have a clear distinction between a lmp controller failure or signalling controller failure; as such you can see the global picture as follows: - LMP maintains control plane adjacencies by sending LMP Hello's on Control Channels implemented on top of a given control network topology - RSVP-TE maintains signalling plane adjacencies by sending RSVP Hello's on signalling channels that can be the same as the above Control Channels but also - OSPF maintain routing adjcencies by sending OSPF Hello's on routing channels that can be the same as the above Control Channels The important point is when these Control Channels have a common usage, the LMP Hello's can be seen as enabling a dynamic setup and maintenance of the control plane channels through which all the other LMP modules (link property correlation, for instance) as well as the routing and signalling protocols can exchange information. However, these lmp hello's do not maintain the liveness of the peering ospf and rsvp-te instances. Some comments in-line... hope this clarifies, - dimitri. Michiel van Everdingen wrote: > > Hello Jonathan, > > Could you please make clear in the LMP draft that > 1. "control channels" are established *over* a "control network". > 2. Not all signaling messages (example: the RSVP-TE notify > message) are sent over "control channels". i let this editorial task to jonathan (just a hint a standard indicates what it does and not what it doesn't) > If this could be added in the LMP draft, I would not have become > confused on the relation between "control channels" and > "control network". > > Examples of text in the LMP draft that caused my confusion: > > - Chapter 1: "To enable communication between nodes for routing, > signaling, and link management, control channels must be > established between the node pair ..." > Why the "must" in this sentence ? I would think that > communication is perfectly well possible over the "control > network", not using "control channels" ? it is clear (at least from my point of view) if one except out of band ip control networks (in such a case one can for instance consider ip tunnels implementing these control channels), nothing tells in this sentence that these channels must be the same; however it is rather obvious that having a "common" control channel topology brings high benefits. > - Chapter 2: "One or more active control channels may be grouped > into a logical control channel for signaling, routing, and > link property correlation purposes." > This sentence seems to go in the direction of a kind of multi- > link PPP protocol (L2). At least it made me believe that the > control network is built on top of control channels - a thought > that apparently is wrong. i would see it as "control channel on top of a control network" > - Chapter 2: "... the control channel MUST terminate on the same > two nodes that the TE link spans" > I could only understand this sentence assuming "control channels" > are a kind of L2 technique. What does "terminate" in this > sentence imply ? Is something more happening than the standard > TCP/UDP termination to packets that are sent over control channels? it simply says you send the TE Link information using the control channel between nodes defining this TE Link > - Chapter 3: "The LMP Hello protocol is intended to be a lightweight > keep-alive mechanism that will react to control channel failures > rapidly so that IGP Hellos are not lost and the associated link- > state adjacencies are not removed unnecessarily." see above. > Again, I could only understand this sentence assuming "control > channels" are a kind of L2 technique. Is it possible to be more > precise on what "IGP" is meant here (see also > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00657.html). > > Could you please also indicate that "control channel management" does > *not* need to be fast (O(mseconds)) ? > See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00700.html. it would be contradicory with the usage defined here above. > Looking back through this thread, I think at least the following > two questions are still open: > > 1. What does the control channel management achieve? > a. IP reachability confirmation. i don't understand what you mean here, please clarify > b. Negotiation of Hello and Dead intervals. this negotiation is part of the control channel configuration so ... seems clear. > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00653.html > > 2. Is there a mandatory need to distinguish between a failure of > the RSVP-TE process and a failure of the LMP process ? > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html see above. > You wrote: > > standard "ping" only tells you reachability. It does not tell you if the LMP > > component is functioning or not. This is similar to why Hellos are used in > > other protocols (e.g., RSVP Hello). > > I'm not sure why we need *both* RSVP-TE Hellos as well as LMP hellos. See > also question 2 above. > > Thanks, > > Michiel > > Jonathan Lang wrote: > > > > Michiel, > > > > > > > > > > If "control channels" are nothing more than the standard "ping" mechanism, > > > why not use this standard "ping" mechanism ? > > > If "control channels" does provide more than standard "ping", could you > > > please let me know what that would be (and why that would be mandatorily > > > needed) ? > > standard "ping" only tells you reachability. It does not tell you if the LMP > > component is functioning or not. This is similar to why Hellos are used in > > other protocols (e.g., RSVP Hello). > > > > Thanks, > > Jonathan > > > > > > > > I think I first need clarity on the relation between "control > > > network" and > > > "control channel" before being able to comment on your other points. > > > > > > > > > Thanks ! > > > > > > Michiel > > > > -- > +------------------------------------------------------------------+ > | Michiel van Everdingen | > | Systems Engineer | > | Lucent Technologies - Optical Networking Group | > | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | > | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | > | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | > +------------------------------------------------------------------+ -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 18:26:01 -0700 Message-Id: <4.3.2.7.2.20020501210609.04628790@sword.cisco.com> Date: Wed, 01 May 2002 21:23:35 -0400 To: Yakov Rekhter From: Zafar Ali Subject: Re: TE metric and graceful restart Cc: "Don Fedyk" , Kireeti Kompella , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10531864==_.ALT" --=====================_10531864==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:23 AM 5/1/2002 -0700, Yakov Rekhter wrote: >The spec doesn't say that a node *should* originate a TE LSA upon the restart. Dear Yakov, Thanks for your reply. The above statement clarifies the issue. Regards.... Zafar --=====================_10531864==_.ALT Content-Type: text/html; charset="us-ascii" At 11:23 AM 5/1/2002 -0700, Yakov Rekhter wrote:
The spec doesn't say that a node *should* originate a TE LSA upon the restart.

Dear Yakov,

Thanks for your reply. The above statement clarifies the issue.

Regards.... Zafar --=====================_10531864==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 15:09:05 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6022EB38E@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Yakov Rekhter , Zafar Ali Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Wed, 1 May 2002 18:08:10 -0400 Yakov Yakov Rekhter wrote: > -----Original Message----- > > Zafar and Don, > > > >I think the text is correct since it is "should ... until it can determine > > >the amount of reserved..." Logically a node might never advertise zero > > >because it knows its resources. However, I do prefer *may* in place of the > > >first *should* which implies zero bandwidth advertisement is optional. > > > > Dear Yakov, > > > > I agree with Don. Switching the "should" to "may" will clarify the text > > greatly. > > Zero b/w advertisement is optional with the current spec, as "should" has > to do with setting unreserved b/w to 0, and not with originating a TE LSA. > The spec doesn't say that a node *should* originate a TE LSA upon the restart. > > Yakov. > Actually you are correct. What is optional is the origination of the TE LSA not the BW info. Agreed. Don > > > > > >Yakov Rekhter wrote: > > > > > > > > Don, > > > > Here is the current text: > > > > > > > > When a restarting node is going to originate its TE LSAs, the TE LSAs > > > > containing Link TLV should be originated with 0 unreserved bandwidth, > > > > and if the Link has LSC or FSC as its Switching Capability then also > > > > with 0 as Max LSP Bandwidth, until the node is able to determine the > > > > amount of unreserved resources taking into account the resources > > > > reserved by the already established LSPs that have been preserved > > > > across the restart. Once the restarting node determines the amount of > > > > unreserved resources, taking into account the resources reserved by > > > > the already established LSPs that have been preserved across the > > > > restart, the node should advertise these resources in its TE LSAs. > > > > > > > > First of all note that the node advertises 0 unreserved b/w > > > > *only* "until the node is able to determine the > > > > amount of unreserved resources taking into account the resources > > > > reserved by the already established LSPs that have been preserved > > > > across the restart." > > > > > > > > Second, note that originating TE LSA with 0 unreserved b/w > > > > is *should*, not *must*. > > > > > > > > With this in mind, don't you think that the text is ok ? > > > > Or do you still want to change "should" in the first sentence above > > > > into "may" ? > > > > > > > > Yakov. > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 14:51:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Subject: Re: Profile parameter in SDH/SONET traffic Params Date: Wed, 01 May 2002 10:25:51 -0700 [ post by non-subscriber ] Hi Dimitri, Should the O-UNI implementations continue to use the old structure or change to the new structure of this parameter (SDH/SONET traffic param)? Is the addition of profile a requirement for UNI or NNI or both ? Regards, manoj. >From: Dimitri.Papadimitriou@alcatel.be >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Profile parameter in SDH/SONET traffic Params >Date: Wed, 01 May 2002 13:13:30 +0200 > >manoj, > >manoj juneja wrote: > > > > [ post by non-subscriber ] > > > > Hi All, > > In the new version of the draft > > draft-ietf-ccamp-gmpls-sonet-sdh-04.txt, a new parameter named "Profile" >has > > been added in SDH/SONET traffic parameters. As OIF's O-UNI is also using > > this parameter, does this mean that this parameter got changed for O-UNI > > requirements also ? > >can you indicate where oif uni use a profile parameter ? the oif o-uni >as you call is based on gmpls signalling so the next question is some >how confusing ... > >wouldn't be possible to be a little bit more accurate ? > > > If this parameter is required only for GMPLS, please indicate that too. > > > > I think OIF's O-UNI makes a reference to this ccamp draft. > >yes (as mentioned here above) but what's the point ? > > > Please help me in understanding this issue. > >there is nothing very mystic to understand here it simply a "field" >that will enable to have a finer connection profile with respect to >monitoring capabilities for instance. > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >Website: http://www.rc.bel.alcatel.be/~papadimd/index.html >Address: Alcatel - Optical NA, Fr. Wellesplein, 1 > B-2018 Antwerpen, Belgium >Phone: Work: +32 3 2408491 - Home: +32 2 3434361 _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 11:34:41 -0700 Message-Id: <200205011823.g41INdT44842@merlot.juniper.net> To: Zafar Ali cc: "Don Fedyk" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18370.1020277419.1@juniper.net> Date: Wed, 01 May 2002 11:23:39 -0700 From: Yakov Rekhter Zafar and Don, > >I think the text is correct since it is "should ... until it can determine > >the amount of reserved..." Logically a node might never advertise zero > >because it knows its resources. However, I do prefer *may* in place of the > >first *should* which implies zero bandwidth advertisement is optional. > > Dear Yakov, > > I agree with Don. Switching the "should" to "may" will clarify the text > greatly. Zero b/w advertisement is optional with the current spec, as "should" has to do with setting unreserved b/w to 0, and not with originating a TE LSA. The spec doesn't say that a node *should* originate a TE LSA upon the restart. Yakov. > > Thanks > > Regards... Zafar > > > >Thanks, > >Don > > > > > >Yakov Rekhter wrote: > > > > > > Don, > > > > > > > Kireeti, Zafer: > > > > > > > > I think that Zafer picked up on my earlier point that just because > >routing > > > > is gracefully restarting an implementation may have an independent > > > > LSP system that can function just fine so why be forced to penalize > > > > it? On the other hand, you may have an LSP system that is linked > > > > to routing such it must restart as well and then I would agree that > > > > zeroing bandwidth may well be necessary( but somewhat less "graceful"). > > > > I'm not convinced changing Metrics is required at all. > > > > > > > > So I would agree with Zafer the wording should be such that either > > > > case is allowed, > > > > > > Here is the current text: > > > > > > When a restarting node is going to originate its TE LSAs, the TE LSAs > > > containing Link TLV should be originated with 0 unreserved bandwidth, > > > and if the Link has LSC or FSC as its Switching Capability then also > > > with 0 as Max LSP Bandwidth, until the node is able to determine the > > > amount of unreserved resources taking into account the resources > > > reserved by the already established LSPs that have been preserved > > > across the restart. Once the restarting node determines the amount of > > > unreserved resources, taking into account the resources reserved by > > > the already established LSPs that have been preserved across the > > > restart, the node should advertise these resources in its TE LSAs. > > > > > > First of all note that the node advertises 0 unreserved b/w > > > *only* "until the node is able to determine the > > > amount of unreserved resources taking into account the resources > > > reserved by the already established LSPs that have been preserved > > > across the restart." > > > > > > Second, note that originating TE LSA with 0 unreserved b/w > > > is *should*, not *must*. > > > > > > With this in mind, don't you think that the text is ok ? > > > Or do you still want to change "should" in the first sentence above > > > into "may" ? > > > > > > Yakov. > > > > > > > > --=====================_15224191==_.ALT > Content-Type: text/html; charset="us-ascii" > > > At 01:01 PM 5/1/2002 -0400, Don Fedyk wrote:
>
Yakov,
>
> I think the text is correct since it is "should ... until it can > determine
> the amount of reserved..." Logically a node might never advertise > zero
> because it knows its resources. However, I do prefer *may* in place of > the
> first *should* which implies zero bandwidth advertisement is > optional. 

> Dear Yakov,
>
> I agree with Don. Switching the "should" to "may" > will clarify the text greatly.
>
> Thanks
>
> Regards... Zafar
>
>
>
Thanks,
> Don
>
>
> Yakov Rekhter wrote:
> >
> > Don,
> >
> > > Kireeti, Zafer:
> > >
> > > I think that Zafer picked up on my earlier point that just > because
> routing
> > > is gracefully restarting an implementation may have an > independent
> > > LSP system that can function just fine so why be forced to > penalize
> > > it? On the other hand, you may have an LSP system that is > linked
> > > to routing such it must restart as well and then I would agree > that
> > > zeroing bandwidth may well be necessary( but somewhat less > "graceful").
> > > I'm not convinced changing Metrics is required at all.
> > >
> > > So I would agree with Zafer the wording should be such that > either
> > > case is allowed,
> >
> > Here is the current text:
> >
> >    When a restarting node is going to originate its > TE LSAs, the TE LSAs
> >    containing Link TLV should be originated with 0 > unreserved bandwidth,
> >    and if the Link has LSC or FSC as its Switching > Capability then also
> >    with 0 as Max LSP Bandwidth, until the node is > able to determine the
> >    amount of unreserved resources taking into account > the resources
> >    reserved by the already established LSPs that have > been preserved
> >    across the restart. Once the restarting node > determines the amount of
> >    unreserved resources, taking into account the > resources reserved by
> >    the already established LSPs that have been > preserved across the
> >    restart, the node should advertise these resources > in its TE LSAs.
> >
> > First of all note that the node advertises 0 unreserved b/w
> > *only* "until the node is able to determine the
> > amount of unreserved resources taking into account the > resources
> > reserved by the already established LSPs that have been > preserved
> > across the restart."
> >
> > Second, note that originating TE LSA with 0 unreserved b/w
> > is *should*, not *must*.
> >
> > With this in mind, don't you think that the text is ok ?
> > Or do you still want to change "should" in the first > sentence above
> > into "may" ?
> >
> > Yakov.
> >
> >
> > --=====================_15224191==_.ALT-- > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 10:59:35 -0700 Message-ID: <3CD029CA.A502DE67@alcatel.be> Date: Wed, 01 May 2002 19:45:46 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: manoj juneja Cc: ccamp@ops.ietf.org, "oif-signal@oiforum.com" Subject: Re: Profile parameter in SDH/SONET traffic Params Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi manoj, i suggest that we continue this discussion on the oif mailing list ... regards, - dimitri. manoj juneja wrote: > > Hi Dimitri, > > Should the O-UNI implementations continue to use the old structure or change > to the new structure of this parameter (SDH/SONET traffic param)? > > Is the addition of profile a requirement for UNI or NNI or both ? > > Regards, > manoj. > > >From: Dimitri.Papadimitriou@alcatel.be > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: Profile parameter in SDH/SONET traffic Params > >Date: Wed, 01 May 2002 13:13:30 +0200 > > > >manoj, > > > >manoj juneja wrote: > > > > > > [ post by non-subscriber ] > > > > > > Hi All, > > > In the new version of the draft > > > draft-ietf-ccamp-gmpls-sonet-sdh-04.txt, a new parameter named "Profile" > >has > > > been added in SDH/SONET traffic parameters. As OIF's O-UNI is also using > > > this parameter, does this mean that this parameter got changed for O-UNI > > > requirements also ? > > > >can you indicate where oif uni use a profile parameter ? the oif o-uni > >as you call is based on gmpls signalling so the next question is some > >how confusing ... > > > >wouldn't be possible to be a little bit more accurate ? > > > > > If this parameter is required only for GMPLS, please indicate that too. > > > > > > I think OIF's O-UNI makes a reference to this ccamp draft. > > > >yes (as mentioned here above) but what's the point ? > > > > > Please help me in understanding this issue. > > > >there is nothing very mystic to understand here it simply a "field" > >that will enable to have a finer connection profile with respect to > >monitoring capabilities for instance. > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > >-- > >Papadimitriou Dimitri > >E-mail : dimitri.papadimitriou@alcatel.be > >Website: http://www.rc.bel.alcatel.be/~papadimd/index.html > >Address: Alcatel - Optical NA, Fr. Wellesplein, 1 > > B-2018 Antwerpen, Belgium > >Phone: Work: +32 3 2408491 - Home: +32 2 3434361 > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 10:51:14 -0700 Message-Id: <4.3.2.7.2.20020501134202.05fc7ec0@sword.cisco.com> Date: Wed, 01 May 2002 13:47:05 -0400 To: "Don Fedyk", Yakov Rekhter From: Zafar Ali Subject: RE: TE metric and graceful restart Cc: Kireeti Kompella , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15224191==_.ALT" --=====================_15224191==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:01 PM 5/1/2002 -0400, Don Fedyk wrote: >Yakov, > >I think the text is correct since it is "should ... until it can determine >the amount of reserved..." Logically a node might never advertise zero >because it knows its resources. However, I do prefer *may* in place of the >first *should* which implies zero bandwidth advertisement is optional. Dear Yakov, I agree with Don. Switching the "should" to "may" will clarify the text greatly. Thanks Regards... Zafar >Thanks, >Don > > >Yakov Rekhter wrote: > > > > Don, > > > > > Kireeti, Zafer: > > > > > > I think that Zafer picked up on my earlier point that just because >routing > > > is gracefully restarting an implementation may have an independent > > > LSP system that can function just fine so why be forced to penalize > > > it? On the other hand, you may have an LSP system that is linked > > > to routing such it must restart as well and then I would agree that > > > zeroing bandwidth may well be necessary( but somewhat less "graceful"). > > > I'm not convinced changing Metrics is required at all. > > > > > > So I would agree with Zafer the wording should be such that either > > > case is allowed, > > > > Here is the current text: > > > > When a restarting node is going to originate its TE LSAs, the TE LSAs > > containing Link TLV should be originated with 0 unreserved bandwidth, > > and if the Link has LSC or FSC as its Switching Capability then also > > with 0 as Max LSP Bandwidth, until the node is able to determine the > > amount of unreserved resources taking into account the resources > > reserved by the already established LSPs that have been preserved > > across the restart. Once the restarting node determines the amount of > > unreserved resources, taking into account the resources reserved by > > the already established LSPs that have been preserved across the > > restart, the node should advertise these resources in its TE LSAs. > > > > First of all note that the node advertises 0 unreserved b/w > > *only* "until the node is able to determine the > > amount of unreserved resources taking into account the resources > > reserved by the already established LSPs that have been preserved > > across the restart." > > > > Second, note that originating TE LSA with 0 unreserved b/w > > is *should*, not *must*. > > > > With this in mind, don't you think that the text is ok ? > > Or do you still want to change "should" in the first sentence above > > into "may" ? > > > > Yakov. > > > > --=====================_15224191==_.ALT Content-Type: text/html; charset="us-ascii" At 01:01 PM 5/1/2002 -0400, Don Fedyk wrote:
Yakov,

I think the text is correct since it is "should ... until it can determine
the amount of reserved..." Logically a node might never advertise zero
because it knows its resources. However, I do prefer *may* in place of the
first *should* which implies zero bandwidth advertisement is optional. 

Dear Yakov,

I agree with Don. Switching the "should" to "may" will clarify the text greatly.

Thanks

Regards... Zafar


Thanks,
Don


Yakov Rekhter wrote:
>
> Don,
>
> > Kireeti, Zafer:
> >
> > I think that Zafer picked up on my earlier point that just because
routing
> > is gracefully restarting an implementation may have an independent
> > LSP system that can function just fine so why be forced to penalize
> > it? On the other hand, you may have an LSP system that is linked
> > to routing such it must restart as well and then I would agree that
> > zeroing bandwidth may well be necessary( but somewhat less "graceful").
> > I'm not convinced changing Metrics is required at all.
> >
> > So I would agree with Zafer the wording should be such that either
> > case is allowed,
>
> Here is the current text:
>
>    When a restarting node is going to originate its TE LSAs, the TE LSAs
>    containing Link TLV should be originated with 0 unreserved bandwidth,
>    and if the Link has LSC or FSC as its Switching Capability then also
>    with 0 as Max LSP Bandwidth, until the node is able to determine the
>    amount of unreserved resources taking into account the resources
>    reserved by the already established LSPs that have been preserved
>    across the restart. Once the restarting node determines the amount of
>    unreserved resources, taking into account the resources reserved by
>    the already established LSPs that have been preserved across the
>    restart, the node should advertise these resources in its TE LSAs.
>
> First of all note that the node advertises 0 unreserved b/w
> *only* "until the node is able to determine the
> amount of unreserved resources taking into account the resources
> reserved by the already established LSPs that have been preserved
> across the restart."
>
> Second, note that originating TE LSA with 0 unreserved b/w
> is *should*, not *must*.
>
> With this in mind, don't you think that the text is ok ?
> Or do you still want to change "should" in the first sentence above
> into "may" ?
>
> Yakov.
>
>
--=====================_15224191==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 10:02:19 -0700 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6022A46A3@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Yakov Rekhter Cc: Zafar Ali , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: TE metric and graceful restart Date: Wed, 1 May 2002 13:01:06 -0400 Yakov, I think the text is correct since it is "should ... until it can determine the amount of reserved..." Logically a node might never advertise zero because it knows its resources. However, I do prefer *may* in place of the first *should* which implies zero bandwidth advertisement is optional. Thanks, Don Yakov Rekhter wrote: > > Don, > > > Kireeti, Zafer: > > > > I think that Zafer picked up on my earlier point that just because routing > > is gracefully restarting an implementation may have an independent > > LSP system that can function just fine so why be forced to penalize > > it? On the other hand, you may have an LSP system that is linked > > to routing such it must restart as well and then I would agree that > > zeroing bandwidth may well be necessary( but somewhat less "graceful"). > > I'm not convinced changing Metrics is required at all. > > > > So I would agree with Zafer the wording should be such that either > > case is allowed, > > Here is the current text: > > When a restarting node is going to originate its TE LSAs, the TE LSAs > containing Link TLV should be originated with 0 unreserved bandwidth, > and if the Link has LSC or FSC as its Switching Capability then also > with 0 as Max LSP Bandwidth, until the node is able to determine the > amount of unreserved resources taking into account the resources > reserved by the already established LSPs that have been preserved > across the restart. Once the restarting node determines the amount of > unreserved resources, taking into account the resources reserved by > the already established LSPs that have been preserved across the > restart, the node should advertise these resources in its TE LSAs. > > First of all note that the node advertises 0 unreserved b/w > *only* "until the node is able to determine the > amount of unreserved resources taking into account the resources > reserved by the already established LSPs that have been preserved > across the restart." > > Second, note that originating TE LSA with 0 unreserved b/w > is *should*, not *must*. > > With this in mind, don't you think that the text is ok ? > Or do you still want to change "should" in the first sentence above > into "may" ? > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 09:43:48 -0700 Message-Id: <200205011635.g41GZsT36431@merlot.juniper.net> To: "Don Fedyk" cc: Zafar Ali , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: TE metric and graceful restart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72823.1020270954.1@juniper.net> Date: Wed, 01 May 2002 09:35:54 -0700 From: Yakov Rekhter Don, > Kireeti, Zafer: > > I think that Zafer picked up on my earlier point that just because routing > is gracefully restarting an implementation may have an independent > LSP system that can function just fine so why be forced to penalize > it? On the other hand, you may have an LSP system that is linked > to routing such it must restart as well and then I would agree that > zeroing bandwidth may well be necessary( but somewhat less "graceful"). > I'm not convinced changing Metrics is required at all. > > So I would agree with Zafer the wording should be such that either > case is allowed, Here is the current text: When a restarting node is going to originate its TE LSAs, the TE LSAs containing Link TLV should be originated with 0 unreserved bandwidth, and if the Link has LSC or FSC as its Switching Capability then also with 0 as Max LSP Bandwidth, until the node is able to determine the amount of unreserved resources taking into account the resources reserved by the already established LSPs that have been preserved across the restart. Once the restarting node determines the amount of unreserved resources, taking into account the resources reserved by the already established LSPs that have been preserved across the restart, the node should advertise these resources in its TE LSAs. First of all note that the node advertises 0 unreserved b/w *only* "until the node is able to determine the amount of unreserved resources taking into account the resources reserved by the already established LSPs that have been preserved across the restart." Second, note that originating TE LSA with 0 unreserved b/w is *should*, not *must*. With this in mind, don't you think that the text is ok ? Or do you still want to change "should" in the first sentence above into "may" ? Yakov. > > Don > -----Original Message----- > >From: Zafar Ali [mailto:zali@cisco.com] > >Sent: Sunday, April 28, 2002 1:53 AM > >To: Kireeti Kompella > >Cc: ccamp@ops.ietf.org > >Subject: RE: TE metric and graceful restart > > > > > >Dear Kireeti, > > > >Thanks for the reply; Please see comments in-lined. > > > >At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote: > > > > > >On Sat, 27 Apr 2002, Zafar Ali wrote: > > > >> The reason that I understood this as a MAY case is that a node that saves > >> bandwidth usage state information locally is able to determine (or > >> estimate) the amount of unreserved resources immediately upon start-up. > In > >> which case it MAY advertise the saved (projected) value(s) during the > >> graceful restart period. > > > >Attractive as that may be, life is not so simple. The process of > >recovery for signaling is complex enough without having new LSPs set > >up during recovery. The idea of discouraging LSPs during recovery is > >not just that the recovering node doesn't know its unreserved bandwidth, > >but that it wants to complete recovery before setting up new LSPs. > > > >A simple example is that the recovering node X uses per-box labels, > >gets a new LSP request while recovering, and allocates label L to that > >request. But L is already in use for an existing LSP .... > >One can > >work around this particular example, but keeping it simple seems like > >a good initial goal. > > > >Agreed! As I also mentioned that in doing so the node looses the charm > >of discouraging other nodes in the network > >in using it, during the restart period. This opens doors for some > >potential race conditions and >scenarios like the one you mentioned > >in the email. Of course, a node that may choose to do so >has to deal > >with kind of scenarios that you mentioned in the email. I see that > >there are some tradeoffs involved and the standard should leave a > >room for exercising such options. Hence, IMO this should be a local > >(vendor specific) decision. > > > >In short, while I am agreeing with the recommendation, I think the > >"SHOULD" part should be >>removed and the standard should leave it as > >part of the local decision. > > > >Thanks > > > >Regards... Zafar > > > >> > >> > >>At least, that's my take. > >> > >>Kireeti. > > ------_=_NextPart_001_01C1EFB2.8A7BC48E > Content-Type: text/html; > charset="iso-8859-1" > > > > > > > RE: TE metric and graceful restart > > > >

Kireeti, Zafer: >

> >

I think that Zafer picked up on my earlier point that just be cause routing >
is gracefully restarting an implementation may have an indep endent >
LSP system that can function just fine so why be forced to p enalize >
it? On the other hand, you may have an LSP system that is li nked >
to routing such it must restart as well and then I would agr ee that >
zeroing bandwidth may well be necessary( but somewhat less & quot;graceful"). >
I'm not convinced changing Metrics is required at all. >

> >

So I would agree with Zafer the wording should be such that e ither >
case is allowed, >

> >

Don  >
-----Original Message----- >
>From: Zafar Ali [mailto: zali@cisco.com] >
>Sent: Sunday, April 28, 2002 1:53 AM >
>To: Kireeti Kompella >
>Cc: ccamp@ops.ietf.org >
>Subject: RE: TE metric and graceful restart >
> >
> >
>Dear Kireeti, >
> >
>Thanks for the reply; Please see comments in-lined. >
> >
>At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote: >
> >
> >
>On Sat, 27 Apr 2002, Zafar Ali wrote: >
> >
>> The reason that I understood this as a MAY case is that a node that saves >
>> bandwidth usage state information locally is able t o determine (or >
>> estimate) the amount of unreserved resources immedi ately upon start-up. In >
>> which case it MAY advertise the saved (projected) v alue(s) during the >
>> graceful restart period. >
> >
>Attractive as that may be, life is not so simple.  The process of >
>recovery for signaling is complex enough without having new LSPs set >
>up during recovery.  The idea of discouraging LSPs during recovery is >
>not just that the recovering node doesn't know its unres erved bandwidth, >
>but that it wants to complete recovery before setting up new LSPs. >
> >
>A simple example is that the recovering node X uses per- box labels, >
>gets a new LSP request while recovering, and allocates l abel L to that >
>request.  But L is already in use for an existing L SP ....  >
>One can >
>work around this particular example, but keeping it simp le seems like >
>a good initial goal. >
> >
>Agreed! As I also mentioned that in doing so the node lo oses the charm >
>of discouraging other nodes in the network >
>in using it, during the restart period. This opens doors for some >
>potential race conditions and >scenarios like the one you mentioned >
>in the email. Of course, a node that may choose to do so >has to deal >
>with kind of scenarios that you mentioned in the email. I see that >
>there are some tradeoffs involved and the standard shoul d leave a >
>room for exercising such options. Hence, IMO this should be a local >
>(vendor specific) decision. >
> >
>In short, while I am agreeing with the recommendation, I think the >
>"SHOULD" part should be >>removed and th e standard should leave it as >
>part of the local decision. >
> >
>Thanks >
> >
>Regards... Zafar >
> >
>> >
>> >
>>At least, that's my take. >
>> >
>>Kireeti. >

> > > > ------_=_NextPart_001_01C1EFB2.8A7BC48E-- > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 05:15:43 -0700 Message-ID: <3CCFCDDA.C222EA80@alcatel.be> Date: Wed, 01 May 2002 13:13:30 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org Subject: Re: Profile parameter in SDH/SONET traffic Params Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii manoj, manoj juneja wrote: > > [ post by non-subscriber ] > > Hi All, > In the new version of the draft > draft-ietf-ccamp-gmpls-sonet-sdh-04.txt, a new parameter named "Profile" has > been added in SDH/SONET traffic parameters. As OIF's O-UNI is also using > this parameter, does this mean that this parameter got changed for O-UNI > requirements also ? can you indicate where oif uni use a profile parameter ? the oif o-uni as you call is based on gmpls signalling so the next question is some how confusing ... wouldn't be possible to be a little bit more accurate ? > If this parameter is required only for GMPLS, please indicate that too. > > I think OIF's O-UNI makes a reference to this ccamp draft. yes (as mentioned here above) but what's the point ? > Please help me in understanding this issue. there is nothing very mystic to understand here it simply a "field" that will enable to have a finer connection profile with respect to monitoring capabilities for instance. > Regards, > manoj. > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 05:06:10 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CCFD9BE.24A263F9@lucent.com> Date: Wed, 01 May 2002 14:04:14 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: ccamp@ops.ietf.org Subject: Re: Question on LMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, Could you please make clear in the LMP draft that 1. "control channels" are established *over* a "control network". 2. Not all signaling messages (example: the RSVP-TE notify message) are sent over "control channels". If this could be added in the LMP draft, I would not have become confused on the relation between "control channels" and "control network". Examples of text in the LMP draft that caused my confusion: - Chapter 1: "To enable communication between nodes for routing, signaling, and link management, control channels must be established between the node pair ..." Why the "must" in this sentence ? I would think that communication is perfectly well possible over the "control network", not using "control channels" ? - Chapter 2: "One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes." This sentence seems to go in the direction of a kind of multi- link PPP protocol (L2). At least it made me believe that the control network is built on top of control channels - a thought that apparently is wrong. - Chapter 2: "... the control channel MUST terminate on the same two nodes that the TE link spans" I could only understand this sentence assuming "control channels" are a kind of L2 technique. What does "terminate" in this sentence imply ? Is something more happening than the standard TCP/UDP termination to packets that are sent over control channels? - Chapter 3: "The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link- state adjacencies are not removed unnecessarily." Again, I could only understand this sentence assuming "control channels" are a kind of L2 technique. Is it possible to be more precise on what "IGP" is meant here (see also http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00657.html). Could you please also indicate that "control channel management" does *not* need to be fast (O(mseconds)) ? See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00700.html. Looking back through this thread, I think at least the following two questions are still open: 1. What does the control channel management achieve? a. IP reachability confirmation. b. Negotiation of Hello and Dead intervals. http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00653.html 2. Is there a mandatory need to distinguish between a failure of the RSVP-TE process and a failure of the LMP process ? http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html You wrote: > standard "ping" only tells you reachability. It does not tell you if the LMP > component is functioning or not. This is similar to why Hellos are used in > other protocols (e.g., RSVP Hello). I'm not sure why we need *both* RSVP-TE Hellos as well as LMP hellos. See also question 2 above. Thanks, Michiel Jonathan Lang wrote: > > Michiel, > > > > > > If "control channels" are nothing more than the standard "ping" mechanism, > > why not use this standard "ping" mechanism ? > > If "control channels" does provide more than standard "ping", could you > > please let me know what that would be (and why that would be mandatorily > > needed) ? > standard "ping" only tells you reachability. It does not tell you if the LMP > component is functioning or not. This is similar to why Hellos are used in > other protocols (e.g., RSVP Hello). > > Thanks, > Jonathan > > > > > I think I first need clarity on the relation between "control > > network" and > > "control channel" before being able to comment on your other points. > > > > > > Thanks ! > > > > Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 04:52:06 -0700 Date: Wed, 1 May 2002 04:49:40 -0700 (PDT) From: Kireeti Kompella Message-Id: <200205011149.g41BneG33790@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Signaling documents ... Cc: mpls@uu.net FYI: CCAMP & MPLS WG Last Call has completed on the Generalized Signaling documents, i.e.: draft-ietf-mpls-generalized-cr-ldp-06.txt draft-ietf-mpls-generalized-rsvp-te-07.txt draft-ietf-mpls-generalized-signaling-08.txt and they have been handed over to the ADs for IESG consideration as Proposed Standards. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 01 May 2002 00:32:16 -0700 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , ccamp@ops.ietf.org Subject: AW: {SUKLM} Changes in new draft Date: Wed, 1 May 2002 09:27:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Manoj, see my comments below. Juergen > -----Urspr=FCngliche Nachricht----- > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Gesendet: Dienstag, 30. April 2002 20:29 > An: ccamp@ops.ietf.org > Betreff: {SUKLM} Changes in new draft >=20 >=20 > [ post by non-subscriber ] >=20 > Hi All, > In the newly released draft=20 > draft-ietf-ccamp-gmpls-sonet-sdh-04.txt,=20 > the interpretation of S field in the {SUKLM} structure looks=20 > to be different=20 > than was present in earlier draft=20 > draft-ietf-ccamp-gmpls-sonet-sdh-03.txt. >=20 > The definition in 04 version is : >=20 > 1. S=3D1->N is the index of a particular AUG-1/STS-3 inside an > STM-N/STS-N multiplex. S is only significant for SDH STM-N (N>0) > and SONET STS-N (N>1) and must be 0 and ignored for STM-0 and > STS-1. >=20 >=20 > The definition in 03 version is : >=20 > 1. S is only significant for SDH STM-N (N>0) and SONET. It must > be ignored for STM-0. S is the index of a particular AUG-1/STS- > 1. S=3D1->N indicates a specific AUG-1/STS-1 inside an = STM-N/STS-N > multiplex. For example, S=3D1 indicates the first AUG-1/STS-1, = and > S=3DN indicates the last AUG-1/STS-1 of this multiplex. >=20 > With the old version of the document, if I need to represent=20 > say Xth (X<=3DN)=20 > VC-4 in STM-N multiplex then the label value is {X, 1, 0, 0}.=20 > What will be=20 > this representation as per 04-version ? The label will be {X,0,0,0} >=20 > Can someone please explain that what was the reason for this=20 > change ? What=20 > will be the advantage of this approach ? >=20 The change were introduced in order to have the same SUKLM coding for = SDH and SONET, so the Xth VC-4 in a STM-N and the Xth STS-3-SPE in a = STS-3n have both a label of {X,0,0,0} =20 > Regards, > manoj. >=20 > _________________________________________________________________ > Get your FREE download of MSN Explorer at=20 http://explorer.msn.com/intl.asp.