Subject: RE: LMP & neighbor discovery
From: "Bernstein, Greg" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "'Jonathan Lang'" <[email-masked]>, "'Martin Dubuc'" <[email-masked]>, Michiel van Everdingen <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Fri, 31 May 2002 14:58:53 -0700

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:[email-masked]]
Sent: Friday, May 31, 2002 2:29 PM
To: Bernstein, Greg
Cc: 'Jonathan Lang'; 'Martin Dubuc'; Michiel van Everdingen; Kireeti
Kompella; [email-masked]
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.

Delivery-date: Fri, 31 May 2002 14:48:47 -0700
From: Anoop Ghanwani <[email-masked]>
To: [email-masked]
Subject: A question on draft-ietf-ccamp-gmpls-architecture-02.txt
Date: Fri, 31 May 2002 14:37:20 -0700

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

Delivery-date: Fri, 31 May 2002 14:30:19 -0700
To: "Bernstein, Greg" <[email-masked]>
cc: "'Jonathan Lang'" <[email-masked]>, "'Martin Dubuc'" <[email-masked]>, Michiel van Everdingen <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: LMP & neighbor discovery 
Date: Fri, 31 May 2002 14:28:53 -0700
From: Yakov Rekhter <[email-masked]>

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.

Delivery-date: Fri, 31 May 2002 13:42:52 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "'Martin Dubuc'" <[email-masked]>, Michiel van Everdingen <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery
Date: Fri, 31 May 2002 13:40:41 -0700

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:[email-masked]]
Sent: Friday, May 31, 2002 12:15 PM
To: Bernstein, Greg; 'Martin Dubuc'; Michiel van Everdingen; Kireeti
Kompella
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery

Greg,
 
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 10:14 AM
> To: 'Martin Dubuc'; Michiel van Everdingen; Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, May 30, 2002 6:41 AM
> To: Michiel van Everdingen; Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, May 30, 2002 7:31 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]  |
> +------------------------------------------------------------------+
> 
> 
> 

Delivery-date: Fri, 31 May 2002 12:25:03 -0700
From: Jonathan Lang <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, 'Martin Dubuc' <[email-masked]>, Michiel van Everdingen <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery
Date: Fri, 31 May 2002 12:15:03 -0700

Greg,
 
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 10:14 AM
> To: 'Martin Dubuc'; Michiel van Everdingen; Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, May 30, 2002 6:41 AM
> To: Michiel van Everdingen; Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, May 30, 2002 7:31 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]  |
> +------------------------------------------------------------------+
> 
> 
> 

Delivery-date: Fri, 31 May 2002 11:48:33 -0700
Date: Fri, 31 May 2002 20:47:30 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: "Bernstein, Greg" <[email-masked]>
Cc: "'Martin Dubuc'" <[email-masked]>, Michiel van Everdingen <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: LMP & neighbor discovery

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:[email-masked]]
> Sent: Thursday, May 30, 2002 6:41 AM
> To: Michiel van Everdingen; Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, May 30, 2002 7:31 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> 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:[email-masked]  |
> +------------------------------------------------------------------+

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
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

Delivery-date: Fri, 31 May 2002 11:02:54 -0700
Date: Fri, 31 May 2002 11:01:18 -0700
From: Sudheer Dharanikota <[email-masked]>
To: [email-masked]
CC: Zhi-Wei Lin <[email-masked]>, Suresh Katukam <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Sonet Ring provisioning

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:[email-masked]]
> > Sent: Friday, May 31, 2002 10:32 AM
> > To: [email-masked]
> > 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: [email-masked] [mailto:[email-masked]]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
> > >
> > > >

Delivery-date: Fri, 31 May 2002 10:49:55 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Sudheer Dharanikota" <[email-masked]>
Cc: "Zhi-Wei Lin" <[email-masked]>, "Suresh Katukam" <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp \(E-mail\)" <[email-masked]>, "mpls@UU. NET \(E-mail\)" <[email-masked]>
Subject: RE: Sonet Ring provisioning
Date: Fri, 31 May 2002 10:54:34 -0700

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:[email-masked]]
> Sent: Friday, May 31, 2002 10:32 AM
> To: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]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
> >
> > >

Delivery-date: Fri, 31 May 2002 10:35:07 -0700
Date: Fri, 31 May 2002 10:34:33 -0700
From: Suresh Katukam <[email-masked]>
Organization: Cisco Systems
To: [email-masked]
CC: Zhi-Wei Lin <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Sonet Ring provisioning

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
> 
> >

Delivery-date: Fri, 31 May 2002 10:33:30 -0700
Date: Fri, 31 May 2002 10:31:45 -0700
From: Sudheer Dharanikota <[email-masked]>
To: [email-masked]
CC: Zhi-Wei Lin <[email-masked]>, Suresh Katukam <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
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: [email-masked] [mailto:[email-masked]]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
>
> >

Delivery-date: Fri, 31 May 2002 10:14:55 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>, Michiel van Everdingen <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery
Date: Fri, 31 May 2002 10:13:50 -0700

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:[email-masked]]
Sent: Thursday, May 30, 2002 6:41 AM
To: Michiel van Everdingen; Kireeti Kompella
Cc: [email-masked]
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:[email-masked]]
Sent: Thursday, May 30, 2002 7:31 AM
To: Kireeti Kompella
Cc: [email-masked]
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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Fri, 31 May 2002 09:45:33 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>, "Suresh Katukam" <[email-masked]>
Cc: "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp \(E-mail\)" <[email-masked]>, "mpls@UU. NET \(E-mail\)" <[email-masked]>
Subject: RE: Sonet Ring provisioning
Date: Fri, 31 May 2002 09:49:33 -0700

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: [email-masked] [mailto:[email-masked]]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: [email-masked]
Delivery-date: Fri, 31 May 2002 06:32:21 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Cheng-Yin Lee" <[email-masked]>
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: <[email-masked]>
To: <IETF-Announce: ;>
Cc: <[email-masked]>
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

Delivery-date: Fri, 31 May 2002 05:47:49 -0700
Cc: Zhi-Wei Lin <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Date: Fri, 31 May 2002 14:45:54 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Suresh Katukam <[email-masked]>
Original-CC: Zhi-Wei Lin <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Sonet Ring provisioning

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" <[email-masked]>
> > >To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
> > ><[email-masked]>
> > >Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
> > >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:[email-masked]]
> > >>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:[email-masked]
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--

Delivery-date: Fri, 31 May 2002 04:23:30 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 31 May 2002 04:23:23 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 31 May 2002 03:01:49 -0700
Cc: [email-masked]
Date: Fri, 31 May 2002 11:59:22 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Martin Dubuc <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP & neighbor discovery

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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Fri, 31 May 2002 01:02:00 -0700
Cc: "'Nik Langrind'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, "R. Muralidharan" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Date: Fri, 31 May 2002 09:59:48 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: "'Nik Langrind'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, "R. Muralidharan" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Sonet Ring provisioning

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:[email-masked]]
> 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:[email-masked]]
> > 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" <[email-masked]>
> > >To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
> > ><[email-masked]>
> > >Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
> > >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:[email-masked]]
> > >>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:[email-masked]
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--

Delivery-date: Thu, 30 May 2002 11:54:49 -0700
Date: Thu, 30 May 2002 14:54:21 -0400
From: Zhi-Wei Lin <[email-masked]>
To: Suresh Katukam <[email-masked]>
CC: "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
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)

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" <[email-masked]>
>>>To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
>>><[email-masked]>
>>>Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
>>>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:[email-masked]]
>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>

Delivery-date: Thu, 30 May 2002 11:24:45 -0700
Date: Thu, 30 May 2002 11:23:01 -0700
From: Suresh Katukam <[email-masked]>
Organization: Cisco Systems
To: Zhi-Wei Lin <[email-masked]>
CC: "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Sonet Ring provisioning

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" <[email-masked]>
> >To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
> ><[email-masked]>
> >Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
> >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:[email-masked]]
> >>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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >

Delivery-date: Thu, 30 May 2002 09:59:10 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Nik Langrind'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, "R. Muralidharan" <[email-masked]>
Cc: "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Sonet Ring provisioning
Date: Thu, 30 May 2002 09:56:28 -0700

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:[email-masked]]
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:[email-masked]]
> 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" <[email-masked]>
> >To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
> ><[email-masked]>
> >Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
> >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:[email-masked]]
> >>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
> >>
> >>
> >>
> >>
> >>
> >>    
> >>
> >
> >  
> >
> 
> 

Delivery-date: Thu, 30 May 2002 07:07:04 -0700
From: Nik Langrind <[email-masked]>
To: "'Zhi-Wei Lin'" <[email-masked]>, "R. Muralidharan" <[email-masked]>
Cc: "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Sonet Ring provisioning
Date: Thu, 30 May 2002 10:05:45 -0400

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:[email-masked]]
> 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" <[email-masked]>
> >To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
> ><[email-masked]>
> >Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
> >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:[email-masked]]
> >>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
> >>
> >>
> >>
> >>
> >>
> >>    
> >>
> >
> >  
> >
> 
> 

Delivery-date: Thu, 30 May 2002 06:45:22 -0700
content-class: urn:content-classes:message
Subject: RE: LMP & neighbor discovery
Date: Thu, 30 May 2002 09:41:15 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Michiel van Everdingen" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]
Sent: Thursday, May 30, 2002 7:31 AM
To: Kireeti Kompella
Cc: [email-masked]
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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Thu, 30 May 2002 05:21:30 -0700
Date: Thu, 30 May 2002 08:20:20 -0400
From: Zhi-Wei Lin <[email-masked]>
To: "R. Muralidharan" <[email-masked]>
CC: "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
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" <[email-masked]>
>To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
><[email-masked]>
>Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
>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:[email-masked]]
>>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
>>
>>
>>
>>
>>
>>    
>>
>
>  
>

Delivery-date: Thu, 30 May 2002 04:33:15 -0700
Cc: [email-masked]
Date: Thu, 30 May 2002 13:31:15 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
Original-CC: [email-masked]
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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Thu, 30 May 2002 02:14:58 -0700
From: "R. Muralidharan" <[email-masked]>
To: "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
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" <[email-masked]>
To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
<[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
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:[email-masked]]
> 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
>
>
>
>
>

Delivery-date: Wed, 29 May 2002 10:01:49 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Sonet Ring provisioning
Date: Wed, 29 May 2002 09:58:02 -0700

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:[email-masked]]
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

      

Delivery-date: Wed, 29 May 2002 03:56:19 -0700
Date: Wed, 29 May 2002 03:53:57 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Michiel van Everdingen <[email-masked]>
cc: <[email-masked]>
Subject: Re: LMP & neighbor discovery

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.

Delivery-date: Tue, 28 May 2002 16:32:25 -0700
Date: Tue, 28 May 2002 19:24:27 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: gmpls signaling survey update

	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

Delivery-date: Tue, 28 May 2002 03:37:38 -0700
Date: Tue, 28 May 2002 16:03:05 +0530
From: Vinay Vernekar <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Identifying a kind of LSP in GMPLS.

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

Delivery-date: Mon, 27 May 2002 06:06:48 -0700
Date: Mon, 27 May 2002 09:00:27 -0400
To: "Michael I Mandelberg(Isaac)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Link Bundle MIB is AWOL
Cc: [email-masked]

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. 

Delivery-date: Fri, 24 May 2002 04:23:36 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 23 May 2002 15:47:59 -0700
From: "Michael I Mandelberg(Isaac)" <[email-masked]>
To: [email-masked]
Subject: Link Bundle MIB is AWOL
Date: Thu, 23 May 2002 18:42:36 -0400

I can't seem to get the latest version of the Link Bundle MIB from the IETF
site. Is it available?

Thanks

Michael Mandelberg

Delivery-date: Thu, 23 May 2002 09:23:22 -0700
Date: Thu, 23 May 2002 12:21:02 -0400
To: "Liran Siglat" <[email-masked]>, <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: RE: IGPs and LMP's TE-link

--=====================_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:[email-masked]]
>Sent: Wednesday, May 22, 2002 8:40 PM
>To: Liran Siglat; [email-masked]
>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: [email-masked]

--=====================_8045198==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 09:33 AM 5/23/2002 +0300, Liran Siglat wrote:<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Hi,</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">I'll try to clarify the
question with an example:</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">We have 4 data-links
a,b,c,d. </font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">We define 2 TE-links:
TEL1 containing a&amp;b, TEL2 containing
c&amp;d.</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Which components may the
UNI use? for which purposes?</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Which components may the
IGP use? for which purposes?</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Which components may the
TE engine use for CSPF? for which purposes?</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Which 'logical'
interfaces will the local UNI-C have towards the remote UNI-C? a,b,c
&amp;d or TEL1 &amp; TEL2?</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">Thanks,
Liran.</font></blockquote><br>
<font size=3>Hi Liran, <br>
<br>
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. <br>
<br>
Thanks<br>
<br>
Regards... Zafar&nbsp; <br>
</font><blockquote type=cite cite>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Zafar Ali
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 22, 2002 8:40 PM
<dd>To:</b> Liran Siglat; [email-masked]
<dd>Subject:</b> Re: IGPs and LMP's TE-link<br>
<br>
</font><font size=3>
<dd>Dear Liran, <br>
<br>

<dd>BTW, I've found your questions rather confusing. Any way, the
following are the related comments, 
</dl>
<ul>
<li>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). 
<li>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. 
<li>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. 
</ul>Hope this helps. <br>
<br>
Thanks<br>
<br>
Regards... Zafar&nbsp; <br>
<br>
At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
I have a question regarding the way LMP's TE-link is observed by
IGPs.<br>
<br>
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) ?</blockquote><br>
===============================================<br>
Zafar Ali<br>
Cisco Systems<br>
100 S Main St. #200<br>
Ann Arbor, MI 48104</u>.<br>
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190<br>
email: </font><font size=3 color="#0000FF">[email-masked]</u></font>
<br>
</blockquote></html>

--=====================_8045198==_.ALT--

Delivery-date: Thu, 23 May 2002 05:54:35 -0700
To: Ron Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: [email-masked], Scott Bradner <[email-masked]>, Bert Wijnen <[email-masked]>
Date: Thu, 23 May 2002 14:51:48 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
Original-To: Ron Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, Jonathan Lang <[email-masked]>
Original-CC: [email-masked], Scott Bradner <[email-masked]>, Bert Wijnen <[email-masked]>
Subject: Re: LMP & neighbor discovery

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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Wed, 22 May 2002 23:33:38 -0700
content-class: urn:content-classes:message
Subject: RE: IGPs and LMP's TE-link
Date: Thu, 23 May 2002 09:33:08 +0300
From: "Liran Siglat" <[email-masked]>
To: "Zafar Ali" <[email-masked]>, <[email-masked]>

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:[email-masked]]
Sent: Wednesday, May 22, 2002 8:40 PM
To: Liran Siglat; [email-masked]
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: [email-masked]=20

------_=_NextPart_001_01C20223.B3C6599B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D547113006-23052002>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D547113006-23052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D547113006-23052002>I'll=20
try to clarify the question with an example:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D547113006-23052002></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D547113006-23052002>
<DIV><SPAN class=3D201192006-23052002><FONT color=3D#0000ff face=3DArial =
size=3D2>We=20
have 4 data-links a,b,c,d. </FONT></SPAN></DIV>
<DIV><SPAN class=3D201192006-23052002><FONT color=3D#0000ff face=3DArial =
size=3D2>We=20
define 2 TE-links: TEL1 containing a&amp;b, TEL2&nbsp;containing=20
c&amp;d.</FONT></SPAN></DIV>
<DIV><SPAN class=3D201192006-23052002><FONT color=3D#0000ff face=3DArial =
size=3D2>Which=20
components&nbsp;<SPAN class=3D547113006-23052002>may </SPAN>the =
UNI&nbsp;use? for=20
which purposes?</FONT></SPAN></DIV>
<DIV><SPAN class=3D201192006-23052002><FONT color=3D#0000ff face=3DArial =
size=3D2>Which=20
components&nbsp;<SPAN class=3D547113006-23052002>may </SPAN>the =
IGP&nbsp;use? for=20
which purposes?</FONT></SPAN></DIV>
<DIV><SPAN class=3D201192006-23052002><FONT color=3D#0000ff face=3DArial =
size=3D2>Which=20
components&nbsp;<SPAN class=3D547113006-23052002>may </SPAN>the TE =
engine&nbsp;use=20
for CSPF? for which purposes?</FONT></SPAN></DIV>
<DIV><SPAN class=3D201192006-23052002><FONT color=3D#0000ff face=3DArial =
size=3D2>Which=20
'logical' interfaces&nbsp;<SPAN class=3D547113006-23052002>will =
</SPAN>the local=20
UNI-C&nbsp;have towards the remote UNI-C? a,b,c &amp;d or TEL1 &amp;=20
TEL2?</FONT></SPAN></DIV>
<DIV><SPAN class=3D201192006-23052002></SPAN>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D201192006-23052002><SPAN=20
class=3D547113006-23052002>Thanks, =
Liran.</SPAN></SPAN></FONT></DIV></SPAN></DIV>
<BLOCKQUOTE>
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Zafar Ali=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 22, 2002 8:40=20
  PM<BR><B>To:</B> Liran Siglat; [email-masked]<BR><B>Subject:</B> =
Re: IGPs=20
  and LMP's TE-link<BR><BR></DIV></FONT><FONT size=3D3>Dear Liran, =
<BR><BR>BTW,=20
  I've found your questions rather confusing. Any way, the following are =
the=20
  related comments,=20
  <UL>
    <LI>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
    <LI>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
    <LI>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
  </LI></UL>Hope this helps. <BR><BR>Thanks<BR><BR>Regards... =
Zafar&nbsp;=20
  <BR><BR>At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote:<BR>
  <BLOCKQUOTE cite type=3D"cite">Hi,<BR><BR>I have a question regarding =
the way=20
    LMP's TE-link is observed by IGPs.<BR><BR>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
  =
?</BLOCKQUOTE><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<BR>Zafar=20
  Ali<BR>Cisco Systems<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI=20
  48104</U>.<BR>Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734)=20
  302-4190<BR>email: </FONT><FONT color=3D#0000ff=20
  size=3D3><U>[email-masked]</FONT></U> </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C20223.B3C6599B--

Delivery-date: Wed, 22 May 2002 23:18:22 -0700
content-class: urn:content-classes:message
Subject: LMP's TE-link FSM
Date: Thu, 23 May 2002 09:15:44 +0300
From: "Liran Siglat" <[email-masked]>
To: <[email-masked]>

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.

Delivery-date: Wed, 22 May 2002 14:57:02 -0700
From: "Juneja, Manoj" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, manoj juneja<[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Notify Message Doubt
Date: Wed, 22 May 2002 14:55:37 -0700

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:[email-masked]]
Sent: Wednesday, May 22, 2002 2:30 PM
To: manoj juneja; [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of manoj juneja
> Sent: Wednesday, May 22, 2002 1:59 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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" <[email-masked]>
> >Reply-To: <[email-masked]>
> >To: "manoj juneja" <[email-masked]>,
> ><[email-masked]>
> >CC: <[email-masked]>
> >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: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of manoj juneja
> > > Sent: Wednesday, May 22, 2002 10:54 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > 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" <[email-masked]>
> > > >To: "manoj juneja" <[email-masked]>
> > > >CC: <[email-masked]>
> > > >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: [email-masked]
> > > >
> > > > >-----Original Message-----
> > > > >From: manoj juneja [mailto:[email-masked]]
> > > > >Sent: Tuesday, May 21, 2002 6:52 PM
> > > > >To: [email-masked]
> > > > >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
>

Delivery-date: Wed, 22 May 2002 14:23:35 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Notify Message Doubt
Date: Wed, 22 May 2002 14:29:43 -0700

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of manoj juneja
> Sent: Wednesday, May 22, 2002 1:59 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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" <[email-masked]>
> >Reply-To: <[email-masked]>
> >To: "manoj juneja" <[email-masked]>,
> ><[email-masked]>
> >CC: <[email-masked]>
> >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: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of manoj juneja
> > > Sent: Wednesday, May 22, 2002 10:54 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > 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" <[email-masked]>
> > > >To: "manoj juneja" <[email-masked]>
> > > >CC: <[email-masked]>
> > > >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: [email-masked]
> > > >
> > > > >-----Original Message-----
> > > > >From: manoj juneja [mailto:[email-masked]]
> > > > >Sent: Tuesday, May 21, 2002 6:52 PM
> > > > >To: [email-masked]
> > > > >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
>

Delivery-date: Wed, 22 May 2002 13:59:01 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Notify Message Doubt
Date: Wed, 22 May 2002 13:58:47 -0700

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" <[email-masked]>
>Reply-To: <[email-masked]>
>To: "manoj juneja" <[email-masked]>, 
><[email-masked]>
>CC: <[email-masked]>
>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: [email-masked] [mailto:[email-masked]]On
> > Behalf Of manoj juneja
> > Sent: Wednesday, May 22, 2002 10:54 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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" <[email-masked]>
> > >To: "manoj juneja" <[email-masked]>
> > >CC: <[email-masked]>
> > >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: [email-masked]
> > >
> > > >-----Original Message-----
> > > >From: manoj juneja [mailto:[email-masked]]
> > > >Sent: Tuesday, May 21, 2002 6:52 PM
> > > >To: [email-masked]
> > > >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

Delivery-date: Wed, 22 May 2002 13:56:51 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
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 <draft-ietf-mpls-generalized-cr-ldp-06.txt> 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 
	<draft-ietf-mpls-generalized-rsvp-te-07.txt>
o Generalized MPLS - Signaling Functional Description 
	<draft-ietf-mpls-generalized-signaling-08.txt>

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 
[email-masked] or [email-masked] 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 

Delivery-date: Wed, 22 May 2002 11:24:04 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of manoj juneja
> Sent: Wednesday, May 22, 2002 10:54 AM
> To: [email-masked]
> Cc: [email-masked]
> 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" <[email-masked]>
> >To: "manoj juneja" <[email-masked]>
> >CC: <[email-masked]>
> >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: [email-masked]
> >
> > >-----Original Message-----
> > >From: manoj juneja [mailto:[email-masked]]
> > >Sent: Tuesday, May 21, 2002 6:52 PM
> > >To: [email-masked]
> > >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.

Delivery-date: Wed, 22 May 2002 11:20:07 -0700
content-class: urn:content-classes:message
Subject: RE: Notify Message Doubt
Date: Wed, 22 May 2002 14:17:19 -0400
From: "George Young" <[email-masked]>
To: "manoj juneja" <[email-masked]>
Cc: <[email-masked]>

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: [email-masked]

>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Wednesday, May 22, 2002 1:54 PM
>To: George Young
>Cc: [email-masked]
>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" <[email-masked]>
>>To: "manoj juneja" <[email-masked]>
>>CC: <[email-masked]>
>>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: [email-masked]
>>
>> >-----Original Message-----
>> >From: manoj juneja [mailto:[email-masked]]
>> >Sent: Tuesday, May 21, 2002 6:52 PM
>> >To: [email-masked]
>> >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.
>
>

Delivery-date: Wed, 22 May 2002 10:55:12 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Notify Message Doubt
Date: Wed, 22 May 2002 10:54:09 -0700

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" <[email-masked]>
>To: "manoj juneja" <[email-masked]>
>CC: <[email-masked]>
>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: [email-masked]
>
> >-----Original Message-----
> >From: manoj juneja [mailto:[email-masked]]
> >Sent: Tuesday, May 21, 2002 6:52 PM
> >To: [email-masked]
> >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.

Delivery-date: Wed, 22 May 2002 10:40:55 -0700
Date: Wed, 22 May 2002 13:39:43 -0400
To: "Liran Siglat" <[email-masked]>, <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: IGPs and LMP's TE-link

--=====================_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: [email-masked]
--=====================_10977685==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Dear Liran, <br>
<br>
BTW, I've found your questions rather confusing. Any way, the following
are the related comments, 
<ul>
<li>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). 
<li>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. 
<li>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.  
</ul>Hope this helps. <br>
<br>
Thanks<br>
<br>
Regards... Zafar&nbsp; <br>
<br>
At 08:06 PM 5/22/2002 +0300, Liran Siglat wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
I have a question regarding the way LMP's TE-link is observed by
IGPs.<br>
<br>
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) ?</blockquote><br>
===============================================<br>
Zafar Ali<br>
Cisco Systems<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
Mobile: (734) 276-2459, Off: (734) 302-4143, Fax: (734) 302-4190<br>
email:
</font><font size=3 color="#0000FF"><u>[email-masked]</font></u></html>

--=====================_10977685==_.ALT--

Delivery-date: Wed, 22 May 2002 10:09:35 -0700
content-class: urn:content-classes:message
Subject: IGPs and LMP's TE-link
Date: Wed, 22 May 2002 20:06:08 +0300
From: "Liran Siglat" <[email-masked]>
To: <[email-masked]>

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) ?

Delivery-date: Wed, 22 May 2002 06:35:13 -0700
content-class: urn:content-classes:message
Subject: RE: Notify Message Doubt
Date: Wed, 22 May 2002 09:30:32 -0400
From: "George Young" <[email-masked]>
To: "manoj juneja" <[email-masked]>
Cc: <[email-masked]>

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: [email-masked]

>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Tuesday, May 21, 2002 6:52 PM
>To: [email-masked]
>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
>
>
>

Delivery-date: Tue, 21 May 2002 22:23:35 -0700
From: "Raju Venkatraman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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

Delivery-date: Tue, 21 May 2002 15:52:59 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Notify Message Doubt
Date: Tue, 21 May 2002 15:52:12 -0700

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

Delivery-date: Tue, 21 May 2002 15:10:47 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: TE metric and graceful restart
Date: Tue, 21 May 2002 18:02:57 -0400

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.

Delivery-date: Tue, 21 May 2002 06:41:38 -0700
Date: Tue, 21 May 2002 09:36:45 -0400
From: Dave McDysan <[email-masked]>
Subject: MPLS 2002: Oct. 27-29, Washington D.C.
To: Ppvpn <[email-masked]>, Ccamp <[email-masked]>, Mpls <[email-masked]>, Pwe3 <[email-masked]>
Cc: [email-masked]

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 [email-masked] 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

Delivery-date: Mon, 20 May 2002 02:59:13 -0700
Date: Mon, 20 May 2002 11:56:04 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: venkat <[email-masked]>
CC: [email-masked]
Subject: Re: Label Set Object/Tlv

see inline

Venkat Dabbara wrote:
> 
> comments inline.........
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: "venkat" <[email-masked]>
> Cc: <[email-masked]>
> 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 : [email-masked]
> > 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 : [email-masked] 
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: [email-masked]
Delivery-date: Sun, 19 May 2002 23:17:30 -0700
Message-ID: <[email-masked]>
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Label Set Object/Tlv
Date: Mon, 20 May 2002 11:45:25 +1000
Organization: wipro technologies

comments inline.........

----- Original Message -----
From: <[email-masked]>
To: "venkat" <[email-masked]>
Cc: <[email-masked]>
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 : [email-masked]
> 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

Delivery-date: Fri, 17 May 2002 02:50:04 -0700
Cc: "'Jonathan Lang'" <[email-masked]>, "'Bhavesh Patel'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Fri, 17 May 2002 11:47:35 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Nik Langrind <[email-masked]>
Original-CC: "'Jonathan Lang'" <[email-masked]>, "'Bhavesh Patel'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Regarding J0 byte in LMP test message

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:[email-masked]]
> > Sent: Thursday, May 16, 2002 1:39 PM
> > To: 'Bhavesh Patel'; [email-masked]'
> > 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:[email-masked]]
> > > Sent: Thursday, May 16, 2002 5:53 AM
> > > To: [email-masked]'
> > > 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
> > > [email-masked] <mailto:[email-masked]>
> > > 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:[email-masked]
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--

Delivery-date: Thu, 16 May 2002 16:25:04 -0700
From: Jonathan Lang <[email-masked]>
To: 'Bhavesh Patel' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Regarding J0 byte in LMP test message
Date: Thu, 16 May 2002 16:16:08 -0700

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:[email-masked]]
Sent: Thursday, May 16, 2002 2:14 PM
To: Jonathan Lang; [email-masked]'
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:[email-masked]]
Sent: Thursday, May 16, 2002 1:39 PM
To: 'Bhavesh Patel'; [email-masked]'
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:[email-masked]]
> Sent: Thursday, May 16, 2002 5:53 AM
> To: [email-masked]'
> 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 
> [email-masked] <mailto:[email-masked]>
> 732-946-7400, ext 2087
> 
> 

Delivery-date: Thu, 16 May 2002 14:26:42 -0700
From: Bhavesh Patel <[email-masked]>
To: 'Jonathan Lang' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Regarding J0 byte in LMP test message
Date: Thu, 16 May 2002 17:13:49 -0400

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:[email-masked]]
Sent: Thursday, May 16, 2002 1:39 PM
To: 'Bhavesh Patel'; [email-masked]'
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:[email-masked]]
> Sent: Thursday, May 16, 2002 5:53 AM
> To: [email-masked]'
> 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 
> [email-masked] <mailto:[email-masked]>
> 732-946-7400, ext 2087
> 
> 

Delivery-date: Thu, 16 May 2002 12:15:51 -0700
From: Nik Langrind <[email-masked]>
To: Nik Langrind <[email-masked]>, "'Jonathan Lang'" <[email-masked]>, "'Bhavesh Patel'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Regarding J0 byte in LMP test message
Date: Thu, 16 May 2002 15:14:28 -0400

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:[email-masked]]
> Sent: Thursday, May 16, 2002 2:04 PM
> To: 'Jonathan Lang'; 'Bhavesh Patel'; [email-masked]'
> 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:[email-masked]]
> > Sent: Thursday, May 16, 2002 1:39 PM
> > To: 'Bhavesh Patel'; [email-masked]'
> > 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:[email-masked]]
> > > Sent: Thursday, May 16, 2002 5:53 AM
> > > To: [email-masked]'
> > > 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 
> > > [email-masked] <mailto:[email-masked]>
> > > 732-946-7400, ext 2087
> > > 
> > > 
> > 
> 

Delivery-date: Thu, 16 May 2002 11:04:48 -0700
From: Nik Langrind <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "'Bhavesh Patel'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Regarding J0 byte in LMP test message
Date: Thu, 16 May 2002 14:04:00 -0400

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:[email-masked]]
> Sent: Thursday, May 16, 2002 1:39 PM
> To: 'Bhavesh Patel'; [email-masked]'
> 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:[email-masked]]
> > Sent: Thursday, May 16, 2002 5:53 AM
> > To: [email-masked]'
> > 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 
> > [email-masked] <mailto:[email-masked]>
> > 732-946-7400, ext 2087
> > 
> > 
> 

Delivery-date: Thu, 16 May 2002 10:49:49 -0700
From: Jonathan Lang <[email-masked]>
To: 'Bhavesh Patel' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Regarding J0 byte in LMP test message
Date: Thu, 16 May 2002 10:38:58 -0700

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:[email-masked]]
> Sent: Thursday, May 16, 2002 5:53 AM
> To: [email-masked]'
> 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 
> [email-masked] <mailto:[email-masked]>
> 732-946-7400, ext 2087
> 
> 

Delivery-date: Thu, 16 May 2002 06:07:16 -0700
From: Bhavesh Patel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Bhavesh Patel <[email-masked]>
Subject: Regarding J0 byte in LMP test message
Date: Thu, 16 May 2002 08:53:12 -0400

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 
[email-masked] <mailto:[email-masked]>
732-946-7400, ext 2087

Delivery-date: Thu, 16 May 2002 03:58:37 -0700
Date: Thu, 16 May 2002 12:56:13 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: venkat <[email-masked]>
CC: [email-masked]
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
  
>     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 : [email-masked] 
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

Delivery-date: Wed, 15 May 2002 21:35:37 -0700
Reply-To: "venkat" <[email-masked]>
From: "Venkat Dabbara" <[email-masked]>
To: <[email-masked]>
Subject: Label Set Object/Tlv
Date: Thu, 16 May 2002 10:01:31 +1000
Organization: wipro technologies

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>hai=20
,<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; In=20
draft-ietf-mpls-generalized-cr-ldp-06.txt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
2.5.1.=20
Procedures<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
A Label Set is defined via one or more Label Set=20
TLVs.<BR>Specific<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
labels/subchannels can be added to or excluded from a Label<BR>Set=20
via<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
Action zero (0) and one (1) TLVs respectively.&nbsp; Ranges=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
labels/subchannels can be added to or excluded from a Label<BR>Set=20
via<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
Action two (2) and three (3) TLVs =
respectively.<BR><BR>&nbsp;&nbsp;&nbsp; The=20
first line of the sec 2.5.1 says a label set is defined via one =
or<BR>more=20
LabelSet TLVs. My interpretation<BR>&nbsp;&nbsp;&nbsp; about this is =
that a=20
label request can have multiple Label Set TLVs in<BR>it with different =
action=20
types corresponding<BR>&nbsp;&nbsp;&nbsp;&nbsp; to each label set TLV. =
Am i=20
right ??<BR>&nbsp;&nbsp;&nbsp;&nbsp; If&nbsp; i am wrong please do =
clarify=20
...<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; If yes, then assume i get a request =
with one=20
label set TLV with action<BR>type 0 which has a list of=20
labels<BR>&nbsp;&nbsp;&nbsp; and other Label set TLV with action type 1 =
which=20
has a range of Labels.<BR>Now in this case i go =
about<BR>&nbsp;&nbsp;&nbsp;=20
picking up a label from the second label set TLV only if i am not =
able<BR>to=20
pick up a label from the first<BR>&nbsp;&nbsp;&nbsp; label set TLV....Is =
that=20
true ??<BR><BR>&nbsp;&nbsp;&nbsp; Now situation may get even worse when =
i have a=20
Label set TLV with action<BR>type to include a =
label<BR>&nbsp;&nbsp;&nbsp; set=20
and other Label Set TLV with action type exclude. I knoe =
such<BR>situations are=20
not practical but<BR>&nbsp;&nbsp;&nbsp; sure needs to be handled=20
someway.<BR><BR>&nbsp;&nbsp;&nbsp; Please do =
clarify<BR><BR>venkat<BR><BR>PS:=20
Please don't bother about the disclaimer which come attached with=20
this<BR>mail.</FONT><BR><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0055_01C1FCC0.A75B8D80--

------=_NextPartTM-000-8c8293fb-5ccc-11d6-ba7c-006067005148--

Delivery-date: Mon, 13 May 2002 08:51:45 -0700
Date: Mon, 13 May 2002 11:55:49 -0400
From: Carmine Daloia <[email-masked]>
Organization: Lucent Technologies
To: Martin Dubuc <[email-masked]>
CC: Michiel van Everdingen <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked]
Subject: Re: LMP & neighbor discovery (verify_id)

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:[email-masked]]
> Sent: Friday, May 10, 2002 4:34 AM
> To: Jonathan Lang
> Cc: [email-masked]
> 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:[email-masked]  |
> +------------------------------------------------------------------+

Delivery-date: Mon, 13 May 2002 05:10:00 -0700
Cc: "'Suresh Katukam'" <[email-masked]>, Zafar Ali <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Date: Mon, 13 May 2002 14:07:50 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
Original-CC: "'Suresh Katukam'" <[email-masked]>, Zafar Ali <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Label Set Object

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:[email-masked]]
> 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:[email-masked]]
> >>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: [email-masked]
> >
> >===============
> >Zafar Ali
> >Cisco Systems
> >(734) 276-2459
> >100 S Main St. #200
> >Ann Arbor, MI 48104.
> >email: [email-masked]
--------------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:[email-masked]
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--

Delivery-date: Mon, 13 May 2002 00:15:59 -0700
From: "sushantm" <[email-masked]>
To: "John Drake" <[email-masked]>
Cc: "Manoj Agiwal" <[email-masked]>, "'Ccamp \(E-mail\)" <[email-masked]>, "mpls@UU. NET \(E-mail\)" <[email-masked]>, "'Suresh Katukam'" <[email-masked]>, "Zafar Ali" <[email-masked]>
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: [email-masked] [mailto:[email-masked]]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:[email-masked]]
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:[email-masked]]
>>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: [email-masked]
>
>===============
>Zafar Ali
>Cisco Systems
>(734) 276-2459
>100 S Main St. #200
>Ann Arbor, MI 48104.
>email: [email-masked]

Delivery-date: Sun, 12 May 2002 23:41:28 -0700
Subject: Re: How many can administrative groups assigned?
To: Curtis Villamizar <[email-masked]>
Cc: "Naidu, Venkata" <[email-masked]>, "'???'" <[email-masked]>, [email-masked], CCAMP <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 13 May 2002 08:36:54 +0200

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 <[email-masked]> on 08/05/2002 20:22:11

                                                              
  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:          "Naidu, Venkata" <[email-masked]>,  
               "'???'" <[email-masked]>,             
               [email-masked], CCAMP <[email-masked]>,       
               [email-masked]                             

                                                              
  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 <[email-masked]>,
sven.van_d
[email-masked] 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

Delivery-date: Fri, 10 May 2002 08:36:42 -0700
content-class: urn:content-classes:message
Subject: RE: LMP & neighbor discovery (verify_id)
Date: Fri, 10 May 2002 11:30:10 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Michiel van Everdingen" <[email-masked]>, "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]
Sent: Friday, May 10, 2002 4:34 AM
To: Jonathan Lang
Cc: [email-masked]
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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Fri, 10 May 2002 05:49:10 -0700
From: "Ravi,  Attili" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Don Fedyk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "CCAMP" <[email-masked]>, <[email-masked]>, "Ravi Attili" <[email-masked]>
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--

Delivery-date: Fri, 10 May 2002 01:57:16 -0700
Cc: Zhi-Wei Lin <[email-masked]>, [email-masked]
Date: Fri, 10 May 2002 10:56:32 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Martin Dubuc <[email-masked]>
Original-CC: Zhi-Wei Lin <[email-masked]>, [email-masked]
Subject: Re: LMP & neighbor discovery

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...>

Delivery-date: Fri, 10 May 2002 01:35:26 -0700
Cc: [email-masked]
Date: Fri, 10 May 2002 10:33:58 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: [email-masked]
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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Fri, 10 May 2002 01:24:54 -0700
Subject: Re: Label Set Object
To: "Anca Zamfir <ancaz" <[email-masked]>
Cc: ""Adrian Farrel" <afarrel" <[email-masked]>, ""John Drake" <jdrake" <[email-masked]>, ""Zafar Ali" <zali" <[email-masked]>, ""[email-masked], "Manoj'\" <m_juneja\"" <[email-masked]>, ""Vinay Vernekar" <vinay.vernekar" <[email-masked]>, ""Manoj Agiwal" <ManojA" <[email-masked]>, "\"\"'Ccamp \(E-mail\)\" <ccamp\"" <[email-masked]>, "<skatukam" <[email-masked]>, ""mpls" <[email-masked]>"@marconi.com
From: "Diego Caviglia" <[email-masked]>
Date: Fri, 10 May 2002 10:21:35 +0200

Anca,
                comment in line.

Regards, Diego.

----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Anca Zamfir <[email-masked]>@ops.ietf.org on 09/05/2002 22.44.28

Sent by:  [email-masked]

To:   "Adrian Farrel" <[email-masked]>
cc:   "John Drake" <[email-masked]>, "Zafar Ali" <[email-masked]>,
      "'Juneja, Manoj'" <[email-masked]>, "Vinay Vernekar"
      <[email-masked]>, "Manoj Agiwal" <[email-masked]>,
      "'Ccamp \(E-mail\)" <[email-masked]>, <[email-masked]>,
      "mpls@UU. NET \(E-mail\)" <[email-masked]>

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]

Delivery-date: Thu, 09 May 2002 20:07:46 -0700
Reply-To: <[email-masked]>
From: "Fong Liaw" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Connection Deletion in GMPLS
Date: Thu, 9 May 2002 20:11:53 -0700

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" <[email-masked]>
> >To: "manoj juneja" <[email-masked]>,
<[email-masked]>
> >CC: <[email-masked]>, <[email-masked]>
> >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

Delivery-date: Thu, 09 May 2002 13:53:39 -0700
Date: Thu, 09 May 2002 22:52:36 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: "Bernstein, Greg" <[email-masked]>
Cc: "'Martin Dubuc'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>, [email-masked], Michiel van Everdingen <[email-masked]>
Subject: Re: LMP & neighbor discovery

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: <flags> <node_id> <interface_id>
...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:[email-masked]]
> Sent: Thursday, May 09, 2002 6:44 AM
> To: Zhi-Wei Lin
> Cc: Michiel van Everdingen; [email-masked]
> 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:[email-masked]]
> Sent: Tuesday, May 07, 2002 5:16 PM
> To: Martin Dubuc
> Cc: Michiel van Everdingen; [email-masked]
> 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:[email-masked]]
> >Sent: Tuesday, May 07, 2002 11:42 AM
> >To: [email-masked]
> >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 : [email-masked] 
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

Delivery-date: Thu, 09 May 2002 13:49:32 -0700
Date: Thu, 09 May 2002 16:44:28 -0400
To: "Adrian Farrel" <[email-masked]>
From: Anca Zamfir <[email-masked]>
Subject: Re: Label Set Object
Cc: "John Drake" <[email-masked]>, "Zafar Ali" <[email-masked]>, "'Juneja, Manoj'" <[email-masked]>, "Vinay Vernekar" <[email-masked]>, "Manoj Agiwal" <[email-masked]>, "'Ccamp \(E-mail\)" <[email-masked]>, <[email-masked]>, "mpls@UU. NET \(E-mail\)" <[email-masked]>

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" <[email-masked]>
>To: "'Anca Zamfir'" <[email-masked]>; "Zafar Ali" <[email-masked]>
>Cc: "'Juneja, Manoj'" <[email-masked]>; "Vinay Vernekar"
><[email-masked]>; "Manoj Agiwal" <[email-masked]>; "'Ccamp
>(E-mail)" <[email-masked]>; <[email-masked]>; "mpls@UU. NET (E-mail)"
><[email-masked]>
>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: [email-masked]
Delivery-date: Thu, 09 May 2002 12:55:02 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "John Drake" <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, "Zafar Ali" <[email-masked]>
Cc: "'Juneja, Manoj'" <[email-masked]>, "Vinay Vernekar" <[email-masked]>, "Manoj Agiwal" <[email-masked]>, "'Ccamp \(E-mail\)" <[email-masked]>, <[email-masked]>, "mpls@UU. NET \(E-mail\)" <[email-masked]>
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" <[email-masked]>
To: "'Anca Zamfir'" <[email-masked]>; "Zafar Ali" <[email-masked]>
Cc: "'Juneja, Manoj'" <[email-masked]>; "Vinay Vernekar"
<[email-masked]>; "Manoj Agiwal" <[email-masked]>; "'Ccamp
(E-mail)" <[email-masked]>; <[email-masked]>; "mpls@UU. NET (E-mail)"
<[email-masked]>
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.
>

Delivery-date: Thu, 09 May 2002 11:44:40 -0700
content-class: urn:content-classes:message
Subject: RE: LMP & neighbor discovery
Date: Thu, 9 May 2002 14:41:14 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>
Cc: "Bernstein, Greg" <[email-masked]>

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: [email-masked]

>-----Original Message-----
>From: Bernstein, Greg [mailto:[email-masked]]
>Sent: Thursday, May 09, 2002 1:53 PM
>To: Martin Dubuc; Zhi-Wei Lin; [email-masked]
>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:[email-masked]]
>Sent: Thursday, May 09, 2002 6:44 AM
>To: Zhi-Wei Lin
>Cc: Michiel van Everdingen; [email-masked]
>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:[email-masked]]
>Sent: Tuesday, May 07, 2002 5:16 PM
>To: Martin Dubuc
>Cc: Michiel van Everdingen; [email-masked]
>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:[email-masked]]
>>Sent: Tuesday, May 07, 2002 11:42 AM
>>To: [email-masked]
>>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
>>
>
>
>
>
>

Delivery-date: Thu, 09 May 2002 10:56:08 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>, [email-masked]
Cc: Michiel van Everdingen <[email-masked]>, "Bernstein, Greg" <[email-masked]>
Subject: RE: LMP & neighbor discovery
Date: Thu, 9 May 2002 10:53:17 -0700 

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:[email-masked]]
Sent: Thursday, May 09, 2002 6:44 AM
To: Zhi-Wei Lin
Cc: Michiel van Everdingen; [email-masked]
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:[email-masked]]
Sent: Tuesday, May 07, 2002 5:16 PM
To: Martin Dubuc
Cc: Michiel van Everdingen; [email-masked]
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:[email-masked]]
>Sent: Tuesday, May 07, 2002 11:42 AM
>To: [email-masked]
>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.
>
>
>  
>

Delivery-date: Thu, 09 May 2002 06:51:08 -0700
content-class: urn:content-classes:message
Subject: RE: LMP & neighbor discovery
Date: Thu, 9 May 2002 09:43:38 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>
Cc: "Michiel van Everdingen" <[email-masked]>, <[email-masked]>

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:[email-masked]]
Sent: Tuesday, May 07, 2002 5:16 PM
To: Martin Dubuc
Cc: Michiel van Everdingen; [email-masked]
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:[email-masked]]
>Sent: Tuesday, May 07, 2002 11:42 AM
>To: [email-masked]
>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
>

Delivery-date: Wed, 08 May 2002 23:21:14 -0700
Date: Wed, 8 May 2002 23:18:41 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Don Fedyk <[email-masked]>
cc: <[email-masked]>, CCAMP <[email-masked]>, <[email-masked]>
Subject: RE: How many can administrative groups assigned? 

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.

Delivery-date: Wed, 08 May 2002 23:10:51 -0700
Date: Thu, 09 May 2002 02:07:48 -0400
To: Nik Langrind <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: TransmissionRate in LMP BeginVery

--=====================_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: [email-masked]

--=====================_59790133==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 04:37 PM 5/8/2002 -0400, Nik Langrind wrote:<br>
</font><blockquote type=cite cite><font face="arial" size=2>Hi,</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2>What is the purpose of including the
Transmission Rate field in the Begin Verify message?
</font></blockquote><br>
Dear Nik, <br>
<br>
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 &quot;hunt&quot; for it. <br>
<br>
<blockquote type=cite cite><font face="arial" size=2>If a group of ports
will be verified in one pass verification, and the ports have different
transmission speeds... then what?</font></blockquote><br>
The transmission rate should always be set to the rate at which the
actual verification message will be sent. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<blockquote type=cite cite><font face="arial" size=2>&nbsp;</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2>Thanks,</font><font size=3><br>
</font><font face="arial" size=2>Nik</font><font size=3></blockquote><br>
===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: </font><font size=3 color="#0000FF"><u>[email-masked]<br>
<br>
</font></u></html>

--=====================_59790133==_.ALT--

Delivery-date: Wed, 08 May 2002 22:25:52 -0700
From: "sushantm" <[email-masked]>
To: "John Drake" <[email-masked]>
Cc: "Manoj Agiwal" <[email-masked]>, "'Ccamp \(E-mail\)" <[email-masked]>, "mpls@UU. NET \(E-mail\)" <[email-masked]>, "'Suresh Katukam'" <[email-masked]>, "Zafar Ali" <[email-masked]>
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: [email-masked] [mailto:[email-masked]]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:[email-masked]]
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:[email-masked]]
>>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: [email-masked]
>
>===============
>Zafar Ali
>Cisco Systems
>(734) 276-2459
>100 S Main St. #200
>Ann Arbor, MI 48104.
>email: [email-masked]

Delivery-date: Wed, 08 May 2002 21:21:07 -0700
From: "Fong Liaw" <[email-masked]>
To: "manoj juneja" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
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

Delivery-date: Wed, 08 May 2002 19:44:02 -0700
From: John Drake <[email-masked]>
To: 'Anca Zamfir' <[email-masked]>, Zafar Ali <[email-masked]>
Cc: "'Juneja, Manoj'" <[email-masked]>, Vinay Vernekar <[email-masked]>, Manoj Agiwal <[email-masked]>,  "'Ccamp (E-mail)" <[email-masked]>, [email-masked],  "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 19:42:29 -0700 

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:[email-masked]]
Sent: Wednesday, May 08, 2002 4:48 PM
To: Zafar Ali
Cc: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp
(E-mail); [email-masked]; 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:[email-masked]]
>>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:[email-masked]]
>>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:[email-masked]]
>>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:[email-masked]]
>>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:[email-masked]]
>>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: <mailto:[email-masked]>Zafar Ali
>>>>To: <mailto:[email-masked]>Manoj Agiwal ; 
>>>><mailto:[email-masked]>'Ccamp (E-mail)
>>>>Cc: <mailto:mpls@UU. NET (E-mail)>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: [email-masked]
>
>
>===============
>Zafar Ali
>Cisco Systems
>(734) 276-2459
>100 S Main St. #200
>Ann Arbor, MI 48104.
>email: [email-masked]

Delivery-date: Wed, 08 May 2002 18:39:08 -0700
From: John Drake <[email-masked]>
To: 'Suresh Katukam' <[email-masked]>, Zafar Ali <[email-masked]>
Cc: Manoj Agiwal <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>,  "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 18:37:32 -0700 

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:[email-masked]]
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:[email-masked]]
>>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: [email-masked]
>
>===============
>Zafar Ali
>Cisco Systems
>(734) 276-2459
>100 S Main St. #200
>Ann Arbor, MI 48104.
>email: [email-masked]

Delivery-date: Wed, 08 May 2002 16:49:02 -0700
Date: Wed, 08 May 2002 19:47:51 -0400
To: Zafar Ali <[email-masked]>
From: Anca Zamfir <[email-masked]>
Subject: RE: Label Set Object
Cc: John Drake <[email-masked]>, "'Juneja, Manoj'" <[email-masked]>, Vinay Vernekar <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, [email-masked], "mpls@UU. NET (E-mail)" <[email-masked]>

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:[email-masked]]
>>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:[email-masked]]
>>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:[email-masked]]
>>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:[email-masked]]
>>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:[email-masked]]
>>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: <mailto:[email-masked]>Zafar Ali
>>>>To: <mailto:[email-masked]>Manoj Agiwal ; 
>>>><mailto:[email-masked]>'Ccamp (E-mail)
>>>>Cc: <mailto:mpls@UU. NET (E-mail)>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: [email-masked]
>
>
>===============
>Zafar Ali
>Cisco Systems
>(734) 276-2459
>100 S Main St. #200
>Ann Arbor, MI 48104.
>email: [email-masked]

Delivery-date: Wed, 08 May 2002 16:28:16 -0700
From: John Drake <[email-masked]>
To: 'Zafar Ali' <[email-masked]>, "'Juneja, Manoj'" <[email-masked]>, Vinay Vernekar <[email-masked]>,  Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, [email-masked]
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 16:26:58 -0700 

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:[email-masked]]
Sent: Wednesday, May 08, 2002 4:05 PM
To: John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 'Ccamp
(E-mail); [email-masked]
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:[email-masked]
<mailto:[email-masked]> ] 

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:[email-masked] <mailto:[email-masked]> ] 

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:[email-masked]
<mailto:[email-masked]> ] 

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:[email-masked] <mailto:[email-masked]> ] 

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:[email-masked] <mailto:[email-masked]> ] 

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 <mailto:[email-masked]>  

To: Manoj Agiwal <mailto:[email-masked]>  ; 'Ccamp (E-mail)
<mailto:[email-masked]>  

Cc: mpls@UU. NET  <mailto:mpls@UU. NET (E-mail)> (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: [email-masked] 

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

------_=_NextPart_001_01C1F6E7.D93A00E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=601032023-08052002><FONT face=Arial color=#0000ff size=2>In the 
SONET/SDH case, there's always one and only one label, so isn't label set 
overkill?&nbsp; That's what I meant by 'more natural'.</FONT></SPAN></DIV>
<DIV><SPAN class=601032023-08052002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=601032023-08052002><FONT face=Arial color=#0000ff size=2>As 
George pointed out,&nbsp;in the downstream direction either explicit label 
control or a label set with one value&nbsp;is a useful thing in the&nbsp;manner 
of 'belt and suspenders' </FONT></SPAN></DIV>
<DIV><SPAN class=601032023-08052002></SPAN><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Zafar Ali 
[mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 4:05 
PM<BR><B>To:</B> John Drake; 'Juneja, Manoj'; Vinay Vernekar; Manoj Agiwal; 
'Ccamp (E-mail); [email-masked]<BR><B>Cc:</B> mpls@UU. NET 
(E-mail)<BR><B>Subject:</B> RE: Label Set Object<BR><BR></DIV></FONT>
<BLOCKQUOTE><FONT size=3>At 01:07 PM 5/8/2002 -0700, John Drake 
  wrote:<BR></FONT>
  <BLOCKQUOTE cite type="cite"><FONT face=arial color=#0000ff size=2>Label Set 
    and Explicit Label Control are used for different purposes, and as I 
    understand it, Explicit Label Control is more natural&nbsp; for establishing 
    SONET/SDH LSPs, while Label Set is more natural for establishing wavelength 
    LSPs.&nbsp; </FONT><BR><FONT face=arial color=#0000ff size=2>You could, 
    however, use Label Set for SONET/SDH LSPs and Explicit Label Control for 
    wavelength LSPs.</FONT></BLOCKQUOTE><FONT size=3><BR>Hi John, <BR><BR>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. <BR><BR>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. 
  <BR><BR>Thanks<BR><BR>Regards... Zafar<BR></FONT>
  <BLOCKQUOTE cite type="cite">
    <DL><FONT face=tahoma size=2>
      <DD>-----Original Message----- 
      <DD>From:</B> Juneja, Manoj [<A href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent:</B> Wednesday, May 08, 2002 11:57 AM 
      <DD>To:</B> John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj 
      Agiwal; 'Ccamp (E-mail) 
      <DD>Cc:</B> mpls@UU. NET (E-mail) 
      <DD>Subject:</B> RE: Label Set Object<BR><BR></FONT><FONT face=arial 
      color=#0000ff size=2>
      <DD>Hi Jonh,</FONT><FONT size=3></FONT><FONT face=arial color=#0000ff 
      size=2> 
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Sorry for creating the confusion. Should the label set be used for 
      establishing the SDH/SONET LSPs ? </FONT><FONT size=3>
      <DD></FONT><FONT face=arial color=#0000ff size=2> 
      <DD>Regards,</FONT><FONT size=3></FONT><FONT face=arial color=#0000ff 
      size=2> 
      <DD>manoj.</FONT><FONT size=3></FONT><FONT face=tahoma size=2> 
      <DD>-----Original Message----- 
      <DD>From:</B> John Drake [<A href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent:</B> Wednesday, May 08, 2002 11:50 AM 
      <DD>To:</B> 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 
      'Ccamp (E-mail) 
      <DD>Cc:</B> mpls@UU. NET (E-mail) 
      <DD>Subject:</B> RE: Label Set Object<BR><BR></FONT><FONT face=arial 
      color=#0000ff size=2>
      <DD>I didn't say that.</FONT><FONT size=3></FONT><FONT face=tahoma size=2> 

      <DD>-----Original Message----- 
      <DD>From:</B> Juneja, Manoj [<A href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent:</B> Wednesday, May 08, 2002 11:48 AM 
      <DD>To:</B> John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp 
      (E-mail) 
      <DD>Cc:</B> mpls@UU. NET (E-mail) 
      <DD>Subject:</B> RE: Label Set Object<BR><BR></FONT><FONT face=arial 
      color=#0000ff size=2>
      <DD>Hi John,</FONT><FONT size=3></FONT><FONT face=arial color=#0000ff 
      size=2> 
      <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Did u mean Explicit label control is used only for SDH/SONET case&nbsp; 
      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.</FONT><FONT size=3> 
      <DD></FONT><FONT face=arial color=#0000ff size=2> 
      <DD>Regards,</FONT><FONT size=3></FONT><FONT face=arial color=#0000ff 
      size=2> 
      <DD>manoj.</FONT><FONT size=3></FONT><FONT face=tahoma size=2> 
      <DD>-----Original Message----- 
      <DD>From:</B> John Drake [<A href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent:</B> Wednesday, May 08, 2002 11:26 AM 
      <DD>To:</B> 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) 
      <DD>Cc:</B> mpls@UU. NET (E-mail) 
      <DD>Subject:</B> RE: Label Set Object<BR><BR></FONT><FONT size=3>
      <DD>Explicit Label Control is used to handle the SONET/SDH case.&nbsp; 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 
      <DD> 
      <DD>Thanks, 
      <DD> 
      <DD>John 
      <DD></FONT><FONT face=tahoma size=2> 
      <DD>-----Original Message----- 
      <DD>From:</B> Zafar Ali [<A href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent:</B> Wednesday, May 08, 2002 10:31 AM 
      <DD>To:</B> Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail) 
      <DD>Cc:</B> mpls@UU. NET (E-mail) 
      <DD>Subject:</B> Re: Label Set Object<BR><BR></FONT><FONT size=3>
      <DD>Dear Vinay, <BR><BR>
      <DD>Please see comments in-lined. <BR><BR>
      <DD>Thanks<BR><BR>
      <DD>Regards... Zafar 
      <DD>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:</FONT>
      <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>
        <DD>Hi Zafar,</FONT><FONT face=arial size=3> 
        <DD>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". </FONT></DD></BLOCKQUOTE>
      <DD>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? <BR><BR>
      <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>
        <DD>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.</FONT></DD></BLOCKQUOTE>
      <DD>IMHO this would be an undesirable restriction. Why its cannot cover 
      the single label case in SONET? <BR><BR>
      <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>
        <DD>Correct me if I am going wrong anywhere.</FONT> 
        <DD><FONT face=arial size=3> 
        <DD>Regards</FONT><FONT face=arial size=3> 
        <DD>Vinay&nbsp;&nbsp;&nbsp; </FONT>
        <BLOCKQUOTE cite type="cite">
          <DD>----- Original Message ----- 
          <DD>From:</B> <A href="mailto:[email-masked]">Zafar Ali</A> 
          <DD>To:</B> <A href="mailto:[email-masked]">Manoj Agiwal</A> ; 
          <A href="mailto:[email-masked]">'Ccamp (E-mail)</A> 
          <DD>Cc:</B> <A href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET 
          (E-mail)</A> 
          <DD>Sent:</B> Wednesday, May 08, 2002 11:04 AM 
          <DD>Subject:</B> Re: Label Set Object<BR><BR>
          <DD>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:
          <BLOCKQUOTE cite type="cite">
            <DD>Hi , 
            <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling 
            extensionsions for RSVP-TE , ccamp architecture on 
            <DD>gmpls has described Label Set object usage 
            <DD>&nbsp;&nbsp;&nbsp; only for the "optical" domain viz. for 
            carrying wavelengths ( Section 
            <DD>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . <BR><BR>
            <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send Label 
            set(i.e. time slots) for TDM switching as 
            <DD>well . In what way it can be useful . </DD></BLOCKQUOTE>
          <DD>Dear Manoj, <BR><BR>
          <DD>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. 
          <DD>&nbsp;The label set object can be used to constrain the downstream 
          label to the same as the upstream label. <BR><BR>
          <DD>Thanks<BR><BR>
          <DD>Regards... Zafar <BR><BR><BR><BR><BR><BR>
          <BLOCKQUOTE cite type="cite">
            <DD>Regards , 
            <DD>Manoj</DD></BLOCKQUOTE>
          <DD>=============== 
          <DD>Zafar Ali 
          <DD>Cisco Systems 
          <DD>(734) 276-2459 
          <DD>100 S Main St. #200 
          <DD>Ann Arbor, MI 48104</U>. 
          <DD>email: <FONT color=#0000ff size=3>[email-masked]</U></FONT> 
        </DD></BLOCKQUOTE></DD></BLOCKQUOTE></DD></DL></BLOCKQUOTE>
  <DL></DL><BR><FONT size=3>===============<BR>Zafar Ali<BR>Cisco 
  Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI 
  48104</U>.<BR>email: </FONT><FONT color=#0000ff 
size=3><U>[email-masked]<BR></BLOCKQUOTE></FONT></U></BODY></HTML>

------_=_NextPart_001_01C1F6E7.D93A00E0--

Delivery-date: Wed, 08 May 2002 16:06:23 -0700
Date: Wed, 08 May 2002 19:04:57 -0400
To: John Drake <[email-masked]>, "'Juneja, Manoj'" <[email-masked]>, Vinay Vernekar <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, [email-masked]
From: Zafar Ali <[email-masked]>
Subject: RE: Label Set Object
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>

--=====================_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:[email-masked]]
>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:[email-masked]]
>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:[email-masked]]
>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:[email-masked]]
>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:[email-masked]]
>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: <mailto:[email-masked]>Zafar Ali
>>>To: <mailto:[email-masked]>Manoj Agiwal ; 
>>><mailto:[email-masked]>'Ccamp (E-mail)
>>>Cc: <mailto:mpls@UU. NET (E-mail)>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: [email-masked]

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

--=====================_34419362==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 01:07 PM 5/8/2002 -0700, John Drake wrote:<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Label
Set and Explicit Label Control are used for different purposes, and as I
understand it, Explicit Label Control is more natural&nbsp; for
establishing SONET/SDH LSPs, while Label Set is more natural for
establishing wavelength LSPs.&nbsp; </font><br>
<font face="arial" size=2 color="#0000FF">You could, however, use Label
Set for SONET/SDH LSPs and Explicit Label Control for wavelength
LSPs.</font></blockquote><font size=3><br>
Hi John, <br>
<br>
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. <br>
<br>
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. <br>
<br>
Thanks<br>
<br>
Regards... Zafar<br>
</font><blockquote type=cite cite>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Juneja, Manoj
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 08, 2002 11:57 AM
<dd>To:</b> John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj
Agiwal; 'Ccamp (E-mail)
<dd>Cc:</b> mpls@UU. NET (E-mail)
<dd>Subject:</b> RE: Label Set Object<br>
<br>
</font><font face="arial" size=2 color="#0000FF">
<dd>Hi
Jonh,</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Sorry for creating the confusion. Should the label set be used for
establishing the SDH/SONET LSPs ? </font><font size=3>
<dd>&nbsp;</font><font face="arial" size=2 color="#0000FF">
<dd>Regards,</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>manoj.</font><font size=3></font><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> John Drake
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 08, 2002 11:50 AM
<dd>To:</b> 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal;
'Ccamp (E-mail)
<dd>Cc:</b> mpls@UU. NET (E-mail)
<dd>Subject:</b> RE: Label Set Object<br>
<br>
</font><font face="arial" size=2 color="#0000FF">
<dd>I didn't say
that.</font><font size=3></font><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Juneja, Manoj
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 08, 2002 11:48 AM
<dd>To:</b> John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp
(E-mail)
<dd>Cc:</b> mpls@UU. NET (E-mail)
<dd>Subject:</b> RE: Label Set Object<br>
<br>
</font><font face="arial" size=2 color="#0000FF">
<dd>Hi
John,</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Did u mean Explicit label control is used only for SDH/SONET case&nbsp;
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.</font><font size=3>
<dd>&nbsp;</font><font face="arial" size=2 color="#0000FF">
<dd>Regards,</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>manoj.</font><font size=3></font><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> John Drake
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 08, 2002 11:26 AM
<dd>To:</b> 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
<dd>Cc:</b> mpls@UU. NET (E-mail)
<dd>Subject:</b> RE: Label Set Object<br>
<br>
</font><font size=3>
<dd>Explicit Label Control is used to handle the SONET/SDH case.&nbsp;
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 
<dd>&nbsp;
<dd>Thanks,
<dd>&nbsp;
<dd>John
<dd>&nbsp;</font><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Zafar Ali
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 08, 2002 10:31 AM
<dd>To:</b> Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)
<dd>Cc:</b> mpls@UU. NET (E-mail)
<dd>Subject:</b> Re: Label Set Object<br>
<br>
</font><font size=3>
<dd>Dear Vinay, <br>
<br>

<dd>Please see comments in-lined. <br>
<br>

<dd>Thanks<br>
<br>

<dd>Regards... Zafar 
<dd>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar
wrote:</font><blockquote type=cite cite><font face="arial" size=3>
<dd>Hi Zafar,</font><font face="arial" size=3>
<dd>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 &quot;Generalized MPLS - Signalling Functional
Description - draft-ietf-mpls-generalized-signaling-08.txt&quot;.
</font></blockquote>
<dd>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? <br>
<br>
<blockquote type=cite cite><font face="arial" size=3>
<dd>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.</font></blockquote>
<dd>IMHO this would be an undesirable restriction. Why its cannot cover
the single label case in SONET? <br>
<br>
<blockquote type=cite cite><font face="arial" size=3>
<dd>Correct me if I am going wrong anywhere.</font>
<dd>&nbsp;<font face="arial" size=3>
<dd>Regards</font><font face="arial" size=3>
<dd>Vinay&nbsp;&nbsp;&nbsp; </font><blockquote type=cite cite>
<dd>----- Original Message ----- 
<dd>From:</b> <a href="mailto:[email-masked]">Zafar Ali</a> 
<dd>To:</b> <a href="mailto:[email-masked]">Manoj Agiwal</a> ;
<a href="mailto:[email-masked]">'Ccamp (E-mail)</a> 
<dd>Cc:</b> <a href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET
(E-mail)</a> 
<dd>Sent:</b> Wednesday, May 08, 2002 11:04 AM
<dd>Subject:</b> Re: Label Set Object<br>
<br>

<dd>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal
wrote:<blockquote type=cite cite>
<dd>Hi ,
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling
extensionsions for RSVP-TE , ccamp architecture on
<dd>gmpls has described Label Set object usage
<dd>&nbsp;&nbsp;&nbsp; only for the &quot;optical&quot; domain viz. for
carrying wavelengths ( Section
<dd>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . <br>
<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send Label
set(i.e. time slots) for TDM switching as
<dd>well . In what way it can be useful . </blockquote>
<dd>Dear Manoj, <br>
<br>

<dd>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.
<dd>&nbsp;The label set object can be used to constrain the downstream
label to the same as the upstream label. <br>
<br>

<dd>Thanks<br>
<br>

<dd>Regards... Zafar <br>
<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dd>Regards ,
<dd>Manoj</blockquote>
<dd>===============
<dd>Zafar Ali
<dd>Cisco Systems
<dd>(734) 276-2459
<dd>100 S Main St. #200
<dd>Ann Arbor, MI 48104</u>.
<dd>email: <font size=3 color="#0000FF">[email-masked]</u></font>
</blockquote></blockquote></blockquote>
</dl><br>
<font size=3>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: </font><font size=3 color="#0000FF"><u>[email-masked]<br>
</font></u></html>

--=====================_34419362==_.ALT--

Envelope-to: [email-masked]
Delivery-date: Wed, 08 May 2002 15:34:01 -0700
Message-Id: <[email-masked]>
To: Suresh Katukam <[email-masked]>
cc: Zafar Ali <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Label Set Object 
Date: Wed, 08 May 2002 18:33:32 -0400
From: George Swallow <[email-masked]>

> 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

Delivery-date: Wed, 08 May 2002 15:24:41 -0700
Date: Wed, 08 May 2002 15:23:04 -0700
To: Zafar Ali <[email-masked]>
From: Suresh Katukam <[email-masked]>
Subject: RE: Label Set Object
Cc: Manoj Agiwal <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>

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:[email-masked]]
>>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: [email-masked]
>
>===============
>Zafar Ali
>Cisco Systems
>(734) 276-2459
>100 S Main St. #200
>Ann Arbor, MI 48104.
>email: [email-masked]

Delivery-date: Wed, 08 May 2002 14:15:24 -0700
From: Jonathan Lang <[email-masked]>
To: 'Yangguang Xu' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: LMP & neighbor discovery (verify_id)
Date: Wed, 8 May 2002 14:06:36 -0700 

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: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, May 08, 2002 7:46 AM
> To: Yangguang Xu
> Cc: [email-masked]
> 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 : [email-masked] 
> 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
> 

Delivery-date: Wed, 08 May 2002 13:38:12 -0700
From: Nik Langrind <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: TransmissionRate in LMP BeginVery
Date: Wed, 8 May 2002 16:37:15 -0400 

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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=817403320-08052002>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=817403320-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=817403320-08052002>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? </SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=817403320-08052002>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=817403320-08052002>Nik</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C1F6D0.23A91AC0--

Envelope-to: [email-masked]
Delivery-date: Wed, 08 May 2002 13:15:29 -0700
Message-ID: <[email-masked]>
From: "Don Fedyk"<[email-masked]>
To: Curtis Villamizar <[email-masked]>, [email-masked]
Cc: "Naidu, Venkata" <[email-masked]>, "'???'" <[email-masked]>, [email-masked], CCAMP <[email-masked]>, [email-masked]
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:[email-masked]]
> 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 
> <[email-masked]>, sven.van_d
> [email-masked] 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
> 

Delivery-date: Wed, 08 May 2002 13:09:16 -0700
From: John Drake <[email-masked]>
To: "'Juneja, Manoj'" <[email-masked]>, 'Zafar Ali' <[email-masked]>, Vinay Vernekar <[email-masked]>,  Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 13:07:22 -0700 

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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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 <mailto:[email-masked]>  
To: Manoj  <mailto:[email-masked]> Agiwal ; 'Ccamp
<mailto:[email-masked]> (E-mail) 
Cc: mpls@UU. NET (E-mail) <mailto: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: [email-masked] 

------_=_NextPart_001_01C1F6CB.F6C16CF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=816120120-08052002><FONT face=Arial color=#0000ff size=2>Label 
Set and Explicit Label Control are used for different purposes, and as I 
understand it, Explicit Label Control is more natural&nbsp; for 
establishing&nbsp;SONET/SDH LSPs, while Label Set is more natural for 
establishing wavelength LSPs.&nbsp; You could, however, use Label Set for 
SONET/SDH LSPs and Explicit Label Control for wavelength 
LSPs.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Juneja, Manoj 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:57 
  AM<BR><B>To:</B> John Drake; Juneja, Manoj; 'Zafar Ali'; Vinay Vernekar; Manoj 
  Agiwal; 'Ccamp (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> 
  RE: Label Set Object<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=197215618-08052002>Hi 
  Jonh,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=197215618-08052002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Sorry for creating the confusion. Should the label set be used for 
  establishing the SDH/SONET LSPs ? </SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=197215618-08052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=197215618-08052002>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=197215618-08052002>manoj.</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> John Drake 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:50 
    AM<BR><B>To:</B> 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 
    'Ccamp (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: 
    Label Set Object<BR><BR></DIV></FONT>
    <DIV><SPAN class=427385018-08052002><FONT face=Arial color=#0000ff size=2>I 
    didn't say that.</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Juneja, Manoj 
      [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 
      11:48 AM<BR><B>To:</B> John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj 
      Agiwal; 'Ccamp (E-mail)<BR><B>Cc:</B> mpls@UU. NET 
      (E-mail)<BR><B>Subject:</B> RE: Label Set Object<BR><BR></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=561354618-08052002>Hi John,</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=561354618-08052002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Did u mean Explicit label control is used only for SDH/SONET case&nbsp; 
      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.</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=561354618-08052002></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=561354618-08052002>Regards,</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=561354618-08052002>manoj.</SPAN></FONT></DIV>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> John Drake 
        [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 
        11:26 AM<BR><B>To:</B> 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp 
        (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: 
        Label Set Object<BR><BR></DIV></FONT>
        <DIV>Explicit Label Control<SPAN class=647072218-08052002> is used to 
        handle the SONET/SDH case.&nbsp; Its semantics are different&nbsp;than 
        Label Set, in the sense that there is one and only one value, rather 
        than a set that is manipulated end-end&nbsp;</SPAN></DIV>
        <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
        <DIV><SPAN class=647072218-08052002>Thanks,</SPAN></DIV>
        <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
        <DIV><SPAN class=647072218-08052002>John</SPAN></DIV>
        <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
        <DIV><SPAN class=647072218-08052002></SPAN><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Zafar Ali 
        [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 10:31 
        AM<BR><B>To:</B> Vinay Vernekar; Manoj Agiwal; 'Ccamp 
        (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> Re: 
        Label Set Object<BR><BR></DIV></FONT>
        <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"><FONT size=3>Dear Vinay, 
          <BR><BR>Please see comments in-lined. <BR><BR>Thanks<BR><BR>Regards... 
          Zafar <BR>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:<BR></FONT>
          <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>Hi 
            Zafar,</FONT><BR><FONT face=arial size=3>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". 
          </FONT></BLOCKQUOTE><BR>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? <BR><BR>
          <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>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.</FONT></BLOCKQUOTE><BR>IMHO this would be an 
          undesirable restriction. Why its cannot cover the single label case in 
          SONET? <BR><BR>
          <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>Correct me if I 
            am going wrong anywhere.</FONT><BR>&nbsp;<BR><FONT face=arial 
            size=3>Regards</FONT><BR><FONT face=arial 
            size=3>Vinay&nbsp;&nbsp;&nbsp; </FONT><BR>
            <BLOCKQUOTE cite type="cite">----- Original Message ----- 
              <BR><B>From:</B> <A href="mailto:[email-masked]">Zafar Ali</A> 
              <BR><B>To:</B> <A href="mailto:[email-masked]">Manoj 
              Agiwal</A> ; <A href="mailto:[email-masked]">'Ccamp 
              (E-mail)</A> <BR><B>Cc:</B> <A 
              href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET (E-mail)</A> 
              <BR><B>Sent:</B> Wednesday, May 08, 2002 11:04 
              AM<BR><B>Subject:</B> Re: Label Set Object<BR><BR>At 10:00 AM 
              5/8/2002 +0530, Manoj Agiwal wrote:<BR>
              <BLOCKQUOTE cite type="cite">Hi 
                ,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling 
                extensionsions for RSVP-TE , ccamp architecture on<BR>gmpls has 
                described Label Set object usage<BR>&nbsp;&nbsp;&nbsp; only for 
                the "optical" domain viz. for carrying wavelengths ( 
                Section<BR>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . 
                <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to 
                send Label set(i.e. time slots) for TDM switching as<BR>well . 
                In what way it can be useful . </BLOCKQUOTE><BR>Dear Manoj, 
              <BR><BR>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.<BR>&nbsp;The label set 
              object can be used to constrain the downstream label to the same 
              as the upstream label. <BR><BR>Thanks<BR><BR>Regards... Zafar 
              <BR><BR><BR><BR>
              <BLOCKQUOTE cite type="cite">Regards 
              ,<BR>Manoj</BLOCKQUOTE><BR>===============<BR>Zafar Ali<BR>Cisco 
              Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, 
              <U>MI 48104</U>.<BR>email: <FONT color=#0000ff 
              size=3><U>[email-masked]</U></FONT><FONT size=3> 
          </BLOCKQUOTE></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F6CB.F6C16CF0--

Delivery-date: Wed, 08 May 2002 11:59:02 -0700
From: "Juneja, Manoj" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "Juneja, Manoj"<[email-masked]>, "'Zafar Ali'" <[email-masked]>, Vinay Vernekar<[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 11:57:06 -0700 

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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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 <mailto:[email-masked]>  
To: Manoj  <mailto:[email-masked]> Agiwal ; 'Ccamp (E-mail)
<mailto:[email-masked]>  
Cc: mpls@UU. NET  <mailto:mpls@UU. NET (E-mail)> (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: [email-masked] 

------_=_NextPart_001_01C1F6C2.263154A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3502.4856" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=197215618-08052002>Hi 
Jonh,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=197215618-08052002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Sorry for creating the confusion. Should the label set be used for establishing 
the SDH/SONET LSPs ? </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=197215618-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=197215618-08052002>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=197215618-08052002>manoj.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Drake 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:50 
  AM<BR><B>To:</B> 'Juneja, Manoj'; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 
  'Ccamp (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: 
  Label Set Object<BR><BR></DIV></FONT>
  <DIV><SPAN class=427385018-08052002><FONT color=#0000ff face=Arial size=2>I 
  didn't say that.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Juneja, Manoj 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:48 
    AM<BR><B>To:</B> John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 
    'Ccamp (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: 
    Label Set Object<BR><BR></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=561354618-08052002>Hi 
    John,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=561354618-08052002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Did u mean Explicit label control is used only for SDH/SONET case&nbsp; 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.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=561354618-08052002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=561354618-08052002>Regards,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=561354618-08052002>manoj.</SPAN></FONT></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> John Drake 
      [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:26 
      AM<BR><B>To:</B> 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp 
      (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: Label 
      Set Object<BR><BR></DIV></FONT>
      <DIV>Explicit Label Control<SPAN class=647072218-08052002> is used to 
      handle the SONET/SDH case.&nbsp; Its semantics are different&nbsp;than 
      Label Set, in the sense that there is one and only one value, rather than 
      a set that is manipulated end-end&nbsp;</SPAN></DIV>
      <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=647072218-08052002>Thanks,</SPAN></DIV>
      <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=647072218-08052002>John</SPAN></DIV>
      <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=647072218-08052002></SPAN><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Zafar Ali 
      [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 10:31 
      AM<BR><B>To:</B> Vinay Vernekar; Manoj Agiwal; 'Ccamp 
      (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> Re: Label 
      Set Object<BR><BR></DIV></FONT>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"><FONT size=3>Dear Vinay, 
        <BR><BR>Please see comments in-lined. <BR><BR>Thanks<BR><BR>Regards... 
        Zafar <BR>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:<BR></FONT>
        <BLOCKQUOTE type="cite" cite><FONT face=arial size=3>Hi 
          Zafar,</FONT><BR><FONT face=arial size=3>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". </FONT></BLOCKQUOTE><BR>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? <BR><BR>
        <BLOCKQUOTE type="cite" cite><FONT face=arial size=3>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.</FONT></BLOCKQUOTE><BR>IMHO this would be an undesirable 
        restriction. Why its cannot cover the single label case in SONET? 
        <BR><BR>
        <BLOCKQUOTE type="cite" cite><FONT face=arial size=3>Correct me if I 
          am going wrong anywhere.</FONT><BR>&nbsp;<BR><FONT face=arial 
          size=3>Regards</FONT><BR><FONT face=arial 
          size=3>Vinay&nbsp;&nbsp;&nbsp; </FONT><BR>
          <BLOCKQUOTE type="cite" cite>----- Original Message ----- 
            <BR><B>From:</B> <A href="mailto:[email-masked]">Zafar Ali</A> 
            <BR><B>To:</B> <A href="mailto:[email-masked]">Manoj 
            Agiwal</A> ; <A href="mailto:[email-masked]">'Ccamp (E-mail)</A> 
            <BR><B>Cc:</B> <A href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET 
            (E-mail)</A> <BR><B>Sent:</B> Wednesday, May 08, 2002 11:04 
            AM<BR><B>Subject:</B> Re: Label Set Object<BR><BR>At 10:00 AM 
            5/8/2002 +0530, Manoj Agiwal wrote:<BR>
            <BLOCKQUOTE type="cite" cite>Hi 
              ,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling 
              extensionsions for RSVP-TE , ccamp architecture on<BR>gmpls has 
              described Label Set object usage<BR>&nbsp;&nbsp;&nbsp; only for 
              the "optical" domain viz. for carrying wavelengths ( 
              Section<BR>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . 
              <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send 
              Label set(i.e. time slots) for TDM switching as<BR>well . In what 
              way it can be useful . </BLOCKQUOTE><BR>Dear Manoj, <BR><BR>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.<BR>&nbsp;The label set object can be used to 
            constrain the downstream label to the same as the upstream label. 
            <BR><BR>Thanks<BR><BR>Regards... Zafar <BR><BR><BR><BR>
            <BLOCKQUOTE type="cite" cite>Regards 
            ,<BR>Manoj</BLOCKQUOTE><BR>===============<BR>Zafar Ali<BR>Cisco 
            Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI 
            48104</U>.<BR>email: <FONT color=#0000ff 
            size=3><U>[email-masked]</U></FONT><FONT size=3> 
        </BLOCKQUOTE></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F6C2.263154A0--

Delivery-date: Wed, 08 May 2002 11:49:49 -0700
From: John Drake <[email-masked]>
To: "'Juneja, Manoj'" <[email-masked]>, 'Zafar Ali' <[email-masked]>, Vinay Vernekar <[email-masked]>,  Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 11:49:35 -0700 

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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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 <mailto:[email-masked]>  
To: Manoj Agiwal <mailto:[email-masked]>  ; 'Ccamp (E-mail)
<mailto:[email-masked]>  
Cc: mpls@UU. NET  <mailto:mpls@UU. NET (E-mail)> (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: [email-masked] 

------_=_NextPart_001_01C1F6C1.18E89020
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=427385018-08052002><FONT face=Arial color=#0000ff size=2>I 
didn't say that.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Juneja, Manoj 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:48 
  AM<BR><B>To:</B> John Drake; 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp 
  (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: Label Set 
  Object<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=561354618-08052002>Hi 
  John,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=561354618-08052002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Did u mean Explicit label control is used only for SDH/SONET case&nbsp; 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.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=561354618-08052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=561354618-08052002>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=561354618-08052002>manoj.</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> John Drake 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:26 
    AM<BR><B>To:</B> 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp 
    (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: Label 
    Set Object<BR><BR></DIV></FONT>
    <DIV>Explicit Label Control<SPAN class=647072218-08052002> is used to handle 
    the SONET/SDH case.&nbsp; Its semantics are different&nbsp;than Label Set, 
    in the sense that there is one and only one value, rather than a set that is 
    manipulated end-end&nbsp;</SPAN></DIV>
    <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=647072218-08052002>Thanks,</SPAN></DIV>
    <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=647072218-08052002>John</SPAN></DIV>
    <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=647072218-08052002></SPAN><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Zafar Ali 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 10:31 
    AM<BR><B>To:</B> Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)<BR><B>Cc:</B> 
    mpls@UU. NET (E-mail)<BR><B>Subject:</B> Re: Label Set 
    Object<BR><BR></DIV></FONT>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"><FONT size=3>Dear Vinay, 
      <BR><BR>Please see comments in-lined. <BR><BR>Thanks<BR><BR>Regards... 
      Zafar <BR>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:<BR></FONT>
      <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>Hi 
        Zafar,</FONT><BR><FONT face=arial size=3>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". </FONT></BLOCKQUOTE><BR>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? <BR><BR>
      <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>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.</FONT></BLOCKQUOTE><BR>IMHO this would be an undesirable 
      restriction. Why its cannot cover the single label case in SONET? <BR><BR>
      <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>Correct me if I am 
        going wrong anywhere.</FONT><BR>&nbsp;<BR><FONT face=arial 
        size=3>Regards</FONT><BR><FONT face=arial size=3>Vinay&nbsp;&nbsp;&nbsp; 
        </FONT><BR>
        <BLOCKQUOTE cite type="cite">----- Original Message ----- 
          <BR><B>From:</B> <A href="mailto:[email-masked]">Zafar Ali</A> 
          <BR><B>To:</B> <A href="mailto:[email-masked]">Manoj Agiwal</A> 
          ; <A href="mailto:[email-masked]">'Ccamp (E-mail)</A> 
          <BR><B>Cc:</B> <A href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET 
          (E-mail)</A> <BR><B>Sent:</B> Wednesday, May 08, 2002 11:04 
          AM<BR><B>Subject:</B> Re: Label Set Object<BR><BR>At 10:00 AM 5/8/2002 
          +0530, Manoj Agiwal wrote:<BR>
          <BLOCKQUOTE cite type="cite">Hi 
            ,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling 
            extensionsions for RSVP-TE , ccamp architecture on<BR>gmpls has 
            described Label Set object usage<BR>&nbsp;&nbsp;&nbsp; only for the 
            "optical" domain viz. for carrying wavelengths ( Section<BR>9.9 
            draft-ietf-ccamp-gmpls-architecture-02.txt) . 
            <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send 
            Label set(i.e. time slots) for TDM switching as<BR>well . In what 
            way it can be useful . </BLOCKQUOTE><BR>Dear Manoj, <BR><BR>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.<BR>&nbsp;The label set object can be used to constrain the 
          downstream label to the same as the upstream label. 
          <BR><BR>Thanks<BR><BR>Regards... Zafar <BR><BR><BR><BR>
          <BLOCKQUOTE cite type="cite">Regards 
          ,<BR>Manoj</BLOCKQUOTE><BR>===============<BR>Zafar Ali<BR>Cisco 
          Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI 
          48104</U>.<BR>email: <FONT color=#0000ff 
          size=3><U>[email-masked]</U></FONT><FONT size=3> 
      </BLOCKQUOTE></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F6C1.18E89020--

Delivery-date: Wed, 08 May 2002 11:48:51 -0700
From: "Juneja, Manoj" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Zafar Ali'" <[email-masked]>, Vinay Vernekar <[email-masked]>, Manoj Agiwal<[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 11:48:11 -0700 

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:[email-masked]]
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:[email-masked]]
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 <mailto:[email-masked]>  
To: Manoj Agiwal <mailto:[email-masked]>  ; 'Ccamp (E-mail)
<mailto:[email-masked]>  
Cc: mpls@UU. NET (E-mail) <mailto: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: [email-masked] 

------_=_NextPart_001_01C1F6C0.E72A7E40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3502.4856" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=561354618-08052002>Hi 
John,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=561354618-08052002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Did u mean Explicit label control is used only for SDH/SONET case&nbsp; 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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=561354618-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=561354618-08052002>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=561354618-08052002>manoj.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Drake 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 11:26 
  AM<BR><B>To:</B> 'Zafar Ali'; Vinay Vernekar; Manoj Agiwal; 'Ccamp 
  (E-mail)<BR><B>Cc:</B> mpls@UU. NET (E-mail)<BR><B>Subject:</B> RE: Label Set 
  Object<BR><BR></DIV></FONT>
  <DIV>Explicit Label Control<SPAN class=647072218-08052002> is used to handle 
  the SONET/SDH case.&nbsp; Its semantics are different&nbsp;than Label Set, in 
  the sense that there is one and only one value, rather than a set that is 
  manipulated end-end&nbsp;</SPAN></DIV>
  <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=647072218-08052002>Thanks,</SPAN></DIV>
  <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=647072218-08052002>John</SPAN></DIV>
  <DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=647072218-08052002></SPAN><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Zafar Ali 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 10:31 
  AM<BR><B>To:</B> Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)<BR><B>Cc:</B> 
  mpls@UU. NET (E-mail)<BR><B>Subject:</B> Re: Label Set 
  Object<BR><BR></DIV></FONT>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"><FONT size=3>Dear Vinay, 
    <BR><BR>Please see comments in-lined. <BR><BR>Thanks<BR><BR>Regards... Zafar 
    <BR>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:<BR></FONT>
    <BLOCKQUOTE type="cite" cite><FONT face=arial size=3>Hi 
      Zafar,</FONT><BR><FONT face=arial size=3>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". </FONT></BLOCKQUOTE><BR>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? <BR><BR>
    <BLOCKQUOTE type="cite" cite><FONT face=arial size=3>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.</FONT></BLOCKQUOTE><BR>IMHO this would be an undesirable 
    restriction. Why its cannot cover the single label case in SONET? <BR><BR>
    <BLOCKQUOTE type="cite" cite><FONT face=arial size=3>Correct me if I am 
      going wrong anywhere.</FONT><BR>&nbsp;<BR><FONT face=arial 
      size=3>Regards</FONT><BR><FONT face=arial size=3>Vinay&nbsp;&nbsp;&nbsp; 
      </FONT><BR>
      <BLOCKQUOTE type="cite" cite>----- Original Message ----- 
        <BR><B>From:</B> <A href="mailto:[email-masked]">Zafar Ali</A> 
        <BR><B>To:</B> <A href="mailto:[email-masked]">Manoj Agiwal</A> ; 
        <A href="mailto:[email-masked]">'Ccamp (E-mail)</A> <BR><B>Cc:</B> 
        <A href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET (E-mail)</A> 
        <BR><B>Sent:</B> Wednesday, May 08, 2002 11:04 AM<BR><B>Subject:</B> Re: 
        Label Set Object<BR><BR>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal 
        wrote:<BR>
        <BLOCKQUOTE type="cite" cite>Hi 
          ,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling 
          extensionsions for RSVP-TE , ccamp architecture on<BR>gmpls has 
          described Label Set object usage<BR>&nbsp;&nbsp;&nbsp; only for the 
          "optical" domain viz. for carrying wavelengths ( Section<BR>9.9 
          draft-ietf-ccamp-gmpls-architecture-02.txt) . 
          <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send 
          Label set(i.e. time slots) for TDM switching as<BR>well . In what way 
          it can be useful . </BLOCKQUOTE><BR>Dear Manoj, <BR><BR>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.<BR>&nbsp;The label set object can be used to constrain the 
        downstream label to the same as the upstream label. 
        <BR><BR>Thanks<BR><BR>Regards... Zafar <BR><BR><BR><BR>
        <BLOCKQUOTE type="cite" cite>Regards 
        ,<BR>Manoj</BLOCKQUOTE><BR>===============<BR>Zafar Ali<BR>Cisco 
        Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI 
        48104</U>.<BR>email: <FONT color=#0000ff 
        size=3><U>[email-masked]</U></FONT><FONT size=3> 
    </BLOCKQUOTE></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F6C0.E72A7E40--

Delivery-date: Wed, 08 May 2002 11:41:46 -0700
To: [email-masked]
cc: "Naidu, Venkata" <[email-masked]>, "'???'" <[email-masked]>, [email-masked], CCAMP <[email-masked]>, [email-masked]
Subject: Re: How many can administrative groups assigned? 
Date: Wed, 08 May 2002 14:22:11 -0400
From: Curtis Villamizar <[email-masked]>

[ 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 <[email-masked]>, sven.van_d
[email-masked] 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

Delivery-date: Wed, 08 May 2002 11:27:42 -0700
From: John Drake <[email-masked]>
To: 'Zafar Ali' <[email-masked]>, Vinay Vernekar <[email-masked]>, Manoj Agiwal <[email-masked]>,  "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: RE: Label Set Object
Date: Wed, 8 May 2002 11:25:57 -0700 

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:[email-masked]]
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 <mailto:[email-masked]>  
To: Manoj Agiwal <mailto:[email-masked]>  ; 'Ccamp (E-mail)
<mailto:[email-masked]>  
Cc: mpls@UU. NET (E-mail) <mailto: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: [email-masked] 

------_=_NextPart_001_01C1F6BD.CC167440
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV>Explicit Label Control<SPAN class=647072218-08052002> is used to handle the 
SONET/SDH case.&nbsp; Its semantics are different&nbsp;than Label Set, in the 
sense that there is one and only one value, rather than a set that is 
manipulated end-end&nbsp;</SPAN></DIV>
<DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
<DIV><SPAN class=647072218-08052002>Thanks,</SPAN></DIV>
<DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
<DIV><SPAN class=647072218-08052002>John</SPAN></DIV>
<DIV><SPAN class=647072218-08052002></SPAN>&nbsp;</DIV>
<DIV><SPAN class=647072218-08052002></SPAN><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Zafar Ali 
[mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, May 08, 2002 10:31 
AM<BR><B>To:</B> Vinay Vernekar; Manoj Agiwal; 'Ccamp (E-mail)<BR><B>Cc:</B> 
mpls@UU. NET (E-mail)<BR><B>Subject:</B> Re: Label Set 
Object<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"><FONT size=3>Dear Vinay, 
  <BR><BR>Please see comments in-lined. <BR><BR>Thanks<BR><BR>Regards... Zafar 
  <BR>At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:<BR></FONT>
  <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>Hi 
    Zafar,</FONT><BR><FONT face=arial size=3>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". </FONT></BLOCKQUOTE><BR>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? <BR><BR>
  <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>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.</FONT></BLOCKQUOTE><BR>IMHO this would be an undesirable 
  restriction. Why its cannot cover the single label case in SONET? <BR><BR>
  <BLOCKQUOTE cite type="cite"><FONT face=arial size=3>Correct me if I am 
    going wrong anywhere.</FONT><BR>&nbsp;<BR><FONT face=arial 
    size=3>Regards</FONT><BR><FONT face=arial size=3>Vinay&nbsp;&nbsp;&nbsp; 
    </FONT><BR>
    <BLOCKQUOTE cite type="cite">----- Original Message ----- <BR><B>From:</B> 
      <A href="mailto:[email-masked]">Zafar Ali</A> <BR><B>To:</B> <A 
      href="mailto:[email-masked]">Manoj Agiwal</A> ; <A 
      href="mailto:[email-masked]">'Ccamp (E-mail)</A> <BR><B>Cc:</B> <A 
      href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET (E-mail)</A> 
      <BR><B>Sent:</B> Wednesday, May 08, 2002 11:04 AM<BR><B>Subject:</B> Re: 
      Label Set Object<BR><BR>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal 
wrote:<BR>
      <BLOCKQUOTE cite type="cite">Hi 
        ,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling 
        extensionsions for RSVP-TE , ccamp architecture on<BR>gmpls has 
        described Label Set object usage<BR>&nbsp;&nbsp;&nbsp; only for the 
        "optical" domain viz. for carrying wavelengths ( Section<BR>9.9 
        draft-ietf-ccamp-gmpls-architecture-02.txt) . 
        <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send Label 
        set(i.e. time slots) for TDM switching as<BR>well . In what way it can 
        be useful . </BLOCKQUOTE><BR>Dear Manoj, <BR><BR>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.<BR>&nbsp;The label 
      set object can be used to constrain the downstream label to the same as 
      the upstream label. <BR><BR>Thanks<BR><BR>Regards... Zafar 
<BR><BR><BR><BR>
      <BLOCKQUOTE cite type="cite">Regards 
      ,<BR>Manoj</BLOCKQUOTE><BR>===============<BR>Zafar Ali<BR>Cisco 
      Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI 
      48104</U>.<BR>email: <FONT color=#0000ff 
      size=3><U>[email-masked]</U></FONT><FONT size=3> 
  </BLOCKQUOTE></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F6BD.CC167440--

Delivery-date: Wed, 08 May 2002 10:33:14 -0700
Date: Wed, 08 May 2002 13:31:09 -0400
To: "Vinay Vernekar" <[email-masked]>, "Manoj Agiwal" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Label Set Object
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>

--=====================_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: <mailto:[email-masked]>Zafar Ali
>>To: <mailto:[email-masked]>Manoj Agiwal ; 
>><mailto:[email-masked]>'Ccamp (E-mail)
>>Cc: <mailto:mpls@UU. NET (E-mail)>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: [email-masked]

--=====================_14391804==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Dear Vinay, <br>
<br>
Please see comments in-lined. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
At 07:56 PM 5/8/2002 +0530, Vinay Vernekar wrote:<br>
</font><blockquote type=cite cite><font face="arial" size=3>Hi
Zafar,</font><br>
<font face="arial" size=3>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 &quot;Generalized MPLS - Signalling
Functional Description -
draft-ietf-mpls-generalized-signaling-08.txt&quot;.
</font></blockquote><br>
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? <br>
<br>
<blockquote type=cite cite><font face="arial" size=3>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.</font></blockquote><br>
IMHO this would be an undesirable restriction. Why its cannot cover the
single label case in SONET? <br>
<br>
<blockquote type=cite cite><font face="arial" size=3>Correct me if I am
going wrong anywhere.</font><br>
&nbsp;<br>
<font face="arial" size=3>Regards</font><br>
<font face="arial" size=3>Vinay&nbsp;&nbsp;&nbsp; </font><br>
<blockquote type=cite cite>----- Original Message ----- <br>
<b>From:</b> <a href="mailto:[email-masked]">Zafar Ali</a> <br>
<b>To:</b> <a href="mailto:[email-masked]">Manoj Agiwal</a> ;
<a href="mailto:[email-masked]">'Ccamp (E-mail)</a> <br>
<b>Cc:</b> <a href="mailto:mpls@UU. NET (E-mail)">mpls@UU. NET
(E-mail)</a> <br>
<b>Sent:</b> Wednesday, May 08, 2002 11:04 AM<br>
<b>Subject:</b> Re: Label Set Object<br>
<br>
At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:<br>
<blockquote type=cite cite>Hi ,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling extensionsions
for RSVP-TE , ccamp architecture on<br>
gmpls has described Label Set object usage<br>
&nbsp;&nbsp;&nbsp; only for the &quot;optical&quot; domain viz. for
carrying wavelengths ( Section<br>
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send Label set(i.e.
time slots) for TDM switching as<br>
well . In what way it can be useful . </blockquote><br>
Dear Manoj, <br>
<br>
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.<br>
&nbsp;The label set object can be used to constrain the downstream label
to the same as the upstream label. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<br>
<blockquote type=cite cite>Regards ,<br>
Manoj</blockquote><br>
===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email:
<font size=3 color="#0000FF"><u>[email-masked]</u></font><font size=3>
</blockquote></font></blockquote></html>

--=====================_14391804==_.ALT--

Delivery-date: Wed, 08 May 2002 10:08:58 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Cc: "Alex Zinin (E-mail)" <[email-masked]>
Subject: new Technical Advisor
Date: Wed, 8 May 2002 19:05:54 +0200 

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 

Delivery-date: Wed, 08 May 2002 07:47:14 -0700
Date: Wed, 08 May 2002 16:46:08 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: Yangguang Xu <[email-masked]>
CC: [email-masked]
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 : [email-masked] 
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

Delivery-date: Wed, 08 May 2002 07:31:43 -0700
From: "Vinay Vernekar" <[email-masked]>
To: "Manoj Agiwal" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "Zafar Ali" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Label Set Object
Date: Wed, 8 May 2002 19:56:34 +0530

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: [email-masked]=20

------=_NextPart_000_00FD_01C1F6CA.74917140
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Hi Zafar,</FONT></DIV>
<DIV><FONT face=3DArial>The Label Set Object can't be sent&nbsp;to =
constrain the=20
downstream label when the LSP encoding type is&nbsp;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&nbsp;object/TLV structure of Label Set as in =

"Generalized MPLS - Signalling Functional Description -=20
draft-ietf-mpls-generalized-signaling-08.txt".&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial>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.</FONT></DIV>
<DIV><FONT face=3DArial>Correct me if I am going wrong =
anywhere.</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>Regards</FONT></DIV>
<DIV><FONT face=3DArial>Vinay&nbsp;&nbsp;&nbsp; </FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[email-masked]" title=[email-masked]>Zafar Ali</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Manoj Agiwal</A> ; <A=20
  href=3D"mailto:[email-masked]" title=[email-masked]>'Ccamp =
(E-mail)</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
  href=3D"mailto:mpls@UU. NET (E-mail)" title=[email-masked]>mpls@UU. NET =

  (E-mail)</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, May 08, 2002 =
11:04=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Label Set =
Object</DIV>
  <DIV><BR></DIV><FONT size=3D3>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal =

wrote:<BR>
  <BLOCKQUOTE cite type=3D"cite">Hi =
,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In=20
    gmpls signaling extensionsions for RSVP-TE , ccamp architecture =
on<BR>gmpls=20
    has described Label Set object usage<BR>&nbsp;&nbsp;&nbsp; only for =
the=20
    "optical" domain viz. for carrying wavelengths ( Section<BR>9.9=20
    draft-ietf-ccamp-gmpls-architecture-02.txt) .=20
    <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send =
Label=20
    set(i.e. time slots) for TDM switching as<BR>well . In what way it =
can be=20
    useful . </FONT></BLOCKQUOTE><BR><FONT size=3D3>Dear Manoj, =
<BR><BR>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.<BR>&nbsp;The label set object can be used to constrain the =

  downstream label to the same as the upstream label.=20
  <BR><BR>Thanks<BR><BR>Regards... Zafar <BR><BR><BR><BR>
  <BLOCKQUOTE cite type=3D"cite">Regards=20
  =
,<BR>Manoj</BLOCKQUOTE><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR>Zafar Ali<BR>Cisco=20
  Systems<BR>(734) 276-2459<BR>100 S Main St. #200<BR>Ann Arbor, <U>MI=20
  48104</U>.<BR>email: </FONT><FONT color=3D#0000ff=20
  size=3D3><U>[email-masked]</FONT></U> </BLOCKQUOTE></BODY></HTML>

------=_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--

Delivery-date: Wed, 08 May 2002 07:02:16 -0700
Date: Wed, 08 May 2002 10:00:54 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: LMP & neighbor discovery

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

Delivery-date: Wed, 08 May 2002 06:17:26 -0700
From: "Ravi Sankar Mantha" <[email-masked]>
To: <[email-masked]>, "Naidu Venkata" <[email-masked]>
Cc: "'???'" <[email-masked]>, <[email-masked]>, "CCAMP" <[email-masked]>, <[email-masked]>
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: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, May 08, 2002 1:46 PM
To: Naidu, Venkata
Cc: '???'; [email-masked]; CCAMP; [email-masked]
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" <[email-masked]> on 07/05/2002 16:16:29

  To:          "'???'" <[email-masked]>,
               [email-masked], CCAMP <[email-masked]>,
               [email-masked]

  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--

Delivery-date: Wed, 08 May 2002 03:27:21 -0700
Date: Wed, 08 May 2002 12:24:55 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: Zhi-Wei Lin <[email-masked]>
Cc: Martin Dubuc <[email-masked]>, Michiel van Everdingen <[email-masked]>, [email-masked]
Subject: Re: LMP & neighbor discovery

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:[email-masked]]
> >Sent: Tuesday, May 07, 2002 11:42 AM
> >To: [email-masked]
> >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 : [email-masked] 
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

Delivery-date: Wed, 08 May 2002 01:17:23 -0700
Subject: RE: How many can administrative groups assigned?
To: "Naidu, Venkata" <[email-masked]>
Cc: "'???'" <[email-masked]>, [email-masked], CCAMP <[email-masked]>, [email-masked]
From: [email-masked]
Date: Wed, 8 May 2002 10:15:50 +0200

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" <[email-masked]> on 07/05/2002 16:16:29

                                                              
  To:          "'???'" <[email-masked]>,             
               [email-masked], CCAMP <[email-masked]>,       
               [email-masked]                             
                                                              
  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.

Delivery-date: Tue, 07 May 2002 22:53:59 -0700
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
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

Delivery-date: Tue, 07 May 2002 22:53:53 -0700
Date: Wed, 08 May 2002 01:53:05 -0400
To: Manoj Agiwal <[email-masked]>, Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: RE: Label Set Object
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>

--=====================_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:[email-masked]]
>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: [email-masked]
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: [email-masked]

--=====================_11732159==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 11:11 AM 5/8/2002 +0530, Manoj Agiwal wrote:<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Hi
,</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">&nbsp;&nbsp; I guess in
that case we can use Suggested Label , Label Set still can still be
avoided .</font></blockquote><br>
<font size=3>Hi Manoj, <br>
<br>
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. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Regards
,</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Manoj</font><font size=3></font>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Zafar Ali
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Wednesday, May 08, 2002 11:05 AM
<dd>To:</b> Manoj Agiwal; 'Ccamp (E-mail)
<dd>Cc:</b> mpls@UU. NET (E-mail)
<dd>Subject:</b> Re: Label Set Object<br>
<br>
</font><font size=3>
<dd>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal
wrote:<blockquote type=cite cite>
<dd>Hi ,
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling
extensionsions for RSVP-TE , ccamp architecture on
<dd>gmpls has described Label Set object usage
<dd>&nbsp;&nbsp;&nbsp; only for the &quot;optical&quot; domain viz. for
carrying wavelengths ( Section
<dd>9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . <br>
<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send Label
set(i.e. time slots) for TDM switching as
<dd>well . In what way it can be useful . </blockquote>
<dd>Dear Manoj, <br>
<br>

<dd>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.
<dd>&nbsp;The label set object can be used to constrain the downstream
label to the same as the upstream label. <br>
<br>

<dd>Thanks<br>
<br>

<dd>Regards... Zafar <br>
<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dd>Regards ,
<dd>Manoj</blockquote>
<dd>===============
<dd>Zafar Ali
<dd>Cisco Systems
<dd>(734) 276-2459
<dd>100 S Main St. #200
<dd>Ann Arbor, MI 48104</u>.
<dd>email: </font><font size=3 color="#0000FF">[email-masked]</u></font>
</blockquote>
</dl><font size=3>===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email: </font><font size=3 color="#0000FF"><u>[email-masked]<br>
</font></u></html>

--=====================_11732159==_.ALT--

Delivery-date: Tue, 07 May 2002 22:36:30 -0700
Date: Wed, 08 May 2002 01:34:43 -0400
To: Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Label Set Object
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>

--=====================_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: [email-masked]
--=====================_10629654==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 10:00 AM 5/8/2002 +0530, Manoj Agiwal wrote:<br>
<blockquote type=cite cite>Hi ,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In gmpls signaling extensionsions
for RSVP-TE , ccamp architecture on<br>
gmpls has described Label Set object usage<br>
&nbsp;&nbsp;&nbsp; only for the &quot;optical&quot; domain viz. for
carrying wavelengths ( Section<br>
9.9 draft-ietf-ccamp-gmpls-architecture-02.txt) . <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we require to send Label set(i.e.
time slots) for TDM switching as<br>
well . In what way it can be useful . </font></blockquote><br>
<font size=3>Dear Manoj, <br>
<br>
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.<br>
&nbsp;The label set object can be used to constrain the downstream label
to the same as the upstream label. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<br>
<blockquote type=cite cite>Regards ,<br>
Manoj</blockquote><br>
===============<br>
Zafar Ali<br>
Cisco Systems<br>
(734) 276-2459<br>
100 S Main St. #200<br>
Ann Arbor, <u>MI 48104</u>.<br>
email:
</font><font size=3 color="#0000FF"><u>[email-masked]</font></u></html>

--=====================_10629654==_.ALT--

Delivery-date: Tue, 07 May 2002 17:42:07 -0700
Date: Tue, 7 May 2002 17:38:55 -0700 (PDT)
From: Fong Liaw <[email-masked]>
Subject: Re: Connection Deletion in GMPLS
To: manoj juneja <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]

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 <[email-masked]> 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

Delivery-date: Tue, 07 May 2002 14:17:23 -0700
Date: Tue, 07 May 2002 17:15:35 -0400
From: Zhi-Wei Lin <[email-masked]>
To: Martin Dubuc <[email-masked]>
CC: Michiel van Everdingen <[email-masked]>, [email-masked]
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:[email-masked]]
>Sent: Tuesday, May 07, 2002 11:42 AM
>To: [email-masked]
>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.
>
>
>  
>

Delivery-date: Tue, 07 May 2002 11:30:45 -0700
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Sudheer Dharanikota <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: RE: Static LSP Configuration 
Date: Tue, 7 May 2002 11:28:48 -0700 

What is the physical architecture? Is it still a ring? a single ring?

-Shahram

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 8:46 PM
> To: Shahram Davari
> Cc: [email-masked]'; Sudheer Dharanikota; Gary Tam; 
> Ajay Simha;
> Ron Bonica; Brijesh Kumar; [email-masked]; CCAMP WG
> Subject: Re: Static LSP Configuration 
> 
> 
> 
> In message 
> <[email-masked]
> > > 
> > > 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
> 

Delivery-date: Tue, 07 May 2002 10:05:32 -0700
content-class: urn:content-classes:message
Subject: RE: LMP & neighbor discovery
Date: Tue, 7 May 2002 13:02:13 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Michiel van Everdingen" <[email-masked]>, <[email-masked]>

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:[email-masked]]
Sent: Tuesday, May 07, 2002 11:42 AM
To: [email-masked]
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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Tue, 07 May 2002 08:43:38 -0700
Date: Tue, 07 May 2002 17:41:37 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
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.

-- 
+------------------------------------------------------------------+
| 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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Tue, 07 May 2002 08:14:07 -0700
content-class: urn:content-classes:message
Subject: draft submitted - "Optical Path Protection Signalling Performance Extension to RSVP"
Date: Tue, 7 May 2002 11:11:13 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Ron Bonica" <[email-masked]>

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: [email-masked]

Delivery-date: Tue, 07 May 2002 07:19:02 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'???'" <[email-masked]>, [email-masked], CCAMP <[email-masked]>, [email-masked]
Subject: RE: How many can administrative groups assigned?
Date: Tue, 7 May 2002 10:16:29 -0400 

Kim,

-> If so, how many can administrative groups assigned? 32 or 2^32 ?

  32. A link can me member of multiple admin groups.

--
Venkata.

Delivery-date: Tue, 07 May 2002 04:15:34 -0700
Date: Tue, 07 May 2002 12:35:39 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: Vinay Vernekar <[email-masked]>
CC: [email-masked]
Subject: Re: Doubt in applying the transforms in SONET/SDH traffic parameters.

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: [email-masked]
> 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 : [email-masked]=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

Delivery-date: Mon, 06 May 2002 21:02:30 -0700
Date: Tue, 07 May 2002 10:22:54 +0900
From: =?ks_c_5601-1987?B?sejB+Mf8?= <[email-masked]>
Subject: How many can administrative groups assigned?
To: [email-masked], CCAMP <[email-masked]>, [email-masked]

[ 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.

Delivery-date: Mon, 06 May 2002 21:00:07 -0700
To: Sudheer Dharanikota <[email-masked]>
cc: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: Re: Static LSP Configuration 
Date: Mon, 06 May 2002 20:48:59 -0400
From: Curtis Villamizar <[email-masked]>

[ 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 <[email-masked]>, 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

Delivery-date: Mon, 06 May 2002 20:59:32 -0700
To: Shahram Davari <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, Sudheer Dharanikota <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: Re: Static LSP Configuration 
Date: Mon, 06 May 2002 20:45:41 -0400
From: Curtis Villamizar <[email-masked]>

[ 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 <[email-masked]
> > 
> > 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

Delivery-date: Mon, 06 May 2002 20:59:14 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
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

Delivery-date: Mon, 06 May 2002 20:44:07 -0700
To: Sudheer Dharanikota <[email-masked]>
cc: Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, [email-masked], Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, "'Curtis Villamizar '" <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: Re: Static LSP Configuration 
Date: Mon, 06 May 2002 16:31:11 -0400
From: Curtis Villamizar <[email-masked]>

[ 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 <[email-masked]>, 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

Delivery-date: Mon, 06 May 2002 16:14:34 -0700
From: "Nagarajan, Ramesh (Ramesh)" <[email-masked]>
To: "'Sudheer Dharanikota'" <[email-masked]>
Cc: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: RE: Static LSP Configuration
Date: Mon, 6 May 2002 19:13:20 -0400 

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: [email-masked].
------------------------------------------------------------------------=
----
---------------------------------------------------

> ----------
> From: 	Sudheer Dharanikota[SMTP:[email-masked]]
> Sent: 	Monday, May 06, 2002 6:41 PM
> To: 	Nagarajan, Ramesh (Ramesh)
> Cc: 	Shahram Davari; [email-masked]'; Gary Tam; Ajay Simha; =
Ron
> Bonica; Brijesh Kumar; [email-masked]; 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: [email-masked].
> >
> =
------------------------------------------------------------------------=
--
> --
> > ---------------------------------------------------
> >
> > > ----------
> > > From:         Sudheer Dharanikota[SMTP:[email-masked]]
> > > Sent:         Monday, May 06, 2002 5:27 PM
> > > To:   Shahram Davari
> > > Cc:   [email-masked]'; Gary Tam; Ajay Simha; Ron Bonica;
> Brijesh
> > > Kumar; [email-masked]; CCAMP WG
> > > Subject:      Re: Static LSP Configuration
> > >
> > >
> > >
> > > Shahram Davari wrote:
> > >
> > > > Curtis,
> > > >
> > > > > -----Original Message-----
> > > > > From: Curtis Villamizar =
[mailto:[email-masked]]
> > > > > Sent: Monday, May 06, 2002 4:31 PM
> > > > > To: Sudheer Dharanikota
> > > > > Cc: Gary Tam; Ajay Simha; [email-masked]; Ron Bonica;
> Brijesh
> > > > > Kumar; 'Curtis Villamizar '; [email-masked]; CCAMP WG
> > > > > Subject: Re: Static LSP Configuration
> > > > >
> > > > >
> > > > >
> > > > > In message <[email-masked]>, 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

Delivery-date: Mon, 06 May 2002 15:48:55 -0700
Date: Mon, 06 May 2002 15:41:42 -0700
From: Sudheer Dharanikota <[email-masked]>
To: "Nagarajan, Ramesh (Ramesh)" <[email-masked]>
CC: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: Re: Static LSP Configuration

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: [email-masked].
> ----------------------------------------------------------------------------
> ---------------------------------------------------
>
> > ----------
> > From:         Sudheer Dharanikota[SMTP:[email-masked]]
> > Sent:         Monday, May 06, 2002 5:27 PM
> > To:   Shahram Davari
> > Cc:   [email-masked]'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh
> > Kumar; [email-masked]; CCAMP WG
> > Subject:      Re: Static LSP Configuration
> >
> >
> >
> > Shahram Davari wrote:
> >
> > > Curtis,
> > >
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:[email-masked]]
> > > > Sent: Monday, May 06, 2002 4:31 PM
> > > > To: Sudheer Dharanikota
> > > > Cc: Gary Tam; Ajay Simha; [email-masked]; Ron Bonica; Brijesh
> > > > Kumar; 'Curtis Villamizar '; [email-masked]; CCAMP WG
> > > > Subject: Re: Static LSP Configuration
> > > >
> > > >
> > > >
> > > > In message <[email-masked]>, 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
> > > >
> >
> >

Delivery-date: Mon, 06 May 2002 15:06:02 -0700
From: "Nagarajan, Ramesh (Ramesh)" <[email-masked]>
To: Shahram Davari <[email-masked]>, "'Sudheer Dharanikota'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: RE: Static LSP Configuration
Date: Mon, 6 May 2002 18:04:40 -0400 

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: [email-masked].
----------------------------------------------------------------------------
---------------------------------------------------

> ----------
> From: 	Sudheer Dharanikota[SMTP:[email-masked]]
> Sent: 	Monday, May 06, 2002 5:27 PM
> To: 	Shahram Davari
> Cc: 	[email-masked]'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh
> Kumar; [email-masked]; CCAMP WG
> Subject: 	Re: Static LSP Configuration
> 
> 
> 
> Shahram Davari wrote:
> 
> > Curtis,
> >
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:[email-masked]]
> > > Sent: Monday, May 06, 2002 4:31 PM
> > > To: Sudheer Dharanikota
> > > Cc: Gary Tam; Ajay Simha; [email-masked]; Ron Bonica; Brijesh
> > > Kumar; 'Curtis Villamizar '; [email-masked]; CCAMP WG
> > > Subject: Re: Static LSP Configuration
> > >
> > >
> > >
> > > In message <[email-masked]>, 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
> > >
> 
> 

Delivery-date: Mon, 06 May 2002 14:35:56 -0700
Date: Mon, 06 May 2002 14:27:26 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Shahram Davari <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: Re: Static LSP Configuration

Shahram Davari wrote:

> Curtis,
>
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[email-masked]]
> > Sent: Monday, May 06, 2002 4:31 PM
> > To: Sudheer Dharanikota
> > Cc: Gary Tam; Ajay Simha; [email-masked]; Ron Bonica; Brijesh
> > Kumar; 'Curtis Villamizar '; [email-masked]; CCAMP WG
> > Subject: Re: Static LSP Configuration
> >
> >
> >
> > In message <[email-masked]>, 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
> >

Delivery-date: Mon, 06 May 2002 13:58:11 -0700
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Sudheer Dharanikota <[email-masked]>
Cc: Gary Tam <[email-masked]>, Ajay Simha <[email-masked]>, Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: RE: Static LSP Configuration 
Date: Mon, 6 May 2002 13:56:23 -0700 

Curtis,

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 4:31 PM
> To: Sudheer Dharanikota
> Cc: Gary Tam; Ajay Simha; [email-masked]; Ron Bonica; Brijesh
> Kumar; 'Curtis Villamizar '; [email-masked]; CCAMP WG
> Subject: Re: Static LSP Configuration 
> 
> 
> 
> In message <[email-masked]>, 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
> 

Delivery-date: Mon, 06 May 2002 11:07:38 -0700
Date: Mon, 06 May 2002 10:58:20 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Gary Tam <[email-masked]>
CC: Ajay Simha <[email-masked]>, [email-masked], Ron Bonica <[email-masked]>, Brijesh Kumar <[email-masked]>, "'Curtis Villamizar '" <[email-masked]>, [email-masked], CCAMP WG <[email-masked]>
Subject: Re: Static LSP Configuration

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 <[email-masked]> 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><[email-masked]> wrote:
> > GT>>
> > GT>> In message
> > GT>>
> >
> GT><[email-masked]>,
> > 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 <gee I
> > 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

Delivery-date: Mon, 06 May 2002 02:26:05 -0700
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 06 May 2002 11:25:21 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: "[email-masked]" <[email-masked]>
Subject: Re: Question on LMP

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:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Mon, 06 May 2002 02:05:55 -0700
From: "Vinay Vernekar" <[email-masked]>
To: <[email-masked]>
Subject: Doubt in applying the transforms in SONET/SDH traffic parameters.
Date: Mon, 6 May 2002 14:29:55 +0530

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: [email-masked]
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Hi,</FONT></DIV>
<DIV><FONT face=3DArial>The draft =
"draft-ietf-ccamp-gmpls-sonet-sdh-04.txt"=20
specifies as follows for the traffic parameters -</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>&nbsp; "Each transform is optional and must be =
ignored if=20
zero, except&nbsp;MT that cannot be zero and is ignored if equal to=20
one"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>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&nbsp;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. </FONT></DIV>
<DIV><FONT face=3DArial>The same argument holds good for other traffic =
parameters=20
also. </FONT></DIV>
<DIV><FONT face=3DArial>Kindly reqly back if I am missing something....=20
</FONT></DIV>
<DIV><FONT face=3DArial>Thanks in advance.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Regards</FONT></DIV>
<DIV><FONT face=3DArial>Vinay</FONT></DIV>
<DIV><FONT=20
face=3DArial>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Yesterda=
y is=20
history. Tomorrow is mystery.<BR>Today is a gift. That&#8217;s why =
it&#8217;s called the=20
Present!!<BR>************************************************************=
*****************<BR>Vinay=20
H. Vernekar<BR>Sr. Software Engineer - Global R&amp;D Solutions<BR>Wipro =

Technologies<BR>No.26, Hosur Main Road, Bommanahalli,<BR>Bangalore-560 =
068,=20
India.<BR>Tel: 91-80-5722293/5722296 Extn. 4019<BR>Fax: =
91-80-5722696<BR>Email:=20
<A =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
The=20
World's First SEI CMM Level 5 Software Services=20
Company<BR>**************************************************************=
***************<BR></FONT></DIV></BODY></HTML>

------=_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--

Delivery-date: Sat, 04 May 2002 10:29:48 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
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

Delivery-date: Fri, 03 May 2002 07:07:24 -0700
To: [email-masked]
Subject: -07 version
Date: Fri, 03 May 2002 07:04:55 -0700
From: Yakov Rekhter <[email-masked]>

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:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Delivery-date: Fri, 03 May 2002 04:30:34 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 03 May 2002 01:52:13 -0700
To: "Gino Carrozzo" <[email-masked]>
Cc: "Zafar Ali" <[email-masked]>, [email-masked], "ccamp" <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 3 May 2002 10:50:42 +0200
Subject: Re: Path TLV 

--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" <[email-masked]> on 03/05/2002 10:30:02

                                                              
  To:          "Zafar Ali" <[email-masked]>                   
                                                              
  cc:          [email-masked], "ccamp"                   
               <[email-masked]>, [email-masked],     
               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 ; [email-masked]
  Cc: [email-masked] ; 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

--0__=C1256BAE003034648f9e8a93df938690918cC1256BAE00303464--

Delivery-date: Fri, 03 May 2002 01:30:47 -0700
From: "Gino Carrozzo" <[email-masked]>
To: "Zafar Ali" <[email-masked]>
Cc: <[email-masked]>, "ccamp" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Path TLV
Date: Fri, 3 May 2002 10:30:02 +0200
Organization: META-CPR

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 ; [email-masked]=20
  Cc: [email-masked] ; 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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Dear Zafar,</DIV>
<DIV>&nbsp;</DIV>
<DIV>if I'm not =
wrong,&nbsp;draft-ietf-ccamp-gmpls-architecture-02.txt&nbsp; is=20
going to be ready for&nbsp;IETF Last Call, </DIV>
<DIV>but some&nbsp;points seems to be without&nbsp;a full consensus =
yet.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anyway,&nbsp;&nbsp;is there any action in IETF now to=20
solve&nbsp;"preliminary" FA-LSPs&nbsp;issues (e.g. Pah TLV,&nbsp;FA =
color/metric=20
assignment)? IMO, draft-vandenbosch-mpls-fa-considerations-00.txt=20
just&nbsp;points out these issues!</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>Thanks </DIV>
<DIV>&nbsp;</DIV>
<DIV>Gino&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial"><FONT size=3D3>----- Original Message =
-----=20
  </FONT></DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><FONT=20
  size=3D3><B>From:</B> </FONT><A title=[email-masked]=20
  href=3D"mailto:[email-masked]"><FONT size=3D3>Zafar =
Ali</FONT></A><FONT size=3D3>=20
  </FONT></DIV>
  <DIV style=3D"FONT: 10pt arial"><FONT size=3D3><B>To:</B> </FONT><A=20
  title=[email-masked] href=3D"mailto:[email-masked]"><FONT =
size=3D3>Gino=20
  Carrozzo</FONT></A><FONT size=3D3> ; </FONT><A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]"><FONT=20
  size=3D3>[email-masked]</FONT></A><FONT size=3D3> </FONT></DIV>
  <DIV style=3D"FONT: 10pt arial"><FONT size=3D3><B>Cc:</B> </FONT><A=20
  title=[email-masked] href=3D"mailto:[email-masked]"><FONT=20
  size=3D3>[email-masked]</FONT></A><FONT size=3D3> ; </FONT><A=20
  title=[email-masked] href=3D"mailto:[email-masked]"><FONT=20
  size=3D3>ccamp</FONT></A><FONT size=3D3> </FONT></DIV>
  <DIV style=3D"FONT: 10pt arial"><FONT size=3D3><B>Sent:</B> Thursday, =
May 02, 2002=20
  9:21 PM</FONT></DIV>
  <DIV style=3D"FONT: 10pt arial"><FONT size=3D3><B>Subject:</B> Re: =
Path=20
  TLV</FONT></DIV>
  <DIV><BR></DIV>At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote:<BR>
  <BLOCKQUOTE cite type=3D"cite">Hi all,<BR><BR>in&nbsp;=20
    draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an =
OSPF/ISIS<BR>Path=20
    TLV is proposed to handle the info about the path taken by an=20
    FA-LSP<BR>associated with a TE-Link (FA).<BR><BR>But the new =
versions of the=20
    GMPLS routing and hierarchy drafts<BR>(i.e. lsp-hierarchy-05.txt /=20
    ospf-gmpls-extensions-06.txt =
/<BR>isis-gmpls-extensions-10.txt)<BR>does not=20
    describe this TLV.<BR><BR>Is this an editorial bug for the =
architecture-02=20
    draft?</BLOCKQUOTE><BR>Dear Gino, <BR><BR>No; you may like to refer =
to the=20
  following draft for some "p<FONT=20
  face=3D"Arial, Helvetica">reliminary</FONT><FONT face=3D"Arial, =
Helvetica">=20
  </FONT>" details on this subject. <BR><BR><A=20
  =
href=3D"http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-=
considerations-00.txt"=20
  =
eudora=3D"autourl">http://search.ietf.org/internet-drafts/draft-vandenbos=
ch-mpls-fa-considerations-00.</A><A=20
  =
href=3D"http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-=
considerations-00.txt"=20
  eudora=3D"autourl">txt<BR><BR></A>Thanks<BR><BR>Regards... Zafar =
<BR><BR><BR>
  <BLOCKQUOTE cite=20
type=3D"cite">Thanks<BR>Gino</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0072_01C1F28D.7BCEB760--

Delivery-date: Thu, 02 May 2002 12:22:08 -0700
Date: Thu, 02 May 2002 15:21:22 -0400
To: "Gino Carrozzo" <[email-masked]>, <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: Path TLV
Cc: <[email-masked]>, "ccamp" <[email-masked]>

--=====================_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"

<html>
<font size=3>At 04:22 PM 5/2/2002 +0200, Gino Carrozzo wrote:<br>
<blockquote type=cite cite>Hi all,<br>
<br>
in&nbsp; draft-ietf-ccamp-gmpls-architecture-02.txt (Sec. 10.1) an
OSPF/ISIS<br>
Path TLV is proposed to handle the info about the path taken by an
FA-LSP<br>
associated with a TE-Link (FA).<br>
<br>
But the new versions of the GMPLS routing and hierarchy drafts<br>
(i.e. lsp-hierarchy-05.txt / ospf-gmpls-extensions-06.txt /<br>
isis-gmpls-extensions-10.txt)<br>
does not describe this TLV.<br>
<br>
Is this an editorial bug for the architecture-02
draft?</font></blockquote><br>
Dear Gino, <br>
<br>
No; you may like to refer to the following draft for some
&quot;<font size=3>p</font><font face="Arial, Helvetica" size=3>reliminary</font><font face="Arial, Helvetica">
</font>&quot; details on this subject. <br>
<br>
<a href="http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-considerations-00.txt" eudora="autourl">http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-considerations-00.</a><a href="http://search.ietf.org/internet-drafts/draft-vandenbosch-mpls-fa-considerations-00.txt" eudora="autourl">txt<br>
<br>
</a>Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<blockquote type=cite cite><font size=3>Thanks<br>
Gino</font></blockquote></html>

--=====================_24732052==_.ALT--

Delivery-date: Thu, 02 May 2002 12:08:00 -0700
Date: Thu, 02 May 2002 15:05:26 -0400
From: Dave McDysan <[email-masked]>
Subject: FYI:  WorldCom Vote/Comments - ITU-T Y.1710 (Corr. 1) and Y.1711
To: [email-masked], [email-masked], [email-masked], [email-masked]

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 "[email-masked]" 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.

Delivery-date: Thu, 02 May 2002 07:24:03 -0700
From: "Gino Carrozzo" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "ccamp" <[email-masked]>
Subject: Path TLV
Date: Thu, 2 May 2002 16:22:06 +0200
Organization: META-CPR

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

Delivery-date: Thu, 02 May 2002 01:59:29 -0700
Date: Thu, 02 May 2002 10:56:43 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: Michiel van Everdingen <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Question on LMP

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,
> >
> > <snip>
> > >
> > > 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
> 
> <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:[email-masked]  |
> +------------------------------------------------------------------+

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 01 May 2002 18:26:01 -0700
Date: Wed, 01 May 2002 21:23:35 -0400
To: Yakov Rekhter <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: Re: TE metric and graceful restart 
Cc: "Don Fedyk" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]

--=====================_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"

<html>
<font size=3>At 11:23 AM 5/1/2002 -0700, Yakov Rekhter wrote:<br>
<blockquote type=cite cite>The spec doesn't say that a node *should*
originate a TE LSA upon the restart.</blockquote><br>
Dear Yakov, <br>
<br>
Thanks for your reply. The above statement clarifies the issue. <br>
<br>
Regards.... Zafar </font></html>

--=====================_10531864==_.ALT--

Envelope-to: [email-masked]
Delivery-date: Wed, 01 May 2002 15:09:05 -0700
Message-ID: <[email-masked]>
From: "Don Fedyk"<[email-masked]>
To: Yakov Rekhter <[email-masked]>, Zafar Ali <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
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.
> > > >
> > > >
> > 

Delivery-date: Wed, 01 May 2002 14:51:03 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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: [email-masked]
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>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 : [email-masked]
>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

Delivery-date: Wed, 01 May 2002 11:34:41 -0700
To: Zafar Ali <[email-masked]>
cc: "Don Fedyk" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: TE metric and graceful restart 
Date: Wed, 01 May 2002 11:23:39 -0700
From: Yakov Rekhter <[email-masked]>

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"
> 
> <html>
> <font size=3>At 01:01 PM 5/1/2002 -0400, Don Fedyk wrote:<br>
> <blockquote type=cite cite>Yakov,<br>
> <br>
> I think the text is correct since it is &quot;should ... until it can
> determine<br>
> the amount of reserved...&quot; Logically a node might never advertise
> zero <br>
> because it knows its resources. However, I do prefer *may* in place of
> the <br>
> first *should* which implies zero bandwidth advertisement is
> optional.&nbsp; </font></blockquote><br>
> Dear Yakov, <br>
> <br>
> I agree with Don. Switching the &quot;should&quot; to &quot;may&quot;
> will clarify the text greatly. <br>
> <br>
> Thanks<br>
> <br>
> Regards... Zafar <br>
> <br>
> <br>
> <blockquote type=cite cite><font size=3>Thanks,<br>
> Don<br>
> <br>
> <br>
> Yakov Rekhter wrote:<br>
> &gt; <br>
> &gt; Don,<br>
> &gt; <br>
> &gt; &gt; Kireeti, Zafer:<br>
> &gt; &gt; <br>
> &gt; &gt; I think that Zafer picked up on my earlier point that just
> because<br>
> routing<br>
> &gt; &gt; is gracefully restarting an implementation may have an
> independent <br>
> &gt; &gt; LSP system that can function just fine so why be forced to
> penalize <br>
> &gt; &gt; it? On the other hand, you may have an LSP system that is
> linked <br>
> &gt; &gt; to routing such it must restart as well and then I would agree
> that <br>
> &gt; &gt; zeroing bandwidth may well be necessary( but somewhat less
> &quot;graceful&quot;).<br>
> &gt; &gt; I'm not convinced changing Metrics is required at all. <br>
> &gt; &gt; <br>
> &gt; &gt; So I would agree with Zafer the wording should be such that
> either <br>
> &gt; &gt; case is allowed,<br>
> &gt; <br>
> &gt; Here is the current text:<br>
> &gt; <br>
> &gt;&nbsp;&nbsp;&nbsp; When a restarting node is going to originate its
> TE LSAs, the TE LSAs<br>
> &gt;&nbsp;&nbsp;&nbsp; containing Link TLV should be originated with 0
> unreserved bandwidth,<br>
> &gt;&nbsp;&nbsp;&nbsp; and if the Link has LSC or FSC as its Switching
> Capability then also<br>
> &gt;&nbsp;&nbsp;&nbsp; with 0 as Max LSP Bandwidth, until the node is
> able to determine the<br>
> &gt;&nbsp;&nbsp;&nbsp; amount of unreserved resources taking into account
> the resources<br>
> &gt;&nbsp;&nbsp;&nbsp; reserved by the already established LSPs that have
> been preserved<br>
> &gt;&nbsp;&nbsp;&nbsp; across the restart. Once the restarting node
> determines the amount of<br>
> &gt;&nbsp;&nbsp;&nbsp; unreserved resources, taking into account the
> resources reserved by<br>
> &gt;&nbsp;&nbsp;&nbsp; the already established LSPs that have been
> preserved across the<br>
> &gt;&nbsp;&nbsp;&nbsp; restart, the node should advertise these resources
> in its TE LSAs.<br>
> &gt; <br>
> &gt; First of all note that the node advertises 0 unreserved b/w<br>
> &gt; *only* &quot;until the node is able to determine the<br>
> &gt; amount of unreserved resources taking into account the
> resources<br>
> &gt; reserved by the already established LSPs that have been
> preserved<br>
> &gt; across the restart.&quot; <br>
> &gt; <br>
> &gt; Second, note that originating TE LSA with 0 unreserved b/w<br>
> &gt; is *should*, not *must*.<br>
> &gt; <br>
> &gt; With this in mind, don't you think that the text is ok ?<br>
> &gt; Or do you still want to change &quot;should&quot; in the first
> sentence above<br>
> &gt; into &quot;may&quot; ?<br>
> &gt; <br>
> &gt; Yakov.<br>
> &gt; <br>
> &gt; </font></blockquote></html>
> 
> --=====================_15224191==_.ALT--
> 

Delivery-date: Wed, 01 May 2002 10:59:35 -0700
Date: Wed, 01 May 2002 19:45:46 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: manoj juneja <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: Profile parameter in SDH/SONET traffic Params

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: [email-masked]
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >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 : [email-masked]
> >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 : [email-masked] 
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

Delivery-date: Wed, 01 May 2002 10:51:14 -0700
Date: Wed, 01 May 2002 13:47:05 -0400
To: "Don Fedyk"<[email-masked]>, Yakov Rekhter <[email-masked]>
From: Zafar Ali <[email-masked]>
Subject: RE: TE metric and graceful restart 
Cc: Kireeti Kompella <[email-masked]>, [email-masked]

--=====================_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"

<html>
<font size=3>At 01:01 PM 5/1/2002 -0400, Don Fedyk wrote:<br>
<blockquote type=cite cite>Yakov,<br>
<br>
I think the text is correct since it is &quot;should ... until it can
determine<br>
the amount of reserved...&quot; Logically a node might never advertise
zero <br>
because it knows its resources. However, I do prefer *may* in place of
the <br>
first *should* which implies zero bandwidth advertisement is
optional.&nbsp; </font></blockquote><br>
Dear Yakov, <br>
<br>
I agree with Don. Switching the &quot;should&quot; to &quot;may&quot;
will clarify the text greatly. <br>
<br>
Thanks<br>
<br>
Regards... Zafar <br>
<br>
<br>
<blockquote type=cite cite><font size=3>Thanks,<br>
Don<br>
<br>
<br>
Yakov Rekhter wrote:<br>
&gt; <br>
&gt; Don,<br>
&gt; <br>
&gt; &gt; Kireeti, Zafer:<br>
&gt; &gt; <br>
&gt; &gt; I think that Zafer picked up on my earlier point that just
because<br>
routing<br>
&gt; &gt; is gracefully restarting an implementation may have an
independent <br>
&gt; &gt; LSP system that can function just fine so why be forced to
penalize <br>
&gt; &gt; it? On the other hand, you may have an LSP system that is
linked <br>
&gt; &gt; to routing such it must restart as well and then I would agree
that <br>
&gt; &gt; zeroing bandwidth may well be necessary( but somewhat less
&quot;graceful&quot;).<br>
&gt; &gt; I'm not convinced changing Metrics is required at all. <br>
&gt; &gt; <br>
&gt; &gt; So I would agree with Zafer the wording should be such that
either <br>
&gt; &gt; case is allowed,<br>
&gt; <br>
&gt; Here is the current text:<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp; When a restarting node is going to originate its
TE LSAs, the TE LSAs<br>
&gt;&nbsp;&nbsp;&nbsp; containing Link TLV should be originated with 0
unreserved bandwidth,<br>
&gt;&nbsp;&nbsp;&nbsp; and if the Link has LSC or FSC as its Switching
Capability then also<br>
&gt;&nbsp;&nbsp;&nbsp; with 0 as Max LSP Bandwidth, until the node is
able to determine the<br>
&gt;&nbsp;&nbsp;&nbsp; amount of unreserved resources taking into account
the resources<br>
&gt;&nbsp;&nbsp;&nbsp; reserved by the already established LSPs that have
been preserved<br>
&gt;&nbsp;&nbsp;&nbsp; across the restart. Once the restarting node
determines the amount of<br>
&gt;&nbsp;&nbsp;&nbsp; unreserved resources, taking into account the
resources reserved by<br>
&gt;&nbsp;&nbsp;&nbsp; the already established LSPs that have been
preserved across the<br>
&gt;&nbsp;&nbsp;&nbsp; restart, the node should advertise these resources
in its TE LSAs.<br>
&gt; <br>
&gt; First of all note that the node advertises 0 unreserved b/w<br>
&gt; *only* &quot;until the node is able to determine the<br>
&gt; amount of unreserved resources taking into account the
resources<br>
&gt; reserved by the already established LSPs that have been
preserved<br>
&gt; across the restart.&quot; <br>
&gt; <br>
&gt; Second, note that originating TE LSA with 0 unreserved b/w<br>
&gt; is *should*, not *must*.<br>
&gt; <br>
&gt; With this in mind, don't you think that the text is ok ?<br>
&gt; Or do you still want to change &quot;should&quot; in the first
sentence above<br>
&gt; into &quot;may&quot; ?<br>
&gt; <br>
&gt; Yakov.<br>
&gt; <br>
&gt; </font></blockquote></html>

--=====================_15224191==_.ALT--

Envelope-to: [email-masked]
Delivery-date: Wed, 01 May 2002 10:02:19 -0700
Message-ID: <[email-masked]>
From: "Don Fedyk"<[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Zafar Ali <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
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.
> 
> 

Delivery-date: Wed, 01 May 2002 09:43:48 -0700
To: "Don Fedyk" <[email-masked]>
cc: Zafar Ali <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: TE metric and graceful restart 
Date: Wed, 01 May 2002 09:35:54 -0700
From: Yakov Rekhter <[email-masked]>

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:[email-masked]]
> >Sent: Sunday, April 28, 2002 1:53 AM
> >To: Kireeti Kompella
> >Cc: [email-masked]
> >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"
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
> <TITLE>RE: TE metric and graceful restart</TITLE>
> </HEAD>
> <BODY>
> 
> <P><FONT SIZE=2>Kireeti, Zafer:</FONT>
> </P>
> 
> <P><FONT SIZE=2>I think that Zafer picked up on my earlier point that just be
cause routing</FONT>
> <BR><FONT SIZE=2>is gracefully restarting an implementation may have an indep
endent </FONT>
> <BR><FONT SIZE=2>LSP system that can function just fine so why be forced to p
enalize </FONT>
> <BR><FONT SIZE=2>it? On the other hand, you may have an LSP system that is li
nked </FONT>
> <BR><FONT SIZE=2>to routing such it must restart as well and then I would agr
ee that </FONT>
> <BR><FONT SIZE=2>zeroing bandwidth may well be necessary( but somewhat less &
quot;graceful&quot;).</FONT>
> <BR><FONT SIZE=2>I'm not convinced changing Metrics is required at all. </FON
T>
> </P>
> 
> <P><FONT SIZE=2>So I would agree with Zafer the wording should be such that e
ither </FONT>
> <BR><FONT SIZE=2>case is allowed,</FONT>
> </P>
> 
> <P><FONT SIZE=2>Don&nbsp; </FONT>
> <BR><FONT SIZE=2>-----Original Message-----</FONT>
> <BR><FONT SIZE=2>&gt;From: Zafar Ali [<A HREF="mailto:[email-masked]">mailto:
[email-masked]</A>]</FONT>
> <BR><FONT SIZE=2>&gt;Sent: Sunday, April 28, 2002 1:53 AM</FONT>
> <BR><FONT SIZE=2>&gt;To: Kireeti Kompella</FONT>
> <BR><FONT SIZE=2>&gt;Cc: [email-masked]</FONT>
> <BR><FONT SIZE=2>&gt;Subject: RE: TE metric and graceful restart</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;Dear Kireeti, </FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;Thanks for the reply; Please see comments in-lined. </FO
NT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:</FO
NT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;On Sat, 27 Apr 2002, Zafar Ali wrote:</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&gt; The reason that I understood this as a MAY case is 
that a node that saves</FONT>
> <BR><FONT SIZE=2>&gt;&gt; bandwidth usage state information locally is able t
o determine (or</FONT>
> <BR><FONT SIZE=2>&gt;&gt; estimate) the amount of unreserved resources immedi
ately upon start-up. In</FONT>
> <BR><FONT SIZE=2>&gt;&gt; which case it MAY advertise the saved (projected) v
alue(s) during the</FONT>
> <BR><FONT SIZE=2>&gt;&gt; graceful restart period.</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;Attractive as that may be, life is not so simple.&nbsp; 
The process of</FONT>
> <BR><FONT SIZE=2>&gt;recovery for signaling is complex enough without having 
new LSPs set</FONT>
> <BR><FONT SIZE=2>&gt;up during recovery.&nbsp; The idea of discouraging LSPs 
during recovery is</FONT>
> <BR><FONT SIZE=2>&gt;not just that the recovering node doesn't know its unres
erved bandwidth,</FONT>
> <BR><FONT SIZE=2>&gt;but that it wants to complete recovery before setting up
 new LSPs.</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;A simple example is that the recovering node X uses per-
box labels,</FONT>
> <BR><FONT SIZE=2>&gt;gets a new LSP request while recovering, and allocates l
abel L to that</FONT>
> <BR><FONT SIZE=2>&gt;request.&nbsp; But L is already in use for an existing L
SP ....&nbsp; </FONT>
> <BR><FONT SIZE=2>&gt;One can</FONT>
> <BR><FONT SIZE=2>&gt;work around this particular example, but keeping it simp
le seems like</FONT>
> <BR><FONT SIZE=2>&gt;a good initial goal.</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;Agreed! As I also mentioned that in doing so the node lo
oses the charm </FONT>
> <BR><FONT SIZE=2>&gt;of discouraging other nodes in the network </FONT>
> <BR><FONT SIZE=2>&gt;in using it, during the restart period. This opens doors
 for some </FONT>
> <BR><FONT SIZE=2>&gt;potential race conditions and &gt;scenarios like the one
 you mentioned </FONT>
> <BR><FONT SIZE=2>&gt;in the email. Of course, a node that may choose to do so
 &gt;has to deal </FONT>
> <BR><FONT SIZE=2>&gt;with kind of scenarios that you mentioned in the email. 
I see that </FONT>
> <BR><FONT SIZE=2>&gt;there are some tradeoffs involved and the standard shoul
d leave a </FONT>
> <BR><FONT SIZE=2>&gt;room for exercising such options. Hence, IMO this should
 be a local </FONT>
> <BR><FONT SIZE=2>&gt;(vendor specific) decision. </FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;In short, while I am agreeing with the recommendation, I
 think the </FONT>
> <BR><FONT SIZE=2>&gt;&quot;SHOULD&quot; part should be &gt;&gt;removed and th
e standard should leave it as </FONT>
> <BR><FONT SIZE=2>&gt;part of the local decision. </FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;Thanks</FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;Regards... Zafar </FONT>
> <BR><FONT SIZE=2>&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&gt;At least, that's my take.</FONT>
> <BR><FONT SIZE=2>&gt;&gt;</FONT>
> <BR><FONT SIZE=2>&gt;&gt;Kireeti.</FONT>
> </P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C1EFB2.8A7BC48E--
> 

Delivery-date: Wed, 01 May 2002 05:15:43 -0700
Date: Wed, 01 May 2002 13:13:30 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: manoj juneja <[email-masked]>
CC: [email-masked]
Subject: Re: Profile parameter in SDH/SONET traffic Params

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 : [email-masked] 
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

Delivery-date: Wed, 01 May 2002 05:06:10 -0700
Cc: [email-masked]
Date: Wed, 01 May 2002 14:04:14 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Jonathan Lang <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Question on LMP.

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,
> 
> <snip>
> >
> > 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

<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:[email-masked]  |
+------------------------------------------------------------------+

Envelope-to: [email-masked]
Delivery-date: Wed, 01 May 2002 04:52:06 -0700
Date: Wed, 1 May 2002 04:49:40 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Signaling documents ...
Cc: [email-masked]

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.

Delivery-date: Wed, 01 May 2002 00:32:16 -0700
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: AW: {SUKLM} Changes in new draft
Date: Wed, 1 May 2002 09:27:59 +0200 

Manoj,

see my comments below.

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: manoj juneja [mailto:[email-masked]]
> Gesendet: Dienstag, 30. April 2002 20:29
> An: [email-masked]
> 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.