Subject: Re: Moving right along ... Switching Type
From: Yangguang Xu <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Dimitri Papadimitriou <[email-masked]>, [email-masked]
Date: Wed, 31 Oct 2001 22:25:44 -0500

> 
> > We have two approaches either "traffic-parameters" are used
> > (in SENDER_TSPEC) then i think the Switching Type capability
> > is useless or they aren't then such field could be optionaly
> > used when applicable (some examples are given in the routing
> > document).
> >
> > Wouldn't be the right way to proceed by defining an "unknown"
> > or "unspecified" value used when "traffic-parameters" are
> > included within the Path Message and optional use the ones
> > proposed in the current version of the specification when they
> > aren't. This field is thus optional and MUST only be used when
> > traffic parameters are not defined. I think this solves both
> > approaches.
> 
> Agreed.

When a hybrid NE sees GMPLS (different C-types from MPLS) messages, it knows the
LSP is not for conventional data LSP. So there is no confusion about
conventional MPLS data LSPs and GMPLS circuit LSPs without Switching Type.
Furthermore, if you have "traffic-parameters", Switching Type is useless, as we
agreed. So, defining "unknown", "unspecified" is not necessary, and neither is
Switching Type.

Yangguang

Delivery-date: Wed, 31 Oct 2001 19:28:28 -0800
Date: Wed, 31 Oct 2001 22:27:52 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Yakov Rekhter <[email-masked]>
CC: Zhi-Wei Lin <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

> 
> Let me see if I understand your proposal. Consider the following
> example:
> 
>    R1---OXC1---OXC2----R2
> 
> where the TE interface on R1 is a collection of GigE ports, and the TE
> interface on R2 is a collection of OC-48 ports. Are you saying that
> establishing an LSP between R1 to R2 makes sense ?
> 

If you have adaptation function in either OXCs, it then makes sense. And sure,
you can also treat the R1-R2 connection as two LSPs separated by the adaptation
function.

Yangguang

Delivery-date: Wed, 31 Oct 2001 18:25:16 -0800
From: John Drake <[email-masked]>
To: 'manoj juneja' <[email-masked]>,  [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 18:23:55 -0800

To handle the case where the path of an LSP transits one or more TE links
which are advertised as having more than one of the following switching
capabilities (PSC, TDM, LSC, FSC) and the LSP is requesting a switching
capability of (PSC, LSC, or FSC).  

Dimitri's proposal also works just fine when the path of an LSP transits
links which have only one advertised switching capability. 

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 6:07 PM
To: John Drake; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Moving right along ... Switching Type

Hi John,
         If the switching type advertised in the link state database is say 
Lambda or Fiber then why we need to carry this in signalling ?

Regards,
manoj.

>From: John Drake <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, 
>[email-masked]
>CC: [email-masked], [email-masked], [email-masked], 
>[email-masked]
>Subject: RE: Moving right along ... Switching Type
>Date: Wed, 31 Oct 2001 17:43:07 -0800
>
>Not exactly.  When the switching type advertised in the link state database
>is TDM, then
>the signalling request doesn't require a switching type with a value of TDM
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Wednesday, October 31, 2001 5:32 PM
>To: [email-masked]
>Cc: [email-masked]; John Drake; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: Moving right along ... Switching Type
>
>
>Hi Dimitri,
>                This means that switching type is not valid when LSP 
>encoding
>
>type is SDH/SONET. Is this true ?
>
>Thank You for ur help.
>
>Regards,
>manoj.
>
> >From: Dimitri Papadimitriou <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked], [email-masked], [email-masked],
> >[email-masked], [email-masked]
> >Subject: Re: Moving right along ... Switching Type
> >Date: Thu, 01 Nov 2001 01:30:49 +0100
> >
> >Hi Manoj,
> >
> >When Traffic_Parameters are used to create VC-4-Xc LSP for
> >instance, Switching Type would take a default value without
> >significance on the node switching capability preference since
> >inferred by the Traffic_Parameters. So when creating SDH/Sonet
> >LSP the Switching Type value will be ignored.
> >
> >PS: better to rephrase the below sentence as follows:
> > > >The usage of this field is thus optional and can (when applicable)
> > > >only be considered when traffic parameters are not defined.
> >
> >Hope this clarifies,
> >
> >- dimitri.
> >
> >manoj juneja wrote:
> > >
> > > Hi Dimitri,
> > >             Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> > > per my understanding these are mandatory as it gives information
> > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> > > etc). If SDH/SONET traffic parameters are not present then how can I
> > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> > > type ?
> > >
> > > Please correct me if I am wrong.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Dimitri Papadimitriou <[email-masked]>
> > > >To: Zhi-Wei Lin <[email-masked]>
> > > >CC: John Drake <[email-masked]>,   "'Ben Mack-Crane'"
> > > ><[email-masked]>,   Kireeti Kompella 
><[email-masked]>,
> > > >[email-masked]
> > > >Subject: Re: Moving right along ... Switching Type
> > > >Date: Wed, 31 Oct 2001 23:52:16 +0100
> > > >
> > > >Hi,
> > > >
> > > >We have two approaches either "traffic-parameters" are used
> > > >(in SENDER_TSPEC) then i think the Switching Type capability
> > > >is useless or they aren't then such field could be optionaly
> > > >used when applicable (some examples are given in the routing
> > > >document).
> > > >
> > > >Wouldn't be the right way to proceed by defining an "unknown"
> > > >or "unspecified" value used when "traffic-parameters" are
> > > >included within the Path Message and optional use the ones
> > > >proposed in the current version of the specification when they
> > > >aren't. This field is thus optional and MUST only be used when
> > > >traffic parameters are not defined. I think this solves both
> > > >approaches.
> > > >
> > > >I think that also some additional text is needed in order to
> > > >clarify the semantic; the following one can be proposed (after
> > > >having discussed with some individuals):
> > > >"The Switching Type field is provided to allow nodes having
> > > >multiple switching layer capabilities to indicate their
> > > >preference. This field should only be used to indicate the
> > > >link switching preference but not end-to-end switching
> > > >preference".
> > > >
> > > >Notice that some proposal concerning the applicability scope
> > > >have been proposed but never really committed within the I-D.
> > > >
> > > >Cheers,
> > > >- dimitri.
> > > >
> > > >Zhi-Wei Lin wrote:
> > > > >
> > > > > Hi John,
> > > > >
> > > > > > <z>The section you mentioned, from what I can tell, is an 
>example
> >list
> > > > > > of some possible combinations of different equipment functions. 
>I
> >see
> > > > > > them as examples. But as I said, from routing perspective, it 
>may
> >make
> > > > > > sense but not signaling. What you've pointed out is the routing
> > > >document...
> > > > > >  From signaling perspective, if I removed the switching 
>capability
> > > > > > field, there is nothing lost...do you agree?
> > > > > >
> > > > > >
> > > > > > JD:  No.  I will try again. What you have to demonstrate is that
> >for
> > > >all
> > > > > > possible combinations of switching capabilities supported on a
> >link,
> > > >an
> > > > > > intermediate node can deduce, from other fields in the Path
> >message,
> > > >what
> > > > > > switching capability is desired.
> > > > > >
> > > > >
> > > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > > different switching capabilities on each side and the possible
> > > > > connections and then demonstrate that what switching capability is
> > > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > > encoding type says and the sender_tspec says is what the switching
> >type
> > > > > used (I'm lazy, it takes too long to run through all the
> > > >combinations)</z>
> > > > >
> > > > > >
> > > > > > And if I removed the switching capability field, then it opens 
>the
> > > >door
> > > > > > for the possibility where somewhere within my network I might
> >change
> > > >the
> > > > > > switching type in order to satisfy a request (because the
> >switching
> > > >type
> > > > > > requested is non-existent or exhausted).</z>
> > > > > >
> > > > > >
> > > > > > JD: Please give an example of where substituting one value of
> > > >switching
> > > > > > capability for another in the middle of an LSP makes sense.
> > > > > >
> > > > >
> > > > > <z>Well, for example, you have a SONET network that can provide
> >STS-48c,
> > > > > and it goes through an all-optical network that can provide OCh1
> >(2.5G
> > > > > service). In the SONET network it switches the STS-48c layer, 
>while
> >in
> > > > > OTN network it switches the OCh layer. This is very similar to
> >E1/VC-12
> > > > > connection, where one part of network may work PDH-based and
> >switching
> > > > > E1 while another part may be SDH-based and switching VC-12, but 
>the
> > > > > connection or service is essentially the same. They're not really
> > > > > client-server layers but similar layers from different
> > > >technologies...</z>
> > > > >
> > > > > > <z>I think it does make sense. I think you have to assume that
> >within
> > > > > > the switched transport network there will be many kinds of
> >interfaces
> > > > > > connecting to the transport network. If you can't offer this
> > > >capability,
> > > > > > then essentially what you've done is segment the transport 
>network
> > > >into
> > > > > > sub-networks based on what interfaces they have and only the
> >like-type
> > > > > > interfaces can connect to each other. If you look at the IP 
>world,
>
> >you
> > > > > > might have a switch with 100 Mbps and another with 10 Mbps
> >connected
> > > > > > together and talking to each other without a problem. This is
> > > >capability
> > > > > > that is also needed, where one end could be 1 Gbps Ethernet and
> > > >another
> > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET
> >(no
> > > > > > reason to restrict this). What really matters is that the 
>service
> >is
> > > > > > delivered. Granted there will be some inefficiencies in this, 
>but
> > > >that's
> > > > > > really a policy decision whether users are willing to accept 
>this
> >type
> > > > > > of connection.</z>
> > > > > >
> > > > > >
> > > > > > JD:  What you're describing here is PSC LSPs and they work just
> >fine.
> > > >What
> > > > > > you were describing in your previous example was an LSP, one end
> >of
> > > >which
> > > > > > was
> > > > > > PSC and the other end of which was TDM.  And that doesn't make
> >sense.
> > > > > >
> > > > >
> > > > > <z>Maybe this is one where we need to ask individuals with
> >operational
> > > > > experience and have some experience with service provisioning
> >whether
> > > > > having one end with Ethernet and another end with OC-48 sounds 
>like
> >a
> > > > > configuration that makes sense?
> > > > >
> > > > > Again, the point here is that if this doesn't make sense, then
> > > > > essentially what you have is multiple switched networks, each
> >serving
> > > > > one particular type of customer interface, i.e., a switched 
>network
> >for
> > > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > > >
> > > > > Is this one of those "violent agreements" where we're 
>concentrating
> >on
> > > > > two different levels but saying the same thing?</z>
> > > ><< dimitri.papadimitriou.vcf >>
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< dimitri.papadimitriou.vcf >>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 31 Oct 2001 18:08:16 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 19:07:09 -0700

Hi John,
         If the switching type advertised in the link state database is say 
Lambda or Fiber then why we need to carry this in signalling ?

Regards,
manoj.

>From: John Drake <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, 
>[email-masked]
>CC: [email-masked], [email-masked], [email-masked], 
>[email-masked]
>Subject: RE: Moving right along ... Switching Type
>Date: Wed, 31 Oct 2001 17:43:07 -0800
>
>Not exactly.  When the switching type advertised in the link state database
>is TDM, then
>the signalling request doesn't require a switching type with a value of TDM
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Wednesday, October 31, 2001 5:32 PM
>To: [email-masked]
>Cc: [email-masked]; John Drake; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: Moving right along ... Switching Type
>
>
>Hi Dimitri,
>                This means that switching type is not valid when LSP 
>encoding
>
>type is SDH/SONET. Is this true ?
>
>Thank You for ur help.
>
>Regards,
>manoj.
>
> >From: Dimitri Papadimitriou <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked], [email-masked], [email-masked],
> >[email-masked], [email-masked]
> >Subject: Re: Moving right along ... Switching Type
> >Date: Thu, 01 Nov 2001 01:30:49 +0100
> >
> >Hi Manoj,
> >
> >When Traffic_Parameters are used to create VC-4-Xc LSP for
> >instance, Switching Type would take a default value without
> >significance on the node switching capability preference since
> >inferred by the Traffic_Parameters. So when creating SDH/Sonet
> >LSP the Switching Type value will be ignored.
> >
> >PS: better to rephrase the below sentence as follows:
> > > >The usage of this field is thus optional and can (when applicable)
> > > >only be considered when traffic parameters are not defined.
> >
> >Hope this clarifies,
> >
> >- dimitri.
> >
> >manoj juneja wrote:
> > >
> > > Hi Dimitri,
> > >             Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> > > per my understanding these are mandatory as it gives information
> > > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> > > etc). If SDH/SONET traffic parameters are not present then how can I
> > > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> > > type ?
> > >
> > > Please correct me if I am wrong.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: Dimitri Papadimitriou <[email-masked]>
> > > >To: Zhi-Wei Lin <[email-masked]>
> > > >CC: John Drake <[email-masked]>,   "'Ben Mack-Crane'"
> > > ><[email-masked]>,   Kireeti Kompella 
><[email-masked]>,
> > > >[email-masked]
> > > >Subject: Re: Moving right along ... Switching Type
> > > >Date: Wed, 31 Oct 2001 23:52:16 +0100
> > > >
> > > >Hi,
> > > >
> > > >We have two approaches either "traffic-parameters" are used
> > > >(in SENDER_TSPEC) then i think the Switching Type capability
> > > >is useless or they aren't then such field could be optionaly
> > > >used when applicable (some examples are given in the routing
> > > >document).
> > > >
> > > >Wouldn't be the right way to proceed by defining an "unknown"
> > > >or "unspecified" value used when "traffic-parameters" are
> > > >included within the Path Message and optional use the ones
> > > >proposed in the current version of the specification when they
> > > >aren't. This field is thus optional and MUST only be used when
> > > >traffic parameters are not defined. I think this solves both
> > > >approaches.
> > > >
> > > >I think that also some additional text is needed in order to
> > > >clarify the semantic; the following one can be proposed (after
> > > >having discussed with some individuals):
> > > >"The Switching Type field is provided to allow nodes having
> > > >multiple switching layer capabilities to indicate their
> > > >preference. This field should only be used to indicate the
> > > >link switching preference but not end-to-end switching
> > > >preference".
> > > >
> > > >Notice that some proposal concerning the applicability scope
> > > >have been proposed but never really committed within the I-D.
> > > >
> > > >Cheers,
> > > >- dimitri.
> > > >
> > > >Zhi-Wei Lin wrote:
> > > > >
> > > > > Hi John,
> > > > >
> > > > > > <z>The section you mentioned, from what I can tell, is an 
>example
> >list
> > > > > > of some possible combinations of different equipment functions. 
>I
> >see
> > > > > > them as examples. But as I said, from routing perspective, it 
>may
> >make
> > > > > > sense but not signaling. What you've pointed out is the routing
> > > >document...
> > > > > >  From signaling perspective, if I removed the switching 
>capability
> > > > > > field, there is nothing lost...do you agree?
> > > > > >
> > > > > >
> > > > > > JD:  No.  I will try again. What you have to demonstrate is that
> >for
> > > >all
> > > > > > possible combinations of switching capabilities supported on a
> >link,
> > > >an
> > > > > > intermediate node can deduce, from other fields in the Path
> >message,
> > > >what
> > > > > > switching capability is desired.
> > > > > >
> > > > >
> > > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > > different switching capabilities on each side and the possible
> > > > > connections and then demonstrate that what switching capability is
> > > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > > encoding type says and the sender_tspec says is what the switching
> >type
> > > > > used (I'm lazy, it takes too long to run through all the
> > > >combinations)</z>
> > > > >
> > > > > >
> > > > > > And if I removed the switching capability field, then it opens 
>the
> > > >door
> > > > > > for the possibility where somewhere within my network I might
> >change
> > > >the
> > > > > > switching type in order to satisfy a request (because the
> >switching
> > > >type
> > > > > > requested is non-existent or exhausted).</z>
> > > > > >
> > > > > >
> > > > > > JD: Please give an example of where substituting one value of
> > > >switching
> > > > > > capability for another in the middle of an LSP makes sense.
> > > > > >
> > > > >
> > > > > <z>Well, for example, you have a SONET network that can provide
> >STS-48c,
> > > > > and it goes through an all-optical network that can provide OCh1
> >(2.5G
> > > > > service). In the SONET network it switches the STS-48c layer, 
>while
> >in
> > > > > OTN network it switches the OCh layer. This is very similar to
> >E1/VC-12
> > > > > connection, where one part of network may work PDH-based and
> >switching
> > > > > E1 while another part may be SDH-based and switching VC-12, but 
>the
> > > > > connection or service is essentially the same. They're not really
> > > > > client-server layers but similar layers from different
> > > >technologies...</z>
> > > > >
> > > > > > <z>I think it does make sense. I think you have to assume that
> >within
> > > > > > the switched transport network there will be many kinds of
> >interfaces
> > > > > > connecting to the transport network. If you can't offer this
> > > >capability,
> > > > > > then essentially what you've done is segment the transport 
>network
> > > >into
> > > > > > sub-networks based on what interfaces they have and only the
> >like-type
> > > > > > interfaces can connect to each other. If you look at the IP 
>world,
>
> >you
> > > > > > might have a switch with 100 Mbps and another with 10 Mbps
> >connected
> > > > > > together and talking to each other without a problem. This is
> > > >capability
> > > > > > that is also needed, where one end could be 1 Gbps Ethernet and
> > > >another
> > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET
> >(no
> > > > > > reason to restrict this). What really matters is that the 
>service
> >is
> > > > > > delivered. Granted there will be some inefficiencies in this, 
>but
> > > >that's
> > > > > > really a policy decision whether users are willing to accept 
>this
> >type
> > > > > > of connection.</z>
> > > > > >
> > > > > >
> > > > > > JD:  What you're describing here is PSC LSPs and they work just
> >fine.
> > > >What
> > > > > > you were describing in your previous example was an LSP, one end
> >of
> > > >which
> > > > > > was
> > > > > > PSC and the other end of which was TDM.  And that doesn't make
> >sense.
> > > > > >
> > > > >
> > > > > <z>Maybe this is one where we need to ask individuals with
> >operational
> > > > > experience and have some experience with service provisioning
> >whether
> > > > > having one end with Ethernet and another end with OC-48 sounds 
>like
> >a
> > > > > configuration that makes sense?
> > > > >
> > > > > Again, the point here is that if this doesn't make sense, then
> > > > > essentially what you have is multiple switched networks, each
> >serving
> > > > > one particular type of customer interface, i.e., a switched 
>network
> >for
> > > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > > >
> > > > > Is this one of those "violent agreements" where we're 
>concentrating
> >on
> > > > > two different levels but saying the same thing?</z>
> > > ><< dimitri.papadimitriou.vcf >>
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> ><< dimitri.papadimitriou.vcf >>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 31 Oct 2001 17:45:10 -0800
From: John Drake <[email-masked]>
To: 'manoj juneja' <[email-masked]>,  [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 17:43:07 -0800

Not exactly.  When the switching type advertised in the link state database
is TDM, then
the signalling request doesn't require a switching type with a value of TDM

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 5:32 PM
To: [email-masked]
Cc: [email-masked]; John Drake; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi Dimitri,
               This means that switching type is not valid when LSP encoding

type is SDH/SONET. Is this true ?

Thank You for ur help.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked],   
>[email-masked], [email-masked]
>Subject: Re: Moving right along ... Switching Type
>Date: Thu, 01 Nov 2001 01:30:49 +0100
>
>Hi Manoj,
>
>When Traffic_Parameters are used to create VC-4-Xc LSP for
>instance, Switching Type would take a default value without
>significance on the node switching capability preference since
>inferred by the Traffic_Parameters. So when creating SDH/Sonet
>LSP the Switching Type value will be ignored.
>
>PS: better to rephrase the below sentence as follows:
> > >The usage of this field is thus optional and can (when applicable)
> > >only be considered when traffic parameters are not defined.
>
>Hope this clarifies,
>
>- dimitri.
>
>manoj juneja wrote:
> >
> > Hi Dimitri,
> >             Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> > per my understanding these are mandatory as it gives information
> > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> > etc). If SDH/SONET traffic parameters are not present then how can I
> > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> > type ?
> >
> > Please correct me if I am wrong.
> >
> > Regards,
> > manoj.
> >
> > >From: Dimitri Papadimitriou <[email-masked]>
> > >To: Zhi-Wei Lin <[email-masked]>
> > >CC: John Drake <[email-masked]>,   "'Ben Mack-Crane'"
> > ><[email-masked]>,   Kireeti Kompella <[email-masked]>,
> > >[email-masked]
> > >Subject: Re: Moving right along ... Switching Type
> > >Date: Wed, 31 Oct 2001 23:52:16 +0100
> > >
> > >Hi,
> > >
> > >We have two approaches either "traffic-parameters" are used
> > >(in SENDER_TSPEC) then i think the Switching Type capability
> > >is useless or they aren't then such field could be optionaly
> > >used when applicable (some examples are given in the routing
> > >document).
> > >
> > >Wouldn't be the right way to proceed by defining an "unknown"
> > >or "unspecified" value used when "traffic-parameters" are
> > >included within the Path Message and optional use the ones
> > >proposed in the current version of the specification when they
> > >aren't. This field is thus optional and MUST only be used when
> > >traffic parameters are not defined. I think this solves both
> > >approaches.
> > >
> > >I think that also some additional text is needed in order to
> > >clarify the semantic; the following one can be proposed (after
> > >having discussed with some individuals):
> > >"The Switching Type field is provided to allow nodes having
> > >multiple switching layer capabilities to indicate their
> > >preference. This field should only be used to indicate the
> > >link switching preference but not end-to-end switching
> > >preference".
> > >
> > >Notice that some proposal concerning the applicability scope
> > >have been proposed but never really committed within the I-D.
> > >
> > >Cheers,
> > >- dimitri.
> > >
> > >Zhi-Wei Lin wrote:
> > > >
> > > > Hi John,
> > > >
> > > > > <z>The section you mentioned, from what I can tell, is an example 
>list
> > > > > of some possible combinations of different equipment functions. I 
>see
> > > > > them as examples. But as I said, from routing perspective, it may 
>make
> > > > > sense but not signaling. What you've pointed out is the routing
> > >document...
> > > > >  From signaling perspective, if I removed the switching capability
> > > > > field, there is nothing lost...do you agree?
> > > > >
> > > > >
> > > > > JD:  No.  I will try again. What you have to demonstrate is that 
>for
> > >all
> > > > > possible combinations of switching capabilities supported on a 
>link,
> > >an
> > > > > intermediate node can deduce, from other fields in the Path 
>message,
> > >what
> > > > > switching capability is desired.
> > > > >
> > > >
> > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > different switching capabilities on each side and the possible
> > > > connections and then demonstrate that what switching capability is
> > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > encoding type says and the sender_tspec says is what the switching 
>type
> > > > used (I'm lazy, it takes too long to run through all the
> > >combinations)</z>
> > > >
> > > > >
> > > > > And if I removed the switching capability field, then it opens the
> > >door
> > > > > for the possibility where somewhere within my network I might 
>change
> > >the
> > > > > switching type in order to satisfy a request (because the 
>switching
> > >type
> > > > > requested is non-existent or exhausted).</z>
> > > > >
> > > > >
> > > > > JD: Please give an example of where substituting one value of
> > >switching
> > > > > capability for another in the middle of an LSP makes sense.
> > > > >
> > > >
> > > > <z>Well, for example, you have a SONET network that can provide 
>STS-48c,
> > > > and it goes through an all-optical network that can provide OCh1 
>(2.5G
> > > > service). In the SONET network it switches the STS-48c layer, while 
>in
> > > > OTN network it switches the OCh layer. This is very similar to 
>E1/VC-12
> > > > connection, where one part of network may work PDH-based and 
>switching
> > > > E1 while another part may be SDH-based and switching VC-12, but the
> > > > connection or service is essentially the same. They're not really
> > > > client-server layers but similar layers from different
> > >technologies...</z>
> > > >
> > > > > <z>I think it does make sense. I think you have to assume that 
>within
> > > > > the switched transport network there will be many kinds of 
>interfaces
> > > > > connecting to the transport network. If you can't offer this
> > >capability,
> > > > > then essentially what you've done is segment the transport network
> > >into
> > > > > sub-networks based on what interfaces they have and only the 
>like-type
> > > > > interfaces can connect to each other. If you look at the IP world,

>you
> > > > > might have a switch with 100 Mbps and another with 10 Mbps 
>connected
> > > > > together and talking to each other without a problem. This is
> > >capability
> > > > > that is also needed, where one end could be 1 Gbps Ethernet and
> > >another
> > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET 
>(no
> > > > > reason to restrict this). What really matters is that the service 
>is
> > > > > delivered. Granted there will be some inefficiencies in this, but
> > >that's
> > > > > really a policy decision whether users are willing to accept this 
>type
> > > > > of connection.</z>
> > > > >
> > > > >
> > > > > JD:  What you're describing here is PSC LSPs and they work just 
>fine.
> > >What
> > > > > you were describing in your previous example was an LSP, one end 
>of
> > >which
> > > > > was
> > > > > PSC and the other end of which was TDM.  And that doesn't make 
>sense.
> > > > >
> > > >
> > > > <z>Maybe this is one where we need to ask individuals with 
>operational
> > > > experience and have some experience with service provisioning 
>whether
> > > > having one end with Ethernet and another end with OC-48 sounds like 
>a
> > > > configuration that makes sense?
> > > >
> > > > Again, the point here is that if this doesn't make sense, then
> > > > essentially what you have is multiple switched networks, each 
>serving
> > > > one particular type of customer interface, i.e., a switched network 
>for
> > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > >
> > > > Is this one of those "violent agreements" where we're concentrating 
>on
> > > > two different levels but saying the same thing?</z>
> > ><< dimitri.papadimitriou.vcf >>
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 31 Oct 2001 17:42:01 -0800
From: John Drake <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... Switching Type 
Date: Wed, 31 Oct 2001 17:39:57 -0800

seems fine

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 5:21 PM
To: Dimitri Papadimitriou
Cc: [email-masked]
Subject: Re: Moving right along ... Switching Type 

Dimitri,

> We have two approaches either "traffic-parameters" are used
> (in SENDER_TSPEC) then i think the Switching Type capability 
> is useless or they aren't then such field could be optionaly
> used when applicable (some examples are given in the routing
> document).
> 
> Wouldn't be the right way to proceed by defining an "unknown"
> or "unspecified" value used when "traffic-parameters" are 
> included within the Path Message and optional use the ones 
> proposed in the current version of the specification when they 
> aren't. This field is thus optional and MUST only be used when 
> traffic parameters are not defined. I think this solves both 
> approaches.

Agreed.
  
Yakov.

Delivery-date: Wed, 31 Oct 2001 17:34:18 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 18:32:24 -0700

Hi Dimitri,
               This means that switching type is not valid when LSP encoding 
type is SDH/SONET. Is this true ?

Thank You for ur help.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked],   
>[email-masked], [email-masked]
>Subject: Re: Moving right along ... Switching Type
>Date: Thu, 01 Nov 2001 01:30:49 +0100
>
>Hi Manoj,
>
>When Traffic_Parameters are used to create VC-4-Xc LSP for
>instance, Switching Type would take a default value without
>significance on the node switching capability preference since
>inferred by the Traffic_Parameters. So when creating SDH/Sonet
>LSP the Switching Type value will be ignored.
>
>PS: better to rephrase the below sentence as follows:
> > >The usage of this field is thus optional and can (when applicable)
> > >only be considered when traffic parameters are not defined.
>
>Hope this clarifies,
>
>- dimitri.
>
>manoj juneja wrote:
> >
> > Hi Dimitri,
> >             Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> > per my understanding these are mandatory as it gives information
> > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> > etc). If SDH/SONET traffic parameters are not present then how can I
> > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> > type ?
> >
> > Please correct me if I am wrong.
> >
> > Regards,
> > manoj.
> >
> > >From: Dimitri Papadimitriou <[email-masked]>
> > >To: Zhi-Wei Lin <[email-masked]>
> > >CC: John Drake <[email-masked]>,   "'Ben Mack-Crane'"
> > ><[email-masked]>,   Kireeti Kompella <[email-masked]>,
> > >[email-masked]
> > >Subject: Re: Moving right along ... Switching Type
> > >Date: Wed, 31 Oct 2001 23:52:16 +0100
> > >
> > >Hi,
> > >
> > >We have two approaches either "traffic-parameters" are used
> > >(in SENDER_TSPEC) then i think the Switching Type capability
> > >is useless or they aren't then such field could be optionaly
> > >used when applicable (some examples are given in the routing
> > >document).
> > >
> > >Wouldn't be the right way to proceed by defining an "unknown"
> > >or "unspecified" value used when "traffic-parameters" are
> > >included within the Path Message and optional use the ones
> > >proposed in the current version of the specification when they
> > >aren't. This field is thus optional and MUST only be used when
> > >traffic parameters are not defined. I think this solves both
> > >approaches.
> > >
> > >I think that also some additional text is needed in order to
> > >clarify the semantic; the following one can be proposed (after
> > >having discussed with some individuals):
> > >"The Switching Type field is provided to allow nodes having
> > >multiple switching layer capabilities to indicate their
> > >preference. This field should only be used to indicate the
> > >link switching preference but not end-to-end switching
> > >preference".
> > >
> > >Notice that some proposal concerning the applicability scope
> > >have been proposed but never really committed within the I-D.
> > >
> > >Cheers,
> > >- dimitri.
> > >
> > >Zhi-Wei Lin wrote:
> > > >
> > > > Hi John,
> > > >
> > > > > <z>The section you mentioned, from what I can tell, is an example 
>list
> > > > > of some possible combinations of different equipment functions. I 
>see
> > > > > them as examples. But as I said, from routing perspective, it may 
>make
> > > > > sense but not signaling. What you've pointed out is the routing
> > >document...
> > > > >  From signaling perspective, if I removed the switching capability
> > > > > field, there is nothing lost...do you agree?
> > > > >
> > > > >
> > > > > JD:  No.  I will try again. What you have to demonstrate is that 
>for
> > >all
> > > > > possible combinations of switching capabilities supported on a 
>link,
> > >an
> > > > > intermediate node can deduce, from other fields in the Path 
>message,
> > >what
> > > > > switching capability is desired.
> > > > >
> > > >
> > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > different switching capabilities on each side and the possible
> > > > connections and then demonstrate that what switching capability is
> > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > encoding type says and the sender_tspec says is what the switching 
>type
> > > > used (I'm lazy, it takes too long to run through all the
> > >combinations)</z>
> > > >
> > > > >
> > > > > And if I removed the switching capability field, then it opens the
> > >door
> > > > > for the possibility where somewhere within my network I might 
>change
> > >the
> > > > > switching type in order to satisfy a request (because the 
>switching
> > >type
> > > > > requested is non-existent or exhausted).</z>
> > > > >
> > > > >
> > > > > JD: Please give an example of where substituting one value of
> > >switching
> > > > > capability for another in the middle of an LSP makes sense.
> > > > >
> > > >
> > > > <z>Well, for example, you have a SONET network that can provide 
>STS-48c,
> > > > and it goes through an all-optical network that can provide OCh1 
>(2.5G
> > > > service). In the SONET network it switches the STS-48c layer, while 
>in
> > > > OTN network it switches the OCh layer. This is very similar to 
>E1/VC-12
> > > > connection, where one part of network may work PDH-based and 
>switching
> > > > E1 while another part may be SDH-based and switching VC-12, but the
> > > > connection or service is essentially the same. They're not really
> > > > client-server layers but similar layers from different
> > >technologies...</z>
> > > >
> > > > > <z>I think it does make sense. I think you have to assume that 
>within
> > > > > the switched transport network there will be many kinds of 
>interfaces
> > > > > connecting to the transport network. If you can't offer this
> > >capability,
> > > > > then essentially what you've done is segment the transport network
> > >into
> > > > > sub-networks based on what interfaces they have and only the 
>like-type
> > > > > interfaces can connect to each other. If you look at the IP world, 
>you
> > > > > might have a switch with 100 Mbps and another with 10 Mbps 
>connected
> > > > > together and talking to each other without a problem. This is
> > >capability
> > > > > that is also needed, where one end could be 1 Gbps Ethernet and
> > >another
> > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET 
>(no
> > > > > reason to restrict this). What really matters is that the service 
>is
> > > > > delivered. Granted there will be some inefficiencies in this, but
> > >that's
> > > > > really a policy decision whether users are willing to accept this 
>type
> > > > > of connection.</z>
> > > > >
> > > > >
> > > > > JD:  What you're describing here is PSC LSPs and they work just 
>fine.
> > >What
> > > > > you were describing in your previous example was an LSP, one end 
>of
> > >which
> > > > > was
> > > > > PSC and the other end of which was TDM.  And that doesn't make 
>sense.
> > > > >
> > > >
> > > > <z>Maybe this is one where we need to ask individuals with 
>operational
> > > > experience and have some experience with service provisioning 
>whether
> > > > having one end with Ethernet and another end with OC-48 sounds like 
>a
> > > > configuration that makes sense?
> > > >
> > > > Again, the point here is that if this doesn't make sense, then
> > > > essentially what you have is multiple switched networks, each 
>serving
> > > > one particular type of customer interface, i.e., a switched network 
>for
> > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > >
> > > > Is this one of those "violent agreements" where we're concentrating 
>on
> > > > two different levels but saying the same thing?</z>
> > ><< dimitri.papadimitriou.vcf >>
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 31 Oct 2001 17:22:38 -0800
To: Dimitri Papadimitriou <[email-masked]>
cc: [email-masked]
Subject: Re: Moving right along ... Switching Type 
Date: Wed, 31 Oct 2001 17:21:09 -0800
From: Yakov Rekhter <[email-masked]>

Dimitri,

> We have two approaches either "traffic-parameters" are used
> (in SENDER_TSPEC) then i think the Switching Type capability 
> is useless or they aren't then such field could be optionaly
> used when applicable (some examples are given in the routing
> document).
> 
> Wouldn't be the right way to proceed by defining an "unknown"
> or "unspecified" value used when "traffic-parameters" are 
> included within the Path Message and optional use the ones 
> proposed in the current version of the specification when they 
> aren't. This field is thus optional and MUST only be used when 
> traffic parameters are not defined. I think this solves both 
> approaches.

Agreed.
  
Yakov.

Delivery-date: Wed, 31 Oct 2001 17:20:54 -0800
To: Zhi-Wei Lin <[email-masked]>
cc: [email-masked]
Subject: Re: Moving right along ... Switching Type 
Date: Wed, 31 Oct 2001 17:18:32 -0800
From: Yakov Rekhter <[email-masked]>

Zhi-Wei,

> <z>Maybe this is one where we need to ask individuals with operational 
> experience and have some experience with service provisioning whether 
> having one end with Ethernet and another end with OC-48 sounds like a 
> configuration that makes sense?

Let me see if I understand your proposal. Consider the following
example:

   R1---OXC1---OXC2----R2

where the TE interface on R1 is a collection of GigE ports, and the TE
interface on R2 is a collection of OC-48 ports. Are you saying that
establishing an LSP between R1 to R2 makes sense ?

Yakov.

Delivery-date: Wed, 31 Oct 2001 17:20:49 -0800
From: John Drake <[email-masked]>
To: 'Ben Mack-Crane' <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 17:17:07 -0800

-----Original Message-----
From: Ben Mack-Crane [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 2:10 PM
To: John Drake
Cc: [email-masked]
Subject: Re: Moving right along ... Switching Type

John,

I had read the routing drafts (as thet are referenced from the signaling
drafts), and was expressing confusion as a result.

The Switching Type values are very broad (each includes several possible
encapsulations, including NULL, of the LSP being created).  What exactly
they include is not clear. For example I don't know where G.709 switching 
would be included.  In fact, even the names are a bit confusing, for example
"TDM Capable" -- I don't see what multiplexing has to do with switching
(one can switch among both multiplexed and non-multiplexed interfaces).
I assume "TDM Capable" means SONET/SDH and maybe PDH...

JD:  All of the above.  Switching Capability is just a rename of Link
Multiplex. 

I have always thought that the LSP Encoding Type, along with the TSPEC,
was sufficient to indicate what was being setup (switched) and that how 
that LSP was encapsulated on each link was a local issue.  For example,
a packet LSP may be encapsulated in Ethernet, ATM, or FR on any given
link along its path, even switched in those forms over several hops, but
this is not an end-to-end concern.  In fact, restricting the switching
type in this case would only artificially restrict the set of available 
routes.

JD:  The LSP encoding type doesn't indicate a link's multiplexing 
capabilities.  The switching capability, nee multiplexing capability,
is used to indicate the type of LSPs that can be multiplexed on that 
link.

Similarly, I think that if one wants to set up an OC-48 RS transparent
LSP, it may be switched at some hop(s) over Lambda-Switch capable
links and at some hops over TDM Capable links or even Fiber Switch capable
links, and that is just fine.  Why one would want to restrict this 
is not clear.

JD:  The way that this would be done in GMPLS is through the use of LSP
hierarchy.

Regards,
Ben

John Drake wrote:
> 
> Ben,
> 
> I think part of the problem is that you also need to read the GMPLS
routing
> drafts:
> 
>
http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> 
> There are also comments in your text.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 9:53 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ... Switching Type
> 
> In reviewing the GMPLS signaling drafts I have been unable to
> get a clear understanding of the need for and use of the Switching
> Type field in the Generalized Label Request object.
> 
> JD:  The Switching Type field is for handling the situation where there
> are multiple switching capabilities per interface (see section 6.4.6 of
> draft-ietf-ccamp-gmpls-routing-00.txt)
> 
> This appears to be an attempt to address LSP setup involving multiple
> layer networks, but it does not adequately address the issues involved.
> 
> JD:  Would you please provide some additional prose explaining your
> reasoning on this?
> 
> That it "Indicates the type of switching that should be performed on a
> particular link." makes it seem to be a local concern, while others
> have indicated it is an end-to-end field. For example, George Swallow
> says "It is my understanding that for a given LSP it does not change,
> but is carried end-to-end and applies at all intermediate hops along
> the path."
> 
> JD:  I think George's interpretation is correct, and I don't think the
> other text you quoted contradicts George.  If a given TE link supports
> multiple switching types, the node controlling that link needs to know
> what switching type a given LSP wants to use.
> 
> As an end-to-end item I have trouble understanding how the originating
node
> would determine how to set this (on what basis one determines what
switching
> choice to make in all cases).  In fact, I'm not sure why the originating
> node would care what type of switching is used as long as the LSP is
> delivered
> to the egress faithfully.
> 
> JD:  The orgin node uses the switching capability information in the link
> state
> database in its CSPF calculation to ensure that switching capability is
> consistent
> along the path of the LSP.
> 
> Regards,
> Ben Mack-Crane

Delivery-date: Wed, 31 Oct 2001 16:36:43 -0800
Date: Thu, 01 Nov 2001 01:30:49 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Moving right along ... Switching Type

This is a multi-part message in MIME format.
--------------3C32C4292B884F76205AB78B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Manoj,

When Traffic_Parameters are used to create VC-4-Xc LSP for 
instance, Switching Type would take a default value without
significance on the node switching capability preference since 
inferred by the Traffic_Parameters. So when creating SDH/Sonet 
LSP the Switching Type value will be ignored.

PS: better to rephrase the below sentence as follows:
> >The usage of this field is thus optional and can (when applicable)
> >only be considered when traffic parameters are not defined.

Hope this clarifies,

- dimitri.

manoj juneja wrote:
> 
> Hi Dimitri,
>             Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> per my understanding these are mandatory as it gives information
> regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> etc). If SDH/SONET traffic parameters are not present then how can I
> determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> type ?
> 
> Please correct me if I am wrong.
> 
> Regards,
> manoj.
> 
> >From: Dimitri Papadimitriou <[email-masked]>
> >To: Zhi-Wei Lin <[email-masked]>
> >CC: John Drake <[email-masked]>,   "'Ben Mack-Crane'"
> ><[email-masked]>,   Kireeti Kompella <[email-masked]>,
> >[email-masked]
> >Subject: Re: Moving right along ... Switching Type
> >Date: Wed, 31 Oct 2001 23:52:16 +0100
> >
> >Hi,
> >
> >We have two approaches either "traffic-parameters" are used
> >(in SENDER_TSPEC) then i think the Switching Type capability
> >is useless or they aren't then such field could be optionaly
> >used when applicable (some examples are given in the routing
> >document).
> >
> >Wouldn't be the right way to proceed by defining an "unknown"
> >or "unspecified" value used when "traffic-parameters" are
> >included within the Path Message and optional use the ones
> >proposed in the current version of the specification when they
> >aren't. This field is thus optional and MUST only be used when
> >traffic parameters are not defined. I think this solves both
> >approaches.
> >
> >I think that also some additional text is needed in order to
> >clarify the semantic; the following one can be proposed (after
> >having discussed with some individuals):
> >"The Switching Type field is provided to allow nodes having
> >multiple switching layer capabilities to indicate their
> >preference. This field should only be used to indicate the
> >link switching preference but not end-to-end switching
> >preference".
> >
> >Notice that some proposal concerning the applicability scope
> >have been proposed but never really committed within the I-D.
> >
> >Cheers,
> >- dimitri.
> >
> >Zhi-Wei Lin wrote:
> > >
> > > Hi John,
> > >
> > > > <z>The section you mentioned, from what I can tell, is an example list
> > > > of some possible combinations of different equipment functions. I see
> > > > them as examples. But as I said, from routing perspective, it may make
> > > > sense but not signaling. What you've pointed out is the routing
> >document...
> > > >  From signaling perspective, if I removed the switching capability
> > > > field, there is nothing lost...do you agree?
> > > >
> > > >
> > > > JD:  No.  I will try again. What you have to demonstrate is that for
> >all
> > > > possible combinations of switching capabilities supported on a link,
> >an
> > > > intermediate node can deduce, from other fields in the Path message,
> >what
> > > > switching capability is desired.
> > > >
> > >
> > > <z>Wow...ok...so I have to list all the different combinations of
> > > different switching capabilities on each side and the possible
> > > connections and then demonstrate that what switching capability is
> > > desired can be deduced...hmmm...can't I just say that whatever the
> > > encoding type says and the sender_tspec says is what the switching type
> > > used (I'm lazy, it takes too long to run through all the
> >combinations)</z>
> > >
> > > >
> > > > And if I removed the switching capability field, then it opens the
> >door
> > > > for the possibility where somewhere within my network I might change
> >the
> > > > switching type in order to satisfy a request (because the switching
> >type
> > > > requested is non-existent or exhausted).</z>
> > > >
> > > >
> > > > JD: Please give an example of where substituting one value of
> >switching
> > > > capability for another in the middle of an LSP makes sense.
> > > >
> > >
> > > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > > and it goes through an all-optical network that can provide OCh1 (2.5G
> > > service). In the SONET network it switches the STS-48c layer, while in
> > > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > > connection, where one part of network may work PDH-based and switching
> > > E1 while another part may be SDH-based and switching VC-12, but the
> > > connection or service is essentially the same. They're not really
> > > client-server layers but similar layers from different
> >technologies...</z>
> > >
> > > > <z>I think it does make sense. I think you have to assume that within
> > > > the switched transport network there will be many kinds of interfaces
> > > > connecting to the transport network. If you can't offer this
> >capability,
> > > > then essentially what you've done is segment the transport network
> >into
> > > > sub-networks based on what interfaces they have and only the like-type
> > > > interfaces can connect to each other. If you look at the IP world, you
> > > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > > together and talking to each other without a problem. This is
> >capability
> > > > that is also needed, where one end could be 1 Gbps Ethernet and
> >another
> > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > > reason to restrict this). What really matters is that the service is
> > > > delivered. Granted there will be some inefficiencies in this, but
> >that's
> > > > really a policy decision whether users are willing to accept this type
> > > > of connection.</z>
> > > >
> > > >
> > > > JD:  What you're describing here is PSC LSPs and they work just fine.
> >What
> > > > you were describing in your previous example was an LSP, one end of
> >which
> > > > was
> > > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > > >
> > >
> > > <z>Maybe this is one where we need to ask individuals with operational
> > > experience and have some experience with service provisioning whether
> > > having one end with Ethernet and another end with OC-48 sounds like a
> > > configuration that makes sense?
> > >
> > > Again, the point here is that if this doesn't make sense, then
> > > essentially what you have is multiple switched networks, each serving
> > > one particular type of customer interface, i.e., a switched network for
> > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > >
> > > Is this one of those "violent agreements" where we're concentrating on
> > > two different levels but saying the same thing?</z>
> ><< dimitri.papadimitriou.vcf >>
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------3C32C4292B884F76205AB78B
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------3C32C4292B884F76205AB78B--

Delivery-date: Wed, 31 Oct 2001 15:47:39 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 16:43:33 -0700

Hi Dimitri,
            Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
per my understanding these are mandatory as it gives information
regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
etc). If SDH/SONET traffic parameters are not present then how can I
determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
type ?

Please correct me if I am wrong.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: Zhi-Wei Lin <[email-masked]>
>CC: John Drake <[email-masked]>,   "'Ben Mack-Crane'" 
><[email-masked]>,   Kireeti Kompella <[email-masked]>, 
>[email-masked]
>Subject: Re: Moving right along ... Switching Type
>Date: Wed, 31 Oct 2001 23:52:16 +0100
>
>Hi,
>
>We have two approaches either "traffic-parameters" are used
>(in SENDER_TSPEC) then i think the Switching Type capability
>is useless or they aren't then such field could be optionaly
>used when applicable (some examples are given in the routing
>document).
>
>Wouldn't be the right way to proceed by defining an "unknown"
>or "unspecified" value used when "traffic-parameters" are
>included within the Path Message and optional use the ones
>proposed in the current version of the specification when they
>aren't. This field is thus optional and MUST only be used when
>traffic parameters are not defined. I think this solves both
>approaches.
>
>I think that also some additional text is needed in order to
>clarify the semantic; the following one can be proposed (after
>having discussed with some individuals):
>"The Switching Type field is provided to allow nodes having
>multiple switching layer capabilities to indicate their
>preference. This field should only be used to indicate the
>link switching preference but not end-to-end switching
>preference".
>
>Notice that some proposal concerning the applicability scope
>have been proposed but never really committed within the I-D.
>
>Cheers,
>- dimitri.
>
>Zhi-Wei Lin wrote:
> >
> > Hi John,
> >
> > > <z>The section you mentioned, from what I can tell, is an example list
> > > of some possible combinations of different equipment functions. I see
> > > them as examples. But as I said, from routing perspective, it may make
> > > sense but not signaling. What you've pointed out is the routing 
>document...
> > >  From signaling perspective, if I removed the switching capability
> > > field, there is nothing lost...do you agree?
> > >
> > >
> > > JD:  No.  I will try again. What you have to demonstrate is that for 
>all
> > > possible combinations of switching capabilities supported on a link, 
>an
> > > intermediate node can deduce, from other fields in the Path message, 
>what
> > > switching capability is desired.
> > >
> >
> > <z>Wow...ok...so I have to list all the different combinations of
> > different switching capabilities on each side and the possible
> > connections and then demonstrate that what switching capability is
> > desired can be deduced...hmmm...can't I just say that whatever the
> > encoding type says and the sender_tspec says is what the switching type
> > used (I'm lazy, it takes too long to run through all the 
>combinations)</z>
> >
> > >
> > > And if I removed the switching capability field, then it opens the 
>door
> > > for the possibility where somewhere within my network I might change 
>the
> > > switching type in order to satisfy a request (because the switching 
>type
> > > requested is non-existent or exhausted).</z>
> > >
> > >
> > > JD: Please give an example of where substituting one value of 
>switching
> > > capability for another in the middle of an LSP makes sense.
> > >
> >
> > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > and it goes through an all-optical network that can provide OCh1 (2.5G
> > service). In the SONET network it switches the STS-48c layer, while in
> > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > connection, where one part of network may work PDH-based and switching
> > E1 while another part may be SDH-based and switching VC-12, but the
> > connection or service is essentially the same. They're not really
> > client-server layers but similar layers from different 
>technologies...</z>
> >
> > > <z>I think it does make sense. I think you have to assume that within
> > > the switched transport network there will be many kinds of interfaces
> > > connecting to the transport network. If you can't offer this 
>capability,
> > > then essentially what you've done is segment the transport network 
>into
> > > sub-networks based on what interfaces they have and only the like-type
> > > interfaces can connect to each other. If you look at the IP world, you
> > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > together and talking to each other without a problem. This is 
>capability
> > > that is also needed, where one end could be 1 Gbps Ethernet and 
>another
> > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > reason to restrict this). What really matters is that the service is
> > > delivered. Granted there will be some inefficiencies in this, but 
>that's
> > > really a policy decision whether users are willing to accept this type
> > > of connection.</z>
> > >
> > >
> > > JD:  What you're describing here is PSC LSPs and they work just fine.  
>What
> > > you were describing in your previous example was an LSP, one end of 
>which
> > > was
> > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > >
> >
> > <z>Maybe this is one where we need to ask individuals with operational
> > experience and have some experience with service provisioning whether
> > having one end with Ethernet and another end with OC-48 sounds like a
> > configuration that makes sense?
> >
> > Again, the point here is that if this doesn't make sense, then
> > essentially what you have is multiple switched networks, each serving
> > one particular type of customer interface, i.e., a switched network for
> > 1 Gb Ethernet, a switched network for OC-48, etc.
> >
> > Is this one of those "violent agreements" where we're concentrating on
> > two different levels but saying the same thing?</z>
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Wed, 31 Oct 2001 14:59:42 -0800
Date: Wed, 31 Oct 2001 23:52:16 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Zhi-Wei Lin <[email-masked]>
CC: John Drake <[email-masked]>, "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

This is a multi-part message in MIME format.
--------------EB27C59D3EBF0CD7965DFC1B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

We have two approaches either "traffic-parameters" are used
(in SENDER_TSPEC) then i think the Switching Type capability 
is useless or they aren't then such field could be optionaly
used when applicable (some examples are given in the routing
document).

Wouldn't be the right way to proceed by defining an "unknown"
or "unspecified" value used when "traffic-parameters" are 
included within the Path Message and optional use the ones 
proposed in the current version of the specification when they 
aren't. This field is thus optional and MUST only be used when 
traffic parameters are not defined. I think this solves both 
approaches.

I think that also some additional text is needed in order to
clarify the semantic; the following one can be proposed (after 
having discussed with some individuals):
"The Switching Type field is provided to allow nodes having 
multiple switching layer capabilities to indicate their 
preference. This field should only be used to indicate the 
link switching preference but not end-to-end switching 
preference".

Notice that some proposal concerning the applicability scope 
have been proposed but never really committed within the I-D. 

Cheers,
- dimitri.

Zhi-Wei Lin wrote:
> 
> Hi John,
> 
> > <z>The section you mentioned, from what I can tell, is an example list
> > of some possible combinations of different equipment functions. I see
> > them as examples. But as I said, from routing perspective, it may make
> > sense but not signaling. What you've pointed out is the routing document...
> >  From signaling perspective, if I removed the switching capability
> > field, there is nothing lost...do you agree?
> >
> >
> > JD:  No.  I will try again. What you have to demonstrate is that for all
> > possible combinations of switching capabilities supported on a link, an
> > intermediate node can deduce, from other fields in the Path message, what
> > switching capability is desired.
> >
> 
> <z>Wow...ok...so I have to list all the different combinations of
> different switching capabilities on each side and the possible
> connections and then demonstrate that what switching capability is
> desired can be deduced...hmmm...can't I just say that whatever the
> encoding type says and the sender_tspec says is what the switching type
> used (I'm lazy, it takes too long to run through all the combinations)</z>
> 
> >
> > And if I removed the switching capability field, then it opens the door
> > for the possibility where somewhere within my network I might change the
> > switching type in order to satisfy a request (because the switching type
> > requested is non-existent or exhausted).</z>
> >
> >
> > JD: Please give an example of where substituting one value of switching
> > capability for another in the middle of an LSP makes sense.
> >
> 
> <z>Well, for example, you have a SONET network that can provide STS-48c,
> and it goes through an all-optical network that can provide OCh1 (2.5G
> service). In the SONET network it switches the STS-48c layer, while in
> OTN network it switches the OCh layer. This is very similar to E1/VC-12
> connection, where one part of network may work PDH-based and switching
> E1 while another part may be SDH-based and switching VC-12, but the
> connection or service is essentially the same. They're not really
> client-server layers but similar layers from different technologies...</z>
> 
> > <z>I think it does make sense. I think you have to assume that within
> > the switched transport network there will be many kinds of interfaces
> > connecting to the transport network. If you can't offer this capability,
> > then essentially what you've done is segment the transport network into
> > sub-networks based on what interfaces they have and only the like-type
> > interfaces can connect to each other. If you look at the IP world, you
> > might have a switch with 100 Mbps and another with 10 Mbps connected
> > together and talking to each other without a problem. This is capability
> > that is also needed, where one end could be 1 Gbps Ethernet and another
> > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > reason to restrict this). What really matters is that the service is
> > delivered. Granted there will be some inefficiencies in this, but that's
> > really a policy decision whether users are willing to accept this type
> > of connection.</z>
> >
> >
> > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > you were describing in your previous example was an LSP, one end of which
> > was
> > PSC and the other end of which was TDM.  And that doesn't make sense.
> >
> 
> <z>Maybe this is one where we need to ask individuals with operational
> experience and have some experience with service provisioning whether
> having one end with Ethernet and another end with OC-48 sounds like a
> configuration that makes sense?
> 
> Again, the point here is that if this doesn't make sense, then
> essentially what you have is multiple switched networks, each serving
> one particular type of customer interface, i.e., a switched network for
> 1 Gb Ethernet, a switched network for OC-48, etc.
> 
> Is this one of those "violent agreements" where we're concentrating on
> two different levels but saying the same thing?</z>
--------------EB27C59D3EBF0CD7965DFC1B
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------EB27C59D3EBF0CD7965DFC1B--

Delivery-date: Wed, 31 Oct 2001 14:17:22 -0800
Date: Wed, 31 Oct 2001 16:10:07 -0600
From: Ben Mack-Crane <[email-masked]>
To: John Drake <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

John,

I had read the routing drafts (as thet are referenced from the signaling
drafts), and was expressing confusion as a result.

The Switching Type values are very broad (each includes several possible
encapsulations, including NULL, of the LSP being created).  What exactly
they include is not clear. For example I don't know where G.709 switching 
would be included.  In fact, even the names are a bit confusing, for example
"TDM Capable" -- I don't see what multiplexing has to do with switching
(one can switch among both multiplexed and non-multiplexed interfaces).
I assume "TDM Capable" means SONET/SDH and maybe PDH...

I have always thought that the LSP Encoding Type, along with the TSPEC,
was sufficient to indicate what was being setup (switched) and that how 
that LSP was encapsulated on each link was a local issue.  For example,
a packet LSP may be encapsulated in Ethernet, ATM, or FR on any given
link along its path, even switched in those forms over several hops, but
this is not an end-to-end concern.  In fact, restricting the switching
type in this case would only artificially restrict the set of available 
routes.

Similarly, I think that if one wants to set up an OC-48 RS transparent
LSP, it may be switched at some hop(s) over Lambda-Switch capable
links and at some hops over TDM Capable links or even Fiber Switch capable
links, and that is just fine.  Why one would want to restrict this 
is not clear.

Regards,
Ben

John Drake wrote:
> 
> Ben,
> 
> I think part of the problem is that you also need to read the GMPLS routing
> drafts:
> 
> http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> 
> There are also comments in your text.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 9:53 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ... Switching Type
> 
> In reviewing the GMPLS signaling drafts I have been unable to
> get a clear understanding of the need for and use of the Switching
> Type field in the Generalized Label Request object.
> 
> JD:  The Switching Type field is for handling the situation where there
> are multiple switching capabilities per interface (see section 6.4.6 of
> draft-ietf-ccamp-gmpls-routing-00.txt)
> 
> This appears to be an attempt to address LSP setup involving multiple
> layer networks, but it does not adequately address the issues involved.
> 
> JD:  Would you please provide some additional prose explaining your
> reasoning on this?
> 
> That it "Indicates the type of switching that should be performed on a
> particular link." makes it seem to be a local concern, while others
> have indicated it is an end-to-end field. For example, George Swallow
> says "It is my understanding that for a given LSP it does not change,
> but is carried end-to-end and applies at all intermediate hops along
> the path."
> 
> JD:  I think George's interpretation is correct, and I don't think the
> other text you quoted contradicts George.  If a given TE link supports
> multiple switching types, the node controlling that link needs to know
> what switching type a given LSP wants to use.
> 
> As an end-to-end item I have trouble understanding how the originating node
> would determine how to set this (on what basis one determines what switching
> choice to make in all cases).  In fact, I'm not sure why the originating
> node would care what type of switching is used as long as the LSP is
> delivered
> to the egress faithfully.
> 
> JD:  The orgin node uses the switching capability information in the link
> state
> database in its CSPF calculation to ensure that switching capability is
> consistent
> along the path of the LSP.
> 
> Regards,
> Ben Mack-Crane

Delivery-date: Wed, 31 Oct 2001 14:02:09 -0800
Date: Wed, 31 Oct 2001 16:59:43 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John,

> <z>The section you mentioned, from what I can tell, is an example list 
> of some possible combinations of different equipment functions. I see 
> them as examples. But as I said, from routing perspective, it may make 
> sense but not signaling. What you've pointed out is the routing document...
>  From signaling perspective, if I removed the switching capability 
> field, there is nothing lost...do you agree?
> 
> 
> JD:  No.  I will try again. What you have to demonstrate is that for all
> possible combinations of switching capabilities supported on a link, an
> intermediate node can deduce, from other fields in the Path message, what
> switching capability is desired.   
> 

<z>Wow...ok...so I have to list all the different combinations of 
different switching capabilities on each side and the possible 
connections and then demonstrate that what switching capability is 
desired can be deduced...hmmm...can't I just say that whatever the 
encoding type says and the sender_tspec says is what the switching type 
used (I'm lazy, it takes too long to run through all the combinations)</z>

> 
> And if I removed the switching capability field, then it opens the door 
> for the possibility where somewhere within my network I might change the 
> switching type in order to satisfy a request (because the switching type 
> requested is non-existent or exhausted).</z>
> 
> 
> JD: Please give an example of where substituting one value of switching
> capability for another in the middle of an LSP makes sense.   
> 

<z>Well, for example, you have a SONET network that can provide STS-48c, 
and it goes through an all-optical network that can provide OCh1 (2.5G 
service). In the SONET network it switches the STS-48c layer, while in 
OTN network it switches the OCh layer. This is very similar to E1/VC-12 
connection, where one part of network may work PDH-based and switching 
E1 while another part may be SDH-based and switching VC-12, but the 
connection or service is essentially the same. They're not really 
client-server layers but similar layers from different technologies...</z>

> <z>I think it does make sense. I think you have to assume that within 
> the switched transport network there will be many kinds of interfaces 
> connecting to the transport network. If you can't offer this capability, 
> then essentially what you've done is segment the transport network into 
> sub-networks based on what interfaces they have and only the like-type 
> interfaces can connect to each other. If you look at the IP world, you 
> might have a switch with 100 Mbps and another with 10 Mbps connected 
> together and talking to each other without a problem. This is capability 
> that is also needed, where one end could be 1 Gbps Ethernet and another 
> end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no 
> reason to restrict this). What really matters is that the service is 
> delivered. Granted there will be some inefficiencies in this, but that's 
> really a policy decision whether users are willing to accept this type 
> of connection.</z>
> 
> 
> JD:  What you're describing here is PSC LSPs and they work just fine.  What
> you were describing in your previous example was an LSP, one end of which
> was
> PSC and the other end of which was TDM.  And that doesn't make sense.
> 

<z>Maybe this is one where we need to ask individuals with operational 
experience and have some experience with service provisioning whether 
having one end with Ethernet and another end with OC-48 sounds like a 
configuration that makes sense?

Again, the point here is that if this doesn't make sense, then 
essentially what you have is multiple switched networks, each serving 
one particular type of customer interface, i.e., a switched network for 
1 Gb Ethernet, a switched network for OC-48, etc.

Is this one of those "violent agreements" where we're concentrating on 
two different levels but saying the same thing?</z>

Delivery-date: Wed, 31 Oct 2001 13:20:02 -0800
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>
Cc: 'Ben Mack-Crane' <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 13:14:30 -0800

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 12:54 PM
To: John Drake
Cc: 'Ben Mack-Crane'; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John,

> <z>Sorry. I thought this was akin to "obvious to the informed reader". 
> ;-) Just kidding. Anyway, let's give an example...
> 
> The user has a router with OC-48 physical interface, and is capable of 
> requesting STS-3c or STS-12c or STS-48c services across that interface. 
> So now the router has three levels of switching capability within the 
> TDM layer (as IETF defines the TDM layer).
> 
> Now also assume that the network as a whole can support packet 
> switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, 
> STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its 
> interfaces can support multiples of these types.
> 
> However, even in this case, when the router makes a request, let's say 
> it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST 
> object, & the SENDER_TSPEC object tells you what switching to use. Thus 
> when the network (intermediate nodes) receives these objects, it knows 
> what switching to use and what signal is been received at the interface. 
> Therefore the switching capability doesn't tell me anything that is not 
> already present or not already known by the nodes (another assertion?).
> 
> Hope this was what you were looking for...</z>
> 
> JD:  What you give here is an example, not a design.  You need to
enumerate
> the procedure for all possible combinations of multiple switching
> capabilities.
> As a start I'd suggest going through the examples in
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt,

> Section 6.4.9.x.  To be clear, I am not saying that it is not possible
> to derive a procedure for all possible combinations.  What I am saying
> is that I don't know if it is possible, but I do know that specifying
> switching capability works in all cases in a consistent manner.    
> 

<z>The section you mentioned, from what I can tell, is an example list 
of some possible combinations of different equipment functions. I see 
them as examples. But as I said, from routing perspective, it may make 
sense but not signaling. What you've pointed out is the routing document...
 From signaling perspective, if I removed the switching capability 
field, there is nothing lost...do you agree?

JD:  No.  I will try again. What you have to demonstrate is that for all
possible combinations of switching capabilities supported on a link, an
intermediate node can deduce, from other fields in the Path message, what
switching capability is desired.   

And if I removed the switching capability field, then it opens the door 
for the possibility where somewhere within my network I might change the 
switching type in order to satisfy a request (because the switching type 
requested is non-existent or exhausted).</z>

JD: Please give an example of where substituting one value of switching
capability for another in the middle of an LSP makes sense.   

> <z>If that's the case, how would you support a non-homogenous 
> (heterogenous?) connection? By that I mean at the source end it is one 
> type of interface and at the destination end it is another type of 
> interface and each end cannot support the other end's switching
capability.
> 
> For example, at the source-end, the physical interface is a 1 Gb 
> Ethernet. At the destination-end, the physical interface is an OC-48 
> interface. In this example, the switching capability at the source may 
> be PSC. However at the destination end the switching capability may be 
> TDM. The service requested is to be able to transport a "100 Mbps date 
> stream" from source to destination.
> 
> 
> JD:  The endpoints of an LSP need to have a common understanding of the
> multiplexing used on that LSP, so I don't think your example makes sense.
> 

<z>I think it does make sense. I think you have to assume that within 
the switched transport network there will be many kinds of interfaces 
connecting to the transport network. If you can't offer this capability, 
then essentially what you've done is segment the transport network into 
sub-networks based on what interfaces they have and only the like-type 
interfaces can connect to each other. If you look at the IP world, you 
might have a switch with 100 Mbps and another with 10 Mbps connected 
together and talking to each other without a problem. This is capability 
that is also needed, where one end could be 1 Gbps Ethernet and another 
end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no 
reason to restrict this). What really matters is that the service is 
delivered. Granted there will be some inefficiencies in this, but that's 
really a policy decision whether users are willing to accept this type 
of connection.</z>

JD:  What you're describing here is PSC LSPs and they work just fine.  What
you were describing in your previous example was an LSP, one end of which
was
PSC and the other end of which was TDM.  And that doesn't make sense.

> 
> I think for this, what is important is that the service requested can be 
> supported end-to-end, not the switching capability supported, nor the 
> signal type supported. Switching and signal type are a means to support 
> a service, not an end to itself.</z>
> 
> 
> JD:  As far as I know, GMPLS doesn't deal with service definition.
> 

<z>Right. It's a tool to support these services</z>

Delivery-date: Wed, 31 Oct 2001 12:58:37 -0800
Date: Wed, 31 Oct 2001 15:54:01 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John,

> <z>Sorry. I thought this was akin to "obvious to the informed reader". 
> ;-) Just kidding. Anyway, let's give an example...
> 
> The user has a router with OC-48 physical interface, and is capable of 
> requesting STS-3c or STS-12c or STS-48c services across that interface. 
> So now the router has three levels of switching capability within the 
> TDM layer (as IETF defines the TDM layer).
> 
> Now also assume that the network as a whole can support packet 
> switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, 
> STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its 
> interfaces can support multiples of these types.
> 
> However, even in this case, when the router makes a request, let's say 
> it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST 
> object, & the SENDER_TSPEC object tells you what switching to use. Thus 
> when the network (intermediate nodes) receives these objects, it knows 
> what switching to use and what signal is been received at the interface. 
> Therefore the switching capability doesn't tell me anything that is not 
> already present or not already known by the nodes (another assertion?).
> 
> Hope this was what you were looking for...</z>
> 
> JD:  What you give here is an example, not a design.  You need to enumerate
> the procedure for all possible combinations of multiple switching
> capabilities.
> As a start I'd suggest going through the examples in
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt, 
> Section 6.4.9.x.  To be clear, I am not saying that it is not possible
> to derive a procedure for all possible combinations.  What I am saying
> is that I don't know if it is possible, but I do know that specifying
> switching capability works in all cases in a consistent manner.    
> 

<z>The section you mentioned, from what I can tell, is an example list 
of some possible combinations of different equipment functions. I see 
them as examples. But as I said, from routing perspective, it may make 
sense but not signaling. What you've pointed out is the routing document...
 From signaling perspective, if I removed the switching capability 
field, there is nothing lost...do you agree?

And if I removed the switching capability field, then it opens the door 
for the possibility where somewhere within my network I might change the 
switching type in order to satisfy a request (because the switching type 
requested is non-existent or exhausted).</z>

> <z>If that's the case, how would you support a non-homogenous 
> (heterogenous?) connection? By that I mean at the source end it is one 
> type of interface and at the destination end it is another type of 
> interface and each end cannot support the other end's switching capability.
> 
> For example, at the source-end, the physical interface is a 1 Gb 
> Ethernet. At the destination-end, the physical interface is an OC-48 
> interface. In this example, the switching capability at the source may 
> be PSC. However at the destination end the switching capability may be 
> TDM. The service requested is to be able to transport a "100 Mbps date 
> stream" from source to destination.
> 
> 
> JD:  The endpoints of an LSP need to have a common understanding of the
> multiplexing used on that LSP, so I don't think your example makes sense.
> 

<z>I think it does make sense. I think you have to assume that within 
the switched transport network there will be many kinds of interfaces 
connecting to the transport network. If you can't offer this capability, 
then essentially what you've done is segment the transport network into 
sub-networks based on what interfaces they have and only the like-type 
interfaces can connect to each other. If you look at the IP world, you 
might have a switch with 100 Mbps and another with 10 Mbps connected 
together and talking to each other without a problem. This is capability 
that is also needed, where one end could be 1 Gbps Ethernet and another 
end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no 
reason to restrict this). What really matters is that the service is 
delivered. Granted there will be some inefficiencies in this, but that's 
really a policy decision whether users are willing to accept this type 
of connection.</z>

> 
> I think for this, what is important is that the service requested can be 
> supported end-to-end, not the switching capability supported, nor the 
> signal type supported. Switching and signal type are a means to support 
> a service, not an end to itself.</z>
> 
> 
> JD:  As far as I know, GMPLS doesn't deal with service definition.
> 

<z>Right. It's a tool to support these services</z>

Delivery-date: Wed, 31 Oct 2001 12:33:01 -0800
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>
Cc: 'Ben Mack-Crane' <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 12:30:21 -0800

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 10:03 AM
To: John Drake
Cc: 'Ben Mack-Crane'; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John, comments in-line.

> I think I've mentioned this before, but I'll repeat myself. I think 
> switching capability may have be useful in identifying what is allowable 
> for routing purposes and for discovery purposes.
> 
> But once those are identified, signaling does not need to get involved.
> 
> JD:  This sounds like an assertion.  It would be helpful to see a detailed
> proposal that describes how an intermediate node controlling a link with
> multiple switching capabilities can determine what switching capability
> a given LSP wishes to use.
>  

<z>Sorry. I thought this was akin to "obvious to the informed reader". 
;-) Just kidding. Anyway, let's give an example...

The user has a router with OC-48 physical interface, and is capable of 
requesting STS-3c or STS-12c or STS-48c services across that interface. 
So now the router has three levels of switching capability within the 
TDM layer (as IETF defines the TDM layer).

Now also assume that the network as a whole can support packet 
switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, 
STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its 
interfaces can support multiples of these types.

However, even in this case, when the router makes a request, let's say 
it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST 
object, & the SENDER_TSPEC object tells you what switching to use. Thus 
when the network (intermediate nodes) receives these objects, it knows 
what switching to use and what signal is been received at the interface. 
Therefore the switching capability doesn't tell me anything that is not 
already present or not already known by the nodes (another assertion?).

Hope this was what you were looking for...</z>

JD:  What you give here is an example, not a design.  You need to enumerate
the procedure for all possible combinations of multiple switching
capabilities.
As a start I'd suggest going through the examples in
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt, 
Section 6.4.9.x.  To be clear, I am not saying that it is not possible
to derive a procedure for all possible combinations.  What I am saying
is that I don't know if it is possible, but I do know that specifying
switching capability works in all cases in a consistent manner.    

> You responded to Ben that the switching capability field is end-to-end 
> and does not change in intermediate nodes. Is this right?
> 
> JD:  As far as I know.
> 

<z>If that's the case, how would you support a non-homogenous 
(heterogenous?) connection? By that I mean at the source end it is one 
type of interface and at the destination end it is another type of 
interface and each end cannot support the other end's switching capability.

For example, at the source-end, the physical interface is a 1 Gb 
Ethernet. At the destination-end, the physical interface is an OC-48 
interface. In this example, the switching capability at the source may 
be PSC. However at the destination end the switching capability may be 
TDM. The service requested is to be able to transport a "100 Mbps date 
stream" from source to destination.

JD:  The endpoints of an LSP need to have a common understanding of the
multiplexing used on that LSP, so I don't think your example makes sense.

I think for this, what is important is that the service requested can be 
supported end-to-end, not the switching capability supported, nor the 
signal type supported. Switching and signal type are a means to support 
a service, not an end to itself.</z>

JD:  As far as I know, GMPLS doesn't deal with service definition.

> Zhi
> 
> 
> 
> John Drake wrote:
> 
> 
>>Ben,
>> 
>>I think part of the problem is that you also need to read the GMPLS
>>
> routing
> 
>>drafts:
>> 
>>
>>
>
http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> 
>> 
>>There are also comments in your text.
>> 
>>Thanks,
>> 
>>John
>>
>>-----Original Message-----
>>From: Ben Mack-Crane [mailto:[email-masked]]
>>Sent: Monday, October 29, 2001 9:53 AM
>>To: Kireeti Kompella
>>Cc: [email-masked]
>>Subject: Re: Moving right along ... Switching Type
>>
>>
>>
>>In reviewing the GMPLS signaling drafts I have been unable to
>>get a clear understanding of the need for and use of the Switching
>>Type field in the Generalized Label Request object.
>>
>>
>>JD:  The Switching Type field is for handling the situation where there
>>are multiple switching capabilities per interface (see section 6.4.6 of
>>draft-ietf-ccamp-gmpls-routing-00.txt)
>>
>>
>>This appears to be an attempt to address LSP setup involving multiple
>>layer networks, but it does not adequately address the issues involved.
>>
>>
>>JD:  Would you please provide some additional prose explaining your
>>reasoning on this?
>>
>>
>>That it "Indicates the type of switching that should be performed on a
>>particular link." makes it seem to be a local concern, while others
>>have indicated it is an end-to-end field. For example, George Swallow
>>says "It is my understanding that for a given LSP it does not change, 
>>but is carried end-to-end and applies at all intermediate hops along 
>>the path."
>>
>>
>>JD:  I think George's interpretation is correct, and I don't think the
>>other text you quoted contradicts George.  If a given TE link supports
>>multiple switching types, the node controlling that link needs to know
>>what switching type a given LSP wants to use.  
>>
>>
>>As an end-to-end item I have trouble understanding how the originating
>>
> node
> 
>>would determine how to set this (on what basis one determines what
>>
> switching
> 
>>choice to make in all cases).  In fact, I'm not sure why the originating
>>node would care what type of switching is used as long as the LSP is
>>delivered
>>to the egress faithfully.
>>
>>
>>JD:  The orgin node uses the switching capability information in the link
>>state
>>database in its CSPF calculation to ensure that switching capability is
>>consistent
>>along the path of the LSP.  
>>
>>
>>Regards,
>>Ben Mack-Crane
>>
>>
>>
> 

Delivery-date: Wed, 31 Oct 2001 10:16:03 -0800
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: A question regarding draft-itef-ccamp-lmp-01.txt
Date: Wed, 31 Oct 2001 13:08:57 -0500

A question regarding draft-itef-ccamp-lmp-01.txt
In section 13.16 CONFIG_ERROR [page 60]: 

o    CONFIG_ERROR, C-Type = 1 
   
0                   1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                          ERROR CODE                           | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          
         The following bit-values are defined: 
         0x01 = Unacceptable non-negotiable CONFIG parameter 
         0x02 = Renegotiate CONFIG parameter 
         0x04 = Bad Received CCID 
 
Question: 
(1) In which situation should you have error code 
0x04 = Bad Received CCID? Since the Config message only 
bring LOCAL_CCID, the only case I can imagine is that when the 
LOCAL_ID in Config doesn't match the lmpRemoteCcId field of 
the receiving node. But in this case, shouldn't we just update the
lmpRemoteCcId field (learning remote CCId) instead of sending a 
ConfigNack with error code = 0x04?  
 
(2) For error code 0x01 and 0x02, the N bit in the Config object 
of ConfigNack already tells about which error it is (The previous 
draft use the N bit in HelloConfig TLV to handle this). 
Is it necessary to have an additional ERROR_CODE object in the
ConfigNack? I think the ERROR_CODE is redundant to the N bit 
in Config object.
 
Thanks,
Fugui

Delivery-date: Wed, 31 Oct 2001 10:09:05 -0800
Date: Wed, 31 Oct 2001 13:03:07 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John, comments in-line.

> I think I've mentioned this before, but I'll repeat myself. I think 
> switching capability may have be useful in identifying what is allowable 
> for routing purposes and for discovery purposes.
> 
> But once those are identified, signaling does not need to get involved.
> 
> JD:  This sounds like an assertion.  It would be helpful to see a detailed
> proposal that describes how an intermediate node controlling a link with
> multiple switching capabilities can determine what switching capability
> a given LSP wishes to use.
>  

<z>Sorry. I thought this was akin to "obvious to the informed reader". 
;-) Just kidding. Anyway, let's give an example...

The user has a router with OC-48 physical interface, and is capable of 
requesting STS-3c or STS-12c or STS-48c services across that interface. 
So now the router has three levels of switching capability within the 
TDM layer (as IETF defines the TDM layer).

Now also assume that the network as a whole can support packet 
switching, all levels of TDM switching (STS-1, STS-3c, STS-12c, STS-48c, 
STS-192c, ODU1, ODU2, ODU3), and OCh switching. And that some of its 
interfaces can support multiples of these types.

However, even in this case, when the router makes a request, let's say 
it asks for STS-12c. The encoding type in the GENERALIZED_LABEL_REQUEST 
object, & the SENDER_TSPEC object tells you what switching to use. Thus 
when the network (intermediate nodes) receives these objects, it knows 
what switching to use and what signal is been received at the interface. 
Therefore the switching capability doesn't tell me anything that is not 
already present or not already known by the nodes (another assertion?).

Hope this was what you were looking for...</z>

> You responded to Ben that the switching capability field is end-to-end 
> and does not change in intermediate nodes. Is this right?
> 
> JD:  As far as I know.
> 

<z>If that's the case, how would you support a non-homogenous 
(heterogenous?) connection? By that I mean at the source end it is one 
type of interface and at the destination end it is another type of 
interface and each end cannot support the other end's switching capability.

For example, at the source-end, the physical interface is a 1 Gb 
Ethernet. At the destination-end, the physical interface is an OC-48 
interface. In this example, the switching capability at the source may 
be PSC. However at the destination end the switching capability may be 
TDM. The service requested is to be able to transport a "100 Mbps date 
stream" from source to destination.

I think for this, what is important is that the service requested can be 
supported end-to-end, not the switching capability supported, nor the 
signal type supported. Switching and signal type are a means to support 
a service, not an end to itself.</z>

> Zhi
> 
> 
> 
> John Drake wrote:
> 
> 
>>Ben,
>> 
>>I think part of the problem is that you also need to read the GMPLS
>>
> routing
> 
>>drafts:
>> 
>>
>>
> http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> 
>> 
>>There are also comments in your text.
>> 
>>Thanks,
>> 
>>John
>>
>>-----Original Message-----
>>From: Ben Mack-Crane [mailto:[email-masked]]
>>Sent: Monday, October 29, 2001 9:53 AM
>>To: Kireeti Kompella
>>Cc: [email-masked]
>>Subject: Re: Moving right along ... Switching Type
>>
>>
>>
>>In reviewing the GMPLS signaling drafts I have been unable to
>>get a clear understanding of the need for and use of the Switching
>>Type field in the Generalized Label Request object.
>>
>>
>>JD:  The Switching Type field is for handling the situation where there
>>are multiple switching capabilities per interface (see section 6.4.6 of
>>draft-ietf-ccamp-gmpls-routing-00.txt)
>>
>>
>>This appears to be an attempt to address LSP setup involving multiple
>>layer networks, but it does not adequately address the issues involved.
>>
>>
>>JD:  Would you please provide some additional prose explaining your
>>reasoning on this?
>>
>>
>>That it "Indicates the type of switching that should be performed on a
>>particular link." makes it seem to be a local concern, while others
>>have indicated it is an end-to-end field. For example, George Swallow
>>says "It is my understanding that for a given LSP it does not change, 
>>but is carried end-to-end and applies at all intermediate hops along 
>>the path."
>>
>>
>>JD:  I think George's interpretation is correct, and I don't think the
>>other text you quoted contradicts George.  If a given TE link supports
>>multiple switching types, the node controlling that link needs to know
>>what switching type a given LSP wants to use.  
>>
>>
>>As an end-to-end item I have trouble understanding how the originating
>>
> node
> 
>>would determine how to set this (on what basis one determines what
>>
> switching
> 
>>choice to make in all cases).  In fact, I'm not sure why the originating
>>node would care what type of switching is used as long as the LSP is
>>delivered
>>to the egress faithfully.
>>
>>
>>JD:  The orgin node uses the switching capability information in the link
>>state
>>database in its CSPF calculation to ensure that switching capability is
>>consistent
>>along the path of the LSP.  
>>
>>
>>Regards,
>>Ben Mack-Crane
>>
>>
>>
> 

Delivery-date: Wed, 31 Oct 2001 09:01:26 -0800
Date: Wed, 31 Oct 2001 17:57:10 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Zhi-Wei Lin <[email-masked]>
CC: John Drake <[email-masked]>, "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

This is a multi-part message in MIME format.
--------------F68961D3043E70788A326320
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zhi,

Consider multi-switching OTN devices having transparent
OCh_CF and switching capabilities allowing optical signal 
regeneration if the Switching Type is set by the ingress
node how can i change the switching type when the signal
would need to be regenerated ? This is i think a case
were more flexibility is needed moreover when these
regeneration capabilities are limited over the network.
However, here the switching type does not help since the 
regeneration decision is taken locally.

Now consider a case were the ODU_CF is on top of the OCH_CF 
the edge-to-edge policy applies (the switching type won't 
change from ingress to egress) in such a case the encoding 
"OCh" would correspond to the switching type "lambda" same 
behaviour applies for ODU switching layer. Here therefore
"identification" is enough and putting the the Switching type 
in the signalling does not need to be involved while it 
doesn't harm in fact - this is typically the situation
with the ASON/ASTN model.

However, there is a case were such capability is useful
it is when having multiservice devices and several policies
have to be applied at the ingress for instance use the 
most suitable switching capability depending on the 
connection request, parameters, capabilities, etc. in
such a way that the local decision can be performed by
the ingress when specifying the switching type.

Nevertheless if i have to follow your reasoning, the TE 
decision can be performed at the ingress but after you 
don't need to identify the switching type to be used
Could you then tell me how to describe the latter case ?

Where i agree is that on this specific issue, more text 
would be really welcome,... one can not afford to use 
different semantic and processing for the same parameter.
And does not apply to any "multiservice" case since some
of them could be implicitly inferred.

- dimitri.

Zhi-Wei Lin wrote:
> 
> Hi John,
> 
> I think I've mentioned this before, but I'll repeat myself. I think
> switching capability may have be useful in identifying what is allowable
> for routing purposes and for discovery purposes.
> 
> But once those are identified, signaling does not need to get involved.
> You responded to Ben that the switching capability field is end-to-end
> and does not change in intermediate nodes. Is this right?
> 
> Zhi
> 
> John Drake wrote:
> 
> > Ben,
> >
> > I think part of the problem is that you also need to read the GMPLS routing
> > drafts:
> >
> > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> >
> > There are also comments in your text.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:[email-masked]]
> > Sent: Monday, October 29, 2001 9:53 AM
> > To: Kireeti Kompella
> > Cc: [email-masked]
> > Subject: Re: Moving right along ... Switching Type
> >
> >
> >
> > In reviewing the GMPLS signaling drafts I have been unable to
> > get a clear understanding of the need for and use of the Switching
> > Type field in the Generalized Label Request object.
> >
> >
> > JD:  The Switching Type field is for handling the situation where there
> > are multiple switching capabilities per interface (see section 6.4.6 of
> > draft-ietf-ccamp-gmpls-routing-00.txt)
> >
> >
> > This appears to be an attempt to address LSP setup involving multiple
> > layer networks, but it does not adequately address the issues involved.
> >
> >
> > JD:  Would you please provide some additional prose explaining your
> > reasoning on this?
> >
> >
> > That it "Indicates the type of switching that should be performed on a
> > particular link." makes it seem to be a local concern, while others
> > have indicated it is an end-to-end field. For example, George Swallow
> > says "It is my understanding that for a given LSP it does not change,
> > but is carried end-to-end and applies at all intermediate hops along
> > the path."
> >
> >
> > JD:  I think George's interpretation is correct, and I don't think the
> > other text you quoted contradicts George.  If a given TE link supports
> > multiple switching types, the node controlling that link needs to know
> > what switching type a given LSP wants to use.
> >
> >
> > As an end-to-end item I have trouble understanding how the originating node
> > would determine how to set this (on what basis one determines what switching
> > choice to make in all cases).  In fact, I'm not sure why the originating
> > node would care what type of switching is used as long as the LSP is
> > delivered
> > to the egress faithfully.
> >
> >
> > JD:  The orgin node uses the switching capability information in the link
> > state
> > database in its CSPF calculation to ensure that switching capability is
> > consistent
> > along the path of the LSP.
> >
> >
> > Regards,
> > Ben Mack-Crane
> >
> >
--------------F68961D3043E70788A326320
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------F68961D3043E70788A326320--

Delivery-date: Wed, 31 Oct 2001 08:31:09 -0800
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>
Cc: 'Ben Mack-Crane' <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Wed, 31 Oct 2001 08:27:55 -0800

Comments in line

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 6:51 AM
To: John Drake
Cc: 'Ben Mack-Crane'; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John,

I think I've mentioned this before, but I'll repeat myself. I think 
switching capability may have be useful in identifying what is allowable 
for routing purposes and for discovery purposes.

But once those are identified, signaling does not need to get involved.

JD:  This sounds like an assertion.  It would be helpful to see a detailed
proposal that describes how an intermediate node controlling a link with
multiple switching capabilities can determine what switching capability
a given LSP wishes to use.
 
You responded to Ben that the switching capability field is end-to-end 
and does not change in intermediate nodes. Is this right?

JD:  As far as I know.

Zhi

John Drake wrote:

> Ben,
>  
> I think part of the problem is that you also need to read the GMPLS
routing
> drafts:
>  
>
http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
>  
> There are also comments in your text.
>  
> Thanks,
>  
> John
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 9:53 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ... Switching Type
> 
> 
> 
> In reviewing the GMPLS signaling drafts I have been unable to
> get a clear understanding of the need for and use of the Switching
> Type field in the Generalized Label Request object.
> 
> 
> JD:  The Switching Type field is for handling the situation where there
> are multiple switching capabilities per interface (see section 6.4.6 of
> draft-ietf-ccamp-gmpls-routing-00.txt)
> 
> 
> This appears to be an attempt to address LSP setup involving multiple
> layer networks, but it does not adequately address the issues involved.
> 
> 
> JD:  Would you please provide some additional prose explaining your
> reasoning on this?
> 
> 
> That it "Indicates the type of switching that should be performed on a
> particular link." makes it seem to be a local concern, while others
> have indicated it is an end-to-end field. For example, George Swallow
> says "It is my understanding that for a given LSP it does not change, 
> but is carried end-to-end and applies at all intermediate hops along 
> the path."
> 
> 
> JD:  I think George's interpretation is correct, and I don't think the
> other text you quoted contradicts George.  If a given TE link supports
> multiple switching types, the node controlling that link needs to know
> what switching type a given LSP wants to use.  
> 
> 
> As an end-to-end item I have trouble understanding how the originating
node
> would determine how to set this (on what basis one determines what
switching
> choice to make in all cases).  In fact, I'm not sure why the originating
> node would care what type of switching is used as long as the LSP is
> delivered
> to the egress faithfully.
> 
> 
> JD:  The orgin node uses the switching capability information in the link
> state
> database in its CSPF calculation to ensure that switching capability is
> consistent
> along the path of the LSP.  
> 
> 
> Regards,
> Ben Mack-Crane
> 
> 

Delivery-date: Wed, 31 Oct 2001 07:02:10 -0800
Date: Wed, 31 Oct 2001 09:51:15 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

Hi John,

I think I've mentioned this before, but I'll repeat myself. I think 
switching capability may have be useful in identifying what is allowable 
for routing purposes and for discovery purposes.

But once those are identified, signaling does not need to get involved. 
You responded to Ben that the switching capability field is end-to-end 
and does not change in intermediate nodes. Is this right?

Zhi

John Drake wrote:

> Ben,
>  
> I think part of the problem is that you also need to read the GMPLS routing
> drafts:
>  
> http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
>  
> There are also comments in your text.
>  
> Thanks,
>  
> John
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 9:53 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ... Switching Type
> 
> 
> 
> In reviewing the GMPLS signaling drafts I have been unable to
> get a clear understanding of the need for and use of the Switching
> Type field in the Generalized Label Request object.
> 
> 
> JD:  The Switching Type field is for handling the situation where there
> are multiple switching capabilities per interface (see section 6.4.6 of
> draft-ietf-ccamp-gmpls-routing-00.txt)
> 
> 
> This appears to be an attempt to address LSP setup involving multiple
> layer networks, but it does not adequately address the issues involved.
> 
> 
> JD:  Would you please provide some additional prose explaining your
> reasoning on this?
> 
> 
> That it "Indicates the type of switching that should be performed on a
> particular link." makes it seem to be a local concern, while others
> have indicated it is an end-to-end field. For example, George Swallow
> says "It is my understanding that for a given LSP it does not change, 
> but is carried end-to-end and applies at all intermediate hops along 
> the path."
> 
> 
> JD:  I think George's interpretation is correct, and I don't think the
> other text you quoted contradicts George.  If a given TE link supports
> multiple switching types, the node controlling that link needs to know
> what switching type a given LSP wants to use.  
> 
> 
> As an end-to-end item I have trouble understanding how the originating node
> would determine how to set this (on what basis one determines what switching
> choice to make in all cases).  In fact, I'm not sure why the originating
> node would care what type of switching is used as long as the LSP is
> delivered
> to the egress faithfully.
> 
> 
> JD:  The orgin node uses the switching capability information in the link
> state
> database in its CSPF calculation to ensure that switching capability is
> consistent
> along the path of the LSP.  
> 
> 
> Regards,
> Ben Mack-Crane
> 
> 

Delivery-date: Tue, 30 Oct 2001 19:28:00 -0800
To: [email-masked]
cc: [email-masked]
Subject: Re: CCAMP WG action items 
Date: Tue, 30 Oct 2001 19:26:01 -0800
From: Yakov Rekhter <[email-masked]>

Eric,

> Yakov> I'd like to understand the *practical* benefits that GTTP would bring
> Yakov> to the  operators *above and beyond*  of what is  already provided by
> Yakov> draft-bonica-icmp-mpls-03.txt  (or   could  be  trivially   added  to
> Yakov> draft-bonica-icmp-mpls-03.txt).  
> 
> I  think  GTTP  adds  the  following  functions  that  are  not  present  in
> draft-bonica-icmp-mpls: 
> 
> - the ability to discover and  trace through nested tunnels, even if the TTL
>   is not percolated through the stack;
> 
> - the ability to trace through a  nested tunnel even if interior LSRs of the
>   tunnel have no route to the management station. 
> 
> Do you think these functions offer practical benefits? 

While I may have an opinion on whether these functions offer any
practical benefits, from my point of view it would be more important
to get the opinion of the folks who actually use this in the
operational environment.

With this in mind, I'd like to hear comments from the folks *who
have operational experience* with MPLS on whether the functions
you mentioned above offer practical benefits.

Yakov.

Delivery-date: Tue, 30 Oct 2001 17:06:05 -0800
From: John Drake <[email-masked]>
To: 'Ben Mack-Crane' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Tue, 30 Oct 2001 17:03:00 -0800

Ben,
 
I think part of the problem is that you also need to read the GMPLS routing
drafts:
 
http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
 
There are also comments in your text.
 
Thanks,
 
John

-----Original Message-----
From: Ben Mack-Crane [mailto:[email-masked]]
Sent: Monday, October 29, 2001 9:53 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: Moving right along ... Switching Type

In reviewing the GMPLS signaling drafts I have been unable to
get a clear understanding of the need for and use of the Switching
Type field in the Generalized Label Request object.

JD:  The Switching Type field is for handling the situation where there
are multiple switching capabilities per interface (see section 6.4.6 of
draft-ietf-ccamp-gmpls-routing-00.txt)

This appears to be an attempt to address LSP setup involving multiple
layer networks, but it does not adequately address the issues involved.

JD:  Would you please provide some additional prose explaining your
reasoning on this?

That it "Indicates the type of switching that should be performed on a
particular link." makes it seem to be a local concern, while others
have indicated it is an end-to-end field. For example, George Swallow
says "It is my understanding that for a given LSP it does not change, 
but is carried end-to-end and applies at all intermediate hops along 
the path."

JD:  I think George's interpretation is correct, and I don't think the
other text you quoted contradicts George.  If a given TE link supports
multiple switching types, the node controlling that link needs to know
what switching type a given LSP wants to use.  

As an end-to-end item I have trouble understanding how the originating node
would determine how to set this (on what basis one determines what switching
choice to make in all cases).  In fact, I'm not sure why the originating
node would care what type of switching is used as long as the LSP is
delivered
to the egress faithfully.

JD:  The orgin node uses the switching capability information in the link
state
database in its CSPF calculation to ensure that switching capability is
consistent
along the path of the LSP.  

Regards,
Ben Mack-Crane

Delivery-date: Tue, 30 Oct 2001 13:16:27 -0800
From: "David Allan" <[email-masked]>
To: [email-masked], Yakov Rekhter <[email-masked]>
Cc: Shahram Davari <[email-masked]>, [email-masked]
Subject: RE: CCAMP WG action items
Date: Tue, 30 Oct 2001 16:12:28 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C16187.946AC8F0
Content-Type: text/plain;
	charset="iso-8859-1"

Eric:

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

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

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

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

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

Dave

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: CCAMP WG action items</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Eric:</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I&nbsp; think&nbsp; GTTP&nbsp; adds&nbsp; =
the&nbsp; following&nbsp; functions&nbsp; that&nbsp; are&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; not&nbsp; present&nbsp; in</FONT>
<BR><FONT SIZE=3D2>&gt; draft-bonica-icmp-mpls: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - the ability to discover and&nbsp; trace =
through nested tunnels, </FONT>
<BR><FONT SIZE=3D2>&gt; even if the TTL</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; is not percolated through the =
stack;</FONT>
</P>

<P><FONT SIZE=3D2>Seems to me that GTTP is &quot;dependent&quot; on TTL =
not percolating through the stack (a.k.a. the &quot;Pipe&quot; =
model).</FONT>
</P>

<P><FONT SIZE=3D2>In the &quot;Uniform&quot; model GTTP requests will =
terminate due to TTL exhaust arbitrarily in the network, and in any =
sort of VPN scenario (disjoint addressing) the LSR where the exhaust =
occured may not have a clue about the trace originator.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - the ability to trace through a&nbsp; nested =
tunnel even if </FONT>
<BR><FONT SIZE=3D2>&gt; interior LSRs of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; tunnel have no route to the =
management station. </FONT>
</P>

<P><FONT SIZE=3D2>By interior LSRs I presume you mean the lower level =
tunnels. LSRs MUST have a route to the trace originator for GTTP to =
provide useful information about the level under test.</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C16187.946AC8F0--

Delivery-date: Tue, 30 Oct 2001 11:08:32 -0800
To: Yakov Rekhter <[email-masked]>
cc: Shahram Davari <[email-masked]>, [email-masked]
Subject: Re: CCAMP WG action items 
Reply-To: [email-masked]
Date: Tue, 30 Oct 2001 14:05:26 -0500
From: Eric Rosen <[email-masked]>

Yakov> I'd like to understand the *practical* benefits that GTTP would bring
Yakov> to the  operators *above and beyond*  of what is  already provided by
Yakov> draft-bonica-icmp-mpls-03.txt  (or   could  be  trivially   added  to
Yakov> draft-bonica-icmp-mpls-03.txt).  

I  think  GTTP  adds  the  following  functions  that  are  not  present  in
draft-bonica-icmp-mpls: 

- the ability to discover and  trace through nested tunnels, even if the TTL
  is not percolated through the stack;

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

Do you think these functions offer practical benefits? 

Delivery-date: Tue, 30 Oct 2001 11:02:35 -0800
From: "David Allan" <[email-masked]>
To: [email-masked], Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: CCAMP WG action items
Date: Tue, 30 Oct 2001 13:56:10 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C16174.8A3A9440
Content-Type: text/plain;
	charset="iso-8859-1"

Comment at end..... 

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 12:11 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: Re: CCAMP WG action items
> 
>

<snip>

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

Eric:

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

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

Dave

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: CCAMP WG action items</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Comment at end..... </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eric Rosen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, October 30, 2001 12:11 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: CCAMP WG action items</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

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

<P><FONT SIZE=3D2>Eric:</FONT>
</P>

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

<P><FONT SIZE=3D2>So with a lot of provisos this thing can work, but =
IMHO it is stretching the fabric of the original design of ICMP and TTL =
handling a bit far....</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C16174.8A3A9440--

Delivery-date: Tue, 30 Oct 2001 10:23:57 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: CCAMP WG action items 
Date: Tue, 30 Oct 2001 18:23:05 -0000

Eric Rosen wrote 30 October 2001 17:11

> Shahram> Some comments regarding Bonica's GTTP draft:
> 
> Shahram> 1) It  relies on  IP layer  being present  and  IP 
> management-plane
> Shahram>    protocol  (ICMPs) for  the trace-probes,  and  
> trace-response to
> Shahram>    trace LSPs (layer violation). 
> 
> It relies on IP?  Heavens.  Relying on IP is a layer violation?
NH=> One should not require a higher (or indeed lower layer) technology's
fault management tools to proxy for missing fault-management.  Sure you can
work-it for some cases, but it is a not a general solution; what about
X-over-MPLS where X is not IP?  Further, creating inter-layer dependancies
is not good for protocol evolution (add/change/delete).  Since MPLS does
create new layer networks, and these will have failure modes that are not
relevant to any other layer network, then for its own long-term benefit it
should be given proper fault-management treatment.
> 
> Shahram> 2) It  is complicated. It requires many back  and 
> forth messages up
> Shahram>    and down  the protocol stack  (layer violation) 
> and up  and down
> Shahram>    the path to figure out the trace. 
> 
> Messages  up   and  down  the  path   is  the  tried   and  
> true  traceroute
> paradigm. Don't now what "up and down the protocol stack" means.
NH=> I believe Shahram means between the IP layer and the (potentially many)
MPLS layer networks.

regards, Neil
<snipped to end> 

Delivery-date: Tue, 30 Oct 2001 10:20:00 -0800
To: Shahram Davari <[email-masked]>
cc: [email-masked]
Subject: Re: CCAMP WG action items 
Date: Tue, 30 Oct 2001 10:18:48 -0800
From: Yakov Rekhter <[email-masked]>

Shahram,

> Some comments regarding Bonica's GTTP draft:
> 
> 1) It relies on IP layer being present and IP management-plane protocol
> (ICMPs) for the trace-probes, and trace-response to trace LSPs (layer
> violation).

layer violation doesn't strike me as a pragmatic consideration...

> 2) It is complicated. It requires many back and forth messages up and down 
> the protocol stack (layer violation) and up and down the path to figure 
> out the trace.

I would agree with you that it is certainly more complex than
draft-bonica-icmp-mpls-03.txt.

Moreover, while draft-bonica-icmp-mpls-03.txt has been implemented
by several vendors, the implementations have been shown to be
interoperable, and it is being used in the operational environment
for quite some time, the same can't be said for the GTTP draft.

So, with this in mind I'd like to understand the *practical* benefits
that GTTP would bring to the operators *above and beyond* of what
is already provided by draft-bonica-icmp-mpls-03.txt (or could be
trivially added to draft-bonica-icmp-mpls-03.txt).

Yakov.

Delivery-date: Tue, 30 Oct 2001 09:13:31 -0800
To: Shahram Davari <[email-masked]>
cc: [email-masked]
Subject: Re: CCAMP WG action items 
Reply-To: [email-masked]
Date: Tue, 30 Oct 2001 12:11:27 -0500
From: Eric Rosen <[email-masked]>

Shahram> Some comments regarding Bonica's GTTP draft:

Shahram> 1) It  relies on  IP layer  being present  and  IP management-plane
Shahram>    protocol  (ICMPs) for  the trace-probes,  and  trace-response to
Shahram>    trace LSPs (layer violation). 

It relies on IP?  Heavens.  Relying on IP is a layer violation?

Shahram> 2) It  is complicated. It requires many back  and forth messages up
Shahram>    and down  the protocol stack  (layer violation) and up  and down
Shahram>    the path to figure out the trace. 

Messages  up   and  down  the  path   is  the  tried   and  true  traceroute
paradigm. Don't now what "up and down the protocol stack" means.

Shahram> 3) In hierarchical LSP  case, not only the ingress  node of the LSP
Shahram>    under test must  run the GTTP, but all ingress  LSRs that are in
Shahram>    the middle  of the  LSP under test  and act as  tunneling points
Shahram>    MUST run GTTP => forklift upgrade required

I dare  say that  most nodes  have downloadable software,  and hence  can be
upgraded without the need to replace equipment.

The point that all the ingress LSRs must support the procedure is valid.

Shahram>  4) It   assumes   reachability  of   all   tunnel  ingresses   and
Shahram>     intermediate nodes by the  tracing entity. So, for example, all
Shahram>     intermediate nodes processing GTTP  have IP connectivity to the
Shahram>     tracing entity. 

Not exactly.  If there is no IP connectivity to a particular tunnel ingress,
you just can't trace through that tunnel.  Many providers do not want others
tracing through their tunnels.  One could still show that things are okay up
until the particular tunnel is reached.  

Shahram> 5) Does nothing to improve operational effectiveness for operators,
Shahram>    ie  no automatic fault  detection/handling....customer complaint
Shahram>    still has to roll-in. 

It is  true that this does  not provide automatic fault  detection.  I'm not
sure  that  that's  the  same   as  "does  nothing  to  improve  operational
effectiveness". 

Delivery-date: Tue, 30 Oct 2001 08:23:35 -0800
From: Shahram Davari <[email-masked]>
To: [email-masked]
Subject: RE: CCAMP WG action items
Date: Tue, 30 Oct 2001 08:23:32 -0800

Hi,

Some comments regarding Bonica's GTTP draft:

1) It relies on IP layer being present and IP management-plane protocol
(ICMPs) for the trace-probes, and trace-response to trace LSPs (layer
violation).
2) It is complicated. It requires many back and forth messages up and down the protocol stack (layer violation) and up and down the path to figure out the trace.
3) In hierarchical LSP case, not only the ingress node of the LSP under test
must run the GTTP, but all ingress LSRs that are in the middle of the LSP
under test and act as tunneling points MUST run GTTP => forklift upgrade required
4) It assumes reachability of all tunnel ingresses and intermediate nodes by the tracing entity. So, for example, all intermediate nodes processing GTTP have IP connectivity to the tracing entity. Therefore it requires homogeneous addressing at any tunnel level. Not necessarily a good thing for inter-carrier tunnels.
5) Does nothing to improve operational effectiveness for operators, ie
no automatic fault detection/handling....customer complaint still has to roll-in.

Yours,
-Shahram

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 12:15 PM
> To: [email-masked]
> Subject: CCAMP WG action items
> 
> 
> 1) Final round of WG comments on GMPLS signalling drafts by August 27.
>    These include:
>    draft-ietf-mpls-generalized-cr-ldp-04.txt
>    draft-ietf-mpls-generalized-rsvp-te-04.txt
>    draft-ietf-mpls-generalized-signaling-05.txt
>    draft-ietf-ccamp-gmpls-sonet-sdh-01.txt
>    
>    At that point, the authors (editors) incorporate the comments, and
>    the documents go to IETF Last Call.
> 
>    The pieces of draft-ietf-ccamp-gmpls-sonet-sdh-01.txt that get
>    taken out are to be put in another draft that will be a CCAMP WG
>    _informational_ document.  When Eric submits this draft, we'll have
>    a three week WG Last Call on it.
>  
> 2) G.709: move non-ITU-standard stuff into a separate document.
> 
> 3) Reissue routing docs as CCAMP WG docs:
>    draft-kompella-ospf-gmpls-extensions-02.txt
>    draft-many-ccamp-gmpls-routing-00.txt
> 
> 4) For each of the following, do you think:
>    a. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
>    b. draft-fontana-ccamp-gmpls-g709-00.txt
> 	(assuming that the non-ITU stuff is removed)
>    c. draft-many-ccamp-gmpls-framework-00.txt
>    d. draft-bonica-tunneltrace-01.txt
> 
>    should these be made CCAMP WG docs or not?
> 
>    Also, for (c), do you think that a GMPLS framework doc is useful?
> 
> 5) Tom and co-authors to send mail to the list stating the degree
>    of independence of LMP MIB to the MPLS TE MIB complex.
> 
> 6) Consensus: don't move forward with NTIP; move forward with LMP-WDM,
>    subject to due diligence that this work belongs in the IETF.
> 
> 7) Once new versions of the following drafts appear, we will have WG
>    Last Call on them:
> 	draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> 	draft-ietf-ccamp-lmp-00.txt
> 	draft-many-gmpls-architecture-01.txt
> 
> Kireeti.
> 

Delivery-date: Mon, 29 Oct 2001 15:09:24 -0800
Date: Mon, 29 Oct 2001 17:03:27 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... gmpls-sonet-sdh-02

A couple of comments on draft-ietf-ccamp-gmpls-sonet-sdh-02.txt

1) Under Signal Type there are four transforms described and it
   is suggested that these four may be applied in the specified
   order.  I don't think transparency makes much sense after specifying
   concatenation transforms.  This should be clarified.

2) In the transparency section it states "Section/Regenerator 
   Section layer transparency means that the entire frames must 
   be delivered unmodified" and "Line/Multiplex Section layer 
   transparency means that the LOH/MSOH must be delivered 
   unmodified."  This would seem to preclude the forms of TDM
   multiplexing supported by some equipment (e.g., 4xOC-48 into
   "OC-192").  I think we should add language that allows for 
   this.

Regards,
Ben Mack-Crane

Delivery-date: Mon, 29 Oct 2001 12:15:22 -0800
Date: Mon, 29 Oct 2001 14:08:56 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... generalized-rsvp-te-05

After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt
I have the following comments and questions:

1) In the procedures regarding the Generalized Label Request 
   object, the statement is made that "The node may either 
   directly support the LSP or it may use a tunnel (FA), 
   i.e., another class of switching."  A Tunnel (FA) is a type
   of link, not a class of switching.  This adds to the 
   confusion I've noted about the need for and use of Switching 
   Type.

2) Bandwidth Encoding use of the Intserv Tspec object seems
   quite unusual since this use is not consistent with existing
   uses of this object, and new uses could easily use a new
   C-Type.

3) In the procedures for Generalized Label it states "If the label is
   unacceptable then the recipient MUST generate a ResvErr message with
   a "Routing problem/MPLS label allocation failure" indication."
   I think "Unacceptable Label Value" would be more appropriate.

4) In the Waveband Switching section it says "For compatibility reasons, 
   a new RSVP C-Type (3) is assigned."  What is the compatability
   problem this is solving?

5) In the Label Set object, why is the Label Type field 14 bits if 
   only the low order 8 bits are used?

6) Some new error strings are defined, "Label Set" and "Unsupported Link 
   Protection," but no values or placeholders are included. Where are new 
   error values to be documented?  

7) The Notify message is intended to "enable expedited notification of 
   failures," but it relies on the IP layer which may be affected by the
   failure that the Notify is reporting.  This could defeat the goal
   of rapid notification.  Without some means of guaranteeing the Notify
   doesn't have to wait for IP routing convergence to be delivered, 
   it isn't a satisfactory solution.

8) The description of the C-Type field in the Label ERO subobject suggests
   that this subobject contains a Label Object.  Is this the case, or does
   the Label ERO subobject simple contain label values, and the C-Type
   matches the C-Type that would be used if the same label values were
   included in a Label object?

9) In deleting an LSP from the egress, the R bit is set in the Admin Status
   object.  The ingress responds with a PathTear message.  Does this PathTear
   contain the Admin Status object or should the R bit be cleared?

10)The Notify message may contain a new setting of the Admin Status.
   Under what conditions would an intermediate or egress node change
   Admin Status?  What happens if the Notify receiver is not the ingress?

11)In Interface Identification it says "Data channels are specified from the view point
   of the sender of the Path message."  Is this true even for Resv messages
   or should it read "Data channels are specified from the viewpoint
   of the sender of the message."?

12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be 
   suppressed during this waiting period."  I assume this is refreshes
   toward the failed neighbor, not to all neighbors for that LSP.  True?

Regards,
Ben Mack-Crane

Delivery-date: Mon, 29 Oct 2001 10:16:41 -0800
Date: Mon, 29 Oct 2001 12:09:56 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... generalized-signaling-06

After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have
a few comments and questions:

1) There seems to be no difference as far as label allocation
   is concerned between LSP Encoding Types Ethernet V2/DIX (2)
   and Ethernet 802.3 (10).  One Encoding type would seem to
   be sufficient.

2) G-PID types (19), (20), and (21) are repeats of (16), (17), 
   and (18).  Since the Siganl Type will indicate whether the
   LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant.

3) G-PID type (37) Lambda seems insufficient (too vague) to 
   support interoperability.  Is there any practical use for this 
   value?

4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
   is useful to define discrete values to identify the bandwidth of the
   LSP."  For SONET/SDH this is unnecessary given the Signal Type is
   provided.  For the other non-packet LSP types (Lambda and Fiber)
   it is not clear that all the values cited in the example are relevant
   (for example, a DS0 lambda would seem wasteful...).
   This is confusing, and should be clarified.  In fact, a description of
   exactly why this field is required is needed.

5) The Waveband ID "is selected by the sender and reused in all 
   subsequent related messages."  This seems more the sort of thing that
   should be negotiated by LMP rather than during connection setup.

6) The definition of Start Label and End Label in waveband switching seems
   inconsistent with the behavior described in generalized-rsvp-te-05.
   
7) In Protection Information it states "The resources allocated for a 
   secondary LSP MAY be used by other LSPs until the primary LSP fails 
   over to the secondary LSP."  This may not always be the case.  An
   explicit flag indicating whether or not extra traffic may use the
   secondary path resources is needed.

8) The Administrative Status Information includes a bit indicating
   "Administratively down," but there is no reference to a definition
   of this state.  Is this intended to mirror the MIB variable?  If so,
   a reference is needed.  If not, more definition is needed to ensure
   the local behaviors driven by this bit are in some way consistent.
   Whether this state defintion is consistent with current transport
   network operations should also be considered.

9) In Interface Identification, the IP Address for types 3,4, and 5 is
   described as possibly "an IP address associated with the router ID."
   Is this intended to mean the Router ID or any IP address owned by 
   the node?  It seems the Router ID is the simplest solution, but the
   wording is not clear.

10)In describing the Interface ID the statement "The special value
   0xFFFFFFFF can be used to indicate the same label is to be valid 
   across all component links."  What is the "label" referred to in
   this case?

Regards,
Ben Mack-Crane

Delivery-date: Mon, 29 Oct 2001 09:59:48 -0800
Date: Mon, 29 Oct 2001 11:52:35 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

In reviewing the GMPLS signaling drafts I have been unable to
get a clear understanding of the need for and use of the Switching
Type field in the Generalized Label Request object.

This appears to be an attempt to address LSP setup involving multiple
layer networks, but it does not adequately address the issues involved.

That it "Indicates the type of switching that should be performed on a
particular link." makes it seem to be a local concern, while others
have indicated it is an end-to-end field. For example, George Swallow
says "It is my understanding that for a given LSP it does not change, 
but is carried end-to-end and applies at all intermediate hops along 
the path."

As an end-to-end item I have trouble understanding how the originating node
would determine how to set this (on what basis one determines what switching
choice to make in all cases).  In fact, I'm not sure why the originating
node would care what type of switching is used as long as the LSP is delivered
to the egress faithfully.

Regards,
Ben Mack-Crane

Delivery-date: Mon, 29 Oct 2001 08:50:10 -0800
To: "Atkinson, Stephen" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Edward Harrison'" <[email-masked]>
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Mon, 29 Oct 2001 08:41:56 -0800
From: Yakov Rekhter <[email-masked]>

Steve,

> Hi Ed,
> 
> I agree, comments below.
> 
> Regards,
> steve atkinson
> 
> > -----Original Message-----
> > From: Edward Harrison [mailto:[email-masked]]
> > Sent: Thursday, September 13, 2001 11:06 AM
> > To: 'Yakov Rekhter'
> > Cc: Nic Larkin; [email-masked]'
> > Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
> > 
> > 
> > Yakov,
> > 
> > > > Can you clarify whether you are proposing removing the
> > COMPONENT_IF_UPSTREAM
> > > > TLV from the INTERFACE_ID hop object (or were you just 
> > saying that Steve
> > > > needn't use it if he doesn't want to)?
> > > 
> > > I am proposing to remove the COMPONENT_IF_UPSTREAM.
> > 
> > In this case, am I right in thinking it makes sense to remove
> > COMPONENT_IF_DOWNSTREAM too, and signal the (single) 
> > component interface
> > identifier, in the IPv4, IPv6 or IF_INDEX TLV?
> 
> This is how I felt it should work. I don't see any additional
> value in COMPONENT_IF_DOWNSTREAM that can't be handled by
> the IF_INDEX TLV. Both carry the same information, the
> unnumbered interface identifier.

I completely agree with the suggestion to remove both
COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM, and use IF_INDEX
TLV instead (for both bunlded and/or unnumbered links).

Yakov.

Delivery-date: Fri, 26 Oct 2001 00:44:56 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Moving right along ...
Date: Fri, 26 Oct 2001 08:36:28 +0100

John Drake said 25 October 2001 19:01
 
> For example, I could very easily argue that a NSAP + 
> Q.2931/PNNI (signalling
> aspects only) + centralised routing approach looks the best 
> commercially for
> what we want to do.  
> 
> JD:  Neil, as I have told you repeatedly in the past, GMPLS 
> fully supports
> this mode of deployment.

NH=> Thanks for clarifying that Q.2931-based/PNNI signalling is supported.

Delivery-date: Thu, 25 Oct 2001 17:10:48 -0700
Date: Thu, 25 Oct 2001 20:11:02 -0400
To: "[email-masked]" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Cc: "'Cheenu Srinivasan'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>

--=====================_126716048==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>I agree with you, that the reference need not be placed
>at all places.. But for the convenience of the readers, we
>can have some consistency in the doc.
>
>Currently the reference appears at some places and
>not at others.. My suggestion is, can this be made
>consistent.. ie.
>1) place at the first instance and leave it other places

         Sure, this sounds reasonable to me.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_126716048==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<blockquote type=cite cite><font size=3>I agree with you, that the
reference need not be placed<br>
at all places.. But for the convenience of the readers, we<br>
can have some consistency in the doc.<br>
<br>
Currently the reference appears at some places and <br>
not at others.. My suggestion is, can this be made<br>
consistent.. ie.<br>
1) place at the first instance and leave it other
places</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Sure, this
sounds reasonable to me.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_126716048==_.ALT--

Delivery-date: Thu, 25 Oct 2001 17:04:48 -0700
From: "S.Manikantan" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Thomas Nadeau'" <[email-masked]>
Cc: "'Cheenu Srinivasan'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 17:07:38 -0700
Organization: Future Communications Software

Hello Tom

I agree with you, that the reference need not be placed
at all places.. But for the convenience of the readers, we
can have some consistency in the doc.

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

Forgive me if my suggestion is stupid or If I am felt
bugging :)

with best regards
mani

-----Original Message-----
From:	Thomas Nadeau [SMTP:[email-masked]]
Sent:	Thursday, October 25, 2001 4:49 PM
To:	[email-masked]
Cc:	'Cheenu Srinivasan'; [email-masked]'; [email-masked]'
Subject:	RE: draft-ietf-mpls-mgmt-overview-00.txt posted

At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:
>Hello Cheenu
>
>Yes. LSR MIB is provided as second item in section 8.
>
>My comment was w.r.t the cross reference. I meant
>
> >    The MPLS-LSR-MIB describes managed objects for modeling a
>
>Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for 
>modeling a"
>
>reason this was the first time it is mentioned in this section. the cross 
>references
>were used for the other MIBs in the other sections..
>
>Hope I have it clear now :)
>
>I have two more comments.
>
>Comment 8 :
>
>In the document I noticed in some places " XXX-YY-MIB [AAMIB]"
>and in some places say "XXX-YY-MIB" .
>
>for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places
>and "MPLS-LSR-MIB" at some places. Any specific reason?? or
>they will be made consistent?

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

         --Tom

>Comment 9:
>The [LDPMIB] reference needs to be added in section 8 references. Currently
>I think it is missed out.
>
>with best regards
>mani
>
>
>
>-----Original Message-----
>From:   Cheenu Srinivasan [SMTP:[email-masked]]
>Sent:   Thursday, October 25, 2001 11:58 AM
>To:     [email-masked]'
>Cc:     [email-masked]'; [email-masked]'
>Subject:        RE: draft-ietf-mpls-mgmt-overview-00.txt posted
>
> > Please find below my comments on the draft.
>
>That was really quick! The corrections you pointed out will
>show up in the next revision. One comment.
>
> > Comment 3:
> > "4.2.  MPLS-LSR-MIB
> >
> >    The MPLS-LSR-MIB describes managed objects for modeling a
> >                ^^^^^^^^
> >    ..."
> >
> > Mani>> The reference to LSRMIB needs to be added??
>
>Its already there (the 2nd reference).
>
>Cheenu

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.  << File: ATT00014.htm >> 

Delivery-date: Thu, 25 Oct 2001 16:50:13 -0700
Date: Thu, 25 Oct 2001 19:49:29 -0400
To: "[email-masked]" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Cc: "'Cheenu Srinivasan'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>

--=====================_125422267==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:
>Hello Cheenu
>
>Yes. LSR MIB is provided as second item in section 8.
>
>My comment was w.r.t the cross reference. I meant
>
> >    The MPLS-LSR-MIB describes managed objects for modeling a
>
>Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for 
>modeling a"
>
>reason this was the first time it is mentioned in this section. the cross 
>references
>were used for the other MIBs in the other sections..
>
>Hope I have it clear now :)
>
>I have two more comments.
>
>Comment 8 :
>
>In the document I noticed in some places " XXX-YY-MIB [AAMIB]"
>and in some places say "XXX-YY-MIB" .
>
>for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places
>and "MPLS-LSR-MIB" at some places. Any specific reason?? or
>they will be made consistent?

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

         --Tom

>Comment 9:
>The [LDPMIB] reference needs to be added in section 8 references. Currently
>I think it is missed out.
>
>with best regards
>mani
>
>
>
>-----Original Message-----
>From:   Cheenu Srinivasan [SMTP:[email-masked]]
>Sent:   Thursday, October 25, 2001 11:58 AM
>To:     [email-masked]'
>Cc:     [email-masked]'; [email-masked]'
>Subject:        RE: draft-ietf-mpls-mgmt-overview-00.txt posted
>
> > Please find below my comments on the draft.
>
>That was really quick! The corrections you pointed out will
>show up in the next revision. One comment.
>
> > Comment 3:
> > "4.2.  MPLS-LSR-MIB
> >
> >    The MPLS-LSR-MIB describes managed objects for modeling a
> >                ^^^^^^^^
> >    ..."
> >
> > Mani>> The reference to LSRMIB needs to be added??
>
>Its already there (the 2nd reference).
>
>Cheenu

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_125422267==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:<br>
<blockquote type=cite cite>Hello Cheenu<br>
<br>
Yes. LSR MIB is provided as second item in section 8.<br>
<br>
My comment was w.r.t the cross reference. I meant <br>
<br>
&gt;&nbsp;&nbsp;&nbsp; The MPLS-LSR-MIB describes managed objects for
modeling a<br>
<br>
Should it be &quot;The MPLS-LSR-MIB [LSRMIB] describes managed objects
for modeling a&quot;<br>
<br>
reason this was the first time it is mentioned in this section. the cross
references<br>
were used for the other MIBs in the other sections..<br>
<br>
Hope I have it clear now :)<br>
<br>
I have two more comments.<br>
<br>
Comment 8 :<br>
<br>
In the document I noticed in some places &quot; XXX-YY-MIB [AAMIB]&quot;
<br>
and in some places say &quot;XXX-YY-MIB&quot; .<br>
<br>
for example &quot;MPLS-LSR-MIB [LSRMIB]&quot; mentioned at some places
<br>
and &quot;MPLS-LSR-MIB&quot; at some places. Any specific reason?? or
<br>
they will be made consistent?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Lets not
get carried away here. I think that if we reference one <br>
of the MIBs once, that is sufficient for someone to track down<br>
the reference. No need to put a reference every place the<br>
term is used.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Comment 9:<br>
The [LDPMIB] reference needs to be added in section 8 references.
Currently<br>
I think it is missed out.<br>
<br>
with best regards<br>
mani<br>
<br>
<br>
<br>
-----Original Message-----<br>
From:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Cheenu Srinivasan
[SMTP:[email-masked]]<br>
Sent:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Thursday, October 25, 2001 11:58
AM<br>
To:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[email-masked]'<br>
Cc:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[email-masked]';
[email-masked]'<br>
Subject:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>RE:
draft-ietf-mpls-mgmt-overview-00.txt posted<br>
<br>
&gt; Please find below my comments on the draft.<br>
<br>
That was really quick! The corrections you pointed out will<br>
show up in the next revision. One comment.<br>
<br>
&gt; Comment 3:<br>
&gt; &quot;4.2.&nbsp; MPLS-LSR-MIB<br>
&gt;&nbsp;&nbsp;&nbsp; <br>
&gt;&nbsp;&nbsp;&nbsp; The MPLS-LSR-MIB describes managed objects for
modeling a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^<br>
&gt;&nbsp;&nbsp;&nbsp; ...&quot;<br>
&gt; <br>
&gt; Mani&gt;&gt; The reference to LSRMIB needs to be added?? <br>
<br>
Its already there (the 2nd reference).<br>
<br>
Cheenu </font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_125422267==_.ALT--

Delivery-date: Thu, 25 Oct 2001 13:31:04 -0700
Date: Wed, 24 Oct 2001 13:30:26 -0400 (EDT)
From: Jim Boyle <[email-masked]>
To: <[email-masked]>
Subject: Last Call on Hierarchy and Restoration Requirements

FYI, this was sent to [email-masked] yesterday.

> The message starts a last call on the document:
>
>         draft-ietf-tewg-restore-hierarchy-00.txt
>
> which outlines requirements for hierarchy and restoration in networks
> utilizing CCAMP technologies such as MPLS.  This document will
> progress as an informational RFC.  The last call ends November 9,
> 2001.  Please comment to [email-masked]
>
> thanks,
>
> Ed & Jim

Delivery-date: Thu, 25 Oct 2001 11:48:12 -0700
content-class: urn:content-classes:message
Subject: RE: Comments on LMP MIB
Date:  Thu, 25 Oct 2001 14:39:48 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Baktha Muralidharan" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Thomas Nadeau" <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C15D84.6CF27390
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Baktha,
=20
Thanks a lot for the feedback. See response below.
=20
Martin

-----Original Message-----
From: Baktha Muralidharan [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 12:05 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Thomas Nadeau;
[email-masked]
Subject: Comments on LMP MIB

Hello,
          My feedback comments are prefixed "BM>"

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

7.5.  lmpLinkVerificationTable

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

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

----------

7.7.  lmpDataBearingLinkPerfTable

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

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

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

8.  Example of LMP Control Channel Setup

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

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

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

BM> Do we mean administrative state?

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

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

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

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

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

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

lmpCcHelloIntervalDefaultMin

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

lmpCcHelloIntervalDefaultMax

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

lmpCcHelloDeadIntervalDefaultMin

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

lmpCcHelloDeadIntervalDefaultMax

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

lmpCcHelloDeadIntervalDefault OBJECT-TYPE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BM> From an LMP perspective, the "member data links" of a TE Links need
BM> to be known.. I realize that this information is available from the
BM> bundling MIB.. It may be handy to add an object to the data bearing
BM> link table to store the TE Link ?
[Martin Dubuc] The info is actually not in the link bundling MIB, but in
the ifStackTable.=20
------------------
BM> Along the lines of TE Link and CC up/down traps, perhaps we should
have
BM> a trap to notify user when a data bearing link is transitioned to
"down"
BM> state due to link verification failure. Note that this information
is not
BM> obtainable from link up/down trap of underlying interface
[Martin Dubuc] I will consider this in the next version.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

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

<!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.50.4522.1801" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D295590318-25102001>Baktha,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D295590318-25102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D295590318-25102001>Thanks=20
a lot for the feedback. See response below.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D295590318-25102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D295590318-25102001>Martin</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Baktha =
Muralidharan=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, October 25, 2001 =
12:05=20
  PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> [email-masked];=20
  [email-masked]; Thomas Nadeau; =
[email-masked]<BR><B>Subject:</B>=20
  Comments on LMP MIB<BR><BR></FONT></DIV>
  <DIV><FONT=20
  face=3D"Courier New, =
Courier">Hello,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
  My feedback comments are prefixed=20
  =
"BM&gt;"<BR><BR>/Baktha<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=3D=3D=3D=3D=3D=3D=3D<BR><BR>7.5.&nbsp;=20
  lmpLinkVerificationTable<BR><BR>&nbsp;&nbsp; This table represents the =
link=20
  verification parameters associated<BR>&nbsp;&nbsp; with the TE=20
  links.<BR><BR>BM&gt; Add "Augments lmpTeLinkTable"<BR><SPAN=20
  class=3D295590318-25102001><FONT face=3DArial color=3D#0000ff =
size=3D2>[Martin=20
  =
Dubuc]&nbsp;OK.&nbsp;</FONT></SPAN><BR><BR>----------<BR><BR>7.7.&nbsp;=20
  lmpDataBearingLinkPerfTable<BR><BR>&nbsp;&nbsp; This table contains =
the=20
  objects to measure the LMP performance of<BR>&nbsp;&nbsp; data-bearing =
links=20
  and is an AUGMENT to the lmpDataBearingLinkTable.<BR><BR>BM&gt; Add =
"Augments=20
  lmpDataBearingLinkTable"<BR><SPAN class=3D295590318-25102001><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>[Martin=20
  =
Dubuc]&nbsp;OK.&nbsp;</FONT></SPAN><BR><BR>------------<BR><BR>8.&nbsp;=20
  Example of LMP Control Channel Setup<BR><BR>&nbsp;&nbsp; In this =
section we=20
  provide a brief example of using the MIB<BR>&nbsp;&nbsp; objects =
described in=20
  section 11 to set up an LMP control channel.<BR>&nbsp;&nbsp; While =
this=20
  example is not meant to illustrate every nuance of the<BR>&nbsp;&nbsp; =
MIB, it=20
  is intended as an aid to understanding some of the key<BR>&nbsp;&nbsp; =

  concepts. It is meant to be read after going through the MIB=20
  itself.<BR><BR><BR>BM&gt; Should read "objects desribed in section=20
  10"<BR><SPAN class=3D295590318-25102001><FONT face=3DArial =
size=3D2><FONT=20
  color=3D#0000ff>[Martin=20
  =
Dubuc]&nbsp;OK.</FONT>&nbsp;</FONT></SPAN><BR>----------------<BR><BR>lmp=
AdminStatus=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  INTEGER { up(1), down(2) }<BR>&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-write<BR>&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp; =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "The desired operational status of LMP on the node."<BR>&nbsp;&nbsp;=20
  DEFVAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { up =
}<BR>&nbsp;&nbsp; ::=3D {=20
  lmpObjects 1 }<BR><BR>BM&gt; Do we mean administrative =
state?<BR><BR><SPAN=20
  class=3D295590318-25102001><FONT face=3DArial color=3D#0000ff =
size=3D2>[Martin=20
  Dubuc]&nbsp;No, the administraive state specifies the desired =
operational=20
  state. For instance, if an operator sets the administrative state of a =
control=20
  channel to&nbsp;up, it&nbsp;gives the system an indication =
that&nbsp;it would=20
  like the operational state to become up (desired operational state). =
Now it is=20
  possible that the system cannot bring the control channel up (for =
instance, if=20
  the fiber is cut). But as soon as it can, it will bring the control =
channel=20
  up.</FONT></SPAN></FONT></DIV><FONT face=3D"Courier New, =
Courier"><SPAN=20
  class=3D295590318-25102001></SPAN>
  <DIV><BR>----------------------<BR><BR>lmpNbrTable =
OBJECT-TYPE<BR>&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE OF=20
  LmpNbrEntry<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  not-accessible<BR>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "This table =
specifies the=20
  neighbor node to which control=20
  channels<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be=20
  established."<BR>&nbsp;&nbsp; ::=3D { lmpObjects 2 }<BR><BR>BM&gt; =
neighbor=20
  node(s)<BR><FONT size=3D2><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
  class=3D295590318-25102001>[Martin=20
  =
Dubuc]&nbsp;OK.&nbsp;</SPAN><BR></FONT></FONT></FONT>--------------------=
--------<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
lmpNbrRetransmitInterval&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
  =3D 10<BR><BR>Wouldn't want this to be the same for link verification, =
summary=20
  etc.<BR><FONT size=3D2><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  class=3D295590318-25102001>[Martin Dubuc]&nbsp;The message =
retransmission=20
  procedure in the latest draft seems to be a generic procedure that is =
not=20
  specific to the message types (as opposed to earlier versions of the =
drafts).=20
  This is why I have collapsed it into a single=20
  =
object.&nbsp;</SPAN><BR></FONT></FONT></FONT>----------------<BR>lmpNbrAd=
minStatus=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  INTEGER { up(1), down(2) }<BR>&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp; =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "The desired operational status of LMP to this remote =
node."<BR>&nbsp;&nbsp;=20
  ::=3D { lmpNbrEntry 3 }<BR><BR>BM&gt; Do we mean desired admin. =
state?<BR><SPAN=20
  class=3D295590318-25102001><FONT face=3DArial size=3D2><FONT =
color=3D#0000ff>[Martin=20
  Dubuc]&nbsp;Same as=20
  =
above.</FONT>&nbsp;</FONT></SPAN><BR>--------------------<BR><BR>lmpCcHel=
loIntervalDefaultMin<BR><BR>BM&gt;=20
  Presumably, this serves as the default value for=20
  lmpCcHelloIntervalMin?<BR><SPAN class=3D295590318-25102001><FONT =
face=3DArial=20
  size=3D2>[Martin Dubuc]&nbsp;Yes. I will be more specific in the=20
  =
MIB.&nbsp;</FONT></SPAN><BR><BR>lmpCcHelloIntervalDefaultMax<BR><BR>BM&gt=
;=20
  Presumably, this serves as the default value for=20
  lmpCcHelloIntervalMax?<BR><SPAN class=3D295590318-25102001><FONT =
face=3DArial=20
  size=3D2><FONT color=3D#0000ff>[Martin Dubuc]&nbsp;Same as=20
  =
above.</FONT>&nbsp;</FONT></SPAN><BR><BR>lmpCcHelloDeadIntervalDefaultMin=
<BR><BR>BM&gt;=20
  Presumably, this serves as the default value for =
lmpCcHelloDeadIntervalMin?=20
  <BR><SPAN class=3D295590318-25102001><FONT face=3DArial =
size=3D2>[Martin=20
  Dubuc]&nbsp;Same as=20
  =
above.&nbsp;</FONT></SPAN><BR><BR>lmpCcHelloDeadIntervalDefaultMax<BR><BR=
>BM&gt;=20
  Presumably, this serves as the default value for=20
  lmpCcHelloDeadIntervalMax?<BR><FONT size=3D2><FONT face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D295590318-25102001>[Martin =
Dubuc]&nbsp;Same as=20
  =
above.&nbsp;</SPAN><BR></FONT></FONT></FONT>------------------------<BR><=
BR>lmpCcHelloDeadIntervalDefault=20
  OBJECT-TYPE<BR><BR>&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LmpInterval<BR>&nbsp;&nbsp;=20
  MAX-ACCESS&nbsp;&nbsp;&nbsp; read-write<BR>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "This object =
specifies the=20
  default HelloDeadInterval parameter=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use in the Hello =
protocol=20
  keep-alive phase. It indicates how=20
  long<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a device should =
wait before=20
  declaring the control channel=20
  dead.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
HelloDeadInterval=20
  parameter must be greater than=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HelloInterval =
parameter and=20
  should be at least three times=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value of=20
  HelloInterval."<BR><BR>BM&gt; Remove the part "must be greated than =
the=20
  HelloInterval parameter and"<BR></FONT><SPAN =
class=3D295590318-25102001><FONT=20
  face=3DArial color=3D#0000ff size=3D2>[Martin =
Dubuc]&nbsp;OK.</FONT></SPAN><FONT=20
  face=3D"Courier New, Courier"><BR>-----------------<BR><BR>lmpCcIsIf=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  TruthValue<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp; =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "Denotes whether or not this control channel corresponds=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an interface =
represented in=20
  the interfaces group table."<BR>&nbsp;&nbsp; ::=3D { =
lmpControlChannelEntry 3=20
  }<BR><BR>BM&gt; Why this additional object?. Why not require that =
there be a=20
  valid<BR>BM&gt; lmpCcUnderlyingIfIndex for CC's rowstatsus to go into =
"active"=20
  state<BR>BM&gt; and that in the absence of a valid underlying =
interface, the=20
  CC<BR>BM&gt; will be in the "notReady" state?<BR>BM&gt;<BR>BM&gt; In =
the TE=20
  LInk case, we require that an entry of type "TE Link" exist<BR>BM&gt; =
BEFORE=20
  the corresponding teLinkEntry is created... Why not do the =
same<BR>BM&gt; with=20
  CC?. After all, the CC is not usable until a real underlying<BR>BM&gt; =

  interface is defined!</FONT><FONT=20
  face=3D"Courier New, Courier"><BR><BR></FONT><SPAN=20
  class=3D295590318-25102001><FONT face=3DArial color=3D#0000ff =
size=3D2>[Martin=20
  Dubuc]&nbsp;This allows pre-provisioning of control channels. I guess =
the same=20
  logic could apply to TE links as well. Not sure what to=20
do.</FONT></SPAN></DIV>
  <DIV><FONT face=3D"Courier New, Courier"><SPAN=20
  class=3D295590318-25102001>&nbsp;</SPAN><BR></FONT><FONT=20
  face=3D"Courier New, Courier">--------------<BR><BR>lmpCcNbrNodeId=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  NodeID<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; =
read-only<BR>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "This is the Node =
ID of=20
  the control channel remote =
node.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  This value gets created by the node when a Config=20
  message<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is received or =
when an=20
  outgoing Config message is=20
  acknowledged<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the =
remote=20
  node."<BR>&nbsp;&nbsp; ::=3D { lmpControlChannelEntry 4 =
}<BR><BR>BM&gt; Should=20
  NOT be a read-only. Neighbor needs to be specified. Consider<BR>BM&gt; =
an=20
  out-of-band Control channel over a shared ethernet LAN =
interface-<BR>BM&gt; If=20
  neighbor is not specified, how will hello config be transmitted =
to<BR>BM&gt; a=20
  neighbor?<BR>BM&gt; Only in the in-band (and with point to point link) =
case=20
  can the neighbor<BR>BM&gt; IP address can be learnt!<BR><FONT =
size=3D2><FONT=20
  face=3DArial><FONT color=3D#0000ff><SPAN =
class=3D295590318-25102001>[Martin=20
  Dubuc]&nbsp;I could change to read-write and specify in the =
conformance=20
  statements that it can be=20
  =
read-only.&nbsp;</SPAN><BR></FONT></FONT></FONT>-----------------<BR>lmpR=
emoteCcId=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Unsigned32<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-only<BR>&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp; =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "This value represents the remote control channel identifier. It=20
  is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; determined during the =

  negotiation phase. A =
value<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of=20
  zero means that the remote control channel identifier has=20
  not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; yet been=20
  assigned."<BR>&nbsp;&nbsp; ::=3D { lmpControlChannelEntry 5 =
}<BR><BR>BM&gt;=20
  Should read "A value of zero means that the remote CC ID has not yet =
been=20
  learnt"<BR><BR><FONT size=3D2><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
  class=3D295590318-25102001>[Martin=20
  =
Dubuc]&nbsp;OK.&nbsp;</SPAN><BR></FONT></FONT></FONT>--------------------=
--<BR><BR>lmpCcSetupRole=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  INTEGER { active(1), passive(2) }<BR>&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp; =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "The role that this node should take during establishment of=20
  this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; control channel. An =
active=20
  node will initiate establishment.=20
  A<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passive node will wait =
for the=20
  remote node to initiate. A =
pair<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  of nodes that both take the passive role will never=20
  establish<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  communications."<BR>&nbsp;&nbsp;=20
  DEFVAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { active =
}<BR><BR>Well, this=20
  is not consistent with the LMP draft, which defines automatic=20
  contention<BR>resolution mechanism based on node ID. Besides, this is =
prone to=20
  human(operator)-error.<BR><BR>The LMP draft reads:<BR>&nbsp; "To avoid =

  ambiguities, the node with the higher Node Id wins <BR>&nbsp;&nbsp; =
the=20
  contention; the node with the lower Node Id MUST stop <BR>&nbsp;&nbsp; =

  transmitting the Config message and respond to the Config message it=20
  <BR>&nbsp;&nbsp; received."<BR><FONT size=3D2><FONT face=3DArial><FONT =

  color=3D#0000ff><SPAN class=3D295590318-25102001>[Martin =
Dubuc]&nbsp;Yes, but the=20
  draft also allows control channels to be&nbsp;put in a ConfigRcv =
state, in=20
  which the node is waiting for acceptable configuration from the remote =
node. I=20
  agree that this is prone to human error, but we have to be able to =
support=20
  this=20
  =
mode.</SPAN><BR></FONT></FONT></FONT>------------------------<BR>lmpCcAdm=
inStatus=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  INTEGER { up(1), down(2) }<BR>&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create<BR>&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp; =
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "The desired operational status of this control =
channel."<BR>&nbsp;&nbsp; ::=3D=20
  { lmpControlChannelEntry 17 }<BR><BR>BM&gt; Should read "desired admin =

  state"<BR>BM&gt; Why is the Admin Status of CC not tied to admin =
status of=20
  the<BR>BM&gt; underlying interface?<BR><BR><FONT size=3D2><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D295590318-25102001>[Martin =
Dubuc]&nbsp;Desired=20
  operational status (see above). As for tying in admin status of CC to =
admin=20
  status of underlying interface,&nbsp;I do not believe&nbsp;we should =
tie these=20
  two. It is possible that one wants to disable a control channel, but =
not=20
  affect any other interfaces/applications sitting on top of the =
underlying=20
  interface.&nbsp;For instance, one may want to strictly disable=20
  =
LMP.</SPAN><BR></FONT></FONT></FONT>---------------------<BR>lmpTeLinkOpe=
rStatus=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  INTEGER { up(1), down(2), testing(3), degraded(4) }<BR>&nbsp;&nbsp;=20
  MAX-ACCESS&nbsp;&nbsp;&nbsp; read-only<BR>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "The actual =
operational=20
  status of this TE link. The=20
  status<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is set to testing =
when=20
  the TE link is performing =
link<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  verification. A degraded status indicates that the TE=20
  link<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cannot provide the=20
  provisioned protection level, but=20
  yet,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; there is no =
disruption of=20
  service. For instance, if =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  protection type is 1+1 and one link is down, the TE=20
  link<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; still carries the =
requested=20
  amount of data traffic, =
but<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this=20
  traffic is not protected anymore."<BR>&nbsp;&nbsp; ::=3D { =
lmpTeLinkEntry 5=20
  }<BR><BR>BM&gt; This should reflect the Finite state machine states, =
defined=20
  in the LMP draft,<BR>BM&gt; for TE Links.<BR><FONT size=3D2><FONT=20
  face=3DArial><FONT color=3D#0000ff><SPAN =
class=3D295590318-25102001>[Martin=20
  Dubuc]&nbsp;I will update the description. Do you want me to remove =
the=20
  testing=20
  =
state?&nbsp;</SPAN><BR></FONT></FONT></FONT>-----------------------------=
-<BR>lmpDataBearingLinkEntry=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  LmpDataBearingLinkEntry<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  not-accessible<BR>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "An entry in this =
table=20
  exists for each ifEntry that=20
  represents<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a =
data-bearing link.=20
  An ifEntry with an ifIndex must=20
  exist<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; before the =
corresponding=20
  lmpDataBearingLinkEntry is=20
  created.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If an entry=20
  representing the data-bearing link is destroyed=20
  in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the ifTable, then so =
is the=20
  corresponding entry in =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  lmpDataBearingLinkTable. The administrative status value=20
  is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; controlled from the =
ifEntry.=20
  The index to this table =
also<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  used to get information in the=20
  dataBearingChannelTable<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [BUNDLE-MIB]."<BR>&nbsp;&nbsp;=20
  INDEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { ifIndex=20
  }<BR><BR>BM&gt; Why is this not an "AUGMENT" to ifEntry?<BR><FONT =
size=3D2><FONT=20
  face=3DArial><FONT color=3D#0000ff><SPAN =
class=3D295590318-25102001>[Martin=20
  Dubuc]&nbsp;There is no reason why it shouldn't.&nbsp;Can =
someone&nbsp;give=20
  me&nbsp;a reason why it=20
  shouldn't?</SPAN><BR></FONT></FONT></FONT>-------------<BR><BR>BM&gt; =
>From an=20
  LMP perspective, the "member data links" of a TE Links need<BR>BM&gt; =
to be=20
  known.. I realize that this information is available from =
the<BR>BM&gt;=20
  bundling MIB.. It may be handy to add an object to the data =
bearing<BR>BM&gt;=20
  link table to store the TE Link ?<BR><FONT size=3D2><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D295590318-25102001>[Martin =
Dubuc]&nbsp;The info is=20
  actually not in the link bundling MIB, but in the=20
  =
ifStackTable.&nbsp;</SPAN><BR></FONT></FONT></FONT>------------------<BR>=
BM&gt;=20
  Along the lines of TE Link and CC up/down traps, perhaps we should=20
  have<BR>BM&gt; a trap to notify user when a data bearing link is =
transitioned=20
  to "down"<BR>BM&gt; state due to link verification failure. Note that =
this=20
  information is not<BR>BM&gt; obtainable from link up/down trap of =
underlying=20
  interface<BR><FONT size=3D2><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
  class=3D295590318-25102001>[Martin Dubuc]&nbsp;I will consider this in =
the next=20
  =
version.&nbsp;</SPAN><BR></FONT></FONT></FONT>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=20
  </DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15D84.6CF27390--

Delivery-date: Thu, 25 Oct 2001 11:47:48 -0700
From: Cheenu Srinivasan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 14:58:03 -0400

> Please find below my comments on the draft.

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

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

Its already there (the 2nd reference).

Cheenu

Delivery-date: Thu, 25 Oct 2001 11:45:25 -0700
Date: Thu, 25 Oct 2001 11:43:49 -0700
From: Sudheer Dharanikota <[email-masked]>
To: CCAMP WG <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Subject: 'GMPLS for ASON' discussion

Hi Zhi:

Sorry I have to change the title of the on going discussion :-)

>From the discussions we had let me summarize the "potential" issues
in adopting GMPLS for ASON:

0. Operators may have to have flexibility in selecting IP control
    plane against other control plane.

   As you pointed out in one of the recent mails.. a transport network
   control plane should be independent of the data being carried in the
   data plane. GMPLS does satisfy this need, so should be other control
   planes. What else do we need to do to make everybody comfortable
   here?

1. Call Controller (aka OIF UNI using GMPLS) may need
    enhancements.

    Your conention is that this is not private UNI and
    the line between these enhancements and NNI is bleak. My suggestion
is
    let us move this topic to OIF mailing list in stead of at IETF (if
it
    is ok by you and other folks).

2. Connection controler may pose new GMPLS 'signaling' extensions
    for inter-domain signaling based on federation models in ASON.

    Can you point out the enhancements needed? This is an on going
    work at IETF currently using crankback mechanisms.

3. Link resource manager may pose some new requirements that are
    not supported by bundling and hierarchy works.

    Do we see any additional requirements here?

4. ASON routing control requires support of hierarchical, source-based
   and step-by-step models.

   IETF does support source-based and step-by-step models. IETF is
working on
   hierarchical (inter-area and inter-domain) TE. Do you see any
   additional requirements here?

5. ASON requires standardization of interfaces between all the above
   components.

    Let us look at valid combination of these components and come up
with
    solid requirements.

6. ASON does not vouch for a specific addressing scheme.

    Which leaves an option for IPv4, IPv6 and NSAP addressing formats.

7. GMPLS may be supporting more than ASON required parameters. This
   is due to the principles used for subnetworking by ASON model.

    What is the problem here?

8. Some of the text is not clear from the IETF protocol specifications.

    Refer to GMPLS architecture document. Is this a valid answer?

Any other issues?

Thank you again for the active participation.

Regards,

sudheer

Delivery-date: Thu, 25 Oct 2001 11:17:07 -0700
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 25 Oct 2001 11:01:02 -0700

Snipped, comments in line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 3:47 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Moving right along ...

For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
aspects only) + centralised routing approach looks the best commercially for
what we want to do.  

JD:  Neil, as I have told you repeatedly in the past, GMPLS fully supports
this mode of deployment.  Furthermore, at request of several operators,
GMPLS
includes the capability of specifying the labels (e.g. time slots) for every
hop along the path of an LSP.  This allows an offline centralized routing
entity to globally optimize not only routes but also time slots within a
network
and then use GMPLS to signal them.   

Delivery-date: Thu, 25 Oct 2001 11:00:03 -0700
Date: Thu, 25 Oct 2001 13:47:28 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Sudheer,

I'm not sure if you can say choose one solution. It really depends on 
which you're more comfortable with. In IETF, we can choose a solution 
based on IP. In other groups that are more inclusive of other than IP, 
there may be other solutions that are non-IP, but also have IP.

As to your other email about private UNI (I want to combine to one 
email), I think you need to be careful. What exactly is private UNI that 
is not supported by I-NNI or E-NNI? From what I understand all these 
interfaces (ASON calls these reference points) allows varying of 
information exchange based on policy applied to them. If you're defining 
private UNI as one instance of NNI with specific info fixed, then I can 
imagine other variations that could create new interfaces. Do we want 
many interfaces?

For example, I'm assuming that private UNI will have some ER object, and 
also security? How would this be different from E-NNI? One thing that I 
think we need to do is first see what reasons are there for creating 
this instead of simply creating them because there's some slight 
differences. Of course, we'll have some fun discussions in OIF on this 
in a little while...:-)

Zhi

Sudheer Dharanikota wrote:

> Hi Neil:
> 
> Couple of comments.
> 
> [email-masked] wrote:
> 
> 
>>Hi Mike.....nice to hear from you and I think you make some good points.
>>However, I want to pick-up on one aspect you bring up a few times....and
>>that is 'choice'.  Operators need choice to suit their views on what
>>is/is-not a viable business case.
>>
>>
> 
> Agreed.
> 
> 
>>For example, we have various client layer networks besides IP to
>>accommodate, and of particular importance are managed BW services directly
>>off the L1 fabric, eg VC4 or lambdas say.  However, we can't see any valid
>>business case for generalised BoD/SVCs services here.....I mean, given
>>unknown calling/holding statistics just what capacity would one need to
>>build to to offer a GoS that customers would consider acceptable and that
>>you could get past finance/products people (esp given current climate)?
>>
>>
> 
> If you are assuming GMPLS is suitable for BoD/SVC services only then it
> is an incorrect assumption. GMPLS is providing Connection control and
> RC functions from ASON model. If that is not the assumption please ignore
> this comment.
> 
> 
>>So, on assumption that S-PVC-like services are all that is commercailly
>>viable (in our opinion at least) then you can ask yourself just what
>>additional revenues and/or Opex cost reductions are available from
>>implementating a control-plane solution?  Even this is difficult to justify
>>given:
>>-       current NMS approaches (in SDH) can easily cater for current and
>>foreseeable core trail churn rates;
>>-       the big costs are in access and laying ducts and installing
>>physicals....no control-plane solution is going to impact these.
>>
> 
>>However, assuming you do decide you want to implement a control-plane
>>solution in your transport networks then you really ought to be able to
>>choose the addressing, signalling and routing components on a best-of-breed
>>basis to suit what you want to do.  They are after all, quite disjoint
>>components and there are many architectural possibilities.......and this is
>>what ASON is all about....choice.
>>
>>For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
>>aspects only) + centralised routing approach looks the best commercially for
>>what we want to do.  Others may argue that the current GMPLS approach suits
>>them best.  ASON allows this choice.
>>
>>
> 
> Personal opinion:
> Agreed Neil. But it also depends on how well this piece fits in the eventual
> unified network control and management planes :-) We need to move one
> step ahead with our development ...  If we find no problems with GMPLS and
> people are comfortable with IP and MPLS control planes let us move ahead
> with GMPLS. It is a good idea to focus our energy on one rather than
> on multiple technologies.
> 
> Regards,
> 
> sudheer
> 
> 
>>regards, Neil
>>
>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]]
>>>Sent: 25 October 2001 11:49
>>>To: Maarten Vissers
>>>Cc: Sudheer Dharanikota; [email-masked]
>>>Subject: Re: Moving right along ...
>>>
>>>
>>>
>>>
>>>Maarten,
>>>
>>>In the interests of reconciliation consider the following:
>>>
>>>ASON and G-MPLS are both post hoc conceptual models
>>>describing the same physical and logical network. The
>>>objectives of automation through signalling are broadly
>>>similar. Therefore it would be surprising indeed if the
>>>solutions were widely different. ASON
>>>is indeed based on the layered model of G.805 and deals with
>>>layering issues up-front. GMPLS is derived from the Internet
>>>model which regards the physical layer as flat. When real
>>>world layering is encountered it is dealt with by refinements
>>>many of which
>>>appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one
>>>of the source documents from which G-MPLS inherits. Here LSP
>>>regions are defined in 6.2 which are as near as I can tell
>>>exactly equivalent to G.805 layer networks. Further, precedence rules
>>>between layers are established with the clear implication
>>>that a higher layer cannot be configured until the
>>>appropriate resources in the lower layer have been
>>>instantiated. The manner in which this may be done is
>>>considered a "local matter". The example
>>>given indicates that a Forwarding Adjacency (equivalent to a
>>>G.805 link supported by one or more trails (LSPs) in the
>>>server layer) may be initiated in various ways including from
>>>an external manager or another (adjacent) LSR. Thus the
>>>example you gave of
>>>a VC-1x layer being set up by signalling and VC-4 layer being
>>>set up by an external planning/management is certainly a
>>>valid implementation within the scope of the G-MPLS solution.
>>>By the same token it is undesirable (and anyway will not be
>>>possible) to
>>>confine signalling to certain layers while reserving others
>>>for management through a standard. Operators will want to
>>>make such important architectural choices on the basis of
>>>optimising their own operation. Once you have agreed on a
>>>signalling protocol to
>>>create connections within a layer network it is generically
>>>applicable to any layer network. Of course making such an
>>>implementation choice (ie management for VC-4, signalling for
>>>VC-1x) is an example of the "local policies" mentioned above.
>>>Such choices
>>>frequently appear as part of some sort of application
>>>specific profile or applications framework on top of the base
>>>generic standard. Note this sort of profiling (if that is the
>>>correct term) is
>>>generally needed to ensure interworking amongst elements
>>>which implement the same generic standard.
>>>
>>>On the last occasion that we studied application of
>>>signalling for transport networks in ITU (over 10 years ago
>>>at the time G.805 was first issued) we had concluded that
>>>connection set-up within a layer was the easy part ie there
>>>were several well
>>>established candidates to choose from (B-ISUP was the
>>>favorite. Neither PNNI nor RSVP existed at that time. ISIS
>>>had already been adopted for DCN in SDH and thus provided
>>>basic neighbour discovery and xSPF computation if required).
>>>The major new problem to
>>>resolve for multi-layer transport networks was indeed
>>>considered to be the desired behaviour at inter-layer
>>>boundaries. It seems that both initiatives have sidelined
>>>this issue as out of scope for the time being.
>>>
>>>regards,
>>>
>>>Mike Sexton
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38
>>>
>>>
>>>
>>> To:      Sudheer Dharanikota <[email-masked]>
>>>
>>> cc:      [email-masked](bcc: Michael J
>>>          SEXTON/GB/ALCATEL)
>>>
>>>
>>>
>>> Subject: Re: Moving right along ...
>>>
>>>
>>>
>>>
>>>
>>>
>>>Sudheer,
>>>
>>>Another issue is ...
>>>
>>>     - ASON is layer network based, GMPLS is not
>>>
>>>i.e. a request for a connection within ASON is treated within
>>>the boundaries of
>>>one layer network (e.g. within the boundaries of a
>>>VT1.5/VC-11 layer network, or
>>>within the boundaries of a STS-3c/VC-4 layer network). A
>>>VT1.5/VC-11 connection
>>>request is processed within the VT1.5/VC-11 layer network,
>>>using existing
>>>VT1.5/VC-11 links (GMPLS: link bundles). If there is not
>>>enough capacity  in the
>>>VT1.5/VC-11 links to support the request, the call fails.
>>>There is no "hidden"
>>>set up of a STS-1 or VC-4 trail supporting an additional
>>>VT/LOVC link or
>>>extending an existing VT/LOVC link. The set up of an
>>>additional STS-1 or VC-4
>>>trail is supported within the scope of network planning and/or network
>>>engineering. This is separated from the connection set up.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>Sudheer Dharanikota wrote:
>>>
>>>>Hi Maarten:
>>>>
>>>>Maarten Vissers wrote:
>>>>
>>>>
>>>>>Sudheer,
>>>>>
>>>>>At the moment I am unable to briefly summarize the
>>>>>
>>>differences between GMPLS and
>>>
>>>>>ASON. I was working from the perception that GMPLS could
>>>>>
>>>be one of the protocols
>>>
>>>>>supporting ASON. The technical comments I made during the
>>>>>
>>>last 10 months were
>>>
>>>>>based on this perception. Also the last comment
>>>>>
>>>describing the concept of serial
>>>
>>>>>compound link had this basis. Reading Yanhe's reply I had
>>>>>
>>>the impression that
>>>
>>>>>GMPLS is able to support serial compound links, but
>>>>>
>>>reading Eric's reply I got
>>>
>>>>>the opposite impression. Furthermore being very surprised
>>>>>
>>>by Eric's reaction on
>>>
>>>>>a pure technical issue, I composed a few challenging
>>>>>
>>>words to attrack more
>>>
>>>>>people to participate in the  discussion... :-)
>>>>>
>>>>I see one of the issue here being ...
>>>>
>>>>    - Does GMPLS support serial compound links?
>>>>
>>>>Let us enumerate few more questions and move the discussion
>>>>
>>>to a technical
>>>
>>>>level again, we need participation especially from the
>>>>
>>>folks who are involved
>>>
>>>>in ASON architecture work.
>>>>
>>>>
>>>>>Being impressed by the few hundred people attending the
>>>>>
>>>last ccamp sessions in
>>>
>>>>>London, I am surprised by the low percentage of those
>>>>>
>>>people being actively
>>>
>>>>>contributing to the correspondence. It can't be the case
>>>>>
>>>that only a handful of
>>>
>>>>>people have an opinion on these matters... and I believe
>>>>>
>>>the discussions would
>>>
>>>>>stay technical if more people express their opinion...
>>>>>
>>>there would not be a
>>>
>>>>>yes/no game between just a few people.
>>>>>
>>>>>
>>>>I thought this is how most of the standards meetings work.
>>>>
>>>5 % work, 95 %
>>>
>>>>try to gather industry intelligence ( :-) ) either by
>>>>
>>>attending IETF or by following
>>>
>>>>the mailing list.
>>>>
>>>>
>>>>>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available
>>>>>
>>>it will be possible to
>>>
>>>>>start an evaluation of GMPLS as a specific protocol for
>>>>>
>>>ASON. As indicated in a
>>>
>>>>>previous email from Steve Trowbridge, ITU-T will make
>>>>>
>>>those ASON documents
>>>
>>>>>available to IETF so we can jointly work this evaluation.
>>>>>
>>>>>
>>>>Most of these documents are available on the t1x1 site. But
>>>>
>>>what we need here is
>>>
>>>>the "delta" that is missing between ASON architecture and
>>>>
>>>the view of GMPLS
>>>
>>>>architecture. Can you help us with this? We may start with
>>>>
>>>a short list...
>>>
>>>>>The approval of the current ASON recommendations is just
>>>>>
>>>a first step within the
>>>
>>>>>larger ASON task. Work is started on other elements of
>>>>>
>>>ASON (G.rtg (routing),
>>>
>>>>>G.lm (link management) and pnni based specific protocol
>>>>>
>>>as an implementation of
>>>
>>>>>the protocol neutral specification in G.7713)),
>>>>>
>>>discussions are started
>>>
>>>>>identifying further ASON elements, and work to extend
>>>>>
>>>G.8080 is planned to start
>>>
>>>>>after this SG15 meeting.
>>>>>
>>>>>
>>>>Obviously GMPLS is a potential candidate to solve the ASON
>>>>
>>>issues. It may be
>>>
>>>>ahead of its time as far as ITU and ANSI are concerned. So
>>>>
>>>let us ammend or
>>>
>>>>modify it to the ITU view on the transport control plane.
>>>>
>>>>Regards,
>>>>
>>>>sudheer
>>>>
>>>>
>>>>>Up to so far... {time to shut down my computer and go to
>>>>>
>>>the concert hall in
>>>
>>>>>Geneva... time to relax after a week and a half of hectic
>>>>>
>>>work over here...}
>>>
>>>>>Regards,
>>>>>
>>>>>Maarten
>>>>>
>>>>>Sudheer Dharanikota wrote:
>>>>>
>>>>>>Hi Marteen:
>>>>>>
>>>>>>Can you briefly summarize the differences you see between
>>>>>>GMPLS architecture and ASON architecture? This has been
>>>>>>asked by many of the folks at IETF.
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>sudheer
>>>>>>
>>>>>>PS: I thought these mails were about label format and suddenly
>>>>>>this is turning into an ITU versus IETF discussion :-(
>>>>>>
> 
> 

Delivery-date: Thu, 25 Oct 2001 10:50:14 -0700
Date: Thu, 25 Oct 2001 13:45:09 -0400
To: "[email-masked]" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Cc: "'Cheenu Srinivasan'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>

--=====================_103563196==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:34 AM 10/25/2001 -0700, S.Manikantan wrote:
>Hello Cheenu
>
>Please find below my comments on the draft.
>
>with best regards
>mani
>(S.Manikantan)
>
>Comment 1:
>"1. Introduction
>   ...
>    Multi-Protocol Label Switching (MPLS) [MPLSArch].
>                                          ^^^^^^^^^^
>   ..."
>
>"2. Terminology
>  ...
>    document [MPLSArch] and various MPLS-related MIBs such as
>             ^^^^^^^^^^^
>  ..."
>
>Mani>> The reference can be changed to RFC3031.

         Okay.

>Comment 2:
>"2. Terminology
>  ...
>    [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and
>                          ^^^^^^^^^
>  ..."
>
>Mani>> The reference to LDPMIB needs to be added to section 8

         Okay.

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

         Yes.

>Comment 4:
>"4.2.  MPLS-LSR-MIB
>    ...
>    MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS
>                                                  ^^^^^^^
>    ..."
>
>Mani>> Should it be MPLS-LSR-MIB for consistency?

         Sure.

>Comment 5:
>"4.3.  MPLS-LDP-MIB
>    ...
>    Distribution Protocol (LDP).
>                         ^^^^^^^
>    ..."
>
>Mani>> Reference to RFC 3036 can be mentioned here, and RFC3036
>can be added to section 8. References.
>
>Comment 6:
>" 4.7.  PPVPN-MPLS-VPN-MIB
>
>    The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects
>                         ^^^^^^^^^^
>
>    that are used to model and manage RFC2277bis MPLS VPNs.
>                                      ^^^^^^^^^^
>    ..."
>
>Mani>> a) Reference to VPNMIB needs to be added in Section 8 References.
>        b) RFC2277bis - should this be RFC2547bis??

         Typo, yes.

>Comment 7:
>"5.2.  Provider Provisioned Virtual Private Network MIBs
>   ...
>    MIBs, as this MIB is described above in section
>                                             ^^^^^^^^^^
>   ..."
>
>Mani>> section "4.7" - needs added.

         Thanks for the comments.

         --Tom

>-----Original Message-----
>From:   Cheenu Srinivasan [SMTP:[email-masked]]
>Sent:   Thursday, October 25, 2001 6:33 AM
>To:     [email-masked]'; [email-masked]'
>Subject:        draft-ietf-mpls-mgmt-overview-00.txt posted
>
>I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should
>appear on the IETF site shortly. A copy of this I-D is attached.
>
>Cheenu
>
> > -----Original Message-----
> > From: George Swallow [mailto:[email-masked]]
> > Sent: Tuesday, October 23, 2001 4:37 PM
> > Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
> >
> >
> > Given that many have supported the idea and none have opposed, the
> > above draft is accepted as a work group draft.
> >
> > ...George
>
>  << File: draft-ietf-mpls-mgmt-overview-00.txt >>

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_103563196==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 10:34 AM 10/25/2001 -0700, S.Manikantan wrote:<br>
<blockquote type=cite cite>Hello Cheenu<br>
<br>
Please find below my comments on the draft.<br>
<br>
with best regards<br>
mani<br>
(S.Manikantan)<br>
<br>
Comment 1:<br>
&quot;1. Introduction<br>
&nbsp; ... <br>
&nbsp;&nbsp; Multi-Protocol Label Switching (MPLS) [MPLSArch].<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^<br>
&nbsp; ...&quot;<br>
<br>
&quot;2. Terminology<br>
&nbsp;...&nbsp; <br>
&nbsp;&nbsp; document [MPLSArch] and various MPLS-related MIBs such
as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^^<br>
&nbsp;...&quot;<br>
<br>
Mani&gt;&gt; The reference can be changed to
RFC3031.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay.<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Comment 2:<br>
&quot;2. Terminology<br>
&nbsp;...<br>
&nbsp;&nbsp; [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB],
and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^<br>
&nbsp;...&quot;<br>
<br>
Mani&gt;&gt; The reference to LDPMIB needs to be added to section
8</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay.<br>
<br>
<blockquote type=cite cite><font size=3>References.<br>
<br>
Comment 3:<br>
&quot;4.2.&nbsp; MPLS-LSR-MIB<br>
&nbsp;&nbsp; <br>
&nbsp;&nbsp; The MPLS-LSR-MIB describes managed objects for modeling
a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; The reference to LSRMIB needs to be added??
</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes.<br>
<br>
<blockquote type=cite cite><font size=3>Comment 4:<br>
&quot;4.2.&nbsp; MPLS-LSR-MIB<br>
&nbsp;&nbsp; ...<br>
&nbsp;&nbsp; MPLS cross-connect table (mplsXCTable) in the LSR MIB.
MPLS<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; Should it be MPLS-LSR-MIB for
consistency?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Sure.<br>
<br>
<blockquote type=cite cite><font size=3>Comment 5:<br>
&quot;4.3.&nbsp; MPLS-LDP-MIB<br>
&nbsp;&nbsp; ...<br>
&nbsp;&nbsp; Distribution Protocol (LDP).<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; Reference to RFC 3036 can be mentioned here, and
RFC3036<br>
can be added to section 8. References.<br>
<br>
Comment 6:<br>
&quot; 4.7.&nbsp; PPVPN-MPLS-VPN-MIB<br>
&nbsp;&nbsp; <br>
&nbsp;&nbsp; The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed
objects<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^<br>
<br>
&nbsp;&nbsp; that are used to model and manage RFC2277bis MPLS 
VPNs.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; a) Reference to VPNMIB needs to be added in Section 8
References.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) RFC2277bis - should this be
RFC2547bis??</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Typo,
yes.<br>
<br>
<blockquote type=cite cite><font size=3>Comment 7:<br>
&quot;5.2.&nbsp; Provider Provisioned Virtual Private Network MIBs<br>
&nbsp; ...<br>
&nbsp;&nbsp; MIBs, as this MIB is described above in section<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^<br>
&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; section &quot;4.7&quot; - needs
added.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Thanks for
the comments.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>-----Original Message-----<br>
From:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Cheenu Srinivasan
[SMTP:[email-masked]]<br>
Sent:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Thursday, October 25, 2001 6:33
AM<br>
To:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[email-masked]';
[email-masked]'<br>
Subject:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>draft-ietf-mpls-mgmt-overview-00.txt
posted<br>
<br>
I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should<br>
appear on the IETF site shortly. A copy of this I-D is attached.<br>
<br>
Cheenu<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: George Swallow
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
&gt; Sent: Tuesday, October 23, 2001 4:37 PM<br>
&gt; Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt <br>
&gt; <br>
&gt; <br>
&gt; Given that many have supported the idea and none have opposed,
the<br>
&gt; above draft is accepted as a work group draft.<br>
&gt; <br>
&gt; ...George<br>
<br>
&nbsp;&lt;&lt; File: draft-ietf-mpls-mgmt-overview-00.txt &gt;&gt;
</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_103563196==_.ALT--

Delivery-date: Thu, 25 Oct 2001 10:25:57 -0700
Date: Thu, 25 Oct 2001 13:13:52 -0400
To: Baktha Muralidharan <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: Re: Comments on LMP MIB
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

--=====================_101685586==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

         Comments inline.  All editorial comments
look good.

>           My feedback comments are prefixed "BM>"
>
>/Baktha
>======================================================
>
>7.5.  lmpLinkVerificationTable
>
>    This table represents the link verification parameters associated
>    with the TE links.
>
>BM> Add "Augments lmpTeLinkTable"
>
>----------
>
>7.7.  lmpDataBearingLinkPerfTable
>
>    This table contains the objects to measure the LMP performance of
>    data-bearing links and is an AUGMENT to the lmpDataBearingLinkTable.
>
>BM> Add "Augments lmpDataBearingLinkTable"
>
>------------
>
>8.  Example of LMP Control Channel Setup
>
>    In this section we provide a brief example of using the MIB
>    objects described in section 11 to set up an LMP control channel.
>    While this example is not meant to illustrate every nuance of the
>    MIB, it is intended as an aid to understanding some of the key
>    concepts. It is meant to be read after going through the MIB itself.
>
>
>BM> Should read "objects desribed in section 10"
>----------------
>
>lmpAdminStatus OBJECT-TYPE
>    SYNTAX        INTEGER { up(1), down(2) }
>    MAX-ACCESS    read-write
>    STATUS        current
>    DESCRIPTION
>        "The desired operational status of LMP on the node."
>    DEFVAL        { up }
>    ::= { lmpObjects 1 }
>
>BM> Do we mean administrative state?
>
>----------------------
>
>lmpNbrTable OBJECT-TYPE
>    SYNTAX        SEQUENCE OF LmpNbrEntry
>    MAX-ACCESS    not-accessible
>    STATUS        current
>    DESCRIPTION
>        "This table specifies the neighbor node to which control channels
>         may be established."
>    ::= { lmpObjects 2 }
>
>BM> neighbor node(s)
>----------------------------
>       lmpNbrRetransmitInterval           = 10
>
>Wouldn't want this to be the same for link verification, summary etc.
>----------------
>lmpNbrAdminStatus OBJECT-TYPE
>    SYNTAX        INTEGER { up(1), down(2) }
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>        "The desired operational status of LMP to this remote node."
>    ::= { lmpNbrEntry 3 }
>
>BM> Do we mean desired admin. state?
>--------------------
>
>lmpCcHelloIntervalDefaultMin
>
>BM> Presumably, this serves as the default value for lmpCcHelloIntervalMin?
>
>lmpCcHelloIntervalDefaultMax
>
>BM> Presumably, this serves as the default value for lmpCcHelloIntervalMax?
>
>lmpCcHelloDeadIntervalDefaultMin
>
>BM> Presumably, this serves as the default value for 
>lmpCcHelloDeadIntervalMin?
>
>lmpCcHelloDeadIntervalDefaultMax
>
>BM> Presumably, this serves as the default value for 
>lmpCcHelloDeadIntervalMax?
>------------------------
>
>lmpCcHelloDeadIntervalDefault OBJECT-TYPE
>
>    SYNTAX        LmpInterval
>    MAX-ACCESS    read-write
>    STATUS        current
>    DESCRIPTION
>        "This object specifies the default HelloDeadInterval parameter to
>         use in the Hello protocol keep-alive phase. It indicates how long
>         a device should wait before declaring the control channel dead.
>         The HelloDeadInterval parameter must be greater than the
>         HelloInterval parameter and should be at least three times the
>         value of HelloInterval."
>
>BM> Remove the part "must be greated than the HelloInterval parameter and"
>-----------------
>
>lmpCcIsIf OBJECT-TYPE
>    SYNTAX        TruthValue
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>        "Denotes whether or not this control channel corresponds to
>         an interface represented in the interfaces group table."
>    ::= { lmpControlChannelEntry 3 }
>
>BM> Why this additional object?. Why not require that there be a valid
>BM> lmpCcUnderlyingIfIndex for CC's rowstatsus to go into "active" state
>BM> and that in the absence of a valid underlying interface, the CC
>BM> will be in the "notReady" state?

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

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

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

>----------------
>
>lmpCcNbrNodeId OBJECT-TYPE
>    SYNTAX        NodeID
>    MAX-ACCESS    read-only
>    STATUS        current
>    DESCRIPTION
>        "This is the Node ID of the control channel remote node.
>         This value gets created by the node when a Config message
>         is received or when an outgoing Config message is acknowledged
>         by the remote node."
>    ::= { lmpControlChannelEntry 4 }
>
>BM> Should NOT be a read-only. Neighbor needs to be specified. Consider
>BM> an out-of-band Control channel over a shared ethernet LAN interface-
>BM> If neighbor is not specified, how will hello config be transmitted to
>BM> a neighbor?
>BM> Only in the in-band (and with point to point link) case can the neighbor
>BM> IP address can be learnt!

         Okay.

>-----------------
>lmpRemoteCcId OBJECT-TYPE
>    SYNTAX        Unsigned32
>    MAX-ACCESS    read-only
>    STATUS        current
>    DESCRIPTION
>        "This value represents the remote control channel identifier. It is
>         determined during the negotiation phase. A value
>         of zero means that the remote control channel identifier has not
>         yet been assigned."
>    ::= { lmpControlChannelEntry 5 }
>
>BM> Should read "A value of zero means that the remote CC ID has not yet 
>been learnt"
>
>----------------------
>
>lmpCcSetupRole OBJECT-TYPE
>    SYNTAX        INTEGER { active(1), passive(2) }
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>        "The role that this node should take during establishment of this
>         control channel. An active node will initiate establishment. A
>         passive node will wait for the remote node to initiate. A pair
>         of nodes that both take the passive role will never establish
>         communications."
>    DEFVAL        { active }
>
>Well, this is not consistent with the LMP draft, which defines automatic 
>contention
>resolution mechanism based on node ID. Besides, this is prone to 
>human(operator)-error.
>
>The LMP draft reads:
>   "To avoid ambiguities, the node with the higher Node Id wins
>    the contention; the node with the lower Node Id MUST stop
>    transmitting the Config message and respond to the Config message it
>    received."

         The text needs to be updated.

>------------------------
>lmpCcAdminStatus OBJECT-TYPE
>    SYNTAX        INTEGER { up(1), down(2) }
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>        "The desired operational status of this control channel."
>    ::= { lmpControlChannelEntry 17 }
>
>BM> Should read "desired admin state"
>BM> Why is the Admin Status of CC not tied to admin status of the
>BM> underlying interface?
>
>---------------------
>lmpTeLinkOperStatus OBJECT-TYPE
>    SYNTAX        INTEGER { up(1), down(2), testing(3), degraded(4) }
>    MAX-ACCESS    read-only
>    STATUS        current
>    DESCRIPTION
>        "The actual operational status of this TE link. The status
>         is set to testing when the TE link is performing link
>         verification. A degraded status indicates that the TE link
>         cannot provide the provisioned protection level, but yet,
>         there is no disruption of service. For instance, if the
>         protection type is 1+1 and one link is down, the TE link
>         still carries the requested amount of data traffic, but
>         this traffic is not protected anymore."
>    ::= { lmpTeLinkEntry 5 }
>
>BM> This should reflect the Finite state machine states, defined in the 
>LMP draft,
>BM> for TE Links.

         Is that necessary, or is the above subset sufficient?

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

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

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

         Isn't this shown through the underlying ifIndex?

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

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

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_101685586==_.ALT
Content-Type: text/html; charset="us-ascii"

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

--=====================_101685586==_.ALT--

Delivery-date: Thu, 25 Oct 2001 10:23:17 -0700
Date: Thu, 25 Oct 2001 10:11:12 -0700
From: Sudheer Dharanikota <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Neil:

Couple of comments.

[email-masked] wrote:

> Hi Mike.....nice to hear from you and I think you make some good points.
> However, I want to pick-up on one aspect you bring up a few times....and
> that is 'choice'.  Operators need choice to suit their views on what
> is/is-not a viable business case.
>

Agreed.

>
> For example, we have various client layer networks besides IP to
> accommodate, and of particular importance are managed BW services directly
> off the L1 fabric, eg VC4 or lambdas say.  However, we can't see any valid
> business case for generalised BoD/SVCs services here.....I mean, given
> unknown calling/holding statistics just what capacity would one need to
> build to to offer a GoS that customers would consider acceptable and that
> you could get past finance/products people (esp given current climate)?
>

If you are assuming GMPLS is suitable for BoD/SVC services only then it
is an incorrect assumption. GMPLS is providing Connection control and
RC functions from ASON model. If that is not the assumption please ignore
this comment.

>
> So, on assumption that S-PVC-like services are all that is commercailly
> viable (in our opinion at least) then you can ask yourself just what
> additional revenues and/or Opex cost reductions are available from
> implementating a control-plane solution?  Even this is difficult to justify
> given:
> -       current NMS approaches (in SDH) can easily cater for current and
> foreseeable core trail churn rates;
> -       the big costs are in access and laying ducts and installing
> physicals....no control-plane solution is going to impact these.

>
> However, assuming you do decide you want to implement a control-plane
> solution in your transport networks then you really ought to be able to
> choose the addressing, signalling and routing components on a best-of-breed
> basis to suit what you want to do.  They are after all, quite disjoint
> components and there are many architectural possibilities.......and this is
> what ASON is all about....choice.
>
> For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
> aspects only) + centralised routing approach looks the best commercially for
> what we want to do.  Others may argue that the current GMPLS approach suits
> them best.  ASON allows this choice.
>

Personal opinion:
Agreed Neil. But it also depends on how well this piece fits in the eventual
unified network control and management planes :-) We need to move one
step ahead with our development ...  If we find no problems with GMPLS and
people are comfortable with IP and MPLS control planes let us move ahead
with GMPLS. It is a good idea to focus our energy on one rather than
on multiple technologies.

Regards,

sudheer

>
> regards, Neil
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 25 October 2001 11:49
> > To: Maarten Vissers
> > Cc: Sudheer Dharanikota; [email-masked]
> > Subject: Re: Moving right along ...
> >
> >
> >
> >
> > Maarten,
> >
> > In the interests of reconciliation consider the following:
> >
> > ASON and G-MPLS are both post hoc conceptual models
> > describing the same physical and logical network. The
> > objectives of automation through signalling are broadly
> > similar. Therefore it would be surprising indeed if the
> > solutions were widely different. ASON
> > is indeed based on the layered model of G.805 and deals with
> > layering issues up-front. GMPLS is derived from the Internet
> > model which regards the physical layer as flat. When real
> > world layering is encountered it is dealt with by refinements
> > many of which
> > appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one
> > of the source documents from which G-MPLS inherits. Here LSP
> > regions are defined in 6.2 which are as near as I can tell
> > exactly equivalent to G.805 layer networks. Further, precedence rules
> > between layers are established with the clear implication
> > that a higher layer cannot be configured until the
> > appropriate resources in the lower layer have been
> > instantiated. The manner in which this may be done is
> > considered a "local matter". The example
> > given indicates that a Forwarding Adjacency (equivalent to a
> > G.805 link supported by one or more trails (LSPs) in the
> > server layer) may be initiated in various ways including from
> > an external manager or another (adjacent) LSR. Thus the
> > example you gave of
> > a VC-1x layer being set up by signalling and VC-4 layer being
> > set up by an external planning/management is certainly a
> > valid implementation within the scope of the G-MPLS solution.
> > By the same token it is undesirable (and anyway will not be
> > possible) to
> > confine signalling to certain layers while reserving others
> > for management through a standard. Operators will want to
> > make such important architectural choices on the basis of
> > optimising their own operation. Once you have agreed on a
> > signalling protocol to
> > create connections within a layer network it is generically
> > applicable to any layer network. Of course making such an
> > implementation choice (ie management for VC-4, signalling for
> > VC-1x) is an example of the "local policies" mentioned above.
> > Such choices
> > frequently appear as part of some sort of application
> > specific profile or applications framework on top of the base
> > generic standard. Note this sort of profiling (if that is the
> > correct term) is
> > generally needed to ensure interworking amongst elements
> > which implement the same generic standard.
> >
> > On the last occasion that we studied application of
> > signalling for transport networks in ITU (over 10 years ago
> > at the time G.805 was first issued) we had concluded that
> > connection set-up within a layer was the easy part ie there
> > were several well
> > established candidates to choose from (B-ISUP was the
> > favorite. Neither PNNI nor RSVP existed at that time. ISIS
> > had already been adopted for DCN in SDH and thus provided
> > basic neighbour discovery and xSPF computation if required).
> > The major new problem to
> > resolve for multi-layer transport networks was indeed
> > considered to be the desired behaviour at inter-layer
> > boundaries. It seems that both initiatives have sidelined
> > this issue as out of scope for the time being.
> >
> > regards,
> >
> > Mike Sexton
> >
> >
> >
> >
> >
> >
> >
> > Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38
> >
> >
> >
> >  To:      Sudheer Dharanikota <[email-masked]>
> >
> >  cc:      [email-masked](bcc: Michael J
> >           SEXTON/GB/ALCATEL)
> >
> >
> >
> >  Subject: Re: Moving right along ...
> >
> >
> >
> >
> >
> >
> > Sudheer,
> >
> > Another issue is ...
> >
> >      - ASON is layer network based, GMPLS is not
> >
> > i.e. a request for a connection within ASON is treated within
> > the boundaries of
> > one layer network (e.g. within the boundaries of a
> > VT1.5/VC-11 layer network, or
> > within the boundaries of a STS-3c/VC-4 layer network). A
> > VT1.5/VC-11 connection
> > request is processed within the VT1.5/VC-11 layer network,
> > using existing
> > VT1.5/VC-11 links (GMPLS: link bundles). If there is not
> > enough capacity  in the
> > VT1.5/VC-11 links to support the request, the call fails.
> > There is no "hidden"
> > set up of a STS-1 or VC-4 trail supporting an additional
> > VT/LOVC link or
> > extending an existing VT/LOVC link. The set up of an
> > additional STS-1 or VC-4
> > trail is supported within the scope of network planning and/or network
> > engineering. This is separated from the connection set up.
> >
> > Regards,
> >
> > Maarten
> >
> > Sudheer Dharanikota wrote:
> > >
> > > Hi Maarten:
> > >
> > > Maarten Vissers wrote:
> > >
> > > > Sudheer,
> > > >
> > > > At the moment I am unable to briefly summarize the
> > differences between GMPLS and
> > > > ASON. I was working from the perception that GMPLS could
> > be one of the protocols
> > > > supporting ASON. The technical comments I made during the
> > last 10 months were
> > > > based on this perception. Also the last comment
> > describing the concept of serial
> > > > compound link had this basis. Reading Yanhe's reply I had
> > the impression that
> > > > GMPLS is able to support serial compound links, but
> > reading Eric's reply I got
> > > > the opposite impression. Furthermore being very surprised
> > by Eric's reaction on
> > > > a pure technical issue, I composed a few challenging
> > words to attrack more
> > > > people to participate in the  discussion... :-)
> > >
> > > I see one of the issue here being ...
> > >
> > >     - Does GMPLS support serial compound links?
> > >
> > > Let us enumerate few more questions and move the discussion
> > to a technical
> > > level again, we need participation especially from the
> > folks who are involved
> > > in ASON architecture work.
> > >
> > > >
> > > > Being impressed by the few hundred people attending the
> > last ccamp sessions in
> > > > London, I am surprised by the low percentage of those
> > people being actively
> > > > contributing to the correspondence. It can't be the case
> > that only a handful of
> > > > people have an opinion on these matters... and I believe
> > the discussions would
> > > > stay technical if more people express their opinion...
> > there would not be a
> > > > yes/no game between just a few people.
> > > >
> > >
> > > I thought this is how most of the standards meetings work.
> > 5 % work, 95 %
> > > try to gather industry intelligence ( :-) ) either by
> > attending IETF or by following
> > >
> > > the mailing list.
> > >
> > > >
> > > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available
> > it will be possible to
> > > > start an evaluation of GMPLS as a specific protocol for
> > ASON. As indicated in a
> > > > previous email from Steve Trowbridge, ITU-T will make
> > those ASON documents
> > > > available to IETF so we can jointly work this evaluation.
> > > >
> > >
> > > Most of these documents are available on the t1x1 site. But
> > what we need here is
> > > the "delta" that is missing between ASON architecture and
> > the view of GMPLS
> > > architecture. Can you help us with this? We may start with
> > a short list...
> > >
> > > >
> > > > The approval of the current ASON recommendations is just
> > a first step within the
> > > > larger ASON task. Work is started on other elements of
> > ASON (G.rtg (routing),
> > > > G.lm (link management) and pnni based specific protocol
> > as an implementation of
> > > > the protocol neutral specification in G.7713)),
> > discussions are started
> > > > identifying further ASON elements, and work to extend
> > G.8080 is planned to start
> > > > after this SG15 meeting.
> > > >
> > >
> > > Obviously GMPLS is a potential candidate to solve the ASON
> > issues. It may be
> > > ahead of its time as far as ITU and ANSI are concerned. So
> > let us ammend or
> > > modify it to the ITU view on the transport control plane.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > >
> > > > Up to so far... {time to shut down my computer and go to
> > the concert hall in
> > > > Geneva... time to relax after a week and a half of hectic
> > work over here...}
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > Sudheer Dharanikota wrote:
> > > > >
> > > > > Hi Marteen:
> > > > >
> > > > > Can you briefly summarize the differences you see between
> > > > > GMPLS architecture and ASON architecture? This has been
> > > > > asked by many of the folks at IETF.
> > > > >
> > > > > Regards,
> > > > >
> > > > > sudheer
> > > > >
> > > > > PS: I thought these mails were about label format and suddenly
> > > > > this is turning into an ITU versus IETF discussion :-(
> >

Delivery-date: Thu, 25 Oct 2001 09:55:29 -0700
Date: Thu, 25 Oct 2001 09:46:52 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Maarten Vissers <[email-masked]>, [email-masked], q12/15 <[email-masked]>, q14/15 <[email-masked]>
Subject: Re: Moving right along ...

Hi Zhi:

Zhi-Wei Lin wrote:

> Hi Sudheer, I tried answering some of your questions in another email,
> so I will put some short answers to this email...below...
>
>
> > Let us enumerate few more questions and move the discussion to a technical
> > level again, we need participation especially from the folks who are involved
> > in ASON architecture work.
> >
> >
>
> <z>This is where I keep suggesting that we put in clarifying text. I
> showed an example a few emails back about "A-B-C" configuration where B
> is not GMPLS aware. I want to bring out the point that the text in GMPLS
> is not clear about whether or not this is supported.
>
> I believe GMPLS can support serial compound links, but we need to
> describe in the text properly (or more clearly) so that people are aware
> of this, instead of simply saying that "it is obvious to the informed
> reader". I think our goal should be to make it as readable as possible
> to the larger audience, not just a few people who has followed the
> mailing list. I keep getting reminded of how specific BGP documents are
> and how much information on BGP is actually not specified anywhere that
> is actually needed in order for it to work properly...this seems a
> little "elitist" to me...please don't flame me...:-)
> </z>
>

People have been working on GMPLS for a while. Some of us are catching up
and some are deep down in it. Hence for some this is magic and for others this is
trivial. Let us be considerate to both. Now there is an architecture document,
which tries to capture most of the GMPLS approach. Please refer to this
document for 'some' of the answers.

>
>
> >>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
> >>start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
> >>previous email from Steve Trowbridge, ITU-T will make those ASON documents
> >>available to IETF so we can jointly work this evaluation.
> >>
> >>
> >
> > Most of these documents are available on the t1x1 site. But what we need here is
> > the "delta" that is missing between ASON architecture and the view of GMPLS
> > architecture. Can you help us with this? We may start with a short list...
> >
> >
>
> <z>Well, let's see, I don't think anybody as really gone through the
> details of it yet. I would be very interested if anybody out there have
> done this already</z>
>

Well.. I am one of them who is interested and am looking at this. Same would be
the case for many of us the vendors who will benifit from this work.

>
> >>The approval of the current ASON recommendations is just a first step within the
> >>larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
> >>G.lm (link management) and pnni based specific protocol as an implementation of
> >>the protocol neutral specification in G.7713)),  discussions are started
> >>identifying further ASON elements, and work to extend G.8080 is planned to start
> >>after this SG15 meeting.
> >>
> >>
> >
> > Obviously GMPLS is a potential candidate to solve the ASON issues. It may be
> > ahead of its time as far as ITU and ANSI are concerned. So let us ammend or
> > modify it to the ITU view on the transport control plane.
> >
>
> <z>I agree GMPLS is definitely a candidate. That is why I don't
> understand some people's mentality of "ITU against/versus IETF". I think
> they are complementary. The architecture experts are in ITU (at least
> some experts) and the protocol experts are in IETF (again, at least some
> experts). In terms of ahead of its times...don't know about
> that...depends on your timeframe...1 month? 1 year? 10 years? 1 week? :-)
> </z>
>

The goal is to keep it as tight timeframe as possible. This is certainly the motto
of IETF also. But we should be forward thinking too :-)

So let us see if GMPLS is meeting ASON requirements. Please refer to my other
mail in response to your summry.

Regards,

sudheer

>
> > Regards,
> >
> > sudheer
> >
> >
> >>Up to so far... {time to shut down my computer and go to the concert hall in
> >>Geneva... time to relax after a week and a half of hectic work over here...}
> >>
> >>Regards,
> >>
> >>Maarten
> >>
> >>Sudheer Dharanikota wrote:
> >>
> >>>Hi Marteen:
> >>>
> >>>Can you briefly summarize the differences you see between
> >>>GMPLS architecture and ASON architecture? This has been
> >>>asked by many of the folks at IETF.
> >>>
> >>>Regards,
> >>>
> >>>sudheer
> >>>
> >>>PS: I thought these mails were about label format and suddenly
> >>>this is turning into an ITU versus IETF discussion :-(
> >>>

Delivery-date: Thu, 25 Oct 2001 09:37:31 -0700
Date: Thu, 25 Oct 2001 09:33:14 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Irfan Lateef <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Zhi:

Thank you for taking time in writing this informative mail.
Few of my opinions and questions are inline...
Please let me know if I am wrong with any of the assumptions.

For those who are interested in ASON architecture refer to
http://http://www.t1.org/filemgr/FileList.taf?Directory=t1x1%5Cx1.5&ShowTitle=New%20T1X1.5%20Files

Of course, the version on this site is old . But this may be
good enough to start some technical discussion. Hopefully
ITU will provide an updated version soon for IETF public.

Zhi-Wei Lin wrote:

> Hi Sudheer,
>
> OK I'll try to highlight some. I think Maarten mentioned one already:
> -- ASON is based on a separation of layer network.
>
> Not only that, ASON is also based on separation of functional roles of
> the switched network. ASON defines the architecture of the switched
> network in terms of the interactions of different components. Components
> defined by ASON performs specific tasks:
>

Agreed on ITU/ANSI approach to define ASON. To compare ASON
requiremetns with what GMPLS provides, we need to see if all these
components are present in what is supported by GMPLS. I would assume
this is not an issue if GMPLS has all the components defined by ASON
(G.808 V0.8.2).

> --Call controller (CallC) is the "service" component that interfaces
> with the user to support service requests. I believe this can be viewed
> as been handled by the OIF UNI specification, which provides the user to
> network request capability

Well then - this is not an issue. Because OIF UNI is already using GMPLS
extensions to support CallC functions. There are plans to enhance OIF UNI
to what ever functions that are missing either using Private UNI or others.
Of course we can always discuss this on OIF mailing lists and at the meetings.

>
> --Connection controller (CC) is the network component that supports the
> connection operations, which includes setup and release of individual
> links (ITU: link connections) in support of the user request. A set of
> connection controllers are involved on a sub-network (area of AS) basis
> to set up/release connections within its domain of responsibility, and
> interacts with other CC in different ways depending on how the operator
> configures the interactions. Methods of interaction include a joint
> federation model and a cooperative federation model. CC is I think what
> GMPLS is about, in terms of setting up and releasing/tearing down
> connections.

Agreed that CC is what GMPLS 'signaling' is all about. Currently (untill
inter-area
TE model is finalized) IETF is working with one area. GMPLS does not
assume how to and where to expand loose segments of a path. So a CC
can be placed anywhere in an area. This path computation can be in an NE
or outside NE. So, in my opinion, this model supports both joint and co-operative
federation models. of course, it has to have all the primitives to manage a
connection. Let me know if I missed any particular scenario.

> --Link resource manager (LRM) is the network component that assigns a link
> (ITU: link connection) from a link bundle/TE-link (ITU: link). Thus the
> progression of signaling goes from CC which receives requests for
> connections to LRM which chooses a link, and provides the CC with the
> requested link information so that CC can set up a sub-network
> connection (a connection across a sub-network). Note that sub-network
> connection "concept" is a recursive definition where the limit of
> recursion of a sub-network connection is the fabric connection. The LRM
> from GMPLS perspective is subsumed into the CC (this is where the label
> negotiation takes place).

I may not be catching all the issues here. I know what you mean by sub-network
connections (SNPs) and their recursive nature. But why do you think this is
not supported by current bundling and hierarchy concepts at IETF?

> --Routing controller (RC) is the network component that provides the
> routing information, including route dissemination, route determination,
> route table update, etc. Three models of routing has been defined:
> hierarchical, source-based and step-by-step. As part of the routing
> definition, a "routing area" is defined to support
> multi-level/hierarchical routing domains. This is very similar (maybe
> identical?) to the OSPF/BGP separation of roles.
>

Agreed that RC is GMPLS 'routing' component. As you know step-by-step
and source-based are supported currently by IETF. Some work is
going on on hierarchical (inter-area, SRG etc.). Hope we cover all the cases
needed for the hierarchical requirements here.

>
> NOTE that these are all logical components (what ITU calls a
> computational view of the control plane), with certain distribution
> assumed (what ITU calls an engineering view of the control plane).
> Different implementations of these components may have, e.g., CallC, CC
> and LRM all in one "box" while another implementation may have CallC in
> one box and CC, LRM and RC in another box. However, the functionality is
> equivalant. Only difference is in terms of which interfaces have been
> exposed and becomes external (that is standardizable).
>

I see. Why don't we concentrate on this topic and discuss what are the
possible combinations and advantages? Coming from the router world
I belive these should be internal to increase the efficiency of operation.

>
> Now to how different or similar is ASON/G.dcm with GMPLS. In terms of
> the information mapping and message mapping between them, I would say
> they are very close to each other. For example, when ASON/G.dcm
> discusses setup/release operations, it views the transport resources as
> an "abstract" entity called SNP (subnetwork point). If you are familiar
> with management objects, the SNP is very similar to SNTP (subnetwork
> termination point). Where SNTP provides the management system with a
> view of the underlying transport resources (CTP or TTP or simply TP),
> the SNP provides the control plane with a view of the underlying
> transport resources. As such these SNP and SNPP (SNP pools which is an
> aggregation of the SNPs into a logical "bundle" based on some policy or
> provisioned constraints) is used in setting up a connection. The
> SNP/SNPP provides an abstraction barrier between physical resources and
> logical resources and is provided on a layer basis (i.e., SNP ID
> information for a STS-1 layer is independent of the SNP ID information
> for a STS-3c layer is independent of the SNP ID information for a ODU1
> layer).
>

Agreed with the concepts. It was tough to read CCITT documents in 1990
and it is tough to read ITU documents now :-) (pun intended). They are
very formal documents and cover all the cases. But this is not an issue for a
discussion I hope.

> The other difference is that ASON/G.dcm deals with abstract "names" in
> terms of specifying relevant endpoints. This is simply a "protocol
> neutral" aspect of addresses used in GMPLS, where GMPLS assumes IPv4 and
> IPv6, G.dcm does not assume any addressing scheme. This is not
> inconsistent, only different levels of specification. One of the "names"
> defined in ASON/G.dcm is a "call name" which is a reference to the call.
> IETF GMPLS I believe "sort-of" supports this. Call name is essentially a
> globally unique identifier that identifies the call. IETF GMPLS also
> provides a globally unique identifier in the form of SESSION and
> SENDER_TEMPLATE (for RSVP-TE).
>

My opinion on addresseing:
IETF may be interested in IPv4 or IPv6 address space for reasons that it can
control the allocation and there was no need to use other address space. It is
a good idea from the deplyoment point of view also. Please do not crusify
me for this.

With your observations on call naming support in GMPLS... naming is not
an issue with GMPLS.

>
> There are also capabilities described in GMPLS that is currently not
> specified by the ASON/G.dcm. This includes the capabilities supported by
> the Admin_Status object (turning on/off monitoring), and the multiplier
> parameter within the SONET/SDH SENDER_TSPEC/FLOWSPEC object. For
> example, many of the parameters that support the SONET/SDH connection
> (such as what signal type, encoding type, NCC, NVC) are implied
> information in ASON/G.dcm since they are layer information. These
> parameters in GMPLS may be thought of as an implementation of the layer
> information for the specific protocol.
>

So are you are saying is GMPLS has more than required? This cannot be
a drawback in the worst case :-)

A comment on the additional parameters...  you are assuming that a layer
boundary is a domain boundary and there is no need to calculate a TE
path through these boundaries. Is this a valid assumption?

>
> GMPLS RSVP-TE is a soft-state protocol, CR-LDP is more a hard-state
> protocol. ASON/G.dcm does not specify whether the protocol needs to be
> soft-state or hard-state. It discusses what are the behaviours and how
> these "systems" may recover from problems. It also provides a high-level
> state transition diagram on the operation of the signaling mechanism.
>  From this viewpoint, I also don't see too much inconsistency. Of
> course, I haven't done any analysis/comparison. If anyone is interested
> doing this it let me know!
>

So this is also a non-issue.

>
>   The first stage of the ITU specification for the ASON work is nearing
> completion. The next stage is to start work on the protocol specific
> implementations of the ASON model. At the current ITU meeting, we
> already have United Kingdom (presented by British Telecom) bring in
> contribution requesting to use PNNI as A protocol for supporting ASON.
> This was also supported by other carriers. The ITU has now opened the
> floor to any other protocols to be submitted as well.
>
> So if people want to see GMPLS considered as one of the protocols for
> ASON, someone needs to submit this to the ITU. Currently the decision is
> that if any protocols meets the requirements outlined in ASON and G.dcm,
> then they will be considered (i.e., any protocol). There were some
> interest shown in the meeting to bringing in GMPLS.
>

Well GMPLS is satisfying most of the ASON requirements. Why not this is a
potential candiadate for submission at ITU? May be the WG chairs have a
plan on how to proceed.

>
> Well, I hope this provides enough of a summary to help the discussions
> along.
>

Thank you for the summary Zhi. Please contribute to this mail thread to
narrow down the issues.

Regards,

sudheer

>
> Zhi
>
> Sudheer Dharanikota wrote:
>
> > Hi Zhi:
> >
> > Zhi-Wei Lin wrote:
> >
> >
> >> From what I understand G.ason and G.dcm is developed to describe the
> >>process and the minimal requirements needed to support a basic switched
> >>transport service. GMPLS is a protocol specific implementation that will
> >>likely meet many of the requirements, and may have some minor areas that
> >>it does not meet. Then the question to ask (as with any requirements and
> >>architecture work -- I'm sure we all have architects in our company) is:
> >>how critical are the requirements that may not be met and what changes
> >>are needed to GMPLS (if any) in order to meet them?
> >>
> >>
> >
> > It may be a good idea to explain where GMPLS is lacking in meeting ASON
> > and DCM requirements. YOu, being involved in this process, is the best
> > person to articulate the major drawbacks. WHy don't you spend a minute in
> > higlighting them.
> >
> > THese discussions are becoming highly non-technical and unproductive. Let us
> > streamline our energy to a common cause - find the enhancements needed to
> > accomodate ASON architecture.
> >
> > Regards,
> >
> > sudheer
> >
> >
> >>
> >

Delivery-date: Thu, 25 Oct 2001 09:23:25 -0700
From: [email-masked]
To: Zhi-Wei Lin <[email-masked]>
cc: Maarten Vissers <[email-masked]>, Sudheer Dharanikota <[email-masked]>, [email-masked]
Date: Thu, 25 Oct 2001 17:59:06 +0100
Subject: Re: Moving right along ...

Zhi,

I am a little reticent to deepen this discussion on the list. It is difficult to avoid appearing like prevaricating philosophers. I can almost hear those CCAMP guys yawning from here. Please feel free to press delete if this is not for you. See discussion
in line.

regards,

Mike Sexton

Zhi-Wei Lin <[email-masked]> on 25/10/2001 12:04:19

                                                              
 To:      Michael J SEXTON/GB/ALCATEL@ALCATEL                 
                                                              
 cc:      Maarten Vissers <[email-masked]>, Sudheer      
          Dharanikota <[email-masked]>, [email-masked] 

                                                              
 Subject: Re: Moving right along ...                          

Hi Mike,

I agree with most of what you said. I think the forwarding adjacency is
more similar to the serial composed link connections (or serial
compound links) than to support from a trail. There is no requirement
for forwarding adjacencies to relate to trails (at least I don't think so).

MS: Not exactly so but I'd rather pass this one up for now as it may get us in even deeper.

And yes, I fully agree that the inter-layer piece is the interesting
piece. I believe Maarten has presented this in several places as the
network engineering function (what you called the "local matter") as
subject to policy control (very operator business model dependent).

MS: I did not follow this thread very closely but my understanding was that Maarten was essentially dividing what IETF call traffic engineering into two sub-domains: network engineering choosing optimum paths within a layer (LSP region) and traffic
engineering - assigning traffic selectively to one or more alternative paths available at the point the traffic is applied. At a layer boundary this implies some sort of daemon capable of making assignment decisions which may in turn be dependent on
policies implemented locally or impressed remotely. Is this in line with your interpretation.

As for the hierarchy and the layer model, I think the hierarchical model
of MPLS is more atuned to the sub-network partition (and sub-network
recursion) which is within a layer. I'm not sure that the hierarchy was
defined for layer network (although I don't see why it can't apply either).

MS: In G.805 the layer network hierarchical relationship is n:n, client:server (ie a network layer can be served by one or more servers and may in turn support one or more clients. This implies a precedence: client connections can only be provided in the
context of a server (logical) topology. The server topology is generated by the connections created between the edges of the server and so on ad infinitum. This is exactly the recursive relationship described rather more tersely in
draft-ietf-mpls-lsp-hierarchy-03.txt para 6.2. The partitioning relationship between partitioning "levels" (we normally try and avoid overusing the term layer in this context) is 1:n, superior:subordinate. The most superior subnetwork includes (contains) 1
to n subnetworks; each of these in turn includes 1 to n subnetworks and so on recursively until the subordinate subnetwork coincides exactly with a single node (matrix, forwarding engine etc) at which point the recursion efrfectively terminates. In both
GMPLS and G.805 partitioning is considered essentially an administrative activity and local policies are again cited. In practice there are externally imposed limits imposed on administrative choice (eg it is difficult to justify creating a subnetwork
which ignores the self selected boundaries imposed by protected subnetworks (eg rings)). Similarly routing domain boundaries must be honoured.

Having clarified that (I hope) it must be noted that subnetworks at any level map onto 1 or more server "layer networks". For example a subnetwork partition of an MPLS layer (eg PSC3) may be partially supported over VC-4/PoS (TSC) and partially over WDM
(LSC). These are indeed subnetworks in VC-4 and WDM layers respectively and may be offering transit services for other adjacent subnetworks in the same layers. However of particular interest here is that they are also layer network segments containing all
the points at which interlayer services are offered to this particular client. These are all the points where multiplexing choices are made, traffic is offered (or rejected) in short all the issues currently in the realm of local policy with no standard
support for bringing this under control. This was the main point I was making. There is nothing about the layered model which proscribes interlayer control interfaces and connection control planes in multiple layers which was a possible inference from
Maarten's note. I am not sure precisely whether ASON has limited its scope in this manner but if so I suppose this can be seen in the context of prioritising and phasing results as G-MPLS has also limited scope rather than an interdictory prosciption.

For completeness I should add one further comment. Although the ID referred to above and G-MPLS in general leaves the interlayer issue open as covered by "local implementation" there is a strong suggestion of a default behaviour in which a new server
FA-LSP is opened (request to the server) if there are no further link resources available for the recommended next hop and that further more this LSP is routed along the shortest path indicated by the IGP which is subsequently used until it in turn
exhausts. This exploits the unique property of shortest path trees in distributed route computation which also works across layer boundaries.

Now in terms of the layer model itself, I think (as I said many times)
that the problem is mainly in how people interpret the text in these
documents. That is why (my little rambling again) I think we need to add
text to clarify some of these concepts...people don't seem to want to
add clarifying text though...sigh...

Zhi

[email-masked] wrote:

 >
 > Maarten,
 >
 > In the interests of reconciliation consider the following:
 >
 > ASON and G-MPLS are both post hoc conceptual models describing the
 > same physical and logical network. The objectives of automation
 > through signalling are broadly similar. Therefore it would be
 > surprising indeed if the solutions were widely different. ASON is
 > indeed based on the layered model of G.805 and deals with layering
 > issues up-front. GMPLS is derived from the Internet model which
 > regards the physical layer as flat. When real world layering is
 > encountered it is dealt with by refinements many of which appear in
 >  draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source
 > documents from which G-MPLS inherits. Here LSP regions are defined
 > in 6.2 which are as near as I can tell exactly equivalent to G.805
 > layer networks. Further, precedence rules between layers are
 > established with the clear implication that a higher layer cannot
 > be configured until the appropriate resources in the lower layer
 > have been instantiated. The manner in which this may be done is
 > considered a "local matter". The example given indicates that a
 > Forwarding Adjacency (equivalent to a G.805 link supported by one
 > or more trails (LSPs) in the server layer) may be initiated in
 > various ways including from an external manager or another
 > (adjacent) LSR. Thus the example you gave of a VC-1x layer being
 > set up by signalling and VC-4 layer being set up by an external
 > planning/management is certainly a valid implementation within the
 > scope of the G-MPLS solution. By the same token it is undesirable
 > (and anyway will not be possible) to confine signalling to certain
 > layers while reserving others for management through a standard.
 > Operators will want to make such important architectural choices on
 >  the basis of optimising their own operation. Once you have agreed
 > on a signalling protocol to create connections within a layer
 > network it is generically applicable to any layer network. Of
 > course making such an implementation choice (ie management for
 > VC-4, signalling for VC-1x) is an example of the "local policies"
 > mentioned above. Such choices frequently appear as part of some
 > sort of application specific profile or applications framework on
 > top of the base generic standard. Note this sort of profiling (if
 > that is the correct term) is generally needed to ensure
 > interworking amongst elements which implement the same generic
 > standard.
 >
 > On the last occasion that we studied application of signalling for
 > transport networks in ITU (over 10 years ago at the time G.805 was
 > first issued) we had concluded that connection set-up within a
 > layer was the easy part ie there were several well established
 > candidates to choose from (B-ISUP was the favorite. Neither PNNI
 > nor RSVP existed at that time. ISIS had already been adopted for
 > DCN in SDH and thus provided basic neighbour discovery and xSPF
 > computation if required). The major new problem to resolve for
 > multi-layer transport networks was indeed considered to be the
 > desired behaviour at inter-layer boundaries. It seems that both
 > initiatives have sidelined this issue as out of scope for the time
 > being.
 >
 > regards,
 >
 > Mike Sexton
 >
 >
 >
 >
 >
 >
 >
 > Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38
 >
 >
 >
 > To:      Sudheer Dharanikota <[email-masked]>
 >
 > cc:      [email-masked](bcc: Michael J
SEXTON/GB/ALCATEL)
 >
 >
 >
 >
 > Subject: Re: Moving right along ...
 >
 >
 >
 >
 >
 >
 > Sudheer,
 >
 > Another issue is ...
 >
 > - ASON is layer network based, GMPLS is not
 >
 > i.e. a request for a connection within ASON is treated within the
 > boundaries of one layer network (e.g. within the boundaries of a
 > VT1.5/VC-11 layer network, or within the boundaries of a
 > STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is
 > processed within the VT1.5/VC-11 layer network, using existing
VT1.5/VC-11
 >  links (GMPLS: link bundles). If there is not enough capacity  in
 > the VT1.5/VC-11 links to support the request, the call fails. There
 >  is no "hidden" set up of a STS-1 or VC-4 trail supporting an
 > additional VT/LOVC link or extending an existing VT/LOVC link. The
 > set up of an additional STS-1 or VC-4 trail is supported within the
 >  scope of network planning and/or network engineering. This is
 > separated from the connection set up.
 >
 > Regards,
 >
 > Maarten
 >
 > Sudheer Dharanikota wrote:
 >
 >> Hi Maarten:
 >>
 >> Maarten Vissers wrote:
 >>
 >>
 >>> Sudheer,
 >>>
 >>> At the moment I am unable to briefly summarize the differences
 >>> between GMPLS and ASON. I was working from the perception that
 >>> GMPLS could be one of the protocols supporting ASON. The
 >>> technical comments I made during the last 10 months were based
 >>> on this perception. Also the last comment describing the
 >>> concept of serial compound link had this basis. Reading Yanhe's
 >>>  reply I had the impression that GMPLS is able to support
 >>> serial compound links, but reading Eric's reply I got the
 >>> opposite impression. Furthermore being very surprised by Eric's
 >>>  reaction on a pure technical issue, I composed a few
 >>> challenging words to attrack more people to participate in the
 >>>  discussion... :-)
 >>>
 >> I see one of the issue here being ...
 >>
 >> - Does GMPLS support serial compound links?
 >>
 >> Let us enumerate few more questions and move the discussion to a
 >> technical level again, we need participation especially from the
 >> folks who are involved in ASON architecture work.
 >>
 >>
 >>> Being impressed by the few hundred people attending the last
 >>> ccamp sessions in London, I am surprised by the low percentage
 >>> of those people being actively contributing to the
 >>> correspondence. It can't be the case that only a handful of people
 >>>  have an opinion on these matters... and I believe the
 >>> discussions would stay technical if more people express their
 >>> opinion... there would not be a yes/no game between just a few
 >>> people.
 >>>
 >>>
 >> I thought this is how most of the standards meetings work. 5 %
 >> work, 95 % try to gather industry intelligence ( :-) ) either by
 >> attending IETF or by following
 >>
 >> the mailing list.
 >>
 >>
 >>> With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it
 >>> will be possible to start an evaluation of GMPLS as a specific
 >>> protocol for ASON. As indicated in a previous email from Steve
 >>> Trowbridge, ITU-T will make those ASON documents available to
 >>> IETF so we can jointly work this evaluation.
 >>>
 >>>
 >> Most of these documents are available on the t1x1 site. But what
 >> we need here is the "delta" that is missing between ASON
 >> architecture and the view of GMPLS architecture. Can you help us
 >> with this? We may start with a short list...
 >>
 >>
 >>> The approval of the current ASON recommendations is just a first
 >>>  step within the larger ASON task. Work is started on other
 >>> elements of ASON (G.rtg (routing), G.lm (link management) and
 >>> pnni based specific protocol as an implementation of the
 >>> protocol neutral specification in G.7713)),  discussions are
 >>> started identifying further ASON elements, and work to extend
 >>> G.8080 is planned to start after this SG15 meeting.
 >>>
 >>>
 >> Obviously GMPLS is a potential candidate to solve the ASON issues.
 >>  It may be ahead of its time as far as ITU and ANSI are
 >> concerned. So let us ammend or modify it to the ITU view on the
 >> transport control plane.
 >>
 >> Regards,
 >>
 >> sudheer
 >>
 >>
 >>> Up to so far... {time to shut down my computer and go to the
 >>> concert hall in Geneva... time to relax after a week and a half
 >>>  of hectic work over here...}
 >>>
 >>> Regards,
 >>>
 >>> Maarten
 >>>
 >>> Sudheer Dharanikota wrote:
 >>>
 >>>> Hi Marteen:
 >>>>
 >>>> Can you briefly summarize the differences you see between GMPLS
 >>>>  architecture and ASON architecture? This has been asked by
 >>>> many of the folks at IETF.
 >>>>
 >>>> Regards,
 >>>>
 >>>> sudheer
 >>>>
 >>>> PS: I thought these mails were about label format and suddenly this
 >>>>  is turning into an ITU versus IETF discussion :-(
 >>>>
 >>>> Part 1.1
 >>>>
 >>>> Content-Type:
 >>>>
 >>>> text/plain
 >>>>
 >>>>
 >>>>
------------------------------------------------------------------------
 >>>>

 >>>> mvissers.vcf
 >>>>
 >>>> Content-Type:
 >>>>
 >>>> application/octet-stream Content-Encoding:
 >>>>
 >>>> base64
 >>>>
 >>>>

Delivery-date: Thu, 25 Oct 2001 09:12:16 -0700
Date: Thu, 25 Oct 2001 12:05:17 -0400
To: [email-masked]
From: Baktha Muralidharan <[email-masked]>
Subject: Comments on LMP MIB
Cc: [email-masked], [email-masked], Thomas Nadeau <[email-masked]>, [email-masked]

--=====================_9978528==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hello,
           My feedback comments are prefixed "BM>"

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

7.5.  lmpLinkVerificationTable

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

BM> Add "Augments lmpTeLinkTable"

----------

7.7.  lmpDataBearingLinkPerfTable

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

BM> Add "Augments lmpDataBearingLinkTable"

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

8.  Example of LMP Control Channel Setup

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

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

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

BM> Do we mean administrative state?

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

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

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

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

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

lmpCcHelloIntervalDefaultMin

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

lmpCcHelloIntervalDefaultMax

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

lmpCcHelloDeadIntervalDefaultMin

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

lmpCcHelloDeadIntervalDefaultMax

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

lmpCcHelloDeadIntervalDefault OBJECT-TYPE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BM> From an LMP perspective, the "member data links" of a TE Links need
BM> to be known.. I realize that this information is available from the
BM> bundling MIB.. It may be handy to add an object to the data bearing
BM> link table to store the TE Link ?
------------------
BM> Along the lines of TE Link and CC up/down traps, perhaps we should have
BM> a trap to notify user when a data bearing link is transitioned to "down"
BM> state due to link verification failure. Note that this information is not
BM> obtainable from link up/down trap of underlying interface
===========================================
--=====================_9978528==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Courier New, Courier">Hello,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My feedback
comments are prefixed &quot;BM&gt;&quot;<br>
<br>
/Baktha<br>
======================================================<br>
<br>
7.5.&nbsp; lmpLinkVerificationTable<br>
<br>
&nbsp;&nbsp; This table represents the link verification parameters
associated<br>
&nbsp;&nbsp; with the TE links.<br>
<br>
BM&gt; Add &quot;Augments lmpTeLinkTable&quot;<br>
<br>
----------<br>
<br>
7.7.&nbsp; lmpDataBearingLinkPerfTable<br>
<br>
&nbsp;&nbsp; This table contains the objects to measure the LMP
performance of<br>
&nbsp;&nbsp; data-bearing links and is an AUGMENT to the
lmpDataBearingLinkTable.<br>
<br>
BM&gt; Add &quot;Augments lmpDataBearingLinkTable&quot;<br>
<br>
------------<br>
<br>
8.&nbsp; Example of LMP Control Channel Setup<br>
<br>
&nbsp;&nbsp; In this section we provide a brief example of using the
MIB<br>
&nbsp;&nbsp; objects described in section 11 to set up an LMP control
channel.<br>
&nbsp;&nbsp; While this example is not meant to illustrate every nuance
of the<br>
&nbsp;&nbsp; MIB, it is intended as an aid to understanding some of the
key<br>
&nbsp;&nbsp; concepts. It is meant to be read after going through the MIB
itself.<br>
<br>
<br>
BM&gt; Should read &quot;objects desribed in section 10&quot;<br>
----------------<br>
<br>
lmpAdminStatus OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER {
up(1), down(2) }<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-write<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The desired operational status
of LMP on the node.&quot;<br>
&nbsp;&nbsp; DEFVAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { up 
}<br>
&nbsp;&nbsp; ::= { lmpObjects 1 }<br>
<br>
BM&gt; Do we mean administrative state?<br>
<br>
----------------------<br>
<br>
lmpNbrTable OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE OF
LmpNbrEntry<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; not-accessible<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This table specifies the
neighbor node to which control channels<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be 
established.&quot;<br>
&nbsp;&nbsp; ::= { lmpObjects 2 }<br>
<br>
BM&gt; neighbor node(s)<br>
----------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
lmpNbrRetransmitInterval&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= 10<br>
<br>
Wouldn't want this to be the same for link verification, summary
etc.<br>
----------------<br>
lmpNbrAdminStatus OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER {
up(1), down(2) }<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The desired operational status
of LMP to this remote node.&quot;<br>
&nbsp;&nbsp; ::= { lmpNbrEntry 3 }<br>
<br>
BM&gt; Do we mean desired admin. state?<br>
--------------------<br>
<br>
lmpCcHelloIntervalDefaultMin<br>
<br>
BM&gt; Presumably, this serves as the default value for
lmpCcHelloIntervalMin?<br>
<br>
lmpCcHelloIntervalDefaultMax<br>
<br>
BM&gt; Presumably, this serves as the default value for
lmpCcHelloIntervalMax?<br>
<br>
lmpCcHelloDeadIntervalDefaultMin<br>
<br>
BM&gt; Presumably, this serves as the default value for
lmpCcHelloDeadIntervalMin? <br>
<br>
lmpCcHelloDeadIntervalDefaultMax<br>
<br>
BM&gt; Presumably, this serves as the default value for
lmpCcHelloDeadIntervalMax?<br>
------------------------<br>
<br>
lmpCcHelloDeadIntervalDefault OBJECT-TYPE<br>
<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LmpInterval<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-write<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This object specifies the
default HelloDeadInterval parameter to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use in the Hello protocol
keep-alive phase. It indicates how long<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a device should wait before
declaring the control channel dead.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The HelloDeadInterval
parameter must be greater than the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HelloInterval parameter and
should be at least three times the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value of
HelloInterval.&quot;<br>
<br>
BM&gt; Remove the part &quot;must be greated than the HelloInterval
parameter and&quot;<br>
-----------------<br>
<br>
lmpCcIsIf OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TruthValue<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Denotes whether or not this
control channel corresponds to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an interface represented in
the interfaces group table.&quot;<br>
&nbsp;&nbsp; ::= { lmpControlChannelEntry 3 }<br>
<br>
BM&gt; Why this additional object?. Why not require that there be a
valid<br>
BM&gt; lmpCcUnderlyingIfIndex for CC's rowstatsus to go into
&quot;active&quot; state<br>
BM&gt; and that in the absence of a valid underlying interface, the
CC<br>
BM&gt; will be in the &quot;notReady&quot; state?<br>
BM&gt;<br>
BM&gt; In the TE LInk case, we require that an entry of type &quot;TE
Link&quot; exist<br>
BM&gt; BEFORE the corresponding teLinkEntry is created... Why not do the
same<br>
BM&gt; with CC?. After all, the CC is not usable until a real
underlying<br>
BM&gt; interface is defined!<br>
<br>
----------------<br>
<br>
lmpCcNbrNodeId OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
NodeID<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-only<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This is the Node ID of the
control channel remote node.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This value gets created by the
node when a Config message<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is received or when an
outgoing Config message is acknowledged<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the remote 
node.&quot;<br>
&nbsp;&nbsp; ::= { lmpControlChannelEntry 4 }<br>
<br>
BM&gt; Should NOT be a read-only. Neighbor needs to be specified.
Consider<br>
BM&gt; an out-of-band Control channel over a shared ethernet LAN
interface-<br>
BM&gt; If neighbor is not specified, how will hello config be transmitted
to<br>
BM&gt; a neighbor?<br>
BM&gt; Only in the in-band (and with point to point link) case can the
neighbor<br>
BM&gt; IP address can be learnt!<br>
-----------------<br>
lmpRemoteCcId OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Unsigned32<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-only<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This value represents the
remote control channel identifier. It is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; determined during the
negotiation phase. A value<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of zero means that the remote
control channel identifier has not<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; yet been assigned.&quot;<br>
&nbsp;&nbsp; ::= { lmpControlChannelEntry 5 }<br>
<br>
BM&gt; Should read &quot;A value of zero means that the remote CC ID has
not yet been learnt&quot;<br>
<br>
----------------------<br>
<br>
lmpCcSetupRole OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER {
active(1), passive(2) }<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The role that this node should
take during establishment of this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; control channel. An active
node will initiate establishment. A<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passive node will wait for the
remote node to initiate. A pair<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of nodes that both take the
passive role will never establish<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; communications.&quot;<br>
&nbsp;&nbsp; DEFVAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { active
}<br>
<br>
Well, this is not consistent with the LMP draft, which defines automatic
contention<br>
resolution mechanism based on node ID. Besides, this is prone to
human(operator)-error.<br>
<br>
The LMP draft reads:<br>
&nbsp; &quot;To avoid ambiguities, the node with the higher Node Id wins
<br>
&nbsp;&nbsp; the contention; the node with the lower Node Id MUST stop
<br>
&nbsp;&nbsp; transmitting the Config message and respond to the Config
message it <br>
&nbsp;&nbsp; received.&quot;<br>
------------------------<br>
lmpCcAdminStatus OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER {
up(1), down(2) }<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The desired operational status
of this control channel.&quot;<br>
&nbsp;&nbsp; ::= { lmpControlChannelEntry 17 }<br>
<br>
BM&gt; Should read &quot;desired admin state&quot;<br>
BM&gt; Why is the Admin Status of CC not tied to admin status of 
the<br>
BM&gt; underlying interface?<br>
<br>
---------------------<br>
lmpTeLinkOperStatus OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER {
up(1), down(2), testing(3), degraded(4) }<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-only<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The actual operational status
of this TE link. The status<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is set to testing when the TE
link is performing link<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verification. A degraded
status indicates that the TE link<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cannot provide the provisioned
protection level, but yet,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; there is no disruption of
service. For instance, if the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; protection type is 1+1 and one
link is down, the TE link<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; still carries the requested
amount of data traffic, but<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this traffic is not protected
anymore.&quot;<br>
&nbsp;&nbsp; ::= { lmpTeLinkEntry 5 }<br>
<br>
BM&gt; This should reflect the Finite state machine states, defined in
the LMP draft,<br>
BM&gt; for TE Links.<br>
------------------------------<br>
lmpDataBearingLinkEntry OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LmpDataBearingLinkEntry<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; not-accessible<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;An entry in this table exists
for each ifEntry that represents<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a data-bearing link. An
ifEntry with an ifIndex must exist<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; before the corresponding
lmpDataBearingLinkEntry is created.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If an entry representing the
data-bearing link is destroyed in<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the ifTable, then so is the
corresponding entry in the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lmpDataBearingLinkTable. The
administrative status value is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; controlled from the ifEntry.
The index to this table also<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to get information in the
dataBearingChannelTable<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [BUNDLE-MIB].&quot;<br>
&nbsp;&nbsp; INDEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {
ifIndex }<br>
<br>
BM&gt; Why is this not an &quot;AUGMENT&quot; to ifEntry?<br>
-------------<br>
<br>
BM&gt; From an LMP perspective, the &quot;member data links&quot; of a TE
Links need<br>
BM&gt; to be known.. I realize that this information is available from
the<br>
BM&gt; bundling MIB.. It may be handy to add an object to the data
bearing<br>
BM&gt; link table to store the TE Link ?<br>
------------------<br>
BM&gt; Along the lines of TE Link and CC up/down traps, perhaps we should
have<br>
BM&gt; a trap to notify user when a data bearing link is transitioned to
&quot;down&quot;<br>
BM&gt; state due to link verification failure. Note that this information
is not<br>
BM&gt; obtainable from link up/down trap of underlying interface<br>
===========================================</font></html>

--=====================_9978528==_.ALT--

Delivery-date: Thu, 25 Oct 2001 08:09:31 -0700
From: Fugui Wang <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>, Fugui Wang <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Questions about draft-ietf-ccamp-lmp-mib-00.txt
Date: Thu, 25 Oct 2001 11:06:07 -0400

Martin,

Thanks for the clarification. But isn't 
lmpDataBearingLinkEncodingType also redundant with
dataBearingChannelEncodingType and teLinkEncodingType 
in the link bundling MIB? 

Thanks,
Fugui

-----Original Message-----
From: Martin Dubuc [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 2:09 PM
To: Fugui Wang
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Questions about draft-ietf-ccamp-lmp-mib-00.txt

Fugui,

The lmpRemoteTeLinkId and lmpRemoteTeLinkType was removed from the
latest LMP MIB because it was redundant with information stored in the
link bundling MIB (see
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt).
The link bundling MIB contains a TE link table (teLinkTable) which
captures the information you are looking for. The remote TE link type is
found in the  teLinkNumberingType object and the remote TE link
identifier is either teLinkRemoteIpAddr or teLinkIncomingIfId depending
on whether or not the TE link is numbered or unnumbered.

Regards,

Martin

-----Original Message-----
From: Fugui Wang [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 12:08 PM
To: Martin Dubuc; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Questions about draft-ietf-ccamp-lmp-mib-00.txt

I noticed that lmpRemoteTeLinkId and lmpRemoteTeLinkType were
taken away from the TE Link Table in this version. Is there
any special reason for that? In the latest LMP draft
draft-ietf-ccamp-lmp-01.txt, when we do link verification or
link summary, we still need the remote TE link ID infomation.
Would you suggest that we store the remote TE link ID in other
places instead of in the TE link Table?

Thanks,
Fugui

Delivery-date: Thu, 25 Oct 2001 07:49:19 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 25 Oct 2001 15:46:23 +0100

Hi Mike,

you wrote 25 October 2001 15:26
> I am not sure that it is appropriate to get into business 
> model issues on this list.
NH=> Agreed in general....but if one is doing something technical one
assumes there is a problem it is solving.  I am showing that the 'business
problem' is not at all clear (even if we had loads of money to spend at the
moment)....irrespective of the right/wrongs of the particular 'technical
solution'.   

regards, Neil

Delivery-date: Thu, 25 Oct 2001 06:53:02 -0700
Date: Thu, 25 Oct 2001 09:50:25 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, Sudheer Dharanikota <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi Eric,

Let's not say which one is sub-set of which other one. As I mentioned, 
ASON and GMPLS (or ASON and PNNI, but from what I understand IETF 
doesn't do PNNI so this issue is not discussed here) are complementary.

Let's treat it that way and move forward by trying to align the two so 
that the industry will benefit (my little rambling again).

However, there are still some issues of GMPLS technology specific that 
still needs to be resolved. Those are not ASON issues, since ASON treats 
these as generic "labels". From what I understand several people are 
still discussing this (I use "discussing" broadly...it sounds 
better)...I think you know my position and several people's position on 
this...

Zhi

Mannie, Eric wrote:

> Hello Maarten,
> 
> 
>>ASON is layer network based, GMPLS is not
>>
> 
> Sorry, but you misunderstood how GMPLS works for SDH/SONET.
> 
> GMPLS supports *all* approaches that you described: "layer network based"
> and/or "hidden set up of a STS-1 or VC-4 trail supporting an additional
> VT/LOVC link or extending an existing VT/LOVC link".
> 
> The difference between these two approaches is a policy matter and should be
> independent of the protocols. That's what we are doing (made) with GMPLS: we
> are developing a toolbox without specifying (forcing) the policies.
> 
> That's up to the manufacturer to decide which policies he will implement
> (e.g. both) and to the operator to decide which policies he wants to use.
> Policies can even be dynamic and depends on customers. You can even use the
> COPS model to deal with these policies.
> 
> To be more clear, at each switch you could have different policies, at some
> places the call could fails (referring here to you example), at some places
> the call could trigger a "hidden" VC-4. GMPLS doesn't specifies that. An
> operator could operate its network in a pure layer network based approach,
> or using only the other approach or using a mix.
> 
> If you mean that ASON "hardcoded" the policies by limiting the architecture
> and the protocols to the example you gave (layer network based), that's a
> *serious* limitation of ASON (and by the way totally unjustified). Clearly
> from that perspective ASON is a subset of GMPLS. Is it the case ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, October 25, 2001 7:04 AM
> To: Sudheer Dharanikota
> Cc: [email-masked]
> Subject: Re: Moving right along ...
> 
> 
> Sudheer,
> 
> Another issue is ...
> 
> 	- ASON is layer network based, GMPLS is not
> 
> i.e. a request for a connection within ASON is treated within the boundaries
> of
> one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer
> network, or
> within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11
> connection
> request is processed within the VT1.5/VC-11 layer network, using existing
> VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity  in
> the
> VT1.5/VC-11 links to support the request, the call fails. There is no
> "hidden"
> set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or
> extending an existing VT/LOVC link. The set up of an additional STS-1 or
> VC-4
> trail is supported within the scope of network planning and/or network
> engineering. This is separated from the connection set up.
> 
> Regards,
> 
> Maarten
> 
> Sudheer Dharanikota wrote:
> 
>>Hi Maarten:
>>
>>Maarten Vissers wrote:
>>
>>
>>>Sudheer,
>>>
>>>At the moment I am unable to briefly summarize the differences between
>>>
> GMPLS and
> 
>>>ASON. I was working from the perception that GMPLS could be one of the
>>>
> protocols
> 
>>>supporting ASON. The technical comments I made during the last 10 months
>>>
> were
> 
>>>based on this perception. Also the last comment describing the concept
>>>
> of serial
> 
>>>compound link had this basis. Reading Yanhe's reply I had the impression
>>>
> that
> 
>>>GMPLS is able to support serial compound links, but reading Eric's reply
>>>
> I got
> 
>>>the opposite impression. Furthermore being very surprised by Eric's
>>>
> reaction on
> 
>>>a pure technical issue, I composed a few challenging words to attrack
>>>
> more
> 
>>>people to participate in the  discussion... :-)
>>>
>>I see one of the issue here being ...
>>
>>    - Does GMPLS support serial compound links?
>>
>>Let us enumerate few more questions and move the discussion to a technical
>>level again, we need participation especially from the folks who are
>>
> involved
> 
>>in ASON architecture work.
>>
>>
>>>Being impressed by the few hundred people attending the last ccamp
>>>
> sessions in
> 
>>>London, I am surprised by the low percentage of those people being
>>>
> actively
> 
>>>contributing to the correspondence. It can't be the case that only a
>>>
> handful of
> 
>>>people have an opinion on these matters... and I believe the discussions
>>>
> would
> 
>>>stay technical if more people express their opinion... there would not
>>>
> be a
> 
>>>yes/no game between just a few people.
>>>
>>>
>>I thought this is how most of the standards meetings work. 5 % work, 95 %
>>try to gather industry intelligence ( :-) ) either by attending IETF or by
>>
> following
> 
>>the mailing list.
>>
>>
>>>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be
>>>
> possible to
> 
>>>start an evaluation of GMPLS as a specific protocol for ASON. As
>>>
> indicated in a
> 
>>>previous email from Steve Trowbridge, ITU-T will make those ASON
>>>
> documents
> 
>>>available to IETF so we can jointly work this evaluation.
>>>
>>>
>>Most of these documents are available on the t1x1 site. But what we need
>>
> here is
> 
>>the "delta" that is missing between ASON architecture and the view of
>>
> GMPLS
> 
>>architecture. Can you help us with this? We may start with a short list...
>>
>>
>>>The approval of the current ASON recommendations is just a first step
>>>
> within the
> 
>>>larger ASON task. Work is started on other elements of ASON (G.rtg
>>>
> (routing),
> 
>>>G.lm (link management) and pnni based specific protocol as an
>>>
> implementation of
> 
>>>the protocol neutral specification in G.7713)),  discussions are started
>>>identifying further ASON elements, and work to extend G.8080 is planned
>>>
> to start
> 
>>>after this SG15 meeting.
>>>
>>>
>>Obviously GMPLS is a potential candidate to solve the ASON issues. It may
>>
> be
> 
>>ahead of its time as far as ITU and ANSI are concerned. So let us ammend
>>
> or
> 
>>modify it to the ITU view on the transport control plane.
>>
>>Regards,
>>
>>sudheer
>>
>>
>>>Up to so far... {time to shut down my computer and go to the concert
>>>
> hall in
> 
>>>Geneva... time to relax after a week and a half of hectic work over
>>>
> here...}
> 
>>>Regards,
>>>
>>>Maarten
>>>
>>>Sudheer Dharanikota wrote:
>>>
>>>>Hi Marteen:
>>>>
>>>>Can you briefly summarize the differences you see between
>>>>GMPLS architecture and ASON architecture? This has been
>>>>asked by many of the folks at IETF.
>>>>
>>>>Regards,
>>>>
>>>>sudheer
>>>>
>>>>PS: I thought these mails were about label format and suddenly
>>>>this is turning into an ITU versus IETF discussion :-(
>>>>
> 

Delivery-date: Thu, 25 Oct 2001 06:49:48 -0700
From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Date: Thu, 25 Oct 2001 15:25:58 +0100
Subject: RE: Moving right along ...

Neil,

I am not sure that it is appropriate to get into business model issues on this list. I'd have to get my marketing and business development hat on. However below, in line, is a brief response I suggest if you want to pursue this further we do it off list.

regards,

Mike Sexton

[email-masked] on 25/10/2001 11:47:18

                                                              
 To:      Michael J SEXTON/GB/ALCATEL@ALCATEL,                
          [email-masked]                                 
                                                              
 cc:      [email-masked], [email-masked]               

                                                              
 Subject: RE: Moving right along ...                          

Hi Mike.....nice to hear from you and I think you make some good points.
However, I want to pick-up on one aspect you bring up a few times....and
that is 'choice'.  Operators need choice to suit their views on what
is/is-not a viable business case.

MS: Naturally.

For example, we have various client layer networks besides IP to
accommodate, and of particular importance are managed BW services directly
off the L1 fabric, eg VC4 or lambdas say.  However, we can't see any valid
business case for generalised BoD/SVCs services here.....I mean, given
unknown calling/holding statistics just what capacity would one need to
build to to offer a GoS that customers would consider acceptable and that
you could get past finance/products people (esp given current climate)?

MS: The service level differences here are quite subtle. They are for many practical purposes indistinguishable. But, getting back on subject, whether they are implemented with the help of a control plane or through a centralised service management process
will only affect secondary features (eg speed of customer response, performance etc) and these will be more determined by implementation details in either model.

So, on assumption that S-PVC-like services are all that is commercailly
viable (in our opinion at least) then you can ask yourself just what
additional revenues and/or Opex cost reductions are available from
implementating a control-plane solution?  Even this is difficult to justify
given:
-    current NMS approaches (in SDH) can easily cater for current and
foreseeable core trail churn rates;
-    the big costs are in access and laying ducts and installing
physicals....no control-plane solution is going to impact these.

MS: Agreed these are difficult calls to make. However I note that there has been considerable interest in recent times in the developing business of bandwidth brokerage. In just a few years implementations of this business model have progressed from purely
paper contract based introductions between buyers and sellers through Web based service transactions to automatically switched on demand. In the last case the bandwidth broker installs a switch (controlled through SS7) or an optical cross-connect
controlled through service management centre (in future ?) buyers and sellers attach themselves to BB premises via metro fibre links and exchange bandwidth either on a form of spot market (as available) or under an evergrowing variety of more elaborate
contracts (time of day, OVPN, standby for overflow or protection etc). This trend may continue or it may indeed fizzle out.

However, assuming you do decide you want to implement a control-plane
solution in your transport networks then you really ought to be able to
choose the addressing, signalling and routing components on a best-of-breed
basis to suit what you want to do.  They are after all, quite disjoint
components and there are many architectural possibilities.......and this is
what ASON is all about....choice.

MS: This is the basic standardisation dilemma. where is the "right" trade off between choice and efficiency. The modern solution to protect choice is to set off a number of de juro standards and leave them to slug it out in the market place. Those that
retain sufficient flexibility to find their market niche and adapt, survive those that don't don't.

For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
aspects only) + centralised routing approach looks the best commercially for
what we want to do.  Others may argue that the current GMPLS approach suits
them best.  ASON allows this choice.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 25 October 2001 11:49
> To: Maarten Vissers
> Cc: Sudheer Dharanikota; [email-masked]
> Subject: Re: Moving right along ...
>
>
>
>
> Maarten,
>
> In the interests of reconciliation consider the following:
>
> ASON and G-MPLS are both post hoc conceptual models
> describing the same physical and logical network. The
> objectives of automation through signalling are broadly
> similar. Therefore it would be surprising indeed if the
> solutions were widely different. ASON
> is indeed based on the layered model of G.805 and deals with
> layering issues up-front. GMPLS is derived from the Internet
> model which regards the physical layer as flat. When real
> world layering is encountered it is dealt with by refinements
> many of which
> appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one
> of the source documents from which G-MPLS inherits. Here LSP
> regions are defined in 6.2 which are as near as I can tell
> exactly equivalent to G.805 layer networks. Further, precedence rules
> between layers are established with the clear implication
> that a higher layer cannot be configured until the
> appropriate resources in the lower layer have been
> instantiated. The manner in which this may be done is
> considered a "local matter". The example
> given indicates that a Forwarding Adjacency (equivalent to a
> G.805 link supported by one or more trails (LSPs) in the
> server layer) may be initiated in various ways including from
> an external manager or another (adjacent) LSR. Thus the
> example you gave of
> a VC-1x layer being set up by signalling and VC-4 layer being
> set up by an external planning/management is certainly a
> valid implementation within the scope of the G-MPLS solution.
> By the same token it is undesirable (and anyway will not be
> possible) to
> confine signalling to certain layers while reserving others
> for management through a standard. Operators will want to
> make such important architectural choices on the basis of
> optimising their own operation. Once you have agreed on a
> signalling protocol to
> create connections within a layer network it is generically
> applicable to any layer network. Of course making such an
> implementation choice (ie management for VC-4, signalling for
> VC-1x) is an example of the "local policies" mentioned above.
> Such choices
> frequently appear as part of some sort of application
> specific profile or applications framework on top of the base
> generic standard. Note this sort of profiling (if that is the
> correct term) is
> generally needed to ensure interworking amongst elements
> which implement the same generic standard.
>
> On the last occasion that we studied application of
> signalling for transport networks in ITU (over 10 years ago
> at the time G.805 was first issued) we had concluded that
> connection set-up within a layer was the easy part ie there
> were several well
> established candidates to choose from (B-ISUP was the
> favorite. Neither PNNI nor RSVP existed at that time. ISIS
> had already been adopted for DCN in SDH and thus provided
> basic neighbour discovery and xSPF computation if required).
> The major new problem to
> resolve for multi-layer transport networks was indeed
> considered to be the desired behaviour at inter-layer
> boundaries. It seems that both initiatives have sidelined
> this issue as out of scope for the time being.
>
> regards,
>
> Mike Sexton
>
>
>
>
>
>
>
> Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38
>
>
>
>  To:      Sudheer Dharanikota <[email-masked]>
>
>  cc:      [email-masked](bcc: Michael J
>           SEXTON/GB/ALCATEL)
>
>
>
>  Subject: Re: Moving right along ...
>
>
>
>
>
>
> Sudheer,
>
> Another issue is ...
>
>      - ASON is layer network based, GMPLS is not
>
> i.e. a request for a connection within ASON is treated within
> the boundaries of
> one layer network (e.g. within the boundaries of a
> VT1.5/VC-11 layer network, or
> within the boundaries of a STS-3c/VC-4 layer network). A
> VT1.5/VC-11 connection
> request is processed within the VT1.5/VC-11 layer network,
> using existing
> VT1.5/VC-11 links (GMPLS: link bundles). If there is not
> enough capacity  in the
> VT1.5/VC-11 links to support the request, the call fails.
> There is no "hidden"
> set up of a STS-1 or VC-4 trail supporting an additional
> VT/LOVC link or
> extending an existing VT/LOVC link. The set up of an
> additional STS-1 or VC-4
> trail is supported within the scope of network planning and/or network
> engineering. This is separated from the connection set up.
>
> Regards,
>
> Maarten
>
> Sudheer Dharanikota wrote:
> >
> > Hi Maarten:
> >
> > Maarten Vissers wrote:
> >
> > > Sudheer,
> > >
> > > At the moment I am unable to briefly summarize the
> differences between GMPLS and
> > > ASON. I was working from the perception that GMPLS could
> be one of the protocols
> > > supporting ASON. The technical comments I made during the
> last 10 months were
> > > based on this perception. Also the last comment
> describing the concept of serial
> > > compound link had this basis. Reading Yanhe's reply I had
> the impression that
> > > GMPLS is able to support serial compound links, but
> reading Eric's reply I got
> > > the opposite impression. Furthermore being very surprised
> by Eric's reaction on
> > > a pure technical issue, I composed a few challenging
> words to attrack more
> > > people to participate in the  discussion... :-)
> >
> > I see one of the issue here being ...
> >
> >     - Does GMPLS support serial compound links?
> >
> > Let us enumerate few more questions and move the discussion
> to a technical
> > level again, we need participation especially from the
> folks who are involved
> > in ASON architecture work.
> >
> > >
> > > Being impressed by the few hundred people attending the
> last ccamp sessions in
> > > London, I am surprised by the low percentage of those
> people being actively
> > > contributing to the correspondence. It can't be the case
> that only a handful of
> > > people have an opinion on these matters... and I believe
> the discussions would
> > > stay technical if more people express their opinion...
> there would not be a
> > > yes/no game between just a few people.
> > >
> >
> > I thought this is how most of the standards meetings work.
> 5 % work, 95 %
> > try to gather industry intelligence ( :-) ) either by
> attending IETF or by following
> >
> > the mailing list.
> >
> > >
> > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available
> it will be possible to
> > > start an evaluation of GMPLS as a specific protocol for
> ASON. As indicated in a
> > > previous email from Steve Trowbridge, ITU-T will make
> those ASON documents
> > > available to IETF so we can jointly work this evaluation.
> > >
> >
> > Most of these documents are available on the t1x1 site. But
> what we need here is
> > the "delta" that is missing between ASON architecture and
> the view of GMPLS
> > architecture. Can you help us with this? We may start with
> a short list...
> >
> > >
> > > The approval of the current ASON recommendations is just
> a first step within the
> > > larger ASON task. Work is started on other elements of
> ASON (G.rtg (routing),
> > > G.lm (link management) and pnni based specific protocol
> as an implementation of
> > > the protocol neutral specification in G.7713)),
> discussions are started
> > > identifying further ASON elements, and work to extend
> G.8080 is planned to start
> > > after this SG15 meeting.
> > >
> >
> > Obviously GMPLS is a potential candidate to solve the ASON
> issues. It may be
> > ahead of its time as far as ITU and ANSI are concerned. So
> let us ammend or
> > modify it to the ITU view on the transport control plane.
> >
> > Regards,
> >
> > sudheer
> >
> > >
> > > Up to so far... {time to shut down my computer and go to
> the concert hall in
> > > Geneva... time to relax after a week and a half of hectic
> work over here...}
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Sudheer Dharanikota wrote:
> > > >
> > > > Hi Marteen:
> > > >
> > > > Can you briefly summarize the differences you see between
> > > > GMPLS architecture and ASON architecture? This has been
> > > > asked by many of the folks at IETF.
> > > >
> > > > Regards,
> > > >
> > > > sudheer
> > > >
> > > > PS: I thought these mails were about label format and suddenly
> > > > this is turning into an ITU versus IETF discussion :-(
>

Delivery-date: Thu, 25 Oct 2001 06:20:24 -0700
From: Cheenu Srinivasan <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 09:33:29 -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_000_01C15D59.A1CC7C50
Content-Type: text/plain

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

Cheenu

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

------_=_NextPart_000_01C15D59.A1CC7C50
Content-Type: text/plain;
	name="draft-ietf-mpls-mgmt-overview-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-mpls-mgmt-overview-00.txt"

Network Working Group                                Thomas D. Nadeau
Internet Draft                                    Cisco Systems, Inc.
Category: Informational                                             =20
Expires: April 2002                                 Cheenu Srinivasan
                                                        Alphion Corp.
                                                                    =20
                                                        Adrian Farrel
                                                 Movaz Networks, Inc.
                                                                    =20
                                                         October 2001
                              =20
                              =20
   Multiprotocol Label Switching (MPLS) Management Overview
                              =20
             draft-ietf-mpls-mgmt-overview-00.txt

Status of this Memo
  =20
   This document is an Internet-Draft and is in full
   conformance with all provisions of Section 10 of RFC 2026
   [RFC2026].
  =20
   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.
  =20
   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."
  =20
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  =20
   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.

Table of Contents
    =20
  Abstract .....................................................  2
  1. Introduction ..............................................  2
  2. Terminology ...............................................  2
  3. The SNMP Management Framework .............................  3
  4. MIBs Addressed by the MPLS Management Framework ...........  4
  4.1. MPLS-TC-MIB .............................................  4
  4.2. MPLS-LSR-MIB ............................................  4
  4.2.1. Dependencies ..........................................  4
  4.3. MPLS-LDP-MIB ............................................  5
  4.3.1. Dependencies ..........................................  5
  4.4. MPLS-TE-MIB .............................................  5

Nadeau et al.               Expires April 2002               [Page 1]
=0C
Internet Draft          MPLS Management Overview         October 2001

  4.4.1. Dependencies ..........................................  5
  4.5. MPLS-FTN-MIB ............................................  6
  4.5.1. Dependencies ..........................................  6
  4.6. MPLS-LINK-BUNDLING-MIB ..................................  6
  4.6.1. Dependencies ..........................................  6
  4.7. PPVPN-MPLS-VPN-MIB ......................................  6
  4.7.1. Dependencies ..........................................  7
  5. Dependencies on Other IETF Working Groups .................  7
  5.1. Pseudo Wire Emulation Edge to Edge MIBs .................  7
  5.2. Provider Provisioned Virtual Private Network MIBs .......  7
  5.3. Common Control and Measurement Plane (CCAMP) WG .........  7
  6. Security Considerations ...................................  7
  7. Acknowledgments ...........................................  8
  8. References ................................................  8
  9. Authors' Addresses ........................................ 10
  10. Full Copyright Statement ................................. 11

Abstract
  =20
   This memo describes the Multi-Protocol Label Switching
   (MPLS) [RFC3031] management architecture and the inter-
   relationships between the different management information
   bases (MIBs).

1. Introduction
  =20
   This memo describes the  Management Architecture for Multi-
   Protocol Label Switching. In particular, it describes how
   various managed objects defined in various Management
   Information Base (MIB) documents model different aspects of
   Multi-Protocol Label Switching (MPLS) [MPLSArch].
   Furthermore, this document explains the interactions and
   dependencies between each of these documents.
  =20
   Comments should be made directly to the MPLS mailing list
   at [email-masked].
  =20
  =20
  =20
   This draft does not propose any additions to the MPLS MIB
   framework, nor define any standards for the Internet
   community.  It is an informational draft.

2. Terminology
  =20
   This document uses terminology from the MPLS architecture

Nadeau et al.               Expires April 2002               [Page 2]
=0C
Internet Draft          MPLS Management Overview         October 2001

   document [MPLSArch] and various MPLS-related MIBs such as
   the MPLS-TC-MIB [TCMIB], MPLS-LSR-MIB [LSRMIB], MPLS-TE-MIB
   [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and
   the MPLS-LINK-BUNDLING-MIB [LBMIB].

3. The SNMP Management Framework
  =20
   The SNMP Management Framework presently consists of five
   major components:
  =20
   -  An overall architecture, described in RFC 2571
      [RFC2571].
  =20
   -  Mechanisms for describing and naming objects and events
      for the purpose of management.  The first version of
      this Structure of Management Information (SMI) is
      called SMIv1 and described in STD 16, RFC 1155
      [RFC1155], STD 16, RFC 1212 [RFC1212] and STD 16, RFC
      1215 [RFC1215].  The second version, called SMIv2, is
      described in STD 58, RFC 2578 [RFC2578], STD 58, RFC
      2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
  =20
   -  Message protocols for transferring management
      information.  The first version of the SNMP message
      protocol is called SNMPv1 and described in STD 15, RFC
      1157 [RFC1157].  A second version of the SNMP message
      protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901
      [RFC1901] and RFC 1906 [RFC1906].  The third version of
      the message protocol is called SNMPv3 and described in
      RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
      [RFC2574].
  =20
   -  Protocol operations for accessing management
      information.  The first set of protocol operations and
      associated PDU formats is described in STD 15, RFC 1157
      [RFC1157].  A second set of protocol operations and
      associated PDU formats is described in RFC 1905
      [RFC1905].
  =20
   -  A set of fundamental applications described in RFC 2573
      [RFC2573] and the view-based access control mechanism
      described in RFC 2575 [RFC2575].
  =20
   A more detailed introduction to the current SNMP Management
   Framework can be found in RFC 2570 [RFC2570].
  =20
   Managed objects are accessed via a virtual information
   store, termed the Management Information Base or MIB.

Nadeau et al.               Expires April 2002               [Page 3]
=0C
Internet Draft          MPLS Management Overview         October 2001

   Objects in the MIB are defined using the mechanisms defined
   in the SMI.

4. MIBs Addressed by the MPLS Management Framework
  =20
   This section briefly explains what the purpose of each MPLS
   related MIB is and what it can be used for.  Each section
   contains a subsection that details the interdependencies
   between that MIB and any of the other MPLS MIBs.

4.1.  MPLS-TC-MIB
  =20
   The MPLS-TC-MIB [TCMIB] describes textual conventions
   [RFC2579] and object identities that may be common to MPLS-
   related MIBs. For example, the textual convention for
   representing an MPLS label should be commonly represented
   and used by all MPLS-related MIBs.

4.2.  MPLS-LSR-MIB
  =20
   The MPLS-LSR-MIB describes managed objects for modeling a
   Multi-Protocol Label Switching (MPLS) [RFC3031] Label
   Switch Router (LSR). In particular, this MIB is used to
   model and manage the basic label switching behavior and the
   label forwarding information base (LFIB) of an MPLS LSR. In
   doing so, the MIB provides a view of the LSPs that are
   being switched by the LSR in question.
  =20
   This MIB is the basis for many of the MPLS MIBs, since
   basic MPLS label switching is common to all MPLS
   applications.  In general, the MPLS-LSR-MIB provides a
   model of incoming labels on MPLS-enabled interfaces being
   mapped to outgoing labels on MPLS-enabled interfaces via a
   conceptual object called an MPLS cross-connect. MPLS cross-
   connect entries and their properties are represented in the
   MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS
   cross-connect entries are typically referred to by other
   MIBs in order to reference the underlying MPLS LSP.
  =20
   For example, the MPLS-TE-MIB [TEMIB] models traffic
   engineered tunnels.  These tunnels map to one more
   underlying MPLS LSPs. Thus, the MPLS-TE-MIB's tunnel table
   (mplsTunnelTable) entries refer to the underlying LSP by
   pointing to entries in mplsXCTable.

4.2.1.   Dependencies
  =20

Nadeau et al.               Expires April 2002               [Page 4]
=0C
Internet Draft          MPLS Management Overview         October 2001

   This MIB does not directly depend upon any other MPLS MIBs.
   It does represent MPLS-enabled interfaces as entries in the
   Interfaces MIB [RFC2233] Interface Table (ifTable). This
   MIB imports several textual conventions from the MPLS-TC-
   MIB [TCMIB].

4.3.  MPLS-LDP-MIB
  =20
   The MPLS-LDP-MIB describes managed objects used to model
   and manage the Multiprotocol Label Switching Label
   Distribution Protocol (LDP).

4.3.1.   Dependencies
  =20
   The LDP MIB [LDPMIB] has three mapping tables -
   mplsLdpSesInLabelMapTable, mplsLdpSesOutLabelMapTable and
   mplsLdpSesXCMapTable - which map the LDP MIB=92s
   representation of LDP sessions to the underlying LSR MIB=92s
   representation of the LSPs created by these sessions by
   pointing to mplsInSegmentTable, mplsOutSegmentTable and
   mplsXCTable, respectively. The LDP MIB=92s mplsXCsFecsTable
   shows the relationship between between forwarding
   equivalence classes (FECs) and cross-connect entries by
   referring to entries in the LSR MIB=92s mplsXCTable.
  =20
   This MIB also imports several textual conventions from the
   MPLS-TC-MIB [TCMIB].

4.4.  MPLS-TE-MIB
  =20
   The MPLS-TE-MIB [TEMIB] describes managed objects that are
   used to model and manage MPLS Traffic Engineered (TE)
   Tunnels. The MIB is based around a table that represents TE
   tunnels that either originate at the LSR in question or
   traverse via or terminate on the LSR. Note that the later
   case is optional, as only tunnel "heads" are required to be
   represented. This MIB provides statistics and configuration
   objects needed for TE tunnels.

4.4.1.   Dependencies
  =20
   This MIB depends on the MPLS-LSR-MIB [LSRMIB] and
   Interfaces MIB [RFC2233]. Tunnel entries in the MPLS-TE-
   MIB=92s mplsTunnelTable refer to entries in mplsXCTable in
   the MPLS-LSR-MIB. When MPLS TE tunnels are represented as
   interfaces, entries for such tunnels in mplsTunnelTable
   have corresponding entries in the Interfaces MIB=92s
   [RFC2233] Interfaces Table (ifTable). This MIB also imports

Nadeau et al.               Expires April 2002               [Page 5]
=0C
Internet Draft          MPLS Management Overview         October 2001

   several textual conventions from the MPLS-TC-MIB [TCMIB].

4.5.  MPLS-FTN-MIB
  =20
   The MPLS-FTN-MIB [FTNMIB] describes managed objects that
   are used to model and manage the MPLS FEC-to-NHLFE mappings
   which take place at any LSR that is on the edge between an
   MPLS domain and a non-MPLS domain. On each such edge LSR,
   to map traffic from the non-MPLS domain into the MPLS
   domain, the FEC-to-NHLFE mapping objects in the MPLS-FTN-
   MIB must be supported.  In the case of an IP-to-MPLS
   mapping, the FEC objects describe IP 5-tuples representing
   IP source and destination ranges, protocol ranges etc.
   Matching IP packets can be mapped to an NHLFE which can
   either be an MPLS LSP or an MPLS TE tunnel.

4.5.1.   Dependencies
  =20
   This MIB relies directly on the MPLS-LSR-MIB [LSRMIB] and
   MPLS-TE-MIB [TEMIB]. FECs can be mapped to two types of
   NHLFEs by the MPLS-FTN-MIB. When the NHLFE is an LSP, the
   FEC-to-NHLFE mapping is accomplished by referring to a
   corresponding entry in mplsXCTable in the MPLS-LSR-MIB.
   When the NHLFE is an MPLS TE tunnel, this mapping is
   accomplished by referring to a corresponding entry in
   mplsTunnelTable in MPLS-TE-MIB.

4.6.  MPLS-LINK-BUNDLING-MIB
  =20
   The MPLS-LINK-BUNDLING-MIB [LBMIB] describes managed
   objects that are used to model and manage the MPLS TE
   interfaces, as well as the link bundling relationships that
   may exist between those interfaces.

4.6.1.   Dependencies
  =20
   The MPLS-LINK-BUNDLING-MIB [LBMIB] interacts directly only
   with the Interfaces MIB [RFC2233]; it references MPLS TE
   interfaces that are modeled by entries in the interfaces
   table (ifTable) in the Interfaces MIB [RFC2233].

4.7.  PPVPN-MPLS-VPN-MIB
  =20
   The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects
   that are used to model and manage RFC2277bis MPLS VPNs.
   This MIB contains tables which model virtual routing
   forwarding entries (VRFs), as well as the interfaces

Nadeau et al.               Expires April 2002               [Page 6]
=0C
Internet Draft          MPLS Management Overview         October 2001

   associated with those VRFs.

4.7.1.   Dependencies
  =20
   This MIB currently has no direct dependencies to any of the
   MPLS MIBs. This MIB does model MPLS VPN interfaces as
   entries in the Interfaces MIB [RFC2233].  This MIB may be
   modified in the future to import textual conventions from
   the MPLS-TC-MIB [TCMIB].

5. Dependencies on Other IETF Working Groups
  =20
   This section will detail the broad interactions between
   other working groups and the MPLS MIBs.

5.1.  Pseudo Wire Emulation Edge to Edge MIBs
  =20
   The Pseudo Wire Emulation Edge to Edge (pwe3) working group
   has produced a framework [PWE3ARCH] describes a framework
   for PWE3 MIBs. Since the PWE3 architecture includes the use
   of MPLS as an emulated service and as a PSN service, the
   MPLS MIBs described above may be leveraged.  This framework
   document describes the interactions between the MPLS MIBs
   and the PWE3 MIBs.

5.2.  Provider Provisioned Virtual Private Network MIBs
  =20
   At present, the Provider Provisioned Virtual Private
   Network (PPVPN) working group has not included a discussion
   of how the MPLS MIBs interact with the MIBs being produced
   by that working group.  The authors of this draft hope to
   make a forthcoming addition to their framework [PPVPNFW]
   document detailing these interactions. At the moment, there
   is only a single MIB produced which interacts with the MPLS
   MIBs, as this MIB is described above in section

5.3.  Common Control and Measurement Plane (CCAMP) WG
  =20
   At present, there are no MIBs produced by the CCAMP working
   group that interact directly with the MPLS MIBs.  However,
   in the future, the existing MPLS MIBs will need to be
   extended and augmented to facilitate the technology being
   produced by this working group.

6. Security Considerations

Nadeau et al.               Expires April 2002               [Page 7]
=0C
Internet Draft          MPLS Management Overview         October 2001

  =20
   This document describes the inter-relationships amongst the
   different MIBs relevant to MPLS management and as such does
   not have any security implications beyond those imposed by
   these MIBs themselves.

7. Acknowledgments
  =20
   TBD.

8. References
  =20
   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C,
                 Viswanathan, A. and H. Sjostrand,
                 "Definition of Textual Conventions and
                 OBJECT-IDENTITIES for Multi-Protocol Label
                 Switching (MPLS) Management", Internet Draft
                 <draft-ietf-mpls-tc-mib-02.txt>, August
                 2001.
  =20
   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Label Switch Router Management
                 Information Base Using SMIv2", Internet
                 Draft <draft-ietf-mpls-lsr-mib-07.txt>,
                 January 2001.
  =20
   [TEMIB]       Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Traffic Engineering Management
                 Information Base Using SMIv2", Internet
                 Draft <draft-ietf-mpls-te-mib-07.txt>,
                 August 2001.
  =20
   [FTNMIB]      Nadeau, T., Srinivasan, C., and A.
                 Viswanathan, "Multiprotocol Label Switching
                 (MPLS) FEC-To-NHLFE (FTN) Management
                 Information Base", Internet Draft <draft-
                 ietf-mpls-ftn-mib-03.txt>, August 2001.
  =20
   [LBMIB]       Dubuc, M., Dharanikota, S., Nadeau, T., J.
                 Lang, "Link Bundling Management Information
                 Base Using SMIv2", Internet Draft <draft-
                 ietf-mpls-bundle-mib-00.txt>, September
                 2001.
  =20
   [PWE3ARCH]    Pate, P., Xiao, X., White., C., Kompella.,
                 K., Malis, A., Johnson, T., and T. Nadeau,
                 "Framework for Pseudo Wire Emulation Edge-to-
                 Edge (PWE3)", Internet Draft <draft-ietf-

Nadeau et al.               Expires April 2002               [Page 8]
=0C
Internet Draft          MPLS Management Overview         October 2001

                 pwe3-framework-00.txt>, September, 2001.
  =20
   [PPVPNFW]     Callon, R., Suzuki, M., Gleeson, B., Malis,
                 A., Muthukrishnan, K., Rosen, E., Sargor,
                 C., and J. Yu, "A Framework for Provider
                 Provisioned Virtual Private Networks",
                 Internet Draft <draft-ietf-ppvpn-framework-
                 01.txt>, July 2001.
  =20
   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for
                 TCP/IP-based Internets", RFC 1155, May 1990.
  =20
   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J.
                 Davin, "Simple Network Management Protocol",
                 RFC 1157, May 1990.
  =20
   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", RFC 1212, March 1991.
  =20
   [RFC1215]     M. Rose, "A Convention for Defining Traps
                 for use with the SNMP", RFC 1215, March
                 1991.
  =20
   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Introduction to Community-based
                 SNMPv2", RFC 1901, January 1996.
  =20
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Protocol Operations for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1905, January 1996.
  =20
   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Transport Mappings for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1906, January 1996.
  =20
   [RFC2026]     S. Bradner, "The Internet Standards Process
                 -- Revision 3", RFC 2026, October 1996.
  =20
   [RFC2233]     McCloghrie, K. and F. Kastenholtz, "The
                 Interface Group MIB Using SMIv2", RFC 2233,
                 November 1997.
  =20
   [RFC2570]     Case, J., Mundy, R., Partain, D., and B.
                 Stewart, "Introduction to Version 3 of the
                 Internet-standard Network Management
                 Framework", RFC 2570, April 1999.
  =20

Nadeau et al.               Expires April 2002               [Page 9]
=0C
Internet Draft          MPLS Management Overview         October 2001

   [RFC2571]     Harrington, D., Presuhn, R., and B. Wijnen,
                 "An Architecture for Describing SNMP
                 Management Frameworks", RFC 2571, April
                 1999.
  =20
   [RFC2572]     Case, J., Harrington D., Presuhn R., and B.
                 Wijnen, "Message Processing and Dispatching
                 for the Simple Network Management Protocol
                 (SNMP)", RFC 2572, April 1999.
  =20
   [RFC2573]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2573, April 1999.
  =20
   [RFC2574]     Blumenthal, U., and B. Wijnen, "User-based
                 Security Model (USM) for version 3 of the
                 Simple Network Management Protocol
                 (SNMPv3)", RFC 2574, April 1999.
  =20
   [RFC2575]     Wijnen, B., Presuhn, R., and K. McCloghrie,
                 "View-based Access Control Model (VACM) for
                 the Simple Network Management Protocol
                 (SNMP)", RFC 2575, April 1999.
  =20
   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Structure of Management Information Version
                 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  =20
   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Textual Conventions for SMIv2", STD 58, RFC
                 2579, April 1999.
  =20
   [RFC2580]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Conformance Statements for SMIv2", STD 58,
                 RFC 2580, April 1999.
  =20
   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching
                 Architecture", RFC 3031, January 2001.

9. Authors' Addresses

  Thomas D. Nadeau
  Cisco Systems, Inc.
  300 Apollo Drive
  Chelmsford, MA 01824
  Phone: +1-978-244-3051

Nadeau et al.               Expires April 2002              [Page 10]
=0C
Internet Draft          MPLS Management Overview         October 2001

  Email: [email-masked]

  Cheenu Srinivasan
  Alphion Corp.
  4 Industrial Way West
  Eatontown, NJ 07724
  Phone: +1-732-676-7066
  Email: [email-masked]

  Adrian Farrel
  Movaz Networks, Inc.
  7926 Jones Branch Drive, Suite 615
  McLean, VA 22102
  Phone: +1-703-847-9847
  Email: [email-masked]

10.   Full Copyright Statement
  =20
   Copyright (C) The Internet Society (2001). All Rights
   Reserved.
  =20
   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on
   or otherwise explain it or assist in its implementation may
   be prepared, copied, published and distributed, in whole or
   in part, without restriction of any kind, provided that the
   above copyright notice and this paragraph are included on
   all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to
   translate it into languages other than English.
  =20
   The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its
   successors or assigns. This document and the information
   contained herein is provided on an "AS IS" basis and THE
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Nadeau et al.               Expires April 2002              [Page 11]

------_=_NextPart_000_01C15D59.A1CC7C50--

Delivery-date: Thu, 25 Oct 2001 04:48:12 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Sudheer Dharanikota <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 25 Oct 2001 13:41:08 +0200

Hello Maarten,

> ASON is layer network based, GMPLS is not

Sorry, but you misunderstood how GMPLS works for SDH/SONET.

GMPLS supports *all* approaches that you described: "layer network based"
and/or "hidden set up of a STS-1 or VC-4 trail supporting an additional
VT/LOVC link or extending an existing VT/LOVC link".

The difference between these two approaches is a policy matter and should be
independent of the protocols. That's what we are doing (made) with GMPLS: we
are developing a toolbox without specifying (forcing) the policies.

That's up to the manufacturer to decide which policies he will implement
(e.g. both) and to the operator to decide which policies he wants to use.
Policies can even be dynamic and depends on customers. You can even use the
COPS model to deal with these policies.

To be more clear, at each switch you could have different policies, at some
places the call could fails (referring here to you example), at some places
the call could trigger a "hidden" VC-4. GMPLS doesn't specifies that. An
operator could operate its network in a pure layer network based approach,
or using only the other approach or using a mix.

If you mean that ASON "hardcoded" the policies by limiting the architecture
and the protocols to the example you gave (layer network based), that's a
*serious* limitation of ASON (and by the way totally unjustified). Clearly
from that perspective ASON is a subset of GMPLS. Is it the case ?

Kind regards,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 7:04 AM
To: Sudheer Dharanikota
Cc: [email-masked]
Subject: Re: Moving right along ...

Sudheer,

Another issue is ...

	- ASON is layer network based, GMPLS is not

i.e. a request for a connection within ASON is treated within the boundaries
of
one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer
network, or
within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11
connection
request is processed within the VT1.5/VC-11 layer network, using existing
VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity  in
the
VT1.5/VC-11 links to support the request, the call fails. There is no
"hidden"
set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or
extending an existing VT/LOVC link. The set up of an additional STS-1 or
VC-4
trail is supported within the scope of network planning and/or network
engineering. This is separated from the connection set up.

Regards,

Maarten

Sudheer Dharanikota wrote:
> 
> Hi Maarten:
> 
> Maarten Vissers wrote:
> 
> > Sudheer,
> >
> > At the moment I am unable to briefly summarize the differences between
GMPLS and
> > ASON. I was working from the perception that GMPLS could be one of the
protocols
> > supporting ASON. The technical comments I made during the last 10 months
were
> > based on this perception. Also the last comment describing the concept
of serial
> > compound link had this basis. Reading Yanhe's reply I had the impression
that
> > GMPLS is able to support serial compound links, but reading Eric's reply
I got
> > the opposite impression. Furthermore being very surprised by Eric's
reaction on
> > a pure technical issue, I composed a few challenging words to attrack
more
> > people to participate in the  discussion... :-)
> 
> I see one of the issue here being ...
> 
>     - Does GMPLS support serial compound links?
> 
> Let us enumerate few more questions and move the discussion to a technical
> level again, we need participation especially from the folks who are
involved
> in ASON architecture work.
> 
> >
> > Being impressed by the few hundred people attending the last ccamp
sessions in
> > London, I am surprised by the low percentage of those people being
actively
> > contributing to the correspondence. It can't be the case that only a
handful of
> > people have an opinion on these matters... and I believe the discussions
would
> > stay technical if more people express their opinion... there would not
be a
> > yes/no game between just a few people.
> >
> 
> I thought this is how most of the standards meetings work. 5 % work, 95 %
> try to gather industry intelligence ( :-) ) either by attending IETF or by
following
> 
> the mailing list.
> 
> >
> > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be
possible to
> > start an evaluation of GMPLS as a specific protocol for ASON. As
indicated in a
> > previous email from Steve Trowbridge, ITU-T will make those ASON
documents
> > available to IETF so we can jointly work this evaluation.
> >
> 
> Most of these documents are available on the t1x1 site. But what we need
here is
> the "delta" that is missing between ASON architecture and the view of
GMPLS
> architecture. Can you help us with this? We may start with a short list...
> 
> >
> > The approval of the current ASON recommendations is just a first step
within the
> > larger ASON task. Work is started on other elements of ASON (G.rtg
(routing),
> > G.lm (link management) and pnni based specific protocol as an
implementation of
> > the protocol neutral specification in G.7713)),  discussions are started
> > identifying further ASON elements, and work to extend G.8080 is planned
to start
> > after this SG15 meeting.
> >
> 
> Obviously GMPLS is a potential candidate to solve the ASON issues. It may
be
> ahead of its time as far as ITU and ANSI are concerned. So let us ammend
or
> modify it to the ITU view on the transport control plane.
> 
> Regards,
> 
> sudheer
> 
> >
> > Up to so far... {time to shut down my computer and go to the concert
hall in
> > Geneva... time to relax after a week and a half of hectic work over
here...}
> >
> > Regards,
> >
> > Maarten
> >
> > Sudheer Dharanikota wrote:
> > >
> > > Hi Marteen:
> > >
> > > Can you briefly summarize the differences you see between
> > > GMPLS architecture and ASON architecture? This has been
> > > asked by many of the folks at IETF.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > PS: I thought these mails were about label format and suddenly
> > > this is turning into an ITU versus IETF discussion :-(

Delivery-date: Thu, 25 Oct 2001 04:05:17 -0700
Date: Thu, 25 Oct 2001 07:04:19 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: Maarten Vissers <[email-masked]>, Sudheer Dharanikota <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi Mike,

I agree with most of what you said. I think the forwarding adjacency is
more similar to the serial composed link connections (or serial
compound links) than to support from a trail. There is no requirement 
for forwarding adjacencies to relate to trails (at least I don't think so).

And yes, I fully agree that the inter-layer piece is the interesting 
piece. I believe Maarten has presented this in several places as the 
network engineering function (what you called the "local matter") as 
subject to policy control (very operator business model dependent).

As for the hierarchy and the layer model, I think the hierarchical model 
of MPLS is more atuned to the sub-network partition (and sub-network 
recursion) which is within a layer. I'm not sure that the hierarchy was 
defined for layer network (although I don't see why it can't apply either).

Now in terms of the layer model itself, I think (as I said many times) 
that the problem is mainly in how people interpret the text in these 
documents. That is why (my little rambling again) I think we need to add 
text to clarify some of these concepts...people don't seem to want to 
add clarifying text though...sigh...

Zhi

[email-masked] wrote:

 >
 > Maarten,
 >
 > In the interests of reconciliation consider the following:
 >
 > ASON and G-MPLS are both post hoc conceptual models describing the
 > same physical and logical network. The objectives of automation
 > through signalling are broadly similar. Therefore it would be
 > surprising indeed if the solutions were widely different. ASON is
 > indeed based on the layered model of G.805 and deals with layering
 > issues up-front. GMPLS is derived from the Internet model which
 > regards the physical layer as flat. When real world layering is
 > encountered it is dealt with by refinements many of which appear in
 >  draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source
 > documents from which G-MPLS inherits. Here LSP regions are defined
 > in 6.2 which are as near as I can tell exactly equivalent to G.805
 > layer networks. Further, precedence rules between layers are
 > established with the clear implication that a higher layer cannot
 > be configured until the appropriate resources in the lower layer
 > have been instantiated. The manner in which this may be done is
 > considered a "local matter". The example given indicates that a
 > Forwarding Adjacency (equivalent to a G.805 link supported by one
 > or more trails (LSPs) in the server layer) may be initiated in
 > various ways including from an external manager or another
 > (adjacent) LSR. Thus the example you gave of a VC-1x layer being
 > set up by signalling and VC-4 layer being set up by an external
 > planning/management is certainly a valid implementation within the
 > scope of the G-MPLS solution. By the same token it is undesirable
 > (and anyway will not be possible) to confine signalling to certain
 > layers while reserving others for management through a standard.
 > Operators will want to make such important architectural choices on
 >  the basis of optimising their own operation. Once you have agreed
 > on a signalling protocol to create connections within a layer
 > network it is generically applicable to any layer network. Of
 > course making such an implementation choice (ie management for
 > VC-4, signalling for VC-1x) is an example of the "local policies"
 > mentioned above. Such choices frequently appear as part of some
 > sort of application specific profile or applications framework on
 > top of the base generic standard. Note this sort of profiling (if
 > that is the correct term) is generally needed to ensure
 > interworking amongst elements which implement the same generic
 > standard.
 >
 > On the last occasion that we studied application of signalling for
 > transport networks in ITU (over 10 years ago at the time G.805 was
 > first issued) we had concluded that connection set-up within a
 > layer was the easy part ie there were several well established
 > candidates to choose from (B-ISUP was the favorite. Neither PNNI
 > nor RSVP existed at that time. ISIS had already been adopted for
 > DCN in SDH and thus provided basic neighbour discovery and xSPF
 > computation if required). The major new problem to resolve for
 > multi-layer transport networks was indeed considered to be the
 > desired behaviour at inter-layer boundaries. It seems that both
 > initiatives have sidelined this issue as out of scope for the time
 > being.
 >
 > regards,
 >
 > Mike Sexton
 >
 >
 >
 >
 >
 >
 >
 > Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38
 >
 >
 >
 > To:      Sudheer Dharanikota <[email-masked]>
 >
 > cc:      [email-masked](bcc: Michael J 
SEXTON/GB/ALCATEL)
 >
 >
 >
 >
 > Subject: Re: Moving right along ...
 >
 >
 >
 >
 >
 >
 > Sudheer,
 >
 > Another issue is ...
 >
 > - ASON is layer network based, GMPLS is not
 >
 > i.e. a request for a connection within ASON is treated within the
 > boundaries of one layer network (e.g. within the boundaries of a
 > VT1.5/VC-11 layer network, or within the boundaries of a
 > STS-3c/VC-4 layer network). A VT1.5/VC-11 connection request is
 > processed within the VT1.5/VC-11 layer network, using existing 
VT1.5/VC-11
 >  links (GMPLS: link bundles). If there is not enough capacity  in
 > the VT1.5/VC-11 links to support the request, the call fails. There
 >  is no "hidden" set up of a STS-1 or VC-4 trail supporting an
 > additional VT/LOVC link or extending an existing VT/LOVC link. The
 > set up of an additional STS-1 or VC-4 trail is supported within the
 >  scope of network planning and/or network engineering. This is
 > separated from the connection set up.
 >
 > Regards,
 >
 > Maarten
 >
 > Sudheer Dharanikota wrote:
 >
 >> Hi Maarten:
 >>
 >> Maarten Vissers wrote:
 >>
 >>
 >>> Sudheer,
 >>>
 >>> At the moment I am unable to briefly summarize the differences
 >>> between GMPLS and ASON. I was working from the perception that
 >>> GMPLS could be one of the protocols supporting ASON. The
 >>> technical comments I made during the last 10 months were based
 >>> on this perception. Also the last comment describing the
 >>> concept of serial compound link had this basis. Reading Yanhe's
 >>>  reply I had the impression that GMPLS is able to support
 >>> serial compound links, but reading Eric's reply I got the
 >>> opposite impression. Furthermore being very surprised by Eric's
 >>>  reaction on a pure technical issue, I composed a few
 >>> challenging words to attrack more people to participate in the
 >>>  discussion... :-)
 >>>
 >> I see one of the issue here being ...
 >>
 >> - Does GMPLS support serial compound links?
 >>
 >> Let us enumerate few more questions and move the discussion to a
 >> technical level again, we need participation especially from the
 >> folks who are involved in ASON architecture work.
 >>
 >>
 >>> Being impressed by the few hundred people attending the last
 >>> ccamp sessions in London, I am surprised by the low percentage
 >>> of those people being actively contributing to the
 >>> correspondence. It can't be the case that only a handful of people
 >>>  have an opinion on these matters... and I believe the
 >>> discussions would stay technical if more people express their
 >>> opinion... there would not be a yes/no game between just a few
 >>> people.
 >>>
 >>>
 >> I thought this is how most of the standards meetings work. 5 %
 >> work, 95 % try to gather industry intelligence ( :-) ) either by
 >> attending IETF or by following
 >>
 >> the mailing list.
 >>
 >>
 >>> With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it
 >>> will be possible to start an evaluation of GMPLS as a specific
 >>> protocol for ASON. As indicated in a previous email from Steve
 >>> Trowbridge, ITU-T will make those ASON documents available to
 >>> IETF so we can jointly work this evaluation.
 >>>
 >>>
 >> Most of these documents are available on the t1x1 site. But what
 >> we need here is the "delta" that is missing between ASON
 >> architecture and the view of GMPLS architecture. Can you help us
 >> with this? We may start with a short list...
 >>
 >>
 >>> The approval of the current ASON recommendations is just a first
 >>>  step within the larger ASON task. Work is started on other
 >>> elements of ASON (G.rtg (routing), G.lm (link management) and
 >>> pnni based specific protocol as an implementation of the
 >>> protocol neutral specification in G.7713)),  discussions are
 >>> started identifying further ASON elements, and work to extend
 >>> G.8080 is planned to start after this SG15 meeting.
 >>>
 >>>
 >> Obviously GMPLS is a potential candidate to solve the ASON issues.
 >>  It may be ahead of its time as far as ITU and ANSI are
 >> concerned. So let us ammend or modify it to the ITU view on the
 >> transport control plane.
 >>
 >> Regards,
 >>
 >> sudheer
 >>
 >>
 >>> Up to so far... {time to shut down my computer and go to the
 >>> concert hall in Geneva... time to relax after a week and a half
 >>>  of hectic work over here...}
 >>>
 >>> Regards,
 >>>
 >>> Maarten
 >>>
 >>> Sudheer Dharanikota wrote:
 >>>
 >>>> Hi Marteen:
 >>>>
 >>>> Can you briefly summarize the differences you see between GMPLS
 >>>>  architecture and ASON architecture? This has been asked by
 >>>> many of the folks at IETF.
 >>>>
 >>>> Regards,
 >>>>
 >>>> sudheer
 >>>>
 >>>> PS: I thought these mails were about label format and suddenly this
 >>>>  is turning into an ITU versus IETF discussion :-(
 >>>>
 >>>> Part 1.1
 >>>>
 >>>> Content-Type:
 >>>>
 >>>> text/plain
 >>>>
 >>>>
 >>>> 
------------------------------------------------------------------------
 >>>>

 >>>> mvissers.vcf
 >>>>
 >>>> Content-Type:
 >>>>
 >>>> application/octet-stream Content-Encoding:
 >>>>
 >>>> base64
 >>>>
 >>>>

Delivery-date: Thu, 25 Oct 2001 03:49:06 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 25 Oct 2001 11:47:18 +0100

Hi Mike.....nice to hear from you and I think you make some good points.
However, I want to pick-up on one aspect you bring up a few times....and
that is 'choice'.  Operators need choice to suit their views on what
is/is-not a viable business case.

For example, we have various client layer networks besides IP to
accommodate, and of particular importance are managed BW services directly
off the L1 fabric, eg VC4 or lambdas say.  However, we can't see any valid
business case for generalised BoD/SVCs services here.....I mean, given
unknown calling/holding statistics just what capacity would one need to
build to to offer a GoS that customers would consider acceptable and that
you could get past finance/products people (esp given current climate)?  

So, on assumption that S-PVC-like services are all that is commercailly
viable (in our opinion at least) then you can ask yourself just what
additional revenues and/or Opex cost reductions are available from
implementating a control-plane solution?  Even this is difficult to justify
given:
-	current NMS approaches (in SDH) can easily cater for current and
foreseeable core trail churn rates;
-	the big costs are in access and laying ducts and installing
physicals....no control-plane solution is going to impact these.

However, assuming you do decide you want to implement a control-plane
solution in your transport networks then you really ought to be able to
choose the addressing, signalling and routing components on a best-of-breed
basis to suit what you want to do.  They are after all, quite disjoint
components and there are many architectural possibilities.......and this is
what ASON is all about....choice.

For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
aspects only) + centralised routing approach looks the best commercially for
what we want to do.  Others may argue that the current GMPLS approach suits
them best.  ASON allows this choice.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 25 October 2001 11:49
> To: Maarten Vissers
> Cc: Sudheer Dharanikota; [email-masked]
> Subject: Re: Moving right along ...
> 
> 
> 
> 
> Maarten,
> 
> In the interests of reconciliation consider the following:
> 
> ASON and G-MPLS are both post hoc conceptual models 
> describing the same physical and logical network. The 
> objectives of automation through signalling are broadly 
> similar. Therefore it would be surprising indeed if the 
> solutions were widely different. ASON
> is indeed based on the layered model of G.805 and deals with 
> layering issues up-front. GMPLS is derived from the Internet 
> model which regards the physical layer as flat. When real 
> world layering is encountered it is dealt with by refinements 
> many of which
> appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one 
> of the source documents from which G-MPLS inherits. Here LSP 
> regions are defined in 6.2 which are as near as I can tell 
> exactly equivalent to G.805 layer networks. Further, precedence rules
> between layers are established with the clear implication 
> that a higher layer cannot be configured until the 
> appropriate resources in the lower layer have been 
> instantiated. The manner in which this may be done is 
> considered a "local matter". The example
> given indicates that a Forwarding Adjacency (equivalent to a 
> G.805 link supported by one or more trails (LSPs) in the 
> server layer) may be initiated in various ways including from 
> an external manager or another (adjacent) LSR. Thus the 
> example you gave of
> a VC-1x layer being set up by signalling and VC-4 layer being 
> set up by an external planning/management is certainly a 
> valid implementation within the scope of the G-MPLS solution. 
> By the same token it is undesirable (and anyway will not be 
> possible) to
> confine signalling to certain layers while reserving others 
> for management through a standard. Operators will want to 
> make such important architectural choices on the basis of 
> optimising their own operation. Once you have agreed on a 
> signalling protocol to
> create connections within a layer network it is generically 
> applicable to any layer network. Of course making such an 
> implementation choice (ie management for VC-4, signalling for 
> VC-1x) is an example of the "local policies" mentioned above. 
> Such choices
> frequently appear as part of some sort of application 
> specific profile or applications framework on top of the base 
> generic standard. Note this sort of profiling (if that is the 
> correct term) is
> generally needed to ensure interworking amongst elements 
> which implement the same generic standard.
> 
> On the last occasion that we studied application of 
> signalling for transport networks in ITU (over 10 years ago 
> at the time G.805 was first issued) we had concluded that 
> connection set-up within a layer was the easy part ie there 
> were several well
> established candidates to choose from (B-ISUP was the 
> favorite. Neither PNNI nor RSVP existed at that time. ISIS 
> had already been adopted for DCN in SDH and thus provided 
> basic neighbour discovery and xSPF computation if required). 
> The major new problem to
> resolve for multi-layer transport networks was indeed 
> considered to be the desired behaviour at inter-layer 
> boundaries. It seems that both initiatives have sidelined 
> this issue as out of scope for the time being.
> 
> regards,
> 
> Mike Sexton
> 
> 
> 
> 
> 
> 
> 
> Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38
>                                                               
>                                                               
>                                                               
>  To:      Sudheer Dharanikota <[email-masked]>             
>                                                               
>  cc:      [email-masked](bcc: Michael J                   
>           SEXTON/GB/ALCATEL)                                  
>                                                               
>                                                               
>                                                               
>  Subject: Re: Moving right along ...                          
>                                                               
> 
> 
> 
> 
> 
> Sudheer,
> 
> Another issue is ...
> 
>      - ASON is layer network based, GMPLS is not
> 
> i.e. a request for a connection within ASON is treated within 
> the boundaries of
> one layer network (e.g. within the boundaries of a 
> VT1.5/VC-11 layer network, or
> within the boundaries of a STS-3c/VC-4 layer network). A 
> VT1.5/VC-11 connection
> request is processed within the VT1.5/VC-11 layer network, 
> using existing
> VT1.5/VC-11 links (GMPLS: link bundles). If there is not 
> enough capacity  in the
> VT1.5/VC-11 links to support the request, the call fails. 
> There is no "hidden"
> set up of a STS-1 or VC-4 trail supporting an additional 
> VT/LOVC link or
> extending an existing VT/LOVC link. The set up of an 
> additional STS-1 or VC-4
> trail is supported within the scope of network planning and/or network
> engineering. This is separated from the connection set up.
> 
> Regards,
> 
> Maarten
> 
> Sudheer Dharanikota wrote:
> >
> > Hi Maarten:
> >
> > Maarten Vissers wrote:
> >
> > > Sudheer,
> > >
> > > At the moment I am unable to briefly summarize the 
> differences between GMPLS and
> > > ASON. I was working from the perception that GMPLS could 
> be one of the protocols
> > > supporting ASON. The technical comments I made during the 
> last 10 months were
> > > based on this perception. Also the last comment 
> describing the concept of serial
> > > compound link had this basis. Reading Yanhe's reply I had 
> the impression that
> > > GMPLS is able to support serial compound links, but 
> reading Eric's reply I got
> > > the opposite impression. Furthermore being very surprised 
> by Eric's reaction on
> > > a pure technical issue, I composed a few challenging 
> words to attrack more
> > > people to participate in the  discussion... :-)
> >
> > I see one of the issue here being ...
> >
> >     - Does GMPLS support serial compound links?
> >
> > Let us enumerate few more questions and move the discussion 
> to a technical
> > level again, we need participation especially from the 
> folks who are involved
> > in ASON architecture work.
> >
> > >
> > > Being impressed by the few hundred people attending the 
> last ccamp sessions in
> > > London, I am surprised by the low percentage of those 
> people being actively
> > > contributing to the correspondence. It can't be the case 
> that only a handful of
> > > people have an opinion on these matters... and I believe 
> the discussions would
> > > stay technical if more people express their opinion... 
> there would not be a
> > > yes/no game between just a few people.
> > >
> >
> > I thought this is how most of the standards meetings work. 
> 5 % work, 95 %
> > try to gather industry intelligence ( :-) ) either by 
> attending IETF or by following
> >
> > the mailing list.
> >
> > >
> > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available 
> it will be possible to
> > > start an evaluation of GMPLS as a specific protocol for 
> ASON. As indicated in a
> > > previous email from Steve Trowbridge, ITU-T will make 
> those ASON documents
> > > available to IETF so we can jointly work this evaluation.
> > >
> >
> > Most of these documents are available on the t1x1 site. But 
> what we need here is
> > the "delta" that is missing between ASON architecture and 
> the view of GMPLS
> > architecture. Can you help us with this? We may start with 
> a short list...
> >
> > >
> > > The approval of the current ASON recommendations is just 
> a first step within the
> > > larger ASON task. Work is started on other elements of 
> ASON (G.rtg (routing),
> > > G.lm (link management) and pnni based specific protocol 
> as an implementation of
> > > the protocol neutral specification in G.7713)),  
> discussions are started
> > > identifying further ASON elements, and work to extend 
> G.8080 is planned to start
> > > after this SG15 meeting.
> > >
> >
> > Obviously GMPLS is a potential candidate to solve the ASON 
> issues. It may be
> > ahead of its time as far as ITU and ANSI are concerned. So 
> let us ammend or
> > modify it to the ITU view on the transport control plane.
> >
> > Regards,
> >
> > sudheer
> >
> > >
> > > Up to so far... {time to shut down my computer and go to 
> the concert hall in
> > > Geneva... time to relax after a week and a half of hectic 
> work over here...}
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Sudheer Dharanikota wrote:
> > > >
> > > > Hi Marteen:
> > > >
> > > > Can you briefly summarize the differences you see between
> > > > GMPLS architecture and ASON architecture? This has been
> > > > asked by many of the folks at IETF.
> > > >
> > > > Regards,
> > > >
> > > > sudheer
> > > >
> > > > PS: I thought these mails were about label format and suddenly
> > > > this is turning into an ITU versus IETF discussion :-(
> 

Delivery-date: Thu, 25 Oct 2001 03:03:01 -0700
From: [email-masked]
To: Maarten Vissers <[email-masked]>
cc: Sudheer Dharanikota <[email-masked]>, [email-masked]
Date: Thu, 25 Oct 2001 11:48:46 +0100
Subject: Re: Moving right along ...

--0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Maarten,

In the interests of reconciliation consider the following:

ASON and G-MPLS are both post hoc conceptual models describing the same physical and logical network. The objectives of automation through signalling are broadly similar. Therefore it would be surprising indeed if the solutions were widely different. ASON
is indeed based on the layered model of G.805 and deals with layering issues up-front. GMPLS is derived from the Internet model which regards the physical layer as flat. When real world layering is encountered it is dealt with by refinements many of which
appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one of the source documents from which G-MPLS inherits. Here LSP regions are defined in 6.2 which are as near as I can tell exactly equivalent to G.805 layer networks. Further, precedence rules
between layers are established with the clear implication that a higher layer cannot be configured until the appropriate resources in the lower layer have been instantiated. The manner in which this may be done is considered a "local matter". The example
given indicates that a Forwarding Adjacency (equivalent to a G.805 link supported by one or more trails (LSPs) in the server layer) may be initiated in various ways including from an external manager or another (adjacent) LSR. Thus the example you gave of
a VC-1x layer being set up by signalling and VC-4 layer being set up by an external planning/management is certainly a valid implementation within the scope of the G-MPLS solution. By the same token it is undesirable (and anyway will not be possible) to
confine signalling to certain layers while reserving others for management through a standard. Operators will want to make such important architectural choices on the basis of optimising their own operation. Once you have agreed on a signalling protocol to
create connections within a layer network it is generically applicable to any layer network. Of course making such an implementation choice (ie management for VC-4, signalling for VC-1x) is an example of the "local policies" mentioned above. Such choices
frequently appear as part of some sort of application specific profile or applications framework on top of the base generic standard. Note this sort of profiling (if that is the correct term) is
generally needed to ensure interworking amongst elements which implement the same generic standard.

On the last occasion that we studied application of signalling for transport networks in ITU (over 10 years ago at the time G.805 was first issued) we had concluded that connection set-up within a layer was the easy part ie there were several well
established candidates to choose from (B-ISUP was the favorite. Neither PNNI nor RSVP existed at that time. ISIS had already been adopted for DCN in SDH and thus provided basic neighbour discovery and xSPF computation if required). The major new problem to
resolve for multi-layer transport networks was indeed considered to be the desired behaviour at inter-layer boundaries. It seems that both initiatives have sidelined this issue as out of scope for the time being.

regards,

Mike Sexton

Maarten Vissers <[email-masked]> on 25/10/2001 06:03:38

                                                              
 To:      Sudheer Dharanikota <[email-masked]>             
                                                              
 cc:      [email-masked](bcc: Michael J                   
          SEXTON/GB/ALCATEL)                                  

                                                              
 Subject: Re: Moving right along ...                          

Sudheer,

Another issue is ...

     - ASON is layer network based, GMPLS is not

i.e. a request for a connection within ASON is treated within the boundaries of
one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer network, or
within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 connection
request is processed within the VT1.5/VC-11 layer network, using existing
VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity  in the
VT1.5/VC-11 links to support the request, the call fails. There is no "hidden"
set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or
extending an existing VT/LOVC link. The set up of an additional STS-1 or VC-4
trail is supported within the scope of network planning and/or network
engineering. This is separated from the connection set up.

Regards,

Maarten

Sudheer Dharanikota wrote:
>
> Hi Maarten:
>
> Maarten Vissers wrote:
>
> > Sudheer,
> >
> > At the moment I am unable to briefly summarize the differences between GMPLS and
> > ASON. I was working from the perception that GMPLS could be one of the protocols
> > supporting ASON. The technical comments I made during the last 10 months were
> > based on this perception. Also the last comment describing the concept of serial
> > compound link had this basis. Reading Yanhe's reply I had the impression that
> > GMPLS is able to support serial compound links, but reading Eric's reply I got
> > the opposite impression. Furthermore being very surprised by Eric's reaction on
> > a pure technical issue, I composed a few challenging words to attrack more
> > people to participate in the  discussion... :-)
>
> I see one of the issue here being ...
>
>     - Does GMPLS support serial compound links?
>
> Let us enumerate few more questions and move the discussion to a technical
> level again, we need participation especially from the folks who are involved
> in ASON architecture work.
>
> >
> > Being impressed by the few hundred people attending the last ccamp sessions in
> > London, I am surprised by the low percentage of those people being actively
> > contributing to the correspondence. It can't be the case that only a handful of
> > people have an opinion on these matters... and I believe the discussions would
> > stay technical if more people express their opinion... there would not be a
> > yes/no game between just a few people.
> >
>
> I thought this is how most of the standards meetings work. 5 % work, 95 %
> try to gather industry intelligence ( :-) ) either by attending IETF or by following
>
> the mailing list.
>
> >
> > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
> > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
> > previous email from Steve Trowbridge, ITU-T will make those ASON documents
> > available to IETF so we can jointly work this evaluation.
> >
>
> Most of these documents are available on the t1x1 site. But what we need here is
> the "delta" that is missing between ASON architecture and the view of GMPLS
> architecture. Can you help us with this? We may start with a short list...
>
> >
> > The approval of the current ASON recommendations is just a first step within the
> > larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
> > G.lm (link management) and pnni based specific protocol as an implementation of
> > the protocol neutral specification in G.7713)),  discussions are started
> > identifying further ASON elements, and work to extend G.8080 is planned to start
> > after this SG15 meeting.
> >
>
> Obviously GMPLS is a potential candidate to solve the ASON issues. It may be
> ahead of its time as far as ITU and ANSI are concerned. So let us ammend or
> modify it to the ITU view on the transport control plane.
>
> Regards,
>
> sudheer
>
> >
> > Up to so far... {time to shut down my computer and go to the concert hall in
> > Geneva... time to relax after a week and a half of hectic work over here...}
> >
> > Regards,
> >
> > Maarten
> >
> > Sudheer Dharanikota wrote:
> > >
> > > Hi Marteen:
> > >
> > > Can you briefly summarize the differences you see between
> > > GMPLS architecture and ASON architecture? This has been
> > > asked by many of the folks at IETF.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > PS: I thought these mails were about label format and suddenly
> > > this is turning into an ITU versus IETF discussion :-(

--0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU
Content-type: application/octet-stream; 
	name="mvissers.vcf"
Content-Disposition: attachment; filename="mvissers.vcf"
Content-transfer-encoding: base64

YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1
DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7
d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO
ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K
ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i
ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh
dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh
cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K

--0__=U8E63R9pnobYnVrF6VRPHUlqkMbej3qmgfw70T8HjLAWui0HCOoWIXdU--

Delivery-date: Thu, 25 Oct 2001 00:21:41 -0700
Date: Thu, 25 Oct 2001 03:13:49 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
CC: Maarten Vissers <[email-masked]>, [email-masked], q12/15 <[email-masked]>, q14/15 <[email-masked]>
Subject: Re: Moving right along ...

Hi Sudheer, I tried answering some of your questions in another email, 
so I will put some short answers to this email...below...

Sudheer Dharanikota wrote:

> Hi Maarten:
> 
> 
> Maarten Vissers wrote:
> 
> 
>>Sudheer,
>>
>>At the moment I am unable to briefly summarize the differences between GMPLS and
>>ASON. I was working from the perception that GMPLS could be one of the protocols
>>supporting ASON. The technical comments I made during the last 10 months were
>>based on this perception. Also the last comment describing the concept of serial
>>compound link had this basis. Reading Yanhe's reply I had the impression that
>>GMPLS is able to support serial compound links, but reading Eric's reply I got
>>the opposite impression. Furthermore being very surprised by Eric's reaction on
>>a pure technical issue, I composed a few challenging words to attrack more
>>people to participate in the  discussion... :-)
>>
> 
> I see one of the issue here being ...
> 
>     - Does GMPLS support serial compound links?
> 
> Let us enumerate few more questions and move the discussion to a technical
> level again, we need participation especially from the folks who are involved
> in ASON architecture work.
> 
> 

<z>This is where I keep suggesting that we put in clarifying text. I 
showed an example a few emails back about "A-B-C" configuration where B 
is not GMPLS aware. I want to bring out the point that the text in GMPLS 
is not clear about whether or not this is supported.

I believe GMPLS can support serial compound links, but we need to 
describe in the text properly (or more clearly) so that people are aware 
of this, instead of simply saying that "it is obvious to the informed 
reader". I think our goal should be to make it as readable as possible 
to the larger audience, not just a few people who has followed the 
mailing list. I keep getting reminded of how specific BGP documents are 
and how much information on BGP is actually not specified anywhere that 
is actually needed in order for it to work properly...this seems a 
little "elitist" to me...please don't flame me...:-)
</z>

>>Being impressed by the few hundred people attending the last ccamp sessions in
>>London, I am surprised by the low percentage of those people being actively
>>contributing to the correspondence. It can't be the case that only a handful of
>>people have an opinion on these matters... and I believe the discussions would
>>stay technical if more people express their opinion... there would not be a
>>yes/no game between just a few people.
>>
>>
> 
> I thought this is how most of the standards meetings work. 5 % work, 95 %
> try to gather industry intelligence ( :-) ) either by attending IETF or by following
> 
> the mailing list.
> 
> 

<z> :-) </z>

>>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
>>start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
>>previous email from Steve Trowbridge, ITU-T will make those ASON documents
>>available to IETF so we can jointly work this evaluation.
>>
>>
> 
> Most of these documents are available on the t1x1 site. But what we need here is
> the "delta" that is missing between ASON architecture and the view of GMPLS
> architecture. Can you help us with this? We may start with a short list...
> 
> 

<z>Well, let's see, I don't think anybody as really gone through the 
details of it yet. I would be very interested if anybody out there have 
done this already</z>

>>The approval of the current ASON recommendations is just a first step within the
>>larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
>>G.lm (link management) and pnni based specific protocol as an implementation of
>>the protocol neutral specification in G.7713)),  discussions are started
>>identifying further ASON elements, and work to extend G.8080 is planned to start
>>after this SG15 meeting.
>>
>>
> 
> Obviously GMPLS is a potential candidate to solve the ASON issues. It may be
> ahead of its time as far as ITU and ANSI are concerned. So let us ammend or
> modify it to the ITU view on the transport control plane.
> 

<z>I agree GMPLS is definitely a candidate. That is why I don't 
understand some people's mentality of "ITU against/versus IETF". I think 
they are complementary. The architecture experts are in ITU (at least 
some experts) and the protocol experts are in IETF (again, at least some 
experts). In terms of ahead of its times...don't know about 
that...depends on your timeframe...1 month? 1 year? 10 years? 1 week? :-)
</z>

> Regards,
> 
> sudheer
> 
> 
>>Up to so far... {time to shut down my computer and go to the concert hall in
>>Geneva... time to relax after a week and a half of hectic work over here...}
>>
>>Regards,
>>
>>Maarten
>>
>>Sudheer Dharanikota wrote:
>>
>>>Hi Marteen:
>>>
>>>Can you briefly summarize the differences you see between
>>>GMPLS architecture and ASON architecture? This has been
>>>asked by many of the folks at IETF.
>>>
>>>Regards,
>>>
>>>sudheer
>>>
>>>PS: I thought these mails were about label format and suddenly
>>>this is turning into an ITU versus IETF discussion :-(
>>>

Delivery-date: Thu, 25 Oct 2001 00:00:30 -0700
Date: Thu, 25 Oct 2001 02:58:49 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
CC: Irfan Lateef <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Sudheer,

OK I'll try to highlight some. I think Maarten mentioned one already:
-- ASON is based on a separation of layer network.

Not only that, ASON is also based on separation of functional roles of 
the switched network. ASON defines the architecture of the switched 
network in terms of the interactions of different components. Components 
defined by ASON performs specific tasks:
--Call controller (CallC) is the "service" component that interfaces 
with the user to support service requests. I believe this can be viewed 
as been handled by the OIF UNI specification, which provides the user to 
network request capability
--Connection controller (CC) is the network component that supports the 
connection operations, which includes setup and release of individual 
links (ITU: link connections) in support of the user request. A set of 
connection controllers are involved on a sub-network (area of AS) basis 
to set up/release connections within its domain of responsibility, and 
interacts with other CC in different ways depending on how the operator 
configures the interactions. Methods of interaction include a joint 
federation model and a cooperative federation model. CC is I think what 
GMPLS is about, in terms of setting up and releasing/tearing down 
connections.
--Link resource manager is the network component that assigns a link 
(ITU: link connection) from a link bundle/TE-link (ITU: link). Thus the 
progression of signaling goes from CC which receives requests for 
connections to LRM which chooses a link, and provides the CC with the 
requested link information so that CC can set up a sub-network 
connection (a connection across a sub-network). Note that sub-network 
connection "concept" is a recursive definition where the limit of 
recursion of a sub-network connection is the fabric connection. The LRM 
from GMPLS perspective is subsumed into the CC (this is where the label 
negotiation takes place).
--Routing controller (RC) is the network component that provides the 
routing information, including route dissemination, route determination, 
route table update, etc. Three models of routing has been defined: 
hierarchical, source-based and step-by-step. As part of the routing 
definition, a "routing area" is defined to support 
multi-level/hierarchical routing domains. This is very similar (maybe 
identical?) to the OSPF/BGP separation of roles.

NOTE that these are all logical components (what ITU calls a 
computational view of the control plane), with certain distribution 
assumed (what ITU calls an engineering view of the control plane). 
Different implementations of these components may have, e.g., CallC, CC 
and LRM all in one "box" while another implementation may have CallC in 
one box and CC, LRM and RC in another box. However, the functionality is 
equivalant. Only difference is in terms of which interfaces have been 
exposed and becomes external (that is standardizable).

Now to how different or similar is ASON/G.dcm with GMPLS. In terms of 
the information mapping and message mapping between them, I would say 
they are very close to each other. For example, when ASON/G.dcm 
discusses setup/release operations, it views the transport resources as 
an "abstract" entity called SNP (subnetwork point). If you are familiar 
with management objects, the SNP is very similar to SNTP (subnetwork 
termination point). Where SNTP provides the management system with a 
view of the underlying transport resources (CTP or TTP or simply TP), 
the SNP provides the control plane with a view of the underlying 
transport resources. As such these SNP and SNPP (SNP pools which is an 
aggregation of the SNPs into a logical "bundle" based on some policy or 
provisioned constraints) is used in setting up a connection. The 
SNP/SNPP provides an abstraction barrier between physical resources and 
logical resources and is provided on a layer basis (i.e., SNP ID 
information for a STS-1 layer is independent of the SNP ID information 
for a STS-3c layer is independent of the SNP ID information for a ODU1 
layer).

The other difference is that ASON/G.dcm deals with abstract "names" in 
terms of specifying relevant endpoints. This is simply a "protocol 
neutral" aspect of addresses used in GMPLS, where GMPLS assumes IPv4 and 
IPv6, G.dcm does not assume any addressing scheme. This is not 
inconsistent, only different levels of specification. One of the "names" 
defined in ASON/G.dcm is a "call name" which is a reference to the call. 
IETF GMPLS I believe "sort-of" supports this. Call name is essentially a 
globally unique identifier that identifies the call. IETF GMPLS also 
provides a globally unique identifier in the form of SESSION and 
SENDER_TEMPLATE (for RSVP-TE).

There are also capabilities described in GMPLS that is currently not 
specified by the ASON/G.dcm. This includes the capabilities supported by 
the Admin_Status object (turning on/off monitoring), and the multiplier 
parameter within the SONET/SDH SENDER_TSPEC/FLOWSPEC object. For 
example, many of the parameters that support the SONET/SDH connection 
(such as what signal type, encoding type, NCC, NVC) are implied 
information in ASON/G.dcm since they are layer information. These 
parameters in GMPLS may be thought of as an implementation of the layer 
information for the specific protocol.

GMPLS RSVP-TE is a soft-state protocol, CR-LDP is more a hard-state 
protocol. ASON/G.dcm does not specify whether the protocol needs to be 
soft-state or hard-state. It discusses what are the behaviours and how 
these "systems" may recover from problems. It also provides a high-level 
state transition diagram on the operation of the signaling mechanism. 
 From this viewpoint, I also don't see too much inconsistency. Of 
course, I haven't done any analysis/comparison. If anyone is interested 
doing this it let me know!

  The first stage of the ITU specification for the ASON work is nearing 
completion. The next stage is to start work on the protocol specific 
implementations of the ASON model. At the current ITU meeting, we 
already have United Kingdom (presented by British Telecom) bring in 
contribution requesting to use PNNI as A protocol for supporting ASON. 
This was also supported by other carriers. The ITU has now opened the 
floor to any other protocols to be submitted as well.

So if people want to see GMPLS considered as one of the protocols for 
ASON, someone needs to submit this to the ITU. Currently the decision is 
that if any protocols meets the requirements outlined in ASON and G.dcm, 
then they will be considered (i.e., any protocol). There were some 
interest shown in the meeting to bringing in GMPLS.

Well, I hope this provides enough of a summary to help the discussions 
along.

Zhi

Sudheer Dharanikota wrote:

> Hi Zhi:
> 
> Zhi-Wei Lin wrote:
> 
> 
>> From what I understand G.ason and G.dcm is developed to describe the
>>process and the minimal requirements needed to support a basic switched
>>transport service. GMPLS is a protocol specific implementation that will
>>likely meet many of the requirements, and may have some minor areas that
>>it does not meet. Then the question to ask (as with any requirements and
>>architecture work -- I'm sure we all have architects in our company) is:
>>how critical are the requirements that may not be met and what changes
>>are needed to GMPLS (if any) in order to meet them?
>>
>>
> 
> It may be a good idea to explain where GMPLS is lacking in meeting ASON
> and DCM requirements. YOu, being involved in this process, is the best
> person to articulate the major drawbacks. WHy don't you spend a minute in
> higlighting them.
> 
> THese discussions are becoming highly non-technical and unproductive. Let us
> streamline our energy to a common cause - find the enhancements needed to
> accomodate ASON architecture.
> 
> Regards,
> 
> sudheer
> 
> 
>>
> 

Delivery-date: Wed, 24 Oct 2001 22:10:13 -0700
Cc: [email-masked]
Date: Thu, 25 Oct 2001 07:03:38 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------9156D9B97ADC3B13F978BCD8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sudheer,

Another issue is ...

	- ASON is layer network based, GMPLS is not

i.e. a request for a connection within ASON is treated within the boundaries of
one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer network, or
within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11 connection
request is processed within the VT1.5/VC-11 layer network, using existing
VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity  in the
VT1.5/VC-11 links to support the request, the call fails. There is no "hidden"
set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or
extending an existing VT/LOVC link. The set up of an additional STS-1 or VC-4
trail is supported within the scope of network planning and/or network
engineering. This is separated from the connection set up.

Regards,

Maarten

Sudheer Dharanikota wrote:
> 
> Hi Maarten:
> 
> Maarten Vissers wrote:
> 
> > Sudheer,
> >
> > At the moment I am unable to briefly summarize the differences between GMPLS and
> > ASON. I was working from the perception that GMPLS could be one of the protocols
> > supporting ASON. The technical comments I made during the last 10 months were
> > based on this perception. Also the last comment describing the concept of serial
> > compound link had this basis. Reading Yanhe's reply I had the impression that
> > GMPLS is able to support serial compound links, but reading Eric's reply I got
> > the opposite impression. Furthermore being very surprised by Eric's reaction on
> > a pure technical issue, I composed a few challenging words to attrack more
> > people to participate in the  discussion... :-)
> 
> I see one of the issue here being ...
> 
>     - Does GMPLS support serial compound links?
> 
> Let us enumerate few more questions and move the discussion to a technical
> level again, we need participation especially from the folks who are involved
> in ASON architecture work.
> 
> >
> > Being impressed by the few hundred people attending the last ccamp sessions in
> > London, I am surprised by the low percentage of those people being actively
> > contributing to the correspondence. It can't be the case that only a handful of
> > people have an opinion on these matters... and I believe the discussions would
> > stay technical if more people express their opinion... there would not be a
> > yes/no game between just a few people.
> >
> 
> I thought this is how most of the standards meetings work. 5 % work, 95 %
> try to gather industry intelligence ( :-) ) either by attending IETF or by following
> 
> the mailing list.
> 
> >
> > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
> > start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
> > previous email from Steve Trowbridge, ITU-T will make those ASON documents
> > available to IETF so we can jointly work this evaluation.
> >
> 
> Most of these documents are available on the t1x1 site. But what we need here is
> the "delta" that is missing between ASON architecture and the view of GMPLS
> architecture. Can you help us with this? We may start with a short list...
> 
> >
> > The approval of the current ASON recommendations is just a first step within the
> > larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
> > G.lm (link management) and pnni based specific protocol as an implementation of
> > the protocol neutral specification in G.7713)),  discussions are started
> > identifying further ASON elements, and work to extend G.8080 is planned to start
> > after this SG15 meeting.
> >
> 
> Obviously GMPLS is a potential candidate to solve the ASON issues. It may be
> ahead of its time as far as ITU and ANSI are concerned. So let us ammend or
> modify it to the ITU view on the transport control plane.
> 
> Regards,
> 
> sudheer
> 
> >
> > Up to so far... {time to shut down my computer and go to the concert hall in
> > Geneva... time to relax after a week and a half of hectic work over here...}
> >
> > Regards,
> >
> > Maarten
> >
> > Sudheer Dharanikota wrote:
> > >
> > > Hi Marteen:
> > >
> > > Can you briefly summarize the differences you see between
> > > GMPLS architecture and ASON architecture? This has been
> > > asked by many of the folks at IETF.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > PS: I thought these mails were about label format and suddenly
> > > this is turning into an ITU versus IETF discussion :-(
--------------9156D9B97ADC3B13F978BCD8
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------9156D9B97ADC3B13F978BCD8--

Delivery-date: Wed, 24 Oct 2001 11:52:05 -0700
Date: Wed, 24 Oct 2001 11:47:38 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Maarten Vissers <[email-masked]>
CC: [email-masked], q12/15 <[email-masked]>, q14/15 <[email-masked]>
Subject: Re: Moving right along ...

Hi Maarten:

Maarten Vissers wrote:

> Sudheer,
>
> At the moment I am unable to briefly summarize the differences between GMPLS and
> ASON. I was working from the perception that GMPLS could be one of the protocols
> supporting ASON. The technical comments I made during the last 10 months were
> based on this perception. Also the last comment describing the concept of serial
> compound link had this basis. Reading Yanhe's reply I had the impression that
> GMPLS is able to support serial compound links, but reading Eric's reply I got
> the opposite impression. Furthermore being very surprised by Eric's reaction on
> a pure technical issue, I composed a few challenging words to attrack more
> people to participate in the  discussion... :-)

I see one of the issue here being ...

    - Does GMPLS support serial compound links?

Let us enumerate few more questions and move the discussion to a technical
level again, we need participation especially from the folks who are involved
in ASON architecture work.

>
> Being impressed by the few hundred people attending the last ccamp sessions in
> London, I am surprised by the low percentage of those people being actively
> contributing to the correspondence. It can't be the case that only a handful of
> people have an opinion on these matters... and I believe the discussions would
> stay technical if more people express their opinion... there would not be a
> yes/no game between just a few people.
>

I thought this is how most of the standards meetings work. 5 % work, 95 %
try to gather industry intelligence ( :-) ) either by attending IETF or by following

the mailing list.

>
> With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
> start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
> previous email from Steve Trowbridge, ITU-T will make those ASON documents
> available to IETF so we can jointly work this evaluation.
>

Most of these documents are available on the t1x1 site. But what we need here is
the "delta" that is missing between ASON architecture and the view of GMPLS
architecture. Can you help us with this? We may start with a short list...

>
> The approval of the current ASON recommendations is just a first step within the
> larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
> G.lm (link management) and pnni based specific protocol as an implementation of
> the protocol neutral specification in G.7713)),  discussions are started
> identifying further ASON elements, and work to extend G.8080 is planned to start
> after this SG15 meeting.
>

Obviously GMPLS is a potential candidate to solve the ASON issues. It may be
ahead of its time as far as ITU and ANSI are concerned. So let us ammend or
modify it to the ITU view on the transport control plane.

Regards,

sudheer

>
> Up to so far... {time to shut down my computer and go to the concert hall in
> Geneva... time to relax after a week and a half of hectic work over here...}
>
> Regards,
>
> Maarten
>
> Sudheer Dharanikota wrote:
> >
> > Hi Marteen:
> >
> > Can you briefly summarize the differences you see between
> > GMPLS architecture and ASON architecture? This has been
> > asked by many of the folks at IETF.
> >
> > Regards,
> >
> > sudheer
> >
> > PS: I thought these mails were about label format and suddenly
> > this is turning into an ITU versus IETF discussion :-(

Delivery-date: Wed, 24 Oct 2001 11:21:43 -0700
Date: Wed, 24 Oct 2001 11:18:27 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Irfan Lateef <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Zhi:

Zhi-Wei Lin wrote:

>
>  From what I understand G.ason and G.dcm is developed to describe the
> process and the minimal requirements needed to support a basic switched
> transport service. GMPLS is a protocol specific implementation that will
> likely meet many of the requirements, and may have some minor areas that
> it does not meet. Then the question to ask (as with any requirements and
> architecture work -- I'm sure we all have architects in our company) is:
> how critical are the requirements that may not be met and what changes
> are needed to GMPLS (if any) in order to meet them?
>

It may be a good idea to explain where GMPLS is lacking in meeting ASON
and DCM requirements. YOu, being involved in this process, is the best
person to articulate the major drawbacks. WHy don't you spend a minute in
higlighting them.

THese discussions are becoming highly non-technical and unproductive. Let us
streamline our energy to a common cause - find the enhancements needed to
accomodate ASON architecture.

Regards,

sudheer

>
>

Delivery-date: Wed, 24 Oct 2001 11:14:18 -0700
content-class: urn:content-classes:message
Subject: RE: Questions about draft-ietf-ccamp-lmp-mib-00.txt
Date:  Wed, 24 Oct 2001 14:08:32 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Fugui Wang" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Fugui,

The lmpRemoteTeLinkId and lmpRemoteTeLinkType was removed from the
latest LMP MIB because it was redundant with information stored in the
link bundling MIB (see
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-00.txt).
The link bundling MIB contains a TE link table (teLinkTable) which
captures the information you are looking for. The remote TE link type is
found in the  teLinkNumberingType object and the remote TE link
identifier is either teLinkRemoteIpAddr or teLinkIncomingIfId depending
on whether or not the TE link is numbered or unnumbered.

Regards,

Martin

-----Original Message-----
From: Fugui Wang [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 12:08 PM
To: Martin Dubuc; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Questions about draft-ietf-ccamp-lmp-mib-00.txt

I noticed that lmpRemoteTeLinkId and lmpRemoteTeLinkType were
taken away from the TE Link Table in this version. Is there
any special reason for that? In the latest LMP draft
draft-ietf-ccamp-lmp-01.txt, when we do link verification or
link summary, we still need the remote TE link ID infomation.
Would you suggest that we store the remote TE link ID in other
places instead of in the TE link Table?

Thanks,
Fugui

Delivery-date: Wed, 24 Oct 2001 11:14:10 -0700
To: Gopal Kailad <[email-masked]>
cc: [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) 
Date: Wed, 24 Oct 2001 11:12:33 -0700
From: Yakov Rekhter <[email-masked]>

Gopal,

[clipped...]

> >>>>If a node supports PSC as well as TDM or LSC interfaces, it
> >>>>might want to advertise different set of parameters in the
> >>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM
> >>>>LSPs which form bearer channels in transport networks.
> >>>>Currently this is not possible.
> >>>>
> >>>>>Can you give us explicit examples as to why and what do
> >>>>>you gain by giving different values for PSC, TDM ?
> >>>>>
> >>>>In case of PSC devices, it may be OK to remove state that
> >>>>is not resynchronized at the end of the recovery period,
>>>>and the recovery period advertised might reflect that.
> >>>>
> >>>>
> >>>>But for LSPs in transport networks, one might want to
> >>>>have a different recovery period to avoid any LSP from
> >>>>going down because of recovery timer expiry.
> >>>>
> >>>There is no requirement for a node to advertise exactly the
> >>>same Restart_Cap on all the interfaces. So, on PSC interfaces
> >>>the node could advertise that it will remove the state that
> >>>isn't syncronized at the end of the recovery period, while
> >>>on the TDM interface precisely the same node could advertise
> >>>that the LSPs would be kept even after the recovery time expires.
> >>>
> >>But to set up LSPs over TDM/LSC interfaces, the PSC interface
> >>is going to be used for signaling - since control and data
> >>planes are decoupled!  So, how will this help?
> >>
> >
> >Help with what ? You asserted that it "is not possible" for
> >"a node that supports PSC as well as TDM and LSC interfaces..
> >to advertise different set of parameters in the RESTART_CAP
> >object for data LSPs as opposed to SONET/WDM LSPs."
> >
> >I pointed out to you that your assertion is incorrect, as
> >there is no requirement for a node to advertise exactly the
> >same Restart_Cap on all of its interfaces.
> >
> I believe your assertion is misleading - If two nodes A and
> B have multiple TDM/LSC links (with out of band signaling)
> between them as well as a PSC link, (they are all unnumbered
> interfaces), there will be only one Hello adjacency between
> A and B, resulting in just one Restart_cap object advertised
> in each direction.
>
> In that case, how can one advertise different values in the
> Restart_cap object for TDM/LSC LSPs as opposed to data LSPs?
> 
> Since there is only one adjacency, the suggestion above to
> treat the node failure as control channel failure does not
> work either, as the restarting node might want to get
> resynchronized for data LSPs.
> 
> I believe your assertion is possible only if all interfaces
> are numbered.  

That is incorrect - what I described is possible if only the
control channel is numbered (note that a control channel, just
like any other link, could have multiple IP addresses assigned to it).

> If so, this is a huge constraint - please
> refer draft-ietf-ipo-carrier-requirements-00, sec 7.4.

In the context of UNI the (multiple) IP addresses assigned
to a control channel could be locally defined. As such
it would meet the requirements of section 7.4 of the draft
you mentioned.

Yakov.

Delivery-date: Wed, 24 Oct 2001 09:12:17 -0700
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Questions about draft-ietf-ccamp-lmp-mib-00.txt
Date: Wed, 24 Oct 2001 12:07:48 -0400

I noticed that lmpRemoteTeLinkId and lmpRemoteTeLinkType were
taken away from the TE Link Table in this version. Is there
any special reason for that? In the latest LMP draft
draft-ietf-ccamp-lmp-01.txt, when we do link verification or
link summary, we still need the remote TE link ID infomation.
Would you suggest that we store the remote TE link ID in other
places instead of in the TE link Table?

Thanks,
Fugui

Delivery-date: Wed, 24 Oct 2001 09:05:26 -0700
Cc: [email-masked], q12/15 <[email-masked]>, q14/15 <[email-masked]>
Date: Wed, 24 Oct 2001 17:59:30 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
Original-CC: [email-masked], q12/15 <[email-masked]>, q14/15 <[email-masked]>
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------237325921DB8ED75897EC97C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sudheer,

At the moment I am unable to briefly summarize the differences between GMPLS and
ASON. I was working from the perception that GMPLS could be one of the protocols
supporting ASON. The technical comments I made during the last 10 months were
based on this perception. Also the last comment describing the concept of serial
compound link had this basis. Reading Yanhe's reply I had the impression that
GMPLS is able to support serial compound links, but reading Eric's reply I got
the opposite impression. Furthermore being very surprised by Eric's reaction on
a pure technical issue, I composed a few challenging words to attrack more
people to participate in the  discussion... :-)

Being impressed by the few hundred people attending the last ccamp sessions in
London, I am surprised by the low percentage of those people being actively
contributing to the correspondence. It can't be the case that only a handful of
people have an opinion on these matters... and I believe the discussions would
stay technical if more people express their opinion... there would not be a
yes/no game between just a few people.

With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be possible to
start an evaluation of GMPLS as a specific protocol for ASON. As indicated in a
previous email from Steve Trowbridge, ITU-T will make those ASON documents
available to IETF so we can jointly work this evaluation.

The approval of the current ASON recommendations is just a first step within the
larger ASON task. Work is started on other elements of ASON (G.rtg (routing),
G.lm (link management) and pnni based specific protocol as an implementation of
the protocol neutral specification in G.7713)),  discussions are started
identifying further ASON elements, and work to extend G.8080 is planned to start
after this SG15 meeting.

Up to so far... {time to shut down my computer and go to the concert hall in
Geneva... time to relax after a week and a half of hectic work over here...}

Regards,

Maarten

Sudheer Dharanikota wrote:
> 
> Hi Marteen:
> 
> Can you briefly summarize the differences you see between
> GMPLS architecture and ASON architecture? This has been
> asked by many of the folks at IETF.
> 
> Regards,
> 
> sudheer
> 
> PS: I thought these mails were about label format and suddenly
> this is turning into an ITU versus IETF discussion :-(
--------------237325921DB8ED75897EC97C
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------237325921DB8ED75897EC97C--

Delivery-date: Wed, 24 Oct 2001 08:55:48 -0700
Date: Wed, 24 Oct 2001 11:47:36 -0400
From: Gopal Kailad <[email-masked]>
To: Yakov Rekhter <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Hi Yakov,

Yakov Rekhter wrote:

>>>
>>>>>>I have some questions/concerns on the restart mechanism as
>>>>>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
>>>>>>have listed them below.
>>>>>>
>>>>>>If a node that is terminating hierarchical LSPs restarts,
>>>>>>there is an ordering issue during resynchronization, since
>>>>>>the LSPs would depend on other FA-LSPs the interface IDs for
>>>>>>which would have been generated dynamically. So the
>>>>>>mechanism as described will not work, unless this
>>>>>>information is preserved across restarts - in which case we
>>>>>>might as well preserve other information as well, and avoid
>>>>>>resynchronization.
>>>>>>
>>>>>Since transit node of the FA-LSP does not see the RSVP
>>>>>messages that use the FA, we only need to consider
>>>>>the ingress and egress node. If the egress node restarts,
>>>>>the worst case is that its upstream node sends an ERO
>>>>>consisting a unrecognized interface address. Since the
>>>>>Path message will carry RECOVERY_LABEL (replacing
>>>>>SUGGESTED_LABEL), the egress node knows that it might
>>>>>not have complete information yet, and can hold on to
>>>>>the Path message until the FA-LSP is established.
>>>>>All the information is there, so implementation
>>>>>can be completely within the egress node. It does work,
>>>>>just not specified enough.
>>>>>
>>>>>Ingress node will have to know the dependency, so not
>>>>>a problem there.
>>>>>
>>>>Are you suggesting that in case of an ERO with an
>>>>unrecognized interface id, if the Path message also
>>>>carries a RECOVERY LABEL, the egress node can hold on
>>>>to it until later?  Note that there may not be a
>>>>RECOVERY LABEL - since this Path message is for a
>>>>hierarchical LSP, and the previous node may not be
>>>>directly connected in the control plane.  Here is an
>>>>example - There is an LSP L1 from C to F, and on top of
>>>>it there is an LSP L2 from A to G.
>>>>
>>>>L1:              C --- D --- E --- F
>>>>L2:  A --- B --- C --------------- F --- G
>>>>
>>>>When F restarts, C may not even know, unless HELLO
>>>>protocol is run between C and F.  Note that the
>>>>HELLO mechanism is intended for immediate neighbors.
>>>>
>>>>And even if the HELLO mechanism is extended, there
>>>>is the issue of interface id assigned by F.  F needs
>>>>to assign the same interface id upon restart so as
>>>>not to bring down the hierarchical LSPs set up on top
>>>>of L1 in 
>>>>the reverse direction (say an LSP from G to
>>>>B set up on top of L1.)  Where would F get this
>>>>information ?
>>>>
>>>Couple of points:
>>>
>>>(1) First of all, you do run RSVP Hello between C and F.
>>>
>>O.K.
>>
>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
>>>be able to recover the Interface ID it assigns to L1 from
>>>a combination of (a) the OSPF/ISIS link state database that
>>>F would recover, and (b) the Forward Interface ID (the one
>>>assigned by C).
>>>
>>True. One could either use IGP restart mechanism to relearn
>>this (I have other concerns on RSVP restart being dependent on
>>IGP restart, but that for later) or preserve this across restarts.
>>In either case,  you agree that RSVP restart depends on some
>>mechanism outside RSVP to help it along?  So RSVP needs a new
>>interface to get this mapping upon restarts, right? This is not
>>clear in the draft.
>>
>
>Couple of points:
>
>1. As Dimitri Papadimitriou mentioned in his other e-mail to this
>list, an Internet Draft "is not a textbook on how to use GMPLS-SIG".
>
The intent is not to make this a textbook at all.

I refer you to documents such as
draft-ietf-ospf-hitless-restart-01.txt which state clearely what
help you need from outside OSPF for restart to work, and as far
as interfaces, RFC 2205 sec 3.11.

In addition, the first answer I got on this list, (I believe,
from one of the authors) stated that

" All the information is there, so implementation
  can be completely within the egress node. It does work,
  just not specified enough."

whereas, in your answer, you have acknowledged that RSVP does
need help in learning the interface ids. that the restarting
node had assigned.  So, is the other answer from an "uninformed
reader" ?

I am not trying to put down anybody - just trying to point out
some things are not clear. I have also heard from implementors
who did not realize that RSVP needs to learn the interface ids
that were assigned before the restart. They could claim that 
their implementation is in full compliance with the draft, even
though hierarchical LSPs will be dropped upon restart.

>
>
>2. What I mentioned in the above should be abundantly obvious to the
>informed reader of RSVP and LSP Hierarchy specs.
>
>
>
>>>>>>Also, let us consider a node that can preserve state across
>>>>>>restarts, and hence does not need its state to be synced by
>>>>>>its peer.  How will it advertise this in the RESTART_CAP
>>>>>>object?
>>>>>>
>>>>>We still need to resynchronize the state since the other
>>>>>side might have connections that are in progress. The
>>>>>
>>>>Let us say the node can resynchronize its neighbor if
>>>>the neighbor restarts and requests state recovery. But
>>>>the issue is how a node can advertise that it does not
>>>>need recovery since all its state was preserved?
>>>>
>>>By treating is the same way as the way the spec handles
>>>control channel fault.
>>>
>>True, but this does not help.  
>>
>
>Help with what ?
>
I meant this does not work - for reasons cited below.

>
>
>>See below.
>>
* deleted *

>
>>>>
>>>>If a node supports PSC as well as TDM or LSC interfaces, it
>>>>might want to advertise different set of parameters in the
>>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM
>>>>LSPs which form bearer channels in transport networks.
>>>>Currently this is not possible.
>>>>
>>>>>Can you give us explicit examples as to why and what do
>>>>>you gain by giving different values for PSC, TDM ?
>>>>>
>>>>In case of PSC devices, it may be OK to remove state that
>>>>is not resynchronized at the end of the recovery period,
>>>>and the recovery period advertised might reflect that.
>>>>
>>>>
>>>>But for LSPs in transport networks, one might want to
>>>>have a different recovery period to avoid any LSP from
>>>>going down because of recovery timer expiry.
>>>>
>>>There is no requirement for a node to advertise exactly the
>>>same Restart_Cap on all the interfaces. So, on PSC interfaces
>>>the node could advertise that it will remove the state that
>>>isn't syncronized at the end of the recovery period, while
>>>on the TDM interface precisely the same node could advertise
>>>that the LSPs would be kept even after the recovery time expires.
>>>
>>But to set up LSPs over TDM/LSC interfaces, the PSC interface
>>is going to be used for signaling - since control and data
>>planes are decoupled!  So, how will this help?
>>
>
>Help with what ? You asserted that it "is not possible" for
>"a node that supports PSC as well as TDM and LSC interfaces..
>to advertise different set of parameters in the RESTART_CAP
>object for data LSPs as opposed to SONET/WDM LSPs."
>
>I pointed out to you that your assertion is incorrect, as
>there is no requirement for a node to advertise exactly the
>same Restart_Cap on all of its interfaces.
>
I believe your assertion is misleading - If two nodes A and
B have multiple TDM/LSC links (with out of band signaling)
between them as well as a PSC link, (they are all unnumbered
interfaces), there will be only one Hello adjacency between
A and B, resulting in just one Restart_cap object advertised
in each direction.

In that case, how can one advertise different values in the
Restart_cap object for TDM/LSC LSPs as opposed to data LSPs?

Since there is only one adjacency, the suggestion above to
treat the node failure as control channel failure does not
work either, as the restarting node might want to get
resynchronized for data LSPs.

I believe your assertion is possible only if all interfaces
are numbered.  If so, this is a huge constraint - please
refer draft-ietf-ipo-carrier-requirements-00, sec 7.4.

Cheers,

Gopal

>
>
>>>>>>According to 9.5.1. (procedures for restarting LSR): "When
>>>>>>sending the corresponding outgoing Path message the node
>>>>>>SHOULD include a SUGGESTED_LABEL object with a label value
>>>>>>^^^^^^
>>>>>>matching the outgoing label from the now restored forwarding
>>>>>>entry."
>>>>>>
>>>>>>This has a conflict with 9.5.2.  Consider the case where
>>>>>>adjacent nodes B and C restart, and B has another adjacent
>>>>>>node A, and C has another adjacent node D.  B and C will get
>>>>>>resynced by A and D, and during this process, they will
>>>>>>resync. each other. While resyncing each other, they act as
>>>>>>neighbors of a restarting LSR, and hence according to 9.5.2,
>>>>>>MUST include the SUGGESTED_LABEL.
>>>>>>
>>>>>>Also according to 9.5.2: "During the recovery period, new
>>>>>>Path state being advertised to the restarted neighbor SHOULD
>>>>>>not include the SUGGESTED_LABEL object in the corresponding
>>>>>>outgoing Path message.  This will prevent the restarting
>>>>>>node
>>>>>>from erroneously reusing a saved forwarding entry."
>>>>>>
>>>>>>I guess this would mean that if suggested labels are used
>>>>>>during new LSP setup (as they are likely to be while
>>>>>>provisioning lightpaths - to reduce latency), then new LSP
>>>>>>setup will not be allowed during resyncing?
>>>>>>
>>>>>The use of RECOVERY_LABEL address all the above questions.
>>>>>
>>>>The first problems seems to be there still - consider two
>>>>adjacent nodes restarting.  They both act both as the restarting
>>>>node as well as the neighbor to the restarting node. So, once
>>>>they learn the state from the upstream neighbor, do they use
>>>>suggested label or the recovery label when they send the path
>>>>message to the just restarted downstream neighbor?
>>>>
>>>The recovery label.
>>>
>>>The following should be added to the existing text from the document:
>>>
>>>  In the special case where a restarting node also has a restating
>>>  downstream neighbor, a Recovery_Label object should be used instead
>>>  of a Suggested_Label object.
>>>
>>Since a restarting node may not be able to detect that a
>>downstream neighbor is restarting, I suggest it always use
>>a Recovery_Label object instead of a Suggested_Label object.
>>
>
>Please see my reply to Yangguang on this topic.
>
>
>
>Yakov.
>
>

Delivery-date: Wed, 24 Oct 2001 08:18:37 -0700
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, [email-masked]
Cc: [email-masked], "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Moving right along ...
Date: Wed, 24 Oct 2001 11:16:06 -0400

Eric,

My comment on the labels was in reference to the gen-signaling draft. As you
note in the gmpls-sonet-sdh draft, sonet/sdh are defined as a base
(combined) set. Whereas in the gen-signaling draft, the LSP encoding type
and G-PID assign different values for the two types. The two documents do
not appear to be in alignment?

One value should apply in the gen-draft, and in the technology specific
draft, the additional technology related attributes can be described. My
comment is the same for the two values assigned for ANSI PDH and ETSI PDH in
the gen draft. One label, PDH, should be used and reference to the ITU-T
documents e.g. one of the most common PDH rates, 45M, is used both in the
U.S. and Europe. The gen draft limits it to ANSI and SONET technologies.
This is in-correct.

You are correct, there is no support for TUG-3 multiplexing in SONET. But
this does not limit "SONET" equipment from supporting TUG-3. Gateway
equipment may support both multiplexing hierarchies (AU-3, AU-4). GMPLS
should allow for each link to negotiate - we do not want to limit equipment
to either AU-3 or AU-4 support by the gmpls label assignment. Just as many
of the routers today can be placed in the U.S. or Europe and connect at a
STS-3c (VC-4) - the STS-3c/VC-4 are equivalent and the PPP/ATM mapping is
the same. We do not want GMPLS to prevent this connectivity. For example,
the current gen-labels limit PPP to SONET - which is incorrect (whereas ATM
can be supported by both sdh and sonet in the current draft). I had
suggested this past summer to use simply SDH and PDH as the gen-labels. And
any technology attributes and related discussion should be in the
tech-specific documents.

As for the only other difference - the SONET VT3 (3.456M)- why it is in
T1.105 and not in G.707 - was before my time :-) As there are no service
mappings defined for it, I don't see it as a show-stopper for preventing
gmpls to be a truly global protocol vs. localized defined. I would propose
in the sdh-sonet draft, it can be included with a note that it is not
supported in ITU-T G707 or it can simply be omitted and if a need arises, it
can be added later (both to G707 and GMPLS). As I think you commented, gmpls
needs to be flexible as there will be future additions (e.g. ODU over SDH).

The ability to decouple the service from the local connection link
technology is the basis for the ITU-T ASON work. The ITU-T ASON work
describes an end-to-end model supporting both client services and native
connections. As GMPLS is only addressing the local link set-up, it does need
information on the payload. But the labels should not constrain the local
link technology which may be used or the services which can be supported.

Deborah Brungard
AT&T 

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 7:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Moving right along ...

Dear All,

Let me strongly clarify something about the SDH/SONET label. I started to
see and receive comments from people that obviously didn't read the text
carefully, or get lost due to "non-technical" comments.

Let's kill the rumor. 

1. The draft defines ONE label format: SUKLM

As explained in the draft the SONET multiplexing structure is seen as a
subset of the SDH one. It is also said that S, L and M have a similar
meaning for SONET and SDH. U and K are not significant for SONET. This is
why we have on single label format for "SDH/SONET".

2. We claimed since the beginning that our goal was to have a common format
for both:

This is why this format was accepted, discussed and enhanced, and this was
beginning of year 2000!

3. SDH and SONET have and will continue to have two different multiplexing
structures:

   - because there is no TUG-3 equivalent in SONET.
   - because there is no VT-3 equivalent in SDH.

This is a fact.

So it results, that the label for SONET and SDH can be as similar as
possible, given these two limitations. They will NEVER be completely
identical because this is not physically possible. The proposal of Juergen
doesn't change that.

The only difference between the current text and the proposal of Juergen is
that:

- the current text uses the single stage interleaving approach of SONET.
- Juergen's proposal uses the two-stage interleaving approach of SONET.

That's the only difference. I already explained the reasons why we used the
single stage interleaving approach.

So please, don't tell me that "some people want to align the labels...",
this is we made almost two years ago.

Kind regards,

Eric

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 9:11 AM
To: Irfan Lateef
Cc: [email-masked]; [email-masked]
Subject: Re: Moving right along ...

Hi Irfan, good summary! I think (b) is probably right for some. I don't 
see (c) as been the case...

 From one uninformed reader to another, I think the quote you had was a 
frustrated person stating what he thinks was implied by another 
frustrated person's statement (am I putting words in anyone's mouth?).

 From what I understand G.ason and G.dcm is developed to describe the 
process and the minimal requirements needed to support a basic switched 
transport service. GMPLS is a protocol specific implementation that will 
likely meet many of the requirements, and may have some minor areas that 
it does not meet. Then the question to ask (as with any requirements and 
architecture work -- I'm sure we all have architects in our company) is: 
how critical are the requirements that may not be met and what changes 
are needed to GMPLS (if any) in order to meet them?

The last few email exchanges I think has been process related: why are 
things added to GMPLS, who has authority to add. Why can't we make GMPLS 
drafts more clear to people reading these drafts?

Of course there were also some fundamental issues, such as Juergen's 
desire to align the labels (which I agree with), Yangguang's question of 
why we are taking a fundamentally different approach for recovery since 
the "transport world" has done it one way for a long time and now it's 
suddenly changed & and authors not willing to discuss why the 
"traditional" way is not desired, and of course my desire to add 
clarifying text to the document to help uninformed reader like myself 
understand what SONET/SDH is all about (which is probably purely 
political rambling...)

Zhi

Irfan Lateef wrote:

> A view from the side lines
> -------------------------------
> 
>   First, on the lighter side I have the following suggestion.
>   we should change the subject line to any of the following,
>   a. Stubbornly stuck - refusing to move forward
>   b. Political Ramblings
>   c. Serious Trouble
>   d. Ugly email war among adults behaving like kids
>   I vote for (b)
> 
>   Now on the serious side, I have a few questions.
> 
> 1. Does the chair of this WG think that this email thread is a necessary
>    democratic step in the process.
> 
> 2. If not, then why isn't somebody stepping in with a summary of issues
>    and resolving them. Isn't there any arbitration process.
> 
> 3. If the protocols are designed to be flexible to accomadate future
changes,
>    why aren't the authors treating "some of the" requests as part of the
flexibility
> 
>   and getting along.
> 
> 4. I feel the authors were treating last call as a formality and are not
ready
>     to accept changes because it is a last call. Then what is the real
intent of
>     last call.
> 
> 5. There seems to be a real disconnect between the needs of,
>     a. vendors and service providers
>     b. data vendors and transport vendors
>     If GMPLS is for at least this three groups, then the issues need to be
>     resolved to the satisfaction of this small set.
>     (I personally agree with not spending 10 years trying to develop a
panacea for
> all)
> 
> 6. And finally it is alarming to me to note the following assertion.
>     "GMPLS wouldn't fit the ASON model... :-( "
>     Can someone clarify the true import of this statement. My
understanding was
> GMPLS is
>     the only thing on which ITU,OIF and IETF are on the same page. Can you
please
> correct
>     me on this and clarify as am a truly "uninformed" person on this.
> 
> Regards,
> Irfan Lateef
> 
> Maarten Vissers wrote:
> 
> 
>>Eric,
>>
>>What you refer to as "our own model" is already developed by ITU-T SG15...
it is
>>in G.8080 (ex. G.ason) and other ASON related recommendations which will
be
>>approved later this week. We are also entering the next phase in ASON
>>development; a phase in which protocol specific details will be defined. A
>>proposal to use PNNI as a basis is accepted... and expected in the near
future
>>is a proposal to use also GMPLS as a 2nd protocol version... but if I
understand
>>your message, GMPLS wouldn't fit the ASON model... :-(
>>
>>It's good to know this beforehand... no need then to consider this
further...
>>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details
over
>>the last 10 months... hope it's different however.
>>
>>Regards,
>>
>>Maarten
>>PS. when I wrote my reply to Yanhe there was no frustation... and their
isn't
>>today either...
>>
>>"Mannie, Eric" wrote:
>>
>>>Hi Maarten and Zhi,
>>>
>>>I have the feeling that you are inventing a new model with a new
protocol.
>>>This is not how GMPLS works. I understand your frustrations and I have
the
>>>feeling that your ideas should be addressed somewhere else rather than
>>>trying to change a model that we are finalizing and that we got from the
>>>MPLS model.
>>>
>>>There are maybe 1000 ways of designing a control plane for transmission
>>>networks. I would suggest that you first develop your own model and then
>>>that we compare the two.
>>>
>>>Please, don't forget that we have here to be constructive in terms of
GMPLS.
>>>We have final discussions about the core GMPLS signaling, this is not the
>>>beginning but the end of an (intermediate) phase.
>>>
>>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean
your
>>>house :-) We know it. Personally, I don't believe in the ultimate model
and
>>>protocol that will do everything and that will take 10 years to be
>>>specified, with abstract protocols, meta-models, etc.
>>>
>>>By the way, personally I don't see any benefit of defining these
>>>meta-models, abstract models and abstract protocols. It is hard to
>>>understand for non super-expert and it is a complete loss of time for the
>>>readers. I prefer practical solutions.
>>>
>>>I am also seeing discussions that we already have many times in the past.
I
>>>don't see any benefit of having them again, and again, and again. If we
>>>continue like this we will all implement a tool to answer automatically
with
>>>our previous e-mails :-)
>>>
>>>Ok, there is a small set of people that don't like the way that GMPLS is
>>>designed and defined (always the same 4 or 5 people by the way) - that's
>>>100% your right guys and I respect it. In comparison with the hundreds
>>>(thousands ?) of people that are working on GMPLS and implementing it,
this
>>>is a great achievement !
>>>
>>>So, I ask you the question: what do you want to achieve personally at
this
>>>stage ? Don't you think that sometimes it is needed to finish one step,
>>>before going to the next one ?
>>>
>>>Kind regards,
>>>
>>>Eric
>>>
>>>-----Original Message-----
>>>From: Maarten Vissers [mailto:[email-masked]]
>>>Sent: Monday, October 22, 2001 11:07 PM
>>>To: Yanhe Fan
>>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ...
>>>
>>>Yanhe,
>>>
>>>The situation Zhi describes is one that will be very typical in the
optical
>>>(SDH/SONET) network in the coming years. We will most likely see islands
of
>>>switched subnetworks interconnected via the existing SDH/SONET
non-switched
>>>networks. By means of management actions, links (GMPLS: link bundles)
will
>>>be
>>>setup between an edge node in one switched subnetwork and an other edge
node
>>>in
>>>the next switched subnetwork. In G.805 terminology, these links are so
>>>called
>>>serial compound links.
>>>
>>>The switched subnetworks will treat these serial compound links as normal
>>>links,
>>>"ignoring" the intermediate non-switched nodes they traverse. These links
>>>will
>>>contain a fixed set of link connections, which are identified by their
>>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
>>>The server signal that carries the e.g. 5 STS1 link connections in the
link
>>>at A
>>>can be an OC12, whereas this can be an OC48 at Z.
>>>
>>>During discovery or by means of provisioning both A and Z nodes get aware
of
>>>the
>>>5 sTS1 link connections as tuples of e.g.
>>>
>>>        SNPa             SNPz
>>>-----------------------------------
>>>- port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
>>>- port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
>>>- port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
>>>- port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
>>>- port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
>>>
>>>As both ends of the link build up this same relation information, it is
>>>possible
>>>to use as link connection identifier only one of the two SNPs. E.g. node
A
>>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
>>>info
>>>to node Z. Node Z receiving this Ai/T1 converts this locally into
"Zj/Ta".
>>>Vice
>>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
>>>received
>>>by node A, this will be converted into Ai/T1.
>>>
>>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot
at
>>>both ends of the link connection, only the timeslot at the sending end.
The
>>>receiving end needs to convert this then into its local timeslot number.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>Yanhe Fan wrote:
>>>
>>>>Hi Zhi,
>>>>
>>>>What B does is breaking the label association between A and C by
crossing
>>>>connect
>>>>the time slots.
>>>>
>>>>If the cross connect performed by B is fixed (in your case), what needs
to
>>>>do is
>>>>just to rebuild the label association by configuration or a protocol
such
>>>>
>>>as
>>>
>>>>LMP;
>>>>If the cross connect is not fixed but dynamic, the best thing to do is
to
>>>>make B
>>>>a GMPLS speaker.
>>>>
>>>Tell this to the 1.000.000+ SDH/SONET network elements in today's
transport
>>>network... no chance... those will stay non-switched...
>>>
>>>
>>>>Yanhe
>>>>
>>>>-----Original Message-----
>>>>From: Zhi-Wei Lin [mailto:[email-masked]]
>>>>Sent: Friday, October 19, 2001 6:01 PM
>>>>To: Yanhe Fan
>>>>Cc: John Drake; Kireeti Kompella; [email-masked]
>>>>Subject: Re: Moving right along ...
>>>>
>>>>Hi Yanhe,
>>>>
>>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
>>>>is simply part of the network that made up the "dumb" pipe. And because
>>>>the control plane control channel is separate, A and C can be adjacent
>>>>without ever knowing who B is or that even B existed. From A and C's
>>>>point of view, the network looks like:
>>>>
>>>>  A ----- C
>>>>
>>>>Think of the case of how a BGP sees an area. If an area is made up of:
>>>>
>>>>  A -- B -- C
>>>>
>>>>and B is internal router, does BGP "see" B?
>>>>
>>>>Zhi
>>>>
>>>>Yanhe Fan wrote:
>>>>
>>>>
>>>>>Hi, Zhi
>>>>>
>>>>>
>>>>>
>>>>>>For the label value for SONET/SDH or the label description in the
>>>>>>generic draft, the label is defined as directly representing the
>>>>>>"timeslot". Now if I have a control plane controlled transport network
>>>>>>that goes through a ADM that is not control plane controlled, as:
>>>>>>
>>>>>>
>>>>>>+--------+               +--------+               +--------+
>>>>>>|        | ---1--------- |        | ----1-------- |        |
>>>>>>|        | ---2--------- |        | ----2-------- |        |
>>>>>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>>>>>>|        | ---4--------- |        | ----4-------- |        |
>>>>>>|        | ---5--------- |        | ----5-------- |        |
>>>>>>+--------+               +--------+               +--------+
>>>>>>
>>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So
at
>>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and
C
>>>>>>has labels 1,2,3,4,5 incoming.
>>>>>>
>>>>>>Now imagine that at B, it actually has a fixed cross-connect that
>>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2
to
>>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>>>>>>
>>>>>>Now when A GMPLS sends a message to C, the label it uses is "1".
>>>>>>However, the connection/LSP associated with timeslot "1" is actually
the
>>>>>>label of timeslot "2" at C. </z>
>>>>>>
>>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node
>>>>>
>>>(B)
>>>
>>>>>which can't understand GMPLS.
>>>>>
>>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by
using
>>>>>GMPLS if B can't understand GMPLS?
>>>>>
>>>>>Now imagine A and B are LSRs, and B is a conventional router (can't
>>>>>understand
>>>>>MPLS), can you setup an LSP A-B-C?
>>>>>
>>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't
>>>>>understand PNNI at all?
>>>>>
>>>>>My point is that in order to make you case work, some additional work
>>>>>
>>>need
>>>
>>>>>to
>>>>>be done besie simply using GMPLS as singnaling protocol, becase some
>>>>>
>>>node
>>>
>>>>on
>>>>
>>>>>the path is not GMPLS speakers. A and C needs the info of time slot
>>>>>
>>>>aligment
>>>>
>>>>>between them. This can be done by some configurations, some link
>>>>>
>>>>management
>>>>
>>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info,
>>>>>eveything
>>>>>works fine.
>>>>>
>>>>>Yanhe
>>>>>
>>>>>
> 
> --
> Irfan Lateef
> Village Networks Inc,
> 
> 
> 
> 

Delivery-date: Wed, 24 Oct 2001 07:34:54 -0700
From: "Juergen Heiles" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: AW: Moving right along ...
Date: Wed, 24 Oct 2001 16:32:15 +0200

Eric,

may be I was not clear when I asked for common labels:

A STM-4 signal with higher order VC-3 and lower order VC-11 is identical to
a STS-12 with STS-1 SPEs and VT1.5-SPEs. They have the same multiplex
structure and recent SDH and SONET equipment that supports such signals can
accept both with out problems.
The same applies to a STM-16 with higher ordr VC-4 and a STS-48 with
STS-3c-SPEs.

However with the the current defintion we would get different SUKLM values
for SDH and SONET. That is what should be avoided.
You mentioned one/two stage multiplexing. This is an implementation issue.
The result always has to look like two-stage multiplexing, for SDH and
SONET.

The current proposal is based on one-stage multiplexing for SONET and
two-stage multiplexing for SDH. This is the differenc.

My original propsoal uses two stage multipelxing for both (align the SONET
label to the SDH label).
You said that it will result in problems forSONET in case of forwarding
adjacencies that are not STS-3xN (e.g. STS-4). Ok, but the current proposal
has the same problem for SDH AU3s when you use a forwarding adjacency that
is not 3xN AU-3 (e.g. 4 AU-3).
So we have to use the one-stage approach for both SONET and SDH in order to
avoid the problem.
Again we are back to the same SUKLM structure for SONET and SDH.

Regards

Juergen

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag
> von Mannie, Eric
> Gesendet: Mittwoch, 24. Oktober 2001 14:56
> An: [email-masked]'; [email-masked]'
> Betreff: FW: Moving right along ...
>
>
> Dear All,
>
> I had the feeling that the information is passing transformed
> from the IETF
> to the ITU-T. So, I am forwarding you this e-mail.
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Mannie, Eric
> Sent: Wednesday, October 24, 2001 1:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Moving right along ...
>
>
> Dear All,
>
> Let me strongly clarify something about the SDH/SONET label. I started to
> see and receive comments from people that obviously didn't read the text
> carefully, or get lost due to "non-technical" comments.
>
> Let's kill the rumor.
>
> 1. The draft defines ONE label format: SUKLM
>
> As explained in the draft the SONET multiplexing structure is seen as a
> subset of the SDH one. It is also said that S, L and M have a similar
> meaning for SONET and SDH. U and K are not significant for SONET. This is
> why we have on single label format for "SDH/SONET".
>
> 2. We claimed since the beginning that our goal was to have a
> common format
> for both:
>
> This is why this format was accepted, discussed and enhanced, and this was
> beginning of year 2000!
>
> 3. SDH and SONET have and will continue to have two different multiplexing
> structures:
>
>    - because there is no TUG-3 equivalent in SONET.
>    - because there is no VT-3 equivalent in SDH.
>
> This is a fact.
>
> So it results, that the label for SONET and SDH can be as similar as
> possible, given these two limitations. They will NEVER be completely
> identical because this is not physically possible. The proposal of Juergen
> doesn't change that.
>
> The only difference between the current text and the proposal of
> Juergen is
> that:
>
> - the current text uses the single stage interleaving approach of SONET.
> - Juergen's proposal uses the two-stage interleaving approach of SONET.
>
> That's the only difference. I already explained the reasons why
> we used the
> single stage interleaving approach.
>
> So please, don't tell me that "some people want to align the labels...",
> this is we made almost two years ago.
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 9:11 AM
> To: Irfan Lateef
> Cc: [email-masked]; [email-masked]
> Subject: Re: Moving right along ...
>
>
> Hi Irfan, good summary! I think (b) is probably right for some. I don't
> see (c) as been the case...
>
>  From one uninformed reader to another, I think the quote you had was a
> frustrated person stating what he thinks was implied by another
> frustrated person's statement (am I putting words in anyone's mouth?).
>
>  From what I understand G.ason and G.dcm is developed to describe the
> process and the minimal requirements needed to support a basic switched
> transport service. GMPLS is a protocol specific implementation that will
> likely meet many of the requirements, and may have some minor areas that
> it does not meet. Then the question to ask (as with any requirements and
> architecture work -- I'm sure we all have architects in our company) is:
> how critical are the requirements that may not be met and what changes
> are needed to GMPLS (if any) in order to meet them?
>
> The last few email exchanges I think has been process related: why are
> things added to GMPLS, who has authority to add. Why can't we make GMPLS
> drafts more clear to people reading these drafts?
>
> Of course there were also some fundamental issues, such as Juergen's
> desire to align the labels (which I agree with), Yangguang's question of
> why we are taking a fundamentally different approach for recovery since
> the "transport world" has done it one way for a long time and now it's
> suddenly changed & and authors not willing to discuss why the
> "traditional" way is not desired, and of course my desire to add
> clarifying text to the document to help uninformed reader like myself
> understand what SONET/SDH is all about (which is probably purely
> political rambling...)
>
> Zhi
>
>
> Irfan Lateef wrote:
>
> > A view from the side lines
> > -------------------------------
> >
> >   First, on the lighter side I have the following suggestion.
> >   we should change the subject line to any of the following,
> >   a. Stubbornly stuck - refusing to move forward
> >   b. Political Ramblings
> >   c. Serious Trouble
> >   d. Ugly email war among adults behaving like kids
> >   I vote for (b)
> >
> >   Now on the serious side, I have a few questions.
> >
> > 1. Does the chair of this WG think that this email thread is a necessary
> >    democratic step in the process.
> >
> > 2. If not, then why isn't somebody stepping in with a summary of issues
> >    and resolving them. Isn't there any arbitration process.
> >
> > 3. If the protocols are designed to be flexible to accomadate future
> changes,
> >    why aren't the authors treating "some of the" requests as part of the
> flexibility
> >
> >   and getting along.
> >
> > 4. I feel the authors were treating last call as a formality and are not
> ready
> >     to accept changes because it is a last call. Then what is the real
> intent of
> >     last call.
> >
> > 5. There seems to be a real disconnect between the needs of,
> >     a. vendors and service providers
> >     b. data vendors and transport vendors
> >     If GMPLS is for at least this three groups, then the issues
> need to be
> >     resolved to the satisfaction of this small set.
> >     (I personally agree with not spending 10 years trying to develop a
> panacea for
> > all)
> >
> > 6. And finally it is alarming to me to note the following assertion.
> >     "GMPLS wouldn't fit the ASON model... :-( "
> >     Can someone clarify the true import of this statement. My
> understanding was
> > GMPLS is
> >     the only thing on which ITU,OIF and IETF are on the same
> page. Can you
> please
> > correct
> >     me on this and clarify as am a truly "uninformed" person on this.
> >
> > Regards,
> > Irfan Lateef
> >
> > Maarten Vissers wrote:
> >
> >
> >>Eric,
> >>
> >>What you refer to as "our own model" is already developed by
> ITU-T SG15...
> it is
> >>in G.8080 (ex. G.ason) and other ASON related recommendations which will
> be
> >>approved later this week. We are also entering the next phase in ASON
> >>development; a phase in which protocol specific details will be
> defined. A
> >>proposal to use PNNI as a basis is accepted... and expected in the near
> future
> >>is a proposal to use also GMPLS as a 2nd protocol version... but if I
> understand
> >>your message, GMPLS wouldn't fit the ASON model... :-(
> >>
> >>It's good to know this beforehand... no need then to consider this
> further...
> >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and
> OTN details
> over
> >>the last 10 months... hope it's different however.
> >>
> >>Regards,
> >>
> >>Maarten
> >>PS. when I wrote my reply to Yanhe there was no frustation... and their
> isn't
> >>today either...
> >>
> >>"Mannie, Eric" wrote:
> >>
> >>>Hi Maarten and Zhi,
> >>>
> >>>I have the feeling that you are inventing a new model with a new
> protocol.
> >>>This is not how GMPLS works. I understand your frustrations and I have
> the
> >>>feeling that your ideas should be addressed somewhere else rather than
> >>>trying to change a model that we are finalizing and that we
> got from the
> >>>MPLS model.
> >>>
> >>>There are maybe 1000 ways of designing a control plane for transmission
> >>>networks. I would suggest that you first develop your own
> model and then
> >>>that we compare the two.
> >>>
> >>>Please, don't forget that we have here to be constructive in terms of
> GMPLS.
> >>>We have final discussions about the core GMPLS signaling, this
> is not the
> >>>beginning but the end of an (intermediate) phase.
> >>>
> >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean
> your
> >>>house :-) We know it. Personally, I don't believe in the ultimate model
> and
> >>>protocol that will do everything and that will take 10 years to be
> >>>specified, with abstract protocols, meta-models, etc.
> >>>
> >>>By the way, personally I don't see any benefit of defining these
> >>>meta-models, abstract models and abstract protocols. It is hard to
> >>>understand for non super-expert and it is a complete loss of
> time for the
> >>>readers. I prefer practical solutions.
> >>>
> >>>I am also seeing discussions that we already have many times
> in the past.
> I
> >>>don't see any benefit of having them again, and again, and again. If we
> >>>continue like this we will all implement a tool to answer automatically
> with
> >>>our previous e-mails :-)
> >>>
> >>>Ok, there is a small set of people that don't like the way
> that GMPLS is
> >>>designed and defined (always the same 4 or 5 people by the
> way) - that's
> >>>100% your right guys and I respect it. In comparison with the hundreds
> >>>(thousands ?) of people that are working on GMPLS and implementing it,
> this
> >>>is a great achievement !
> >>>
> >>>So, I ask you the question: what do you want to achieve personally at
> this
> >>>stage ? Don't you think that sometimes it is needed to finish one step,
> >>>before going to the next one ?
> >>>
> >>>Kind regards,
> >>>
> >>>Eric
> >>>
> >>>-----Original Message-----
> >>>From: Maarten Vissers [mailto:[email-masked]]
> >>>Sent: Monday, October 22, 2001 11:07 PM
> >>>To: Yanhe Fan
> >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
> >>>Subject: Re: Moving right along ...
> >>>
> >>>Yanhe,
> >>>
> >>>The situation Zhi describes is one that will be very typical in the
> optical
> >>>(SDH/SONET) network in the coming years. We will most likely
> see islands
> of
> >>>switched subnetworks interconnected via the existing SDH/SONET
> non-switched
> >>>networks. By means of management actions, links (GMPLS: link bundles)
> will
> >>>be
> >>>setup between an edge node in one switched subnetwork and an other edge
> node
> >>>in
> >>>the next switched subnetwork. In G.805 terminology, these links are so
> >>>called
> >>>serial compound links.
> >>>
> >>>The switched subnetworks will treat these serial compound
> links as normal
> >>>links,
> >>>"ignoring" the intermediate non-switched nodes they traverse.
> These links
> >>>will
> >>>contain a fixed set of link connections, which are identified by their
> >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
> >>>The server signal that carries the e.g. 5 STS1 link connections in the
> link
> >>>at A
> >>>can be an OC12, whereas this can be an OC48 at Z.
> >>>
> >>>During discovery or by means of provisioning both A and Z
> nodes get aware
> of
> >>>the
> >>>5 sTS1 link connections as tuples of e.g.
> >>>
> >>>        SNPa             SNPz
> >>>-----------------------------------
> >>>- port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
> >>>- port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
> >>>- port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
> >>>- port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
> >>>- port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
> >>>
> >>>As both ends of the link build up this same relation information, it is
> >>>possible
> >>>to use as link connection identifier only one of the two SNPs.
> E.g. node
> A
> >>>identifies the STS1 link connection #1 by means of "Ai/T1" and
> sends this
> >>>info
> >>>to node Z. Node Z receiving this Ai/T1 converts this locally into
> "Zj/Ta".
> >>>Vice
> >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
> >>>received
> >>>by node A, this will be converted into Ai/T1.
> >>>
> >>>For GMPLS this implies that the GMPLS label doesn't identify
> the timeslot
> at
> >>>both ends of the link connection, only the timeslot at the sending end.
> The
> >>>receiving end needs to convert this then into its local
> timeslot number.
> >>>
> >>>Regards,
> >>>
> >>>Maarten
> >>>
> >>>Yanhe Fan wrote:
> >>>
> >>>>Hi Zhi,
> >>>>
> >>>>What B does is breaking the label association between A and C by
> crossing
> >>>>connect
> >>>>the time slots.
> >>>>
> >>>>If the cross connect performed by B is fixed (in your case),
> what needs
> to
> >>>>do is
> >>>>just to rebuild the label association by configuration or a protocol
> such
> >>>>
> >>>as
> >>>
> >>>>LMP;
> >>>>If the cross connect is not fixed but dynamic, the best thing to do is
> to
> >>>>make B
> >>>>a GMPLS speaker.
> >>>>
> >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's
> transport
> >>>network... no chance... those will stay non-switched...
> >>>
> >>>
> >>>>Yanhe
> >>>>
> >>>>-----Original Message-----
> >>>>From: Zhi-Wei Lin [mailto:[email-masked]]
> >>>>Sent: Friday, October 19, 2001 6:01 PM
> >>>>To: Yanhe Fan
> >>>>Cc: John Drake; Kireeti Kompella; [email-masked]
> >>>>Subject: Re: Moving right along ...
> >>>>
> >>>>Hi Yanhe,
> >>>>
> >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> >>>>is simply part of the network that made up the "dumb" pipe.
> And because
> >>>>the control plane control channel is separate, A and C can be adjacent
> >>>>without ever knowing who B is or that even B existed. From A and C's
> >>>>point of view, the network looks like:
> >>>>
> >>>>  A ----- C
> >>>>
> >>>>Think of the case of how a BGP sees an area. If an area is made up of:
> >>>>
> >>>>  A -- B -- C
> >>>>
> >>>>and B is internal router, does BGP "see" B?
> >>>>
> >>>>Zhi
> >>>>
> >>>>Yanhe Fan wrote:
> >>>>
> >>>>
> >>>>>Hi, Zhi
> >>>>>
> >>>>>
> >>>>>
> >>>>>>For the label value for SONET/SDH or the label description in the
> >>>>>>generic draft, the label is defined as directly representing the
> >>>>>>"timeslot". Now if I have a control plane controlled
> transport network
> >>>>>>that goes through a ADM that is not control plane controlled, as:
> >>>>>>
> >>>>>>
> >>>>>>+--------+               +--------+               +--------+
> >>>>>>|        | ---1--------- |        | ----1-------- |        |
> >>>>>>|        | ---2--------- |        | ----2-------- |        |
> >>>>>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> >>>>>>|        | ---4--------- |        | ----4-------- |        |
> >>>>>>|        | ---5--------- |        | ----5-------- |        |
> >>>>>>+--------+               +--------+               +--------+
> >>>>>>
> >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So
> at
> >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM
> format) and
> C
> >>>>>>has labels 1,2,3,4,5 incoming.
> >>>>>>
> >>>>>>Now imagine that at B, it actually has a fixed cross-connect that
> >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming
> timeslot #2), A-2
> to
> >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> >>>>>>
> >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1".
> >>>>>>However, the connection/LSP associated with timeslot "1" is actually
> the
> >>>>>>label of timeslot "2" at C. </z>
> >>>>>>
> >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node
> >>>>>
> >>>(B)
> >>>
> >>>>>which can't understand GMPLS.
> >>>>>
> >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by
> using
> >>>>>GMPLS if B can't understand GMPLS?
> >>>>>
> >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't
> >>>>>understand
> >>>>>MPLS), can you setup an LSP A-B-C?
> >>>>>
> >>>>>Now imagine A, B and C are ATM switches, can you setup a svc
> if B can't
> >>>>>understand PNNI at all?
> >>>>>
> >>>>>My point is that in order to make you case work, some additional work
> >>>>>
> >>>need
> >>>
> >>>>>to
> >>>>>be done besie simply using GMPLS as singnaling protocol, becase some
> >>>>>
> >>>node
> >>>
> >>>>on
> >>>>
> >>>>>the path is not GMPLS speakers. A and C needs the info of time slot
> >>>>>
> >>>>aligment
> >>>>
> >>>>>between them. This can be done by some configurations, some link
> >>>>>
> >>>>management
> >>>>
> >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info,
> >>>>>eveything
> >>>>>works fine.
> >>>>>
> >>>>>Yanhe
> >>>>>
> >>>>>
> >
> > --
> > Irfan Lateef
> > Village Networks Inc,
> >
> >
> >
> >
>

Delivery-date: Wed, 24 Oct 2001 05:58:07 -0700
From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
To: "'Irfan Lateef'" <[email-masked]>, [email-masked]
Cc: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Wed, 24 Oct 2001 08:56:33 -0400

> why isn't somebody stepping in with a summary of issues
> and resolving them. Isn't there any arbitration process.

This is a good suggestion.  Perhaps some objective person (e.g., Kireeti)
could step in and help here.  Further repetition by commenters and authors
isn't really helping or needed.

Jerry Ash
AT&T Labs

Delivery-date: Wed, 24 Oct 2001 05:43:45 -0700
Date: Wed, 24 Oct 2001 14:41:53 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: "Mannie, Eric" <[email-masked]>
CC: "'Zhi-Wei Lin'" <[email-masked]>, Irfan Lateef <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------90AA354664CEBD1312A5D854
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Zhi,

I still don't understand the following you claim to be an "uninformed
reader which would like to know what SDH/Sonet is all about" but after
you are defending the Juergen's proposal.

How can an uninformed reader defend a technical solution for which he
requests more clarifying text to be become informed ? Are you an 
technically informed uninformed reader ;-) ?

Please clarify your position,
Dimitri.

"Mannie, Eric" wrote:
> 
> Hello Zhi,
> 
> > From one uninformed reader to another...  and of course my desire to add
> > clarifying text to the document to help uninformed reader like myself
> >understand what SONET/SDH is all about...
> 
> Is this a joke ? May I remind you that you and your colleagues where more
> than deeply involved in the SDH/SONET drafts, and also that you are listed
> among the co-authors of that draft. I am surprised to see that you are
> uninformed :-)
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 9:11 AM
> To: Irfan Lateef
> Cc: [email-masked]; [email-masked]
> Subject: Re: Moving right along ...
> 
> Hi Irfan, good summary! I think (b) is probably right for some. I don't
> see (c) as been the case...
> 
>  From one uninformed reader to another, I think the quote you had was a
> frustrated person stating what he thinks was implied by another
> frustrated person's statement (am I putting words in anyone's mouth?).
> 
>  From what I understand G.ason and G.dcm is developed to describe the
> process and the minimal requirements needed to support a basic switched
> transport service. GMPLS is a protocol specific implementation that will
> likely meet many of the requirements, and may have some minor areas that
> it does not meet. Then the question to ask (as with any requirements and
> architecture work -- I'm sure we all have architects in our company) is:
> how critical are the requirements that may not be met and what changes
> are needed to GMPLS (if any) in order to meet them?
> 
> The last few email exchanges I think has been process related: why are
> things added to GMPLS, who has authority to add. Why can't we make GMPLS
> drafts more clear to people reading these drafts?
> 
> Of course there were also some fundamental issues, such as Juergen's
> desire to align the labels (which I agree with), Yangguang's question of
> why we are taking a fundamentally different approach for recovery since
> the "transport world" has done it one way for a long time and now it's
> suddenly changed & and authors not willing to discuss why the
> "traditional" way is not desired, and of course my desire to add
> clarifying text to the document to help uninformed reader like myself
> understand what SONET/SDH is all about (which is probably purely
> political rambling...)
> 
> Zhi
> 
> Irfan Lateef wrote:
> 
> > A view from the side lines
> > -------------------------------
> >
> >   First, on the lighter side I have the following suggestion.
> >   we should change the subject line to any of the following,
> >   a. Stubbornly stuck - refusing to move forward
> >   b. Political Ramblings
> >   c. Serious Trouble
> >   d. Ugly email war among adults behaving like kids
> >   I vote for (b)
> >
> >   Now on the serious side, I have a few questions.
> >
> > 1. Does the chair of this WG think that this email thread is a necessary
> >    democratic step in the process.
> >
> > 2. If not, then why isn't somebody stepping in with a summary of issues
> >    and resolving them. Isn't there any arbitration process.
> >
> > 3. If the protocols are designed to be flexible to accomadate future
> changes,
> >    why aren't the authors treating "some of the" requests as part of the
> flexibility
> >
> >   and getting along.
> >
> > 4. I feel the authors were treating last call as a formality and are not
> ready
> >     to accept changes because it is a last call. Then what is the real
> intent of
> >     last call.
> >
> > 5. There seems to be a real disconnect between the needs of,
> >     a. vendors and service providers
> >     b. data vendors and transport vendors
> >     If GMPLS is for at least this three groups, then the issues need to be
> >     resolved to the satisfaction of this small set.
> >     (I personally agree with not spending 10 years trying to develop a
> panacea for
> > all)
> >
> > 6. And finally it is alarming to me to note the following assertion.
> >     "GMPLS wouldn't fit the ASON model... :-( "
> >     Can someone clarify the true import of this statement. My
> understanding was
> > GMPLS is
> >     the only thing on which ITU,OIF and IETF are on the same page. Can you
> please
> > correct
> >     me on this and clarify as am a truly "uninformed" person on this.
> >
> > Regards,
> > Irfan Lateef
> >
> > Maarten Vissers wrote:
> >
> >
> >>Eric,
> >>
> >>What you refer to as "our own model" is already developed by ITU-T SG15...
> it is
> >>in G.8080 (ex. G.ason) and other ASON related recommendations which will
> be
> >>approved later this week. We are also entering the next phase in ASON
> >>development; a phase in which protocol specific details will be defined. A
> >>proposal to use PNNI as a basis is accepted... and expected in the near
> future
> >>is a proposal to use also GMPLS as a 2nd protocol version... but if I
> understand
> >>your message, GMPLS wouldn't fit the ASON model... :-(
> >>
> >>It's good to know this beforehand... no need then to consider this
> further...
> >>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details
> over
> >>the last 10 months... hope it's different however.
> >>
> >>Regards,
> >>
> >>Maarten
> >>PS. when I wrote my reply to Yanhe there was no frustation... and their
> isn't
> >>today either...
> >>
> >>"Mannie, Eric" wrote:
> >>
> >>>Hi Maarten and Zhi,
> >>>
> >>>I have the feeling that you are inventing a new model with a new
> protocol.
> >>>This is not how GMPLS works. I understand your frustrations and I have
> the
> >>>feeling that your ideas should be addressed somewhere else rather than
> >>>trying to change a model that we are finalizing and that we got from the
> >>>MPLS model.
> >>>
> >>>There are maybe 1000 ways of designing a control plane for transmission
> >>>networks. I would suggest that you first develop your own model and then
> >>>that we compare the two.
> >>>
> >>>Please, don't forget that we have here to be constructive in terms of
> GMPLS.
> >>>We have final discussions about the core GMPLS signaling, this is not the
> >>>beginning but the end of an (intermediate) phase.
> >>>
> >>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean
> your
> >>>house :-) We know it. Personally, I don't believe in the ultimate model
> and
> >>>protocol that will do everything and that will take 10 years to be
> >>>specified, with abstract protocols, meta-models, etc.
> >>>
> >>>By the way, personally I don't see any benefit of defining these
> >>>meta-models, abstract models and abstract protocols. It is hard to
> >>>understand for non super-expert and it is a complete loss of time for the
> >>>readers. I prefer practical solutions.
> >>>
> >>>I am also seeing discussions that we already have many times in the past.
> I
> >>>don't see any benefit of having them again, and again, and again. If we
> >>>continue like this we will all implement a tool to answer automatically
> with
> >>>our previous e-mails :-)
> >>>
> >>>Ok, there is a small set of people that don't like the way that GMPLS is
> >>>designed and defined (always the same 4 or 5 people by the way) - that's
> >>>100% your right guys and I respect it. In comparison with the hundreds
> >>>(thousands ?) of people that are working on GMPLS and implementing it,
> this
> >>>is a great achievement !
> >>>
> >>>So, I ask you the question: what do you want to achieve personally at
> this
> >>>stage ? Don't you think that sometimes it is needed to finish one step,
> >>>before going to the next one ?
> >>>
> >>>Kind regards,
> >>>
> >>>Eric
> >>>
> >>>-----Original Message-----
> >>>From: Maarten Vissers [mailto:[email-masked]]
> >>>Sent: Monday, October 22, 2001 11:07 PM
> >>>To: Yanhe Fan
> >>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
> >>>Subject: Re: Moving right along ...
> >>>
> >>>Yanhe,
> >>>
> >>>The situation Zhi describes is one that will be very typical in the
> optical
> >>>(SDH/SONET) network in the coming years. We will most likely see islands
> of
> >>>switched subnetworks interconnected via the existing SDH/SONET
> non-switched
> >>>networks. By means of management actions, links (GMPLS: link bundles)
> will
> >>>be
> >>>setup between an edge node in one switched subnetwork and an other edge
> node
> >>>in
> >>>the next switched subnetwork. In G.805 terminology, these links are so
> >>>called
> >>>serial compound links.
> >>>
> >>>The switched subnetworks will treat these serial compound links as normal
> >>>links,
> >>>"ignoring" the intermediate non-switched nodes they traverse. These links
> >>>will
> >>>contain a fixed set of link connections, which are identified by their
> >>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
> >>>The server signal that carries the e.g. 5 STS1 link connections in the
> link
> >>>at A
> >>>can be an OC12, whereas this can be an OC48 at Z.
> >>>
> >>>During discovery or by means of provisioning both A and Z nodes get aware
> of
> >>>the
> >>>5 sTS1 link connections as tuples of e.g.
> >>>
> >>>        SNPa             SNPz
> >>>-----------------------------------
> >>>- port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
> >>>- port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
> >>>- port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
> >>>- port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
> >>>- port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
> >>>
> >>>As both ends of the link build up this same relation information, it is
> >>>possible
> >>>to use as link connection identifier only one of the two SNPs. E.g. node
> A
> >>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
> >>>info
> >>>to node Z. Node Z receiving this Ai/T1 converts this locally into
> "Zj/Ta".
> >>>Vice
> >>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
> >>>received
> >>>by node A, this will be converted into Ai/T1.
> >>>
> >>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot
> at
> >>>both ends of the link connection, only the timeslot at the sending end.
> The
> >>>receiving end needs to convert this then into its local timeslot number.
> >>>
> >>>Regards,
> >>>
> >>>Maarten
> >>>
> >>>Yanhe Fan wrote:
> >>>
> >>>>Hi Zhi,
> >>>>
> >>>>What B does is breaking the label association between A and C by
> crossing
> >>>>connect
> >>>>the time slots.
> >>>>
> >>>>If the cross connect performed by B is fixed (in your case), what needs
> to
> >>>>do is
> >>>>just to rebuild the label association by configuration or a protocol
> such
> >>>>
> >>>as
> >>>
> >>>>LMP;
> >>>>If the cross connect is not fixed but dynamic, the best thing to do is
> to
> >>>>make B
> >>>>a GMPLS speaker.
> >>>>
> >>>Tell this to the 1.000.000+ SDH/SONET network elements in today's
> transport
> >>>network... no chance... those will stay non-switched...
> >>>
> >>>
> >>>>Yanhe
> >>>>
> >>>>-----Original Message-----
> >>>>From: Zhi-Wei Lin [mailto:[email-masked]]
> >>>>Sent: Friday, October 19, 2001 6:01 PM
> >>>>To: Yanhe Fan
> >>>>Cc: John Drake; Kireeti Kompella; [email-masked]
> >>>>Subject: Re: Moving right along ...
> >>>>
> >>>>Hi Yanhe,
> >>>>
> >>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> >>>>is simply part of the network that made up the "dumb" pipe. And because
> >>>>the control plane control channel is separate, A and C can be adjacent
> >>>>without ever knowing who B is or that even B existed. From A and C's
> >>>>point of view, the network looks like:
> >>>>
> >>>>  A ----- C
> >>>>
> >>>>Think of the case of how a BGP sees an area. If an area is made up of:
> >>>>
> >>>>  A -- B -- C
> >>>>
> >>>>and B is internal router, does BGP "see" B?
> >>>>
> >>>>Zhi
> >>>>
> >>>>Yanhe Fan wrote:
> >>>>
> >>>>
> >>>>>Hi, Zhi
> >>>>>
> >>>>>
> >>>>>
> >>>>>>For the label value for SONET/SDH or the label description in the
> >>>>>>generic draft, the label is defined as directly representing the
> >>>>>>"timeslot". Now if I have a control plane controlled transport network
> >>>>>>that goes through a ADM that is not control plane controlled, as:
> >>>>>>
> >>>>>>
> >>>>>>+--------+               +--------+               +--------+
> >>>>>>|        | ---1--------- |        | ----1-------- |        |
> >>>>>>|        | ---2--------- |        | ----2-------- |        |
> >>>>>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> >>>>>>|        | ---4--------- |        | ----4-------- |        |
> >>>>>>|        | ---5--------- |        | ----5-------- |        |
> >>>>>>+--------+               +--------+               +--------+
> >>>>>>
> >>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So
> at
> >>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and
> C
> >>>>>>has labels 1,2,3,4,5 incoming.
> >>>>>>
> >>>>>>Now imagine that at B, it actually has a fixed cross-connect that
> >>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2
> to
> >>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> >>>>>>
> >>>>>>Now when A GMPLS sends a message to C, the label it uses is "1".
> >>>>>>However, the connection/LSP associated with timeslot "1" is actually
> the
> >>>>>>label of timeslot "2" at C. </z>
> >>>>>>
> >>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node
> >>>>>
> >>>(B)
> >>>
> >>>>>which can't understand GMPLS.
> >>>>>
> >>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by
> using
> >>>>>GMPLS if B can't understand GMPLS?
> >>>>>
> >>>>>Now imagine A and B are LSRs, and B is a conventional router (can't
> >>>>>understand
> >>>>>MPLS), can you setup an LSP A-B-C?
> >>>>>
> >>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> >>>>>understand PNNI at all?
> >>>>>
> >>>>>My point is that in order to make you case work, some additional work
> >>>>>
> >>>need
> >>>
> >>>>>to
> >>>>>be done besie simply using GMPLS as singnaling protocol, becase some
> >>>>>
> >>>node
> >>>
> >>>>on
> >>>>
> >>>>>the path is not GMPLS speakers. A and C needs the info of time slot
> >>>>>
> >>>>aligment
> >>>>
> >>>>>between them. This can be done by some configurations, some link
> >>>>>
> >>>>management
> >>>>
> >>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info,
> >>>>>eveything
> >>>>>works fine.
> >>>>>
> >>>>>Yanhe
> >>>>>
> >>>>>
> >
> > --
> > Irfan Lateef
> > Village Networks Inc,
> >
> >
> >
> >
--------------90AA354664CEBD1312A5D854
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------90AA354664CEBD1312A5D854--

Delivery-date: Wed, 24 Oct 2001 05:23:40 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, Irfan Lateef <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Moving right along ...
Date: Wed, 24 Oct 2001 14:22:34 +0200

Hello Zhi,

> From one uninformed reader to another...  and of course my desire to add 
> clarifying text to the document to help uninformed reader like myself 
>understand what SONET/SDH is all about...

Is this a joke ? May I remind you that you and your colleagues where more
than deeply involved in the SDH/SONET drafts, and also that you are listed
among the co-authors of that draft. I am surprised to see that you are
uninformed :-)

Kind regards,

Eric

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 9:11 AM
To: Irfan Lateef
Cc: [email-masked]; [email-masked]
Subject: Re: Moving right along ...

Hi Irfan, good summary! I think (b) is probably right for some. I don't 
see (c) as been the case...

 From one uninformed reader to another, I think the quote you had was a 
frustrated person stating what he thinks was implied by another 
frustrated person's statement (am I putting words in anyone's mouth?).

 From what I understand G.ason and G.dcm is developed to describe the 
process and the minimal requirements needed to support a basic switched 
transport service. GMPLS is a protocol specific implementation that will 
likely meet many of the requirements, and may have some minor areas that 
it does not meet. Then the question to ask (as with any requirements and 
architecture work -- I'm sure we all have architects in our company) is: 
how critical are the requirements that may not be met and what changes 
are needed to GMPLS (if any) in order to meet them?

The last few email exchanges I think has been process related: why are 
things added to GMPLS, who has authority to add. Why can't we make GMPLS 
drafts more clear to people reading these drafts?

Of course there were also some fundamental issues, such as Juergen's 
desire to align the labels (which I agree with), Yangguang's question of 
why we are taking a fundamentally different approach for recovery since 
the "transport world" has done it one way for a long time and now it's 
suddenly changed & and authors not willing to discuss why the 
"traditional" way is not desired, and of course my desire to add 
clarifying text to the document to help uninformed reader like myself 
understand what SONET/SDH is all about (which is probably purely 
political rambling...)

Zhi

Irfan Lateef wrote:

> A view from the side lines
> -------------------------------
> 
>   First, on the lighter side I have the following suggestion.
>   we should change the subject line to any of the following,
>   a. Stubbornly stuck - refusing to move forward
>   b. Political Ramblings
>   c. Serious Trouble
>   d. Ugly email war among adults behaving like kids
>   I vote for (b)
> 
>   Now on the serious side, I have a few questions.
> 
> 1. Does the chair of this WG think that this email thread is a necessary
>    democratic step in the process.
> 
> 2. If not, then why isn't somebody stepping in with a summary of issues
>    and resolving them. Isn't there any arbitration process.
> 
> 3. If the protocols are designed to be flexible to accomadate future
changes,
>    why aren't the authors treating "some of the" requests as part of the
flexibility
> 
>   and getting along.
> 
> 4. I feel the authors were treating last call as a formality and are not
ready
>     to accept changes because it is a last call. Then what is the real
intent of
>     last call.
> 
> 5. There seems to be a real disconnect between the needs of,
>     a. vendors and service providers
>     b. data vendors and transport vendors
>     If GMPLS is for at least this three groups, then the issues need to be
>     resolved to the satisfaction of this small set.
>     (I personally agree with not spending 10 years trying to develop a
panacea for
> all)
> 
> 6. And finally it is alarming to me to note the following assertion.
>     "GMPLS wouldn't fit the ASON model... :-( "
>     Can someone clarify the true import of this statement. My
understanding was
> GMPLS is
>     the only thing on which ITU,OIF and IETF are on the same page. Can you
please
> correct
>     me on this and clarify as am a truly "uninformed" person on this.
> 
> Regards,
> Irfan Lateef
> 
> Maarten Vissers wrote:
> 
> 
>>Eric,
>>
>>What you refer to as "our own model" is already developed by ITU-T SG15...
it is
>>in G.8080 (ex. G.ason) and other ASON related recommendations which will
be
>>approved later this week. We are also entering the next phase in ASON
>>development; a phase in which protocol specific details will be defined. A
>>proposal to use PNNI as a basis is accepted... and expected in the near
future
>>is a proposal to use also GMPLS as a 2nd protocol version... but if I
understand
>>your message, GMPLS wouldn't fit the ASON model... :-(
>>
>>It's good to know this beforehand... no need then to consider this
further...
>>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details
over
>>the last 10 months... hope it's different however.
>>
>>Regards,
>>
>>Maarten
>>PS. when I wrote my reply to Yanhe there was no frustation... and their
isn't
>>today either...
>>
>>"Mannie, Eric" wrote:
>>
>>>Hi Maarten and Zhi,
>>>
>>>I have the feeling that you are inventing a new model with a new
protocol.
>>>This is not how GMPLS works. I understand your frustrations and I have
the
>>>feeling that your ideas should be addressed somewhere else rather than
>>>trying to change a model that we are finalizing and that we got from the
>>>MPLS model.
>>>
>>>There are maybe 1000 ways of designing a control plane for transmission
>>>networks. I would suggest that you first develop your own model and then
>>>that we compare the two.
>>>
>>>Please, don't forget that we have here to be constructive in terms of
GMPLS.
>>>We have final discussions about the core GMPLS signaling, this is not the
>>>beginning but the end of an (intermediate) phase.
>>>
>>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean
your
>>>house :-) We know it. Personally, I don't believe in the ultimate model
and
>>>protocol that will do everything and that will take 10 years to be
>>>specified, with abstract protocols, meta-models, etc.
>>>
>>>By the way, personally I don't see any benefit of defining these
>>>meta-models, abstract models and abstract protocols. It is hard to
>>>understand for non super-expert and it is a complete loss of time for the
>>>readers. I prefer practical solutions.
>>>
>>>I am also seeing discussions that we already have many times in the past.
I
>>>don't see any benefit of having them again, and again, and again. If we
>>>continue like this we will all implement a tool to answer automatically
with
>>>our previous e-mails :-)
>>>
>>>Ok, there is a small set of people that don't like the way that GMPLS is
>>>designed and defined (always the same 4 or 5 people by the way) - that's
>>>100% your right guys and I respect it. In comparison with the hundreds
>>>(thousands ?) of people that are working on GMPLS and implementing it,
this
>>>is a great achievement !
>>>
>>>So, I ask you the question: what do you want to achieve personally at
this
>>>stage ? Don't you think that sometimes it is needed to finish one step,
>>>before going to the next one ?
>>>
>>>Kind regards,
>>>
>>>Eric
>>>
>>>-----Original Message-----
>>>From: Maarten Vissers [mailto:[email-masked]]
>>>Sent: Monday, October 22, 2001 11:07 PM
>>>To: Yanhe Fan
>>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ...
>>>
>>>Yanhe,
>>>
>>>The situation Zhi describes is one that will be very typical in the
optical
>>>(SDH/SONET) network in the coming years. We will most likely see islands
of
>>>switched subnetworks interconnected via the existing SDH/SONET
non-switched
>>>networks. By means of management actions, links (GMPLS: link bundles)
will
>>>be
>>>setup between an edge node in one switched subnetwork and an other edge
node
>>>in
>>>the next switched subnetwork. In G.805 terminology, these links are so
>>>called
>>>serial compound links.
>>>
>>>The switched subnetworks will treat these serial compound links as normal
>>>links,
>>>"ignoring" the intermediate non-switched nodes they traverse. These links
>>>will
>>>contain a fixed set of link connections, which are identified by their
>>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
>>>The server signal that carries the e.g. 5 STS1 link connections in the
link
>>>at A
>>>can be an OC12, whereas this can be an OC48 at Z.
>>>
>>>During discovery or by means of provisioning both A and Z nodes get aware
of
>>>the
>>>5 sTS1 link connections as tuples of e.g.
>>>
>>>        SNPa             SNPz
>>>-----------------------------------
>>>- port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
>>>- port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
>>>- port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
>>>- port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
>>>- port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
>>>
>>>As both ends of the link build up this same relation information, it is
>>>possible
>>>to use as link connection identifier only one of the two SNPs. E.g. node
A
>>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
>>>info
>>>to node Z. Node Z receiving this Ai/T1 converts this locally into
"Zj/Ta".
>>>Vice
>>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
>>>received
>>>by node A, this will be converted into Ai/T1.
>>>
>>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot
at
>>>both ends of the link connection, only the timeslot at the sending end.
The
>>>receiving end needs to convert this then into its local timeslot number.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>Yanhe Fan wrote:
>>>
>>>>Hi Zhi,
>>>>
>>>>What B does is breaking the label association between A and C by
crossing
>>>>connect
>>>>the time slots.
>>>>
>>>>If the cross connect performed by B is fixed (in your case), what needs
to
>>>>do is
>>>>just to rebuild the label association by configuration or a protocol
such
>>>>
>>>as
>>>
>>>>LMP;
>>>>If the cross connect is not fixed but dynamic, the best thing to do is
to
>>>>make B
>>>>a GMPLS speaker.
>>>>
>>>Tell this to the 1.000.000+ SDH/SONET network elements in today's
transport
>>>network... no chance... those will stay non-switched...
>>>
>>>
>>>>Yanhe
>>>>
>>>>-----Original Message-----
>>>>From: Zhi-Wei Lin [mailto:[email-masked]]
>>>>Sent: Friday, October 19, 2001 6:01 PM
>>>>To: Yanhe Fan
>>>>Cc: John Drake; Kireeti Kompella; [email-masked]
>>>>Subject: Re: Moving right along ...
>>>>
>>>>Hi Yanhe,
>>>>
>>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
>>>>is simply part of the network that made up the "dumb" pipe. And because
>>>>the control plane control channel is separate, A and C can be adjacent
>>>>without ever knowing who B is or that even B existed. From A and C's
>>>>point of view, the network looks like:
>>>>
>>>>  A ----- C
>>>>
>>>>Think of the case of how a BGP sees an area. If an area is made up of:
>>>>
>>>>  A -- B -- C
>>>>
>>>>and B is internal router, does BGP "see" B?
>>>>
>>>>Zhi
>>>>
>>>>Yanhe Fan wrote:
>>>>
>>>>
>>>>>Hi, Zhi
>>>>>
>>>>>
>>>>>
>>>>>>For the label value for SONET/SDH or the label description in the
>>>>>>generic draft, the label is defined as directly representing the
>>>>>>"timeslot". Now if I have a control plane controlled transport network
>>>>>>that goes through a ADM that is not control plane controlled, as:
>>>>>>
>>>>>>
>>>>>>+--------+               +--------+               +--------+
>>>>>>|        | ---1--------- |        | ----1-------- |        |
>>>>>>|        | ---2--------- |        | ----2-------- |        |
>>>>>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>>>>>>|        | ---4--------- |        | ----4-------- |        |
>>>>>>|        | ---5--------- |        | ----5-------- |        |
>>>>>>+--------+               +--------+               +--------+
>>>>>>
>>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So
at
>>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and
C
>>>>>>has labels 1,2,3,4,5 incoming.
>>>>>>
>>>>>>Now imagine that at B, it actually has a fixed cross-connect that
>>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2
to
>>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>>>>>>
>>>>>>Now when A GMPLS sends a message to C, the label it uses is "1".
>>>>>>However, the connection/LSP associated with timeslot "1" is actually
the
>>>>>>label of timeslot "2" at C. </z>
>>>>>>
>>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node
>>>>>
>>>(B)
>>>
>>>>>which can't understand GMPLS.
>>>>>
>>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by
using
>>>>>GMPLS if B can't understand GMPLS?
>>>>>
>>>>>Now imagine A and B are LSRs, and B is a conventional router (can't
>>>>>understand
>>>>>MPLS), can you setup an LSP A-B-C?
>>>>>
>>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't
>>>>>understand PNNI at all?
>>>>>
>>>>>My point is that in order to make you case work, some additional work
>>>>>
>>>need
>>>
>>>>>to
>>>>>be done besie simply using GMPLS as singnaling protocol, becase some
>>>>>
>>>node
>>>
>>>>on
>>>>
>>>>>the path is not GMPLS speakers. A and C needs the info of time slot
>>>>>
>>>>aligment
>>>>
>>>>>between them. This can be done by some configurations, some link
>>>>>
>>>>management
>>>>
>>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info,
>>>>>eveything
>>>>>works fine.
>>>>>
>>>>>Yanhe
>>>>>
>>>>>
> 
> --
> Irfan Lateef
> Village Networks Inc,
> 
> 
> 
> 

Delivery-date: Wed, 24 Oct 2001 04:52:55 -0700
From: "Mannie, Eric" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Wed, 24 Oct 2001 13:49:54 +0200

Dear All,

Let me strongly clarify something about the SDH/SONET label. I started to
see and receive comments from people that obviously didn't read the text
carefully, or get lost due to "non-technical" comments.

Let's kill the rumor. 

1. The draft defines ONE label format: SUKLM

As explained in the draft the SONET multiplexing structure is seen as a
subset of the SDH one. It is also said that S, L and M have a similar
meaning for SONET and SDH. U and K are not significant for SONET. This is
why we have on single label format for "SDH/SONET".

2. We claimed since the beginning that our goal was to have a common format
for both:

This is why this format was accepted, discussed and enhanced, and this was
beginning of year 2000!

3. SDH and SONET have and will continue to have two different multiplexing
structures:

   - because there is no TUG-3 equivalent in SONET.
   - because there is no VT-3 equivalent in SDH.

This is a fact.

So it results, that the label for SONET and SDH can be as similar as
possible, given these two limitations. They will NEVER be completely
identical because this is not physically possible. The proposal of Juergen
doesn't change that.

The only difference between the current text and the proposal of Juergen is
that:

- the current text uses the single stage interleaving approach of SONET.
- Juergen's proposal uses the two-stage interleaving approach of SONET.

That's the only difference. I already explained the reasons why we used the
single stage interleaving approach.

So please, don't tell me that "some people want to align the labels...",
this is we made almost two years ago.

Kind regards,

Eric

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 9:11 AM
To: Irfan Lateef
Cc: [email-masked]; [email-masked]
Subject: Re: Moving right along ...

Hi Irfan, good summary! I think (b) is probably right for some. I don't 
see (c) as been the case...

 From one uninformed reader to another, I think the quote you had was a 
frustrated person stating what he thinks was implied by another 
frustrated person's statement (am I putting words in anyone's mouth?).

 From what I understand G.ason and G.dcm is developed to describe the 
process and the minimal requirements needed to support a basic switched 
transport service. GMPLS is a protocol specific implementation that will 
likely meet many of the requirements, and may have some minor areas that 
it does not meet. Then the question to ask (as with any requirements and 
architecture work -- I'm sure we all have architects in our company) is: 
how critical are the requirements that may not be met and what changes 
are needed to GMPLS (if any) in order to meet them?

The last few email exchanges I think has been process related: why are 
things added to GMPLS, who has authority to add. Why can't we make GMPLS 
drafts more clear to people reading these drafts?

Of course there were also some fundamental issues, such as Juergen's 
desire to align the labels (which I agree with), Yangguang's question of 
why we are taking a fundamentally different approach for recovery since 
the "transport world" has done it one way for a long time and now it's 
suddenly changed & and authors not willing to discuss why the 
"traditional" way is not desired, and of course my desire to add 
clarifying text to the document to help uninformed reader like myself 
understand what SONET/SDH is all about (which is probably purely 
political rambling...)

Zhi

Irfan Lateef wrote:

> A view from the side lines
> -------------------------------
> 
>   First, on the lighter side I have the following suggestion.
>   we should change the subject line to any of the following,
>   a. Stubbornly stuck - refusing to move forward
>   b. Political Ramblings
>   c. Serious Trouble
>   d. Ugly email war among adults behaving like kids
>   I vote for (b)
> 
>   Now on the serious side, I have a few questions.
> 
> 1. Does the chair of this WG think that this email thread is a necessary
>    democratic step in the process.
> 
> 2. If not, then why isn't somebody stepping in with a summary of issues
>    and resolving them. Isn't there any arbitration process.
> 
> 3. If the protocols are designed to be flexible to accomadate future
changes,
>    why aren't the authors treating "some of the" requests as part of the
flexibility
> 
>   and getting along.
> 
> 4. I feel the authors were treating last call as a formality and are not
ready
>     to accept changes because it is a last call. Then what is the real
intent of
>     last call.
> 
> 5. There seems to be a real disconnect between the needs of,
>     a. vendors and service providers
>     b. data vendors and transport vendors
>     If GMPLS is for at least this three groups, then the issues need to be
>     resolved to the satisfaction of this small set.
>     (I personally agree with not spending 10 years trying to develop a
panacea for
> all)
> 
> 6. And finally it is alarming to me to note the following assertion.
>     "GMPLS wouldn't fit the ASON model... :-( "
>     Can someone clarify the true import of this statement. My
understanding was
> GMPLS is
>     the only thing on which ITU,OIF and IETF are on the same page. Can you
please
> correct
>     me on this and clarify as am a truly "uninformed" person on this.
> 
> Regards,
> Irfan Lateef
> 
> Maarten Vissers wrote:
> 
> 
>>Eric,
>>
>>What you refer to as "our own model" is already developed by ITU-T SG15...
it is
>>in G.8080 (ex. G.ason) and other ASON related recommendations which will
be
>>approved later this week. We are also entering the next phase in ASON
>>development; a phase in which protocol specific details will be defined. A
>>proposal to use PNNI as a basis is accepted... and expected in the near
future
>>is a proposal to use also GMPLS as a 2nd protocol version... but if I
understand
>>your message, GMPLS wouldn't fit the ASON model... :-(
>>
>>It's good to know this beforehand... no need then to consider this
further...
>>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details
over
>>the last 10 months... hope it's different however.
>>
>>Regards,
>>
>>Maarten
>>PS. when I wrote my reply to Yanhe there was no frustation... and their
isn't
>>today either...
>>
>>"Mannie, Eric" wrote:
>>
>>>Hi Maarten and Zhi,
>>>
>>>I have the feeling that you are inventing a new model with a new
protocol.
>>>This is not how GMPLS works. I understand your frustrations and I have
the
>>>feeling that your ideas should be addressed somewhere else rather than
>>>trying to change a model that we are finalizing and that we got from the
>>>MPLS model.
>>>
>>>There are maybe 1000 ways of designing a control plane for transmission
>>>networks. I would suggest that you first develop your own model and then
>>>that we compare the two.
>>>
>>>Please, don't forget that we have here to be constructive in terms of
GMPLS.
>>>We have final discussions about the core GMPLS signaling, this is not the
>>>beginning but the end of an (intermediate) phase.
>>>
>>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean
your
>>>house :-) We know it. Personally, I don't believe in the ultimate model
and
>>>protocol that will do everything and that will take 10 years to be
>>>specified, with abstract protocols, meta-models, etc.
>>>
>>>By the way, personally I don't see any benefit of defining these
>>>meta-models, abstract models and abstract protocols. It is hard to
>>>understand for non super-expert and it is a complete loss of time for the
>>>readers. I prefer practical solutions.
>>>
>>>I am also seeing discussions that we already have many times in the past.
I
>>>don't see any benefit of having them again, and again, and again. If we
>>>continue like this we will all implement a tool to answer automatically
with
>>>our previous e-mails :-)
>>>
>>>Ok, there is a small set of people that don't like the way that GMPLS is
>>>designed and defined (always the same 4 or 5 people by the way) - that's
>>>100% your right guys and I respect it. In comparison with the hundreds
>>>(thousands ?) of people that are working on GMPLS and implementing it,
this
>>>is a great achievement !
>>>
>>>So, I ask you the question: what do you want to achieve personally at
this
>>>stage ? Don't you think that sometimes it is needed to finish one step,
>>>before going to the next one ?
>>>
>>>Kind regards,
>>>
>>>Eric
>>>
>>>-----Original Message-----
>>>From: Maarten Vissers [mailto:[email-masked]]
>>>Sent: Monday, October 22, 2001 11:07 PM
>>>To: Yanhe Fan
>>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ...
>>>
>>>Yanhe,
>>>
>>>The situation Zhi describes is one that will be very typical in the
optical
>>>(SDH/SONET) network in the coming years. We will most likely see islands
of
>>>switched subnetworks interconnected via the existing SDH/SONET
non-switched
>>>networks. By means of management actions, links (GMPLS: link bundles)
will
>>>be
>>>setup between an edge node in one switched subnetwork and an other edge
node
>>>in
>>>the next switched subnetwork. In G.805 terminology, these links are so
>>>called
>>>serial compound links.
>>>
>>>The switched subnetworks will treat these serial compound links as normal
>>>links,
>>>"ignoring" the intermediate non-switched nodes they traverse. These links
>>>will
>>>contain a fixed set of link connections, which are identified by their
>>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
>>>The server signal that carries the e.g. 5 STS1 link connections in the
link
>>>at A
>>>can be an OC12, whereas this can be an OC48 at Z.
>>>
>>>During discovery or by means of provisioning both A and Z nodes get aware
of
>>>the
>>>5 sTS1 link connections as tuples of e.g.
>>>
>>>        SNPa             SNPz
>>>-----------------------------------
>>>- port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
>>>- port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
>>>- port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
>>>- port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
>>>- port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
>>>
>>>As both ends of the link build up this same relation information, it is
>>>possible
>>>to use as link connection identifier only one of the two SNPs. E.g. node
A
>>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
>>>info
>>>to node Z. Node Z receiving this Ai/T1 converts this locally into
"Zj/Ta".
>>>Vice
>>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
>>>received
>>>by node A, this will be converted into Ai/T1.
>>>
>>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot
at
>>>both ends of the link connection, only the timeslot at the sending end.
The
>>>receiving end needs to convert this then into its local timeslot number.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>Yanhe Fan wrote:
>>>
>>>>Hi Zhi,
>>>>
>>>>What B does is breaking the label association between A and C by
crossing
>>>>connect
>>>>the time slots.
>>>>
>>>>If the cross connect performed by B is fixed (in your case), what needs
to
>>>>do is
>>>>just to rebuild the label association by configuration or a protocol
such
>>>>
>>>as
>>>
>>>>LMP;
>>>>If the cross connect is not fixed but dynamic, the best thing to do is
to
>>>>make B
>>>>a GMPLS speaker.
>>>>
>>>Tell this to the 1.000.000+ SDH/SONET network elements in today's
transport
>>>network... no chance... those will stay non-switched...
>>>
>>>
>>>>Yanhe
>>>>
>>>>-----Original Message-----
>>>>From: Zhi-Wei Lin [mailto:[email-masked]]
>>>>Sent: Friday, October 19, 2001 6:01 PM
>>>>To: Yanhe Fan
>>>>Cc: John Drake; Kireeti Kompella; [email-masked]
>>>>Subject: Re: Moving right along ...
>>>>
>>>>Hi Yanhe,
>>>>
>>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
>>>>is simply part of the network that made up the "dumb" pipe. And because
>>>>the control plane control channel is separate, A and C can be adjacent
>>>>without ever knowing who B is or that even B existed. From A and C's
>>>>point of view, the network looks like:
>>>>
>>>>  A ----- C
>>>>
>>>>Think of the case of how a BGP sees an area. If an area is made up of:
>>>>
>>>>  A -- B -- C
>>>>
>>>>and B is internal router, does BGP "see" B?
>>>>
>>>>Zhi
>>>>
>>>>Yanhe Fan wrote:
>>>>
>>>>
>>>>>Hi, Zhi
>>>>>
>>>>>
>>>>>
>>>>>>For the label value for SONET/SDH or the label description in the
>>>>>>generic draft, the label is defined as directly representing the
>>>>>>"timeslot". Now if I have a control plane controlled transport network
>>>>>>that goes through a ADM that is not control plane controlled, as:
>>>>>>
>>>>>>
>>>>>>+--------+               +--------+               +--------+
>>>>>>|        | ---1--------- |        | ----1-------- |        |
>>>>>>|        | ---2--------- |        | ----2-------- |        |
>>>>>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>>>>>>|        | ---4--------- |        | ----4-------- |        |
>>>>>>|        | ---5--------- |        | ----5-------- |        |
>>>>>>+--------+               +--------+               +--------+
>>>>>>
>>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So
at
>>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and
C
>>>>>>has labels 1,2,3,4,5 incoming.
>>>>>>
>>>>>>Now imagine that at B, it actually has a fixed cross-connect that
>>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2
to
>>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>>>>>>
>>>>>>Now when A GMPLS sends a message to C, the label it uses is "1".
>>>>>>However, the connection/LSP associated with timeslot "1" is actually
the
>>>>>>label of timeslot "2" at C. </z>
>>>>>>
>>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node
>>>>>
>>>(B)
>>>
>>>>>which can't understand GMPLS.
>>>>>
>>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by
using
>>>>>GMPLS if B can't understand GMPLS?
>>>>>
>>>>>Now imagine A and B are LSRs, and B is a conventional router (can't
>>>>>understand
>>>>>MPLS), can you setup an LSP A-B-C?
>>>>>
>>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't
>>>>>understand PNNI at all?
>>>>>
>>>>>My point is that in order to make you case work, some additional work
>>>>>
>>>need
>>>
>>>>>to
>>>>>be done besie simply using GMPLS as singnaling protocol, becase some
>>>>>
>>>node
>>>
>>>>on
>>>>
>>>>>the path is not GMPLS speakers. A and C needs the info of time slot
>>>>>
>>>>aligment
>>>>
>>>>>between them. This can be done by some configurations, some link
>>>>>
>>>>management
>>>>
>>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info,
>>>>>eveything
>>>>>works fine.
>>>>>
>>>>>Yanhe
>>>>>
>>>>>
> 
> --
> Irfan Lateef
> Village Networks Inc,
> 
> 
> 
> 

Delivery-date: Wed, 24 Oct 2001 00:12:53 -0700
Date: Wed, 24 Oct 2001 03:10:46 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Irfan Lateef <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Irfan, good summary! I think (b) is probably right for some. I don't 
see (c) as been the case...

 From one uninformed reader to another, I think the quote you had was a 
frustrated person stating what he thinks was implied by another 
frustrated person's statement (am I putting words in anyone's mouth?).

 From what I understand G.ason and G.dcm is developed to describe the 
process and the minimal requirements needed to support a basic switched 
transport service. GMPLS is a protocol specific implementation that will 
likely meet many of the requirements, and may have some minor areas that 
it does not meet. Then the question to ask (as with any requirements and 
architecture work -- I'm sure we all have architects in our company) is: 
how critical are the requirements that may not be met and what changes 
are needed to GMPLS (if any) in order to meet them?

The last few email exchanges I think has been process related: why are 
things added to GMPLS, who has authority to add. Why can't we make GMPLS 
drafts more clear to people reading these drafts?

Of course there were also some fundamental issues, such as Juergen's 
desire to align the labels (which I agree with), Yangguang's question of 
why we are taking a fundamentally different approach for recovery since 
the "transport world" has done it one way for a long time and now it's 
suddenly changed & and authors not willing to discuss why the 
"traditional" way is not desired, and of course my desire to add 
clarifying text to the document to help uninformed reader like myself 
understand what SONET/SDH is all about (which is probably purely 
political rambling...)

Zhi

Irfan Lateef wrote:

> A view from the side lines
> -------------------------------
> 
>   First, on the lighter side I have the following suggestion.
>   we should change the subject line to any of the following,
>   a. Stubbornly stuck - refusing to move forward
>   b. Political Ramblings
>   c. Serious Trouble
>   d. Ugly email war among adults behaving like kids
>   I vote for (b)
> 
>   Now on the serious side, I have a few questions.
> 
> 1. Does the chair of this WG think that this email thread is a necessary
>    democratic step in the process.
> 
> 2. If not, then why isn't somebody stepping in with a summary of issues
>    and resolving them. Isn't there any arbitration process.
> 
> 3. If the protocols are designed to be flexible to accomadate future changes,
>    why aren't the authors treating "some of the" requests as part of the flexibility
> 
>   and getting along.
> 
> 4. I feel the authors were treating last call as a formality and are not ready
>     to accept changes because it is a last call. Then what is the real intent of
>     last call.
> 
> 5. There seems to be a real disconnect between the needs of,
>     a. vendors and service providers
>     b. data vendors and transport vendors
>     If GMPLS is for at least this three groups, then the issues need to be
>     resolved to the satisfaction of this small set.
>     (I personally agree with not spending 10 years trying to develop a panacea for
> all)
> 
> 6. And finally it is alarming to me to note the following assertion.
>     "GMPLS wouldn't fit the ASON model... :-( "
>     Can someone clarify the true import of this statement. My understanding was
> GMPLS is
>     the only thing on which ITU,OIF and IETF are on the same page. Can you please
> correct
>     me on this and clarify as am a truly "uninformed" person on this.
> 
> Regards,
> Irfan Lateef
> 
> Maarten Vissers wrote:
> 
> 
>>Eric,
>>
>>What you refer to as "our own model" is already developed by ITU-T SG15... it is
>>in G.8080 (ex. G.ason) and other ASON related recommendations which will be
>>approved later this week. We are also entering the next phase in ASON
>>development; a phase in which protocol specific details will be defined. A
>>proposal to use PNNI as a basis is accepted... and expected in the near future
>>is a proposal to use also GMPLS as a 2nd protocol version... but if I understand
>>your message, GMPLS wouldn't fit the ASON model... :-(
>>
>>It's good to know this beforehand... no need then to consider this further...
>>feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over
>>the last 10 months... hope it's different however.
>>
>>Regards,
>>
>>Maarten
>>PS. when I wrote my reply to Yanhe there was no frustation... and their isn't
>>today either...
>>
>>"Mannie, Eric" wrote:
>>
>>>Hi Maarten and Zhi,
>>>
>>>I have the feeling that you are inventing a new model with a new protocol.
>>>This is not how GMPLS works. I understand your frustrations and I have the
>>>feeling that your ideas should be addressed somewhere else rather than
>>>trying to change a model that we are finalizing and that we got from the
>>>MPLS model.
>>>
>>>There are maybe 1000 ways of designing a control plane for transmission
>>>networks. I would suggest that you first develop your own model and then
>>>that we compare the two.
>>>
>>>Please, don't forget that we have here to be constructive in terms of GMPLS.
>>>We have final discussions about the core GMPLS signaling, this is not the
>>>beginning but the end of an (intermediate) phase.
>>>
>>>Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your
>>>house :-) We know it. Personally, I don't believe in the ultimate model and
>>>protocol that will do everything and that will take 10 years to be
>>>specified, with abstract protocols, meta-models, etc.
>>>
>>>By the way, personally I don't see any benefit of defining these
>>>meta-models, abstract models and abstract protocols. It is hard to
>>>understand for non super-expert and it is a complete loss of time for the
>>>readers. I prefer practical solutions.
>>>
>>>I am also seeing discussions that we already have many times in the past. I
>>>don't see any benefit of having them again, and again, and again. If we
>>>continue like this we will all implement a tool to answer automatically with
>>>our previous e-mails :-)
>>>
>>>Ok, there is a small set of people that don't like the way that GMPLS is
>>>designed and defined (always the same 4 or 5 people by the way) - that's
>>>100% your right guys and I respect it. In comparison with the hundreds
>>>(thousands ?) of people that are working on GMPLS and implementing it, this
>>>is a great achievement !
>>>
>>>So, I ask you the question: what do you want to achieve personally at this
>>>stage ? Don't you think that sometimes it is needed to finish one step,
>>>before going to the next one ?
>>>
>>>Kind regards,
>>>
>>>Eric
>>>
>>>-----Original Message-----
>>>From: Maarten Vissers [mailto:[email-masked]]
>>>Sent: Monday, October 22, 2001 11:07 PM
>>>To: Yanhe Fan
>>>Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ...
>>>
>>>Yanhe,
>>>
>>>The situation Zhi describes is one that will be very typical in the optical
>>>(SDH/SONET) network in the coming years. We will most likely see islands of
>>>switched subnetworks interconnected via the existing SDH/SONET non-switched
>>>networks. By means of management actions, links (GMPLS: link bundles) will
>>>be
>>>setup between an edge node in one switched subnetwork and an other edge node
>>>in
>>>the next switched subnetwork. In G.805 terminology, these links are so
>>>called
>>>serial compound links.
>>>
>>>The switched subnetworks will treat these serial compound links as normal
>>>links,
>>>"ignoring" the intermediate non-switched nodes they traverse. These links
>>>will
>>>contain a fixed set of link connections, which are identified by their
>>>respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
>>>The server signal that carries the e.g. 5 STS1 link connections in the link
>>>at A
>>>can be an OC12, whereas this can be an OC48 at Z.
>>>
>>>During discovery or by means of provisioning both A and Z nodes get aware of
>>>the
>>>5 sTS1 link connections as tuples of e.g.
>>>
>>>        SNPa             SNPz
>>>-----------------------------------
>>>- port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
>>>- port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
>>>- port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
>>>- port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
>>>- port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
>>>
>>>As both ends of the link build up this same relation information, it is
>>>possible
>>>to use as link connection identifier only one of the two SNPs. E.g. node A
>>>identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
>>>info
>>>to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta".
>>>Vice
>>>versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
>>>received
>>>by node A, this will be converted into Ai/T1.
>>>
>>>For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
>>>both ends of the link connection, only the timeslot at the sending end. The
>>>receiving end needs to convert this then into its local timeslot number.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>Yanhe Fan wrote:
>>>
>>>>Hi Zhi,
>>>>
>>>>What B does is breaking the label association between A and C by crossing
>>>>connect
>>>>the time slots.
>>>>
>>>>If the cross connect performed by B is fixed (in your case), what needs to
>>>>do is
>>>>just to rebuild the label association by configuration or a protocol such
>>>>
>>>as
>>>
>>>>LMP;
>>>>If the cross connect is not fixed but dynamic, the best thing to do is to
>>>>make B
>>>>a GMPLS speaker.
>>>>
>>>Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
>>>network... no chance... those will stay non-switched...
>>>
>>>
>>>>Yanhe
>>>>
>>>>-----Original Message-----
>>>>From: Zhi-Wei Lin [mailto:[email-masked]]
>>>>Sent: Friday, October 19, 2001 6:01 PM
>>>>To: Yanhe Fan
>>>>Cc: John Drake; Kireeti Kompella; [email-masked]
>>>>Subject: Re: Moving right along ...
>>>>
>>>>Hi Yanhe,
>>>>
>>>>Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
>>>>is simply part of the network that made up the "dumb" pipe. And because
>>>>the control plane control channel is separate, A and C can be adjacent
>>>>without ever knowing who B is or that even B existed. From A and C's
>>>>point of view, the network looks like:
>>>>
>>>>  A ----- C
>>>>
>>>>Think of the case of how a BGP sees an area. If an area is made up of:
>>>>
>>>>  A -- B -- C
>>>>
>>>>and B is internal router, does BGP "see" B?
>>>>
>>>>Zhi
>>>>
>>>>Yanhe Fan wrote:
>>>>
>>>>
>>>>>Hi, Zhi
>>>>>
>>>>>
>>>>>
>>>>>>For the label value for SONET/SDH or the label description in the
>>>>>>generic draft, the label is defined as directly representing the
>>>>>>"timeslot". Now if I have a control plane controlled transport network
>>>>>>that goes through a ADM that is not control plane controlled, as:
>>>>>>
>>>>>>
>>>>>>+--------+               +--------+               +--------+
>>>>>>|        | ---1--------- |        | ----1-------- |        |
>>>>>>|        | ---2--------- |        | ----2-------- |        |
>>>>>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>>>>>>|        | ---4--------- |        | ----4-------- |        |
>>>>>>|        | ---5--------- |        | ----5-------- |        |
>>>>>>+--------+               +--------+               +--------+
>>>>>>
>>>>>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
>>>>>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
>>>>>>has labels 1,2,3,4,5 incoming.
>>>>>>
>>>>>>Now imagine that at B, it actually has a fixed cross-connect that
>>>>>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
>>>>>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>>>>>>
>>>>>>Now when A GMPLS sends a message to C, the label it uses is "1".
>>>>>>However, the connection/LSP associated with timeslot "1" is actually the
>>>>>>label of timeslot "2" at C. </z>
>>>>>>
>>>>>In this case, you're trying to use GMPLS to setup an LSP cross a node
>>>>>
>>>(B)
>>>
>>>>>which can't understand GMPLS.
>>>>>
>>>>>Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
>>>>>GMPLS if B can't understand GMPLS?
>>>>>
>>>>>Now imagine A and B are LSRs, and B is a conventional router (can't
>>>>>understand
>>>>>MPLS), can you setup an LSP A-B-C?
>>>>>
>>>>>Now imagine A, B and C are ATM switches, can you setup a svc if B can't
>>>>>understand PNNI at all?
>>>>>
>>>>>My point is that in order to make you case work, some additional work
>>>>>
>>>need
>>>
>>>>>to
>>>>>be done besie simply using GMPLS as singnaling protocol, becase some
>>>>>
>>>node
>>>
>>>>on
>>>>
>>>>>the path is not GMPLS speakers. A and C needs the info of time slot
>>>>>
>>>>aligment
>>>>
>>>>>between them. This can be done by some configurations, some link
>>>>>
>>>>management
>>>>
>>>>>protocls (LMP maybe) etc. As long as A and C have this piece of info,
>>>>>eveything
>>>>>works fine.
>>>>>
>>>>>Yanhe
>>>>>
>>>>>
> 
> --
> Irfan Lateef
> Village Networks Inc,
> 
> 
> 
> 

Delivery-date: Tue, 23 Oct 2001 17:55:29 -0700
From: "Susumu Yoneda" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Generalized Signaling - LSP Encoding Type expansion 
Date: Wed, 24 Oct 2001 09:54:39 +0900

All,

I would like to address one of carrier's perspective. We will deploy GMPLS
in next year. However, we do not expect GMPLS to support all services for
all people. We are looking at future services and applications, which are
basically unknown. Therefore, GMPLS should be flexible enough to incorporate
future needs when they become clear. At that point, if some migrations of
existing service controls into GMPLS become economical, then we will do so.
OW, the current control will be fine with us. Do I have confused all of you?

Thank you,

Best Regards.

Susumu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Yakov Rekhter
Sent: Wednesday, October 24, 2001 12:17 AM
To: Lazer, Monica A, NNAD
Cc: [email-masked]'; [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

Monica,

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

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

Yakov.

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

Delivery-date: Tue, 23 Oct 2001 17:23:59 -0700
Date: Tue, 23 Oct 2001 20:24:38 -0400
From: Irfan Lateef <[email-masked]>
Organization: Village Networks Inc
To: [email-masked]
CC: [email-masked]
Subject: Re: Moving right along ...

A view from the side lines
-------------------------------

  First, on the lighter side I have the following suggestion.
  we should change the subject line to any of the following,
  a. Stubbornly stuck - refusing to move forward
  b. Political Ramblings
  c. Serious Trouble
  d. Ugly email war among adults behaving like kids
  I vote for (b)

  Now on the serious side, I have a few questions.

1. Does the chair of this WG think that this email thread is a necessary
   democratic step in the process.

2. If not, then why isn't somebody stepping in with a summary of issues
   and resolving them. Isn't there any arbitration process.

3. If the protocols are designed to be flexible to accomadate future changes,
   why aren't the authors treating "some of the" requests as part of the flexibility

  and getting along.

4. I feel the authors were treating last call as a formality and are not ready
    to accept changes because it is a last call. Then what is the real intent of
    last call.

5. There seems to be a real disconnect between the needs of,
    a. vendors and service providers
    b. data vendors and transport vendors
    If GMPLS is for at least this three groups, then the issues need to be
    resolved to the satisfaction of this small set.
    (I personally agree with not spending 10 years trying to develop a panacea for
all)

6. And finally it is alarming to me to note the following assertion.
    "GMPLS wouldn't fit the ASON model... :-( "
    Can someone clarify the true import of this statement. My understanding was
GMPLS is
    the only thing on which ITU,OIF and IETF are on the same page. Can you please
correct
    me on this and clarify as am a truly "uninformed" person on this.

Regards,
Irfan Lateef

Maarten Vissers wrote:

> Eric,
>
> What you refer to as "our own model" is already developed by ITU-T SG15... it is
> in G.8080 (ex. G.ason) and other ASON related recommendations which will be
> approved later this week. We are also entering the next phase in ASON
> development; a phase in which protocol specific details will be defined. A
> proposal to use PNNI as a basis is accepted... and expected in the near future
> is a proposal to use also GMPLS as a 2nd protocol version... but if I understand
> your message, GMPLS wouldn't fit the ASON model... :-(
>
> It's good to know this beforehand... no need then to consider this further...
> feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over
> the last 10 months... hope it's different however.
>
> Regards,
>
> Maarten
> PS. when I wrote my reply to Yanhe there was no frustation... and their isn't
> today either...
>
> "Mannie, Eric" wrote:
> >
> > Hi Maarten and Zhi,
> >
> > I have the feeling that you are inventing a new model with a new protocol.
> > This is not how GMPLS works. I understand your frustrations and I have the
> > feeling that your ideas should be addressed somewhere else rather than
> > trying to change a model that we are finalizing and that we got from the
> > MPLS model.
> >
> > There are maybe 1000 ways of designing a control plane for transmission
> > networks. I would suggest that you first develop your own model and then
> > that we compare the two.
> >
> > Please, don't forget that we have here to be constructive in terms of GMPLS.
> > We have final discussions about the core GMPLS signaling, this is not the
> > beginning but the end of an (intermediate) phase.
> >
> > Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your
> > house :-) We know it. Personally, I don't believe in the ultimate model and
> > protocol that will do everything and that will take 10 years to be
> > specified, with abstract protocols, meta-models, etc.
> >
> > By the way, personally I don't see any benefit of defining these
> > meta-models, abstract models and abstract protocols. It is hard to
> > understand for non super-expert and it is a complete loss of time for the
> > readers. I prefer practical solutions.
> >
> > I am also seeing discussions that we already have many times in the past. I
> > don't see any benefit of having them again, and again, and again. If we
> > continue like this we will all implement a tool to answer automatically with
> > our previous e-mails :-)
> >
> > Ok, there is a small set of people that don't like the way that GMPLS is
> > designed and defined (always the same 4 or 5 people by the way) - that's
> > 100% your right guys and I respect it. In comparison with the hundreds
> > (thousands ?) of people that are working on GMPLS and implementing it, this
> > is a great achievement !
> >
> > So, I ask you the question: what do you want to achieve personally at this
> > stage ? Don't you think that sometimes it is needed to finish one step,
> > before going to the next one ?
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Monday, October 22, 2001 11:07 PM
> > To: Yanhe Fan
> > Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ...
> >
> > Yanhe,
> >
> > The situation Zhi describes is one that will be very typical in the optical
> > (SDH/SONET) network in the coming years. We will most likely see islands of
> > switched subnetworks interconnected via the existing SDH/SONET non-switched
> > networks. By means of management actions, links (GMPLS: link bundles) will
> > be
> > setup between an edge node in one switched subnetwork and an other edge node
> > in
> > the next switched subnetwork. In G.805 terminology, these links are so
> > called
> > serial compound links.
> >
> > The switched subnetworks will treat these serial compound links as normal
> > links,
> > "ignoring" the intermediate non-switched nodes they traverse. These links
> > will
> > contain a fixed set of link connections, which are identified by their
> > respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
> > The server signal that carries the e.g. 5 STS1 link connections in the link
> > at A
> > can be an OC12, whereas this can be an OC48 at Z.
> >
> > During discovery or by means of provisioning both A and Z nodes get aware of
> > the
> > 5 sTS1 link connections as tuples of e.g.
> >
> >         SNPa             SNPz
> > -----------------------------------
> > - port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
> > - port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
> > - port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
> > - port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
> > - port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
> >
> > As both ends of the link build up this same relation information, it is
> > possible
> > to use as link connection identifier only one of the two SNPs. E.g. node A
> > identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
> > info
> > to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta".
> > Vice
> > versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
> > received
> > by node A, this will be converted into Ai/T1.
> >
> > For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
> > both ends of the link connection, only the timeslot at the sending end. The
> > receiving end needs to convert this then into its local timeslot number.
> >
> > Regards,
> >
> > Maarten
> >
> > Yanhe Fan wrote:
> > >
> > > Hi Zhi,
> > >
> > > What B does is breaking the label association between A and C by crossing
> > > connect
> > > the time slots.
> > >
> > > If the cross connect performed by B is fixed (in your case), what needs to
> > > do is
> > > just to rebuild the label association by configuration or a protocol such
> > as
> > > LMP;
> > > If the cross connect is not fixed but dynamic, the best thing to do is to
> > > make B
> > > a GMPLS speaker.
> >
> > Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
> > network... no chance... those will stay non-switched...
> >
> > >
> > > Yanhe
> > >
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:[email-masked]]
> > > Sent: Friday, October 19, 2001 6:01 PM
> > > To: Yanhe Fan
> > > Cc: John Drake; Kireeti Kompella; [email-masked]
> > > Subject: Re: Moving right along ...
> > >
> > > Hi Yanhe,
> > >
> > > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> > > is simply part of the network that made up the "dumb" pipe. And because
> > > the control plane control channel is separate, A and C can be adjacent
> > > without ever knowing who B is or that even B existed. From A and C's
> > > point of view, the network looks like:
> > >
> > >   A ----- C
> > >
> > > Think of the case of how a BGP sees an area. If an area is made up of:
> > >
> > >   A -- B -- C
> > >
> > > and B is internal router, does BGP "see" B?
> > >
> > > Zhi
> > >
> > > Yanhe Fan wrote:
> > >
> > > > Hi, Zhi
> > > >
> > > >
> > > >>For the label value for SONET/SDH or the label description in the
> > > >>generic draft, the label is defined as directly representing the
> > > >>"timeslot". Now if I have a control plane controlled transport network
> > > >>that goes through a ADM that is not control plane controlled, as:
> > > >>
> > > >>
> > > >>+--------+               +--------+               +--------+
> > > >>|        | ---1--------- |        | ----1-------- |        |
> > > >>|        | ---2--------- |        | ----2-------- |        |
> > > >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> > > >>|        | ---4--------- |        | ----4-------- |        |
> > > >>|        | ---5--------- |        | ----5-------- |        |
> > > >>+--------+               +--------+               +--------+
> > > >>
> > > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> > > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> > > >>has labels 1,2,3,4,5 incoming.
> > > >>
> > > >>Now imagine that at B, it actually has a fixed cross-connect that
> > > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> > > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> > > >>
> > > >>Now when A GMPLS sends a message to C, the label it uses is "1".
> > > >>However, the connection/LSP associated with timeslot "1" is actually the
> > > >>label of timeslot "2" at C. </z>
> > > >>
> > > >
> > > > In this case, you're trying to use GMPLS to setup an LSP cross a node
> > (B)
> > > > which can't understand GMPLS.
> > > >
> > > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > > > GMPLS if B can't understand GMPLS?
> > > >
> > > > Now imagine A and B are LSRs, and B is a conventional router (can't
> > > > understand
> > > > MPLS), can you setup an LSP A-B-C?
> > > >
> > > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > > > understand PNNI at all?
> > > >
> > > > My point is that in order to make you case work, some additional work
> > need
> > > > to
> > > > be done besie simply using GMPLS as singnaling protocol, becase some
> > node
> > > on
> > > > the path is not GMPLS speakers. A and C needs the info of time slot
> > > aligment
> > > >
> > > > between them. This can be done by some configurations, some link
> > > management
> > > > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > > > eveything
> > > > works fine.
> > > >
> > > > Yanhe
> > > >

--
Irfan Lateef
Village Networks Inc,

Delivery-date: Tue, 23 Oct 2001 17:12:14 -0700
Date: Tue, 23 Oct 2001 17:09:42 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Maarten Vissers <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi Marteen:

Can you briefly summarize the differences you see between
GMPLS architecture and ASON architecture? This has been
asked by many of the folks at IETF.

Regards,

sudheer

PS: I thought these mails were about label format and suddenly
this is turning into an ITU versus IETF discussion :-(

Delivery-date: Tue, 23 Oct 2001 15:59:36 -0700
Cc: [email-masked]
Date: Wed, 24 Oct 2001 00:54:44 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------8BC15EED8DAA848A85239179
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

What you refer to as "our own model" is already developed by ITU-T SG15... it is
in G.8080 (ex. G.ason) and other ASON related recommendations which will be
approved later this week. We are also entering the next phase in ASON
development; a phase in which protocol specific details will be defined. A
proposal to use PNNI as a basis is accepted... and expected in the near future
is a proposal to use also GMPLS as a 2nd protocol version... but if I understand
your message, GMPLS wouldn't fit the ASON model... :-(

It's good to know this beforehand... no need then to consider this further...
feels as if I wasted my time in enhancing GMPLS SDH/SONET and OTN details over
the last 10 months... hope it's different however.

Regards,

Maarten
PS. when I wrote my reply to Yanhe there was no frustation... and their isn't
today either...

"Mannie, Eric" wrote:
> 
> Hi Maarten and Zhi,
> 
> I have the feeling that you are inventing a new model with a new protocol.
> This is not how GMPLS works. I understand your frustrations and I have the
> feeling that your ideas should be addressed somewhere else rather than
> trying to change a model that we are finalizing and that we got from the
> MPLS model.
> 
> There are maybe 1000 ways of designing a control plane for transmission
> networks. I would suggest that you first develop your own model and then
> that we compare the two.
> 
> Please, don't forget that we have here to be constructive in terms of GMPLS.
> We have final discussions about the core GMPLS signaling, this is not the
> beginning but the end of an (intermediate) phase.
> 
> Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your
> house :-) We know it. Personally, I don't believe in the ultimate model and
> protocol that will do everything and that will take 10 years to be
> specified, with abstract protocols, meta-models, etc.
> 
> By the way, personally I don't see any benefit of defining these
> meta-models, abstract models and abstract protocols. It is hard to
> understand for non super-expert and it is a complete loss of time for the
> readers. I prefer practical solutions.
> 
> I am also seeing discussions that we already have many times in the past. I
> don't see any benefit of having them again, and again, and again. If we
> continue like this we will all implement a tool to answer automatically with
> our previous e-mails :-)
> 
> Ok, there is a small set of people that don't like the way that GMPLS is
> designed and defined (always the same 4 or 5 people by the way) - that's
> 100% your right guys and I respect it. In comparison with the hundreds
> (thousands ?) of people that are working on GMPLS and implementing it, this
> is a great achievement !
> 
> So, I ask you the question: what do you want to achieve personally at this
> stage ? Don't you think that sometimes it is needed to finish one step,
> before going to the next one ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, October 22, 2001 11:07 PM
> To: Yanhe Fan
> Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ...
> 
> Yanhe,
> 
> The situation Zhi describes is one that will be very typical in the optical
> (SDH/SONET) network in the coming years. We will most likely see islands of
> switched subnetworks interconnected via the existing SDH/SONET non-switched
> networks. By means of management actions, links (GMPLS: link bundles) will
> be
> setup between an edge node in one switched subnetwork and an other edge node
> in
> the next switched subnetwork. In G.805 terminology, these links are so
> called
> serial compound links.
> 
> The switched subnetworks will treat these serial compound links as normal
> links,
> "ignoring" the intermediate non-switched nodes they traverse. These links
> will
> contain a fixed set of link connections, which are identified by their
> respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
> The server signal that carries the e.g. 5 STS1 link connections in the link
> at A
> can be an OC12, whereas this can be an OC48 at Z.
> 
> During discovery or by means of provisioning both A and Z nodes get aware of
> the
> 5 sTS1 link connections as tuples of e.g.
> 
>         SNPa             SNPz
> -----------------------------------
> - port Ai/trib T1 - port Zj/trib Ta     (STS1 link connection #1)
> - port Ai/trib T2 - port Zj/trib Tb     (STS1 link connection #2)
> - port Ai/trib T3 - port Zj/trib Tc     (STS1 link connection #3)
> - port Ai/trib T4 - port Zj/trib Td     (STS1 link connection #4)
> - port Ai/trib T5 - port Zj/trib Te     (STS1 link connection #5)
> 
> As both ends of the link build up this same relation information, it is
> possible
> to use as link connection identifier only one of the two SNPs. E.g. node A
> identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
> info
> to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta".
> Vice
> versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
> received
> by node A, this will be converted into Ai/T1.
> 
> For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
> both ends of the link connection, only the timeslot at the sending end. The
> receiving end needs to convert this then into its local timeslot number.
> 
> Regards,
> 
> Maarten
> 
> Yanhe Fan wrote:
> >
> > Hi Zhi,
> >
> > What B does is breaking the label association between A and C by crossing
> > connect
> > the time slots.
> >
> > If the cross connect performed by B is fixed (in your case), what needs to
> > do is
> > just to rebuild the label association by configuration or a protocol such
> as
> > LMP;
> > If the cross connect is not fixed but dynamic, the best thing to do is to
> > make B
> > a GMPLS speaker.
> 
> Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
> network... no chance... those will stay non-switched...
> 
> >
> > Yanhe
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Friday, October 19, 2001 6:01 PM
> > To: Yanhe Fan
> > Cc: John Drake; Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ...
> >
> > Hi Yanhe,
> >
> > Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> > is simply part of the network that made up the "dumb" pipe. And because
> > the control plane control channel is separate, A and C can be adjacent
> > without ever knowing who B is or that even B existed. From A and C's
> > point of view, the network looks like:
> >
> >   A ----- C
> >
> > Think of the case of how a BGP sees an area. If an area is made up of:
> >
> >   A -- B -- C
> >
> > and B is internal router, does BGP "see" B?
> >
> > Zhi
> >
> > Yanhe Fan wrote:
> >
> > > Hi, Zhi
> > >
> > >
> > >>For the label value for SONET/SDH or the label description in the
> > >>generic draft, the label is defined as directly representing the
> > >>"timeslot". Now if I have a control plane controlled transport network
> > >>that goes through a ADM that is not control plane controlled, as:
> > >>
> > >>
> > >>+--------+               +--------+               +--------+
> > >>|        | ---1--------- |        | ----1-------- |        |
> > >>|        | ---2--------- |        | ----2-------- |        |
> > >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> > >>|        | ---4--------- |        | ----4-------- |        |
> > >>|        | ---5--------- |        | ----5-------- |        |
> > >>+--------+               +--------+               +--------+
> > >>
> > >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> > >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> > >>has labels 1,2,3,4,5 incoming.
> > >>
> > >>Now imagine that at B, it actually has a fixed cross-connect that
> > >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> > >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> > >>
> > >>Now when A GMPLS sends a message to C, the label it uses is "1".
> > >>However, the connection/LSP associated with timeslot "1" is actually the
> > >>label of timeslot "2" at C. </z>
> > >>
> > >
> > > In this case, you're trying to use GMPLS to setup an LSP cross a node
> (B)
> > > which can't understand GMPLS.
> > >
> > > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > > GMPLS if B can't understand GMPLS?
> > >
> > > Now imagine A and B are LSRs, and B is a conventional router (can't
> > > understand
> > > MPLS), can you setup an LSP A-B-C?
> > >
> > > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > > understand PNNI at all?
> > >
> > > My point is that in order to make you case work, some additional work
> need
> > > to
> > > be done besie simply using GMPLS as singnaling protocol, becase some
> node
> > on
> > > the path is not GMPLS speakers. A and C needs the info of time slot
> > aligment
> > >
> > > between them. This can be done by some configurations, some link
> > management
> > > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > > eveything
> > > works fine.
> > >
> > > Yanhe
> > >
--------------8BC15EED8DAA848A85239179
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------8BC15EED8DAA848A85239179--

Delivery-date: Tue, 23 Oct 2001 13:52:23 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Generalized Signalling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 16:49:52 -0400

Yakov,
 More comments in line.
Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Yakov Rekhter [mailto:[email-masked]] 
Sent:	Tuesday, October 23, 2001 1:26 PM
To:	[email-masked]
Cc:	[email-masked]
Subject:	Re: Generalized Signalling - LSP Encoding Type expansion 

Shehzad,

> Yakov,
> 
> The percentage of carriers that have all of their requirements met by the
> current GMPLS drafts is an unknown.  However the following points still 
> need to be addressed.
> 
> 1.  Why would an operator adopt GMPLS infrastructure if it only carried a
> subset of the transport services that they are already offer to customers?
> In effect spending more and getting less.

It depends on the percentage of the total profit that could be generated by
the subset.
[[Lazer, AT&T]]  This is neither here nor there, for a standards
organization to decide. 
[[Lazer, AT&T]] Let me restate: a network element shall not require separate
control plane for  individual line cards (this will be a strong
requirement). 
Service companies need to make their choices as to what the business case is
for each service offering; individual equipment vendors will decide what
specific services, line cards, or features to support on each NE. But it is
not the role of a body to decide that only some services deserve to be
supported by the control plane, while others are undeserving. 
This is not IETF's job! 
> 2.  Why is there a problem reserving a code-point for a service that some
> vendors may wish to implement on their GMPLS equipment?  Presumably they
> would not implement capability for which there is no demand.

If all you ask is a code-point, this code point is relevant only
to the LSPs' end-points, and not every GMPLS vendor is *required* to support
this code-point, then I don't think there is a problem with doing
this.
[[Lazer, AT&T]] Clearly not every GMPLS vendor would be required to support
every service. Every vendor claiming support of GMPLS on the NE will be
asked whether that applies to all the interfaces and services supported by
the NE. I believe that code points will be relevant to subnetwork
inter-connection points too, not only the network edges.
Let me re-iterate, every vendor needs to make its own decision as to what
needs to be supported in the NEs they sell. Every carrier makes its decision
as to what to support in the networks they deploy. 

> 3.  What is the process by which certain transport services are decided
> suitable for inclusion into the GMPLS specifications/drafts?  It seems
that
> inclusion of additional services fraught with difficulties, this is likely
> to get worse when the drafts turn into specifications.

The types of services that would be suitable for inclusion are the services
that (a) would *not* require changes/upgrades to the GMPLS core, and (b)
would
not require every GMPLS vendor to implement every service.
[[Lazer, AT&T]] So what you are saying is that every carrier will need to
beg for IETF's blessing for every new service
if GMPLS will be the architecture of choice for control plane?

Let me state something else again: If IETF forces GMPLS to be an
architecture where control plane support for some services needs to be
separate from the control plane for some of its other services, than IETF
ensures that GMPLS has a diminished value. GMPLS is not just a protocol. It
is a distributed control plane architecture using a suite of protocols. If
this architecture makes it very hard to evolve the control plane in step
with the data plane, than this architecture needs a lot of work.

Monica

Yakov.

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

Delivery-date: Tue, 23 Oct 2001 12:50:24 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Eric Gray'" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion
Date: Tue, 23 Oct 2001 15:49:44 -0400

Eric,
Eric, you are telling me that transport boxes are not allowed to support
services other than IP? Isn't this a choice to be made by individual service
providers? Why is a standards body trying to impede development of control
plane support for a subset of transport services?  What is the principle
here? I am not saying that a every vendor needs to implement all services in
the control plane. But if a vendor chooses to implement a set of services in
the data plane, then there should be standards for controlling them.

Let me offer you the analogy of how I see this discussion. Assume that a
road contractor is building a road because he knows that a lot of cars will
go through the area. But he decides that only cars carrying married people
will be allowed on the road. No cars carrying a parent and a child are
allowed. 

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Eric Gray [mailto:[email-masked]] 
Sent:	Tuesday, October 23, 2001 2:34 PM
To:	Lazer, Monica A, NNAD
Cc:	Yakov Rekhter; [email-masked]
Subject:	Re: Generalized Signaling - LSP Encoding Type expansion

Monica,

    I believe this is both the crux of the argument and the point at which
people keep arguing past each other.  Some people would like to see a
unified transport control plane while other would like to see an IP control
plane for transport networks.  These would be very different goals.

    If you'll bear with an analogy for a moment, imagine that you were to
set
out to design a bicycle.  Now along comes somebody that says - "hey,  it
looks like you've got a pretty good start on a design for an all terrain
vehicle;
all you need to do is add this, change that and bing, bang, boom - we have
an ATV."  That would be just fine, provided you didn't have any particular
reason to be designing a bicycle.  But, assuming what you really wanted was
a bicycle, this somebody could not be looked on as being helpful, could
they?

You wrote:

> [[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we
> should work to make it that.

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Tue, 23 Oct 2001 12:46:37 -0700
Date: Tue, 23 Oct 2001 15:45:40 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Yakov Rekhter <[email-masked]>
CC: "Lazer, Monica A, NNAD" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

Hi,

While we're talking about why something should be added, and some folks 
seem to be getting a rough time needing to explain completely why they 
need it (and that if they want to add it, then it better be useful to 
majority of the folks), then could I ask that things such as "switching 
type" (which was added without much of a discussion of why it's needed 
and how many people actually need it, and for what purpose) also be open 
for discussion before it is actually accepted into the document?

Zhi

Yakov Rekhter wrote:

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

Delivery-date: Tue, 23 Oct 2001 12:46:30 -0700
Date: Tue, 23 Oct 2001 15:42:34 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Eric Gray <[email-masked]>
CC: "Lazer, Monica A, NNAD" <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

Hi Eric,

Maybe I'm confused but is it really talking about "unified transport 
CP"? I think we are still talking about an IP control plane (BTW, what 
is the definition of IP CP?), but using this IP control plane to allow 
requesting different types of transport plane for services that those 
transport planes can offer, still using the IP-based protocols.

Is that right, or am I completely uninformed?

Zhi

Eric Gray wrote:

> Monica,
> 
>     I believe this is both the crux of the argument and the point at which
> people keep arguing past each other.  Some people would like to see a
> unified transport control plane while other would like to see an IP control
> plane for transport networks.  These would be very different goals.
> 
>     If you'll bear with an analogy for a moment, imagine that you were to set
> out to design a bicycle.  Now along comes somebody that says - "hey,  it
> looks like you've got a pretty good start on a design for an all terrain vehicle;
> all you need to do is add this, change that and bing, bang, boom - we have
> an ATV."  That would be just fine, provided you didn't have any particular
> reason to be designing a bicycle.  But, assuming what you really wanted was
> a bicycle, this somebody could not be looked on as being helpful, could they?
> 
> You wrote:
> 
> 
>>[[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we
>>should work to make it that.
>>
> 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 
> 
> 

Delivery-date: Tue, 23 Oct 2001 11:42:23 -0700
Date: Tue, 23 Oct 2001 14:34:11 -0400
From: Eric Gray <[email-masked]>
To: "Lazer, Monica A, NNAD" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

Monica,

    I believe this is both the crux of the argument and the point at which
people keep arguing past each other.  Some people would like to see a
unified transport control plane while other would like to see an IP control
plane for transport networks.  These would be very different goals.

    If you'll bear with an analogy for a moment, imagine that you were to set
out to design a bicycle.  Now along comes somebody that says - "hey,  it
looks like you've got a pretty good start on a design for an all terrain vehicle;
all you need to do is add this, change that and bing, bang, boom - we have
an ATV."  That would be just fine, provided you didn't have any particular
reason to be designing a bicycle.  But, assuming what you really wanted was
a bicycle, this somebody could not be looked on as being helpful, could they?

You wrote:

> [[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we
> should work to make it that.

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Tue, 23 Oct 2001 11:38:03 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Juergen Heiles' <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, [email-masked]
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Moving right along ...
Date: Tue, 23 Oct 2001 20:22:58 +0200

Hi Juergen,

More about the SDH and SONET labels:

We designed them using the same principles to have as much =
compatibility as
possible between SDH and SONET, this was our objective. But they will =
never
be the same as explained hereafter.

For the Sonet label we have the choice between the single stage =
interleaving
and the two stage interleaving approach. One must choose either one or =
the
other.

Your proposal is to use the two stage interleaving to define the Sonet
label. We chosen the single stage Sonet interleaving. The advantage of =
using
the single stage interleaving as a basis is that it works in both cases =
in
the same way, i.e. it just point to the first STS-1 and the label =
doesn't
care if a single or two stage interleaving is used, it results that S =
has
exactly the same *semantic* for SDH and SONET, but not the same *value* =
of
course.

Another reason to use the single stage interleaving is to avoid to =
introduce
a particular case just for SONET. If we introduce a STS-3 group we =
could
also introduce AUG-4, AUG-16, AUG-64 and AUG-256. If we do that (to be
compatible with the two stage SONET approach), the label needs three
additional artificial fields. Each time we add an additional level, we =
need
to add a field. It becomes more complex without adding any new feature =
and
we loose the flexibility.

One main driver for our solution is that the label doesn't need to know
about the grouping of STS-1 or AUG, there is no need to encode that
information in the label because nobody is going to use it. So we =
obtained
an easier coding.

More important: the label structure will NEVER be the same for SONET =
and SDH
because this is physically not possible: there is not TUG-3 equivalent =
in
SONET, there is no VT-3 equivalent in SDH. So whatever is the label =
coding,
K and M will ALWAYS be different. Nobody can change it.

The C code for coding and dealing with the multiplex allocation will =
never
be the same neither. A link will never be operated at the same time as =
SDH
and SONET.

The label is always local to a link and there is no interoperability =
issue
between SONET and SDH for that reason (because they are physically
separated).

We had the same desire to have the SDH and SONET label as compatible as
possible, and this is what we think we achieved while taking into
consideration the purpose of the label, why we need a label and where =
we
need a label.

Kind regards,

Eric

-----Original Message-----
From: Juergen Heiles [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 6:08 PM
To: Mannie, Eric; 'Juergen Heiles'; 'Kireeti Kompella';
[email-masked]
Subject: AW: Moving right along ...

> -----Urspr=FCngliche Nachricht-----
> Von: Mannie, Eric [mailto:[email-masked]]
> Gesendet: Dienstag, 23. Oktober 2001 17:12
> An: 'Juergen Heiles'; 'Kireeti Kompella'; [email-masked]
> Betreff: RE: Moving right along ...
>
>
> Juergen,
>
> I am answering to your e-mails exactly because I am the editor of =
these
> documents. Some people don't want to answer anymore. Answering or not =
to
> e-mails is a personal decision of each one, nobody is forced to =
answer.
>
> You had the feedback from the mailing list. In general when
> people are happy
> with what they saw they don't spend time to add more comments.
>
> Your proposals were supported by you and Maarten. I answered with =
Dimitri.
> It is easy of course (for all of us) to ask all our colleagues and =
friends
> to flood a mailing list.
>
> Concerning your request to move the group signals to the other draft: =
this
> was answered publicly by Kireeti during the last CCAMP meeting and =
the
> answer was no. I asked again to Kireeti a couple of weeks ago,
> same answer.
> This is also the advice that I received from Rob.

As this is not a question of rough consensus let the chairs sort this =
out.

>
> Concerning your label proposal: details are not yet cooked from our =
(I and
> Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding =
Adjacency
> there is no second STS-3 group, sorry if my example was confusing). =
Your
> text needs to be corrected but that's a detail, it just shows that it =
is
> quite difficult to write a text that works in all cases.
>
What does a STS-4 SPE Forwarding Adjacency provide capacity for 4 STS-1
SPEs?
Ok, how about a 4xAU-3 Forwarding Adjacency, the SDH equivalent. It =
should
be also possible (Japan for example uses SDH AU3).
How would you use it with the current SDH lable. If you consider such
features I agree that my proposal has problems, but the current =
proposal
also for AU3. To cover it for both SONET and SDH AU3 we have to use the
current SONET labels also for SDH AU3. Again we would have identical =
SONET
and SDH labels.
And this example clearly shows to me that we need the same lables. =
Otherwise
we end up with some features that are only possible in SDH or only =
possible
in SONET because of different restrictions due to the different lables. =
What
can be done in SONET can also be done in SDH.

> We spend a considerable amount of time reviewing the current
> label encoding
> and we made sure that it works in the craziest cases. Indeed, this is =
the
> most stable part of the SDH/SONET draft since a very long time.
> By adopting
> your proposal we will have to do it again for no additional benefit =
and we
> will need another WG last call (you know it perfectly). That's
> why I refused
> during the WG last call some months ago, and why I am refusing again.
>
> As an editor my job is also to keep the boat in the middle of the
> river and
> to make sure that drafts are progressing and are not being constantly
> re-worded. Also, I don't want to force all manufacturers to change =
their
> implementations (prototypes:-) of the SONET label just because you =
found
> another way of encoding it. One solution or the other is more a =
matter of
> personal feeling.
>
> At this stage, as a co-author you should be more concerned by
> finishing this
> work. We can spend years having new ideas, improving and proposing
> modifications to a draft.
>
If a co-author has to keep quiet on the mailing list or during the =
meeting
with comments on the document it is fine with me to be removed as =
co-author.

> It is a fact that we spend a huge amount of time (for me it =
represents
> months of work since the beginning of year 2000) fine-tuning this
> draft. Now
> it is time to publish it.
>
> >From the technical point of view your proposals versus keeping
> the current
> text will not change anything. It started as a political issue and I =
hope
> that it didn't become a personal issue.
>
> I am just asking you to help us to publish this work, even if it
> is not 100%
> as you would like to see it.
>
> Kind regards,
>
> Eric
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: Mannie, Eric [mailto:[email-masked]]
> > Gesendet: Dienstag, 23. Oktober 2001 12:23
> > An: 'Juergen Heiles'; 'Kireeti Kompella'; [email-masked]
> > Betreff: RE: Moving right along ...
> >
> >
> > Hi Juergen,
> >
> > We already discussed all these points (at least 5 times) :-)
> even more
>
>
> >
> > - about automatic detection:
> >
> > Indeed, you either configure a box with a signal structure, or if
> > implemented you can ask to the box to discover itself the
> structure (what
> > you call automatic detection).
> >
> For groups the box has to discover the structure itself.
>
>
> > Automatic detection is a process applied internally to a box,
> and this is
> > totally invisible to any other box in the network. This is an
> > implementation
> > issue, not a protocol issue since the protocol defines
> everyhting you need
> > to do it.
> >
> > I understand your frustration that SDH standards don't describe all =
the
> > processes for an implementation, but in general standards don't
> touch that
> > part.
> >
> SDH and Sonet standards define detailed equipment functionality
> in order to
> ensure interworking.
> ITU has for example G.783 that defeins in detail what to do in SDH
> equipment. Even G.707 gives some details
> on pointer processing (genration, interpretation). For SONET we
> have GR-253
> from Telcordia which provides this details.
> No of them mentiones automatic detection.
>
>
> > Automatic detection is a matter of reading the standard and
> understanding
> > how the multiplexing works. By the way, you explained it yourself
> > very well.
> >
> > The fact that a process is not described in some SDH standards has =
no
> > meaning, it is simply not relevant. Every manufacturer is free to =
do its
> > implementation as he likes if the protocol is fullfilled, and
> this is the
> > case.
> >
> > - about the comparison of automatic detection and transparency:
> >
> > You are comparing apples with chocolates. Transparency may require =
to
> > transport bytes in unused bytes, so in that case it changes the
> overhead.
> > Automatic detection is an internal process.
> >
> > - You wrote: "During errors (defects, AIS condtions) of
> individual singals
> > of a group (e.g. one VC-12 in a TUG3 fails) it can get =
problematic."
> >
> > and I already answered many times: a super signal (group signal) is =
one
> > single LSP. If something fails inside everything fails. In that =
case you
> > don't need to demultiplex anymore, you just protect/restore the
> whole (if
> > required). A group signal is a signaling plane object, i.e. one
> > single LSP.
> >
> I mentioned the case that the problem is outside your LSP. You get =
for
> example a signal from a user and setup a group LSP.
> Now due to problems on the user side one of the VCs has AIS, may
> be the user
> isn't even using this VC currently. You cannot protect it as the
> problem is
> outside the LSP. If you now drop all other VCs of this group your
> user would
> be very happy I assume.
>
>
> > - Can you present me any ITU/ANSI standard that defines automatic
> > detection
> > of the group structure?
> >
> > No need, this is not in the scope of ITU/ANSI standards.
>
> Are you defining what is in the scope of ITU/ANSI standards?
> This is in the scope of ITU/ANSI/Telcordia standards. Look on
> G.707 pointer
> interpretation, G.783 and GR-253 as mentioned above. When we talk =
about
> standard SONET/SDH it includes the equipment functionality. For
> ETSI we even
> have compliance statements that go down to these details.
> I have no problems when soemone implements this feature, but we =
should no
> give the impression that this is a standard SONET/SDH feature by
> putting it
> into the standard features document. Move it to the non-standard =
document.
>
> >
> > - You wrote " You haven't provided a reason for different lables. =
We had
> > several people that wanted to have the same label structure and =
only you
> > opposed. So what is rough consensus?"
> >
> > The labels are local per interface, so they are "different" by
> definition
> > since an SDH interface is not a Sonet interface.
>
> A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N
> with AU-3 have
> the identical structure.
> But with the current proposal we have to use different lables. Is =
this
> simple?
>
> > However, we
> > defined the two
> > label formats based on the same principles, i.e. the first field is =
the
> > index of the first AUG-1/STS-1 (easy). We chosen not to
> indicate any level
> > of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc)
> because this
> > is not needed and less flexible. A label is just a simple pointer =
in the
> > multiplex, how to interpret the content of what is pointed to is
> > not defined
> > by the label.
> >
>
> I just took the SDH AU3 case and used it for SONET. So if you see
> a problem
> it would already apply to the defined SDH lable.
>
>
> > Using your proposal we would introduce a particular case, and
> in that case
> > there is no reason why we should not introduce other particular
> > case (AUG-4,
> > etc). At the end we would have something totally unreadable.
> >
> > Your proposal has also some issues, e.g. with your definition of =
the S
> > field:
> >
> > "1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N
> >     indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
> >     multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 =
group,
> >     and S=3DN indicates the last AUG-1/STS-3 group of this =
multiplex.
> >     S is not significant for STM-0/STS-1.
> >
> > What happens if a link is not a a multiple of 3xN STS-1 ? For
> instance, a
> > virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or
> an STS-4.
> > There is no real second STS-3 group. Your proposal is not
> > appropriate to the
> > level of flexibility that we want to provide. Another observations: =
our
> > undrestanding of the label is that it is defined before any
> interleaving,
> > not after.
> >
>
> Oh, suddently we have STS-4, STS-4 virtual links poping up,
> interesting. But
> couldn't we also have virtual SDH signals with only 5 AU-3?
> I don't know as I don't have any information about this virtual link
> concept. But if you introduce something like this there should be no
> difference between SONET and SDH. Otherwise we introduce new =
differences
> between SONET and SDH that we tried to avoid now for some years (see
> Deborahs e-mail). We learned from the mistakes made during the =
development
> of SONET and SDH. In todays global world we don't want these =
differences.
> And that is the reason why we propose to use a common lable.
> Don't make the
> same mistakes again. So if you see a problem it also applies to
> the defined
> SDH label.
>
>
>
> > I am opposed because your proposal doesn't bring any new =
functionality.
> > There are probably 100 ways of coding such a label for SDH and =
Sonet. We
> > discussed it during one year,
> The proposal to use a common lable is already disucssed for several =
month
> (over 1/2 year) as soon as we got involved in the GMPLS discussions.
>
>
> > we agreed on the current one because it is
> > simple, easy to understand, easy to code and very flexible (and =
more
> > important we never broke it !!!). We validate it, it is stable
> > since a very
> > long time. Why should we accept your way of coding it, and not
> the way of
> > somebody else at this final stage ?
> >
>
> To use a common label is the only alternative proposal we have, no =
others.
> It makes a lot of sense and is supported by several people on the =
list. Up
> to know only oppossed by you. Again what is rough consensus?
>
>
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Juergen Heiles [mailto:[email-masked]]
> > Sent: Monday, October 22, 2001 3:01 PM
> > To: Mannie, Eric; 'Kireeti Kompella'; [email-masked]
> > Subject: AW: Moving right along ...
> >
> >
> > Hi Eric,
> >
> > sorry for the delayed answer, but I have problems with the remtoe
> > LAN access
> > here in Geneva.
> > I am therefore sending the mail via my ITU e-mail account and hope =
it is
> > accepted by the ccamp list server.
> >
> > You compare groups with the multiplier, this is wrong. The
> multiplier sets
> > up n indivudal VC-n connections. The transport plane sees only the
> > individual VCs and the VC type (VC-4/372712711) is explicitly
> > defined. So no
> > additional support at the transport plane is needed. It is a
> pure control
> > plane feature.
> > Groups are not a pure control plane feature. When you setup a
> group (AUG,
> > TUG, VTG, STSG) the transport plane still has to handle the =
individual
> > VCs/SPEs that are part of the group. Due the independent timing of =
each
> > VC/STS-SPE pointer processing has to be done per individual VC/SPE. =
The
> > transport plane cannot switch the group as a whole between
> STM/STS ports.
> > The transport plane therefore has to automatically detect the
> structure of
> > the group, a TUG3 for example can consist of VC-3, VC-2, VC-12,
> VC-11 or a
> > mixture and that may change over the lifetime of the group.
> This automatic
> > detection is not a standard SONET/SDH feature. As I described
> in previous
> > e-mails it is possible to do it based on pointer values during non =
error
> > situations. During errors (defects, AIS condtions) of individual
> > singals of
> > a group (e.g. one VC-12 in a TUG3 fails) it can get problematic.
> > If a single
> > VC-12 in a TUG3 group has AIS (note that the AIS could result
> > from a failure
> > outside the LSP), I assume that still all the other VCs of the
> group shall
> > be connected without errors. No SONET/SDH standard covers the =
automatic
> > detection.
> > So in my view it is similarly to transparency of individual SOH
> > bytes. G.707
> > defines the individual SOH bytes, however transparency it is
> not standard
> > SONET/SDH and is therefore in the non-standard document. In the =
same way
> > G.707 defines groups, but not the automatic detection of the group
> > structure. So it should be moved to the non-standards document. At =
the
> > London meeting Kireeti said the decision on
> standard/non-standard features
> > is not based on rough consensus, but on what is in the ITU/ANSI
> documents.
> > Can you present me any ITU/ANSI standard that defines automatic
> > detection of
> > the group structure?
> >
> > You say groups are cool, may be for some applications. But note
> > that groups
> > have the same fragementation problem as contiguous concatenation.
> > The VCs in
> > a group always have to stay together. If for a example a TUG2
> consits of 3
> > VC-12 you cannot put them in arbitrary free time slots. They
> have stay in
> > the time slots that belong to a single TUG2.
> >
> >
> > Concering the lable, aligning the SONET labels with the SDH lables =
makes
> > live easier. It is also a sign that SONET and SDH are identical for =
most
> > parts. I also showed you that SONET uses the same two-stage =
interleaving
> > process as SDH. If you look at the attached figure from T1.105
> > you see that
> > the STS-1 time slots in an STS-N signal are not continously
> > number. First 3
> > STS-1s are combiend to a STS3 groupg and then the STS3 groups are
> > multiplexed. The same as SDH with AU3s and AUGs.
> > As the SONET lables will become the same as the SDH labels we
> > don't have to
> > evaluate much. I already made a proposal some time ago. Why =
introduce
> > different labels without a need?
> > You haven't provided a reason for different lables. We had
> several people
> > that wanted to have the same label structure and only you
> opposed. So what
> > is rough consensus?
> >
> > See my proposal for the labels below.
> >
> >
> > Juergen
> >
> >
> > This is my proposal for the label:
> >    The format of the label for SDH and/or SONET TDM-LSR link is:
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |               S               |   U   |   K   |   L   |   M   =
|
> >    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    For SDH, this is an extension of the numbering scheme defined in
> >    G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the =
same
> >    signaling scheme is used in order to provide easy
> interworkign between
> >    SDH and SONET signaling. For the S field a STS-3 group,which
> >    corresponds with the SDH AUG-1 level is introduce. The U field
> > indicates
> >    the position of the STS-3c-SPE or STS-1-SPE within the STS-3
> > group. The K
> >    field is not significant for SONET as it doesn't support =
structured
> >    STS-3c-SPEs and must be set to zero.
> >
> >    Each letter indicates a possible branch number starting at the
> >    parent node in the multiplex structure. Branches are considered =
as
> >    numbered in increasing order, starting from the top of the
> >    multiplexing structure. The numbering starts at 1, zero is used =
to
> >    indicate a non-significant field.
> >
> >    When a field is not significant in a particular context it MUST =
be
> >    set to zero when transmitted, and MUST be ignored when received.
> >
> >    When hierarchical SDH/SONET LSPs are used, an LSP with a given
> >    bandwidth can be used to tunnel lower order LSPs.  The higher
> >    order SDH/SONET LSP behaves as a virtual link with a given
> >    bandwidth (e.g. VC-3), it may also be used as a Forwarding
> >    Adjacency. A lower order SDH/SONET LSP can be established =
through
> >    that higher order LSP. Since a label is local to a (virtual) =
link,
> >    the highest part of that label is non-significant and is set to
> >    zero.
> >
> >    For instance, a VC-3 LSP can be advertised as a forwarding
> >    adjacency. In that case the labels allocated between the two =
ends
> >    of that LSP (i.e. for that "link") will have S, U and K set to
> >    zero, i.e., non-significant, while L and M will be used to
> >    indicate the signal allocated in that VC-3.
> >
> >      1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N
> >      indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
> >      multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 =
group,
> >      and S=3DN indicates the last AUG-1/STS-3 group of this =
multiplex.
> >      S is not significant for STM-0/STS-1.
> >
> >      2. U indicates a specific VC/STS-SPE inside a given =
AUG-1/STS-3
> >      group or STM-0/STS-1. U=3D1 indicates a single VC-4/STS-3c-SPE =
in a
> >      AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1,
> > while U=3D2->4
> >      indicates a specific VC-3/STS-1-SPE inside the given =
AUG-1/STS-3
> >      group.
> >
> >      3. K is only significant for SDH VC-4 and must be ignored for
> >      SONET and SDH HOVC-3. It indicates a specific branch of a =
VC-4.
> >      K=3D1 indicates that the VC-4 is not further subdivided and
> >      contains a C-4. K=3D2->4 indicates a specific TUG-3 inside the =
VC-
> >      4. K is not significant when the AUG-1 is divided into AU-3s
> >      (easy to read and test).
> >
> >      4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 =
SPE.
> >      It is not significant for an unstructured VC-4 or
> VC-3/STS-1 SPE. L=3D1
> >      indicates that the TUG-3/VC-3/STS-1 SPE is not further
> >      subdivided and contains a VC-3/C-3 in SDH or the equivalent in
> >      SONET. L=3D2->8 indicates a specific TUG-2/VT Group inside the
> >      corresponding higher order signal.
> >
> >      5. M indicates a specific branch of a TUG-2/VT Group. It is =
not
> >      significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 =
SPE.
> >      M=3D1 indicates that the TUG-2/VT Group is not further =
subdivided
> >      and contains a VC-2/VT-6 SPE. M=3D2->3 indicates a specific =
VT-3
> >      inside the corresponding VT Group, these values MUST NOT be =
used
> >      for SDH since there is no equivalent of VT-3 with SDH. =
M=3D4->6
> >      indicates a specific VC-12/VT-2 SPE inside the corresponding
> >      TUG-2/VT Group. M=3D7->10 indicates a specific VC-11/VT-1.5 =
SPE
> >      inside the corresponding TUG-2/VT Group. Note that M=3D0 =
denotes
> >      an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
> >
> >
> >       The M encoding is summarized in the following table:
> >
> >           M    SDH                          SONET
> >          ----------------------------------------------------------
> >           0    unstructured VC-4/VC-3  unstructured STS-1 SPE
> >           1    VC-2                    VT-6
> >           2    -                       1st VT-3
> >           3    -                       2nd VT-3
> >           4    1st VC-12               1st VT-2
> >           5    2nd VC-12               2nd VT-2
> >           6    3rd VC-12               3rd VT-2
> >           7    1st VC-11               1st VT-1.5
> >           8    2nd VC-11               2nd VT-1.5
> >           9    3rd VC-11               3rd VT-1.5
> >           10   4th VC-11               4th VT-1.5
> >
> >    In case of contiguous concatenation, the label that is used is =
the
> >    lowest label of the contiguously concatenated signal as =
explained
> >    before. The higher part of the label indicates where the signal
> >    starts and the lowest part is not significant. For instance, =
when
> >    requesting an STS-48c the label is S>0, U=3D0, K=3D0, L=3D0, =
M=3D0.
> >
> >    Examples of labels:
> >
> >    Example 1: S>0, U=3D1, K=3D1, L=3D0, M=3D0
> >    Denotes the unstructured VC-4/STS-3c-SPE of the Sth
> AUG-1/STS-3 group.
> >
> >    Example 2: S>0, U=3D1, K>1, L=3D1, M=3D0
> >    Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth =
AUG-1.
> >
> >    Example 3: S>0, U>1, K=3D0, L=3D0, M=3D0
> >    Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth
> > AUG-1/STS-3 group.
> >
> >    Example 4: S>0, U>1, K=3D0, L>1, M=3D1
> >    Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth
> VC-3/STS-1
> > SPE of the Sth AUG-1/STS-3 group.
> >
> >    Example 5: S>0, U>1, K=3D0, L>1, M=3D9
> >    Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the =
Uth
> > VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.
> >
> >    Example 6: S>0, U=3D1, K>1, L>1, M=3D5
> >    Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in
> the VC-4 of
> > the Sth AUG-1.
> >
> >
> >
> >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: Mannie, Eric [mailto:[email-masked]]
> > > Gesendet: Donnerstag, 18. Oktober 2001 18:58
> > > An: 'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> > > Betreff: RE: Moving right along ...
> > >
> > >
> > > Hello Juergen,
> > >
> > > Your comments are addressed hereafter. Note that you didn't =
raised any
> > > technical problem or mistake in your comments (i.e. the draft
> > "works" very
> > > well as it is).
> > >
> > > - the first comment is not about a technical issue but an
> > > "editorial" issue.
> > > - the second comment is about a change that will not bring any =
new
> > > capability.
> > >
> > > >Concerning the SDH/Sonet documents I want to raise a formal =
issue.
> > > >We have now two documents, a document that covers ITU/ANSI =
standard
> > > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document =
that
> > > covers non-standard features
> > > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in
> > > Appendix 1
> > > of the standard feature document a non standard feature (Group
> > signals) is
> > > listed. It is even mentioned that the use of groups (AUG, STSG,
> > > ...) is not
> > > described in standards. So this feature should be moved to the
> > > non-standards
> > > document. Otherwise the split of the documents doesn't make =
sense.
> > >
> > > We spend a considerable amount of time speaking about this
> > > particular issue
> > > and I still don't see any technical justification for what you =
said.
> > >
> > > For those who are not SDH/SONET experts some quick explanation:
> > >
> > > We call a "super-circuit" a set of physical circuits in the
> > > transport plane
> > > all belonging to the same LSP in the signaling plane. We
> > defined two kinds
> > > of super-circuits: "group circuits" and "multiplicative =
circuits".
> > >
> > > Multiplicative circuits are setup using the multiplier field that
> > > we defined
> > > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no
> > > objection
> > > about these ones.
> > >
> > > Group circuits are setup using the SDH/SONET naming for groups,
> > i.e. AUG,
> > > TUG, VTG (we defined the equivalent signal type in the =
signaling). The
> > > comment of Juergen is about these group circuits. A group circuit
> > > represents
> > > some bandwidth at a given place in the SDH/SONET multiplex. The
> > > advantage of
> > > such a super-circuit is that the customer can re-structure its
> > content as
> > > he/she likes. The operator doesn't care.
> > >
> > > Such an application is possible and is already implemented.
> SDH/SONET is
> > > self-describing, i.e. by looking at the signal one can understand
> > > how it is
> > > structured (like Juergen explained on the mailing list), so one
> > > can setup a
> > > circuit without describing the content (very very cool).
> > >
> > > The transport plane ignores that the signaling plane uses an
> > "abstraction"
> > > (i.e. an LSP) representing several physical circuits. Note that
> > > restoration
> > > and management belong respectively to the signaling plane and to =
the
> > > management plane in the IETF view (not to the transport plane
> > like in the
> > > ITU-T view).
> > >
> > > From that point of view, group circuits are a GMPLS signaling
> > > plane feature
> > > and not a transport plane feature. We put the comment on the fact
> > > that this
> > > is not defined (like GMPLS LSPs, etc) by ITU-T to make some
> guys happy.
> > >
> > > I could say clearly at the beginning of the draft that the signal
> > > types that
> > > we are defining in this document are not ITU-T signal types but
> > > GMPLS signal
> > > types (of course) whose have in some cases a direct
> > relationship with the
> > > ITU-T signal types.
> > >
> > > Any objection ?
> > >
> > > >For the Sonet and SDH labels in
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
> > > prefer to have the same coding for Sonet and SDH. That makes the
> > > implementation for Sonet and SDH simpler. Furthermore ITU and T1
> > > have tried
> > > over the last years to align Sonet and SDH as much as possible. =
The
> > > definition of different labels for Sonet and SDH contradicts =
these
> > > activities.
> > >
> > > We discussed this one since a long time as well. Let me be clear:
> > >
> > > - labels are local to an interface (we all agree).
> > > - a link (interface) is operated at one point in the time as
> > either SDH or
> > > SONET.
> > > - your proposal will require to re-evaluate many things.
> > > - and it took us a lot of time to fine-tune and to validate
> the current
> > > label structure.
> > > - we could have technical issues with your proposal that would
> > impact more
> > > than this draft (Dimitri saw some of them, please see with him).
> > > - you never provided a complete analysis of your proposal.
> > >
> > > But more important: your proposal doesn't bring any additional
> > > functionality
> > > to the draft.
> > >
> > > At this very late stage, since this not bringing any new
> > > functionality, and
> > > since the label structure is very stable since a long time, I
> > would prefer
> > > not to restart a long technical discussion to change and
> re-validate the
> > > draft.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > >
> > >
> > > > -----Urspr=FCngliche Nachricht-----
> > > > Von: Kireeti Kompella [mailto:[email-masked]]
> > > > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > > > An: [email-masked]
> > > > Betreff: Moving right along ...
> > > >
> > > >
> > > > Despite the energetic subject line, we the WG chairs have been
> > > > lax in our duties.  So, here goes:
> > > >
> > > > Lou has submitted the latest versions of the generalized
> > > > signaling documents quite some time ago (thanks, Lou):
> > > >
> > > > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > > draft-ietf-mpls-generalized-signaling-06.txt
> > > >
> > > > Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > > >
> > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > > >
> > > > All of these should have addressed the issues raised in the =
earlier
> > > > versions.  Please read the new versions, and send your comments =
to
> > > > the list by Tuesday Oct 23.  At that point, when the final =
round
> > > > of comments have been addressed, these docs will go to IESG =
Last
> > > > Call.  If any one objects to sending these docs to IESG Last =
Call,
> > > > raise your issues now.
> > > >
> > > > I see that the GMPLS architecture document is a CCAMP WG doc, =
but
> > > > the minutes say that we should look for consensus on the list.  =
So,
> > > > if you think this doc *shouldn't* be a WG doc, let us know.  =
(If we
> > > > arrived at a consensus, remind me :-))  If nothing is heard, =
the doc
> > > > will progress to WG Last Call.
> > > >
> > > > The docs
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration =
to be
> > > > CCAMP WG docs; consensus at the meeting was Yes.  Please let =
the
> > > > list know what your thinking is on these.  (BTW, both these =
docs
> > > > were to have some edits done.  If the authors could do that =
before
> > > > the next IETF, we can try to make more progress then.)
> > > >
> > > > The MIB overview doc was recently posted.  Please read and =
comment
> > > > to the list.
> > > >
> > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > > was generally thought to be useful; it will be published as a
> > > > CCAMP informational doc.  This begins a two week Last Call on
> > > > the doc, ending Tuesday Oct 30.
> > > >
> > > > There was no consensus on whether the GMPLS framework should be
> > > > a CCAMP WG doc.  Please indicate your pleasure.
> > > >
> > > > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > > > raised that this draft is close to ready for WG Last Call.  =
Please
> > > > review it, and let us know if you disagree.
> > > >
> > > > The OLI requirements doc was broadly accepted.  Please let the
> > > > list know if you think this doc should be a WG doc.
> > > >
> > > > It's still open whether we (the IETF) should be working on
> > > > LMP-WDM.  I urge the authors to keep on working on the doc, and
> > > > keeping it in sync with LMP; however, we will postpone making =
it
> > > > a CCAMP WG doc until the issue is resolved.  Hopefully that =
will
> > > > happen in Salt Lake City.
> > > >
> > > > There was reasonable interest in the tunnel trace requirements
> > > > doc.  Let's formalize this: do you think this should be made a
> > > > CCAMP WG document?
> > > >
> > > > Summary:
> > > >
> > > > 1) Final comments and IESG Last Call readiness for:
> > > > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > > draft-ietf-mpls-generalized-signaling-06.txt
> > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > > >
> > > > 2) Should the following documents be CCAMP WG docs?
> > > > draft-bonica-tunneltrace-02.txt
> > > > draft-fontana-ccamp-gmpls-g709-00.txt
> > > > draft-ietf-ccamp-gmpls-architecture-00.txt
> > > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > > > draft-many-ccamp-gmpls-framework-00.txt
> > > > draft-many-oli-reqts-00.txt
> > > >
> > > > 3) Comment on MIB overview.
> > > >
> > > > 4) Two week Last Call comments on
> > > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > >
> > > > 5) Last Call readiness of
> > > > draft-ietf-ccamp-gmpls-architecture-00.txt
> > > > draft-ietf-ccamp-lmp-01.txt
> > > >
> > > > Thanks,
> > > > Kireeti.
> > > >
> > >

Delivery-date: Tue, 23 Oct 2001 10:28:19 -0700
To: [email-masked]
cc: [email-masked]
Subject: Re: Generalized Signalling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 10:25:56 -0700
From: Yakov Rekhter <[email-masked]>

Shehzad,

> Yakov,
> 
> The percentage of carriers that have all of their requirements met by the
> current GMPLS drafts is an unknown.  However the following points still 
> need to be addressed.
> 
> 1.  Why would an operator adopt GMPLS infrastructure if it only carried a
> subset of the transport services that they are already offer to customers?
> In effect spending more and getting less.

It depends on the percentage of the total profit that could be generated by
the subset.

> 2.  Why is there a problem reserving a code-point for a service that some
> vendors may wish to implement on their GMPLS equipment?  Presumably they
> would not implement capability for which there is no demand.

If all you ask is a code-point, this code point is relevant only
to the LSPs' end-points, and not every GMPLS vendor is *required* to support
this code-point, then I don't think there is a problem with doing
this.

> 3.  What is the process by which certain transport services are decided
> suitable for inclusion into the GMPLS specifications/drafts?  It seems that
> inclusion of additional services fraught with difficulties, this is likely
> to get worse when the drafts turn into specifications.

The types of services that would be suitable for inclusion are the services
that (a) would *not* require changes/upgrades to the GMPLS core, and (b) would
not require every GMPLS vendor to implement every service. 

Yakov.

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

Delivery-date: Tue, 23 Oct 2001 09:30:16 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Eric Gray'" <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion
Date: Tue, 23 Oct 2001 11:49:28 -0400

Eric, let's see if I got this right... 

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Eric Gray [mailto:[email-masked]] 
Sent:	Tuesday, October 23, 2001 11:37 AM
To:	Yakov Rekhter
Cc:	Lazer, Monica A, NNAD; [email-masked]
Subject:	Re: Generalized Signaling - LSP Encoding Type expansion

Yakov,

    To be completely fair, it is NOT necessary for any provider to run
"*all possible services*" for the introduction of a new control plane
which supports only a subset of those services to be costly.  It is
only necessary for a provider to need to provide some services from
that subset and some services from the universe-less-that-subset for
it to be necessary to either support multiple control planes, or avoid
use of the new control plane.
[[Lazer, AT&T]]  Yes, what I mean is that if a given NE needs two control
planes that is bad.

    This is probably what Monica means by diminished value.

    On the other hand, GMPLS is intended to be optimized for IP which
- in some people's model of *the future of networking* - might mean
that it will likely be adopted in spite of a perceived diminished value
in the general sense. Hence, I think part of your point might be better
expressed as:
[[Lazer, AT&T]] As far as I understand, MPLS is for IP, GMPLS encompasses
extensions needed to control the transport network. IP networks, whether
they represent a large percentage of the traffic, still run over facilities.
In my view GMPLS is a control plane intended for managing facilities. Saying
that GMPLS is only intended for IP is puzzling, because if this is true, why
is it a claim that it can provide the control plane of transport facilities?

    *Extending GMPLS to support all possible applications in an effort
    to reduce a perception of diminished value, would actually diminish
    the value of GMPLS for its target application(s).*
[[Lazer, AT&T]] If GMPLS is intended as a transport control plane, then we
should work to make it that. 

What do you think?

You wrote:

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

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Tue, 23 Oct 2001 09:05:00 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 11:49:47 -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_01C15BDA.57D4DA50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Yakov Rekhter [mailto:[email-masked]]=20
Sent:	Tuesday, October 23, 2001 11:17 AM
To:	Lazer, Monica A, NNAD
Cc:	[email-masked]'; [email-masked]
Subject:	Re: Generalized Signaling - LSP Encoding Type expansion=20

Monica,

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

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

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

Regards, again
Yakov.

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Generalized Signaling - LSP Encoding Type expansion </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Yakov, </FONT>
<BR><FONT SIZE=3D2>We seem to have the same discussion on two separate =
threads.</FONT>
</P>

<P><FONT SIZE=3D2>Monica A. Lazer</FONT>
<BR><FONT SIZE=3D2>Advanced Transport Technology and Architecture =
Planning</FONT>
</P>

<P><FONT SIZE=3D2>908 234 8462</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Yakov Rekhter [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Tuesday, October 23, 2001 11:17 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Lazer, Monica A, =
NNAD</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]'; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: Generalized Signaling - LSP Encoding Type expansion </FONT>
</P>

<P><FONT SIZE=3D2>Monica,</FONT>
</P>

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

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

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

<P><FONT SIZE=3D2>Regards, again</FONT>
<BR><FONT SIZE=3D2>Yakov.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15BDA.57D4DA50--

Delivery-date: Tue, 23 Oct 2001 09:02:36 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Generalized Signalling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 16:45:58 +0100

Yakov,

The percentage of carriers that have all of their requirements met by the
current GMPLS drafts is an unknown.  However the following points still need
to be addressed.

1.  Why would an operator adopt GMPLS infrastructure if it only carried a
subset of the transport services that they are already offer to customers?
In effect spending more and getting less.

2.  Why is there a problem reserving a code-point for a service that some
vendors may wish to implement on their GMPLS equipment?  Presumably they
would not implement capability for which there is no demand.

3.  What is the process by which certain transport services are decided
suitable for inclusion into the GMPLS specifications/drafts?  It seems that
inclusion of additional services fraught with difficulties, this is likely
to get worse when the drafts turn into specifications.

Shehzad

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

Delivery-date: Tue, 23 Oct 2001 08:56:57 -0700
From: John Drake <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 08:41:30 -0700

I think it's the case that if we'e dealing with end-end services across a
GMPLS core, the types of end-end services that could be supported is fairly
open without having to upgrade the GMPLS core, and without having to require
every vendor implementing GMPLS to support every conceivable type of end-end
service.  I.e., you could deploy a GMPLS network with core switches from
vendor 1, SONET/SDH grooming service devices from vendor 2, IP router
service devicess from vendor 3, ATM service devices from vendor 3,
transparent LAN service devices from vendor 4, private line service devices
from vendor 5, etc 

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 8:17 AM
To: Lazer, Monica A, NNAD
Cc: [email-masked]'; [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion 

Monica,

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

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

Yakov.

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

Delivery-date: Tue, 23 Oct 2001 08:56:50 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: 'Juergen Heiles' <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: FW: Moving right along ...
Date: Tue, 23 Oct 2001 17:39:46 +0200

Dear ITU-T and T1 folks,

Since Juergen is fowarding some e-mails from the IETF CCAMP mailing list to
ITU-T and T1, I thought it is appropriate to forward also my answer :-) (I
put the full text).

Please note also that I don't want to start an inter-mailing list flooding
between three bodies, since all people interested by GMPLS are on the CCAMP
mailing list I guess.

I tried to remove all frustrations in my answer :-)

Kind regards,

Eric

-----Original Message-----
From: Mannie, Eric 
Sent: Tuesday, October 23, 2001 5:12 PM
To: 'Juergen Heiles'; 'Kireeti Kompella'; [email-masked]
Subject: RE: Moving right along ...

Juergen,

I am answering to your e-mails exactly because I am the editor of these
documents. Some people don't want to answer anymore. Answering or not to
e-mails is a personal decision of each one, nobody is forced to answer.

You had the feedback from the mailing list. In general when people are happy
with what they saw they don't spend time to add more comments.

Your proposals were supported by you and Maarten. I answered with Dimitri.
It is easy of course (for all of us) to ask all our colleagues and friends
to flood a mailing list.

Concerning your request to move the group signals to the other draft: this
was answered publicly by Kireeti during the last CCAMP meeting and the
answer was no. I asked again to Kireeti a couple of weeks ago, same answer.
This is also the advice that I received from Rob.

Concerning your label proposal: details are not yet cooked from our (I and
Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding Adjacency
there is no second STS-3 group, sorry if my example was confusing). Your
text needs to be corrected but that's a detail, it just shows that it is
quite difficult to write a text that works in all cases.

We spend a considerable amount of time reviewing the current label encoding
and we made sure that it works in the craziest cases. Indeed, this is the
most stable part of the SDH/SONET draft since a very long time. By adopting
your proposal we will have to do it again for no additional benefit and we
will need another WG last call (you know it perfectly). That's why I refused
during the WG last call some months ago, and why I am refusing again.

As an editor my job is also to keep the boat in the middle of the river and
to make sure that drafts are progressing and are not being constantly
re-worded. Also, I don't want to force all manufacturers to change their
implementations (prototypes:-) of the SONET label just because you found
another way of encoding it. One solution or the other is more a matter of
personal feeling.

At this stage, as a co-author you should be more concerned by finishing this
work. We can spend years having new ideas, improving and proposing
modifications to a draft.

It is a fact that we spend a huge amount of time (for me it represents
months of work since the beginning of year 2000) fine-tuning this draft. Now
it is time to publish it.

>From the technical point of view your proposals versus keeping the current
text will not change anything. It started as a political issue and I hope
that it didn't become a personal issue.

I am just asking you to help us to publish this work, even if it is not 100%
as you would like to see it.

Kind regards,

Eric

>-----Original Message-----
>From: Juergen Heiles [mailto:[email-masked]]
>Sent: Tuesday, October 23, 2001 1:46 PM
>To: Mannie, Eric; 'Juergen Heiles'; 'Kireeti Kompella';
>[email-masked]
>Subject: AW: Moving right along ...
>
>
>Eric,
>
><frustration mode on>
>it is getting boring and frustrating to discuss the same issue for several
>month with several people supporting the proposals and only one person
>opposing them. But this person has the power to reject them as editor. If
>this is the way IETF works I have to accept it. However I have to
reconsider
>my future activities in this case.
>It seems that you think I want to block the GMPLS activities by bringing up
>late issues. That is not the case, we have a long discussion on these
issues
>for month (on the ccamp list and on private lists) and the only rejection
>came from your side.
><frustration mode off>
>
>So see my comments below
>
>Juergen
>
> -----Ursprüngliche Nachricht-----
> Von: Mannie, Eric [mailto:[email-masked]]
> Gesendet: Dienstag, 23. Oktober 2001 12:23
> An: 'Juergen Heiles'; 'Kireeti Kompella'; [email-masked]
> Betreff: RE: Moving right along ...
>
>
> Hi Juergen,
>
> We already discussed all these points (at least 5 times) :-)
even more

>
> - about automatic detection:
>
> Indeed, you either configure a box with a signal structure, or if
> implemented you can ask to the box to discover itself the structure (what
> you call automatic detection).
>
For groups the box has to discover the structure itself.

> Automatic detection is a process applied internally to a box, and this is
> totally invisible to any other box in the network. This is an
> implementation
> issue, not a protocol issue since the protocol defines everyhting you need
> to do it.
>
> I understand your frustration that SDH standards don't describe all the
> processes for an implementation, but in general standards don't touch that
> part.
>
SDH and Sonet standards define detailed equipment functionality in order to
ensure interworking.
ITU has for example G.783 that defeins in detail what to do in SDH
equipment. Even G.707 gives some details
on pointer processing (genration, interpretation). For SONET we have GR-253
from Telcordia which provides this details.
No of them mentiones automatic detection.

> Automatic detection is a matter of reading the standard and understanding
> how the multiplexing works. By the way, you explained it yourself
> very well.
>
> The fact that a process is not described in some SDH standards has no
> meaning, it is simply not relevant. Every manufacturer is free to do its
> implementation as he likes if the protocol is fullfilled, and this is the
> case.
>
> - about the comparison of automatic detection and transparency:
>
> You are comparing apples with chocolates. Transparency may require to
> transport bytes in unused bytes, so in that case it changes the overhead.
> Automatic detection is an internal process.
>
> - You wrote: "During errors (defects, AIS condtions) of individual singals
> of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic."
>
> and I already answered many times: a super signal (group signal) is one
> single LSP. If something fails inside everything fails. In that case you
> don't need to demultiplex anymore, you just protect/restore the whole (if
> required). A group signal is a signaling plane object, i.e. one
> single LSP.
>
I mentioned the case that the problem is outside your LSP. You get for
example a signal from a user and setup a group LSP.
Now due to problems on the user side one of the VCs has AIS, may be the user
isn't even using this VC currently. You cannot protect it as the problem is
outside the LSP. If you now drop all other VCs of this group your user would
be very happy I assume.

> - Can you present me any ITU/ANSI standard that defines automatic
> detection
> of the group structure?
>
> No need, this is not in the scope of ITU/ANSI standards.

Are you defining what is in the scope of ITU/ANSI standards?
This is in the scope of ITU/ANSI/Telcordia standards. Look on G.707 pointer
interpretation, G.783 and GR-253 as mentioned above. When we talk about
standard SONET/SDH it includes the equipment functionality. For ETSI we even
have compliance statements that go down to these details.
I have no problems when soemone implements this feature, but we should no
give the impression that this is a standard SONET/SDH feature by putting it
into the standard features document. Move it to the non-standard document.

>
> - You wrote " You haven't provided a reason for different lables. We had
> several people that wanted to have the same label structure and only you
> opposed. So what is rough consensus?"
>
> The labels are local per interface, so they are "different" by definition
> since an SDH interface is not a Sonet interface.

A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N with AU-3 have
the identical structure.
But with the current proposal we have to use different lables. Is this
simple?

> However, we
> defined the two
> label formats based on the same principles, i.e. the first field is the
> index of the first AUG-1/STS-1 (easy). We chosen not to indicate any level
> of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because this
> is not needed and less flexible. A label is just a simple pointer in the
> multiplex, how to interpret the content of what is pointed to is
> not defined
> by the label.
>

I just took the SDH AU3 case and used it for SONET. So if you see a problem
it would already apply to the defined SDH lable.

> Using your proposal we would introduce a particular case, and in that case
> there is no reason why we should not introduce other particular
> case (AUG-4,
> etc). At the end we would have something totally unreadable.
>
> Your proposal has also some issues, e.g. with your definition of the S
> field:
>
> "1. S is the index of a particular AUG-1/STS-3 group. S=1->N
>     indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
>     multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
>     and S=N indicates the last AUG-1/STS-3 group of this multiplex.
>     S is not significant for STM-0/STS-1.
>
> What happens if a link is not a a multiple of 3xN STS-1 ? For instance, a
> virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an STS-4.
> There is no real second STS-3 group. Your proposal is not
> appropriate to the
> level of flexibility that we want to provide. Another observations: our
> undrestanding of the label is that it is defined before any interleaving,
> not after.
>

Oh, suddently we have STS-4, STS-4 virtual links poping up, interesting. But
couldn't we also have virtual SDH signals with only 5 AU-3?
I don't know as I don't have any information about this virtual link
concept. But if you introduce something like this there should be no
difference between SONET and SDH. Otherwise we introduce new differences
between SONET and SDH that we tried to avoid now for some years (see
Deborahs e-mail). We learned from the mistakes made during the development
of SONET and SDH. In todays global world we don't want these differences.
And that is the reason why we propose to use a common lable. Don't make the
same mistakes again. So if you see a problem it also applies to the defined
SDH label.

> I am opposed because your proposal doesn't bring any new functionality.
> There are probably 100 ways of coding such a label for SDH and Sonet. We
> discussed it during one year,
The proposal to use a common lable is already disucssed for several month
(over 1/2 year) as soon as we got involved in the GMPLS discussions.

> we agreed on the current one because it is
> simple, easy to understand, easy to code and very flexible (and more
> important we never broke it !!!). We validate it, it is stable
> since a very
> long time. Why should we accept your way of coding it, and not the way of
> somebody else at this final stage ?
>

To use a common label is the only alternative proposal we have, no others.
It makes a lot of sense and is supported by several people on the list. Up
to know only oppossed by you. Again what is rough consensus?

> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Juergen Heiles [mailto:[email-masked]]
> Sent: Monday, October 22, 2001 3:01 PM
> To: Mannie, Eric; 'Kireeti Kompella'; [email-masked]
> Subject: AW: Moving right along ...
>
>
> Hi Eric,
>
> sorry for the delayed answer, but I have problems with the remtoe
> LAN access
> here in Geneva.
> I am therefore sending the mail via my ITU e-mail account and hope it is
> accepted by the ccamp list server.
>
> You compare groups with the multiplier, this is wrong. The multiplier sets
> up n indivudal VC-n connections. The transport plane sees only the
> individual VCs and the VC type (VC-4/372712711) is explicitly
> defined. So no
> additional support at the transport plane is needed. It is a pure control
> plane feature.
> Groups are not a pure control plane feature. When you setup a group (AUG,
> TUG, VTG, STSG) the transport plane still has to handle the individual
> VCs/SPEs that are part of the group. Due the independent timing of each
> VC/STS-SPE pointer processing has to be done per individual VC/SPE. The
> transport plane cannot switch the group as a whole between STM/STS ports.
> The transport plane therefore has to automatically detect the structure of
> the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a
> mixture and that may change over the lifetime of the group. This automatic
> detection is not a standard SONET/SDH feature. As I described in previous
> e-mails it is possible to do it based on pointer values during non error
> situations. During errors (defects, AIS condtions) of individual
> singals of
> a group (e.g. one VC-12 in a TUG3 fails) it can get problematic.
> If a single
> VC-12 in a TUG3 group has AIS (note that the AIS could result
> from a failure
> outside the LSP), I assume that still all the other VCs of the group shall
> be connected without errors. No SONET/SDH standard covers the automatic
> detection.
> So in my view it is similarly to transparency of individual SOH
> bytes. G.707
> defines the individual SOH bytes, however transparency it is not standard
> SONET/SDH and is therefore in the non-standard document. In the same way
> G.707 defines groups, but not the automatic detection of the group
> structure. So it should be moved to the non-standards document. At the
> London meeting Kireeti said the decision on standard/non-standard features
> is not based on rough consensus, but on what is in the ITU/ANSI documents.
> Can you present me any ITU/ANSI standard that defines automatic
> detection of
> the group structure?
>
> You say groups are cool, may be for some applications. But note
> that groups
> have the same fragementation problem as contiguous concatenation.
> The VCs in
> a group always have to stay together. If for a example a TUG2 consits of 3
> VC-12 you cannot put them in arbitrary free time slots. They have stay in
> the time slots that belong to a single TUG2.
>
>
> Concering the lable, aligning the SONET labels with the SDH lables makes
> live easier. It is also a sign that SONET and SDH are identical for most
> parts. I also showed you that SONET uses the same two-stage interleaving
> process as SDH. If you look at the attached figure from T1.105
> you see that
> the STS-1 time slots in an STS-N signal are not continously
> number. First 3
> STS-1s are combiend to a STS3 groupg and then the STS3 groups are
> multiplexed. The same as SDH with AU3s and AUGs.
> As the SONET lables will become the same as the SDH labels we
> don't have to
> evaluate much. I already made a proposal some time ago. Why introduce
> different labels without a need?
> You haven't provided a reason for different lables. We had several people
> that wanted to have the same label structure and only you opposed. So what
> is rough consensus?
>
> See my proposal for the labels below.
>
>
> Juergen
>
>
> This is my proposal for the label:
>    The format of the label for SDH and/or SONET TDM-LSR link is:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               S               |   U   |   K   |   L   |   M   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    For SDH, this is an extension of the numbering scheme defined in
>    G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same
>    signaling scheme is used in order to provide easy interworkign between
>    SDH and SONET signaling. For the S field a STS-3 group,which
>    corresponds with the SDH AUG-1 level is introduce. The U field
> indicates
>    the position of the STS-3c-SPE or STS-1-SPE within the STS-3
> group. The K
>    field is not significant for SONET as it doesn't support structured
>    STS-3c-SPEs and must be set to zero.
>
>    Each letter indicates a possible branch number starting at the
>    parent node in the multiplex structure. Branches are considered as
>    numbered in increasing order, starting from the top of the
>    multiplexing structure. The numbering starts at 1, zero is used to
>    indicate a non-significant field.
>
>    When a field is not significant in a particular context it MUST be
>    set to zero when transmitted, and MUST be ignored when received.
>
>    When hierarchical SDH/SONET LSPs are used, an LSP with a given
>    bandwidth can be used to tunnel lower order LSPs.  The higher
>    order SDH/SONET LSP behaves as a virtual link with a given
>    bandwidth (e.g. VC-3), it may also be used as a Forwarding
>    Adjacency. A lower order SDH/SONET LSP can be established through
>    that higher order LSP. Since a label is local to a (virtual) link,
>    the highest part of that label is non-significant and is set to
>    zero.
>
>    For instance, a VC-3 LSP can be advertised as a forwarding
>    adjacency. In that case the labels allocated between the two ends
>    of that LSP (i.e. for that "link") will have S, U and K set to
>    zero, i.e., non-significant, while L and M will be used to
>    indicate the signal allocated in that VC-3.
>
>      1. S is the index of a particular AUG-1/STS-3 group. S=1->N
>      indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
>      multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
>      and S=N indicates the last AUG-1/STS-3 group of this multiplex.
>      S is not significant for STM-0/STS-1.
>
>      2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3
>      group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a
>      AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1,
> while U=2->4
>      indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3
>      group.
>
>      3. K is only significant for SDH VC-4 and must be ignored for
>      SONET and SDH HOVC-3. It indicates a specific branch of a VC-4.
>      K=1 indicates that the VC-4 is not further subdivided and
>      contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-
>      4. K is not significant when the AUG-1 is divided into AU-3s
>      (easy to read and test).
>
>      4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
>      It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1
>      indicates that the TUG-3/VC-3/STS-1 SPE is not further
>      subdivided and contains a VC-3/C-3 in SDH or the equivalent in
>      SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
>      corresponding higher order signal.
>
>      5. M indicates a specific branch of a TUG-2/VT Group. It is not
>      significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.
>      M=1 indicates that the TUG-2/VT Group is not further subdivided
>      and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
>      inside the corresponding VT Group, these values MUST NOT be used
>      for SDH since there is no equivalent of VT-3 with SDH. M=4->6
>      indicates a specific VC-12/VT-2 SPE inside the corresponding
>      TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE
>      inside the corresponding TUG-2/VT Group. Note that M=0 denotes
>      an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
>
>
>       The M encoding is summarized in the following table:
>
>           M    SDH                          SONET
>          ----------------------------------------------------------
>           0    unstructured VC-4/VC-3  unstructured STS-1 SPE
>           1    VC-2                    VT-6
>           2    -                       1st VT-3
>           3    -                       2nd VT-3
>           4    1st VC-12               1st VT-2
>           5    2nd VC-12               2nd VT-2
>           6    3rd VC-12               3rd VT-2
>           7    1st VC-11               1st VT-1.5
>           8    2nd VC-11               2nd VT-1.5
>           9    3rd VC-11               3rd VT-1.5
>           10   4th VC-11               4th VT-1.5
>
>    In case of contiguous concatenation, the label that is used is the
>    lowest label of the contiguously concatenated signal as explained
>    before. The higher part of the label indicates where the signal
>    starts and the lowest part is not significant. For instance, when
>    requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.
>
>    Examples of labels:
>
>    Example 1: S>0, U=1, K=1, L=0, M=0
>    Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group.
>
>    Example 2: S>0, U=1, K>1, L=1, M=0
>    Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.
>
>    Example 3: S>0, U>1, K=0, L=0, M=0
>    Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth
> AUG-1/STS-3 group.
>
>    Example 4: S>0, U>1, K=0, L>1, M=1
>    Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1
> SPE of the Sth AUG-1/STS-3 group.
>
>    Example 5: S>0, U>1, K=0, L>1, M=9
>    Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth
> VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.
>
>    Example 6: S>0, U=1, K>1, L>1, M=5
>    Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of
> the Sth AUG-1.
>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Mannie, Eric [mailto:[email-masked]]
> > Gesendet: Donnerstag, 18. Oktober 2001 18:58
> > An: 'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> > Betreff: RE: Moving right along ...
> >
> >
> > Hello Juergen,
> >
> > Your comments are addressed hereafter. Note that you didn't raised any
> > technical problem or mistake in your comments (i.e. the draft
> "works" very
> > well as it is).
> >
> > - the first comment is not about a technical issue but an
> > "editorial" issue.
> > - the second comment is about a change that will not bring any new
> > capability.
> >
> > >Concerning the SDH/Sonet documents I want to raise a formal issue.
> > >We have now two documents, a document that covers ITU/ANSI standard
> > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that
> > covers non-standard features
> > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in
> > Appendix 1
> > of the standard feature document a non standard feature (Group
> signals) is
> > listed. It is even mentioned that the use of groups (AUG, STSG,
> > ...) is not
> > described in standards. So this feature should be moved to the
> > non-standards
> > document. Otherwise the split of the documents doesn't make sense.
> >
> > We spend a considerable amount of time speaking about this
> > particular issue
> > and I still don't see any technical justification for what you said.
> >
> > For those who are not SDH/SONET experts some quick explanation:
> >
> > We call a "super-circuit" a set of physical circuits in the
> > transport plane
> > all belonging to the same LSP in the signaling plane. We
> defined two kinds
> > of super-circuits: "group circuits" and "multiplicative circuits".
> >
> > Multiplicative circuits are setup using the multiplier field that
> > we defined
> > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no
> > objection
> > about these ones.
> >
> > Group circuits are setup using the SDH/SONET naming for groups,
> i.e. AUG,
> > TUG, VTG (we defined the equivalent signal type in the signaling). The
> > comment of Juergen is about these group circuits. A group circuit
> > represents
> > some bandwidth at a given place in the SDH/SONET multiplex. The
> > advantage of
> > such a super-circuit is that the customer can re-structure its
> content as
> > he/she likes. The operator doesn't care.
> >
> > Such an application is possible and is already implemented. SDH/SONET is
> > self-describing, i.e. by looking at the signal one can understand
> > how it is
> > structured (like Juergen explained on the mailing list), so one
> > can setup a
> > circuit without describing the content (very very cool).
> >
> > The transport plane ignores that the signaling plane uses an
> "abstraction"
> > (i.e. an LSP) representing several physical circuits. Note that
> > restoration
> > and management belong respectively to the signaling plane and to the
> > management plane in the IETF view (not to the transport plane
> like in the
> > ITU-T view).
> >
> > From that point of view, group circuits are a GMPLS signaling
> > plane feature
> > and not a transport plane feature. We put the comment on the fact
> > that this
> > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy.
> >
> > I could say clearly at the beginning of the draft that the signal
> > types that
> > we are defining in this document are not ITU-T signal types but
> > GMPLS signal
> > types (of course) whose have in some cases a direct
> relationship with the
> > ITU-T signal types.
> >
> > Any objection ?
> >
> > >For the Sonet and SDH labels in
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
> > prefer to have the same coding for Sonet and SDH. That makes the
> > implementation for Sonet and SDH simpler. Furthermore ITU and T1
> > have tried
> > over the last years to align Sonet and SDH as much as possible. The
> > definition of different labels for Sonet and SDH contradicts these
> > activities.
> >
> > We discussed this one since a long time as well. Let me be clear:
> >
> > - labels are local to an interface (we all agree).
> > - a link (interface) is operated at one point in the time as
> either SDH or
> > SONET.
> > - your proposal will require to re-evaluate many things.
> > - and it took us a lot of time to fine-tune and to validate the current
> > label structure.
> > - we could have technical issues with your proposal that would
> impact more
> > than this draft (Dimitri saw some of them, please see with him).
> > - you never provided a complete analysis of your proposal.
> >
> > But more important: your proposal doesn't bring any additional
> > functionality
> > to the draft.
> >
> > At this very late stage, since this not bringing any new
> > functionality, and
> > since the label structure is very stable since a long time, I
> would prefer
> > not to restart a long technical discussion to change and re-validate the
> > draft.
> >
> > Kind regards,
> >
> > Eric
> >
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Kireeti Kompella [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > > An: [email-masked]
> > > Betreff: Moving right along ...
> > >
> > >
> > > Despite the energetic subject line, we the WG chairs have been
> > > lax in our duties.  So, here goes:
> > >
> > > Lou has submitted the latest versions of the generalized
> > > signaling documents quite some time ago (thanks, Lou):
> > >
> > > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > draft-ietf-mpls-generalized-signaling-06.txt
> > >
> > > Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > >
> > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >
> > > All of these should have addressed the issues raised in the earlier
> > > versions.  Please read the new versions, and send your comments to
> > > the list by Tuesday Oct 23.  At that point, when the final round
> > > of comments have been addressed, these docs will go to IESG Last
> > > Call.  If any one objects to sending these docs to IESG Last Call,
> > > raise your issues now.
> > >
> > > I see that the GMPLS architecture document is a CCAMP WG doc, but
> > > the minutes say that we should look for consensus on the list.  So,
> > > if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > > arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > > will progress to WG Last Call.
> > >
> > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > > CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > > list know what your thinking is on these.  (BTW, both these docs
> > > were to have some edits done.  If the authors could do that before
> > > the next IETF, we can try to make more progress then.)
> > >
> > > The MIB overview doc was recently posted.  Please read and comment
> > > to the list.
> > >
> > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > was generally thought to be useful; it will be published as a
> > > CCAMP informational doc.  This begins a two week Last Call on
> > > the doc, ending Tuesday Oct 30.
> > >
> > > There was no consensus on whether the GMPLS framework should be
> > > a CCAMP WG doc.  Please indicate your pleasure.
> > >
> > > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > > raised that this draft is close to ready for WG Last Call.  Please
> > > review it, and let us know if you disagree.
> > >
> > > The OLI requirements doc was broadly accepted.  Please let the
> > > list know if you think this doc should be a WG doc.
> > >
> > > It's still open whether we (the IETF) should be working on
> > > LMP-WDM.  I urge the authors to keep on working on the doc, and
> > > keeping it in sync with LMP; however, we will postpone making it
> > > a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > > happen in Salt Lake City.
> > >
> > > There was reasonable interest in the tunnel trace requirements
> > > doc.  Let's formalize this: do you think this should be made a
> > > CCAMP WG document?
> > >
> > > Summary:
> > >
> > > 1) Final comments and IESG Last Call readiness for:
> > > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > draft-ietf-mpls-generalized-signaling-06.txt
> > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >
> > > 2) Should the following documents be CCAMP WG docs?
> > > draft-bonica-tunneltrace-02.txt
> > > draft-fontana-ccamp-gmpls-g709-00.txt
> > > draft-ietf-ccamp-gmpls-architecture-00.txt
> > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > > draft-many-ccamp-gmpls-framework-00.txt
> > > draft-many-oli-reqts-00.txt
> > >
> > > 3) Comment on MIB overview.
> > >
> > > 4) Two week Last Call comments on
> > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >
> > > 5) Last Call readiness of
> > > draft-ietf-ccamp-gmpls-architecture-00.txt
> > > draft-ietf-ccamp-lmp-01.txt
> > >
> > > Thanks,
> > > Kireeti.
> > >
> >

Delivery-date: Tue, 23 Oct 2001 08:44:26 -0700
Date: Tue, 23 Oct 2001 11:36:52 -0400
From: Eric Gray <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "Lazer, Monica A, NNAD" <[email-masked]>, [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

Yakov,

    To be completely fair, it is NOT necessary for any provider to run
"*all possible services*" for the introduction of a new control plane
which supports only a subset of those services to be costly.  It is
only necessary for a provider to need to provide some services from
that subset and some services from the universe-less-that-subset for
it to be necessary to either support multiple control planes, or avoid
use of the new control plane.

    This is probably what Monica means by diminished value.

    On the other hand, GMPLS is intended to be optimized for IP which
- in some people's model of *the future of networking* - might mean
that it will likely be adopted in spite of a perceived diminished value
in the general sense. Hence, I think part of your point might be better
expressed as:

    *Extending GMPLS to support all possible applications in an effort
    to reduce a perception of diminished value, would actually diminish
    the value of GMPLS for its target application(s).*

What do you think?

You wrote:

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

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Tue, 23 Oct 2001 08:23:21 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 11:20:21 -0400

Yakov,
Thank you for your reply. I appreciate your comments, but we may have some
differences of opinion. For convenience, I am inserting my opinions in line.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Yakov Rekhter [mailto:[email-masked]] 
Sent:	Monday, October 22, 2001 4:12 PM
To:	Lazer, Monica A, NNAD
Cc:	[email-masked]
Subject:	Re: Generalized Signaling - LSP Encoding Type expansion 

Monica,

> Dimitri,
> Actually, it may be more accurate to put it differently - if GMPLS
supports
> only a handful of the services running on a given transport network, than
> its value as a network's control plane component is diminished. 

To be even more accurate, GMPLS value is diminished *in the context*
of that particular transport network. And unless *all* providers
are going to run *all possible services* on their transport networks
(which is a somewhat unrealistic scenario), that means that the
value of GMPLS as a network's control plane component would be
diminished for *some*, but not *all* service providers.

[[Lazer, AT&T]]  I think that we may have somewhat diverging opinions. For
me a control plane of value for a given transport technology needs to
support control for all the services supported in the data plane. To be more
specific, if a transport technology supports transport for SONET, GbE, and
SAN, its associated control plane must support signaling and routing for
same. It does not need to encumber itself for support of services not
implemented in the hardware, but I see no good reason to support a service
in the data plane, but not in the control plane.

At the same time, it is important to keep in mind that being "all
things for all people" (aka as "perfect solution") is one of the
*non-goals* of GMPLS. So, it shouldn't come as a surprise if for a
*particular* provider GMPLS would *not* support *all* the services
that this provider runs on its transport network.

[[Lazer, AT&T]]  I am not looking at "all things for all people". I am
looking, as I mentioned in an earlier message at the control plane of a
given subnetwork supporting all the services of the data plane it controls.
If some services using a given network elements use the control plane, while
others need an outside OS, resource allocation and coordination becomes are
real issue.
Yakov.

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

Delivery-date: Tue, 23 Oct 2001 08:16:53 -0700
To: "Lazer, Monica A, NNAD" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 08:16:32 -0700
From: Yakov Rekhter <[email-masked]>

Monica,

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

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

Yakov.

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

Delivery-date: Tue, 23 Oct 2001 08:15:38 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Juergen Heiles' <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Tue, 23 Oct 2001 17:12:05 +0200

Juergen,

I am answering to your e-mails exactly because I am the editor of these
documents. Some people don't want to answer anymore. Answering or not =
to
e-mails is a personal decision of each one, nobody is forced to answer.

You had the feedback from the mailing list. In general when people are =
happy
with what they saw they don't spend time to add more comments.

Your proposals were supported by you and Maarten. I answered with =
Dimitri.
It is easy of course (for all of us) to ask all our colleagues and =
friends
to flood a mailing list.

Concerning your request to move the group signals to the other draft: =
this
was answered publicly by Kireeti during the last CCAMP meeting and the
answer was no. I asked again to Kireeti a couple of weeks ago, same =
answer.
This is also the advice that I received from Rob.

Concerning your label proposal: details are not yet cooked from our (I =
and
Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding =
Adjacency
there is no second STS-3 group, sorry if my example was confusing). =
Your
text needs to be corrected but that's a detail, it just shows that it =
is
quite difficult to write a text that works in all cases.

We spend a considerable amount of time reviewing the current label =
encoding
and we made sure that it works in the craziest cases. Indeed, this is =
the
most stable part of the SDH/SONET draft since a very long time. By =
adopting
your proposal we will have to do it again for no additional benefit and =
we
will need another WG last call (you know it perfectly). That's why I =
refused
during the WG last call some months ago, and why I am refusing again.

As an editor my job is also to keep the boat in the middle of the river =
and
to make sure that drafts are progressing and are not being constantly
re-worded. Also, I don't want to force all manufacturers to change =
their
implementations (prototypes:-) of the SONET label just because you =
found
another way of encoding it. One solution or the other is more a matter =
of
personal feeling.

At this stage, as a co-author you should be more concerned by finishing =
this
work. We can spend years having new ideas, improving and proposing
modifications to a draft.

It is a fact that we spend a huge amount of time (for me it represents
months of work since the beginning of year 2000) fine-tuning this =
draft. Now
it is time to publish it.

>From the technical point of view your proposals versus keeping the =
current
text will not change anything. It started as a political issue and I =
hope
that it didn't become a personal issue.

I am just asking you to help us to publish this work, even if it is not =
100%
as you would like to see it.

Kind regards,

Eric

> -----Urspr=FCngliche Nachricht-----
> Von: Mannie, Eric [mailto:[email-masked]]
> Gesendet: Dienstag, 23. Oktober 2001 12:23
> An: 'Juergen Heiles'; 'Kireeti Kompella'; [email-masked]
> Betreff: RE: Moving right along ...
>
>
> Hi Juergen,
>
> We already discussed all these points (at least 5 times) :-)
even more

>
> - about automatic detection:
>
> Indeed, you either configure a box with a signal structure, or if
> implemented you can ask to the box to discover itself the structure =
(what
> you call automatic detection).
>
For groups the box has to discover the structure itself.

> Automatic detection is a process applied internally to a box, and =
this is
> totally invisible to any other box in the network. This is an
> implementation
> issue, not a protocol issue since the protocol defines everyhting you =
need
> to do it.
>
> I understand your frustration that SDH standards don't describe all =
the
> processes for an implementation, but in general standards don't touch =
that
> part.
>
SDH and Sonet standards define detailed equipment functionality in =
order to
ensure interworking.
ITU has for example G.783 that defeins in detail what to do in SDH
equipment. Even G.707 gives some details
on pointer processing (genration, interpretation). For SONET we have =
GR-253
from Telcordia which provides this details.
No of them mentiones automatic detection.

> Automatic detection is a matter of reading the standard and =
understanding
> how the multiplexing works. By the way, you explained it yourself
> very well.
>
> The fact that a process is not described in some SDH standards has no
> meaning, it is simply not relevant. Every manufacturer is free to do =
its
> implementation as he likes if the protocol is fullfilled, and this is =
the
> case.
>
> - about the comparison of automatic detection and transparency:
>
> You are comparing apples with chocolates. Transparency may require to
> transport bytes in unused bytes, so in that case it changes the =
overhead.
> Automatic detection is an internal process.
>
> - You wrote: "During errors (defects, AIS condtions) of individual =
singals
> of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic."
>
> and I already answered many times: a super signal (group signal) is =
one
> single LSP. If something fails inside everything fails. In that case =
you
> don't need to demultiplex anymore, you just protect/restore the whole =
(if
> required). A group signal is a signaling plane object, i.e. one
> single LSP.
>
I mentioned the case that the problem is outside your LSP. You get for
example a signal from a user and setup a group LSP.
Now due to problems on the user side one of the VCs has AIS, may be the =
user
isn't even using this VC currently. You cannot protect it as the =
problem is
outside the LSP. If you now drop all other VCs of this group your user =
would
be very happy I assume.

> - Can you present me any ITU/ANSI standard that defines automatic
> detection
> of the group structure?
>
> No need, this is not in the scope of ITU/ANSI standards.

Are you defining what is in the scope of ITU/ANSI standards?
This is in the scope of ITU/ANSI/Telcordia standards. Look on G.707 =
pointer
interpretation, G.783 and GR-253 as mentioned above. When we talk about
standard SONET/SDH it includes the equipment functionality. For ETSI we =
even
have compliance statements that go down to these details.
I have no problems when soemone implements this feature, but we should =
no
give the impression that this is a standard SONET/SDH feature by =
putting it
into the standard features document. Move it to the non-standard =
document.

>
> - You wrote " You haven't provided a reason for different lables. We =
had
> several people that wanted to have the same label structure and only =
you
> opposed. So what is rough consensus?"
>
> The labels are local per interface, so they are "different" by =
definition
> since an SDH interface is not a Sonet interface.

A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N with AU-3 =
have
the identical structure.
But with the current proposal we have to use different lables. Is this
simple?

> However, we
> defined the two
> label formats based on the same principles, i.e. the first field is =
the
> index of the first AUG-1/STS-1 (easy). We chosen not to indicate any =
level
> of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because =
this
> is not needed and less flexible. A label is just a simple pointer in =
the
> multiplex, how to interpret the content of what is pointed to is
> not defined
> by the label.
>

I just took the SDH AU3 case and used it for SONET. So if you see a =
problem
it would already apply to the defined SDH lable.

> Using your proposal we would introduce a particular case, and in that =
case
> there is no reason why we should not introduce other particular
> case (AUG-4,
> etc). At the end we would have something totally unreadable.
>
> Your proposal has also some issues, e.g. with your definition of the =
S
> field:
>
> "1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N
>     indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
>     multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 =
group,
>     and S=3DN indicates the last AUG-1/STS-3 group of this multiplex.
>     S is not significant for STM-0/STS-1.
>
> What happens if a link is not a a multiple of 3xN STS-1 ? For =
instance, a
> virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an =
STS-4.
> There is no real second STS-3 group. Your proposal is not
> appropriate to the
> level of flexibility that we want to provide. Another observations: =
our
> undrestanding of the label is that it is defined before any =
interleaving,
> not after.
>

Oh, suddently we have STS-4, STS-4 virtual links poping up, =
interesting. But
couldn't we also have virtual SDH signals with only 5 AU-3?
I don't know as I don't have any information about this virtual link
concept. But if you introduce something like this there should be no
difference between SONET and SDH. Otherwise we introduce new =
differences
between SONET and SDH that we tried to avoid now for some years (see
Deborahs e-mail). We learned from the mistakes made during the =
development
of SONET and SDH. In todays global world we don't want these =
differences.
And that is the reason why we propose to use a common lable. Don't make =
the
same mistakes again. So if you see a problem it also applies to the =
defined
SDH label.

> I am opposed because your proposal doesn't bring any new =
functionality.
> There are probably 100 ways of coding such a label for SDH and Sonet. =
We
> discussed it during one year,
The proposal to use a common lable is already disucssed for several =
month
(over 1/2 year) as soon as we got involved in the GMPLS discussions.

> we agreed on the current one because it is
> simple, easy to understand, easy to code and very flexible (and more
> important we never broke it !!!). We validate it, it is stable
> since a very
> long time. Why should we accept your way of coding it, and not the =
way of
> somebody else at this final stage ?
>

To use a common label is the only alternative proposal we have, no =
others.
It makes a lot of sense and is supported by several people on the list. =
Up
to know only oppossed by you. Again what is rough consensus?

> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Juergen Heiles [mailto:[email-masked]]
> Sent: Monday, October 22, 2001 3:01 PM
> To: Mannie, Eric; 'Kireeti Kompella'; [email-masked]
> Subject: AW: Moving right along ...
>
>
> Hi Eric,
>
> sorry for the delayed answer, but I have problems with the remtoe
> LAN access
> here in Geneva.
> I am therefore sending the mail via my ITU e-mail account and hope it =
is
> accepted by the ccamp list server.
>
> You compare groups with the multiplier, this is wrong. The multiplier =
sets
> up n indivudal VC-n connections. The transport plane sees only the
> individual VCs and the VC type (VC-4/372712711) is explicitly
> defined. So no
> additional support at the transport plane is needed. It is a pure =
control
> plane feature.
> Groups are not a pure control plane feature. When you setup a group =
(AUG,
> TUG, VTG, STSG) the transport plane still has to handle the =
individual
> VCs/SPEs that are part of the group. Due the independent timing of =
each
> VC/STS-SPE pointer processing has to be done per individual VC/SPE. =
The
> transport plane cannot switch the group as a whole between STM/STS =
ports.
> The transport plane therefore has to automatically detect the =
structure of
> the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 =
or a
> mixture and that may change over the lifetime of the group. This =
automatic
> detection is not a standard SONET/SDH feature. As I described in =
previous
> e-mails it is possible to do it based on pointer values during non =
error
> situations. During errors (defects, AIS condtions) of individual
> singals of
> a group (e.g. one VC-12 in a TUG3 fails) it can get problematic.
> If a single
> VC-12 in a TUG3 group has AIS (note that the AIS could result
> from a failure
> outside the LSP), I assume that still all the other VCs of the group =
shall
> be connected without errors. No SONET/SDH standard covers the =
automatic
> detection.
> So in my view it is similarly to transparency of individual SOH
> bytes. G.707
> defines the individual SOH bytes, however transparency it is not =
standard
> SONET/SDH and is therefore in the non-standard document. In the same =
way
> G.707 defines groups, but not the automatic detection of the group
> structure. So it should be moved to the non-standards document. At =
the
> London meeting Kireeti said the decision on standard/non-standard =
features
> is not based on rough consensus, but on what is in the ITU/ANSI =
documents.
> Can you present me any ITU/ANSI standard that defines automatic
> detection of
> the group structure?
>
> You say groups are cool, may be for some applications. But note
> that groups
> have the same fragementation problem as contiguous concatenation.
> The VCs in
> a group always have to stay together. If for a example a TUG2 consits =
of 3
> VC-12 you cannot put them in arbitrary free time slots. They have =
stay in
> the time slots that belong to a single TUG2.
>
>
> Concering the lable, aligning the SONET labels with the SDH lables =
makes
> live easier. It is also a sign that SONET and SDH are identical for =
most
> parts. I also showed you that SONET uses the same two-stage =
interleaving
> process as SDH. If you look at the attached figure from T1.105
> you see that
> the STS-1 time slots in an STS-N signal are not continously
> number. First 3
> STS-1s are combiend to a STS3 groupg and then the STS3 groups are
> multiplexed. The same as SDH with AU3s and AUGs.
> As the SONET lables will become the same as the SDH labels we
> don't have to
> evaluate much. I already made a proposal some time ago. Why introduce
> different labels without a need?
> You haven't provided a reason for different lables. We had several =
people
> that wanted to have the same label structure and only you opposed. So =
what
> is rough consensus?
>
> See my proposal for the labels below.
>
>
> Juergen
>
>
> This is my proposal for the label:
>    The format of the label for SDH and/or SONET TDM-LSR link is:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               S               |   U   |   K   |   L   |   M   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    For SDH, this is an extension of the numbering scheme defined in
>    G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the =
same
>    signaling scheme is used in order to provide easy interworkign =
between
>    SDH and SONET signaling. For the S field a STS-3 group,which
>    corresponds with the SDH AUG-1 level is introduce. The U field
> indicates
>    the position of the STS-3c-SPE or STS-1-SPE within the STS-3
> group. The K
>    field is not significant for SONET as it doesn't support =
structured
>    STS-3c-SPEs and must be set to zero.
>
>    Each letter indicates a possible branch number starting at the
>    parent node in the multiplex structure. Branches are considered as
>    numbered in increasing order, starting from the top of the
>    multiplexing structure. The numbering starts at 1, zero is used to
>    indicate a non-significant field.
>
>    When a field is not significant in a particular context it MUST be
>    set to zero when transmitted, and MUST be ignored when received.
>
>    When hierarchical SDH/SONET LSPs are used, an LSP with a given
>    bandwidth can be used to tunnel lower order LSPs.  The higher
>    order SDH/SONET LSP behaves as a virtual link with a given
>    bandwidth (e.g. VC-3), it may also be used as a Forwarding
>    Adjacency. A lower order SDH/SONET LSP can be established through
>    that higher order LSP. Since a label is local to a (virtual) link,
>    the highest part of that label is non-significant and is set to
>    zero.
>
>    For instance, a VC-3 LSP can be advertised as a forwarding
>    adjacency. In that case the labels allocated between the two ends
>    of that LSP (i.e. for that "link") will have S, U and K set to
>    zero, i.e., non-significant, while L and M will be used to
>    indicate the signal allocated in that VC-3.
>
>      1. S is the index of a particular AUG-1/STS-3 group. S=3D1->N
>      indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
>      multiplex. For example, S=3D1 indicates the first AUG-1/STS-3 =
group,
>      and S=3DN indicates the last AUG-1/STS-3 group of this =
multiplex.
>      S is not significant for STM-0/STS-1.
>
>      2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3
>      group or STM-0/STS-1. U=3D1 indicates a single VC-4/STS-3c-SPE =
in a
>      AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1,
> while U=3D2->4
>      indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3
>      group.
>
>      3. K is only significant for SDH VC-4 and must be ignored for
>      SONET and SDH HOVC-3. It indicates a specific branch of a VC-4.
>      K=3D1 indicates that the VC-4 is not further subdivided and
>      contains a C-4. K=3D2->4 indicates a specific TUG-3 inside the =
VC-
>      4. K is not significant when the AUG-1 is divided into AU-3s
>      (easy to read and test).
>
>      4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
>      It is not significant for an unstructured VC-4 or VC-3/STS-1 =
SPE. L=3D1
>      indicates that the TUG-3/VC-3/STS-1 SPE is not further
>      subdivided and contains a VC-3/C-3 in SDH or the equivalent in
>      SONET. L=3D2->8 indicates a specific TUG-2/VT Group inside the
>      corresponding higher order signal.
>
>      5. M indicates a specific branch of a TUG-2/VT Group. It is not
>      significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.
>      M=3D1 indicates that the TUG-2/VT Group is not further =
subdivided
>      and contains a VC-2/VT-6 SPE. M=3D2->3 indicates a specific VT-3
>      inside the corresponding VT Group, these values MUST NOT be used
>      for SDH since there is no equivalent of VT-3 with SDH. M=3D4->6
>      indicates a specific VC-12/VT-2 SPE inside the corresponding
>      TUG-2/VT Group. M=3D7->10 indicates a specific VC-11/VT-1.5 SPE
>      inside the corresponding TUG-2/VT Group. Note that M=3D0 denotes
>      an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
>
>
>       The M encoding is summarized in the following table:
>
>           M    SDH                          SONET
>          ----------------------------------------------------------
>           0    unstructured VC-4/VC-3  unstructured STS-1 SPE
>           1    VC-2                    VT-6
>           2    -                       1st VT-3
>           3    -                       2nd VT-3
>           4    1st VC-12               1st VT-2
>           5    2nd VC-12               2nd VT-2
>           6    3rd VC-12               3rd VT-2
>           7    1st VC-11               1st VT-1.5
>           8    2nd VC-11               2nd VT-1.5
>           9    3rd VC-11               3rd VT-1.5
>           10   4th VC-11               4th VT-1.5
>
>    In case of contiguous concatenation, the label that is used is the
>    lowest label of the contiguously concatenated signal as explained
>    before. The higher part of the label indicates where the signal
>    starts and the lowest part is not significant. For instance, when
>    requesting an STS-48c the label is S>0, U=3D0, K=3D0, L=3D0, =
M=3D0.
>
>    Examples of labels:
>
>    Example 1: S>0, U=3D1, K=3D1, L=3D0, M=3D0
>    Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 =
group.
>
>    Example 2: S>0, U=3D1, K>1, L=3D1, M=3D0
>    Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.
>
>    Example 3: S>0, U>1, K=3D0, L=3D0, M=3D0
>    Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth
> AUG-1/STS-3 group.
>
>    Example 4: S>0, U>1, K=3D0, L>1, M=3D1
>    Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth =
VC-3/STS-1
> SPE of the Sth AUG-1/STS-3 group.
>
>    Example 5: S>0, U>1, K=3D0, L>1, M=3D9
>    Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth
> VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.
>
>    Example 6: S>0, U=3D1, K>1, L>1, M=3D5
>    Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the =
VC-4 of
> the Sth AUG-1.
>
>
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: Mannie, Eric [mailto:[email-masked]]
> > Gesendet: Donnerstag, 18. Oktober 2001 18:58
> > An: 'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> > Betreff: RE: Moving right along ...
> >
> >
> > Hello Juergen,
> >
> > Your comments are addressed hereafter. Note that you didn't raised =
any
> > technical problem or mistake in your comments (i.e. the draft
> "works" very
> > well as it is).
> >
> > - the first comment is not about a technical issue but an
> > "editorial" issue.
> > - the second comment is about a change that will not bring any new
> > capability.
> >
> > >Concerning the SDH/Sonet documents I want to raise a formal issue.
> > >We have now two documents, a document that covers ITU/ANSI =
standard
> > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document =
that
> > covers non-standard features
> > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in
> > Appendix 1
> > of the standard feature document a non standard feature (Group
> signals) is
> > listed. It is even mentioned that the use of groups (AUG, STSG,
> > ...) is not
> > described in standards. So this feature should be moved to the
> > non-standards
> > document. Otherwise the split of the documents doesn't make sense.
> >
> > We spend a considerable amount of time speaking about this
> > particular issue
> > and I still don't see any technical justification for what you =
said.
> >
> > For those who are not SDH/SONET experts some quick explanation:
> >
> > We call a "super-circuit" a set of physical circuits in the
> > transport plane
> > all belonging to the same LSP in the signaling plane. We
> defined two kinds
> > of super-circuits: "group circuits" and "multiplicative circuits".
> >
> > Multiplicative circuits are setup using the multiplier field that
> > we defined
> > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no
> > objection
> > about these ones.
> >
> > Group circuits are setup using the SDH/SONET naming for groups,
> i.e. AUG,
> > TUG, VTG (we defined the equivalent signal type in the signaling). =
The
> > comment of Juergen is about these group circuits. A group circuit
> > represents
> > some bandwidth at a given place in the SDH/SONET multiplex. The
> > advantage of
> > such a super-circuit is that the customer can re-structure its
> content as
> > he/she likes. The operator doesn't care.
> >
> > Such an application is possible and is already implemented. =
SDH/SONET is
> > self-describing, i.e. by looking at the signal one can understand
> > how it is
> > structured (like Juergen explained on the mailing list), so one
> > can setup a
> > circuit without describing the content (very very cool).
> >
> > The transport plane ignores that the signaling plane uses an
> "abstraction"
> > (i.e. an LSP) representing several physical circuits. Note that
> > restoration
> > and management belong respectively to the signaling plane and to =
the
> > management plane in the IETF view (not to the transport plane
> like in the
> > ITU-T view).
> >
> > From that point of view, group circuits are a GMPLS signaling
> > plane feature
> > and not a transport plane feature. We put the comment on the fact
> > that this
> > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys =
happy.
> >
> > I could say clearly at the beginning of the draft that the signal
> > types that
> > we are defining in this document are not ITU-T signal types but
> > GMPLS signal
> > types (of course) whose have in some cases a direct
> relationship with the
> > ITU-T signal types.
> >
> > Any objection ?
> >
> > >For the Sonet and SDH labels in
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
> > prefer to have the same coding for Sonet and SDH. That makes the
> > implementation for Sonet and SDH simpler. Furthermore ITU and T1
> > have tried
> > over the last years to align Sonet and SDH as much as possible. The
> > definition of different labels for Sonet and SDH contradicts these
> > activities.
> >
> > We discussed this one since a long time as well. Let me be clear:
> >
> > - labels are local to an interface (we all agree).
> > - a link (interface) is operated at one point in the time as
> either SDH or
> > SONET.
> > - your proposal will require to re-evaluate many things.
> > - and it took us a lot of time to fine-tune and to validate the =
current
> > label structure.
> > - we could have technical issues with your proposal that would
> impact more
> > than this draft (Dimitri saw some of them, please see with him).
> > - you never provided a complete analysis of your proposal.
> >
> > But more important: your proposal doesn't bring any additional
> > functionality
> > to the draft.
> >
> > At this very late stage, since this not bringing any new
> > functionality, and
> > since the label structure is very stable since a long time, I
> would prefer
> > not to restart a long technical discussion to change and =
re-validate the
> > draft.
> >
> > Kind regards,
> >
> > Eric
> >
> >
> >
> > > -----Urspr=FCngliche Nachricht-----
> > > Von: Kireeti Kompella [mailto:[email-masked]]
> > > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > > An: [email-masked]
> > > Betreff: Moving right along ...
> > >
> > >
> > > Despite the energetic subject line, we the WG chairs have been
> > > lax in our duties.  So, here goes:
> > >
> > > Lou has submitted the latest versions of the generalized
> > > signaling documents quite some time ago (thanks, Lou):
> > >
> > > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > draft-ietf-mpls-generalized-signaling-06.txt
> > >
> > > Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > >
> > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >
> > > All of these should have addressed the issues raised in the =
earlier
> > > versions.  Please read the new versions, and send your comments =
to
> > > the list by Tuesday Oct 23.  At that point, when the final round
> > > of comments have been addressed, these docs will go to IESG Last
> > > Call.  If any one objects to sending these docs to IESG Last =
Call,
> > > raise your issues now.
> > >
> > > I see that the GMPLS architecture document is a CCAMP WG doc, but
> > > the minutes say that we should look for consensus on the list.  =
So,
> > > if you think this doc *shouldn't* be a WG doc, let us know.  (If =
we
> > > arrived at a consensus, remind me :-))  If nothing is heard, the =
doc
> > > will progress to WG Last Call.
> > >
> > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt =
and
> > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to =
be
> > > CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > > list know what your thinking is on these.  (BTW, both these docs
> > > were to have some edits done.  If the authors could do that =
before
> > > the next IETF, we can try to make more progress then.)
> > >
> > > The MIB overview doc was recently posted.  Please read and =
comment
> > > to the list.
> > >
> > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > was generally thought to be useful; it will be published as a
> > > CCAMP informational doc.  This begins a two week Last Call on
> > > the doc, ending Tuesday Oct 30.
> > >
> > > There was no consensus on whether the GMPLS framework should be
> > > a CCAMP WG doc.  Please indicate your pleasure.
> > >
> > > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > > raised that this draft is close to ready for WG Last Call.  =
Please
> > > review it, and let us know if you disagree.
> > >
> > > The OLI requirements doc was broadly accepted.  Please let the
> > > list know if you think this doc should be a WG doc.
> > >
> > > It's still open whether we (the IETF) should be working on
> > > LMP-WDM.  I urge the authors to keep on working on the doc, and
> > > keeping it in sync with LMP; however, we will postpone making it
> > > a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > > happen in Salt Lake City.
> > >
> > > There was reasonable interest in the tunnel trace requirements
> > > doc.  Let's formalize this: do you think this should be made a
> > > CCAMP WG document?
> > >
> > > Summary:
> > >
> > > 1) Final comments and IESG Last Call readiness for:
> > > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > draft-ietf-mpls-generalized-signaling-06.txt
> > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >
> > > 2) Should the following documents be CCAMP WG docs?
> > > draft-bonica-tunneltrace-02.txt
> > > draft-fontana-ccamp-gmpls-g709-00.txt
> > > draft-ietf-ccamp-gmpls-architecture-00.txt
> > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > > draft-many-ccamp-gmpls-framework-00.txt
> > > draft-many-oli-reqts-00.txt
> > >
> > > 3) Comment on MIB overview.
> > >
> > > 4) Two week Last Call comments on
> > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >
> > > 5) Last Call readiness of
> > > draft-ietf-ccamp-gmpls-architecture-00.txt
> > > draft-ietf-ccamp-lmp-01.txt
> > >
> > > Thanks,
> > > Kireeti.
> > >
> >

Delivery-date: Tue, 23 Oct 2001 06:58:50 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 09:55:19 -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_01C15BCA.5A2A5650
Content-Type: text/plain;
	charset="iso-8859-1"

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

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Tuesday, October 23, 2001 6:25 AM
To:	[email-masked]
Cc:	Lazer, Monica A, NNAD; [email-masked]
Subject:	RE: Generalized Signaling - LSP Encoding Type expansion 

Yakov,

See comments in-line

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

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

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

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

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Generalized Signaling - LSP Encoding Type expansion </TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Monica A. Lazer</FONT>
<BR><FONT SIZE=3D2>Advanced Transport Technology and Architecture =
Planning</FONT>
</P>

<P><FONT SIZE=3D2>908 234 8462</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Tuesday, October 23, 2001 6:25 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Lazer, Monica A, NNAD; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: Generalized Signaling - LSP Encoding Type expansion </FONT>
</P>

<P><FONT SIZE=3D2>Yakov,</FONT>
</P>

<P><FONT SIZE=3D2>See comments in-line</FONT>
</P>

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

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

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

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>On a more =
general point, is the support of transport technologies</FONT>
<BR><FONT SIZE=3D2>within GMPLS signalling restricted to those that the =
authors of the GMPLS</FONT>
<BR><FONT SIZE=3D2>drafts will allow? </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2> =
</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15BCA.5A2A5650--

Delivery-date: Tue, 23 Oct 2001 06:13:39 -0700
Date: Tue, 23 Oct 2001 09:13:26 -0400
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
Subject: Re: the LMP mib
Cc: ccamp-wg <[email-masked]>

--=====================_86702211==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

         Hi Bert,

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

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

         --Tom

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

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_86702211==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi
Bert,<br>
<br>
<blockquote type=cite cite>Just a very quick reaction (better to alert
you at rev 00 than<br>
later).</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Thanks for
the review. We will clean things up in<br>
the next revision.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<blockquote type=cite cite><font size=3>- You have picked up an old
template for section 4.<br>
&nbsp; It references obsolted RFCs. Pls use latest one<br>
- Section 4.1 is redundant and can be removed.<br>
- Remove &quot;using SMIv2&quot; from the title.<br>
&nbsp; We have been using SMIv2 for 5 years or so. This<br>
&nbsp; &quot;Using SMIv2&quot; was customary when we had SMIv1<br>
&nbsp; as the standard tool. These days SMIv2 is mandatory<br>
- Why is the abstract and the 1st para of the intro (just<br>
&nbsp; underneath each other) exactly the same?<br>
- sect 9. DO not talk about interfaces group of MIB II.<br>
&nbsp; Instead just stick to IFMIB (RFC2863)<br>
- You are importing/using IpAddress.<br>
&nbsp; CANNOT do that. Pls use TCs from RFC2851, or better<br>
&nbsp; from the update that is being done right now.<br>
- REVISION clause(s). In the end, when this MIB is first<br>
&nbsp; published as RFC, we only want one simple revision<br>
&nbsp; clause, aka:<br>
&nbsp;&nbsp;&nbsp; REVISION &quot;yyyymmddhhmmZ&quot;<br>
&nbsp;&nbsp;&nbsp; DESCRIPTION &quot;Initial version, published as RFC
xxxx&quot;<br>
&nbsp;&nbsp;&nbsp; -- xxxx to be assigned by RFC Editor.<br>
&nbsp; All the changes made during InternetDraft stages are<br>
&nbsp; nice for the WG, but not really interesting once we publish.<br>
&nbsp; You can put them in an appendix till doc goes to RFC-Editor<br>
- lmpNbrNodeId OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
NodeID<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; accessible-for-notify<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp; This is an INDEX object... should be not-accessible!<br>
- STorageType object needs to describe which objects<br>
&nbsp; (if any) must be writable when the StorageType is permanent<br>
- RowStatus object needs to describe which objects (if any)<br>
&nbsp; can be modified when the status is active.<br>
- I do not see a reference to any discontinuity object in you<br>
&nbsp; counter32/counter64 objects. Is there no potential for<br>
&nbsp; discontinuity, otehr than at restart of the SNMP agent?<br>
&nbsp; I guess there is, because you do have such an object<br>
- In general, I would just talk about &quot;notifications&quot; and
not<br>
&nbsp; about traps. A notification can be send as a trap or as<br>
&nbsp; an inform, but that is under control of the MIB(s) in<br>
&nbsp; RFC2573.<br>
- I would like to see 2 conformance statements:<br>
&nbsp;<br>
&nbsp; lmpMIBFullConformance which allow READ/Create, so that it<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
can be used for configuration and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
monitoring.<br>
&nbsp; lmpMIBReadOnlyCompliance which is more or less the one you<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
have now and which allows for just<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
minitoring.<br>
<br>
&nbsp;&nbsp; <br>
- In the security section, can you add some words about which
objects<br>
&nbsp; contain sensitive information and why? That would be usefull
for<br>
&nbsp; users so they can determine how serious they have to
excercise<br>
&nbsp; access control.<br>
<br>
Just a quick sniff.<br>
Bert<br>
Bert </font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_86702211==_.ALT--

Delivery-date: Tue, 23 Oct 2001 06:02:07 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: the LMP mib
Date: Tue, 23 Oct 2001 14:59:52 +0200

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

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

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

Just a quick sniff.
Bert
Bert 

Delivery-date: Tue, 23 Oct 2001 04:53:56 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Dimitri Papadimitriou' <[email-masked]>,  manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Tue, 23 Oct 2001 13:49:24 +0200

Hi Manoj,

Manoj:
>> 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table
>> as an addendum to the draft.

Dimitri:
>This would apply to the SDH/Sonet document ... however i see it more
>adapted to the "SDH/Sonet framework" one. Personally i think that in 
>such I-D it can be useful (please contact Eric for that purpose) and
>so i think we are in agreement here.

I agree with Dimitri. Note also that EDCBA is a notation convention used in
G.707 to help the reader, this is not transported by any overhead. So this
conversion table doesn't belong to the protocol work but more the
explanatory work.

Manoj:
>> 4. As per OIF, the carrier requirement is that SDH LSPs should be
>> either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
>> supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS
>> has different set of carrier requirements in this regard ?
>

Dimitri:
>The I-D is covering HO/STS SPE and LOVC/VT for completeness (as described
in G.707 ANSI T1.105), OIF UNI 1.0 uses a subset. Why not.

Right, GMPLS is a tool box. From that perspective, the OIF chosen to use
some tools and not others. It was very very easy to cover the LOVC/VT case.
It doesn't mean that it must be implemented. Don't forget that a core switch
is nothing without metro and edge switches and that carriers need end-to-end
signaling (between customer access points) if they really want to take
benefit of the control plane (for restoration, etc). What is the use of a
control plane for SDH/SONET that stops at the edge of the core, without
going to the metro ? It is quite limited.

Manoj:
> 2. Usage of Label Set :
>         There are cases mentioned in the draft which explains the usage
> of label set. It should also mention that the range of labels in
> SDH/SONET does not make sense.

I don't think so. Sometimes you have tools that you don't need now but that
could be useful for future usage. The label set is a very rich tool that
could be used for SONET/SDH as well. There is no need today to restrict its
usage to all optical applications only.

Indeed, there are two different design approaches that can be compared:
either you design an open protocol, or a closed protocol. We chosen to
design an open protocol and this is consistent with the toolbox approach. We
didn't want to completely limit everything from time zero. This gives room
for growth and future developments.

Another approach is the closed one, this was many times defended by some
ITU-T folks. E.g. to say for each field "this field is not applicable to and
to .... and to ... and to...", or "this range is limited to....". In that
case you block everything. It is better to say "this field can be used
for.... and the current values are....", then somebody else could use that
"tool" for an additional purpose in the future. Don't close the door too
quickly at this stage, certainly when you don't need to close the door. If
you completely close the door, then GMPLS will be very difficult to extend
and will stop to be a toolbox.

GMPLS is not an architecture that can be applied as such, it needs a profile
for each particular application. If someone read it, thinking: "I will know
exactly what my GMPLS control plane for SDH/SONET needs to implement",
he/she is completely missing the point and will be very confused.

Kind regards,

Eric

-----Original Message-----
From: Dimitri Papadimitriou [mailto:[email-masked]]
Sent: Sunday, October 21, 2001 1:57 PM
To: manoj juneja
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Moving right along ...

Hi Manoj,

My previous e-mail was a generic one, not only focused on your 
question concerning the conversion table. I personally think 
the following on this issue:

> 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table
> as an addendum to the draft.

This would apply to the SDH/Sonet document ... however i see it more
adapted to the "SDH/Sonet framework" one. Personally i think that in 
such I-D it can be useful (please contact Eric for that purpose) and
so i think we are in agreement here.

Here the response to your other questions:

> 1. Can someone please tell me the usage of bandwidth encoding
> parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> will be drived from the signal type field. How the bandwidth encoding
> type will be interpreted in case of other LSP encoding types (lambda,
> waveband, fiber etc) ? The draft should list down the cases in which 
> the bandwidth encoding type is to be filled.

To which I-D do you refer here, in GMPLS-SIG this is well explained.
For the SDH/Sonet one, we had this discussion sometime ago and the 
outcome was to "un-use" this value (even if i don't think it is the
best solution but since discussion brought us to more complexity...) 
Remember that the resulting bandwidth is dependent on the application
of the different field on the elementary Signal Type resulting in a 
final signal.

Anyway, if it has to be detailed it would be in the SDH/Sonet and
other technology dependent ones.
 
> 2. Usage of Label Set :
>         There are cases mentioned in the draft which explains the usage
> of label set. It should also mention that the range of labels in
> SDH/SONET does not make sense. Ranges in label set are applicable in
> case of waveband/lambda switching etc. The range in label set is valid
> in SDH/SONET only if there is one element in the range i.e. start range
> and end range should be same.

Is it a question or an assertion ? I refer you also here to my previous 
e-mail
 
> 3. There are couple of scenarios where there can be contention for
> establishing bi-directional LSPs. All the scenarios are not listed in
> the document. If it is not possible to list all the scenarios then the
> draft should say that this is one of the example scenario. The
> contention can also be possible in case where same label set and
> upstream label are used in both the directions.

This has been extensively discussed on this mailing list i am referring
you to the outcome of this discussion
 
> 4. As per OIF, the carrier requirement is that SDH LSPs should be
> either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS
> has different set of carrier requirements in this regard ?

The I-D is covering HO/STS SPE and LOVC/VT for completeness (as
described 
in G.707 ANSI T1.105), OIF UNI 1.0 uses a subset. Why not.
 
> 6. The relation between switching capability and LSP encoding type
> should be clearly explained in the drafts. As the switching capability
> field was added very late (just 2 months back) in the drafts,
> specific reason should be mentioned for its addition.

... ? re-phrasing one of the remarks i saw this week can be applied here
we are not discussing "requirement" document here

Hope this will help you,

Regards,
Dimitri.

manoj juneja wrote:
> 
> Hi Dimitri,
>             I don't think there is any issue in including the
> conversion table in the draft. Even this table can be kept in some
> informational draft. The inclusion of conversion table is a valid thing
and
> probably nobody on ccamp mailing list would like oppose. I
> still didn't get answers to other points in my mail.
> 
> Regards,
> manoj.
> 
> >From: Dimitri Papadimitriou <[email-masked]>
> >To: Zhi-Wei Lin <[email-masked]>
> >CC: manoj juneja <[email-masked]>, [email-masked],
> >[email-masked]
> >Subject: Re: Moving right along ...
> >Date: Sat, 20 Oct 2001 16:05:01 +0200
> >
> >Hi Zhi,
> >
> >I would like to remember you something here: the SDH/Sonet I-D is not
> >1) a textbook on how to use GMPLS-SIG but must be understood an
> >    additional document complementing the signalling one
> >2) a tutorial on Sonet/SDH (a framework has been proposed for that
> >    purpose)
> >
> >We have spent hard time together with the SDH/Sonet I-D co-authors in
> >order to find the best balance between reproducing well known SDH/Sonet
> >concepts and paragraphs really providing an added value in this document
> >
> >Of course we can not make 100% people happy (even between the list of
> >30 co-authors) some of us found there was too much explanations while
> >others were requesting more content.
> >
> >Therefore for the non-covered content we are referencing the appropriate
> >document either it comes from ITU or IETF. Please understand that we
> >can not wait until everybody in this world has no question anymore or a
> >full understanding on any technical detail in order to go forward with
> >these documents.
> >
> >Thanks for your "virtual" understanding,
> >Dimitri.
> >
> >Zhi-Wei Lin wrote:
> > >
> > > Hi Manoj,
> > >
> > > I agree with many of your points. I actually submitted an I-D several
> > > months ago (I think it's expired) that proposes some text to add to
the
> > > GMPLS SONET/SDH on the rules for setting different values, such as for
> > > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the
> > > range of acceptable value of X, etc.
> > >
> > > My rationale at that time was that not everyone is a SONET/SDH expert
> > > and instead of asking them to look somewhere else and dig through
those
> > > documents to find the answer, if we can provide them in the GMPLS set
of
> > > drafts it would be extremely useful for the entire IETF community and
> > > would help clarify the usage of these parameters. But unfortunately if
> > > you were at the meeting at the time, it wasn't accepted because some
> > > folks thought that these were obvious or that this info is not needed
> > > because they can find it in other places referenced...
> > >
> > > If you have the old drafts, the file was:
> > > draft-lin-ccamp-ipo-common-label-request-01
> > >
> > > But anyway...people will just have to read all the referenced
documents
> > > to understand how to use the different parameters...
> > >
> > > Zhi
> > >
> > > manoj juneja wrote:
> > >
> > > > Hi Kireeti,
> > > >            I am not an active member of IETF but a regular reader of
> > > > GMPLS drafts. I am not sure how much weight my mail will carry but
as
> >a
> > > > regular reader of these drafts, I recommend the following points
> >should
> > > > be made clear in the documents before proceeding to the last call.
> > > >
> > > >
> > > > 1. Can someone please tell me the usage of bandwidth encoding
> > > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> > > > will be drived from the signal type field. How the bandwidth
encoding
> > > > type will be interpreted in case of other LSP encoding types
(lambda,
> > > > waveband, fiber etc) ? The draft should list down the cases in which
> >the
> > > > bandwidth encoding type is to be filled.
> > > >
> > > > 2. Usage of Label Set :
> > > >        There are cases mentioned in the draft which explains the
usage
> > > > of label set. It should also mention that the range of labels in
> > > > SDH/SONET does not make sense. Ranges in label set are applicable in
> > > > case of waveband/lambda switching etc. The range in label set is
valid
> > > > in SDH/SONET only if there is one element in the range i.e. start
> >range
> > > > and end range should be same.
> > > >
> > > > 3. There are couple of scenarios where there can be contention for
> > > > establishing bi-directional LSPs. All the scenarios are not listed
in
> > > > the document. If it is not possible to list all the scenarios then
the
> > > > draft should say that this is one of the example scenario. The
> > > > contention can also be possible in case where same label set and
> > > > upstream label are used in both the directions.
> > > >
> > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be
> > > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> > > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean
> >GMPLS
> > > > has different set of carrier requirements in this regard ?
> > > >
> > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table
as
> > > > an addendum to the draft.
> > > >
> > > > 6. The relation between switching capability and LSP encoding type
> > > > should be clearly explained in the drafts. As the switching
capability
> > > > field was added very late (just 2 months back) in the drafts,
> > > > specific reason should be mentioned for its addition.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > >
> > > >
> > > >> From: Kireeti Kompella <[email-masked]>
> > > >> To: [email-masked]
> > > >> Subject: Moving right along ...
> > > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
> > > >>
> > > >> Despite the energetic subject line, we the WG chairs have been
> > > >> lax in our duties.  So, here goes:
> > > >>
> > > >> Lou has submitted the latest versions of the generalized
> > > >> signaling documents quite some time ago (thanks, Lou):
> > > >>
> > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > >> draft-ietf-mpls-generalized-signaling-06.txt
> > > >>
> > > >> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > > >>
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > > >>
> > > >> All of these should have addressed the issues raised in the earlier
> > > >> versions.  Please read the new versions, and send your comments to
> > > >> the list by Tuesday Oct 23.  At that point, when the final round
> > > >> of comments have been addressed, these docs will go to IESG Last
> > > >> Call.  If any one objects to sending these docs to IESG Last Call,
> > > >> raise your issues now.
> > > >>
> > > >> I see that the GMPLS architecture document is a CCAMP WG doc, but
> > > >> the minutes say that we should look for consensus on the list.  So,
> > > >> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > > >> arrived at a consensus, remind me :-))  If nothing is heard, the
doc
> > > >> will progress to WG Last Call.
> > > >>
> > > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
and
> > > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to
be
> > > >> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > > >> list know what your thinking is on these.  (BTW, both these docs
> > > >> were to have some edits done.  If the authors could do that before
> > > >> the next IETF, we can try to make more progress then.)
> > > >>
> > > >> The MIB overview doc was recently posted.  Please read and comment
> > > >> to the list.
> > > >>
> > > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > >> was generally thought to be useful; it will be published as a
> > > >> CCAMP informational doc.  This begins a two week Last Call on
> > > >> the doc, ending Tuesday Oct 30.
> > > >>
> > > >> There was no consensus on whether the GMPLS framework should be
> > > >> a CCAMP WG doc.  Please indicate your pleasure.
> > > >>
> > > >> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > > >> raised that this draft is close to ready for WG Last Call.  Please
> > > >> review it, and let us know if you disagree.
> > > >>
> > > >> The OLI requirements doc was broadly accepted.  Please let the
> > > >> list know if you think this doc should be a WG doc.
> > > >>
> > > >> It's still open whether we (the IETF) should be working on
> > > >> LMP-WDM.  I urge the authors to keep on working on the doc, and
> > > >> keeping it in sync with LMP; however, we will postpone making it
> > > >> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > > >> happen in Salt Lake City.
> > > >>
> > > >> There was reasonable interest in the tunnel trace requirements
> > > >> doc.  Let's formalize this: do you think this should be made a
> > > >> CCAMP WG document?
> > > >>
> > > >> Summary:
> > > >>
> > > >> 1) Final comments and IESG Last Call readiness for:
> > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > >> draft-ietf-mpls-generalized-signaling-06.txt
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > > >>
> > > >> 2) Should the following documents be CCAMP WG docs?
> > > >> draft-bonica-tunneltrace-02.txt
> > > >> draft-fontana-ccamp-gmpls-g709-00.txt
> > > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > > >> draft-many-ccamp-gmpls-framework-00.txt
> > > >> draft-many-oli-reqts-00.txt
> > > >>
> > > >> 3) Comment on MIB overview.
> > > >>
> > > >> 4) Two week Last Call comments on
> > > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > >>
> > > >> 5) Last Call readiness of
> > > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > > >> draft-ietf-ccamp-lmp-01.txt
> > > >>
> > > >> Thanks,
> > > >> Kireeti.
> > > >>
> > > >
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> > > >
> > > >
> ><< dimitri.papadimitriou.vcf >>
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Tue, 23 Oct 2001 04:03:09 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-00.txt
Date: Tue, 23 Oct 2001 07:02:10 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Link Management Protocol Management Information Base 
                          Using SMIv2
	Author(s)	: M. Dubuc et al.
	Filename	: draft-ietf-ccamp-lmp-mib-00.txt
	Pages		: 18
	Date		: 22-Oct-01
	
This memo defines an experimental portion of the Management Informa-
tion Base (MIB) for use with network management protocols in the
Internet community. In particular, it describes managed objects for
modeling the Link Management Protocol (LMP) [LMP].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lmp-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Oct 2001 03:26:56 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion 
Date: Tue, 23 Oct 2001 11:25:13 +0100

Yakov,

See comments in-line

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

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

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

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

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

Delivery-date: Tue, 23 Oct 2001 03:24:54 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Juergen Heiles' <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Tue, 23 Oct 2001 12:23:24 +0200

Hi Juergen,

We already discussed all these points (at least 5 times) :-)

- about automatic detection: 

Indeed, you either configure a box with a signal structure, or if
implemented you can ask to the box to discover itself the structure (what
you call automatic detection).

Automatic detection is a process applied internally to a box, and this is
totally invisible to any other box in the network. This is an implementation
issue, not a protocol issue since the protocol defines everyhting you need
to do it.

I understand your frustration that SDH standards don't describe all the
processes for an implementation, but in general standards don't touch that
part.

Automatic detection is a matter of reading the standard and understanding
how the multiplexing works. By the way, you explained it yourself very well.

The fact that a process is not described in some SDH standards has no
meaning, it is simply not relevant. Every manufacturer is free to do its
implementation as he likes if the protocol is fullfilled, and this is the
case.

- about the comparison of automatic detection and transparency:

You are comparing apples with chocolates. Transparency may require to
transport bytes in unused bytes, so in that case it changes the overhead.
Automatic detection is an internal process.

- You wrote: "During errors (defects, AIS condtions) of individual singals
of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic."

and I already answered many times: a super signal (group signal) is one
single LSP. If something fails inside everything fails. In that case you
don't need to demultiplex anymore, you just protect/restore the whole (if
required). A group signal is a signaling plane object, i.e. one single LSP.

- Can you present me any ITU/ANSI standard that defines automatic detection
of the group structure?

No need, this is not in the scope of ITU/ANSI standards.

- You wrote " You haven't provided a reason for different lables. We had
several people that wanted to have the same label structure and only you
opposed. So what is rough consensus?"

The labels are local per interface, so they are "different" by definition
since an SDH interface is not a Sonet interface. However, we defined the two
label formats based on the same principles, i.e. the first field is the
index of the first AUG-1/STS-1 (easy). We chosen not to indicate any level
of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because this
is not needed and less flexible. A label is just a simple pointer in the
multiplex, how to interpret the content of what is pointed to is not defined
by the label.

Using your proposal we would introduce a particular case, and in that case
there is no reason why we should not introduce other particular case (AUG-4,
etc). At the end we would have something totally unreadable.

Your proposal has also some issues, e.g. with your definition of the S
field:

"1. S is the index of a particular AUG-1/STS-3 group. S=1->N
    indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
    multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
    and S=N indicates the last AUG-1/STS-3 group of this multiplex.
    S is not significant for STM-0/STS-1.

What happens if a link is not a a multiple of 3xN STS-1 ? For instance, a
virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an STS-4.
There is no real second STS-3 group. Your proposal is not appropriate to the
level of flexibility that we want to provide. Another observations: our
undrestanding of the label is that it is defined before any interleaving,
not after.

I am opposed because your proposal doesn't bring any new functionality.
There are probably 100 ways of coding such a label for SDH and Sonet. We
discussed it during one year, we agreed on the current one because it is
simple, easy to understand, easy to code and very flexible (and more
important we never broke it !!!). We validate it, it is stable since a very
long time. Why should we accept your way of coding it, and not the way of
somebody else at this final stage ?

Kind regards,

Eric

-----Original Message-----
From: Juergen Heiles [mailto:[email-masked]]
Sent: Monday, October 22, 2001 3:01 PM
To: Mannie, Eric; 'Kireeti Kompella'; [email-masked]
Subject: AW: Moving right along ...

Hi Eric,

sorry for the delayed answer, but I have problems with the remtoe LAN access
here in Geneva.
I am therefore sending the mail via my ITU e-mail account and hope it is
accepted by the ccamp list server.

You compare groups with the multiplier, this is wrong. The multiplier sets
up n indivudal VC-n connections. The transport plane sees only the
individual VCs and the VC type (VC-4/372712711) is explicitly defined. So no
additional support at the transport plane is needed. It is a pure control
plane feature.
Groups are not a pure control plane feature. When you setup a group (AUG,
TUG, VTG, STSG) the transport plane still has to handle the individual
VCs/SPEs that are part of the group. Due the independent timing of each
VC/STS-SPE pointer processing has to be done per individual VC/SPE. The
transport plane cannot switch the group as a whole between STM/STS ports.
The transport plane therefore has to automatically detect the structure of
the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a
mixture and that may change over the lifetime of the group. This automatic
detection is not a standard SONET/SDH feature. As I described in previous
e-mails it is possible to do it based on pointer values during non error
situations. During errors (defects, AIS condtions) of individual singals of
a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. If a single
VC-12 in a TUG3 group has AIS (note that the AIS could result from a failure
outside the LSP), I assume that still all the other VCs of the group shall
be connected without errors. No SONET/SDH standard covers the automatic
detection.
So in my view it is similarly to transparency of individual SOH bytes. G.707
defines the individual SOH bytes, however transparency it is not standard
SONET/SDH and is therefore in the non-standard document. In the same way
G.707 defines groups, but not the automatic detection of the group
structure. So it should be moved to the non-standards document. At the
London meeting Kireeti said the decision on standard/non-standard features
is not based on rough consensus, but on what is in the ITU/ANSI documents.
Can you present me any ITU/ANSI standard that defines automatic detection of
the group structure?

You say groups are cool, may be for some applications. But note that groups
have the same fragementation problem as contiguous concatenation. The VCs in
a group always have to stay together. If for a example a TUG2 consits of 3
VC-12 you cannot put them in arbitrary free time slots. They have stay in
the time slots that belong to a single TUG2.

Concering the lable, aligning the SONET labels with the SDH lables makes
live easier. It is also a sign that SONET and SDH are identical for most
parts. I also showed you that SONET uses the same two-stage interleaving
process as SDH. If you look at the attached figure from T1.105 you see that
the STS-1 time slots in an STS-N signal are not continously number. First 3
STS-1s are combiend to a STS3 groupg and then the STS3 groups are
multiplexed. The same as SDH with AU3s and AUGs.
As the SONET lables will become the same as the SDH labels we don't have to
evaluate much. I already made a proposal some time ago. Why introduce
different labels without a need?
You haven't provided a reason for different lables. We had several people
that wanted to have the same label structure and only you opposed. So what
is rough consensus?

See my proposal for the labels below.

Juergen

This is my proposal for the label:
   The format of the label for SDH and/or SONET TDM-LSR link is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               S               |   U   |   K   |   L   |   M   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For SDH, this is an extension of the numbering scheme defined in
   G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same
   signaling scheme is used in order to provide easy interworkign between
   SDH and SONET signaling. For the S field a STS-3 group,which
   corresponds with the SDH AUG-1 level is introduce. The U field indicates
   the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. The K
   field is not significant for SONET as it doesn't support structured
   STS-3c-SPEs and must be set to zero.

   Each letter indicates a possible branch number starting at the
   parent node in the multiplex structure. Branches are considered as
   numbered in increasing order, starting from the top of the
   multiplexing structure. The numbering starts at 1, zero is used to
   indicate a non-significant field.

   When a field is not significant in a particular context it MUST be
   set to zero when transmitted, and MUST be ignored when received.

   When hierarchical SDH/SONET LSPs are used, an LSP with a given
   bandwidth can be used to tunnel lower order LSPs.  The higher
   order SDH/SONET LSP behaves as a virtual link with a given
   bandwidth (e.g. VC-3), it may also be used as a Forwarding
   Adjacency. A lower order SDH/SONET LSP can be established through
   that higher order LSP. Since a label is local to a (virtual) link,
   the highest part of that label is non-significant and is set to
   zero.

   For instance, a VC-3 LSP can be advertised as a forwarding
   adjacency. In that case the labels allocated between the two ends
   of that LSP (i.e. for that "link") will have S, U and K set to
   zero, i.e., non-significant, while L and M will be used to
   indicate the signal allocated in that VC-3.

     1. S is the index of a particular AUG-1/STS-3 group. S=1->N
     indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
     multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
     and S=N indicates the last AUG-1/STS-3 group of this multiplex.
     S is not significant for STM-0/STS-1.

     2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3
     group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a
     AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4
     indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3
     group.

     3. K is only significant for SDH VC-4 and must be ignored for
     SONET and SDH HOVC-3. It indicates a specific branch of a VC-4.
     K=1 indicates that the VC-4 is not further subdivided and
     contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-
     4. K is not significant when the AUG-1 is divided into AU-3s
     (easy to read and test).

     4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
     It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1
     indicates that the TUG-3/VC-3/STS-1 SPE is not further
     subdivided and contains a VC-3/C-3 in SDH or the equivalent in
     SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
     corresponding higher order signal.

     5. M indicates a specific branch of a TUG-2/VT Group. It is not
     significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.
     M=1 indicates that the TUG-2/VT Group is not further subdivided
     and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
     inside the corresponding VT Group, these values MUST NOT be used
     for SDH since there is no equivalent of VT-3 with SDH. M=4->6
     indicates a specific VC-12/VT-2 SPE inside the corresponding
     TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE
     inside the corresponding TUG-2/VT Group. Note that M=0 denotes
     an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).

      The M encoding is summarized in the following table:

          M    SDH                          SONET
         ----------------------------------------------------------
          0    unstructured VC-4/VC-3  unstructured STS-1 SPE
          1    VC-2                    VT-6
          2    -                       1st VT-3
          3    -                       2nd VT-3
          4    1st VC-12               1st VT-2
          5    2nd VC-12               2nd VT-2
          6    3rd VC-12               3rd VT-2
          7    1st VC-11               1st VT-1.5
          8    2nd VC-11               2nd VT-1.5
          9    3rd VC-11               3rd VT-1.5
          10   4th VC-11               4th VT-1.5

   In case of contiguous concatenation, the label that is used is the
   lowest label of the contiguously concatenated signal as explained
   before. The higher part of the label indicates where the signal
   starts and the lowest part is not significant. For instance, when
   requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.

   Examples of labels:

   Example 1: S>0, U=1, K=1, L=0, M=0
   Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group.

   Example 2: S>0, U=1, K>1, L=1, M=0
   Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.

   Example 3: S>0, U>1, K=0, L=0, M=0
   Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.

   Example 4: S>0, U>1, K=0, L>1, M=1
   Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1
SPE of the Sth AUG-1/STS-3 group.

   Example 5: S>0, U>1, K=0, L>1, M=9
   Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth
VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.

   Example 6: S>0, U=1, K>1, L>1, M=5
   Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of
the Sth AUG-1.

> -----Ursprüngliche Nachricht-----
> Von: Mannie, Eric [mailto:[email-masked]]
> Gesendet: Donnerstag, 18. Oktober 2001 18:58
> An: 'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> Betreff: RE: Moving right along ...
>
>
> Hello Juergen,
>
> Your comments are addressed hereafter. Note that you didn't raised any
> technical problem or mistake in your comments (i.e. the draft "works" very
> well as it is).
>
> - the first comment is not about a technical issue but an
> "editorial" issue.
> - the second comment is about a change that will not bring any new
> capability.
>
> >Concerning the SDH/Sonet documents I want to raise a formal issue.
> >We have now two documents, a document that covers ITU/ANSI standard
> features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that
> covers non-standard features
> (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in
> Appendix 1
> of the standard feature document a non standard feature (Group signals) is
> listed. It is even mentioned that the use of groups (AUG, STSG,
> ...) is not
> described in standards. So this feature should be moved to the
> non-standards
> document. Otherwise the split of the documents doesn't make sense.
>
> We spend a considerable amount of time speaking about this
> particular issue
> and I still don't see any technical justification for what you said.
>
> For those who are not SDH/SONET experts some quick explanation:
>
> We call a "super-circuit" a set of physical circuits in the
> transport plane
> all belonging to the same LSP in the signaling plane. We defined two kinds
> of super-circuits: "group circuits" and "multiplicative circuits".
>
> Multiplicative circuits are setup using the multiplier field that
> we defined
> (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no
> objection
> about these ones.
>
> Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG,
> TUG, VTG (we defined the equivalent signal type in the signaling). The
> comment of Juergen is about these group circuits. A group circuit
> represents
> some bandwidth at a given place in the SDH/SONET multiplex. The
> advantage of
> such a super-circuit is that the customer can re-structure its content as
> he/she likes. The operator doesn't care.
>
> Such an application is possible and is already implemented. SDH/SONET is
> self-describing, i.e. by looking at the signal one can understand
> how it is
> structured (like Juergen explained on the mailing list), so one
> can setup a
> circuit without describing the content (very very cool).
>
> The transport plane ignores that the signaling plane uses an "abstraction"
> (i.e. an LSP) representing several physical circuits. Note that
> restoration
> and management belong respectively to the signaling plane and to the
> management plane in the IETF view (not to the transport plane like in the
> ITU-T view).
>
> From that point of view, group circuits are a GMPLS signaling
> plane feature
> and not a transport plane feature. We put the comment on the fact
> that this
> is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy.
>
> I could say clearly at the beginning of the draft that the signal
> types that
> we are defining in this document are not ITU-T signal types but
> GMPLS signal
> types (of course) whose have in some cases a direct relationship with the
> ITU-T signal types.
>
> Any objection ?
>
> >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
> prefer to have the same coding for Sonet and SDH. That makes the
> implementation for Sonet and SDH simpler. Furthermore ITU and T1
> have tried
> over the last years to align Sonet and SDH as much as possible. The
> definition of different labels for Sonet and SDH contradicts these
> activities.
>
> We discussed this one since a long time as well. Let me be clear:
>
> - labels are local to an interface (we all agree).
> - a link (interface) is operated at one point in the time as either SDH or
> SONET.
> - your proposal will require to re-evaluate many things.
> - and it took us a lot of time to fine-tune and to validate the current
> label structure.
> - we could have technical issues with your proposal that would impact more
> than this draft (Dimitri saw some of them, please see with him).
> - you never provided a complete analysis of your proposal.
>
> But more important: your proposal doesn't bring any additional
> functionality
> to the draft.
>
> At this very late stage, since this not bringing any new
> functionality, and
> since the label structure is very stable since a long time, I would prefer
> not to restart a long technical discussion to change and re-validate the
> draft.
>
> Kind regards,
>
> Eric
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Kireeti Kompella [mailto:[email-masked]]
> > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > An: [email-masked]
> > Betreff: Moving right along ...
> >
> >
> > Despite the energetic subject line, we the WG chairs have been
> > lax in our duties.  So, here goes:
> >
> > Lou has submitted the latest versions of the generalized
> > signaling documents quite some time ago (thanks, Lou):
> >
> > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > draft-ietf-mpls-generalized-signaling-06.txt
> >
> > Also, Eric has posted the SONET/SDH documents (merci, Eric):
> >
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >
> > All of these should have addressed the issues raised in the earlier
> > versions.  Please read the new versions, and send your comments to
> > the list by Tuesday Oct 23.  At that point, when the final round
> > of comments have been addressed, these docs will go to IESG Last
> > Call.  If any one objects to sending these docs to IESG Last Call,
> > raise your issues now.
> >
> > I see that the GMPLS architecture document is a CCAMP WG doc, but
> > the minutes say that we should look for consensus on the list.  So,
> > if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > will progress to WG Last Call.
> >
> > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > list know what your thinking is on these.  (BTW, both these docs
> > were to have some edits done.  If the authors could do that before
> > the next IETF, we can try to make more progress then.)
> >
> > The MIB overview doc was recently posted.  Please read and comment
> > to the list.
> >
> > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > was generally thought to be useful; it will be published as a
> > CCAMP informational doc.  This begins a two week Last Call on
> > the doc, ending Tuesday Oct 30.
> >
> > There was no consensus on whether the GMPLS framework should be
> > a CCAMP WG doc.  Please indicate your pleasure.
> >
> > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > raised that this draft is close to ready for WG Last Call.  Please
> > review it, and let us know if you disagree.
> >
> > The OLI requirements doc was broadly accepted.  Please let the
> > list know if you think this doc should be a WG doc.
> >
> > It's still open whether we (the IETF) should be working on
> > LMP-WDM.  I urge the authors to keep on working on the doc, and
> > keeping it in sync with LMP; however, we will postpone making it
> > a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > happen in Salt Lake City.
> >
> > There was reasonable interest in the tunnel trace requirements
> > doc.  Let's formalize this: do you think this should be made a
> > CCAMP WG document?
> >
> > Summary:
> >
> > 1) Final comments and IESG Last Call readiness for:
> > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > draft-ietf-mpls-generalized-signaling-06.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >
> > 2) Should the following documents be CCAMP WG docs?
> > draft-bonica-tunneltrace-02.txt
> > draft-fontana-ccamp-gmpls-g709-00.txt
> > draft-ietf-ccamp-gmpls-architecture-00.txt
> > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > draft-many-ccamp-gmpls-framework-00.txt
> > draft-many-oli-reqts-00.txt
> >
> > 3) Comment on MIB overview.
> >
> > 4) Two week Last Call comments on
> > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> >
> > 5) Last Call readiness of
> > draft-ietf-ccamp-gmpls-architecture-00.txt
> > draft-ietf-ccamp-lmp-01.txt
> >
> > Thanks,
> > Kireeti.
> >
>

Delivery-date: Tue, 23 Oct 2001 03:22:39 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Yanhe Fan <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, John Drake <[email-masked]>,  Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Tue, 23 Oct 2001 12:20:01 +0200

Hi Maarten and Zhi,

I have the feeling that you are inventing a new model with a new protocol.
This is not how GMPLS works. I understand your frustrations and I have the
feeling that your ideas should be addressed somewhere else rather than
trying to change a model that we are finalizing and that we got from the
MPLS model.

There are maybe 1000 ways of designing a control plane for transmission
networks. I would suggest that you first develop your own model and then
that we compare the two. 

Please, don't forget that we have here to be constructive in terms of GMPLS.
We have final discussions about the core GMPLS signaling, this is not the
beginning but the end of an (intermediate) phase.

Ok, GMPLS doesn't do everything. It doesn't do coffee and doesn't clean your
house :-) We know it. Personally, I don't believe in the ultimate model and
protocol that will do everything and that will take 10 years to be
specified, with abstract protocols, meta-models, etc.

By the way, personally I don't see any benefit of defining these
meta-models, abstract models and abstract protocols. It is hard to
understand for non super-expert and it is a complete loss of time for the
readers. I prefer practical solutions.

I am also seeing discussions that we already have many times in the past. I
don't see any benefit of having them again, and again, and again. If we
continue like this we will all implement a tool to answer automatically with
our previous e-mails :-)

Ok, there is a small set of people that don't like the way that GMPLS is
designed and defined (always the same 4 or 5 people by the way) - that's
100% your right guys and I respect it. In comparison with the hundreds
(thousands ?) of people that are working on GMPLS and implementing it, this
is a great achievement !

So, I ask you the question: what do you want to achieve personally at this
stage ? Don't you think that sometimes it is needed to finish one step,
before going to the next one ?

Kind regards,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, October 22, 2001 11:07 PM
To: Yanhe Fan
Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ...

Yanhe,

The situation Zhi describes is one that will be very typical in the optical
(SDH/SONET) network in the coming years. We will most likely see islands of
switched subnetworks interconnected via the existing SDH/SONET non-switched
networks. By means of management actions, links (GMPLS: link bundles) will
be
setup between an edge node in one switched subnetwork and an other edge node
in
the next switched subnetwork. In G.805 terminology, these links are so
called
serial compound links.

The switched subnetworks will treat these serial compound links as normal
links,
"ignoring" the intermediate non-switched nodes they traverse. These links
will
contain a fixed set of link connections, which are identified by their
respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
The server signal that carries the e.g. 5 STS1 link connections in the link
at A
can be an OC12, whereas this can be an OC48 at Z.

During discovery or by means of provisioning both A and Z nodes get aware of
the
5 sTS1 link connections as tuples of e.g. 

        SNPa             SNPz
-----------------------------------
- port Ai/trib T1 - port Zj/trib Ta	(STS1 link connection #1)
- port Ai/trib T2 - port Zj/trib Tb	(STS1 link connection #2)
- port Ai/trib T3 - port Zj/trib Tc	(STS1 link connection #3)
- port Ai/trib T4 - port Zj/trib Td	(STS1 link connection #4)
- port Ai/trib T5 - port Zj/trib Te	(STS1 link connection #5)

As both ends of the link build up this same relation information, it is
possible
to use as link connection identifier only one of the two SNPs. E.g. node A
identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
info
to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta".
Vice
versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
received
by node A, this will be converted into Ai/T1.

For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
both ends of the link connection, only the timeslot at the sending end. The
receiving end needs to convert this then into its local timeslot number.

Regards,

Maarten

Yanhe Fan wrote:
> 
> Hi Zhi,
> 
> What B does is breaking the label association between A and C by crossing
> connect
> the time slots.
> 
> If the cross connect performed by B is fixed (in your case), what needs to
> do is
> just to rebuild the label association by configuration or a protocol such
as
> LMP;
> If the cross connect is not fixed but dynamic, the best thing to do is to
> make B
> a GMPLS speaker.

Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
network... no chance... those will stay non-switched...

> 
> Yanhe
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 6:01 PM
> To: Yanhe Fan
> Cc: John Drake; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ...
> 
> Hi Yanhe,
> 
> Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> is simply part of the network that made up the "dumb" pipe. And because
> the control plane control channel is separate, A and C can be adjacent
> without ever knowing who B is or that even B existed. From A and C's
> point of view, the network looks like:
> 
>   A ----- C
> 
> Think of the case of how a BGP sees an area. If an area is made up of:
> 
>   A -- B -- C
> 
> and B is internal router, does BGP "see" B?
> 
> Zhi
> 
> Yanhe Fan wrote:
> 
> > Hi, Zhi
> >
> >
> >>For the label value for SONET/SDH or the label description in the
> >>generic draft, the label is defined as directly representing the
> >>"timeslot". Now if I have a control plane controlled transport network
> >>that goes through a ADM that is not control plane controlled, as:
> >>
> >>
> >>+--------+               +--------+               +--------+
> >>|        | ---1--------- |        | ----1-------- |        |
> >>|        | ---2--------- |        | ----2-------- |        |
> >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> >>|        | ---4--------- |        | ----4-------- |        |
> >>|        | ---5--------- |        | ----5-------- |        |
> >>+--------+               +--------+               +--------+
> >>
> >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> >>has labels 1,2,3,4,5 incoming.
> >>
> >>Now imagine that at B, it actually has a fixed cross-connect that
> >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> >>
> >>Now when A GMPLS sends a message to C, the label it uses is "1".
> >>However, the connection/LSP associated with timeslot "1" is actually the
> >>label of timeslot "2" at C. </z>
> >>
> >
> > In this case, you're trying to use GMPLS to setup an LSP cross a node
(B)
> > which can't understand GMPLS.
> >
> > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > GMPLS if B can't understand GMPLS?
> >
> > Now imagine A and B are LSRs, and B is a conventional router (can't
> > understand
> > MPLS), can you setup an LSP A-B-C?
> >
> > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > understand PNNI at all?
> >
> > My point is that in order to make you case work, some additional work
need
> > to
> > be done besie simply using GMPLS as singnaling protocol, becase some
node
> on
> > the path is not GMPLS speakers. A and C needs the info of time slot
> aligment
> >
> > between them. This can be done by some configurations, some link
> management
> > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > eveything
> > works fine.
> >
> > Yanhe
> >

Delivery-date: Mon, 22 Oct 2001 20:12:25 -0700
From: "Juergen Heiles" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: AW: Moving right along ...
Date: Mon, 22 Oct 2001 15:00:45 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C15B0A.53696060
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi Eric,

sorry for the delayed answer, but I have problems with the remtoe LAN access
here in Geneva.
I am therefore sending the mail via my ITU e-mail account and hope it is
accepted by the ccamp list server.

You compare groups with the multiplier, this is wrong. The multiplier sets
up n indivudal VC-n connections. The transport plane sees only the
individual VCs and the VC type (VC-4/372712711) is explicitly defined. So no
additional support at the transport plane is needed. It is a pure control
plane feature.
Groups are not a pure control plane feature. When you setup a group (AUG,
TUG, VTG, STSG) the transport plane still has to handle the individual
VCs/SPEs that are part of the group. Due the independent timing of each
VC/STS-SPE pointer processing has to be done per individual VC/SPE. The
transport plane cannot switch the group as a whole between STM/STS ports.
The transport plane therefore has to automatically detect the structure of
the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a
mixture and that may change over the lifetime of the group. This automatic
detection is not a standard SONET/SDH feature. As I described in previous
e-mails it is possible to do it based on pointer values during non error
situations. During errors (defects, AIS condtions) of individual singals of
a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. If a single
VC-12 in a TUG3 group has AIS (note that the AIS could result from a failure
outside the LSP), I assume that still all the other VCs of the group shall
be connected without errors. No SONET/SDH standard covers the automatic
detection.
So in my view it is similarly to transparency of individual SOH bytes. G.707
defines the individual SOH bytes, however transparency it is not standard
SONET/SDH and is therefore in the non-standard document. In the same way
G.707 defines groups, but not the automatic detection of the group
structure. So it should be moved to the non-standards document. At the
London meeting Kireeti said the decision on standard/non-standard features
is not based on rough consensus, but on what is in the ITU/ANSI documents.
Can you present me any ITU/ANSI standard that defines automatic detection of
the group structure?

You say groups are cool, may be for some applications. But note that groups
have the same fragementation problem as contiguous concatenation. The VCs in
a group always have to stay together. If for a example a TUG2 consits of 3
VC-12 you cannot put them in arbitrary free time slots. They have stay in
the time slots that belong to a single TUG2.

Concering the lable, aligning the SONET labels with the SDH lables makes
live easier. It is also a sign that SONET and SDH are identical for most
parts. I also showed you that SONET uses the same two-stage interleaving
process as SDH. If you look at the attached figure from T1.105 you see that
the STS-1 time slots in an STS-N signal are not continously number. First 3
STS-1s are combiend to a STS3 groupg and then the STS3 groups are
multiplexed. The same as SDH with AU3s and AUGs.
As the SONET lables will become the same as the SDH labels we don't have to
evaluate much. I already made a proposal some time ago. Why introduce
different labels without a need?
You haven't provided a reason for different lables. We had several people
that wanted to have the same label structure and only you opposed. So what
is rough consensus?

See my proposal for the labels below.

Juergen

This is my proposal for the label:
   The format of the label for SDH and/or SONET TDM-LSR link is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               S               |   U   |   K   |   L   |   M   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For SDH, this is an extension of the numbering scheme defined in
   G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same
   signaling scheme is used in order to provide easy interworkign between
   SDH and SONET signaling. For the S field a STS-3 group,which
   corresponds with the SDH AUG-1 level is introduce. The U field indicates
   the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. The K
   field is not significant for SONET as it doesn't support structured
   STS-3c-SPEs and must be set to zero.

   Each letter indicates a possible branch number starting at the
   parent node in the multiplex structure. Branches are considered as
   numbered in increasing order, starting from the top of the
   multiplexing structure. The numbering starts at 1, zero is used to
   indicate a non-significant field.

   When a field is not significant in a particular context it MUST be
   set to zero when transmitted, and MUST be ignored when received.

   When hierarchical SDH/SONET LSPs are used, an LSP with a given
   bandwidth can be used to tunnel lower order LSPs.  The higher
   order SDH/SONET LSP behaves as a virtual link with a given
   bandwidth (e.g. VC-3), it may also be used as a Forwarding
   Adjacency. A lower order SDH/SONET LSP can be established through
   that higher order LSP. Since a label is local to a (virtual) link,
   the highest part of that label is non-significant and is set to
   zero.

   For instance, a VC-3 LSP can be advertised as a forwarding
   adjacency. In that case the labels allocated between the two ends
   of that LSP (i.e. for that "link") will have S, U and K set to
   zero, i.e., non-significant, while L and M will be used to
   indicate the signal allocated in that VC-3.

     1. S is the index of a particular AUG-1/STS-3 group. S=1->N
     indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN
     multiplex. For example, S=1 indicates the first AUG-1/STS-3 group,
     and S=N indicates the last AUG-1/STS-3 group of this multiplex.
     S is not significant for STM-0/STS-1.

     2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3
     group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a
     AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4
     indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3
     group.

     3. K is only significant for SDH VC-4 and must be ignored for
     SONET and SDH HOVC-3. It indicates a specific branch of a VC-4.
     K=1 indicates that the VC-4 is not further subdivided and
     contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-
     4. K is not significant when the AUG-1 is divided into AU-3s
     (easy to read and test).

     4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
     It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1
     indicates that the TUG-3/VC-3/STS-1 SPE is not further
     subdivided and contains a VC-3/C-3 in SDH or the equivalent in
     SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
     corresponding higher order signal.

     5. M indicates a specific branch of a TUG-2/VT Group. It is not
     significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.
     M=1 indicates that the TUG-2/VT Group is not further subdivided
     and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
     inside the corresponding VT Group, these values MUST NOT be used
     for SDH since there is no equivalent of VT-3 with SDH. M=4->6
     indicates a specific VC-12/VT-2 SPE inside the corresponding
     TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE
     inside the corresponding TUG-2/VT Group. Note that M=0 denotes
     an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).

      The M encoding is summarized in the following table:

          M    SDH                          SONET
         ----------------------------------------------------------
          0    unstructured VC-4/VC-3  unstructured STS-1 SPE
          1    VC-2                    VT-6
          2    -                       1st VT-3
          3    -                       2nd VT-3
          4    1st VC-12               1st VT-2
          5    2nd VC-12               2nd VT-2
          6    3rd VC-12               3rd VT-2
          7    1st VC-11               1st VT-1.5
          8    2nd VC-11               2nd VT-1.5
          9    3rd VC-11               3rd VT-1.5
          10   4th VC-11               4th VT-1.5

   In case of contiguous concatenation, the label that is used is the
   lowest label of the contiguously concatenated signal as explained
   before. The higher part of the label indicates where the signal
   starts and the lowest part is not significant. For instance, when
   requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.

   Examples of labels:

   Example 1: S>0, U=1, K=1, L=0, M=0
   Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group.

   Example 2: S>0, U=1, K>1, L=1, M=0
   Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.

   Example 3: S>0, U>1, K=0, L=0, M=0
   Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.

   Example 4: S>0, U>1, K=0, L>1, M=1
   Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1
SPE of the Sth AUG-1/STS-3 group.

   Example 5: S>0, U>1, K=0, L>1, M=9
   Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth
VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group.

   Example 6: S>0, U=1, K>1, L>1, M=5
   Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of
the Sth AUG-1.

> -----Ursprüngliche Nachricht-----
> Von: Mannie, Eric [mailto:[email-masked]]
> Gesendet: Donnerstag, 18. Oktober 2001 18:58
> An: 'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> Betreff: RE: Moving right along ...
>
>
> Hello Juergen,
>
> Your comments are addressed hereafter. Note that you didn't raised any
> technical problem or mistake in your comments (i.e. the draft "works" very
> well as it is).
>
> - the first comment is not about a technical issue but an
> "editorial" issue.
> - the second comment is about a change that will not bring any new
> capability.
>
> >Concerning the SDH/Sonet documents I want to raise a formal issue.
> >We have now two documents, a document that covers ITU/ANSI standard
> features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that
> covers non-standard features
> (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in
> Appendix 1
> of the standard feature document a non standard feature (Group signals) is
> listed. It is even mentioned that the use of groups (AUG, STSG,
> ...) is not
> described in standards. So this feature should be moved to the
> non-standards
> document. Otherwise the split of the documents doesn't make sense.
>
> We spend a considerable amount of time speaking about this
> particular issue
> and I still don't see any technical justification for what you said.
>
> For those who are not SDH/SONET experts some quick explanation:
>
> We call a "super-circuit" a set of physical circuits in the
> transport plane
> all belonging to the same LSP in the signaling plane. We defined two kinds
> of super-circuits: "group circuits" and "multiplicative circuits".
>
> Multiplicative circuits are setup using the multiplier field that
> we defined
> (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no
> objection
> about these ones.
>
> Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG,
> TUG, VTG (we defined the equivalent signal type in the signaling). The
> comment of Juergen is about these group circuits. A group circuit
> represents
> some bandwidth at a given place in the SDH/SONET multiplex. The
> advantage of
> such a super-circuit is that the customer can re-structure its content as
> he/she likes. The operator doesn't care.
>
> Such an application is possible and is already implemented. SDH/SONET is
> self-describing, i.e. by looking at the signal one can understand
> how it is
> structured (like Juergen explained on the mailing list), so one
> can setup a
> circuit without describing the content (very very cool).
>
> The transport plane ignores that the signaling plane uses an "abstraction"
> (i.e. an LSP) representing several physical circuits. Note that
> restoration
> and management belong respectively to the signaling plane and to the
> management plane in the IETF view (not to the transport plane like in the
> ITU-T view).
>
> From that point of view, group circuits are a GMPLS signaling
> plane feature
> and not a transport plane feature. We put the comment on the fact
> that this
> is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy.
>
> I could say clearly at the beginning of the draft that the signal
> types that
> we are defining in this document are not ITU-T signal types but
> GMPLS signal
> types (of course) whose have in some cases a direct relationship with the
> ITU-T signal types.
>
> Any objection ?
>
> >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
> prefer to have the same coding for Sonet and SDH. That makes the
> implementation for Sonet and SDH simpler. Furthermore ITU and T1
> have tried
> over the last years to align Sonet and SDH as much as possible. The
> definition of different labels for Sonet and SDH contradicts these
> activities.
>
> We discussed this one since a long time as well. Let me be clear:
>
> - labels are local to an interface (we all agree).
> - a link (interface) is operated at one point in the time as either SDH or
> SONET.
> - your proposal will require to re-evaluate many things.
> - and it took us a lot of time to fine-tune and to validate the current
> label structure.
> - we could have technical issues with your proposal that would impact more
> than this draft (Dimitri saw some of them, please see with him).
> - you never provided a complete analysis of your proposal.
>
> But more important: your proposal doesn't bring any additional
> functionality
> to the draft.
>
> At this very late stage, since this not bringing any new
> functionality, and
> since the label structure is very stable since a long time, I would prefer
> not to restart a long technical discussion to change and re-validate the
> draft.
>
> Kind regards,
>
> Eric
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Kireeti Kompella [mailto:[email-masked]]
> > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > An: [email-masked]
> > Betreff: Moving right along ...
> >
> >
> > Despite the energetic subject line, we the WG chairs have been
> > lax in our duties.  So, here goes:
> >
> > Lou has submitted the latest versions of the generalized
> > signaling documents quite some time ago (thanks, Lou):
> >
> > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > draft-ietf-mpls-generalized-signaling-06.txt
> >
> > Also, Eric has posted the SONET/SDH documents (merci, Eric):
> >
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >
> > All of these should have addressed the issues raised in the earlier
> > versions.  Please read the new versions, and send your comments to
> > the list by Tuesday Oct 23.  At that point, when the final round
> > of comments have been addressed, these docs will go to IESG Last
> > Call.  If any one objects to sending these docs to IESG Last Call,
> > raise your issues now.
> >
> > I see that the GMPLS architecture document is a CCAMP WG doc, but
> > the minutes say that we should look for consensus on the list.  So,
> > if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > will progress to WG Last Call.
> >
> > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > list know what your thinking is on these.  (BTW, both these docs
> > were to have some edits done.  If the authors could do that before
> > the next IETF, we can try to make more progress then.)
> >
> > The MIB overview doc was recently posted.  Please read and comment
> > to the list.
> >
> > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > was generally thought to be useful; it will be published as a
> > CCAMP informational doc.  This begins a two week Last Call on
> > the doc, ending Tuesday Oct 30.
> >
> > There was no consensus on whether the GMPLS framework should be
> > a CCAMP WG doc.  Please indicate your pleasure.
> >
> > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > raised that this draft is close to ready for WG Last Call.  Please
> > review it, and let us know if you disagree.
> >
> > The OLI requirements doc was broadly accepted.  Please let the
> > list know if you think this doc should be a WG doc.
> >
> > It's still open whether we (the IETF) should be working on
> > LMP-WDM.  I urge the authors to keep on working on the doc, and
> > keeping it in sync with LMP; however, we will postpone making it
> > a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > happen in Salt Lake City.
> >
> > There was reasonable interest in the tunnel trace requirements
> > doc.  Let's formalize this: do you think this should be made a
> > CCAMP WG document?
> >
> > Summary:
> >
> > 1) Final comments and IESG Last Call readiness for:
> > draft-ietf-mpls-generalized-cr-ldp-04.txt
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > draft-ietf-mpls-generalized-signaling-06.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >
> > 2) Should the following documents be CCAMP WG docs?
> > draft-bonica-tunneltrace-02.txt
> > draft-fontana-ccamp-gmpls-g709-00.txt
> > draft-ietf-ccamp-gmpls-architecture-00.txt
> > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > draft-many-ccamp-gmpls-framework-00.txt
> > draft-many-oli-reqts-00.txt
> >
> > 3) Comment on MIB overview.
> >
> > 4) Two week Last Call comments on
> > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> >
> > 5) Last Call readiness of
> > draft-ietf-ccamp-gmpls-architecture-00.txt
> > draft-ietf-ccamp-lmp-01.txt
> >
> > Thanks,
> > Kireeti.
> >
>

------=_NextPart_000_0000_01C15B0A.53696060
Content-Type: application/msword;
	name="sonet_interleaver.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="sonet_interleaver.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALAAAAAAAAAAA
EAAALgAAAAEAAAD+////AAAAACsAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------=_NextPart_000_0000_01C15B0A.53696060--

Delivery-date: Mon, 22 Oct 2001 16:09:07 -0700
Date: Mon, 22 Oct 2001 19:08:13 -0400
From: Eric Gray <[email-masked]>
To: Yangguang Xu <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Yangguang/Yakov,

    This seems to be getting all blown out of proportion, however it
is probably at least partly my fault - for taking earlier discussions
off of the list.  Therefore, I will try to address these comments on
the list - though I will almost certainly regret the attempt.  :-)

    Back on October 1st, Lou Berger announced availability of new
draft version of the signaling and RSVP-TE documents he had been
working on.  On October 3rd, Yangguang repeated some questions
that had been asked previously on the list and Fong Liaw answered
these questions.  This much can be seen at the archival site -

        ftp://ops.ietf.org/pub/lists/ccamp.current

(look for the subject line - "update GMPLS signaling documents").
This site is (unfortunately) not an HTML friendly site.

    I felt that Fong had answered these questions completely, but I
tried to add a little to this in an off-line reply (I copied Fong as a
courtesy).  Most of my replies to the ccamp mailing list are off line,
because usually replies I send to this list bounce (feel free to ask
the list administrator why that happens).  I did not realize at the
time that (at least one of the) questions that Yangguang posted were
actually asked by other people (the posting didn't include this
information), or I would have included Gopal, at least.

    From this reply ensued an off-list discussion that lasted slightly
less than a day. I will try to summarize this here (named participants,
jump in if you think this summary is fundamentally inaccurate).

========================================================================

Yangguang (on list): There is an ordering issue during resynchronization
since the LSPs would depend on other FA-LSPs the interface IDs for which
would have been generated dynamically. So the mechanism described will
not work, unless this information is preserved across restarts - in
which case we might as well preserve other information as well, and
avoid resynchronization.

Fong (on list):  We only need to consider the FA-LSP ingress and egress
since the transit nodes do not see signaling for the hierarchical LSP.
In the egress reset case, the egress can resolve the ordering based on
the fact that it receives a 'recovery' label instead of a suggested label.
In the ingress case, the ingress LSR will know the required ordering.
You need to resynchronize no matter what because of the possibility of
in-progress connection setup.

Me (off-list from here on): Ordering problems should not arise because
Path messages should not be sent until underlying LSPs are established
and interface IDs are known.  Resynchronization is both simpler and more
likely to work than trying to preserve sufficient state to be able to
avoid it. In any case, no implementation should be allowed to assume
indefinitely that it has correctly preserved state.

Yangguang: For FA-LSPs, are you suggesting the re-start happens between
the ingress/egress nodes, instead of its physically adjacent neighbors?

Me:  'Ingress', 'egress' and 'adjacent neighbors' are misleading when
used with hierarchical LSPs without at least further qualification.
Adjacent neighbors (WRT one LSP) have no state relative to 'higher-level'
LSPs (these would be seen as lower-level labels by these LSRs).  Adjacent
neighbors in a higher-level LSP would be the ingress and egress LSRs for
lower-level LSPs on which they are based.

Fong: No, since the data plane of the FA may still function.  The egress
node of the FA may receive RSVP packets for the LSP that uses the FA. If
the data plane does not function after the restart, we don't even have
the dependency problem at all.

Me:  Yes, higher level LSPs labels can be exchanged before the lower
level data plane is established - but cannot be used until the link has
been re-established.  Moreover, if the signaling for the higher level LSP
depends on knowing in advance the way that the link is identified, then
signaling will be delayed until the information is available even if the
control plane remains active.

Yangguang:  My question and example all assume the data path is working
normally and only the control entity fails.  In the example below:

----A------B..B1....C1..C-----D------E-----

B and C are FAs, if B's control entity fails and reboots, it has to
re-sync with C for LSPs using the B-C tunnel (BC FA-LSP).  B must re-sync
with both its immediate neighbor B1 and FA C.  Then B's re-sync process
does have order issue. It should make sure all FA-LSPs are still working
and then re-sync with FAs (if they have a way to keep these information
and mapping after reboot) for LSPs using the FA-LSPs.

Me:  Using your example, suppose that the link between A and B goes down,
imagine that the labels used by A and B for LSPs across this link are
exchanged out of band, and suppose that a means exists by which both A
and B expect this link to be restored.  Under these circumstances, do not
the exact same issues exist as in your example (between B and C)?  Yet
everyone must know that any labels negotiated between A and B will not be
useful until the link is restored.  Also, everyone must realize that - if
the link IDs are lost as a result of the loss of the link between A & B -
the signaling for LSP restoration MUST wait for the link IDs to be
re-established.

 Me (continued): The key difference between a link failure between A and
B and B's having a control plane restart (as in your example) is that (in
your example) you assume the same technique is used to restore all LSPs
involving B.  It is not valid to assume - in a reasonable implementation
- that all LSPS involving B will be re-established simultaneously.  The
ordering constraint is a naturally occurring one given that - in any
recovery - links must first be re-established, then adjacencies across
those links and then any higher level activity.  The fact that - without
of band signaling - it is possible to signal labels before the data plane
is ready to be used in no way implies that it it makes sense to ignore
the natural ordering of hierarchical link re-establishment.

========================================================================

I think it is not clear that anything further needs to be specified in
the draft with respect to the issue of ordering of LSP re-establishment.

Also, with respect to the backward compatibility issue below: it is not
impossible for an implementation to be configurable to support either
GMPLS based signaling or some existing scheme on a per-interface basis,
if that is what you want to do.  To my knowledge, there is not so much
in the way of current 'lateral' compatibility to be worried that much
about backward compatibility.  Who in particular should we aim to be
backward compatible with, given that few existing solutions are truly
compatible with each other?    :-)

Yangguang wrote:

> Yakov,
>
> Thanks for resenting me the message from Eric.
>
> Indeed, instead of looking for answers from you, my intention was just trying to
> point out some holes in the current proposal and your previous response. And
> thanks for just throwing them back to me.
>
> Again, not trying to add more smoke, just repeat my main point again: there are
> existing solid solutions that can satisfy carriers' requirement of preserving
> data path and re-create data path state after rebooting. I think many of us are
> aware of that. If you are proposing a new mechanism, no matter good or bad, at
> least you could consider some "backward" compatibility issues. Meanwhile, even I
> have confidence that you can make it work well eventually, there are some corner
> cases I'd like to point out.
>
> And also a piece of suggestion, before claiming a solution for a problem. It's
> better to understand the problem well first. There is nothing can replace
> working experience of either operating, designing and developing optical
> transport network and NEs.
>
> Yangguang
>
> Yakov Rekhter wrote:
> >
> > Yangguang,
> >
> > > Indeed, you didn't answer my questions.
> >
> > Perhaps it would be more correct to say that I didn't answer
> > your questions *to your satisfaction*. And if that is the case, then
> > I hope that the attached e-mail from Eric Gray (that he let me repost
> > to the list) would answer your questions to your satisfaction.
> >
> > > Instead of informed readers, more
> > > important is to have better informed writers.
> >
> > See the attached.
> >
> > > BTW, I have no intention to let you design my product at all.
> >
> > Glad to hear this !!!
> >
> > Yakov.
> > ---------------------------------------------------------------------
> > Date:    Fri, 19 Oct 2001 15:38:58 EDT
> > To:      Yangguang Xu <[email-masked]>
> > cc:      Yakov Rekhter <[email-masked]>
> > From:    Eric Gray <[email-masked]>
> > Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
> >
> > Yangguang,
> >
> >     Careful, don't let this discussion descend into the nether regions of
> > name calling and finger pointing. :-)
> >
> >     The fact that the seeming remote neighbors use RSVP Hello is clear
> > once you realize that - for the purposes of hierarchical LSP setup, they
> > are adjacent.  You may recall this from an off-line discussion we had.
> >
> >     Yakov's comment was simply stating that it is not a part of standard's
> > development to make an implementer's cook-book.  He was not (I think)
> > trying to imply that you could not write your own implementation.  He was
> > just saying that the effort of achieving interoperability falls on the people
> > doing the implementation not on the people doing the standard.  The bare
> > information is there, but the work is up to you.
> >
> >     As you know, the standard is not complete until several implementations
> > have achieved interoperability independently.  But the opportunity to get in
> > the market stems from being one of those implementations - and there is
> > zero motivation for any implementer to make this task easy for all others.
> > One of the costs associated with the 'running code' part of IETF mistique
> > is that standards are written by implementers.
> >
> >     Unless and until that changes, you just have to learn to deal with it.  :-)
> >
> > You wrote:
> >
> > > Indeed, you didn't answer my questions. Instead of informed readers, more
> > > important is to have better informed writers.
> > >
> > > BTW, I have no intention to let you design my product at all.
> > >
> > > Yangguang
> > >
> > > Yakov Rekhter wrote:
> > > >
> > > > Yangguang,
> > > >
> > > > > Yakov,
> > > > >
> > > > > Further questions in-line. Regards,
> > > >
> > > > Further responses in-line...
> > > >
> > > > > Yangguang
> > > > >
> > > > > > Couple of points:
> > > > > >
> > > > > > (1) First of all, you do run RSVP Hello between C and F.
> > > > >
> > > > > Is this specified somewhere? Or it's your proposal.
> > > >
> > > > What I mentioned in the above should be abundantly obvious to the
> > > > informed reader of RSVP and LSP Hierarchy specs.
> > > >
> > > > > Then, is there a scalability issue here?
> > > >
> > > > No.
> > > >
> > > > > Also, C and F could be thousands mile away (in the transport
> > > > > network) and the control channel bandwidth is expensive.
> > > >
> > > > GMPLS assumes that control channel is more than just 56Kbits/sec link.
> > > >
> > > > Or to put it differently, control channels used by GMPLS have more than
> > > > enough capacity for RSVP Hellos.
> > > >
> > > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > > > > > be able to recover the Interface ID it assigns to L1 from
> > > > > > a combination of (a) the OSPF/ISIS link state database that
> > > > > > F would recover, and (b) the Forward Interface ID (the one
> > > > > > assigned by C).
> > > > >
> > > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
> > n it
> > > > > has to recover its FA info first. How?
> > > >
> > > > The answer should be abundantly obvious to the informed reader.
> > > >
> > > > And to make it crystal clear, I have no intention in designing your
> > > > products for you.
> > > >
> > > > > > > Let us say the node can resynchronize its neighbor if
> > > > > > > the neighbor restarts and requests state recovery. But
> > > > > > > the issue is how a node can advertise that it does not
> > > > > > > need recovery since all its state was preserved?
> > > > > >
> > > > > > By treating is the same way as the way the spec handles
> > > > > > control channel fault.
> > > > > >
> > > > >
> > > > > If a node can recover states from NVRAM or OS (this solution is
> > > > > cheaper and have been implemented). It may not implement the spec.
> > > > > How could a neighboring node, which implements the spec, not tear
> > > > > down data connections mistakenly? Similar to a backward compatibility
> > > > > problem, even not.
> > > >
> > > > Stating the obvious: interoperability with a node that doesn't implement
> > > > the spec is outside the scope of the spec.
> > > >
> > > > > > > RECOVERY LABEL does not come into picture unless the node
> > > > > > > that is upstream to the restarting node has already received
> > > > > > > a Resv.
> > > > > >
> > > > > > Wrong. Quoting 9.5.3:
> > > > > >
> > > > > >    Upon detecting a restart with a neighbor that supports state
> > > > > >    recovery, a node SHOULD refresh all Path state shared with that
> > > > > >    neighbor.
> > > > > >
> > > > > > So, as you can hopefully see from the above, the upstream node doesn't
> > > > > > wait until it receives a Resv.
> > > > > >
> > > > >
> > > > > Then this may not meet carriers' requirement. (see IPO carriers' requirem
> > ent)
> > > > > Again, back to the telecom world (sorry about this, yet we are talking ab
> > out
> > > > > GMPLS), typically only the established pathes are preserved. Pending requ
> > ests
> > > > > may be purged/aborted. Then how?
> > > >
> > > > Note the verb is "SHOULD", not "MUST". The rest should be
> > > > obvious to the informed reader.
> > > >
> > > > > > > In case of PSC devices, it may be OK to remove state that
> > > > > > > is not resynchronized at the end of the recovery period,
> > > > > > > and the recovery period advertised might reflect that.
> > > > > > > But for LSPs in transport networks, one might want to
> > > > > > > have a different recovery period to avoid any LSP from
> > > > > > > going down because of recovery timer expiry.
> > > > > >
> > > > > > There is no requirement for a node to advertise exactly the
> > > > > > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > > > > > the node could advertise that it will remove the state that
> > > > > > isn't syncronized at the end of the recovery period, while
> > > > > > on the TDM interface precisely the same node could advertise
> > > > > > that the LSPs would be kept even after the recovery time expires.
> > > > > >
> > > > >
> > > > > So, restart_cap is per interface based?
> > > >
> > > > yes.
> > > >
> > > > > Is the spec going to be enhanced/clarified?
> > > >
> > > > The current spec need not be enhanced/clarified - what I mentioned in the
> > > > above should be abundantly obvious to the informed reader.
> > > >
> > > > > > > The first problems seems to be there still - consider two
> > > > > > > adjacent nodes restarting.  They both act both as the restarting
> > > > > > > node as well as the neighbor to the restarting node. So, once
> > > > > > > they learn the state from the upstream neighbor, do they use
> > > > > > > suggested label or the recovery label when they send the path
> > > > > > > message to the just restarted downstream neighbor?
> > > > > >
> > > > > > The recovery label.
> > > > > >
> > > > > > The following should be added to the existing text from the document:
> > > > > >
> > > > > >    In the special case where a restarting node also has a restating
> > > > > >    downstream neighbor, a Recovery_Label object should be used instead
> > > > > >    of a Suggested_Label object.
> > > > >
> > > > > How does a recovering NE know that its neighbor is also recovering? it ma
> > y
> > > > > lose the instance number totally
> > > >
> > > > It's advertised in the neighbor's hellos.
> > > >
> > > > Yakov.
> >
> > --
> > Eric Gray (mailto:[email-masked])
> > http://www.mindspring.com/~ewgray

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 22 Oct 2001 15:53:03 -0700
From: "Ewart Tempest" <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion
Date: Mon, 22 Oct 2001 18:51:33 -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_01C15B4C.188647A0
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,

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

Ewart

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Generalized Signaling - LSP Encoding Type expansion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dimitri,</FONT>
</P>

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

<P><FONT SIZE=3D2>Ewart</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15B4C.188647A0--

Delivery-date: Mon, 22 Oct 2001 15:35:12 -0700
From: Yanhe Fan <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>
Cc: "'Zhi-Wei Lin'" <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Mon, 22 Oct 2001 18:34:06 -0400

Hi Maarten,

A GMPLS label carries the info that can be used to configured the
crossconnets on a node. If the GMPLS neighboring nodes are connected
by normal links, the label identifies the time slots on both sides
and therefore, it can be used without any conversion. If the links
between the two nodes are not normal links, but a series compounded
links (No matter how many no-switched nodes they traverse), the label,
in this case, identifies the time slots only on one side, not both 
sides. This is what I mean by "breaking the label association". The
other side will convert the label into the local time slots before 
configuring the hardware. In order to do this, some additional info
is needed. This is what I mean by "rebuild the label association".
This can be done by configuration, a protocol, etc. The connection
tuples in your example can be used for this regarding as well.

Regards,
Yanhe

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, October 22, 2001 5:07 PM
To: Yanhe Fan
Cc: 'Zhi-Wei Lin'; John Drake; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ...

Yanhe,

The situation Zhi describes is one that will be very typical in the optical
(SDH/SONET) network in the coming years. We will most likely see islands of
switched subnetworks interconnected via the existing SDH/SONET non-switched
networks. By means of management actions, links (GMPLS: link bundles) will
be
setup between an edge node in one switched subnetwork and an other edge node
in
the next switched subnetwork. In G.805 terminology, these links are so
called
serial compound links.

The switched subnetworks will treat these serial compound links as normal
links,
"ignoring" the intermediate non-switched nodes they traverse. These links
will
contain a fixed set of link connections, which are identified by their
respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
The server signal that carries the e.g. 5 STS1 link connections in the link
at A
can be an OC12, whereas this can be an OC48 at Z.

During discovery or by means of provisioning both A and Z nodes get aware of
the
5 sTS1 link connections as tuples of e.g. 

        SNPa             SNPz
-----------------------------------
- port Ai/trib T1 - port Zj/trib Ta	(STS1 link connection #1)
- port Ai/trib T2 - port Zj/trib Tb	(STS1 link connection #2)
- port Ai/trib T3 - port Zj/trib Tc	(STS1 link connection #3)
- port Ai/trib T4 - port Zj/trib Td	(STS1 link connection #4)
- port Ai/trib T5 - port Zj/trib Te	(STS1 link connection #5)

As both ends of the link build up this same relation information, it is
possible
to use as link connection identifier only one of the two SNPs. E.g. node A
identifies the STS1 link connection #1 by means of "Ai/T1" and sends this
info
to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta".
Vice
versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when
received
by node A, this will be converted into Ai/T1.

For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
both ends of the link connection, only the timeslot at the sending end. The
receiving end needs to convert this then into its local timeslot number.

Regards,

Maarten

Yanhe Fan wrote:
> 
> Hi Zhi,
> 
> What B does is breaking the label association between A and C by crossing
> connect
> the time slots.
> 
> If the cross connect performed by B is fixed (in your case), what needs to
> do is
> just to rebuild the label association by configuration or a protocol such
as
> LMP;
> If the cross connect is not fixed but dynamic, the best thing to do is to
> make B
> a GMPLS speaker.

Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
network... no chance... those will stay non-switched...

You maybe miss "If the cross connect is NOT fixed BUT dynamic" and please
see the above respond.

> 
> Yanhe
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 6:01 PM
> To: Yanhe Fan
> Cc: John Drake; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ...
> 
> Hi Yanhe,
> 
> Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> is simply part of the network that made up the "dumb" pipe. And because
> the control plane control channel is separate, A and C can be adjacent
> without ever knowing who B is or that even B existed. From A and C's
> point of view, the network looks like:
> 
>   A ----- C
> 
> Think of the case of how a BGP sees an area. If an area is made up of:
> 
>   A -- B -- C
> 
> and B is internal router, does BGP "see" B?
> 
> Zhi
> 
> Yanhe Fan wrote:
> 
> > Hi, Zhi
> >
> >
> >>For the label value for SONET/SDH or the label description in the
> >>generic draft, the label is defined as directly representing the
> >>"timeslot". Now if I have a control plane controlled transport network
> >>that goes through a ADM that is not control plane controlled, as:
> >>
> >>
> >>+--------+               +--------+               +--------+
> >>|        | ---1--------- |        | ----1-------- |        |
> >>|        | ---2--------- |        | ----2-------- |        |
> >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> >>|        | ---4--------- |        | ----4-------- |        |
> >>|        | ---5--------- |        | ----5-------- |        |
> >>+--------+               +--------+               +--------+
> >>
> >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> >>has labels 1,2,3,4,5 incoming.
> >>
> >>Now imagine that at B, it actually has a fixed cross-connect that
> >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> >>
> >>Now when A GMPLS sends a message to C, the label it uses is "1".
> >>However, the connection/LSP associated with timeslot "1" is actually the
> >>label of timeslot "2" at C. </z>
> >>
> >
> > In this case, you're trying to use GMPLS to setup an LSP cross a node
(B)
> > which can't understand GMPLS.
> >
> > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > GMPLS if B can't understand GMPLS?
> >
> > Now imagine A and B are LSRs, and B is a conventional router (can't
> > understand
> > MPLS), can you setup an LSP A-B-C?
> >
> > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > understand PNNI at all?
> >
> > My point is that in order to make you case work, some additional work
need
> > to
> > be done besie simply using GMPLS as singnaling protocol, becase some
node
> on
> > the path is not GMPLS speakers. A and C needs the info of time slot
> aligment
> >
> > between them. This can be done by some configurations, some link
> management
> > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > eveything
> > works fine.
> >
> > Yanhe
> >

Delivery-date: Mon, 22 Oct 2001 15:34:43 -0700
Date: Tue, 23 Oct 2001 00:32:35 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Ewart Tempest <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

This is a multi-part message in MIME format.
--------------3676A15E4158D2233563CF17
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Ewart,

As we speak as individual (or groups of individuals) here i would 
rephrase your first sentence as "i think support of ..." the 
importance of the support of FC doesn't depend on your private 
affiliation. Also if FC is included we would have to update the
Bandwidth values as well.

Concerning your question i think you have responded by yourself to
it; please check section 3.1.2 of GMPLS-SIG and 2.1.2 of Generalized 
RSVP-TE (a mention could be considered). 

Regards,
Dimitri.

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

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------3676A15E4158D2233563CF17--

Delivery-date: Mon, 22 Oct 2001 15:13:37 -0700
Date: Mon, 22 Oct 2001 15:11:37 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, Yangguang Xu <[email-masked]>, [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Hi Zhi:

draft-ietf-ccamp-gmpls-architecture-00.txt provides some of the
information you may be looking for...

Cheers,

sudheer

Zhi-Wei Lin wrote:

> Hi Yakov,
>
> Thanks for your response. Very informative. Can I ask how an uninformed
> reader get to become informed if the docs in question cannot give the
> info (and I'm assuming there are no textbooks or university courses to
> take)...?
>
> As for the response from Eric, thanks for that info. Can I also ask for
> an uninformed implementor how exactly they go about getting informed?
> Any pointers or documents that you can point to?
>
> Zhi
>
> Yakov Rekhter wrote:
>
> > Zhi-Wei,
> >
> >
> >>Just to be clear, I am definitely one of the uninformed readers since I
> >>have joined IETF not so long ago (not everyone is part of IETF when it
> >>first started unfortunately). So Yakov, if you would be so kind as to
> >>inform an uninformed reader that would be very very much appreciated.
> >>
> >
> > There are few points I'd like to make to an uninformed reader:
> >
> > 1. As was pointed the other day by Dimitri Papadimitriou,
> > GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG".
> >
> > 2. As was also pointed out in the same e-mail from Dimitri,
> > "we can not wait until everybody in this world has no question anymore
> > or a full understanding on any technical detail in order to go forward".
> >
> > 3. Finally, please read the attached e-mail from Eric Gray to your
> > collegue from Lucent.
> >
> > Yakov.
> > -------------------------------------------------------------------------
> > Date:    Fri, 19 Oct 2001 15:38:58 EDT
> > To:      Yangguang Xu <[email-masked]>
> > cc:      Yakov Rekhter <[email-masked]>
> > From:    Eric Gray <[email-masked]>
> > Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
> >
> > Yangguang,
> >
> >     Careful, don't let this discussion descend into the nether regions of
> > name calling and finger pointing. :-)
> >
> >     The fact that the seeming remote neighbors use RSVP Hello is clear
> > once you realize that - for the purposes of hierarchical LSP setup, they
> > are adjacent.  You may recall this from an off-line discussion we had.
> >
> >     Yakov's comment was simply stating that it is not a part of standard's
> > development to make an implementer's cook-book.  He was not (I think)
> > trying to imply that you could not write your own implementation.  He was
> > just saying that the effort of achieving interoperability falls on the people
> > doing the implementation not on the people doing the standard.  The bare
> > information is there, but the work is up to you.
> >
> >     As you know, the standard is not complete until several implementations
> > have achieved interoperability independently.  But the opportunity to get in
> > the market stems from being one of those implementations - and there is
> > zero motivation for any implementer to make this task easy for all others.
> > One of the costs associated with the 'running code' part of IETF mistique
> > is that standards are written by implementers.
> >
> >     Unless and until that changes, you just have to learn to deal with it.  :-)
> >
> > You wrote:
> >
> >
> >>Indeed, you didn't answer my questions. Instead of informed readers, more
> >>important is to have better informed writers.
> >>
> >>BTW, I have no intention to let you design my product at all.
> >>
> >>Yangguang
> >>
> >>Yakov Rekhter wrote:
> >>
> >>>Yangguang,
> >>>
> >>>
> >>>>Yakov,
> >>>>
> >>>>Further questions in-line. Regards,
> >>>>
> >>>Further responses in-line...
> >>>
> >>>
> >>>>Yangguang
> >>>>
> >>>>
> >>>>>Couple of points:
> >>>>>
> >>>>>(1) First of all, you do run RSVP Hello between C and F.
> >>>>>
> >>>>Is this specified somewhere? Or it's your proposal.
> >>>>
> >>>What I mentioned in the above should be abundantly obvious to the
> >>>informed reader of RSVP and LSP Hierarchy specs.
> >>>
> >>>
> >>>>Then, is there a scalability issue here?
> >>>>
> >>>No.
> >>>
> >>>
> >>>>Also, C and F could be thousands mile away (in the transport
> >>>>network) and the control channel bandwidth is expensive.
> >>>>
> >>>GMPLS assumes that control channel is more than just 56Kbits/sec link.
> >>>
> >>>Or to put it differently, control channels used by GMPLS have more than
> >>>enough capacity for RSVP Hellos.
> >>>
> >>>
> >>>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> >>>>>be able to recover the Interface ID it assigns to L1 from
> >>>>>a combination of (a) the OSPF/ISIS link state database that
> >>>>>F would recover, and (b) the Forward Interface ID (the one
> >>>>>assigned by C).
> >>>>>
> >>>>Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
> >>>>
> > n it
> >
> >>>>has to recover its FA info first. How?
> >>>>
> >>>The answer should be abundantly obvious to the informed reader.
> >>>
> >>>And to make it crystal clear, I have no intention in designing your
> >>>products for you.
> >>>
> >>>
> >>>>>>Let us say the node can resynchronize its neighbor if
> >>>>>>the neighbor restarts and requests state recovery. But
> >>>>>>the issue is how a node can advertise that it does not
> >>>>>>need recovery since all its state was preserved?
> >>>>>>
> >>>>>By treating is the same way as the way the spec handles
> >>>>>control channel fault.
> >>>>>
> >>>>>
> >>>>If a node can recover states from NVRAM or OS (this solution is
> >>>>cheaper and have been implemented). It may not implement the spec.
> >>>>How could a neighboring node, which implements the spec, not tear
> >>>>down data connections mistakenly? Similar to a backward compatibility
> >>>>problem, even not.
> >>>>
> >>>Stating the obvious: interoperability with a node that doesn't implement
> >>>the spec is outside the scope of the spec.
> >>>
> >>>
> >>>>>>RECOVERY LABEL does not come into picture unless the node
> >>>>>>that is upstream to the restarting node has already received
> >>>>>>a Resv.
> >>>>>>
> >>>>>Wrong. Quoting 9.5.3:
> >>>>>
> >>>>>   Upon detecting a restart with a neighbor that supports state
> >>>>>   recovery, a node SHOULD refresh all Path state shared with that
> >>>>>   neighbor.
> >>>>>
> >>>>>So, as you can hopefully see from the above, the upstream node doesn't
> >>>>>wait until it receives a Resv.
> >>>>>
> >>>>>
> >>>>Then this may not meet carriers' requirement. (see IPO carriers' requirem
> >>>>
> > ent)
> >
> >>>>Again, back to the telecom world (sorry about this, yet we are talking ab
> >>>>
> > out
> >
> >>>>GMPLS), typically only the established pathes are preserved. Pending requ
> >>>>
> > ests
> >
> >>>>may be purged/aborted. Then how?
> >>>>
> >>>Note the verb is "SHOULD", not "MUST". The rest should be
> >>>obvious to the informed reader.
> >>>
> >>>
> >>>>>>In case of PSC devices, it may be OK to remove state that
> >>>>>>is not resynchronized at the end of the recovery period,
> >>>>>>and the recovery period advertised might reflect that.
> >>>>>>But for LSPs in transport networks, one might want to
> >>>>>>have a different recovery period to avoid any LSP from
> >>>>>>going down because of recovery timer expiry.
> >>>>>>
> >>>>>There is no requirement for a node to advertise exactly the
> >>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces
> >>>>>the node could advertise that it will remove the state that
> >>>>>isn't syncronized at the end of the recovery period, while
> >>>>>on the TDM interface precisely the same node could advertise
> >>>>>that the LSPs would be kept even after the recovery time expires.
> >>>>>
> >>>>>
> >>>>So, restart_cap is per interface based?
> >>>>
> >>>yes.
> >>>
> >>>
> >>>>Is the spec going to be enhanced/clarified?
> >>>>
> >>>The current spec need not be enhanced/clarified - what I mentioned in the
> >>>above should be abundantly obvious to the informed reader.
> >>>
> >>>
> >>>>>>The first problems seems to be there still - consider two
> >>>>>>adjacent nodes restarting.  They both act both as the restarting
> >>>>>>node as well as the neighbor to the restarting node. So, once
> >>>>>>they learn the state from the upstream neighbor, do they use
> >>>>>>suggested label or the recovery label when they send the path
> >>>>>>message to the just restarted downstream neighbor?
> >>>>>>
> >>>>>The recovery label.
> >>>>>
> >>>>>The following should be added to the existing text from the document:
> >>>>>
> >>>>>   In the special case where a restarting node also has a restating
> >>>>>   downstream neighbor, a Recovery_Label object should be used instead
> >>>>>   of a Suggested_Label object.
> >>>>>
> >>>>How does a recovering NE know that its neighbor is also recovering? it ma
> >>>>
> > y
> >
> >>>>lose the instance number totally
> >>>>
> >>>It's advertised in the neighbor's hellos.
> >>>
> >>>Yakov.
> >>>
> >
> > --
> > Eric Gray (mailto:[email-masked])
> > http://www.mindspring.com/~ewgray
> >
> >
> >
> >

Delivery-date: Mon, 22 Oct 2001 15:01:49 -0700
From: "Ewart Tempest" <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>
Cc: [email-masked], [email-masked], "Ewart Tempest" <[email-masked]>
Subject: RE: Generalized Signaling - LSP Encoding Type expansion
Date: Mon, 22 Oct 2001 17:58:57 -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_01C15B44.BF6E1190
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,

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

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

Ewart

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Generalized Signaling - LSP Encoding Type expansion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dimitri,</FONT>
</P>

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

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

<P><FONT SIZE=3D2>Ewart</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15B44.BF6E1190--

Delivery-date: Mon, 22 Oct 2001 14:43:50 -0700
Date: Mon, 22 Oct 2001 17:42:29 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Yakov Rekhter <[email-masked]>
CC: Yangguang Xu <[email-masked]>, [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Hi Yakov,

Thanks for your response. Very informative. Can I ask how an uninformed 
reader get to become informed if the docs in question cannot give the 
info (and I'm assuming there are no textbooks or university courses to 
take)...?

As for the response from Eric, thanks for that info. Can I also ask for 
an uninformed implementor how exactly they go about getting informed? 
Any pointers or documents that you can point to?

Zhi

Yakov Rekhter wrote:

> Zhi-Wei,
> 
> 
>>Just to be clear, I am definitely one of the uninformed readers since I 
>>have joined IETF not so long ago (not everyone is part of IETF when it 
>>first started unfortunately). So Yakov, if you would be so kind as to 
>>inform an uninformed reader that would be very very much appreciated.
>>
> 
> There are few points I'd like to make to an uninformed reader:
> 
> 1. As was pointed the other day by Dimitri Papadimitriou,
> GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG".
> 
> 2. As was also pointed out in the same e-mail from Dimitri,
> "we can not wait until everybody in this world has no question anymore 
> or a full understanding on any technical detail in order to go forward".
> 
> 3. Finally, please read the attached e-mail from Eric Gray to your 
> collegue from Lucent.
> 
> Yakov.
> -------------------------------------------------------------------------
> Date:    Fri, 19 Oct 2001 15:38:58 EDT
> To:      Yangguang Xu <[email-masked]>
> cc:      Yakov Rekhter <[email-masked]>
> From:    Eric Gray <[email-masked]>
> Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
> 
> Yangguang,
> 
>     Careful, don't let this discussion descend into the nether regions of
> name calling and finger pointing. :-)
> 
>     The fact that the seeming remote neighbors use RSVP Hello is clear
> once you realize that - for the purposes of hierarchical LSP setup, they
> are adjacent.  You may recall this from an off-line discussion we had.
> 
>     Yakov's comment was simply stating that it is not a part of standard's
> development to make an implementer's cook-book.  He was not (I think)
> trying to imply that you could not write your own implementation.  He was
> just saying that the effort of achieving interoperability falls on the people
> doing the implementation not on the people doing the standard.  The bare
> information is there, but the work is up to you.
> 
>     As you know, the standard is not complete until several implementations
> have achieved interoperability independently.  But the opportunity to get in
> the market stems from being one of those implementations - and there is
> zero motivation for any implementer to make this task easy for all others.
> One of the costs associated with the 'running code' part of IETF mistique
> is that standards are written by implementers.
> 
>     Unless and until that changes, you just have to learn to deal with it.  :-)
> 
> You wrote:
> 
> 
>>Indeed, you didn't answer my questions. Instead of informed readers, more
>>important is to have better informed writers.
>>
>>BTW, I have no intention to let you design my product at all.
>>
>>Yangguang
>>
>>Yakov Rekhter wrote:
>>
>>>Yangguang,
>>>
>>>
>>>>Yakov,
>>>>
>>>>Further questions in-line. Regards,
>>>>
>>>Further responses in-line...
>>>
>>>
>>>>Yangguang
>>>>
>>>>
>>>>>Couple of points:
>>>>>
>>>>>(1) First of all, you do run RSVP Hello between C and F.
>>>>>
>>>>Is this specified somewhere? Or it's your proposal.
>>>>
>>>What I mentioned in the above should be abundantly obvious to the
>>>informed reader of RSVP and LSP Hierarchy specs.
>>>
>>>
>>>>Then, is there a scalability issue here?
>>>>
>>>No.
>>>
>>>
>>>>Also, C and F could be thousands mile away (in the transport
>>>>network) and the control channel bandwidth is expensive.
>>>>
>>>GMPLS assumes that control channel is more than just 56Kbits/sec link.
>>>
>>>Or to put it differently, control channels used by GMPLS have more than
>>>enough capacity for RSVP Hellos.
>>>
>>>
>>>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
>>>>>be able to recover the Interface ID it assigns to L1 from
>>>>>a combination of (a) the OSPF/ISIS link state database that
>>>>>F would recover, and (b) the Forward Interface ID (the one
>>>>>assigned by C).
>>>>>
>>>>Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
>>>>
> n it
> 
>>>>has to recover its FA info first. How?
>>>>
>>>The answer should be abundantly obvious to the informed reader.
>>>
>>>And to make it crystal clear, I have no intention in designing your
>>>products for you.
>>>
>>>
>>>>>>Let us say the node can resynchronize its neighbor if
>>>>>>the neighbor restarts and requests state recovery. But
>>>>>>the issue is how a node can advertise that it does not
>>>>>>need recovery since all its state was preserved?
>>>>>>
>>>>>By treating is the same way as the way the spec handles
>>>>>control channel fault.
>>>>>
>>>>>
>>>>If a node can recover states from NVRAM or OS (this solution is
>>>>cheaper and have been implemented). It may not implement the spec.
>>>>How could a neighboring node, which implements the spec, not tear
>>>>down data connections mistakenly? Similar to a backward compatibility
>>>>problem, even not.
>>>>
>>>Stating the obvious: interoperability with a node that doesn't implement
>>>the spec is outside the scope of the spec.
>>>
>>>
>>>>>>RECOVERY LABEL does not come into picture unless the node
>>>>>>that is upstream to the restarting node has already received
>>>>>>a Resv.
>>>>>>
>>>>>Wrong. Quoting 9.5.3:
>>>>>
>>>>>   Upon detecting a restart with a neighbor that supports state
>>>>>   recovery, a node SHOULD refresh all Path state shared with that
>>>>>   neighbor.
>>>>>
>>>>>So, as you can hopefully see from the above, the upstream node doesn't
>>>>>wait until it receives a Resv.
>>>>>
>>>>>
>>>>Then this may not meet carriers' requirement. (see IPO carriers' requirem
>>>>
> ent)
> 
>>>>Again, back to the telecom world (sorry about this, yet we are talking ab
>>>>
> out
> 
>>>>GMPLS), typically only the established pathes are preserved. Pending requ
>>>>
> ests
> 
>>>>may be purged/aborted. Then how?
>>>>
>>>Note the verb is "SHOULD", not "MUST". The rest should be
>>>obvious to the informed reader.
>>>
>>>
>>>>>>In case of PSC devices, it may be OK to remove state that
>>>>>>is not resynchronized at the end of the recovery period,
>>>>>>and the recovery period advertised might reflect that.
>>>>>>But for LSPs in transport networks, one might want to
>>>>>>have a different recovery period to avoid any LSP from
>>>>>>going down because of recovery timer expiry.
>>>>>>
>>>>>There is no requirement for a node to advertise exactly the
>>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces
>>>>>the node could advertise that it will remove the state that
>>>>>isn't syncronized at the end of the recovery period, while
>>>>>on the TDM interface precisely the same node could advertise
>>>>>that the LSPs would be kept even after the recovery time expires.
>>>>>
>>>>>
>>>>So, restart_cap is per interface based?
>>>>
>>>yes.
>>>
>>>
>>>>Is the spec going to be enhanced/clarified?
>>>>
>>>The current spec need not be enhanced/clarified - what I mentioned in the
>>>above should be abundantly obvious to the informed reader.
>>>
>>>
>>>>>>The first problems seems to be there still - consider two
>>>>>>adjacent nodes restarting.  They both act both as the restarting
>>>>>>node as well as the neighbor to the restarting node. So, once
>>>>>>they learn the state from the upstream neighbor, do they use
>>>>>>suggested label or the recovery label when they send the path
>>>>>>message to the just restarted downstream neighbor?
>>>>>>
>>>>>The recovery label.
>>>>>
>>>>>The following should be added to the existing text from the document:
>>>>>
>>>>>   In the special case where a restarting node also has a restating
>>>>>   downstream neighbor, a Recovery_Label object should be used instead
>>>>>   of a Suggested_Label object.
>>>>>
>>>>How does a recovering NE know that its neighbor is also recovering? it ma
>>>>
> y
> 
>>>>lose the instance number totally
>>>>
>>>It's advertised in the neighbor's hellos.
>>>
>>>Yakov.
>>>
> 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 
> 

Delivery-date: Mon, 22 Oct 2001 14:09:03 -0700
Cc: "'Zhi-Wei Lin'" <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Mon, 22 Oct 2001 23:06:45 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Yanhe Fan <[email-masked]>
Original-CC: "'Zhi-Wei Lin'" <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------C13950118C107088CF25213B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yanhe,

The situation Zhi describes is one that will be very typical in the optical
(SDH/SONET) network in the coming years. We will most likely see islands of
switched subnetworks interconnected via the existing SDH/SONET non-switched
networks. By means of management actions, links (GMPLS: link bundles) will be
setup between an edge node in one switched subnetwork and an other edge node in
the next switched subnetwork. In G.805 terminology, these links are so called
serial compound links.

The switched subnetworks will treat these serial compound links as normal links,
"ignoring" the intermediate non-switched nodes they traverse. These links will
contain a fixed set of link connections, which are identified by their
respective endpoints at nodes A and Z (i.e. SNPa - SNPz).
The server signal that carries the e.g. 5 STS1 link connections in the link at A
can be an OC12, whereas this can be an OC48 at Z.

During discovery or by means of provisioning both A and Z nodes get aware of the
5 sTS1 link connections as tuples of e.g. 

        SNPa             SNPz
-----------------------------------
- port Ai/trib T1 - port Zj/trib Ta	(STS1 link connection #1)
- port Ai/trib T2 - port Zj/trib Tb	(STS1 link connection #2)
- port Ai/trib T3 - port Zj/trib Tc	(STS1 link connection #3)
- port Ai/trib T4 - port Zj/trib Td	(STS1 link connection #4)
- port Ai/trib T5 - port Zj/trib Te	(STS1 link connection #5)

As both ends of the link build up this same relation information, it is possible
to use as link connection identifier only one of the two SNPs. E.g. node A
identifies the STS1 link connection #1 by means of "Ai/T1" and sends this info
to node Z. Node Z receiving this Ai/T1 converts this locally into "Zj/Ta". Vice
versa, node Z will refer to STS1 link connection #1 as "Zj/Ta" and when received
by node A, this will be converted into Ai/T1.

For GMPLS this implies that the GMPLS label doesn't identify the timeslot at
both ends of the link connection, only the timeslot at the sending end. The
receiving end needs to convert this then into its local timeslot number.

Regards,

Maarten

Yanhe Fan wrote:
> 
> Hi Zhi,
> 
> What B does is breaking the label association between A and C by crossing
> connect
> the time slots.
> 
> If the cross connect performed by B is fixed (in your case), what needs to
> do is
> just to rebuild the label association by configuration or a protocol such as
> LMP;
> If the cross connect is not fixed but dynamic, the best thing to do is to
> make B
> a GMPLS speaker.

Tell this to the 1.000.000+ SDH/SONET network elements in today's transport
network... no chance... those will stay non-switched...

> 
> Yanhe
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 6:01 PM
> To: Yanhe Fan
> Cc: John Drake; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ...
> 
> Hi Yanhe,
> 
> Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> is simply part of the network that made up the "dumb" pipe. And because
> the control plane control channel is separate, A and C can be adjacent
> without ever knowing who B is or that even B existed. From A and C's
> point of view, the network looks like:
> 
>   A ----- C
> 
> Think of the case of how a BGP sees an area. If an area is made up of:
> 
>   A -- B -- C
> 
> and B is internal router, does BGP "see" B?
> 
> Zhi
> 
> Yanhe Fan wrote:
> 
> > Hi, Zhi
> >
> >
> >>For the label value for SONET/SDH or the label description in the
> >>generic draft, the label is defined as directly representing the
> >>"timeslot". Now if I have a control plane controlled transport network
> >>that goes through a ADM that is not control plane controlled, as:
> >>
> >>
> >>+--------+               +--------+               +--------+
> >>|        | ---1--------- |        | ----1-------- |        |
> >>|        | ---2--------- |        | ----2-------- |        |
> >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> >>|        | ---4--------- |        | ----4-------- |        |
> >>|        | ---5--------- |        | ----5-------- |        |
> >>+--------+               +--------+               +--------+
> >>
> >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> >>has labels 1,2,3,4,5 incoming.
> >>
> >>Now imagine that at B, it actually has a fixed cross-connect that
> >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> >>
> >>Now when A GMPLS sends a message to C, the label it uses is "1".
> >>However, the connection/LSP associated with timeslot "1" is actually the
> >>label of timeslot "2" at C. </z>
> >>
> >
> > In this case, you're trying to use GMPLS to setup an LSP cross a node (B)
> > which can't understand GMPLS.
> >
> > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > GMPLS if B can't understand GMPLS?
> >
> > Now imagine A and B are LSRs, and B is a conventional router (can't
> > understand
> > MPLS), can you setup an LSP A-B-C?
> >
> > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > understand PNNI at all?
> >
> > My point is that in order to make you case work, some additional work need
> > to
> > be done besie simply using GMPLS as singnaling protocol, becase some node
> on
> > the path is not GMPLS speakers. A and C needs the info of time slot
> aligment
> >
> > between them. This can be done by some configurations, some link
> management
> > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > eveything
> > works fine.
> >
> > Yanhe
> >
--------------C13950118C107088CF25213B
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------C13950118C107088CF25213B--

Delivery-date: Mon, 22 Oct 2001 13:16:22 -0700
To: "Lazer, Monica A, NNAD" <[email-masked]>
cc: [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion 
Date: Mon, 22 Oct 2001 13:12:11 -0700
From: Yakov Rekhter <[email-masked]>

Monica,

> Dimitri,
> Actually, it may be more accurate to put it differently - if GMPLS supports
> only a handful of the services running on a given transport network, than
> its value as a network's control plane component is diminished. 

To be even more accurate, GMPLS value is diminished *in the context*
of that particular transport network. And unless *all* providers
are going to run *all possible services* on their transport networks
(which is a somewhat unrealistic scenario), that means that the
value of GMPLS as a network's control plane component would be
diminished for *some*, but not *all* service providers.

At the same time, it is important to keep in mind that being "all
things for all people" (aka as "perfect solution") is one of the
*non-goals* of GMPLS. So, it shouldn't come as a surprise if for a
*particular* provider GMPLS would *not* support *all* the services
that this provider runs on its transport network.

Yakov.

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

Delivery-date: Mon, 22 Oct 2001 12:54:51 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>
Cc: Ewart Tempest <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion
Date: Mon, 22 Oct 2001 15:51:47 -0400

Dimitri,
Actually, it may be more accurate to put it differently - if GMPLS supports
only a handful of the services running on a given transport network, than
its value as a network's control plane component is diminished. 

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Dimitri Papadimitriou [mailto:[email-masked]] 
Sent:	Monday, October 22, 2001 3:15 PM
To:	Lazer, Monica A, NNAD
Cc:	Ewart Tempest; [email-masked]; [email-masked]
Subject:	Re: Generalized Signaling - LSP Encoding Type expansion

 << File: Card for Dimitri Papadimitriou >> Hi Monica,

Fine. Now we know the following: GMPLS is really attractive for 
carriers when it supports all transport technologies so it has 
to support Fiber Channel as well.

I wasn't aware that Ewart was capable to read in your mind ;-)

Regards,
Dimitri.

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

Delivery-date: Mon, 22 Oct 2001 12:18:30 -0700
Date: Mon, 22 Oct 2001 21:15:07 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: "Lazer, Monica A, NNAD" <[email-masked]>
CC: Ewart Tempest <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

This is a multi-part message in MIME format.
--------------51CD3388782DA225F085F3F9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Monica,

Fine. Now we know the following: GMPLS is really attractive for 
carriers when it supports all transport technologies so it has 
to support Fiber Channel as well.

I wasn't aware that Ewart was capable to read in your mind ;-)

Regards,
Dimitri.

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

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------51CD3388782DA225F085F3F9--

Delivery-date: Mon, 22 Oct 2001 12:03:19 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>, Ewart Tempest <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Generalized Signaling - LSP Encoding Type expansion
Date: Mon, 22 Oct 2001 15:02:25 -0400

Dimitri,
I am just answering the PS question with this message.
The short answer is yes.  The long answer is that the GMPLS control plane is
really useful if it can support connection management for all the transport
services supported by the transport network using GMPLS. Therefore, the
carrier services section for the NNI document to be posted on the OIF site
within a few minutes and the next draft of the carrier requirements IETF
draft will both contain references to support of Fiber Channel.
Regards,
Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Dimitri Papadimitriou [mailto:[email-masked]] 
Sent:	Monday, October 22, 2001 2:47 PM
To:	Ewart Tempest
Cc:	[email-masked]; [email-masked]
Subject:	Re: Generalized Signaling - LSP Encoding Type expansion

 << File: Card for Dimitri Papadimitriou >> Hi Ewart,

If you take a look on the IEEE Standards you will see 
that GE is referred to as 
- 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab
- 802.3ae for 10Gbps (see below [2])

So my question is what do you have in mind ? to separate
these values ?

Thanks,
Dimitri.

PS: for FiberChannel sorry i am not an expert but is someone
    targeting to use GMPLS for FiberChannel LSP ?

-------

[1] From - http://standards.ieee.org

Project scope: Define Carrier Sense Multiple Access with Collision 
Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal 
augmentation of its operation, physical layer characteristics, repeater 
functions and management parameters for transfer of 802.3 and Ethernet 
format frames at 1,000 Mb/s. 

Project purpose: The purpose of this project is to extend the 802.3 
protocol to an operating speed of 1,000 Mb/s in order to provide a 
significant increase in bandwidth while maintaining maximum
compatibility 
with the installed base of CSMA/CD nodes, previous investment in
research 
and development, and principles of network operation and management. 

[2] From - http://standards.ieee.org

Project scope: Define 802.3 Media Access Control (MAC) parameters and 
minimal augmentation of its operation, physical layer characteristics 
and management parameters for transfer of LLC and Ethernet format 
frames at 10 Gb/s using full duplex operation as defined in the 802.3 
standard. In addition to the traditional LAN space, add parameters and 
mechanisms that enable deployment of Ethernet over the Wide Area Network 
operating at a data rate compatible with OC-192c and SDH VC-4-64c
payload 
rate. 

Project purpose: The purpose of this project is to extend the 802.3 
protocol to an operating speed of 10 Gb/s and to expand the Ethernet 
application space to include Wide Area Network links in order to provide 
a significant increase in bandwidth while maintaining maximum
compatibility 
with the installed base of 802.3 interfaces, previous investment in
research 
and development, and principles of network operation and management.

-------

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

Delivery-date: Mon, 22 Oct 2001 11:54:49 -0700
Date: Mon, 22 Oct 2001 20:46:56 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Ewart Tempest <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Generalized Signaling - LSP Encoding Type expansion

This is a multi-part message in MIME format.
--------------E0956412F0390207C3F4403D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Ewart,

If you take a look on the IEEE Standards you will see 
that GE is referred to as 
- 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab
- 802.3ae for 10Gbps (see below [2])

So my question is what do you have in mind ? to separate
these values ?

Thanks,
Dimitri.

PS: for FiberChannel sorry i am not an expert but is someone
    targeting to use GMPLS for FiberChannel LSP ?

-------

[1] From - http://standards.ieee.org

Project scope: Define Carrier Sense Multiple Access with Collision 
Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal 
augmentation of its operation, physical layer characteristics, repeater 
functions and management parameters for transfer of 802.3 and Ethernet 
format frames at 1,000 Mb/s. 

Project purpose: The purpose of this project is to extend the 802.3 
protocol to an operating speed of 1,000 Mb/s in order to provide a 
significant increase in bandwidth while maintaining maximum
compatibility 
with the installed base of CSMA/CD nodes, previous investment in
research 
and development, and principles of network operation and management. 

[2] From - http://standards.ieee.org

Project scope: Define 802.3 Media Access Control (MAC) parameters and 
minimal augmentation of its operation, physical layer characteristics 
and management parameters for transfer of LLC and Ethernet format 
frames at 10 Gb/s using full duplex operation as defined in the 802.3 
standard. In addition to the traditional LAN space, add parameters and 
mechanisms that enable deployment of Ethernet over the Wide Area Network 
operating at a data rate compatible with OC-192c and SDH VC-4-64c
payload 
rate. 

Project purpose: The purpose of this project is to extend the 802.3 
protocol to an operating speed of 10 Gb/s and to expand the Ethernet 
application space to include Wide Area Network links in order to provide 
a significant increase in bandwidth while maintaining maximum
compatibility 
with the installed base of 802.3 interfaces, previous investment in
research 
and development, and principles of network operation and management.

-------

> Ewart Tempest wrote:
> 
> Lou,
> 
> Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can
> you please add additonal LSP Encoding Types for GE and FiberChannel.
> GE is not really covered by the existing Ethernet related encoding
> types, and FiberChannel is not covered at all. Thanks.
> 
> Ewart
--------------E0956412F0390207C3F4403D
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------E0956412F0390207C3F4403D--

Delivery-date: Mon, 22 Oct 2001 11:13:49 -0700
From: "Ewart Tempest" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Ewart Tempest" <[email-masked]>
Subject: Generalized Signaling - LSP Encoding Type expansion
Date: Mon, 22 Oct 2001 14:11:28 -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_01C15B24.F7F93820
Content-Type: text/plain;
	charset="iso-8859-1"

Lou,

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

Ewart

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Generalized Signaling - LSP Encoding Type expansion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Lou,</FONT>
</P>

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

<P><FONT SIZE=3D2>Ewart</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15B24.F7F93820--

Envelope-to: [email-masked]
Delivery-date: Mon, 22 Oct 2001 10:54:33 -0700
Message-Id: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Generalized Signaling - Underspecification of Switching Type
Date: Mon, 22 Oct 2001 13:51:33 -0400
From: George Swallow <[email-masked]>

Lou -

The definition of the Switching Type field of the Generalized label
does not specify the scope over which it operates.  It is my
understanding that for a given LSP it does not change, but is carried
end-to-end and applies at all intermediate hops along the path.

The Label Request Object is a hop by hop object.  Further the
description of the Switching Type includes the phrase "on a
particular link", further implying that it may not be constant.
(As an aside, I don't like the phrase anyway since I think of
Switching Type applying mainly to the node at the end of the link ;-)

I think some clarifying text is in order.

Thanks,

...George

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Mon, 22 Oct 2001 10:51:45 -0700
To: Zhi-Wei Lin <[email-masked]>
cc: Yangguang Xu <[email-masked]>, [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) 
Date: Mon, 22 Oct 2001 10:45:11 -0700
From: Yakov Rekhter <[email-masked]>

Zhi-Wei,

> Just to be clear, I am definitely one of the uninformed readers since I 
> have joined IETF not so long ago (not everyone is part of IETF when it 
> first started unfortunately). So Yakov, if you would be so kind as to 
> inform an uninformed reader that would be very very much appreciated.

There are few points I'd like to make to an uninformed reader:

1. As was pointed the other day by Dimitri Papadimitriou,
GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG".

2. As was also pointed out in the same e-mail from Dimitri,
"we can not wait until everybody in this world has no question anymore 
or a full understanding on any technical detail in order to go forward".

3. Finally, please read the attached e-mail from Eric Gray to your 
collegue from Lucent.

Yakov.
-------------------------------------------------------------------------
Date:    Fri, 19 Oct 2001 15:38:58 EDT
To:      Yangguang Xu <[email-masked]>
cc:      Yakov Rekhter <[email-masked]>
From:    Eric Gray <[email-masked]>
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Yangguang,

    Careful, don't let this discussion descend into the nether regions of
name calling and finger pointing. :-)

    The fact that the seeming remote neighbors use RSVP Hello is clear
once you realize that - for the purposes of hierarchical LSP setup, they
are adjacent.  You may recall this from an off-line discussion we had.

    Yakov's comment was simply stating that it is not a part of standard's
development to make an implementer's cook-book.  He was not (I think)
trying to imply that you could not write your own implementation.  He was
just saying that the effort of achieving interoperability falls on the people
doing the implementation not on the people doing the standard.  The bare
information is there, but the work is up to you.

    As you know, the standard is not complete until several implementations
have achieved interoperability independently.  But the opportunity to get in
the market stems from being one of those implementations - and there is
zero motivation for any implementer to make this task easy for all others.
One of the costs associated with the 'running code' part of IETF mistique
is that standards are written by implementers.

    Unless and until that changes, you just have to learn to deal with it.  :-)

You wrote:

> Indeed, you didn't answer my questions. Instead of informed readers, more
> important is to have better informed writers.
>
> BTW, I have no intention to let you design my product at all.
>
> Yangguang
>
> Yakov Rekhter wrote:
> >
> > Yangguang,
> >
> > > Yakov,
> > >
> > > Further questions in-line. Regards,
> >
> > Further responses in-line...
> >
> > > Yangguang
> > >
> > > > Couple of points:
> > > >
> > > > (1) First of all, you do run RSVP Hello between C and F.
> > >
> > > Is this specified somewhere? Or it's your proposal.
> >
> > What I mentioned in the above should be abundantly obvious to the
> > informed reader of RSVP and LSP Hierarchy specs.
> >
> > > Then, is there a scalability issue here?
> >
> > No.
> >
> > > Also, C and F could be thousands mile away (in the transport
> > > network) and the control channel bandwidth is expensive.
> >
> > GMPLS assumes that control channel is more than just 56Kbits/sec link.
> >
> > Or to put it differently, control channels used by GMPLS have more than
> > enough capacity for RSVP Hellos.
> >
> > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > > > be able to recover the Interface ID it assigns to L1 from
> > > > a combination of (a) the OSPF/ISIS link state database that
> > > > F would recover, and (b) the Forward Interface ID (the one
> > > > assigned by C).
> > >
> > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
n it
> > > has to recover its FA info first. How?
> >
> > The answer should be abundantly obvious to the informed reader.
> >
> > And to make it crystal clear, I have no intention in designing your
> > products for you.
> >
> > > > > Let us say the node can resynchronize its neighbor if
> > > > > the neighbor restarts and requests state recovery. But
> > > > > the issue is how a node can advertise that it does not
> > > > > need recovery since all its state was preserved?
> > > >
> > > > By treating is the same way as the way the spec handles
> > > > control channel fault.
> > > >
> > >
> > > If a node can recover states from NVRAM or OS (this solution is
> > > cheaper and have been implemented). It may not implement the spec.
> > > How could a neighboring node, which implements the spec, not tear
> > > down data connections mistakenly? Similar to a backward compatibility
> > > problem, even not.
> >
> > Stating the obvious: interoperability with a node that doesn't implement
> > the spec is outside the scope of the spec.
> >
> > > > > RECOVERY LABEL does not come into picture unless the node
> > > > > that is upstream to the restarting node has already received
> > > > > a Resv.
> > > >
> > > > Wrong. Quoting 9.5.3:
> > > >
> > > >    Upon detecting a restart with a neighbor that supports state
> > > >    recovery, a node SHOULD refresh all Path state shared with that
> > > >    neighbor.
> > > >
> > > > So, as you can hopefully see from the above, the upstream node doesn't
> > > > wait until it receives a Resv.
> > > >
> > >
> > > Then this may not meet carriers' requirement. (see IPO carriers' requirem
ent)
> > > Again, back to the telecom world (sorry about this, yet we are talking ab
out
> > > GMPLS), typically only the established pathes are preserved. Pending requ
ests
> > > may be purged/aborted. Then how?
> >
> > Note the verb is "SHOULD", not "MUST". The rest should be
> > obvious to the informed reader.
> >
> > > > > In case of PSC devices, it may be OK to remove state that
> > > > > is not resynchronized at the end of the recovery period,
> > > > > and the recovery period advertised might reflect that.
> > > > > But for LSPs in transport networks, one might want to
> > > > > have a different recovery period to avoid any LSP from
> > > > > going down because of recovery timer expiry.
> > > >
> > > > There is no requirement for a node to advertise exactly the
> > > > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > > > the node could advertise that it will remove the state that
> > > > isn't syncronized at the end of the recovery period, while
> > > > on the TDM interface precisely the same node could advertise
> > > > that the LSPs would be kept even after the recovery time expires.
> > > >
> > >
> > > So, restart_cap is per interface based?
> >
> > yes.
> >
> > > Is the spec going to be enhanced/clarified?
> >
> > The current spec need not be enhanced/clarified - what I mentioned in the
> > above should be abundantly obvious to the informed reader.
> >
> > > > > The first problems seems to be there still - consider two
> > > > > adjacent nodes restarting.  They both act both as the restarting
> > > > > node as well as the neighbor to the restarting node. So, once
> > > > > they learn the state from the upstream neighbor, do they use
> > > > > suggested label or the recovery label when they send the path
> > > > > message to the just restarted downstream neighbor?
> > > >
> > > > The recovery label.
> > > >
> > > > The following should be added to the existing text from the document:
> > > >
> > > >    In the special case where a restarting node also has a restating
> > > >    downstream neighbor, a Recovery_Label object should be used instead
> > > >    of a Suggested_Label object.
> > >
> > > How does a recovering NE know that its neighbor is also recovering? it ma
y
> > > lose the instance number totally
> >
> > It's advertised in the neighbor's hellos.
> >
> > Yakov.

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 22 Oct 2001 10:36:58 -0700
To: Gopal Kailad <[email-masked]>
cc: [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) 
Date: Mon, 22 Oct 2001 10:33:03 -0700
From: Yakov Rekhter <[email-masked]>

Gopal,

> Thanks for the clarification.  

You are welcomed !!!

> My comments are inline:

My comments are inline:

> Yakov Rekhter wrote:
> 
> >Gopal,
> >
> >>>>I have some questions/concerns on the restart mechanism as
> >>>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
> >>>>have listed them below.
> >>>>
> >>>>If a node that is terminating hierarchical LSPs restarts,
> >>>>there is an ordering issue during resynchronization, since
> >>>>the LSPs would depend on other FA-LSPs the interface IDs for
> >>>>which would have been generated dynamically. So the
> >>>>mechanism as described will not work, unless this
> >>>>information is preserved across restarts - in which case we
> >>>>might as well preserve other information as well, and avoid
> >>>>resynchronization.
> >>>>
> >>>Since transit node of the FA-LSP does not see the RSVP
> >>>messages that use the FA, we only need to consider
> >>>the ingress and egress node. If the egress node restarts,
> >>>the worst case is that its upstream node sends an ERO
> >>>consisting a unrecognized interface address. Since the
> >>>Path message will carry RECOVERY_LABEL (replacing
> >>>SUGGESTED_LABEL), the egress node knows that it might
> >>>not have complete information yet, and can hold on to
> >>>the Path message until the FA-LSP is established.
> >>>All the information is there, so implementation
> >>>can be completely within the egress node. It does work,
> >>>just not specified enough.
> >>>
> >>>Ingress node will have to know the dependency, so not
> >>>a problem there.
> >>>
> >>Are you suggesting that in case of an ERO with an
> >>unrecognized interface id, if the Path message also
> >>carries a RECOVERY LABEL, the egress node can hold on
> >>to it until later?  Note that there may not be a
> >>RECOVERY LABEL - since this Path message is for a
> >>hierarchical LSP, and the previous node may not be
> >>directly connected in the control plane.  Here is an
> >>example - There is an LSP L1 from C to F, and on top of
> >>it there is an LSP L2 from A to G.
> >>
> >> L1:              C --- D --- E --- F
> >> L2:  A --- B --- C --------------- F --- G
> >>
> >>When F restarts, C may not even know, unless HELLO
> >>protocol is run between C and F.  Note that the
> >>HELLO mechanism is intended for immediate neighbors.
> >>
> >>And even if the HELLO mechanism is extended, there
> >>is the issue of interface id assigned by F.  F needs
> >>to assign the same interface id upon restart so as
> >>not to bring down the hierarchical LSPs set up on top
> >>of L1 in 
> >>the reverse direction (say an LSP from G to
> >>B set up on top of L1.)  Where would F get this
> >>information ?
> >>
> >
> >Couple of points:
> >
> >(1) First of all, you do run RSVP Hello between C and F.
> 
> O.K.
> 
> >(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> >be able to recover the Interface ID it assigns to L1 from
> >a combination of (a) the OSPF/ISIS link state database that
> >F would recover, and (b) the Forward Interface ID (the one
> >assigned by C).
> >
> True. One could either use IGP restart mechanism to relearn
> this (I have other concerns on RSVP restart being dependent on
> IGP restart, but that for later) or preserve this across restarts.
> In either case,  you agree that RSVP restart depends on some
> mechanism outside RSVP to help it along?  So RSVP needs a new
> interface to get this mapping upon restarts, right? This is not
> clear in the draft.

Couple of points:

1. As Dimitri Papadimitriou mentioned in his other e-mail to this
list, an Internet Draft "is not a textbook on how to use GMPLS-SIG".

2. What I mentioned in the above should be abundantly obvious to the
informed reader of RSVP and LSP Hierarchy specs.

> >>>>Also, let us consider a node that can preserve state across
> >>>>restarts, and hence does not need its state to be synced by
> >>>>its peer.  How will it advertise this in the RESTART_CAP
> >>>>object?
> >>>>
> >>>We still need to resynchronize the state since the other
> >>>side might have connections that are in progress. The
> >>>
> >>Let us say the node can resynchronize its neighbor if
> >>the neighbor restarts and requests state recovery. But
> >>the issue is how a node can advertise that it does not
> >>need recovery since all its state was preserved?
> >>
> >
> >By treating is the same way as the way the spec handles
> >control channel fault.
> >
> 
> True, but this does not help.  

Help with what ?

> See below.
> 
> >>>reason for resynchronization is to make sure both side
> >>>have done the same to the in-progress connections, not
> >>>just to synchronize the established states.
> >>>
> >>>The value of the RESTART_CAP will set to non-zero values
> >>>
> >>RECOVERY LABEL does not come into picture unless the node
> >>that is upstream to the restarting node has already received
> >>a Resv.
> >>
> >
> >Wrong. Quoting 9.5.3:
> >
> >   Upon detecting a restart with a neighbor that supports state
> >   recovery, a node SHOULD refresh all Path state shared with that
> >   neighbor.
> >
> >So, as you can hopefully see from the above, the upstream node doesn't 
> >wait until it receives a Resv.
> >
> True - if you had read further, you would have noticed that
> I have said the same thing that you have quoted :) -
> but there will be no RECOVERY_LABEL unless a Resv has
> been received, right?
>
> It is possible that the downstream node, after programming
> its forwarding path, restarted before sending the Resv.
> This would result in the upstream node refreshing the Path
> message without the Recovery Label, and the downstream
> node eventually allocating a different label. 

Correct.

> So essentially it is a new LSP setup.

It is a setup for a connection that is *in-progress*.

> >>So it seems that the procedure is to resynchronize
> >>established state? If Resv has not been received yet, there
> >>will be a refresh of Path message, and the restarting node
> >>will consider it as a new request, etc.  So can you elaborate
> >>on "to make sure both side have done the same to the in
> >>progress connections" ?
> >>
> >>>>If a node supports PSC as well as TDM or LSC interfaces, it
> >>>>might want to advertise different set of parameters in the
> >>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM
> >>>>LSPs which form bearer channels in transport networks.
> >>>>Currently this is not possible.
> >>>>
> >>>Can you give us explicit examples as to why and what do
> >>>you gain by giving different values for PSC, TDM ?
> >>>
> >>In case of PSC devices, it may be OK to remove state that
> >>is not resynchronized at the end of the recovery period,
> >>and the recovery period advertised might reflect that.
> >>But for LSPs in transport networks, one might want to
> >>have a different recovery period to avoid any LSP from
> >>going down because of recovery timer expiry.
> >>
> >
> >There is no requirement for a node to advertise exactly the
> >same Restart_Cap on all the interfaces. So, on PSC interfaces
> >the node could advertise that it will remove the state that
> >isn't syncronized at the end of the recovery period, while
> >on the TDM interface precisely the same node could advertise
> >that the LSPs would be kept even after the recovery time expires.
>
> But to set up LSPs over TDM/LSC interfaces, the PSC interface
> is going to be used for signaling - since control and data
> planes are decoupled!  So, how will this help?

Help with what ? You asserted that it "is not possible" for
"a node that supports PSC as well as TDM and LSC interfaces..
to advertise different set of parameters in the RESTART_CAP
object for data LSPs as opposed to SONET/WDM LSPs."

I pointed out to you that your assertion is incorrect, as
there is no requirement for a node to advertise exactly the
same Restart_Cap on all of its interfaces.

> >>>>According to 9.5.1. (procedures for restarting LSR): "When
> >>>>sending the corresponding outgoing Path message the node
> >>>>SHOULD include a SUGGESTED_LABEL object with a label value
> >>>>^^^^^^
> >>>>matching the outgoing label from the now restored forwarding
> >>>>entry."
> >>>>
> >>>>This has a conflict with 9.5.2.  Consider the case where
> >>>>adjacent nodes B and C restart, and B has another adjacent
> >>>>node A, and C has another adjacent node D.  B and C will get
> >>>>resynced by A and D, and during this process, they will
> >>>>resync. each other. While resyncing each other, they act as
> >>>>neighbors of a restarting LSR, and hence according to 9.5.2,
> >>>>MUST include the SUGGESTED_LABEL.
> >>>>
> >>>>Also according to 9.5.2: "During the recovery period, new
> >>>>Path state being advertised to the restarted neighbor SHOULD
> >>>>not include the SUGGESTED_LABEL object in the corresponding
> >>>>outgoing Path message.  This will prevent the restarting
> >>>>node
> >>>> from erroneously reusing a saved forwarding entry."
> >>>>
> >>>>I guess this would mean that if suggested labels are used
> >>>>during new LSP setup (as they are likely to be while
> >>>>provisioning lightpaths - to reduce latency), then new LSP
> >>>>setup will not be allowed during resyncing?
> >>>>
> >>>The use of RECOVERY_LABEL address all the above questions.
> >>>
> >>The first problems seems to be there still - consider two
> >>adjacent nodes restarting.  They both act both as the restarting
> >>node as well as the neighbor to the restarting node. So, once
> >>they learn the state from the upstream neighbor, do they use
> >>suggested label or the recovery label when they send the path
> >>message to the just restarted downstream neighbor?
> >>
> >
> >The recovery label.
> >
> >The following should be added to the existing text from the document:
> >
> >   In the special case where a restarting node also has a restating
> >   downstream neighbor, a Recovery_Label object should be used instead
> >   of a Suggested_Label object.
> >
> Since a restarting node may not be able to detect that a
> downstream neighbor is restarting, I suggest it always use
> a Recovery_Label object instead of a Suggested_Label object.

Please see my reply to Yangguang on this topic.

Yakov.

Delivery-date: Mon, 22 Oct 2001 10:36:52 -0700
Date: Mon, 22 Oct 2001 13:32:07 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Yakov Rekhter <[email-masked]>
CC: [email-masked], Eric Gray <[email-masked]>
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Yakov,

Thanks for resenting me the message from Eric.

Indeed, instead of looking for answers from you, my intention was just trying to
point out some holes in the current proposal and your previous response. And
thanks for just throwing them back to me.

Again, not trying to add more smoke, just repeat my main point again: there are
existing solid solutions that can satisfy carriers' requirement of preserving
data path and re-create data path state after rebooting. I think many of us are
aware of that. If you are proposing a new mechanism, no matter good or bad, at
least you could consider some "backward" compatibility issues. Meanwhile, even I
have confidence that you can make it work well eventually, there are some corner
cases I'd like to point out.

And also a piece of suggestion, before claiming a solution for a problem. It's
better to understand the problem well first. There is nothing can replace
working experience of either operating, designing and developing optical
transport network and NEs.

Yangguang 

Yakov Rekhter wrote:
> 
> Yangguang,
> 
> > Indeed, you didn't answer my questions.
> 
> Perhaps it would be more correct to say that I didn't answer
> your questions *to your satisfaction*. And if that is the case, then
> I hope that the attached e-mail from Eric Gray (that he let me repost
> to the list) would answer your questions to your satisfaction.
> 
> > Instead of informed readers, more
> > important is to have better informed writers.
> 
> See the attached.
> 
> > BTW, I have no intention to let you design my product at all.
> 
> Glad to hear this !!!
> 
> Yakov.
> ---------------------------------------------------------------------
> Date:    Fri, 19 Oct 2001 15:38:58 EDT
> To:      Yangguang Xu <[email-masked]>
> cc:      Yakov Rekhter <[email-masked]>
> From:    Eric Gray <[email-masked]>
> Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
> 
> Yangguang,
> 
>     Careful, don't let this discussion descend into the nether regions of
> name calling and finger pointing. :-)
> 
>     The fact that the seeming remote neighbors use RSVP Hello is clear
> once you realize that - for the purposes of hierarchical LSP setup, they
> are adjacent.  You may recall this from an off-line discussion we had.
> 
>     Yakov's comment was simply stating that it is not a part of standard's
> development to make an implementer's cook-book.  He was not (I think)
> trying to imply that you could not write your own implementation.  He was
> just saying that the effort of achieving interoperability falls on the people
> doing the implementation not on the people doing the standard.  The bare
> information is there, but the work is up to you.
> 
>     As you know, the standard is not complete until several implementations
> have achieved interoperability independently.  But the opportunity to get in
> the market stems from being one of those implementations - and there is
> zero motivation for any implementer to make this task easy for all others.
> One of the costs associated with the 'running code' part of IETF mistique
> is that standards are written by implementers.
> 
>     Unless and until that changes, you just have to learn to deal with it.  :-)
> 
> You wrote:
> 
> > Indeed, you didn't answer my questions. Instead of informed readers, more
> > important is to have better informed writers.
> >
> > BTW, I have no intention to let you design my product at all.
> >
> > Yangguang
> >
> > Yakov Rekhter wrote:
> > >
> > > Yangguang,
> > >
> > > > Yakov,
> > > >
> > > > Further questions in-line. Regards,
> > >
> > > Further responses in-line...
> > >
> > > > Yangguang
> > > >
> > > > > Couple of points:
> > > > >
> > > > > (1) First of all, you do run RSVP Hello between C and F.
> > > >
> > > > Is this specified somewhere? Or it's your proposal.
> > >
> > > What I mentioned in the above should be abundantly obvious to the
> > > informed reader of RSVP and LSP Hierarchy specs.
> > >
> > > > Then, is there a scalability issue here?
> > >
> > > No.
> > >
> > > > Also, C and F could be thousands mile away (in the transport
> > > > network) and the control channel bandwidth is expensive.
> > >
> > > GMPLS assumes that control channel is more than just 56Kbits/sec link.
> > >
> > > Or to put it differently, control channels used by GMPLS have more than
> > > enough capacity for RSVP Hellos.
> > >
> > > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > > > > be able to recover the Interface ID it assigns to L1 from
> > > > > a combination of (a) the OSPF/ISIS link state database that
> > > > > F would recover, and (b) the Forward Interface ID (the one
> > > > > assigned by C).
> > > >
> > > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
> n it
> > > > has to recover its FA info first. How?
> > >
> > > The answer should be abundantly obvious to the informed reader.
> > >
> > > And to make it crystal clear, I have no intention in designing your
> > > products for you.
> > >
> > > > > > Let us say the node can resynchronize its neighbor if
> > > > > > the neighbor restarts and requests state recovery. But
> > > > > > the issue is how a node can advertise that it does not
> > > > > > need recovery since all its state was preserved?
> > > > >
> > > > > By treating is the same way as the way the spec handles
> > > > > control channel fault.
> > > > >
> > > >
> > > > If a node can recover states from NVRAM or OS (this solution is
> > > > cheaper and have been implemented). It may not implement the spec.
> > > > How could a neighboring node, which implements the spec, not tear
> > > > down data connections mistakenly? Similar to a backward compatibility
> > > > problem, even not.
> > >
> > > Stating the obvious: interoperability with a node that doesn't implement
> > > the spec is outside the scope of the spec.
> > >
> > > > > > RECOVERY LABEL does not come into picture unless the node
> > > > > > that is upstream to the restarting node has already received
> > > > > > a Resv.
> > > > >
> > > > > Wrong. Quoting 9.5.3:
> > > > >
> > > > >    Upon detecting a restart with a neighbor that supports state
> > > > >    recovery, a node SHOULD refresh all Path state shared with that
> > > > >    neighbor.
> > > > >
> > > > > So, as you can hopefully see from the above, the upstream node doesn't
> > > > > wait until it receives a Resv.
> > > > >
> > > >
> > > > Then this may not meet carriers' requirement. (see IPO carriers' requirem
> ent)
> > > > Again, back to the telecom world (sorry about this, yet we are talking ab
> out
> > > > GMPLS), typically only the established pathes are preserved. Pending requ
> ests
> > > > may be purged/aborted. Then how?
> > >
> > > Note the verb is "SHOULD", not "MUST". The rest should be
> > > obvious to the informed reader.
> > >
> > > > > > In case of PSC devices, it may be OK to remove state that
> > > > > > is not resynchronized at the end of the recovery period,
> > > > > > and the recovery period advertised might reflect that.
> > > > > > But for LSPs in transport networks, one might want to
> > > > > > have a different recovery period to avoid any LSP from
> > > > > > going down because of recovery timer expiry.
> > > > >
> > > > > There is no requirement for a node to advertise exactly the
> > > > > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > > > > the node could advertise that it will remove the state that
> > > > > isn't syncronized at the end of the recovery period, while
> > > > > on the TDM interface precisely the same node could advertise
> > > > > that the LSPs would be kept even after the recovery time expires.
> > > > >
> > > >
> > > > So, restart_cap is per interface based?
> > >
> > > yes.
> > >
> > > > Is the spec going to be enhanced/clarified?
> > >
> > > The current spec need not be enhanced/clarified - what I mentioned in the
> > > above should be abundantly obvious to the informed reader.
> > >
> > > > > > The first problems seems to be there still - consider two
> > > > > > adjacent nodes restarting.  They both act both as the restarting
> > > > > > node as well as the neighbor to the restarting node. So, once
> > > > > > they learn the state from the upstream neighbor, do they use
> > > > > > suggested label or the recovery label when they send the path
> > > > > > message to the just restarted downstream neighbor?
> > > > >
> > > > > The recovery label.
> > > > >
> > > > > The following should be added to the existing text from the document:
> > > > >
> > > > >    In the special case where a restarting node also has a restating
> > > > >    downstream neighbor, a Recovery_Label object should be used instead
> > > > >    of a Suggested_Label object.
> > > >
> > > > How does a recovering NE know that its neighbor is also recovering? it ma
> y
> > > > lose the instance number totally
> > >
> > > It's advertised in the neighbor's hellos.
> > >
> > > Yakov.
> 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray

Delivery-date: Mon, 22 Oct 2001 10:05:47 -0700
To: Yangguang Xu <[email-masked]>
cc: [email-masked], Eric Gray <[email-masked]>
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) 
Date: Mon, 22 Oct 2001 10:00:37 -0700
From: Yakov Rekhter <[email-masked]>

Yangguang,

> Indeed, you didn't answer my questions. 

Perhaps it would be more correct to say that I didn't answer
your questions *to your satisfaction*. And if that is the case, then
I hope that the attached e-mail from Eric Gray (that he let me repost
to the list) would answer your questions to your satisfaction.

> Instead of informed readers, more
> important is to have better informed writers. 

See the attached.

> BTW, I have no intention to let you design my product at all. 

Glad to hear this !!!

Yakov.
---------------------------------------------------------------------
Date:    Fri, 19 Oct 2001 15:38:58 EDT
To:      Yangguang Xu <[email-masked]>
cc:      Yakov Rekhter <[email-masked]>
From:    Eric Gray <[email-masked]>
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Yangguang,

    Careful, don't let this discussion descend into the nether regions of
name calling and finger pointing. :-)

    The fact that the seeming remote neighbors use RSVP Hello is clear
once you realize that - for the purposes of hierarchical LSP setup, they
are adjacent.  You may recall this from an off-line discussion we had.

    Yakov's comment was simply stating that it is not a part of standard's
development to make an implementer's cook-book.  He was not (I think)
trying to imply that you could not write your own implementation.  He was
just saying that the effort of achieving interoperability falls on the people
doing the implementation not on the people doing the standard.  The bare
information is there, but the work is up to you.

    As you know, the standard is not complete until several implementations
have achieved interoperability independently.  But the opportunity to get in
the market stems from being one of those implementations - and there is
zero motivation for any implementer to make this task easy for all others.
One of the costs associated with the 'running code' part of IETF mistique
is that standards are written by implementers.

    Unless and until that changes, you just have to learn to deal with it.  :-)

You wrote:

> Indeed, you didn't answer my questions. Instead of informed readers, more
> important is to have better informed writers.
>
> BTW, I have no intention to let you design my product at all.
>
> Yangguang
>
> Yakov Rekhter wrote:
> >
> > Yangguang,
> >
> > > Yakov,
> > >
> > > Further questions in-line. Regards,
> >
> > Further responses in-line...
> >
> > > Yangguang
> > >
> > > > Couple of points:
> > > >
> > > > (1) First of all, you do run RSVP Hello between C and F.
> > >
> > > Is this specified somewhere? Or it's your proposal.
> >
> > What I mentioned in the above should be abundantly obvious to the
> > informed reader of RSVP and LSP Hierarchy specs.
> >
> > > Then, is there a scalability issue here?
> >
> > No.
> >
> > > Also, C and F could be thousands mile away (in the transport
> > > network) and the control channel bandwidth is expensive.
> >
> > GMPLS assumes that control channel is more than just 56Kbits/sec link.
> >
> > Or to put it differently, control channels used by GMPLS have more than
> > enough capacity for RSVP Hellos.
> >
> > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > > > be able to recover the Interface ID it assigns to L1 from
> > > > a combination of (a) the OSPF/ISIS link state database that
> > > > F would recover, and (b) the Forward Interface ID (the one
> > > > assigned by C).
> > >
> > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
n it
> > > has to recover its FA info first. How?
> >
> > The answer should be abundantly obvious to the informed reader.
> >
> > And to make it crystal clear, I have no intention in designing your
> > products for you.
> >
> > > > > Let us say the node can resynchronize its neighbor if
> > > > > the neighbor restarts and requests state recovery. But
> > > > > the issue is how a node can advertise that it does not
> > > > > need recovery since all its state was preserved?
> > > >
> > > > By treating is the same way as the way the spec handles
> > > > control channel fault.
> > > >
> > >
> > > If a node can recover states from NVRAM or OS (this solution is
> > > cheaper and have been implemented). It may not implement the spec.
> > > How could a neighboring node, which implements the spec, not tear
> > > down data connections mistakenly? Similar to a backward compatibility
> > > problem, even not.
> >
> > Stating the obvious: interoperability with a node that doesn't implement
> > the spec is outside the scope of the spec.
> >
> > > > > RECOVERY LABEL does not come into picture unless the node
> > > > > that is upstream to the restarting node has already received
> > > > > a Resv.
> > > >
> > > > Wrong. Quoting 9.5.3:
> > > >
> > > >    Upon detecting a restart with a neighbor that supports state
> > > >    recovery, a node SHOULD refresh all Path state shared with that
> > > >    neighbor.
> > > >
> > > > So, as you can hopefully see from the above, the upstream node doesn't
> > > > wait until it receives a Resv.
> > > >
> > >
> > > Then this may not meet carriers' requirement. (see IPO carriers' requirem
ent)
> > > Again, back to the telecom world (sorry about this, yet we are talking ab
out
> > > GMPLS), typically only the established pathes are preserved. Pending requ
ests
> > > may be purged/aborted. Then how?
> >
> > Note the verb is "SHOULD", not "MUST". The rest should be
> > obvious to the informed reader.
> >
> > > > > In case of PSC devices, it may be OK to remove state that
> > > > > is not resynchronized at the end of the recovery period,
> > > > > and the recovery period advertised might reflect that.
> > > > > But for LSPs in transport networks, one might want to
> > > > > have a different recovery period to avoid any LSP from
> > > > > going down because of recovery timer expiry.
> > > >
> > > > There is no requirement for a node to advertise exactly the
> > > > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > > > the node could advertise that it will remove the state that
> > > > isn't syncronized at the end of the recovery period, while
> > > > on the TDM interface precisely the same node could advertise
> > > > that the LSPs would be kept even after the recovery time expires.
> > > >
> > >
> > > So, restart_cap is per interface based?
> >
> > yes.
> >
> > > Is the spec going to be enhanced/clarified?
> >
> > The current spec need not be enhanced/clarified - what I mentioned in the
> > above should be abundantly obvious to the informed reader.
> >
> > > > > The first problems seems to be there still - consider two
> > > > > adjacent nodes restarting.  They both act both as the restarting
> > > > > node as well as the neighbor to the restarting node. So, once
> > > > > they learn the state from the upstream neighbor, do they use
> > > > > suggested label or the recovery label when they send the path
> > > > > message to the just restarted downstream neighbor?
> > > >
> > > > The recovery label.
> > > >
> > > > The following should be added to the existing text from the document:
> > > >
> > > >    In the special case where a restarting node also has a restating
> > > >    downstream neighbor, a Recovery_Label object should be used instead
> > > >    of a Suggested_Label object.
> > >
> > > How does a recovering NE know that its neighbor is also recovering? it ma
y
> > > lose the instance number totally
> >
> > It's advertised in the neighbor's hellos.
> >
> > Yakov.

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 22 Oct 2001 09:10:38 -0700
From: Edward Harrison <[email-masked]>
To: 'Lou Berger' <[email-masked]>
Cc: [email-masked]
Subject: RE: update GMPLS signaling documents
Date: Mon, 22 Oct 2001 17:04:54 +0100
Deferred-Delivery: Mon, 22 Oct 2001 17:07:00 +0100

Lou,

I'm interested to know the rationale behind the two new flags introduced to
the Admin Status object in draft-ietf-mpls-generalized-signaling-06.
Unfortunately I can't seem to find any comments relating to them in the
CCAMP or MPLS mailing lists.

Is there any chance you could either point me to the appropriate mails or
let me know what the relevant comments were (for example, if they were
private emails or phone comments)?

Thanks very much,

Ed
----------
Edward Harrison  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd.
http://www.dataconnection.com/
Tel: +44 20 8366 1177  Fax: +44 20 8363 1468

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: 01 October 2001 07:48
To: [email-masked]
Subject: update GMPLS signaling documents

FYI -

Updated versions of the signaling and RSVP-TE documents have been 
submitted. The CR-LDP version is forthcoming.  The updates address comments 
received during the August meeting and comment period.

Here's a summary of changes:

draft-ietf-mpls-generalized-signaling-06.txt
Changes from previous version:
o Removed redundant encoding type
o Revised Admin Status Usage (per comments and also removed potential race 
condition) o Clarified text related to interface bundling (To be consistent 
with updated bundling draft.)
o Minor editorial changes and clarifications
o Revised G-PID (per comments on list)

draft-ietf-mpls-generalized-rsvp-te-05.txt
Changes from previous version:
o Revised Admin Status Usage (per comments and also removed potential race 
condition)
o Clarified text related to interface bundling (To be consistent with 
updated bundling draft.)
o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel 
Separation by allowing identification of errored interface.)
o Added U bit to Label RRO subobject (Per comment, to match defined ERO.)
o Clarified usage of Restart_Cap o Replaced use of Suggested_Label during 
recovery with new Recovery_Label (Per last WG session)
o Added IANA Considerations
o Minor editorial changes and clarifications

For those who don't want to wait, the drafts are available from:
http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt
http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt

Lou

Delivery-date: Mon, 22 Oct 2001 08:41:12 -0700
From: Yanhe Fan <[email-masked]>
To: "'Zhi-Wei Lin'" <[email-masked]>
Cc: John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Mon, 22 Oct 2001 11:34:26 -0400

Hi Zhi,

What B does is breaking the label association between A and C by crossing
connect
the time slots.

If the cross connect performed by B is fixed (in your case), what needs to
do is 
just to rebuild the label association by configuration or a protocol such as
LMP;
If the cross connect is not fixed but dynamic, the best thing to do is to
make B 
a GMPLS speaker.

Yanhe

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Friday, October 19, 2001 6:01 PM
To: Yanhe Fan
Cc: John Drake; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ...

Hi Yanhe,

Maybe there is some misunderstanding. Node B is strictly not GMPLS. It 
is simply part of the network that made up the "dumb" pipe. And because 
the control plane control channel is separate, A and C can be adjacent 
without ever knowing who B is or that even B existed. From A and C's 
point of view, the network looks like:

  A ----- C

Think of the case of how a BGP sees an area. If an area is made up of:

  A -- B -- C

and B is internal router, does BGP "see" B?

Zhi

Yanhe Fan wrote:

> Hi, Zhi
> 
> 
>>For the label value for SONET/SDH or the label description in the 
>>generic draft, the label is defined as directly representing the 
>>"timeslot". Now if I have a control plane controlled transport network 
>>that goes through a ADM that is not control plane controlled, as:
>>
>>
>>+--------+               +--------+               +--------+
>>|        | ---1--------- |        | ----1-------- |        |
>>|        | ---2--------- |        | ----2-------- |        |
>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>>|        | ---4--------- |        | ----4-------- |        |
>>|        | ---5--------- |        | ----5-------- |        |
>>+--------+               +--------+               +--------+
>>
>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at 
>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C 
>>has labels 1,2,3,4,5 incoming.
>>
>>Now imagine that at B, it actually has a fixed cross-connect that 
>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to 
>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>>
>>Now when A GMPLS sends a message to C, the label it uses is "1". 
>>However, the connection/LSP associated with timeslot "1" is actually the 
>>label of timeslot "2" at C. </z>
>>
> 
> In this case, you're trying to use GMPLS to setup an LSP cross a node (B)
> which can't understand GMPLS.
> 
> Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using 
> GMPLS if B can't understand GMPLS?
> 
> Now imagine A and B are LSRs, and B is a conventional router (can't
> understand
> MPLS), can you setup an LSP A-B-C?
> 
> Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> understand PNNI at all?
> 
> My point is that in order to make you case work, some additional work need
> to
> be done besie simply using GMPLS as singnaling protocol, becase some node
on
> the path is not GMPLS speakers. A and C needs the info of time slot
aligment
> 
> between them. This can be done by some configurations, some link
management 
> protocls (LMP maybe) etc. As long as A and C have this piece of info,
> eveything
> works fine.
> 
> Yanhe
> 

Delivery-date: Sun, 21 Oct 2001 05:02:24 -0700
Date: Sun, 21 Oct 2001 13:56:50 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------DC51005CBB896A044C61013B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Manoj,

My previous e-mail was a generic one, not only focused on your 
question concerning the conversion table. I personally think 
the following on this issue:

> 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table
> as an addendum to the draft.

This would apply to the SDH/Sonet document ... however i see it more
adapted to the "SDH/Sonet framework" one. Personally i think that in 
such I-D it can be useful (please contact Eric for that purpose) and
so i think we are in agreement here.

Here the response to your other questions:

> 1. Can someone please tell me the usage of bandwidth encoding
> parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> will be drived from the signal type field. How the bandwidth encoding
> type will be interpreted in case of other LSP encoding types (lambda,
> waveband, fiber etc) ? The draft should list down the cases in which 
> the bandwidth encoding type is to be filled.

To which I-D do you refer here, in GMPLS-SIG this is well explained.
For the SDH/Sonet one, we had this discussion sometime ago and the 
outcome was to "un-use" this value (even if i don't think it is the
best solution but since discussion brought us to more complexity...) 
Remember that the resulting bandwidth is dependent on the application
of the different field on the elementary Signal Type resulting in a 
final signal.

Anyway, if it has to be detailed it would be in the SDH/Sonet and
other technology dependent ones.
 
> 2. Usage of Label Set :
>         There are cases mentioned in the draft which explains the usage
> of label set. It should also mention that the range of labels in
> SDH/SONET does not make sense. Ranges in label set are applicable in
> case of waveband/lambda switching etc. The range in label set is valid
> in SDH/SONET only if there is one element in the range i.e. start range
> and end range should be same.

Is it a question or an assertion ? I refer you also here to my previous 
e-mail
 
> 3. There are couple of scenarios where there can be contention for
> establishing bi-directional LSPs. All the scenarios are not listed in
> the document. If it is not possible to list all the scenarios then the
> draft should say that this is one of the example scenario. The
> contention can also be possible in case where same label set and
> upstream label are used in both the directions.

This has been extensively discussed on this mailing list i am referring
you to the outcome of this discussion
 
> 4. As per OIF, the carrier requirement is that SDH LSPs should be
> either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS
> has different set of carrier requirements in this regard ?

The I-D is covering HO/STS SPE and LOVC/VT for completeness (as
described 
in G.707 ANSI T1.105), OIF UNI 1.0 uses a subset. Why not.
 
> 6. The relation between switching capability and LSP encoding type
> should be clearly explained in the drafts. As the switching capability
> field was added very late (just 2 months back) in the drafts,
> specific reason should be mentioned for its addition.

... ? re-phrasing one of the remarks i saw this week can be applied here
we are not discussing "requirement" document here

Hope this will help you,

Regards,
Dimitri.

manoj juneja wrote:
> 
> Hi Dimitri,
>             I don't think there is any issue in including the
> conversion table in the draft. Even this table can be kept in some
> informational draft. The inclusion of conversion table is a valid thing and
> probably nobody on ccamp mailing list would like oppose. I
> still didn't get answers to other points in my mail.
> 
> Regards,
> manoj.
> 
> >From: Dimitri Papadimitriou <[email-masked]>
> >To: Zhi-Wei Lin <[email-masked]>
> >CC: manoj juneja <[email-masked]>, [email-masked],
> >[email-masked]
> >Subject: Re: Moving right along ...
> >Date: Sat, 20 Oct 2001 16:05:01 +0200
> >
> >Hi Zhi,
> >
> >I would like to remember you something here: the SDH/Sonet I-D is not
> >1) a textbook on how to use GMPLS-SIG but must be understood an
> >    additional document complementing the signalling one
> >2) a tutorial on Sonet/SDH (a framework has been proposed for that
> >    purpose)
> >
> >We have spent hard time together with the SDH/Sonet I-D co-authors in
> >order to find the best balance between reproducing well known SDH/Sonet
> >concepts and paragraphs really providing an added value in this document
> >
> >Of course we can not make 100% people happy (even between the list of
> >30 co-authors) some of us found there was too much explanations while
> >others were requesting more content.
> >
> >Therefore for the non-covered content we are referencing the appropriate
> >document either it comes from ITU or IETF. Please understand that we
> >can not wait until everybody in this world has no question anymore or a
> >full understanding on any technical detail in order to go forward with
> >these documents.
> >
> >Thanks for your "virtual" understanding,
> >Dimitri.
> >
> >Zhi-Wei Lin wrote:
> > >
> > > Hi Manoj,
> > >
> > > I agree with many of your points. I actually submitted an I-D several
> > > months ago (I think it's expired) that proposes some text to add to the
> > > GMPLS SONET/SDH on the rules for setting different values, such as for
> > > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the
> > > range of acceptable value of X, etc.
> > >
> > > My rationale at that time was that not everyone is a SONET/SDH expert
> > > and instead of asking them to look somewhere else and dig through those
> > > documents to find the answer, if we can provide them in the GMPLS set of
> > > drafts it would be extremely useful for the entire IETF community and
> > > would help clarify the usage of these parameters. But unfortunately if
> > > you were at the meeting at the time, it wasn't accepted because some
> > > folks thought that these were obvious or that this info is not needed
> > > because they can find it in other places referenced...
> > >
> > > If you have the old drafts, the file was:
> > > draft-lin-ccamp-ipo-common-label-request-01
> > >
> > > But anyway...people will just have to read all the referenced documents
> > > to understand how to use the different parameters...
> > >
> > > Zhi
> > >
> > > manoj juneja wrote:
> > >
> > > > Hi Kireeti,
> > > >            I am not an active member of IETF but a regular reader of
> > > > GMPLS drafts. I am not sure how much weight my mail will carry but as
> >a
> > > > regular reader of these drafts, I recommend the following points
> >should
> > > > be made clear in the documents before proceeding to the last call.
> > > >
> > > >
> > > > 1. Can someone please tell me the usage of bandwidth encoding
> > > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> > > > will be drived from the signal type field. How the bandwidth encoding
> > > > type will be interpreted in case of other LSP encoding types (lambda,
> > > > waveband, fiber etc) ? The draft should list down the cases in which
> >the
> > > > bandwidth encoding type is to be filled.
> > > >
> > > > 2. Usage of Label Set :
> > > >        There are cases mentioned in the draft which explains the usage
> > > > of label set. It should also mention that the range of labels in
> > > > SDH/SONET does not make sense. Ranges in label set are applicable in
> > > > case of waveband/lambda switching etc. The range in label set is valid
> > > > in SDH/SONET only if there is one element in the range i.e. start
> >range
> > > > and end range should be same.
> > > >
> > > > 3. There are couple of scenarios where there can be contention for
> > > > establishing bi-directional LSPs. All the scenarios are not listed in
> > > > the document. If it is not possible to list all the scenarios then the
> > > > draft should say that this is one of the example scenario. The
> > > > contention can also be possible in case where same label set and
> > > > upstream label are used in both the directions.
> > > >
> > > > 4. As per OIF, the carrier requirement is that SDH LSPs should be
> > > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> > > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean
> >GMPLS
> > > > has different set of carrier requirements in this regard ?
> > > >
> > > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
> > > > an addendum to the draft.
> > > >
> > > > 6. The relation between switching capability and LSP encoding type
> > > > should be clearly explained in the drafts. As the switching capability
> > > > field was added very late (just 2 months back) in the drafts,
> > > > specific reason should be mentioned for its addition.
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > >
> > > >
> > > >> From: Kireeti Kompella <[email-masked]>
> > > >> To: [email-masked]
> > > >> Subject: Moving right along ...
> > > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
> > > >>
> > > >> Despite the energetic subject line, we the WG chairs have been
> > > >> lax in our duties.  So, here goes:
> > > >>
> > > >> Lou has submitted the latest versions of the generalized
> > > >> signaling documents quite some time ago (thanks, Lou):
> > > >>
> > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > >> draft-ietf-mpls-generalized-signaling-06.txt
> > > >>
> > > >> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > > >>
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > > >>
> > > >> All of these should have addressed the issues raised in the earlier
> > > >> versions.  Please read the new versions, and send your comments to
> > > >> the list by Tuesday Oct 23.  At that point, when the final round
> > > >> of comments have been addressed, these docs will go to IESG Last
> > > >> Call.  If any one objects to sending these docs to IESG Last Call,
> > > >> raise your issues now.
> > > >>
> > > >> I see that the GMPLS architecture document is a CCAMP WG doc, but
> > > >> the minutes say that we should look for consensus on the list.  So,
> > > >> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > > >> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > > >> will progress to WG Last Call.
> > > >>
> > > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > > >> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > > >> list know what your thinking is on these.  (BTW, both these docs
> > > >> were to have some edits done.  If the authors could do that before
> > > >> the next IETF, we can try to make more progress then.)
> > > >>
> > > >> The MIB overview doc was recently posted.  Please read and comment
> > > >> to the list.
> > > >>
> > > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > >> was generally thought to be useful; it will be published as a
> > > >> CCAMP informational doc.  This begins a two week Last Call on
> > > >> the doc, ending Tuesday Oct 30.
> > > >>
> > > >> There was no consensus on whether the GMPLS framework should be
> > > >> a CCAMP WG doc.  Please indicate your pleasure.
> > > >>
> > > >> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > > >> raised that this draft is close to ready for WG Last Call.  Please
> > > >> review it, and let us know if you disagree.
> > > >>
> > > >> The OLI requirements doc was broadly accepted.  Please let the
> > > >> list know if you think this doc should be a WG doc.
> > > >>
> > > >> It's still open whether we (the IETF) should be working on
> > > >> LMP-WDM.  I urge the authors to keep on working on the doc, and
> > > >> keeping it in sync with LMP; however, we will postpone making it
> > > >> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > > >> happen in Salt Lake City.
> > > >>
> > > >> There was reasonable interest in the tunnel trace requirements
> > > >> doc.  Let's formalize this: do you think this should be made a
> > > >> CCAMP WG document?
> > > >>
> > > >> Summary:
> > > >>
> > > >> 1) Final comments and IESG Last Call readiness for:
> > > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > > >> draft-ietf-mpls-generalized-signaling-06.txt
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > > >>
> > > >> 2) Should the following documents be CCAMP WG docs?
> > > >> draft-bonica-tunneltrace-02.txt
> > > >> draft-fontana-ccamp-gmpls-g709-00.txt
> > > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > > >> draft-many-ccamp-gmpls-framework-00.txt
> > > >> draft-many-oli-reqts-00.txt
> > > >>
> > > >> 3) Comment on MIB overview.
> > > >>
> > > >> 4) Two week Last Call comments on
> > > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > > >>
> > > >> 5) Last Call readiness of
> > > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > > >> draft-ietf-ccamp-lmp-01.txt
> > > >>
> > > >> Thanks,
> > > >> Kireeti.
> > > >>
> > > >
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> > > >
> > > >
> ><< dimitri.papadimitriou.vcf >>
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------DC51005CBB896A044C61013B
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------DC51005CBB896A044C61013B--

Delivery-date: Sat, 20 Oct 2001 16:35:08 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Moving right along ...
Date: Sat, 20 Oct 2001 16:29:41 -0700

Hi Dimitri,
            I don't think there is any issue in including the
conversion table in the draft. Even this table can be kept in some
informational draft. The inclusion of conversion table is a valid thing and 
probably nobody on ccamp mailing list would like oppose. I
still didn't get answers to other points in my mail.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: Zhi-Wei Lin <[email-masked]>
>CC: manoj juneja <[email-masked]>, [email-masked],   
>[email-masked]
>Subject: Re: Moving right along ...
>Date: Sat, 20 Oct 2001 16:05:01 +0200
>
>Hi Zhi,
>
>I would like to remember you something here: the SDH/Sonet I-D is not
>1) a textbook on how to use GMPLS-SIG but must be understood an
>    additional document complementing the signalling one
>2) a tutorial on Sonet/SDH (a framework has been proposed for that
>    purpose)
>
>We have spent hard time together with the SDH/Sonet I-D co-authors in
>order to find the best balance between reproducing well known SDH/Sonet
>concepts and paragraphs really providing an added value in this document
>
>Of course we can not make 100% people happy (even between the list of
>30 co-authors) some of us found there was too much explanations while
>others were requesting more content.
>
>Therefore for the non-covered content we are referencing the appropriate
>document either it comes from ITU or IETF. Please understand that we
>can not wait until everybody in this world has no question anymore or a
>full understanding on any technical detail in order to go forward with
>these documents.
>
>Thanks for your "virtual" understanding,
>Dimitri.
>
>Zhi-Wei Lin wrote:
> >
> > Hi Manoj,
> >
> > I agree with many of your points. I actually submitted an I-D several
> > months ago (I think it's expired) that proposes some text to add to the
> > GMPLS SONET/SDH on the rules for setting different values, such as for
> > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the
> > range of acceptable value of X, etc.
> >
> > My rationale at that time was that not everyone is a SONET/SDH expert
> > and instead of asking them to look somewhere else and dig through those
> > documents to find the answer, if we can provide them in the GMPLS set of
> > drafts it would be extremely useful for the entire IETF community and
> > would help clarify the usage of these parameters. But unfortunately if
> > you were at the meeting at the time, it wasn't accepted because some
> > folks thought that these were obvious or that this info is not needed
> > because they can find it in other places referenced...
> >
> > If you have the old drafts, the file was:
> > draft-lin-ccamp-ipo-common-label-request-01
> >
> > But anyway...people will just have to read all the referenced documents
> > to understand how to use the different parameters...
> >
> > Zhi
> >
> > manoj juneja wrote:
> >
> > > Hi Kireeti,
> > >            I am not an active member of IETF but a regular reader of
> > > GMPLS drafts. I am not sure how much weight my mail will carry but as 
>a
> > > regular reader of these drafts, I recommend the following points 
>should
> > > be made clear in the documents before proceeding to the last call.
> > >
> > >
> > > 1. Can someone please tell me the usage of bandwidth encoding
> > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> > > will be drived from the signal type field. How the bandwidth encoding
> > > type will be interpreted in case of other LSP encoding types (lambda,
> > > waveband, fiber etc) ? The draft should list down the cases in which 
>the
> > > bandwidth encoding type is to be filled.
> > >
> > > 2. Usage of Label Set :
> > >        There are cases mentioned in the draft which explains the usage
> > > of label set. It should also mention that the range of labels in
> > > SDH/SONET does not make sense. Ranges in label set are applicable in
> > > case of waveband/lambda switching etc. The range in label set is valid
> > > in SDH/SONET only if there is one element in the range i.e. start 
>range
> > > and end range should be same.
> > >
> > > 3. There are couple of scenarios where there can be contention for
> > > establishing bi-directional LSPs. All the scenarios are not listed in
> > > the document. If it is not possible to list all the scenarios then the
> > > draft should say that this is one of the example scenario. The
> > > contention can also be possible in case where same label set and
> > > upstream label are used in both the directions.
> > >
> > > 4. As per OIF, the carrier requirement is that SDH LSPs should be
> > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean 
>GMPLS
> > > has different set of carrier requirements in this regard ?
> > >
> > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
> > > an addendum to the draft.
> > >
> > > 6. The relation between switching capability and LSP encoding type
> > > should be clearly explained in the drafts. As the switching capability
> > > field was added very late (just 2 months back) in the drafts,
> > > specific reason should be mentioned for its addition.
> > >
> > > Regards,
> > > manoj.
> > >
> > >
> > >
> > >> From: Kireeti Kompella <[email-masked]>
> > >> To: [email-masked]
> > >> Subject: Moving right along ...
> > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
> > >>
> > >> Despite the energetic subject line, we the WG chairs have been
> > >> lax in our duties.  So, here goes:
> > >>
> > >> Lou has submitted the latest versions of the generalized
> > >> signaling documents quite some time ago (thanks, Lou):
> > >>
> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >> draft-ietf-mpls-generalized-signaling-06.txt
> > >>
> > >> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > >>
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >>
> > >> All of these should have addressed the issues raised in the earlier
> > >> versions.  Please read the new versions, and send your comments to
> > >> the list by Tuesday Oct 23.  At that point, when the final round
> > >> of comments have been addressed, these docs will go to IESG Last
> > >> Call.  If any one objects to sending these docs to IESG Last Call,
> > >> raise your issues now.
> > >>
> > >> I see that the GMPLS architecture document is a CCAMP WG doc, but
> > >> the minutes say that we should look for consensus on the list.  So,
> > >> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > >> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > >> will progress to WG Last Call.
> > >>
> > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > >> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > >> list know what your thinking is on these.  (BTW, both these docs
> > >> were to have some edits done.  If the authors could do that before
> > >> the next IETF, we can try to make more progress then.)
> > >>
> > >> The MIB overview doc was recently posted.  Please read and comment
> > >> to the list.
> > >>
> > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >> was generally thought to be useful; it will be published as a
> > >> CCAMP informational doc.  This begins a two week Last Call on
> > >> the doc, ending Tuesday Oct 30.
> > >>
> > >> There was no consensus on whether the GMPLS framework should be
> > >> a CCAMP WG doc.  Please indicate your pleasure.
> > >>
> > >> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > >> raised that this draft is close to ready for WG Last Call.  Please
> > >> review it, and let us know if you disagree.
> > >>
> > >> The OLI requirements doc was broadly accepted.  Please let the
> > >> list know if you think this doc should be a WG doc.
> > >>
> > >> It's still open whether we (the IETF) should be working on
> > >> LMP-WDM.  I urge the authors to keep on working on the doc, and
> > >> keeping it in sync with LMP; however, we will postpone making it
> > >> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > >> happen in Salt Lake City.
> > >>
> > >> There was reasonable interest in the tunnel trace requirements
> > >> doc.  Let's formalize this: do you think this should be made a
> > >> CCAMP WG document?
> > >>
> > >> Summary:
> > >>
> > >> 1) Final comments and IESG Last Call readiness for:
> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >> draft-ietf-mpls-generalized-signaling-06.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >>
> > >> 2) Should the following documents be CCAMP WG docs?
> > >> draft-bonica-tunneltrace-02.txt
> > >> draft-fontana-ccamp-gmpls-g709-00.txt
> > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > >> draft-many-ccamp-gmpls-framework-00.txt
> > >> draft-many-oli-reqts-00.txt
> > >>
> > >> 3) Comment on MIB overview.
> > >>
> > >> 4) Two week Last Call comments on
> > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >>
> > >> 5) Last Call readiness of
> > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > >> draft-ietf-ccamp-lmp-01.txt
> > >>
> > >> Thanks,
> > >> Kireeti.
> > >>
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
> > >
> > >
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Sat, 20 Oct 2001 16:34:55 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Moving right along ...
Date: Sat, 20 Oct 2001 16:29:45 -0700

Hi Dimitri,
            I don't think there is any issue in including the
conversion table in the draft. Even this table can be kept in some
informational draft. The inclusion of conversion table is a valid thing and 
probably nobody on ccamp mailing list would like oppose. I
still didn't get answers to other points in my mail.

Regards,
manoj.

>From: Dimitri Papadimitriou <[email-masked]>
>To: Zhi-Wei Lin <[email-masked]>
>CC: manoj juneja <[email-masked]>, [email-masked],   
>[email-masked]
>Subject: Re: Moving right along ...
>Date: Sat, 20 Oct 2001 16:05:01 +0200
>
>Hi Zhi,
>
>I would like to remember you something here: the SDH/Sonet I-D is not
>1) a textbook on how to use GMPLS-SIG but must be understood an
>    additional document complementing the signalling one
>2) a tutorial on Sonet/SDH (a framework has been proposed for that
>    purpose)
>
>We have spent hard time together with the SDH/Sonet I-D co-authors in
>order to find the best balance between reproducing well known SDH/Sonet
>concepts and paragraphs really providing an added value in this document
>
>Of course we can not make 100% people happy (even between the list of
>30 co-authors) some of us found there was too much explanations while
>others were requesting more content.
>
>Therefore for the non-covered content we are referencing the appropriate
>document either it comes from ITU or IETF. Please understand that we
>can not wait until everybody in this world has no question anymore or a
>full understanding on any technical detail in order to go forward with
>these documents.
>
>Thanks for your "virtual" understanding,
>Dimitri.
>
>Zhi-Wei Lin wrote:
> >
> > Hi Manoj,
> >
> > I agree with many of your points. I actually submitted an I-D several
> > months ago (I think it's expired) that proposes some text to add to the
> > GMPLS SONET/SDH on the rules for setting different values, such as for
> > STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the
> > range of acceptable value of X, etc.
> >
> > My rationale at that time was that not everyone is a SONET/SDH expert
> > and instead of asking them to look somewhere else and dig through those
> > documents to find the answer, if we can provide them in the GMPLS set of
> > drafts it would be extremely useful for the entire IETF community and
> > would help clarify the usage of these parameters. But unfortunately if
> > you were at the meeting at the time, it wasn't accepted because some
> > folks thought that these were obvious or that this info is not needed
> > because they can find it in other places referenced...
> >
> > If you have the old drafts, the file was:
> > draft-lin-ccamp-ipo-common-label-request-01
> >
> > But anyway...people will just have to read all the referenced documents
> > to understand how to use the different parameters...
> >
> > Zhi
> >
> > manoj juneja wrote:
> >
> > > Hi Kireeti,
> > >            I am not an active member of IETF but a regular reader of
> > > GMPLS drafts. I am not sure how much weight my mail will carry but as 
>a
> > > regular reader of these drafts, I recommend the following points 
>should
> > > be made clear in the documents before proceeding to the last call.
> > >
> > >
> > > 1. Can someone please tell me the usage of bandwidth encoding
> > > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> > > will be drived from the signal type field. How the bandwidth encoding
> > > type will be interpreted in case of other LSP encoding types (lambda,
> > > waveband, fiber etc) ? The draft should list down the cases in which 
>the
> > > bandwidth encoding type is to be filled.
> > >
> > > 2. Usage of Label Set :
> > >        There are cases mentioned in the draft which explains the usage
> > > of label set. It should also mention that the range of labels in
> > > SDH/SONET does not make sense. Ranges in label set are applicable in
> > > case of waveband/lambda switching etc. The range in label set is valid
> > > in SDH/SONET only if there is one element in the range i.e. start 
>range
> > > and end range should be same.
> > >
> > > 3. There are couple of scenarios where there can be contention for
> > > establishing bi-directional LSPs. All the scenarios are not listed in
> > > the document. If it is not possible to list all the scenarios then the
> > > draft should say that this is one of the example scenario. The
> > > contention can also be possible in case where same label set and
> > > upstream label are used in both the directions.
> > >
> > > 4. As per OIF, the carrier requirement is that SDH LSPs should be
> > > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> > > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean 
>GMPLS
> > > has different set of carrier requirements in this regard ?
> > >
> > > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
> > > an addendum to the draft.
> > >
> > > 6. The relation between switching capability and LSP encoding type
> > > should be clearly explained in the drafts. As the switching capability
> > > field was added very late (just 2 months back) in the drafts,
> > > specific reason should be mentioned for its addition.
> > >
> > > Regards,
> > > manoj.
> > >
> > >
> > >
> > >> From: Kireeti Kompella <[email-masked]>
> > >> To: [email-masked]
> > >> Subject: Moving right along ...
> > >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
> > >>
> > >> Despite the energetic subject line, we the WG chairs have been
> > >> lax in our duties.  So, here goes:
> > >>
> > >> Lou has submitted the latest versions of the generalized
> > >> signaling documents quite some time ago (thanks, Lou):
> > >>
> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >> draft-ietf-mpls-generalized-signaling-06.txt
> > >>
> > >> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> > >>
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >>
> > >> All of these should have addressed the issues raised in the earlier
> > >> versions.  Please read the new versions, and send your comments to
> > >> the list by Tuesday Oct 23.  At that point, when the final round
> > >> of comments have been addressed, these docs will go to IESG Last
> > >> Call.  If any one objects to sending these docs to IESG Last Call,
> > >> raise your issues now.
> > >>
> > >> I see that the GMPLS architecture document is a CCAMP WG doc, but
> > >> the minutes say that we should look for consensus on the list.  So,
> > >> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> > >> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> > >> will progress to WG Last Call.
> > >>
> > >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> > >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> > >> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> > >> list know what your thinking is on these.  (BTW, both these docs
> > >> were to have some edits done.  If the authors could do that before
> > >> the next IETF, we can try to make more progress then.)
> > >>
> > >> The MIB overview doc was recently posted.  Please read and comment
> > >> to the list.
> > >>
> > >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >> was generally thought to be useful; it will be published as a
> > >> CCAMP informational doc.  This begins a two week Last Call on
> > >> the doc, ending Tuesday Oct 30.
> > >>
> > >> There was no consensus on whether the GMPLS framework should be
> > >> a CCAMP WG doc.  Please indicate your pleasure.
> > >>
> > >> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > >> raised that this draft is close to ready for WG Last Call.  Please
> > >> review it, and let us know if you disagree.
> > >>
> > >> The OLI requirements doc was broadly accepted.  Please let the
> > >> list know if you think this doc should be a WG doc.
> > >>
> > >> It's still open whether we (the IETF) should be working on
> > >> LMP-WDM.  I urge the authors to keep on working on the doc, and
> > >> keeping it in sync with LMP; however, we will postpone making it
> > >> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> > >> happen in Salt Lake City.
> > >>
> > >> There was reasonable interest in the tunnel trace requirements
> > >> doc.  Let's formalize this: do you think this should be made a
> > >> CCAMP WG document?
> > >>
> > >> Summary:
> > >>
> > >> 1) Final comments and IESG Last Call readiness for:
> > >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> > >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> > >> draft-ietf-mpls-generalized-signaling-06.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > >>
> > >> 2) Should the following documents be CCAMP WG docs?
> > >> draft-bonica-tunneltrace-02.txt
> > >> draft-fontana-ccamp-gmpls-g709-00.txt
> > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> > >> draft-many-ccamp-gmpls-framework-00.txt
> > >> draft-many-oli-reqts-00.txt
> > >>
> > >> 3) Comment on MIB overview.
> > >>
> > >> 4) Two week Last Call comments on
> > >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> > >>
> > >> 5) Last Call readiness of
> > >> draft-ietf-ccamp-gmpls-architecture-00.txt
> > >> draft-ietf-ccamp-lmp-01.txt
> > >>
> > >> Thanks,
> > >> Kireeti.
> > >>
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
> > >
> > >
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Sat, 20 Oct 2001 07:09:52 -0700
Date: Sat, 20 Oct 2001 16:05:01 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Zhi-Wei Lin <[email-masked]>
CC: manoj juneja <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------49A55E47AED14BB4283B6C9A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Zhi,

I would like to remember you something here: the SDH/Sonet I-D is not 
1) a textbook on how to use GMPLS-SIG but must be understood an 
   additional document complementing the signalling one
2) a tutorial on Sonet/SDH (a framework has been proposed for that
   purpose)

We have spent hard time together with the SDH/Sonet I-D co-authors in
order to find the best balance between reproducing well known SDH/Sonet
concepts and paragraphs really providing an added value in this document

Of course we can not make 100% people happy (even between the list of
30 co-authors) some of us found there was too much explanations while 
others were requesting more content.

Therefore for the non-covered content we are referencing the appropriate
document either it comes from ITU or IETF. Please understand that we
can not wait until everybody in this world has no question anymore or a
full understanding on any technical detail in order to go forward with
these documents.

Thanks for your "virtual" understanding,
Dimitri. 
 
Zhi-Wei Lin wrote:
> 
> Hi Manoj,
> 
> I agree with many of your points. I actually submitted an I-D several
> months ago (I think it's expired) that proposes some text to add to the
> GMPLS SONET/SDH on the rules for setting different values, such as for
> STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the
> range of acceptable value of X, etc.
> 
> My rationale at that time was that not everyone is a SONET/SDH expert
> and instead of asking them to look somewhere else and dig through those
> documents to find the answer, if we can provide them in the GMPLS set of
> drafts it would be extremely useful for the entire IETF community and
> would help clarify the usage of these parameters. But unfortunately if
> you were at the meeting at the time, it wasn't accepted because some
> folks thought that these were obvious or that this info is not needed
> because they can find it in other places referenced...
> 
> If you have the old drafts, the file was:
> draft-lin-ccamp-ipo-common-label-request-01
> 
> But anyway...people will just have to read all the referenced documents
> to understand how to use the different parameters...
> 
> Zhi
> 
> manoj juneja wrote:
> 
> > Hi Kireeti,
> >            I am not an active member of IETF but a regular reader of
> > GMPLS drafts. I am not sure how much weight my mail will carry but as a
> > regular reader of these drafts, I recommend the following points should
> > be made clear in the documents before proceeding to the last call.
> >
> >
> > 1. Can someone please tell me the usage of bandwidth encoding
> > parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> > will be drived from the signal type field. How the bandwidth encoding
> > type will be interpreted in case of other LSP encoding types (lambda,
> > waveband, fiber etc) ? The draft should list down the cases in which the
> > bandwidth encoding type is to be filled.
> >
> > 2. Usage of Label Set :
> >        There are cases mentioned in the draft which explains the usage
> > of label set. It should also mention that the range of labels in
> > SDH/SONET does not make sense. Ranges in label set are applicable in
> > case of waveband/lambda switching etc. The range in label set is valid
> > in SDH/SONET only if there is one element in the range i.e. start range
> > and end range should be same.
> >
> > 3. There are couple of scenarios where there can be contention for
> > establishing bi-directional LSPs. All the scenarios are not listed in
> > the document. If it is not possible to list all the scenarios then the
> > draft should say that this is one of the example scenario. The
> > contention can also be possible in case where same label set and
> > upstream label are used in both the directions.
> >
> > 4. As per OIF, the carrier requirement is that SDH LSPs should be
> > either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> > supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS
> > has different set of carrier requirements in this regard ?
> >
> > 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
> > an addendum to the draft.
> >
> > 6. The relation between switching capability and LSP encoding type
> > should be clearly explained in the drafts. As the switching capability
> > field was added very late (just 2 months back) in the drafts,
> > specific reason should be mentioned for its addition.
> >
> > Regards,
> > manoj.
> >
> >
> >
> >> From: Kireeti Kompella <[email-masked]>
> >> To: [email-masked]
> >> Subject: Moving right along ...
> >> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
> >>
> >> Despite the energetic subject line, we the WG chairs have been
> >> lax in our duties.  So, here goes:
> >>
> >> Lou has submitted the latest versions of the generalized
> >> signaling documents quite some time ago (thanks, Lou):
> >>
> >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> >> draft-ietf-mpls-generalized-signaling-06.txt
> >>
> >> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> >>
> >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >>
> >> All of these should have addressed the issues raised in the earlier
> >> versions.  Please read the new versions, and send your comments to
> >> the list by Tuesday Oct 23.  At that point, when the final round
> >> of comments have been addressed, these docs will go to IESG Last
> >> Call.  If any one objects to sending these docs to IESG Last Call,
> >> raise your issues now.
> >>
> >> I see that the GMPLS architecture document is a CCAMP WG doc, but
> >> the minutes say that we should look for consensus on the list.  So,
> >> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> >> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> >> will progress to WG Last Call.
> >>
> >> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> >> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> >> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> >> list know what your thinking is on these.  (BTW, both these docs
> >> were to have some edits done.  If the authors could do that before
> >> the next IETF, we can try to make more progress then.)
> >>
> >> The MIB overview doc was recently posted.  Please read and comment
> >> to the list.
> >>
> >> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> >> was generally thought to be useful; it will be published as a
> >> CCAMP informational doc.  This begins a two week Last Call on
> >> the doc, ending Tuesday Oct 30.
> >>
> >> There was no consensus on whether the GMPLS framework should be
> >> a CCAMP WG doc.  Please indicate your pleasure.
> >>
> >> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> >> raised that this draft is close to ready for WG Last Call.  Please
> >> review it, and let us know if you disagree.
> >>
> >> The OLI requirements doc was broadly accepted.  Please let the
> >> list know if you think this doc should be a WG doc.
> >>
> >> It's still open whether we (the IETF) should be working on
> >> LMP-WDM.  I urge the authors to keep on working on the doc, and
> >> keeping it in sync with LMP; however, we will postpone making it
> >> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> >> happen in Salt Lake City.
> >>
> >> There was reasonable interest in the tunnel trace requirements
> >> doc.  Let's formalize this: do you think this should be made a
> >> CCAMP WG document?
> >>
> >> Summary:
> >>
> >> 1) Final comments and IESG Last Call readiness for:
> >> draft-ietf-mpls-generalized-cr-ldp-04.txt
> >> draft-ietf-mpls-generalized-rsvp-te-05.txt
> >> draft-ietf-mpls-generalized-signaling-06.txt
> >> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> >> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> >>
> >> 2) Should the following documents be CCAMP WG docs?
> >> draft-bonica-tunneltrace-02.txt
> >> draft-fontana-ccamp-gmpls-g709-00.txt
> >> draft-ietf-ccamp-gmpls-architecture-00.txt
> >> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> >> draft-many-ccamp-gmpls-framework-00.txt
> >> draft-many-oli-reqts-00.txt
> >>
> >> 3) Comment on MIB overview.
> >>
> >> 4) Two week Last Call comments on
> >> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> >>
> >> 5) Last Call readiness of
> >> draft-ietf-ccamp-gmpls-architecture-00.txt
> >> draft-ietf-ccamp-lmp-01.txt
> >>
> >> Thanks,
> >> Kireeti.
> >>
> >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> >
> >
--------------49A55E47AED14BB4283B6C9A
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------49A55E47AED14BB4283B6C9A--

Delivery-date: Sat, 20 Oct 2001 04:37:33 -0700
Date: Sat, 20 Oct 2001 07:32:58 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Manoj,

I agree with many of your points. I actually submitted an I-D several 
months ago (I think it's expired) that proposes some text to add to the 
GMPLS SONET/SDH on the rules for setting different values, such as for 
STS-1-Xv, what is the range of value of X, for VC-4-Xv, what is the 
range of acceptable value of X, etc.

My rationale at that time was that not everyone is a SONET/SDH expert 
and instead of asking them to look somewhere else and dig through those 
documents to find the answer, if we can provide them in the GMPLS set of 
drafts it would be extremely useful for the entire IETF community and 
would help clarify the usage of these parameters. But unfortunately if 
you were at the meeting at the time, it wasn't accepted because some 
folks thought that these were obvious or that this info is not needed 
because they can find it in other places referenced...

If you have the old drafts, the file was:
draft-lin-ccamp-ipo-common-label-request-01

But anyway...people will just have to read all the referenced documents 
to understand how to use the different parameters...

Zhi

manoj juneja wrote:

> Hi Kireeti,
>            I am not an active member of IETF but a regular reader of
> GMPLS drafts. I am not sure how much weight my mail will carry but as a
> regular reader of these drafts, I recommend the following points should
> be made clear in the documents before proceeding to the last call.
> 
> 
> 1. Can someone please tell me the usage of bandwidth encoding
> parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
> will be drived from the signal type field. How the bandwidth encoding
> type will be interpreted in case of other LSP encoding types (lambda, 
> waveband, fiber etc) ? The draft should list down the cases in which the 
> bandwidth encoding type is to be filled.
> 
> 2. Usage of Label Set :
>        There are cases mentioned in the draft which explains the usage
> of label set. It should also mention that the range of labels in
> SDH/SONET does not make sense. Ranges in label set are applicable in
> case of waveband/lambda switching etc. The range in label set is valid
> in SDH/SONET only if there is one element in the range i.e. start range
> and end range should be same.
> 
> 3. There are couple of scenarios where there can be contention for
> establishing bi-directional LSPs. All the scenarios are not listed in
> the document. If it is not possible to list all the scenarios then the
> draft should say that this is one of the example scenario. The
> contention can also be possible in case where same label set and
> upstream label are used in both the directions.
> 
> 4. As per OIF, the carrier requirement is that SDH LSPs should be
> either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
> supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS
> has different set of carrier requirements in this regard ?
> 
> 5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
> an addendum to the draft.
> 
> 6. The relation between switching capability and LSP encoding type
> should be clearly explained in the drafts. As the switching capability
> field was added very late (just 2 months back) in the drafts,
> specific reason should be mentioned for its addition.
> 
> Regards,
> manoj.
> 
> 
> 
>> From: Kireeti Kompella <[email-masked]>
>> To: [email-masked]
>> Subject: Moving right along ...
>> Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
>>
>> Despite the energetic subject line, we the WG chairs have been
>> lax in our duties.  So, here goes:
>>
>> Lou has submitted the latest versions of the generalized
>> signaling documents quite some time ago (thanks, Lou):
>>
>> draft-ietf-mpls-generalized-cr-ldp-04.txt
>> draft-ietf-mpls-generalized-rsvp-te-05.txt
>> draft-ietf-mpls-generalized-signaling-06.txt
>>
>> Also, Eric has posted the SONET/SDH documents (merci, Eric):
>>
>> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
>> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
>>
>> All of these should have addressed the issues raised in the earlier
>> versions.  Please read the new versions, and send your comments to
>> the list by Tuesday Oct 23.  At that point, when the final round
>> of comments have been addressed, these docs will go to IESG Last
>> Call.  If any one objects to sending these docs to IESG Last Call,
>> raise your issues now.
>>
>> I see that the GMPLS architecture document is a CCAMP WG doc, but
>> the minutes say that we should look for consensus on the list.  So,
>> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
>> arrived at a consensus, remind me :-))  If nothing is heard, the doc
>> will progress to WG Last Call.
>>
>> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
>> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
>> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
>> list know what your thinking is on these.  (BTW, both these docs
>> were to have some edits done.  If the authors could do that before
>> the next IETF, we can try to make more progress then.)
>>
>> The MIB overview doc was recently posted.  Please read and comment
>> to the list.
>>
>> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
>> was generally thought to be useful; it will be published as a
>> CCAMP informational doc.  This begins a two week Last Call on
>> the doc, ending Tuesday Oct 30.
>>
>> There was no consensus on whether the GMPLS framework should be
>> a CCAMP WG doc.  Please indicate your pleasure.
>>
>> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
>> raised that this draft is close to ready for WG Last Call.  Please
>> review it, and let us know if you disagree.
>>
>> The OLI requirements doc was broadly accepted.  Please let the
>> list know if you think this doc should be a WG doc.
>>
>> It's still open whether we (the IETF) should be working on
>> LMP-WDM.  I urge the authors to keep on working on the doc, and
>> keeping it in sync with LMP; however, we will postpone making it
>> a CCAMP WG doc until the issue is resolved.  Hopefully that will
>> happen in Salt Lake City.
>>
>> There was reasonable interest in the tunnel trace requirements
>> doc.  Let's formalize this: do you think this should be made a
>> CCAMP WG document?
>>
>> Summary:
>>
>> 1) Final comments and IESG Last Call readiness for:
>> draft-ietf-mpls-generalized-cr-ldp-04.txt
>> draft-ietf-mpls-generalized-rsvp-te-05.txt
>> draft-ietf-mpls-generalized-signaling-06.txt
>> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
>> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
>>
>> 2) Should the following documents be CCAMP WG docs?
>> draft-bonica-tunneltrace-02.txt
>> draft-fontana-ccamp-gmpls-g709-00.txt
>> draft-ietf-ccamp-gmpls-architecture-00.txt
>> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
>> draft-many-ccamp-gmpls-framework-00.txt
>> draft-many-oli-reqts-00.txt
>>
>> 3) Comment on MIB overview.
>>
>> 4) Two week Last Call comments on
>> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
>>
>> 5) Last Call readiness of
>> draft-ietf-ccamp-gmpls-architecture-00.txt
>> draft-ietf-ccamp-lmp-01.txt
>>
>> Thanks,
>> Kireeti.
>>
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 

Delivery-date: Fri, 19 Oct 2001 15:37:24 -0700
Date: Sat, 20 Oct 2001 00:35:27 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Zhi-Wei Lin <[email-masked]>
CC: Yanhe Fan <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------4D507C67C8AA36EDE4DFDCCC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Just some months ago, you asked the same question
but it was between AS's rather nodes. John Drake 
responded to your question at that time... (sorry 
i can't find it back otherwise i would have kindly
refreshed your memory...).

Thanks,
Dimitri.

Zhi-Wei Lin wrote:
> 
> Hi Yanhe,
> 
> Maybe there is some misunderstanding. Node B is strictly not GMPLS. It
> is simply part of the network that made up the "dumb" pipe. And because
> the control plane control channel is separate, A and C can be adjacent
> without ever knowing who B is or that even B existed. From A and C's
> point of view, the network looks like:
> 
>   A ----- C
> 
> Think of the case of how a BGP sees an area. If an area is made up of:
> 
>   A -- B -- C
> 
> and B is internal router, does BGP "see" B?
> 
> Zhi
> 
> Yanhe Fan wrote:
> 
> > Hi, Zhi
> >
> >
> >>For the label value for SONET/SDH or the label description in the
> >>generic draft, the label is defined as directly representing the
> >>"timeslot". Now if I have a control plane controlled transport network
> >>that goes through a ADM that is not control plane controlled, as:
> >>
> >>
> >>+--------+               +--------+               +--------+
> >>|        | ---1--------- |        | ----1-------- |        |
> >>|        | ---2--------- |        | ----2-------- |        |
> >>|  A     | ---3--------- |   B    | ----3-------- |   C    |
> >>|        | ---4--------- |        | ----4-------- |        |
> >>|        | ---5--------- |        | ----5-------- |        |
> >>+--------+               +--------+               +--------+
> >>
> >>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
> >>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
> >>has labels 1,2,3,4,5 incoming.
> >>
> >>Now imagine that at B, it actually has a fixed cross-connect that
> >>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
> >>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
> >>
> >>Now when A GMPLS sends a message to C, the label it uses is "1".
> >>However, the connection/LSP associated with timeslot "1" is actually the
> >>label of timeslot "2" at C. </z>
> >>
> >
> > In this case, you're trying to use GMPLS to setup an LSP cross a node (B)
> > which can't understand GMPLS.
> >
> > Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using
> > GMPLS if B can't understand GMPLS?
> >
> > Now imagine A and B are LSRs, and B is a conventional router (can't
> > understand
> > MPLS), can you setup an LSP A-B-C?
> >
> > Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> > understand PNNI at all?
> >
> > My point is that in order to make you case work, some additional work need
> > to
> > be done besie simply using GMPLS as singnaling protocol, becase some node on
> > the path is not GMPLS speakers. A and C needs the info of time slot aligment
> >
> > between them. This can be done by some configurations, some link management
> > protocls (LMP maybe) etc. As long as A and C have this piece of info,
> > eveything
> > works fine.
> >
> > Yanhe
> >
--------------4D507C67C8AA36EDE4DFDCCC
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------4D507C67C8AA36EDE4DFDCCC--

Delivery-date: Fri, 19 Oct 2001 15:08:40 -0700
Date: Fri, 19 Oct 2001 18:08:54 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
CC: John Drake <[email-masked]>, Maarten Vissers <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi Dimitri,

Yes thank you. I wasn't saying implying that I want it now! I was just 
pointing out that this was something that I am working with Eric already 
to resolved (if you see my first email).

Thanks for your help! I appreciate it!

Zhi

Dimitri Papadimitriou wrote:

> All,
> 
> Just to mention here that this request is under evaluation
> we have never reject this proposal but only answer for some
> time in order to check for consistency with the existing 
> content of the document. It is not because we are speaking 
> "optical" stuff that we can integrate content at the speed 
> of light ;-)
> 
> It has been received when the document was just issued this
> is why not included in the current version. I hope this 
> non-issue is closed.
> 
> Thanks for your understanding and your patience,
> Dimitri.
> 
> Zhi-Wei Lin wrote:
> 
>>Hi John,
>>
>>It wasn't that I wanted it without explanation. The explanation is that
>>M0/M1 is carried transparently across the network without changes at any
>>intermediate points. I thought it was obvious that under "transparent"
>>attribute, specifying this is automatically assumed transparent unless
>>there is some exception cases about them...
>>
>>Hope this explains. I wasn't trying to "ram" this down anyone's
>>throat...BTW, you can just refer to me as "Zhi" :-)
>>
>>Zhi
>>
>>John Drake wrote:
>>
>>
>>>Maarten,
>>>
>>>I'm sorry, my comment was more procedural than technical.  If everyone
>>>agrees that it is necessary, then obviously it should be added.  Zhi-Wei
>>>didn't try to gain consensus for adding it, he just said that he wanted it
>>>with no explanation, as far as I could tell.
>>>
>>>Thanks,
>>>
>>>John
>>>
>>>-----Original Message-----
>>>From: Maarten Vissers [mailto:[email-masked]]
>>>Sent: Thursday, October 18, 2001 1:32 PM
>>>To: John Drake
>>>Cc: Zhi-Wei Lin; Kireeti Kompella; [email-masked]
>>>Subject: Re: Moving right along ...
>>>
>>>
>>>John,
>>>
>>>Semi transparent STM-N signal transport is typically required to support the
>>>following applications:
>>>
>>>* DCN application: D1-D3, D4-D12
>>>* MS protection application: J0, K1, K2, B2
>>>* Other:
>>>  [Orderwire] E1, E2,
>>>  [User Channel] F1,
>>>  [Single-ended MSn Performance Monitoring] M0, M1 (in addition to
>>>                                          J0, K2[6-8] and B2)
>>>  [RSn Performance Monitoring] B1 (in addition to J0)
>>>
>>>So M0/M1 transport is required in order to support single-ended MSn
>>>performance
>>>monitoring.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>John Drake wrote:
>>>
>>>
>>>>-----Original Message-----
>>>>From: Zhi-Wei Lin [mailto:[email-masked]]
>>>>Sent: Thursday, October 18, 2001 5:47 AM
>>>>To: Kireeti Kompella
>>>>Cc: [email-masked]
>>>>Subject: Re: Moving right along ...
>>>>
>>>>SNIPPED
>>>>
>>>>
>>>>
>>>>>As for the rest, let me juxtapose your comments on switching type
>>>>>and M0/M1; I will say nothing, hoping that the juxtaposition will
>>>>>speak for itself.
>>>>>
>>>>>
>>>>>
>>>><z>The switching type is in a "standard" document, while the M0/M1 is in
>>>>the "non-standard" document. I will let that speak for itself as well.
>>>>And by the way, when you made this comment are making it as a chair or
>>>>as a contributor?</z>
>>>>
>>>>JD:  Actually, the signalling drafts are on exactly the same technical
>>>>footing as the "non-standard" draft,
>>>>so I think your attempt to draw a distinction between the two is specious
>>>>
>>>>
>>>at
>>>
>>>
>>>>best.  Once again, a feature
>>>>or capability is added if the community as a whole decides, through a
>>>>process of rough consensus, that it
>>>>should be added.  No one other than you has indicated an issue with
>>>>switching type and I haven't seen a groundswell
>>>>of support for M0/M1.
>>>>
>>>>
>>>>
>>>>Zhi
>>>>
>>>>
>>>
>>>

Delivery-date: Fri, 19 Oct 2001 15:04:19 -0700
Date: Fri, 19 Oct 2001 18:04:00 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Yangguang Xu <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Hello,

Just to be clear, I am definitely one of the uninformed readers since I 
have joined IETF not so long ago (not everyone is part of IETF when it 
first started unfortunately). So Yakov, if you would be so kind as to 
inform an uninformed reader that would be very very much appreciated.

Thanks in advance for your answers!

Zhi

Yangguang Xu wrote:

> Indeed, you didn't answer my questions. Instead of informed readers, more
> important is to have better informed writers. 
> 
> BTW, I have no intention to let you design my product at all. 
> 
> Yangguang
> 
> Yakov Rekhter wrote:
> 
>>Yangguang,
>>
>>
>>>Yakov,
>>>
>>>Further questions in-line. Regards,
>>>
>>Further responses in-line...
>>
>>
>>>Yangguang
>>>
>>>
>>>>Couple of points:
>>>>
>>>>(1) First of all, you do run RSVP Hello between C and F.
>>>>
>>>Is this specified somewhere? Or it's your proposal.
>>>
>>What I mentioned in the above should be abundantly obvious to the
>>informed reader of RSVP and LSP Hierarchy specs.
>>
>>
>>>Then, is there a scalability issue here?
>>>
>>No.
>>
>>
>>>Also, C and F could be thousands mile away (in the transport
>>>network) and the control channel bandwidth is expensive.
>>>
>>GMPLS assumes that control channel is more than just 56Kbits/sec link.
>>
>>Or to put it differently, control channels used by GMPLS have more than
>>enough capacity for RSVP Hellos.
>>
>>
>>>>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
>>>>be able to recover the Interface ID it assigns to L1 from
>>>>a combination of (a) the OSPF/ISIS link state database that
>>>>F would recover, and (b) the Forward Interface ID (the one
>>>>assigned by C).
>>>>
>>>Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it
>>>has to recover its FA info first. How?
>>>
>>The answer should be abundantly obvious to the informed reader.
>>
>>And to make it crystal clear, I have no intention in designing your
>>products for you.
>>
>>
>>>>>Let us say the node can resynchronize its neighbor if
>>>>>the neighbor restarts and requests state recovery. But
>>>>>the issue is how a node can advertise that it does not
>>>>>need recovery since all its state was preserved?
>>>>>
>>>>By treating is the same way as the way the spec handles
>>>>control channel fault.
>>>>
>>>>
>>>If a node can recover states from NVRAM or OS (this solution is
>>>cheaper and have been implemented). It may not implement the spec.
>>>How could a neighboring node, which implements the spec, not tear
>>>down data connections mistakenly? Similar to a backward compatibility
>>>problem, even not.
>>>
>>Stating the obvious: interoperability with a node that doesn't implement
>>the spec is outside the scope of the spec.
>>
>>
>>>>>RECOVERY LABEL does not come into picture unless the node
>>>>>that is upstream to the restarting node has already received
>>>>>a Resv.
>>>>>
>>>>Wrong. Quoting 9.5.3:
>>>>
>>>>   Upon detecting a restart with a neighbor that supports state
>>>>   recovery, a node SHOULD refresh all Path state shared with that
>>>>   neighbor.
>>>>
>>>>So, as you can hopefully see from the above, the upstream node doesn't
>>>>wait until it receives a Resv.
>>>>
>>>>
>>>Then this may not meet carriers' requirement. (see IPO carriers' requirement)
>>>Again, back to the telecom world (sorry about this, yet we are talking about
>>>GMPLS), typically only the established pathes are preserved. Pending requests
>>>may be purged/aborted. Then how?
>>>
>>Note the verb is "SHOULD", not "MUST". The rest should be
>>obvious to the informed reader.
>>
>>
>>>>>In case of PSC devices, it may be OK to remove state that
>>>>>is not resynchronized at the end of the recovery period,
>>>>>and the recovery period advertised might reflect that.
>>>>>But for LSPs in transport networks, one might want to
>>>>>have a different recovery period to avoid any LSP from
>>>>>going down because of recovery timer expiry.
>>>>>
>>>>There is no requirement for a node to advertise exactly the
>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces
>>>>the node could advertise that it will remove the state that
>>>>isn't syncronized at the end of the recovery period, while
>>>>on the TDM interface precisely the same node could advertise
>>>>that the LSPs would be kept even after the recovery time expires.
>>>>
>>>>
>>>So, restart_cap is per interface based?
>>>
>>yes.
>>
>>
>>>Is the spec going to be enhanced/clarified?
>>>
>>The current spec need not be enhanced/clarified - what I mentioned in the
>>above should be abundantly obvious to the informed reader.
>>
>>
>>>>>The first problems seems to be there still - consider two
>>>>>adjacent nodes restarting.  They both act both as the restarting
>>>>>node as well as the neighbor to the restarting node. So, once
>>>>>they learn the state from the upstream neighbor, do they use
>>>>>suggested label or the recovery label when they send the path
>>>>>message to the just restarted downstream neighbor?
>>>>>
>>>>The recovery label.
>>>>
>>>>The following should be added to the existing text from the document:
>>>>
>>>>   In the special case where a restarting node also has a restating
>>>>   downstream neighbor, a Recovery_Label object should be used instead
>>>>   of a Suggested_Label object.
>>>>
>>>How does a recovering NE know that its neighbor is also recovering? it may
>>>lose the instance number totally
>>>
>>It's advertised in the neighbor's hellos.
>>
>>Yakov.
>>
> 

Delivery-date: Fri, 19 Oct 2001 15:03:37 -0700
Date: Fri, 19 Oct 2001 18:01:18 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Yanhe Fan <[email-masked]>
CC: John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi Yanhe,

Maybe there is some misunderstanding. Node B is strictly not GMPLS. It 
is simply part of the network that made up the "dumb" pipe. And because 
the control plane control channel is separate, A and C can be adjacent 
without ever knowing who B is or that even B existed. From A and C's 
point of view, the network looks like:

  A ----- C

Think of the case of how a BGP sees an area. If an area is made up of:

  A -- B -- C

and B is internal router, does BGP "see" B?

Zhi

Yanhe Fan wrote:

> Hi, Zhi
> 
> 
>>For the label value for SONET/SDH or the label description in the 
>>generic draft, the label is defined as directly representing the 
>>"timeslot". Now if I have a control plane controlled transport network 
>>that goes through a ADM that is not control plane controlled, as:
>>
>>
>>+--------+               +--------+               +--------+
>>|        | ---1--------- |        | ----1-------- |        |
>>|        | ---2--------- |        | ----2-------- |        |
>>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>>|        | ---4--------- |        | ----4-------- |        |
>>|        | ---5--------- |        | ----5-------- |        |
>>+--------+               +--------+               +--------+
>>
>>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at 
>>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C 
>>has labels 1,2,3,4,5 incoming.
>>
>>Now imagine that at B, it actually has a fixed cross-connect that 
>>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to 
>>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>>
>>Now when A GMPLS sends a message to C, the label it uses is "1". 
>>However, the connection/LSP associated with timeslot "1" is actually the 
>>label of timeslot "2" at C. </z>
>>
> 
> In this case, you're trying to use GMPLS to setup an LSP cross a node (B)
> which can't understand GMPLS.
> 
> Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using 
> GMPLS if B can't understand GMPLS?
> 
> Now imagine A and B are LSRs, and B is a conventional router (can't
> understand
> MPLS), can you setup an LSP A-B-C?
> 
> Now imagine A, B and C are ATM switches, can you setup a svc if B can't
> understand PNNI at all?
> 
> My point is that in order to make you case work, some additional work need
> to
> be done besie simply using GMPLS as singnaling protocol, becase some node on
> the path is not GMPLS speakers. A and C needs the info of time slot aligment
> 
> between them. This can be done by some configurations, some link management 
> protocls (LMP maybe) etc. As long as A and C have this piece of info,
> eveything
> works fine.
> 
> Yanhe
> 

Delivery-date: Fri, 19 Oct 2001 13:04:26 -0700
From: Jonathan Lang <[email-masked]>
To: "'Sameh M. Elsharkawy'" <[email-masked]>, [email-masked]
Cc: Jonathan Lang <[email-masked]>
Subject: RE: LMP Question: fault management messages
Date: Fri, 19 Oct 2001 12:58:52 -0700

Sameh,
  To address George's comment, we plan to modify the text as follows  (new
text in <<text>>):

Section 6.2 Fault Localization Procedure

...

As part of the fault localization, a downstream node (downstream in terms of
data flow) that detects data link failures will send a ChannelStatus message
to its upstream neighbor <<indicating that a failure has occurred>>
(bundling together the notification of all of the failed data links).  An
upstream node that receives the ChannelStatus message MUST send a
ChannelStatusAck message to the downstream node indicating it has received
the ChannelStatus message.  The upstream node should correlate the failure
to see if the failure is also detected locally (including ingress side) for
the corresponding LSP(s).  If, for example, the failure is clear on the
input of the upstream node or internally, then the upstream node will have
localized the failure.  <<Once the failure is correlated, the upstream node
SHOULD send a ChannelStatus message to the downstream node indicating that
the channel is failed or is ok.  If a ChannelStatus message is not received
by the downstream node, it SHOULD send a ChannelStatusRequest message for
the channel in question.>>  Once the failure has been localized, the
signaling protocols can be used to initiate span or path
protection/restoration procedures.

Thanks,
Jonathan

> -----Original Message-----
> From: Sameh M. Elsharkawy [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 12:46 PM
> To: [email-masked]
> Subject: RE: LMP Question: fault management messages
> 
> 
> 
> I fully agree with this comment since the removal of ChannelFailNack
message
> from the fault management procedure prevent downstream nodes from
localizing
> the failure on their input ports. If signaling is responsible for
> propagating the information, this will delay the recovery process, until
the
> information   is disseminated by signaling.
> 
> Thanks
> 
> Sameh M. Elsharkawy
> Senior Member of Technical Staff
> FirstWave Intelligent Optical Networks
> 6301 Ivy Lane, Suite 700, Greenbelt, MD 20770
> (301) 345-2137 x1034
> 
> 
> 
> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Tuesday, October 09, 2001 1:57 PM
> To: [email-masked]
> Subject: LMP Question: fault management messages
> 
> 
> I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus
> message and its friends.
> 
> In Section 6.2. Fault Localization Procedure, LMP states "Once the
> failure has been localized, the signaling protocols can be used to
> initiate span or path protection/restoration procedures". This is
> workable and signalling can reroute around the link or the path,
> releasing resources as appropriate. However, with the departure of the
> ChannelFailNack, the node at the receive end of the faulty 
> link does not
> find out about the fault from either the signalling protocol 
> or LMP. As
> bidirectional paths are allocated, there is a chance that the failed
> link will be allocated to a subsequent call through this node.
> 
> Furthermore, assuming a signalling protocol has established paths, and
> indicated their active or backup status with the Administrative Status
> object in GMPLS, there does not appear to be any need in LMP for the
> Active/Deactive indications in the CHANNEL_STATUS object. This
> information has already been conveyed by the signalling 
> protocol during
> path establishment.  
> 
> If my understanding is correct, ChannelFailNack functionality 
> is needed
> and the Active and Deactive values of the CHANNEL_STATUS 
> object are not.
> 
> Regards,
> George R. Young
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 

Delivery-date: Fri, 19 Oct 2001 13:00:34 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: Moving right along ...
Date: Fri, 19 Oct 2001 12:57:30 -0700

Hi Kireeti,
            I am not an active member of IETF but a regular reader of
GMPLS drafts. I am not sure how much weight my mail will carry but as a
regular reader of these drafts, I recommend the following points should
be made clear in the documents before proceeding to the last call.

1. Can someone please tell me the usage of bandwidth encoding
parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
will be drived from the signal type field. How the bandwidth encoding
type will be interpreted in case of other LSP encoding types (lambda, 
waveband, fiber etc) ? The draft should list down the cases in which the 
bandwidth encoding type is to be filled.

2. Usage of Label Set :
        There are cases mentioned in the draft which explains the usage
of label set. It should also mention that the range of labels in
SDH/SONET does not make sense. Ranges in label set are applicable in
case of waveband/lambda switching etc. The range in label set is valid
in SDH/SONET only if there is one element in the range i.e. start range
and end range should be same.

3. There are couple of scenarios where there can be contention for
establishing bi-directional LSPs. All the scenarios are not listed in
the document. If it is not possible to list all the scenarios then the
draft should say that this is one of the example scenario. The
contention can also be possible in case where same label set and
upstream label are used in both the directions.

4. As per OIF, the carrier requirement is that SDH LSPs should be
either VC-4 or VC-3 and no lower than that viz. VC-11/VC-12. GMPLS
supports lower order SDH LSPs i.e. VC-11/VC12 etc. Does this mean GMPLS
has different set of carrier requirements in this regard ?

5. I strongly recommend to add {EDCBA} ==> {SUKLM} conversion table as
an addendum to the draft.

6. The relation between switching capability and LSP encoding type
should be clearly explained in the drafts. As the switching capability
field was added very late (just 2 months back) in the drafts,
specific reason should be mentioned for its addition.

Regards,
manoj.

>From: Kireeti Kompella <[email-masked]>
>To: [email-masked]
>Subject: Moving right along ...
>Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
>
>Despite the energetic subject line, we the WG chairs have been
>lax in our duties.  So, here goes:
>
>Lou has submitted the latest versions of the generalized
>signaling documents quite some time ago (thanks, Lou):
>
>draft-ietf-mpls-generalized-cr-ldp-04.txt
>draft-ietf-mpls-generalized-rsvp-te-05.txt
>draft-ietf-mpls-generalized-signaling-06.txt
>
>Also, Eric has posted the SONET/SDH documents (merci, Eric):
>
>draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
>draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
>
>All of these should have addressed the issues raised in the earlier
>versions.  Please read the new versions, and send your comments to
>the list by Tuesday Oct 23.  At that point, when the final round
>of comments have been addressed, these docs will go to IESG Last
>Call.  If any one objects to sending these docs to IESG Last Call,
>raise your issues now.
>
>I see that the GMPLS architecture document is a CCAMP WG doc, but
>the minutes say that we should look for consensus on the list.  So,
>if you think this doc *shouldn't* be a WG doc, let us know.  (If we
>arrived at a consensus, remind me :-))  If nothing is heard, the doc
>will progress to WG Last Call.
>
>The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
>draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
>CCAMP WG docs; consensus at the meeting was Yes.  Please let the
>list know what your thinking is on these.  (BTW, both these docs
>were to have some edits done.  If the authors could do that before
>the next IETF, we can try to make more progress then.)
>
>The MIB overview doc was recently posted.  Please read and comment
>to the list.
>
>The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
>was generally thought to be useful; it will be published as a
>CCAMP informational doc.  This begins a two week Last Call on
>the doc, ending Tuesday Oct 30.
>
>There was no consensus on whether the GMPLS framework should be
>a CCAMP WG doc.  Please indicate your pleasure.
>
>draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
>raised that this draft is close to ready for WG Last Call.  Please
>review it, and let us know if you disagree.
>
>The OLI requirements doc was broadly accepted.  Please let the
>list know if you think this doc should be a WG doc.
>
>It's still open whether we (the IETF) should be working on
>LMP-WDM.  I urge the authors to keep on working on the doc, and
>keeping it in sync with LMP; however, we will postpone making it
>a CCAMP WG doc until the issue is resolved.  Hopefully that will
>happen in Salt Lake City.
>
>There was reasonable interest in the tunnel trace requirements
>doc.  Let's formalize this: do you think this should be made a
>CCAMP WG document?
>
>Summary:
>
>1) Final comments and IESG Last Call readiness for:
>draft-ietf-mpls-generalized-cr-ldp-04.txt
>draft-ietf-mpls-generalized-rsvp-te-05.txt
>draft-ietf-mpls-generalized-signaling-06.txt
>draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
>draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
>
>2) Should the following documents be CCAMP WG docs?
>draft-bonica-tunneltrace-02.txt
>draft-fontana-ccamp-gmpls-g709-00.txt
>draft-ietf-ccamp-gmpls-architecture-00.txt
>draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
>draft-many-ccamp-gmpls-framework-00.txt
>draft-many-oli-reqts-00.txt
>
>3) Comment on MIB overview.
>
>4) Two week Last Call comments on
>draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
>
>5) Last Call readiness of
>draft-ietf-ccamp-gmpls-architecture-00.txt
>draft-ietf-ccamp-lmp-01.txt
>
>Thanks,
>Kireeti.
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Fri, 19 Oct 2001 12:49:53 -0700
From: "Sameh M. Elsharkawy" <[email-masked]>
To: [email-masked]
Subject: RE: LMP Question: fault management messages
Date: Fri, 19 Oct 2001 15:46:27 -0400

I fully agree with this comment since the removal of ChannelFailNack message
from the fault management procedure prevent downstream nodes from localizing
the failure on their input ports. If signaling is responsible for
propagating the information, this will delay the recovery process, until the
information   is disseminated by signaling.

Thanks

Sameh M. Elsharkawy
Senior Member of Technical Staff
FirstWave Intelligent Optical Networks
6301 Ivy Lane, Suite 700, Greenbelt, MD 20770
(301) 345-2137 x1034

-----Original Message-----
From: George Young [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 1:57 PM
To: [email-masked]
Subject: LMP Question: fault management messages

I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus
message and its friends.

In Section 6.2. Fault Localization Procedure, LMP states "Once the
failure has been localized, the signaling protocols can be used to
initiate span or path protection/restoration procedures". This is
workable and signalling can reroute around the link or the path,
releasing resources as appropriate. However, with the departure of the
ChannelFailNack, the node at the receive end of the faulty link does not
find out about the fault from either the signalling protocol or LMP. As
bidirectional paths are allocated, there is a chance that the failed
link will be allocated to a subsequent call through this node.

Furthermore, assuming a signalling protocol has established paths, and
indicated their active or backup status with the Administrative Status
object in GMPLS, there does not appear to be any need in LMP for the
Active/Deactive indications in the CHANNEL_STATUS object. This
information has already been conveyed by the signalling protocol during
path establishment.  

If my understanding is correct, ChannelFailNack functionality is needed
and the Active and Deactive values of the CHANNEL_STATUS object are not.

Regards,
George R. Young
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

Delivery-date: Fri, 19 Oct 2001 10:47:19 -0700
Date: Fri, 19 Oct 2001 13:44:41 -0400
From: Gopal Kailad <[email-masked]>
To: Yakov Rekhter <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Yakov,

Thanks for the clarification.  My comments are inline:

Yakov Rekhter wrote:

>Gopal,
>
>>>>I have some questions/concerns on the restart mechanism as
>>>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
>>>>have listed them below.
>>>>
>>>>If a node that is terminating hierarchical LSPs restarts,
>>>>there is an ordering issue during resynchronization, since
>>>>the LSPs would depend on other FA-LSPs the interface IDs for
>>>>which would have been generated dynamically. So the
>>>>mechanism as described will not work, unless this
>>>>information is preserved across restarts - in which case we
>>>>might as well preserve other information as well, and avoid
>>>>resynchronization.
>>>>
>>>Since transit node of the FA-LSP does not see the RSVP
>>>messages that use the FA, we only need to consider
>>>the ingress and egress node. If the egress node restarts,
>>>the worst case is that its upstream node sends an ERO
>>>consisting a unrecognized interface address. Since the
>>>Path message will carry RECOVERY_LABEL (replacing
>>>SUGGESTED_LABEL), the egress node knows that it might
>>>not have complete information yet, and can hold on to
>>>the Path message until the FA-LSP is established.
>>>All the information is there, so implementation
>>>can be completely within the egress node. It does work,
>>>just not specified enough.
>>>
>>>Ingress node will have to know the dependency, so not
>>>a problem there.
>>>
>>Are you suggesting that in case of an ERO with an
>>unrecognized interface id, if the Path message also
>>carries a RECOVERY LABEL, the egress node can hold on
>>to it until later?  Note that there may not be a
>>RECOVERY LABEL - since this Path message is for a
>>hierarchical LSP, and the previous node may not be
>>directly connected in the control plane.  Here is an
>>example - There is an LSP L1 from C to F, and on top of
>>it there is an LSP L2 from A to G.
>>
>> L1:              C --- D --- E --- F
>> L2:  A --- B --- C --------------- F --- G
>>
>>When F restarts, C may not even know, unless HELLO
>>protocol is run between C and F.  Note that the
>>HELLO mechanism is intended for immediate neighbors.
>>
>>And even if the HELLO mechanism is extended, there
>>is the issue of interface id assigned by F.  F needs
>>to assign the same interface id upon restart so as
>>not to bring down the hierarchical LSPs set up on top
>>of L1 in 
>>the reverse direction (say an LSP from G to
>>B set up on top of L1.)  Where would F get this
>>information ?
>>
>
>Couple of points:
>
>(1) First of all, you do run RSVP Hello between C and F.
>

O.K.

>
>
>(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
>be able to recover the Interface ID it assigns to L1 from
>a combination of (a) the OSPF/ISIS link state database that
>F would recover, and (b) the Forward Interface ID (the one
>assigned by C).
>
True. One could either use IGP restart mechanism to relearn
this (I have other concerns on RSVP restart being dependent on
IGP restart, but that for later) or preserve this across restarts.
In either case,  you agree that RSVP restart depends on some
mechanism outside RSVP to help it along?  So RSVP needs a new
interface to get this mapping upon restarts, right? This is not
clear in the draft.

>
>
>>>>Also, let us consider a node that can preserve state across
>>>>restarts, and hence does not need its state to be synced by
>>>>its peer.  How will it advertise this in the RESTART_CAP
>>>>object?
>>>>
>>>We still need to resynchronize the state since the other
>>>side might have connections that are in progress. The
>>>
>>Let us say the node can resynchronize its neighbor if
>>the neighbor restarts and requests state recovery. But
>>the issue is how a node can advertise that it does not
>>need recovery since all its state was preserved?
>>
>
>By treating is the same way as the way the spec handles
>control channel fault.
>

True, but this does not help.  See below.

>
>
>>>reason for resynchronization is to make sure both side
>>>have done the same to the in-progress connections, not
>>>just to synchronize the established states.
>>>
>>>The value of the RESTART_CAP will set to non-zero values
>>>
>>RECOVERY LABEL does not come into picture unless the node
>>that is upstream to the restarting node has already received
>>a Resv.
>>
>
>Wrong. Quoting 9.5.3:
>
>   Upon detecting a restart with a neighbor that supports state
>   recovery, a node SHOULD refresh all Path state shared with that
>   neighbor.
>
>So, as you can hopefully see from the above, the upstream node doesn't 
>wait until it receives a Resv.
>
True - if you had read further, you would have noticed that
I have said the same thing that you have quoted :) -
but there will be no RECOVERY_LABEL unless a Resv has
been received, right?

It is possible that the downstream node, after programming
its forwarding path, restarted before sending the Resv.
This would result in the upstream node refreshing the Path
message without the Recovery Label, and the downstream
node eventually allocating a different label.  So essentially
it is a new LSP setup.

>
>
>>So it seems that the procedure is to resynchronize
>>established state? If Resv has not been received yet, there
>>will be a refresh of Path message, and the restarting node
>>will consider it as a new request, etc.  So can you elaborate
>>on "to make sure both side have done the same to the in
>>progress connections" ?
>>
>>>>If a node supports PSC as well as TDM or LSC interfaces, it
>>>>might want to advertise different set of parameters in the
>>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM
>>>>LSPs which form bearer channels in transport networks.
>>>>Currently this is not possible.
>>>>
>>>Can you give us explicit examples as to why and what do
>>>you gain by giving different values for PSC, TDM ?
>>>
>>In case of PSC devices, it may be OK to remove state that
>>is not resynchronized at the end of the recovery period,
>>and the recovery period advertised might reflect that.
>>But for LSPs in transport networks, one might want to
>>have a different recovery period to avoid any LSP from
>>going down because of recovery timer expiry.
>>
>
>There is no requirement for a node to advertise exactly the
>same Restart_Cap on all the interfaces. So, on PSC interfaces
>the node could advertise that it will remove the state that
>isn't syncronized at the end of the recovery period, while
>on the TDM interface precisely the same node could advertise
>that the LSPs would be kept even after the recovery time expires.
>

But to set up LSPs over TDM/LSC interfaces, the PSC interface
is going to be used for signaling - since control and data
planes are decoupled!  So, how will this help?

>
>
>>>>According to 9.5.1. (procedures for restarting LSR): "When
>>>>sending the corresponding outgoing Path message the node
>>>>SHOULD include a SUGGESTED_LABEL object with a label value
>>>>^^^^^^
>>>>matching the outgoing label from the now restored forwarding
>>>>entry."
>>>>
>>>>This has a conflict with 9.5.2.  Consider the case where
>>>>adjacent nodes B and C restart, and B has another adjacent
>>>>node A, and C has another adjacent node D.  B and C will get
>>>>resynced by A and D, and during this process, they will
>>>>resync. each other. While resyncing each other, they act as
>>>>neighbors of a restarting LSR, and hence according to 9.5.2,
>>>>MUST include the SUGGESTED_LABEL.
>>>>
>>>>Also according to 9.5.2: "During the recovery period, new
>>>>Path state being advertised to the restarted neighbor SHOULD
>>>>not include the SUGGESTED_LABEL object in the corresponding
>>>>outgoing Path message.  This will prevent the restarting
>>>>node
>>>> from erroneously reusing a saved forwarding entry."
>>>>
>>>>I guess this would mean that if suggested labels are used
>>>>during new LSP setup (as they are likely to be while
>>>>provisioning lightpaths - to reduce latency), then new LSP
>>>>setup will not be allowed during resyncing?
>>>>
>>>The use of RECOVERY_LABEL address all the above questions.
>>>
>>The first problems seems to be there still - consider two
>>adjacent nodes restarting.  They both act both as the restarting
>>node as well as the neighbor to the restarting node. So, once
>>they learn the state from the upstream neighbor, do they use
>>suggested label or the recovery label when they send the path
>>message to the just restarted downstream neighbor?
>>
>
>The recovery label.
>
>The following should be added to the existing text from the document:
>
>   In the special case where a restarting node also has a restating
>   downstream neighbor, a Recovery_Label object should be used instead
>   of a Suggested_Label object.
>
Since a restarting node may not be able to detect that a
downstream neighbor is restarting, I suggest it always use
a Recovery_Label object instead of a Suggested_Label object.

Gopal

>
>
>Yakov.
>
>

Delivery-date: Fri, 19 Oct 2001 08:42:19 -0700
Date: Fri, 19 Oct 2001 11:41:24 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Yakov Rekhter <[email-masked]>
CC: [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Indeed, you didn't answer my questions. Instead of informed readers, more
important is to have better informed writers. 

BTW, I have no intention to let you design my product at all. 

Yangguang

Yakov Rekhter wrote:
> 
> Yangguang,
> 
> > Yakov,
> >
> > Further questions in-line. Regards,
> 
> Further responses in-line...
> 
> > Yangguang
> >
> > > Couple of points:
> > >
> > > (1) First of all, you do run RSVP Hello between C and F.
> >
> > Is this specified somewhere? Or it's your proposal.
> 
> What I mentioned in the above should be abundantly obvious to the
> informed reader of RSVP and LSP Hierarchy specs.
> 
> > Then, is there a scalability issue here?
> 
> No.
> 
> > Also, C and F could be thousands mile away (in the transport
> > network) and the control channel bandwidth is expensive.
> 
> GMPLS assumes that control channel is more than just 56Kbits/sec link.
> 
> Or to put it differently, control channels used by GMPLS have more than
> enough capacity for RSVP Hellos.
> 
> > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > > be able to recover the Interface ID it assigns to L1 from
> > > a combination of (a) the OSPF/ISIS link state database that
> > > F would recover, and (b) the Forward Interface ID (the one
> > > assigned by C).
> >
> > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it
> > has to recover its FA info first. How?
> 
> The answer should be abundantly obvious to the informed reader.
> 
> And to make it crystal clear, I have no intention in designing your
> products for you.
> 
> > > > Let us say the node can resynchronize its neighbor if
> > > > the neighbor restarts and requests state recovery. But
> > > > the issue is how a node can advertise that it does not
> > > > need recovery since all its state was preserved?
> > >
> > > By treating is the same way as the way the spec handles
> > > control channel fault.
> > >
> >
> > If a node can recover states from NVRAM or OS (this solution is
> > cheaper and have been implemented). It may not implement the spec.
> > How could a neighboring node, which implements the spec, not tear
> > down data connections mistakenly? Similar to a backward compatibility
> > problem, even not.
> 
> Stating the obvious: interoperability with a node that doesn't implement
> the spec is outside the scope of the spec.
> 
> > > > RECOVERY LABEL does not come into picture unless the node
> > > > that is upstream to the restarting node has already received
> > > > a Resv.
> > >
> > > Wrong. Quoting 9.5.3:
> > >
> > >    Upon detecting a restart with a neighbor that supports state
> > >    recovery, a node SHOULD refresh all Path state shared with that
> > >    neighbor.
> > >
> > > So, as you can hopefully see from the above, the upstream node doesn't
> > > wait until it receives a Resv.
> > >
> >
> > Then this may not meet carriers' requirement. (see IPO carriers' requirement)
> > Again, back to the telecom world (sorry about this, yet we are talking about
> > GMPLS), typically only the established pathes are preserved. Pending requests
> > may be purged/aborted. Then how?
> 
> Note the verb is "SHOULD", not "MUST". The rest should be
> obvious to the informed reader.
> 
> > > > In case of PSC devices, it may be OK to remove state that
> > > > is not resynchronized at the end of the recovery period,
> > > > and the recovery period advertised might reflect that.
> > > > But for LSPs in transport networks, one might want to
> > > > have a different recovery period to avoid any LSP from
> > > > going down because of recovery timer expiry.
> > >
> > > There is no requirement for a node to advertise exactly the
> > > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > > the node could advertise that it will remove the state that
> > > isn't syncronized at the end of the recovery period, while
> > > on the TDM interface precisely the same node could advertise
> > > that the LSPs would be kept even after the recovery time expires.
> > >
> >
> > So, restart_cap is per interface based?
> 
> yes.
> 
> > Is the spec going to be enhanced/clarified?
> 
> The current spec need not be enhanced/clarified - what I mentioned in the
> above should be abundantly obvious to the informed reader.
> 
> > > > The first problems seems to be there still - consider two
> > > > adjacent nodes restarting.  They both act both as the restarting
> > > > node as well as the neighbor to the restarting node. So, once
> > > > they learn the state from the upstream neighbor, do they use
> > > > suggested label or the recovery label when they send the path
> > > > message to the just restarted downstream neighbor?
> > >
> > > The recovery label.
> > >
> > > The following should be added to the existing text from the document:
> > >
> > >    In the special case where a restarting node also has a restating
> > >    downstream neighbor, a Recovery_Label object should be used instead
> > >    of a Suggested_Label object.
> >
> > How does a recovering NE know that its neighbor is also recovering? it may
> > lose the instance number totally
> 
> It's advertised in the neighbor's hellos.
> 
> Yakov.

Delivery-date: Fri, 19 Oct 2001 08:38:43 -0700
To: Yangguang Xu <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) 
Date: Fri, 19 Oct 2001 08:34:48 -0700
From: Yakov Rekhter <[email-masked]>

Yangguang,

> Yakov,
> 
> Further questions in-line. Regards,

Further responses in-line...

> Yangguang
> 
> > Couple of points:
> > 
> > (1) First of all, you do run RSVP Hello between C and F.
>  
> Is this specified somewhere? Or it's your proposal. 

What I mentioned in the above should be abundantly obvious to the 
informed reader of RSVP and LSP Hierarchy specs.

> Then, is there a scalability issue here? 

No.

> Also, C and F could be thousands mile away (in the transport
> network) and the control channel bandwidth is expensive.

GMPLS assumes that control channel is more than just 56Kbits/sec link.

Or to put it differently, control channels used by GMPLS have more than 
enough capacity for RSVP Hellos.

> > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > be able to recover the Interface ID it assigns to L1 from
> > a combination of (a) the OSPF/ISIS link state database that
> > F would recover, and (b) the Forward Interface ID (the one
> > assigned by C).
> 
> Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it
> has to recover its FA info first. How?

The answer should be abundantly obvious to the informed reader.

And to make it crystal clear, I have no intention in designing your 
products for you.

> > > Let us say the node can resynchronize its neighbor if
> > > the neighbor restarts and requests state recovery. But
> > > the issue is how a node can advertise that it does not
> > > need recovery since all its state was preserved?
> > 
> > By treating is the same way as the way the spec handles
> > control channel fault.
> >
> 
> If a node can recover states from NVRAM or OS (this solution is
> cheaper and have been implemented). It may not implement the spec.
> How could a neighboring node, which implements the spec, not tear
> down data connections mistakenly? Similar to a backward compatibility
> problem, even not.

Stating the obvious: interoperability with a node that doesn't implement 
the spec is outside the scope of the spec.

> > > RECOVERY LABEL does not come into picture unless the node
> > > that is upstream to the restarting node has already received
> > > a Resv.
> > 
> > Wrong. Quoting 9.5.3:
> > 
> >    Upon detecting a restart with a neighbor that supports state
> >    recovery, a node SHOULD refresh all Path state shared with that
> >    neighbor.
> > 
> > So, as you can hopefully see from the above, the upstream node doesn't
> > wait until it receives a Resv.
> > 
> 
> Then this may not meet carriers' requirement. (see IPO carriers' requirement)
> Again, back to the telecom world (sorry about this, yet we are talking about
> GMPLS), typically only the established pathes are preserved. Pending requests
> may be purged/aborted. Then how?

Note the verb is "SHOULD", not "MUST". The rest should be
obvious to the informed reader.
  
> > > In case of PSC devices, it may be OK to remove state that
> > > is not resynchronized at the end of the recovery period,
> > > and the recovery period advertised might reflect that.
> > > But for LSPs in transport networks, one might want to
> > > have a different recovery period to avoid any LSP from
> > > going down because of recovery timer expiry.
> > 
> > There is no requirement for a node to advertise exactly the
> > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > the node could advertise that it will remove the state that
> > isn't syncronized at the end of the recovery period, while
> > on the TDM interface precisely the same node could advertise
> > that the LSPs would be kept even after the recovery time expires.
> >
> 
> So, restart_cap is per interface based? 

yes.

> Is the spec going to be enhanced/clarified?

The current spec need not be enhanced/clarified - what I mentioned in the
above should be abundantly obvious to the informed reader.

> > > The first problems seems to be there still - consider two
> > > adjacent nodes restarting.  They both act both as the restarting
> > > node as well as the neighbor to the restarting node. So, once
> > > they learn the state from the upstream neighbor, do they use
> > > suggested label or the recovery label when they send the path
> > > message to the just restarted downstream neighbor?
> > 
> > The recovery label.
> > 
> > The following should be added to the existing text from the document:
> > 
> >    In the special case where a restarting node also has a restating
> >    downstream neighbor, a Recovery_Label object should be used instead
> >    of a Suggested_Label object.
> 
> How does a recovering NE know that its neighbor is also recovering? it may 
> lose the instance number totally

It's advertised in the neighbor's hellos.

Yakov.

Delivery-date: Fri, 19 Oct 2001 08:16:07 -0700
From: Yanhe Fan <[email-masked]>
To: "'Zhi-Wei Lin'" <[email-masked]>, John Drake <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Fri, 19 Oct 2001 11:14:29 -0400

Hi, Zhi

>For the label value for SONET/SDH or the label description in the 
>generic draft, the label is defined as directly representing the 
>"timeslot". Now if I have a control plane controlled transport network 
>that goes through a ADM that is not control plane controlled, as:
>
>
>+--------+               +--------+               +--------+
>|        | ---1--------- |        | ----1-------- |        |
>|        | ---2--------- |        | ----2-------- |        |
>|  A     | ---3--------- |   B    | ----3-------- |   C    |
>|        | ---4--------- |        | ----4-------- |        |
>|        | ---5--------- |        | ----5-------- |        |
>+--------+               +--------+               +--------+
>
>Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at 
>A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C 
>has labels 1,2,3,4,5 incoming.
>
>Now imagine that at B, it actually has a fixed cross-connect that 
>connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to 
>C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
>
>Now when A GMPLS sends a message to C, the label it uses is "1". 
>However, the connection/LSP associated with timeslot "1" is actually the 
>label of timeslot "2" at C. </z>

In this case, you're trying to use GMPLS to setup an LSP cross a node (B)
which can't understand GMPLS.

Now imagine A, B and C are all OXCs, can you setup an LSP A-B-C by using 
GMPLS if B can't understand GMPLS?

Now imagine A and B are LSRs, and B is a conventional router (can't
understand
MPLS), can you setup an LSP A-B-C?

Now imagine A, B and C are ATM switches, can you setup a svc if B can't
understand PNNI at all?

My point is that in order to make you case work, some additional work need
to
be done besie simply using GMPLS as singnaling protocol, becase some node on
the path is not GMPLS speakers. A and C needs the info of time slot aligment

between them. This can be done by some configurations, some link management 
protocls (LMP maybe) etc. As long as A and C have this piece of info,
eveything
works fine.

Yanhe

Delivery-date: Fri, 19 Oct 2001 07:25:15 -0700
Date: Fri, 19 Oct 2001 10:16:30 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Yakov Rekhter <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

Yakov,

Further questions in-line. Regards,

Yangguang

> 
> Couple of points:
> 
> (1) First of all, you do run RSVP Hello between C and F.
 
Is this specified somewhere? Or it's your proposal. Then, is there a scalability
issue here? Also, C and F could be thousands mile away (in the transport
network) and the control channel bandwidth is expensive.

> (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> be able to recover the Interface ID it assigns to L1 from
> a combination of (a) the OSPF/ISIS link state database that
> F would recover, and (b) the Forward Interface ID (the one
> assigned by C).

Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess then it
has to recover its FA info first. How?

> > Let us say the node can resynchronize its neighbor if
> > the neighbor restarts and requests state recovery. But
> > the issue is how a node can advertise that it does not
> > need recovery since all its state was preserved?
> 
> By treating is the same way as the way the spec handles
> control channel fault.
>

If a node can recover states from NVRAM or OS (this solution is cheaper and have
been implemented). It may not implement the spec. How could a neighboring node,
which implements the spec, not tear down data connections mistakenly? Similar to
a backward compatibility problem, even not.

> >
> > RECOVERY LABEL does not come into picture unless the node
> > that is upstream to the restarting node has already received
> > a Resv.
> 
> Wrong. Quoting 9.5.3:
> 
>    Upon detecting a restart with a neighbor that supports state
>    recovery, a node SHOULD refresh all Path state shared with that
>    neighbor.
> 
> So, as you can hopefully see from the above, the upstream node doesn't
> wait until it receives a Resv.
> 

Then this may not meet carriers' requirement. (see IPO carriers' requirement)
Again, back to the telecom world (sorry about this, yet we are talking about
GMPLS), typically only the established pathes are preserved. Pending requests
may be purged/aborted. Then how?

> > In case of PSC devices, it may be OK to remove state that
> > is not resynchronized at the end of the recovery period,
> > and the recovery period advertised might reflect that.
> > But for LSPs in transport networks, one might want to
> > have a different recovery period to avoid any LSP from
> > going down because of recovery timer expiry.
> 
> There is no requirement for a node to advertise exactly the
> same Restart_Cap on all the interfaces. So, on PSC interfaces
> the node could advertise that it will remove the state that
> isn't syncronized at the end of the recovery period, while
> on the TDM interface precisely the same node could advertise
> that the LSPs would be kept even after the recovery time expires.
>

So, restart_cap is per interface based? Is the spec going to be
enhanced/clarified?

> > The first problems seems to be there still - consider two
> > adjacent nodes restarting.  They both act both as the restarting
> > node as well as the neighbor to the restarting node. So, once
> > they learn the state from the upstream neighbor, do they use
> > suggested label or the recovery label when they send the path
> > message to the just restarted downstream neighbor?
> 
> The recovery label.
> 
> The following should be added to the existing text from the document:
> 
>    In the special case where a restarting node also has a restating
>    downstream neighbor, a Recovery_Label object should be used instead
>    of a Suggested_Label object.
> 

How does a recovering NE know that its neighbor is also recovering? it may lose
the instance number totally

Delivery-date: Fri, 19 Oct 2001 05:00:11 -0700
From: "Mak, L (Leen)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Fri, 19 Oct 2001 13:58:04 +0200

Kireeti,

> 
> Let's move the comment period to end Oct 30th.
> 

Thanks a lot!

Leen.

Delivery-date: Fri, 19 Oct 2001 02:34:44 -0700
Date: Fri, 19 Oct 2001 11:32:54 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Zhi-Wei Lin <[email-masked]>
CC: John Drake <[email-masked]>, Maarten Vissers <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------A1AA3999068C8D697212CD8E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Just to mention here that this request is under evaluation
we have never reject this proposal but only answer for some
time in order to check for consistency with the existing 
content of the document. It is not because we are speaking 
"optical" stuff that we can integrate content at the speed 
of light ;-)

It has been received when the document was just issued this
is why not included in the current version. I hope this 
non-issue is closed.

Thanks for your understanding and your patience,
Dimitri.

Zhi-Wei Lin wrote:
> 
> Hi John,
> 
> It wasn't that I wanted it without explanation. The explanation is that
> M0/M1 is carried transparently across the network without changes at any
> intermediate points. I thought it was obvious that under "transparent"
> attribute, specifying this is automatically assumed transparent unless
> there is some exception cases about them...
> 
> Hope this explains. I wasn't trying to "ram" this down anyone's
> throat...BTW, you can just refer to me as "Zhi" :-)
> 
> Zhi
> 
> John Drake wrote:
> 
> > Maarten,
> >
> > I'm sorry, my comment was more procedural than technical.  If everyone
> > agrees that it is necessary, then obviously it should be added.  Zhi-Wei
> > didn't try to gain consensus for adding it, he just said that he wanted it
> > with no explanation, as far as I could tell.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Thursday, October 18, 2001 1:32 PM
> > To: John Drake
> > Cc: Zhi-Wei Lin; Kireeti Kompella; [email-masked]
> > Subject: Re: Moving right along ...
> >
> >
> > John,
> >
> > Semi transparent STM-N signal transport is typically required to support the
> > following applications:
> >
> > * DCN application: D1-D3, D4-D12
> > * MS protection application: J0, K1, K2, B2
> > * Other:
> >   [Orderwire] E1, E2,
> >   [User Channel] F1,
> >   [Single-ended MSn Performance Monitoring] M0, M1 (in addition to
> >                                           J0, K2[6-8] and B2)
> >   [RSn Performance Monitoring] B1 (in addition to J0)
> >
> > So M0/M1 transport is required in order to support single-ended MSn
> > performance
> > monitoring.
> >
> > Regards,
> >
> > Maarten
> >
> > John Drake wrote:
> >
> >>-----Original Message-----
> >>From: Zhi-Wei Lin [mailto:[email-masked]]
> >>Sent: Thursday, October 18, 2001 5:47 AM
> >>To: Kireeti Kompella
> >>Cc: [email-masked]
> >>Subject: Re: Moving right along ...
> >>
> >>SNIPPED
> >>
> >>
> >>>As for the rest, let me juxtapose your comments on switching type
> >>>and M0/M1; I will say nothing, hoping that the juxtaposition will
> >>>speak for itself.
> >>>
> >>>
> >><z>The switching type is in a "standard" document, while the M0/M1 is in
> >>the "non-standard" document. I will let that speak for itself as well.
> >>And by the way, when you made this comment are making it as a chair or
> >>as a contributor?</z>
> >>
> >>JD:  Actually, the signalling drafts are on exactly the same technical
> >>footing as the "non-standard" draft,
> >>so I think your attempt to draw a distinction between the two is specious
> >>
> > at
> >
> >>best.  Once again, a feature
> >>or capability is added if the community as a whole decides, through a
> >>process of rough consensus, that it
> >>should be added.  No one other than you has indicated an issue with
> >>switching type and I haven't seen a groundswell
> >>of support for M0/M1.
> >>
> >>
> >>
> >>Zhi
> >>
--------------A1AA3999068C8D697212CD8E
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------A1AA3999068C8D697212CD8E--

Delivery-date: Fri, 19 Oct 2001 01:50:49 -0700
From: [email-masked]
Date: Fri, 19 Oct 2001 03:47:57 -0500
Subject: RE: Moving right along ...
TO: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

I agree with Deborah.  It doesn't make any sense to me that the labels 
are different from the established standards.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
[email-masked]

-----Original Message-----
From: dbrungard [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 5:57 PM
To: mvissers; Eric.Mannie
Cc: dbrungard; Juergen.Heiles; kireeti; ccamp
Subject: RE: Moving right along ...

Eric,

I also have commented on this multiple times. My previous comments were 
that
the labels are inaccurate (e.g. ITU SDH supports both SONET (AU-3 and 
AU-4)
and ETSI SDH (AU-4)) and they introduce an unnecessary complexity as 
they
are not aligned with the transport plane functionality. There already 
exists
lots of mis-information on SDH/SONET interworking - let's not add to it 
for
supporting GMPLS. For a carrier, this introduces unnecessary operational
complexity. I have not seen any discussion of my comments.

Can you please share with us your concerns as it is difficult to discuss
technical issues if they are not identified.

Deborah Brungard
AT&T

> -----Original Message-----
> From:	Maarten Vissers [SMTP:[email-masked]]
> Sent:	Thursday, October 18, 2001 4:42 PM
> To:	Mannie, Eric
> Cc:	'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> Subject:	Re: Moving right along ...
> 
> Eric,
> 
> > At this very late stage, since this not bringing any new 
functionality,
> and
> > since the label structure is very stable since a long time, I would
> prefer
> > not to restart a long technical discussion to change and re-validate 
the
> > draft.
> 
> This label issue is brought up many months ago already and strongly
> supported by
> multiple people. So far it has been rejected by you, and thus not
> included. The
> label structure isn't stable as such since a long time... there was 
simply
> a
> rejection to properly adapt it.
> 
> For me and other SDH/SONET folks it is of utmost importance to see SDH 
and
> SONET
> be treated similarly, as also reflected in the ITU-T and T1 
specifications
> for
> these technologies. In my opinion the current text in the draft must 
be
> adapted
> as proposed by Juergen (and by me and others in the past as well).
> 
> Regards,
> 
> Maarten << File: Card for Maarten Vissers >> 

Delivery-date: Thu, 18 Oct 2001 16:06:52 -0700
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: "'Heiles Juergen'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 18:57:06 -0400

Eric,

I also have commented on this multiple times. My previous comments were that
the labels are inaccurate (e.g. ITU SDH supports both SONET (AU-3 and AU-4)
and ETSI SDH (AU-4)) and they introduce an unnecessary complexity as they
are not aligned with the transport plane functionality. There already exists
lots of mis-information on SDH/SONET interworking - let's not add to it for
supporting GMPLS. For a carrier, this introduces unnecessary operational
complexity. I have not seen any discussion of my comments.

Can you please share with us your concerns as it is difficult to discuss
technical issues if they are not identified.

Deborah Brungard
AT&T

> -----Original Message-----
> From:	Maarten Vissers [SMTP:[email-masked]]
> Sent:	Thursday, October 18, 2001 4:42 PM
> To:	Mannie, Eric
> Cc:	'Heiles Juergen'; 'Kireeti Kompella'; [email-masked]
> Subject:	Re: Moving right along ...
> 
> Eric,
> 
> > At this very late stage, since this not bringing any new functionality,
> and
> > since the label structure is very stable since a long time, I would
> prefer
> > not to restart a long technical discussion to change and re-validate the
> > draft.
> 
> This label issue is brought up many months ago already and strongly
> supported by
> multiple people. So far it has been rejected by you, and thus not
> included. The
> label structure isn't stable as such since a long time... there was simply
> a
> rejection to properly adapt it.
> 
> For me and other SDH/SONET folks it is of utmost importance to see SDH and
> SONET
> be treated similarly, as also reflected in the ITU-T and T1 specifications
> for
> these technologies. In my opinion the current text in the draft must be
> adapted
> as proposed by Juergen (and by me and others in the past as well).
> 
> Regards,
> 
> Maarten << File: Card for Maarten Vissers >> 

Delivery-date: Thu, 18 Oct 2001 15:02:58 -0700
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
Date: Thu, 18 Oct 2001 14:59:29 -0700
From: Yakov Rekhter <[email-masked]>

Gopal,

> >>I have some questions/concerns on the restart mechanism as
> >>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
> >>have listed them below.
> >>
> >>If a node that is terminating hierarchical LSPs restarts,
> >>there is an ordering issue during resynchronization, since
> >>the LSPs would depend on other FA-LSPs the interface IDs for
> >>which would have been generated dynamically. So the
> >>mechanism as described will not work, unless this
> >>information is preserved across restarts - in which case we
> >>might as well preserve other information as well, and avoid
> >>resynchronization.
> >>
> >
> >Since transit node of the FA-LSP does not see the RSVP
> >messages that use the FA, we only need to consider
> >the ingress and egress node. If the egress node restarts,
> >the worst case is that its upstream node sends an ERO
> >consisting a unrecognized interface address. Since the
> >Path message will carry RECOVERY_LABEL (replacing
> >SUGGESTED_LABEL), the egress node knows that it might
> >not have complete information yet, and can hold on to
> >the Path message until the FA-LSP is established.
> >All the information is there, so implementation
> >can be completely within the egress node. It does work,
> >just not specified enough.
> >
> >Ingress node will have to know the dependency, so not
> >a problem there.
> >
> Are you suggesting that in case of an ERO with an
> unrecognized interface id, if the Path message also
> carries a RECOVERY LABEL, the egress node can hold on
> to it until later?  Note that there may not be a
> RECOVERY LABEL - since this Path message is for a
> hierarchical LSP, and the previous node may not be
> directly connected in the control plane.  Here is an
> example - There is an LSP L1 from C to F, and on top of
> it there is an LSP L2 from A to G.
>
>  L1:              C --- D --- E --- F
>  L2:  A --- B --- C --------------- F --- G
>
> When F restarts, C may not even know, unless HELLO
> protocol is run between C and F.  Note that the
> HELLO mechanism is intended for immediate neighbors.
>
> And even if the HELLO mechanism is extended, there
> is the issue of interface id assigned by F.  F needs
> to assign the same interface id upon restart so as
> not to bring down the hierarchical LSPs set up on top
> of L1 in the reverse direction (say an LSP from G to
> B set up on top of L1.)  Where would F get this
> information ?

Couple of points:

(1) First of all, you do run RSVP Hello between C and F.

(2) Since L1 is advertised as an FA into OSPF/ISIS, F should
be able to recover the Interface ID it assigns to L1 from
a combination of (a) the OSPF/ISIS link state database that
F would recover, and (b) the Forward Interface ID (the one
assigned by C).

> >>Also, let us consider a node that can preserve state across
> >>restarts, and hence does not need its state to be synced by
> >>its peer.  How will it advertise this in the RESTART_CAP
> >>object?
> >>
> >
> >We still need to resynchronize the state since the other
> >side might have connections that are in progress. The
> >
> Let us say the node can resynchronize its neighbor if
> the neighbor restarts and requests state recovery. But
> the issue is how a node can advertise that it does not
> need recovery since all its state was preserved?

By treating is the same way as the way the spec handles
control channel fault.

> >reason for resynchronization is to make sure both side
> >have done the same to the in-progress connections, not
> >just to synchronize the established states.
> >
> >The value of the RESTART_CAP will set to non-zero values
> >
>
> RECOVERY LABEL does not come into picture unless the node
> that is upstream to the restarting node has already received
> a Resv.

Wrong. Quoting 9.5.3:

   Upon detecting a restart with a neighbor that supports state
   recovery, a node SHOULD refresh all Path state shared with that
   neighbor.

So, as you can hopefully see from the above, the upstream node doesn't 
wait until it receives a Resv.

> So it seems that the procedure is to resynchronize
> established state? If Resv has not been received yet, there
> will be a refresh of Path message, and the restarting node
> will consider it as a new request, etc.  So can you elaborate
> on "to make sure both side have done the same to the in
> progress connections" ?
>
> >>If a node supports PSC as well as TDM or LSC interfaces, it
> >>might want to advertise different set of parameters in the
> >>RESTART_CAP object for data LSPs as opposed to SONET/WDM
> >>LSPs which form bearer channels in transport networks.
> >>Currently this is not possible.
> >>
> >
> >Can you give us explicit examples as to why and what do
> >you gain by giving different values for PSC, TDM ?
> >
> In case of PSC devices, it may be OK to remove state that
> is not resynchronized at the end of the recovery period,
> and the recovery period advertised might reflect that.
> But for LSPs in transport networks, one might want to
> have a different recovery period to avoid any LSP from
> going down because of recovery timer expiry.

There is no requirement for a node to advertise exactly the
same Restart_Cap on all the interfaces. So, on PSC interfaces
the node could advertise that it will remove the state that
isn't syncronized at the end of the recovery period, while
on the TDM interface precisely the same node could advertise
that the LSPs would be kept even after the recovery time expires.

> >>According to 9.5.1. (procedures for restarting LSR): "When
> >>sending the corresponding outgoing Path message the node
> >>SHOULD include a SUGGESTED_LABEL object with a label value
> >>^^^^^^
> >>matching the outgoing label from the now restored forwarding
> >>entry."
> >>
> >>This has a conflict with 9.5.2.  Consider the case where
> >>adjacent nodes B and C restart, and B has another adjacent
> >>node A, and C has another adjacent node D.  B and C will get
> >>resynced by A and D, and during this process, they will
> >>resync. each other. While resyncing each other, they act as
> >>neighbors of a restarting LSR, and hence according to 9.5.2,
> >>MUST include the SUGGESTED_LABEL.
> >>
> >>Also according to 9.5.2: "During the recovery period, new
> >>Path state being advertised to the restarted neighbor SHOULD
> >>not include the SUGGESTED_LABEL object in the corresponding
> >>outgoing Path message.  This will prevent the restarting
> >>node from erroneously reusing a saved forwarding entry."
> >>
> >>I guess this would mean that if suggested labels are used
> >>during new LSP setup (as they are likely to be while
> >>provisioning lightpaths - to reduce latency), then new LSP
> >>setup will not be allowed during resyncing?
> >>
> >
> >The use of RECOVERY_LABEL address all the above questions.
> >
> The first problems seems to be there still - consider two
> adjacent nodes restarting.  They both act both as the restarting
> node as well as the neighbor to the restarting node. So, once
> they learn the state from the upstream neighbor, do they use
> suggested label or the recovery label when they send the path
> message to the just restarted downstream neighbor?

The recovery label.

The following should be added to the existing text from the document:

   In the special case where a restarting node also has a restating
   downstream neighbor, a Recovery_Label object should be used instead
   of a Suggested_Label object.

Yakov.

Delivery-date: Thu, 18 Oct 2001 14:56:54 -0700
Date: Thu, 18 Oct 2001 14:54:11 -0700
From: Ping Pan <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Zhi-Wei Lin wrote:
> 
>  From what I recall, one of the cases that I was having difficulty
> seeing was how a source LSR control plane failed, how the states were
> recovered. Since in this case, the Path message defined for restart cap
> is only going downstream and not upstream to recover the upstream
> (source) node.
> 

At headend, it's more like a number of routes maps to each LSP to
forward traffic. After a headend restart, the downstream nodes will feed
the allocated labels to the headend router. Now depending on your
implementation, the route-label mapping could be recovered. However,
graceful restart is used to recover GMPLS operation only, but is not a
magic pill to recover other functions in the network, such as route
recovery, config recovery.... IMHO, this applied to all nodes in the
network. I would like to see different tools used to recover different
things on every node.

I don't see why GMPLS graceful restart does not work.

- Ping

Delivery-date: Thu, 18 Oct 2001 14:30:24 -0700
Date: Thu, 18 Oct 2001 17:30:24 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Maarten Vissers <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi John,

It wasn't that I wanted it without explanation. The explanation is that 
M0/M1 is carried transparently across the network without changes at any 
intermediate points. I thought it was obvious that under "transparent" 
attribute, specifying this is automatically assumed transparent unless 
there is some exception cases about them...

Hope this explains. I wasn't trying to "ram" this down anyone's 
throat...BTW, you can just refer to me as "Zhi" :-)

Zhi

John Drake wrote:

> Maarten,
> 
> I'm sorry, my comment was more procedural than technical.  If everyone
> agrees that it is necessary, then obviously it should be added.  Zhi-Wei
> didn't try to gain consensus for adding it, he just said that he wanted it
> with no explanation, as far as I could tell.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 1:32 PM
> To: John Drake
> Cc: Zhi-Wei Lin; Kireeti Kompella; [email-masked]
> Subject: Re: Moving right along ...
> 
> 
> John,
> 
> Semi transparent STM-N signal transport is typically required to support the
> following applications:
> 
> * DCN application: D1-D3, D4-D12
> * MS protection application: J0, K1, K2, B2
> * Other: 
>   [Orderwire] E1, E2, 
>   [User Channel] F1, 
>   [Single-ended MSn Performance Monitoring] M0, M1 (in addition to 
> 					    J0, K2[6-8] and B2)
>   [RSn Performance Monitoring] B1 (in addition to J0)
> 
> So M0/M1 transport is required in order to support single-ended MSn
> performance
> monitoring.
> 
> Regards,
> 
> Maarten
> 
> John Drake wrote:
> 
>>-----Original Message-----
>>From: Zhi-Wei Lin [mailto:[email-masked]]
>>Sent: Thursday, October 18, 2001 5:47 AM
>>To: Kireeti Kompella
>>Cc: [email-masked]
>>Subject: Re: Moving right along ...
>>
>>SNIPPED
>>
>>
>>>As for the rest, let me juxtapose your comments on switching type
>>>and M0/M1; I will say nothing, hoping that the juxtaposition will
>>>speak for itself.
>>>
>>>
>><z>The switching type is in a "standard" document, while the M0/M1 is in
>>the "non-standard" document. I will let that speak for itself as well.
>>And by the way, when you made this comment are making it as a chair or
>>as a contributor?</z>
>>
>>JD:  Actually, the signalling drafts are on exactly the same technical
>>footing as the "non-standard" draft,
>>so I think your attempt to draw a distinction between the two is specious
>>
> at
> 
>>best.  Once again, a feature
>>or capability is added if the community as a whole decides, through a
>>process of rough consensus, that it
>>should be added.  No one other than you has indicated an issue with
>>switching type and I haven't seen a groundswell
>>of support for M0/M1.
>>
>>
>>
>>Zhi
>>

Delivery-date: Thu, 18 Oct 2001 14:23:44 -0700
Date: Thu, 18 Oct 2001 17:23:33 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Maarten Vissers <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

At the risk of sounding like a "me-too" person, me-too agree with 
Maarten. :-)

Zhi

Maarten Vissers wrote:

> Eric,
> 
> 
>>At this very late stage, since this not bringing any new functionality, and
>>since the label structure is very stable since a long time, I would prefer
>>not to restart a long technical discussion to change and re-validate the
>>draft.
>>
> 
> This label issue is brought up many months ago already and strongly supported by
> multiple people. So far it has been rejected by you, and thus not included. The
> label structure isn't stable as such since a long time... there was simply a
> rejection to properly adapt it.
> 
> For me and other SDH/SONET folks it is of utmost importance to see SDH and SONET
> be treated similarly, as also reflected in the ITU-T and T1 specifications for
> these technologies. In my opinion the current text in the draft must be adapted
> as proposed by Juergen (and by me and others in the past as well).
> 
> Regards,
> 
> Maarten
> 
> 

Delivery-date: Thu, 18 Oct 2001 14:22:29 -0700
From: John Drake <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: Zhi-Wei Lin <[email-masked]>, Kireeti Kompella <[email-masked]>,  [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 14:21:06 -0700

Maarten,

I'm sorry, my comment was more procedural than technical.  If everyone
agrees that it is necessary, then obviously it should be added.  Zhi-Wei
didn't try to gain consensus for adding it, he just said that he wanted it
with no explanation, as far as I could tell.

Thanks,

John

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 1:32 PM
To: John Drake
Cc: Zhi-Wei Lin; Kireeti Kompella; [email-masked]
Subject: Re: Moving right along ...

John,

Semi transparent STM-N signal transport is typically required to support the
following applications:

* DCN application: D1-D3, D4-D12
* MS protection application: J0, K1, K2, B2
* Other: 
  [Orderwire] E1, E2, 
  [User Channel] F1, 
  [Single-ended MSn Performance Monitoring] M0, M1 (in addition to 
					    J0, K2[6-8] and B2)
  [RSn Performance Monitoring] B1 (in addition to J0)

So M0/M1 transport is required in order to support single-ended MSn
performance
monitoring.

Regards,

Maarten

John Drake wrote:
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 5:47 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ...
> 
> SNIPPED
> 
> > As for the rest, let me juxtapose your comments on switching type
> > and M0/M1; I will say nothing, hoping that the juxtaposition will
> > speak for itself.
> >
> 
> <z>The switching type is in a "standard" document, while the M0/M1 is in
> the "non-standard" document. I will let that speak for itself as well.
> And by the way, when you made this comment are making it as a chair or
> as a contributor?</z>
> 
> JD:  Actually, the signalling drafts are on exactly the same technical
> footing as the "non-standard" draft,
> so I think your attempt to draw a distinction between the two is specious
at
> best.  Once again, a feature
> or capability is added if the community as a whole decides, through a
> process of rough consensus, that it
> should be added.  No one other than you has indicated an issue with
> switching type and I haven't seen a groundswell
> of support for M0/M1.
> 
> 
> 
> Zhi

Delivery-date: Thu, 18 Oct 2001 14:22:18 -0700
Date: Thu, 18 Oct 2001 17:21:42 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi John,

> JD:  If a valid technical issue is raised, the authors of a draft attempt
> to deal with it and their efforts are documented in a subsequent version
> of the draft.  If the proposed solution is inadequate or someone has a 
> better solution, then the proposed solution is either changed or fixed.
> 
> I don't think an exhaustive public discussion of every possible solution
> is particularly useful.  And as has been pointed out, we're dealing with
> rough consensus;  this means that we don't necessarily need to get your
> approval for everything that we do.
> 

<z>I guess I'm giving you the wrong impression again and making you mad 
at me again...I didn't mean that it needs my approval or any such 
things. I merely bring up a point that some items have not been 
resolved, and was not really decided upon by the CCAMP group. Of course 
my understanding was that there was some inadequacy, and the explanation 
I've been given did not get through my thick skull yet...</z>

> JD:  And Fong answered the questions completely.
> 

<z>I thinkg Yangguang replied to this, so we can continue the discussion 
on that thread instead. :-) </z>

> JD:  The authors add it and invite comments and criticism.  I have made
> several attempts to explain switching type to you, with no apparent success.
> I haven't had this problem explaining it to anyone else.
>    

<z>Yes, and I thank you for explaining to me. It's just that what I 
heard seems to say that "this seems like a good thing for multi-service 
nodes" without really concrete reason how this makes the protocol better 
or what problem it is solving. Maybe I'm been too academic in protocol 
design cleanliness???
For example, even the LSP encoding type is really not necessary if you 
think about it, since the port or interface that you use has been 
discovered as a certain type of signal there. But of course that's not 
the issue here...</z>

> JD:  The attempt was made to address Juergen's comments.  It would be nice
> for him, rather than you, to indicate whether they were adequately
> addressed.

<z>Yes, you're right. I should only care about my own comments and only 
reply to my own comments and not use other people's words in my email.</z>

> As for you second point, we'd love to see valid technical issues and good
> technical solutions from you or anyone else.  As St Francis said, he would
> accept wisdom regardless of the source.
>  

<z>Good quote from St. Francis. I'll have to follow that more often. :-)

As for technical issues, I won't repeat other arguments as they've been 
given (I'll let the others speak directly rather than speak for them -- 
I'm taking your advice!) :-)

But I do have one issue that actually Maarten and Juergen brought up 
(since they haven't mentioned it yet in public I will paraphrase them):

For the label value for SONET/SDH or the label description in the 
generic draft, the label is defined as directly representing the 
"timeslot". Now if I have a control plane controlled transport network 
that goes through a ADM that is not control plane controlled, as:

+--------+               +--------+               +--------+
|        | ---1--------- |        | ----1-------- |        |
|        | ---2--------- |        | ----2-------- |        |
|  A     | ---3--------- |   B    | ----3-------- |   C    |
|        | ---4--------- |        | ----4-------- |        |
|        | ---5--------- |        | ----5-------- |        |
+--------+               +--------+               +--------+

Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at 
A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C 
has labels 1,2,3,4,5 incoming.

Now imagine that at B, it actually has a fixed cross-connect that 
connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to 
C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.

Now when A GMPLS sends a message to C, the label it uses is "1". 
However, the connection/LSP associated with timeslot "1" is actually the 
label of timeslot "2" at C. </z>

Zhi

Delivery-date: Thu, 18 Oct 2001 13:59:14 -0700
Date: Thu, 18 Oct 2001 16:59:30 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi John,

I didn't know that. I thought the "non-standard" draft was going to 
route of informational RFC and the "standard" draft was targeted for the 
regular process...

As for M0/M1, I thought the decision for this transparency was to be 
able to support different available products (wasn't that the original 
intention of things like arbitrary concat and stuff??). And from what I 
(as an individual) understand, there are vendors doing this...

You may know of other vendors that may not do this, and as I remember, 
those that don't use it simply don't set it or ignore it...

Maybe I still don't understand the process (as I mentioned in another 
mail, I'm pretty slow).

Zhi

John Drake wrote:

> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 5:47 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ...
> 
> SNIPPED
> 
> 
> 
>>As for the rest, let me juxtapose your comments on switching type
>>and M0/M1; I will say nothing, hoping that the juxtaposition will
>>speak for itself.
>>
>>
> 
> 
> <z>The switching type is in a "standard" document, while the M0/M1 is in 
> the "non-standard" document. I will let that speak for itself as well. 
> And by the way, when you made this comment are making it as a chair or 
> as a contributor?</z>
> 
> 
> JD:  Actually, the signalling drafts are on exactly the same technical
> footing as the "non-standard" draft,
> so I think your attempt to draw a distinction between the two is specious at
> best.  Once again, a feature
> or capability is added if the community as a whole decides, through a
> process of rough consensus, that it
> should be added.  No one other than you has indicated an issue with
> switching type and I haven't seen a groundswell
> of support for M0/M1.
> 
> 
>   
> 
> 
> 
> Zhi
> 
> 

Delivery-date: Thu, 18 Oct 2001 13:57:24 -0700
Date: Thu, 18 Oct 2001 16:56:16 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Ping Pan <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Hi Ping,

Maybe I misinterpreted or I am just dumb. In that case, I hope that you 
have some patience with me...

 From what I recall, one of the cases that I was having difficulty 
seeing was how a source LSR control plane failed, how the states were 
recovered. Since in this case, the Path message defined for restart cap 
is only going downstream and not upstream to recover the upstream 
(source) node.

As I recall, when you asked what information is not resoverable, I 
mentioned information in the Session Attribute object which included 
information about routing constraints (such as the exclude/include list, 
holding priority and flag). I also mentioned that the restart cap did 
not handle some info in the Generalized_UNI object.

Yes I know that that is strictly for OIF to deal with, but still if OIF 
is re-using and the authors are essentially working in both fora we 
should be able to look at it and not push to other groups.

As you said, maybe you've provided me with enough info and I'm just not 
seeing the "big picture". If you could be so kind as to show me the way 
and be patient with me. I am slow...

Thanks

Zhi

Ping Pan wrote:

> Zhi-Wei,
> 
> Zhi-Wei Lin wrote:
> 
>>
>><z>I apologize because I can't look back at all the emails (I'm at the
>>ITU meeting and is connecting over a phone line). I will give you more
>>details on this when I get back.
>>
>>Essentially I've had email exchanges with Ping Pan on this issue for a
>>while and asked some questions that has still not been answered. I will
>>dig those out and forward to this group probably the week of Oct. 29.</z>
>>
> 
> Sigh ... unbelievable!
> 
> If I recall, you had sent me some emails on how graceful restart works
> several weeks ago. I had replied all but one, where you were asking
> about how Session Attribute object would work here. I thought it was
> best to read the RSVP-TE draft more carefully.
> 
> I also recalled that I had told you enough without telling you exactly
> how I was about to implement graceful restart. :-( Yes, there may have
> some corner cases on restarting at ingress *depending* on how your
> router works. However, I felt that the draft was generic enough to cover
> all the cases. All the issues that you had asked had been worked out by
> the authors, including the ones for OIF UNI....
> 
> So if you feel that it's broken, let all of us know. There is no point
> of sending many private emails and expecting others to reply everyone of
> them. If short of a reply, you start to put people's name all over the
> place.
> 
> - Ping
> 

Delivery-date: Thu, 18 Oct 2001 13:42:42 -0700
Cc: "'Heiles Juergen'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Date: Thu, 18 Oct 2001 22:41:59 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "'Heiles Juergen'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------810C1A528C7BE82C2F1692F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

> At this very late stage, since this not bringing any new functionality, and
> since the label structure is very stable since a long time, I would prefer
> not to restart a long technical discussion to change and re-validate the
> draft.

This label issue is brought up many months ago already and strongly supported by
multiple people. So far it has been rejected by you, and thus not included. The
label structure isn't stable as such since a long time... there was simply a
rejection to properly adapt it.

For me and other SDH/SONET folks it is of utmost importance to see SDH and SONET
be treated similarly, as also reflected in the ITU-T and T1 specifications for
these technologies. In my opinion the current text in the draft must be adapted
as proposed by Juergen (and by me and others in the past as well).

Regards,

Maarten
--------------810C1A528C7BE82C2F1692F1
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------810C1A528C7BE82C2F1692F1--

Delivery-date: Thu, 18 Oct 2001 13:37:50 -0700
Cc: Zhi-Wei Lin <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Thu, 18 Oct 2001 22:32:20 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
Original-CC: Zhi-Wei Lin <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------96D22359B20548C75F52B1CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Semi transparent STM-N signal transport is typically required to support the
following applications:

* DCN application: D1-D3, D4-D12
* MS protection application: J0, K1, K2, B2
* Other: 
  [Orderwire] E1, E2, 
  [User Channel] F1, 
  [Single-ended MSn Performance Monitoring] M0, M1 (in addition to 
					    J0, K2[6-8] and B2)
  [RSn Performance Monitoring] B1 (in addition to J0)

So M0/M1 transport is required in order to support single-ended MSn performance
monitoring.

Regards,

Maarten

John Drake wrote:
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 5:47 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: Moving right along ...
> 
> SNIPPED
> 
> > As for the rest, let me juxtapose your comments on switching type
> > and M0/M1; I will say nothing, hoping that the juxtaposition will
> > speak for itself.
> >
> 
> <z>The switching type is in a "standard" document, while the M0/M1 is in
> the "non-standard" document. I will let that speak for itself as well.
> And by the way, when you made this comment are making it as a chair or
> as a contributor?</z>
> 
> JD:  Actually, the signalling drafts are on exactly the same technical
> footing as the "non-standard" draft,
> so I think your attempt to draw a distinction between the two is specious at
> best.  Once again, a feature
> or capability is added if the community as a whole decides, through a
> process of rough consensus, that it
> should be added.  No one other than you has indicated an issue with
> switching type and I haven't seen a groundswell
> of support for M0/M1.
> 
> 
> 
> Zhi
--------------96D22359B20548C75F52B1CA
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------96D22359B20548C75F52B1CA--

Delivery-date: Thu, 18 Oct 2001 09:58:46 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 18:57:51 +0200

Hello Juergen,

Your comments are addressed hereafter. Note that you didn't raised any
technical problem or mistake in your comments (i.e. the draft "works" very
well as it is).

- the first comment is not about a technical issue but an "editorial" issue.
- the second comment is about a change that will not bring any new
capability.

>Concerning the SDH/Sonet documents I want to raise a formal issue.
>We have now two documents, a document that covers ITU/ANSI standard
features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that
covers non-standard features
(draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in Appendix 1
of the standard feature document a non standard feature (Group signals) is
listed. It is even mentioned that the use of groups (AUG, STSG, ...) is not
described in standards. So this feature should be moved to the non-standards
document. Otherwise the split of the documents doesn't make sense.

We spend a considerable amount of time speaking about this particular issue
and I still don't see any technical justification for what you said.

For those who are not SDH/SONET experts some quick explanation:

We call a "super-circuit" a set of physical circuits in the transport plane
all belonging to the same LSP in the signaling plane. We defined two kinds
of super-circuits: "group circuits" and "multiplicative circuits".

Multiplicative circuits are setup using the multiplier field that we defined
(e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no objection
about these ones.

Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG,
TUG, VTG (we defined the equivalent signal type in the signaling). The
comment of Juergen is about these group circuits. A group circuit represents
some bandwidth at a given place in the SDH/SONET multiplex. The advantage of
such a super-circuit is that the customer can re-structure its content as
he/she likes. The operator doesn't care.

Such an application is possible and is already implemented. SDH/SONET is
self-describing, i.e. by looking at the signal one can understand how it is
structured (like Juergen explained on the mailing list), so one can setup a
circuit without describing the content (very very cool).

The transport plane ignores that the signaling plane uses an "abstraction"
(i.e. an LSP) representing several physical circuits. Note that restoration
and management belong respectively to the signaling plane and to the
management plane in the IETF view (not to the transport plane like in the
ITU-T view).

>From that point of view, group circuits are a GMPLS signaling plane feature
and not a transport plane feature. We put the comment on the fact that this
is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy.

I could say clearly at the beginning of the draft that the signal types that
we are defining in this document are not ITU-T signal types but GMPLS signal
types (of course) whose have in some cases a direct relationship with the
ITU-T signal types.

Any objection ?

>For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I
prefer to have the same coding for Sonet and SDH. That makes the
implementation for Sonet and SDH simpler. Furthermore ITU and T1 have tried
over the last years to align Sonet and SDH as much as possible. The
definition of different labels for Sonet and SDH contradicts these
activities.

We discussed this one since a long time as well. Let me be clear:

- labels are local to an interface (we all agree).
- a link (interface) is operated at one point in the time as either SDH or
SONET.
- your proposal will require to re-evaluate many things.
- and it took us a lot of time to fine-tune and to validate the current
label structure.
- we could have technical issues with your proposal that would impact more
than this draft (Dimitri saw some of them, please see with him).
- you never provided a complete analysis of your proposal.

But more important: your proposal doesn't bring any additional functionality
to the draft.

At this very late stage, since this not bringing any new functionality, and
since the label structure is very stable since a long time, I would prefer
not to restart a long technical discussion to change and re-validate the
draft.

Kind regards,

Eric

 
> -----Ursprüngliche Nachricht-----
> Von: Kireeti Kompella [mailto:[email-masked]]
> Gesendet: Mittwoch, 17. Oktober 2001 11:25
> An: [email-masked]
> Betreff: Moving right along ...
> 
> 
> Despite the energetic subject line, we the WG chairs have been
> lax in our duties.  So, here goes:
> 
> Lou has submitted the latest versions of the generalized
> signaling documents quite some time ago (thanks, Lou):
> 
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> 
> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> 
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> All of these should have addressed the issues raised in the earlier
> versions.  Please read the new versions, and send your comments to
> the list by Tuesday Oct 23.  At that point, when the final round
> of comments have been addressed, these docs will go to IESG Last
> Call.  If any one objects to sending these docs to IESG Last Call,
> raise your issues now.
> 
> I see that the GMPLS architecture document is a CCAMP WG doc, but
> the minutes say that we should look for consensus on the list.  So,
> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> will progress to WG Last Call.
> 
> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> list know what your thinking is on these.  (BTW, both these docs
> were to have some edits done.  If the authors could do that before
> the next IETF, we can try to make more progress then.)
> 
> The MIB overview doc was recently posted.  Please read and comment
> to the list.
> 
> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> was generally thought to be useful; it will be published as a
> CCAMP informational doc.  This begins a two week Last Call on
> the doc, ending Tuesday Oct 30.
> 
> There was no consensus on whether the GMPLS framework should be
> a CCAMP WG doc.  Please indicate your pleasure.
> 
> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.
> 
> The OLI requirements doc was broadly accepted.  Please let the
> list know if you think this doc should be a WG doc.
> 
> It's still open whether we (the IETF) should be working on
> LMP-WDM.  I urge the authors to keep on working on the doc, and
> keeping it in sync with LMP; however, we will postpone making it
> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> happen in Salt Lake City.
> 
> There was reasonable interest in the tunnel trace requirements
> doc.  Let's formalize this: do you think this should be made a
> CCAMP WG document?
> 
> Summary:
> 
> 1) Final comments and IESG Last Call readiness for:
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> 2) Should the following documents be CCAMP WG docs?
> draft-bonica-tunneltrace-02.txt
> draft-fontana-ccamp-gmpls-g709-00.txt
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> draft-many-ccamp-gmpls-framework-00.txt
> draft-many-oli-reqts-00.txt
> 
> 3) Comment on MIB overview.
> 
> 4) Two week Last Call comments on
> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> 
> 5) Last Call readiness of
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-ietf-ccamp-lmp-01.txt
> 
> Thanks,
> Kireeti.
> 

Envelope-to: [email-masked]
Delivery-date: Thu, 18 Oct 2001 09:54:26 -0700
Date: Thu, 18 Oct 2001 09:52:23 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Moving right along ...
Cc: [email-masked], [email-masked], [email-masked]

> > Why not?
> 
> Why why not?

Okay, folks, let's step back, take a deep breath, and come back
to this discussion when the blood rush is over.

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Thu, 18 Oct 2001 09:40:48 -0700
Date: Thu, 18 Oct 2001 09:39:23 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Moving right along ...
Cc: [email-masked]

Hi Steve,

> Yes, I have discussed this with the management team of ITU-T SG 15, and
> we agree that these will be made available in our new public FTP area,

That's super!  Thanks for your efforts.

> They do want to
> wait for Friday 25 October so you can get the official word on our
> decisions.

No problem.

Kireeti.

Delivery-date: Thu, 18 Oct 2001 09:13:13 -0700
Date: Thu, 18 Oct 2001 09:12:05 -0700
From: Ping Pan <[email-masked]>
To: Debanjan Saha <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

Debanjan Saha wrote:
> 
> Ping Pan
> >>
> >> To me, what carriers want are (1) How to preserve data path when control
> >> channel/entity fails?
> 
> >Apply fast reroute.
> 
> Why would you do fast reroute if your data channel is still up?
>

wrong reply for someone scans emails once in a long while and saw his
name poping up. :-)

> Debanjan

Delivery-date: Thu, 18 Oct 2001 09:11:56 -0700
Date: Thu, 18 Oct 2001 10:10:44 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

Kireeti,
Yes, I have discussed this with the management team of ITU-T SG 15, and
we agree that these will be made available in our new public FTP area,
with an email to you & ccamp to annouce their presence. They do want to
wait for Friday 25 October so you can get the official word on our
decisions.

On the VBI work, as you say, the results are not so urgent.
Regards,
Steve

Kireeti Kompella wrote:
> 
> Hi Steve,
> 
> > In addition to the time crunch, we have the issue that some comment may
> > be derived from the status of related work in Study Group 15. This has
> > been communicated before, but to summarize some results that are expected
> > by 25 October:
> > We expect consent on the following documents related to GMPLS:
> > G.ason, now numbered G.8080/Y.1304 "Architecture for the Automatic Switched
> >   Optical Network"
> > G.dcm, now numbered G.7713/Y.1704 "Distributed Connection Management"
> > G.disc, now numbered G.7714/Y.1705 "Generalized Automatic Discovery"
> > G.dcn, now numbered G.7712/Y.1703 "Architecture and Specification of
> >   Data Communications Network"
> 
> That would be very useful.  Would these be publicly available?
> 
> > We expect also to be able to report progress relating to the VBI/New
> > Equipment Partitioning work, related to OLI/LMP/NTIP work.
> >
> > While full harmonization of the ITU-T/IETF work may be out of reach
> > for the first effort, people should at least have the opportunity to
> > read the ITU-T documents and consider the impact.
> 
> While this is also very useful (I've glanced at the documents, thanks
> for the urls), as you point out, these relate to LMP-WDM, and that
> document isn't under consideration even as a WG document until we
> resolve whether the IETF or the ITU-T (or both or neither) should work
> on it.  Hopefully, we can get that resolved by the next IETF meeting.
> 
> Kireeti.

Delivery-date: Thu, 18 Oct 2001 09:08:38 -0700
From: Debanjan Saha <[email-masked]>
To: 'Ping Pan' <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 12:08:10 -0400

Ping Pan
>> 
>> To me, what carriers want are (1) How to preserve data path when control
>> channel/entity fails? 

>Apply fast reroute. 

Why would you do fast reroute if your data channel is still up?

Debanjan

Delivery-date: Thu, 18 Oct 2001 09:08:26 -0700
Date: Thu, 18 Oct 2001 12:03:52 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Ping Pan <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

> >
> > To me, what carriers want are (1) How to preserve data path when control
> > channel/entity fails?
> 
> Apply fast reroute.
> 

Doesn't work

> > (2) How to resync/recover data path information after
> > failure recovers?
> >
> > I still don't have good answers to (1), which is a hard requirement. I
> > understand the solution may be a local decision. Yet, if local behavior may
> > impact interworking, it's better be specified. For (2), I have a fundamental
> > requirement question: does recover/resync from neighbor NE (what's being
> > proposed by Ping Pan) acceptable to transport service providers?
> 
> Why not?
> 

Why why not?

> > because this is
> > not conventional done in transport network.
> >
> 
> How so? Feed us more.
> 

See my previous emails.

Delivery-date: Thu, 18 Oct 2001 08:34:42 -0700
Date: Thu, 18 Oct 2001 08:28:52 -0700
From: Ping Pan <[email-masked]>
To: Yangguang Xu <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

Yangguang Xu wrote:
> 
> To me, what carriers want are (1) How to preserve data path when control
> channel/entity fails? 

Apply fast reroute. 

> (2) How to resync/recover data path information after
> failure recovers?
> 
> I still don't have good answers to (1), which is a hard requirement. I
> understand the solution may be a local decision. Yet, if local behavior may
> impact interworking, it's better be specified. For (2), I have a fundamental
> requirement question: does recover/resync from neighbor NE (what's being
> proposed by Ping Pan) acceptable to transport service providers? 

Why not?

> because this is
> not conventional done in transport network.
>

How so? Feed us more.

- Ping

> Cheers,
> 
> Yangguang

Delivery-date: Thu, 18 Oct 2001 08:18:03 -0700
Date: Thu, 18 Oct 2001 08:14:13 -0700
From: Ping Pan <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Zhi-Wei,

Zhi-Wei Lin wrote:
> 
> 
> <z>I apologize because I can't look back at all the emails (I'm at the
> ITU meeting and is connecting over a phone line). I will give you more
> details on this when I get back.
> 
> Essentially I've had email exchanges with Ping Pan on this issue for a
> while and asked some questions that has still not been answered. I will
> dig those out and forward to this group probably the week of Oct. 29.</z>
> 

Sigh ... unbelievable!

If I recall, you had sent me some emails on how graceful restart works
several weeks ago. I had replied all but one, where you were asking
about how Session Attribute object would work here. I thought it was
best to read the RSVP-TE draft more carefully.

I also recalled that I had told you enough without telling you exactly
how I was about to implement graceful restart. :-( Yes, there may have
some corner cases on restarting at ingress *depending* on how your
router works. However, I felt that the draft was generic enough to cover
all the cases. All the issues that you had asked had been worked out by
the authors, including the ones for OIF UNI....

So if you feel that it's broken, let all of us know. There is no point
of sending many private emails and expecting others to reply everyone of
them. If short of a reply, you start to put people's name all over the
place.

- Ping

Delivery-date: Thu, 18 Oct 2001 08:09:50 -0700
From: John Drake <[email-masked]>
To: Yangguang Xu <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 08:05:21 -0700

Yes I did.  I probably should have replied to it.

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 7:04 AM
To: John Drake
Cc: [email-masked]
Subject: Re: Moving right along ...

> <z>I think Yangguang mentioned some. If you look back at the email
> archive, I think some folks from Netplane and others also made some
> comments. And yes, these comments were made when the resync stuff was
> first added. The comments were simply not addressed adequately (in my
> opinion of course).</z>
> 
> JD:  And Fong answered the questions completely.
> 

Yea, probably in the scope of your knowledge.

BTW, did you see Gopal's response to Fong's response. It was posted at MPLS
WG. 

Yangguang

Delivery-date: Thu, 18 Oct 2001 07:53:16 -0700
From: John Drake <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 07:49:53 -0700

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 5:47 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: Moving right along ...

SNIPPED

> As for the rest, let me juxtapose your comments on switching type
> and M0/M1; I will say nothing, hoping that the juxtaposition will
> speak for itself.
> 

<z>The switching type is in a "standard" document, while the M0/M1 is in 
the "non-standard" document. I will let that speak for itself as well. 
And by the way, when you made this comment are making it as a chair or 
as a contributor?</z>

JD:  Actually, the signalling drafts are on exactly the same technical
footing as the "non-standard" draft,
so I think your attempt to draw a distinction between the two is specious at
best.  Once again, a feature
or capability is added if the community as a whole decides, through a
process of rough consensus, that it
should be added.  No one other than you has indicated an issue with
switching type and I haven't seen a groundswell
of support for M0/M1.

  

Zhi

Delivery-date: Thu, 18 Oct 2001 07:05:29 -0700
Date: Thu, 18 Oct 2001 10:03:41 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: John Drake <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

> <z>I think Yangguang mentioned some. If you look back at the email
> archive, I think some folks from Netplane and others also made some
> comments. And yes, these comments were made when the resync stuff was
> first added. The comments were simply not addressed adequately (in my
> opinion of course).</z>
> 
> JD:  And Fong answered the questions completely.
> 

Yea, probably in the scope of your knowledge.

BTW, did you see Gopal's response to Fong's response. It was posted at MPLS WG. 

Yangguang

Delivery-date: Thu, 18 Oct 2001 06:56:33 -0700
From: John Drake <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 06:52:27 -0700

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 12:31 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: Moving right along ...

SNIPPED 

<z>Yes, I agree it is a strong statement. But I think it's warranted.
Yes, it solves a problem, but there are many differnet solutions of
which Yangguang mentioned one such. Who made these decisions to include?
Is there a need to look at both these (and possibly other) methods first
prior to including in a WG document? IETF is a public standards forum
where discussions on what is chosen is done in public for everyone's
benefit, and therefore this decision should be considered by everyone
prior to adding anything...</z>

JD:  If a valid technical issue is raised, the authors of a draft attempt
to deal with it and their efforts are documented in a subsequent version
of the draft.  If the proposed solution is inadequate or someone has a 
better solution, then the proposed solution is either changed or fixed.

I don't think an exhaustive public discussion of every possible solution
is particularly useful.  And as has been pointed out, we're dealing with
rough consensus;  this means that we don't necessarily need to get your
approval for everything that we do.

> > Is it correct to simply include content of individual drafts into
> > a WG draft that is in last call without adequate data on whether it
> > handles all the different cases?
> 
> Clearly not.  Are you suggesting that that was what was done?
> 
> It is a judgment call to include significant new material into a
> document in last call.  In this instance, handling restart of the
> control plane is of sufficient importance to warrant inclusion.
> That said, this inclusion happened some time ago (late July);
> your comment would have been more timely then.
> 
> In any case, it would be more helpful if you pointed out
> scenarios that are missing, and even better if you had concrete
> suggestions to fix things.
> 

<z>I think Yangguang mentioned some. If you look back at the email
archive, I think some folks from Netplane and others also made some
comments. And yes, these comments were made when the resync stuff was
first added. The comments were simply not addressed adequately (in my
opinion of course).</z>

JD:  And Fong answered the questions completely.

<z>Yes, I agree with "rough consensus" (in a way), but if things that
are added are unclear or doesn't seem to address any requirements, and
the private discussions are just that: a private discussion. I would
think that the authors need to have these discussions in the open to get
as much participation and "buy-in" as possible.

For example, I've commented on the "switching type" as part of signaling
for some time, and never really understand why this was added. Yes,
there has been some explanations, but I don't think those are reasons
for adding. It sounds like it is something that "seems" to be
reasonable. If something can be added because it "seems" reasonable,
then does that mean if I think there is something that "seems"
reasonable, the authors would be compelled to add these or who makes the
decision to add these?

JD:  The authors add it and invite comments and criticism.  I have made
several attempts to explain switching type to you, with no apparent success.
I haven't had this problem explaining it to anyone else.

Of course, Juergen has provided some examples of issues as well, so
those still need to be resolved. And I believe they need to be resolved
in the open public email list so that everyone understand the decisions.
Let's open up the commenting and decision process to the "common folks"
like myself! 
</z>

JD:  The attempt was made to address Juergen's comments.  It would be nice
for him, rather than you, to indicate whether they were adequately
addressed.
As for you second point, we'd love to see valid technical issues and good
technical solutions from you or anyone else.  As St Francis said, he would
accept wisdom regardless of the source.

Delivery-date: Thu, 18 Oct 2001 05:53:57 -0700
Date: Thu, 18 Oct 2001 08:46:39 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

Hi Kireeti,

> The docs that have a one week Last Call have been Last Called at least
> twice previously.  The process has to terminate at some point.  Also,
> the docs were posted some time ago.  You don't have to wait for someone
> to suggest that you comment -- please fire at will.
> 

<z>yes, of course. I've tried to work on some of the issues off-line 
with the authors prior to the last call process. But I figured since 
this is the last call, I need to send something to the mail list...</z>

> Alan Kullberg made a comment (and a valid one) on Sept 20.  The
> resync stuff was sent out July 24.  Perhaps in your opinion, that
> counts as "when the resync stuff was first added".
> 

<z>I apologize because I can't look back at all the emails (I'm at the 
ITU meeting and is connecting over a phone line). I will give you more 
details on this when I get back.

Essentially I've had email exchanges with Ping Pan on this issue for a 
while and asked some questions that has still not been answered. I will 
dig those out and forward to this group probably the week of Oct. 29.</z>

> I don't know how to put this politely, so let me be blunt.  Using
> the fact that others had comments to put roadblocks in the process
> is not kosher.  If you said "Hey, there is an issue with ingress
> LSRs", I buy that, and I too would like to see this fixed.  I hate
> to speak for Alan, but I believe he wants a fix, not to hold up
> progress.
> 
> I hate too to impute motives to you wrongly.  It's very likely
> that you got confused with the loooong discussion on NTIP resync.
> However, this is a Last Call process; vague references to "the
> comments were simply not addressed adequately" just do not cut it.
> State crisply and definitely the issues you feel exist, and let's
> resolve them if we can, or get rough consensus if we cannot, and
> put this behind us.
> 

<z>I don't think my position was to put up roadblocks. What I am doing 
is trying to resolve issues that are still pending. If you equate the 
two, then that's your call.</z>

> As for the rest, let me juxtapose your comments on switching type
> and M0/M1; I will say nothing, hoping that the juxtaposition will
> speak for itself.
> 

<z>The switching type is in a "standard" document, while the M0/M1 is in 
the "non-standard" document. I will let that speak for itself as well. 
And by the way, when you made this comment are making it as a chair or 
as a contributor?</z>

Zhi

Envelope-to: [email-masked]
Delivery-date: Thu, 18 Oct 2001 03:46:55 -0700
Date: Thu, 18 Oct 2001 03:45:43 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: Moving right along ...
Cc: [email-masked]

Hi Steve,

> In addition to the time crunch, we have the issue that some comment may
> be derived from the status of related work in Study Group 15. This has
> been communicated before, but to summarize some results that are expected
> by 25 October:
> We expect consent on the following documents related to GMPLS:
> G.ason, now numbered G.8080/Y.1304 "Architecture for the Automatic Switched
>   Optical Network"
> G.dcm, now numbered G.7713/Y.1704 "Distributed Connection Management"
> G.disc, now numbered G.7714/Y.1705 "Generalized Automatic Discovery"
> G.dcn, now numbered G.7712/Y.1703 "Architecture and Specification of
>   Data Communications Network"

That would be very useful.  Would these be publicly available?

> We expect also to be able to report progress relating to the VBI/New
> Equipment Partitioning work, related to OLI/LMP/NTIP work.
> 
> While full harmonization of the ITU-T/IETF work may be out of reach
> for the first effort, people should at least have the opportunity to
> read the ITU-T documents and consider the impact.

While this is also very useful (I've glanced at the documents, thanks
for the urls), as you point out, these relate to LMP-WDM, and that
document isn't under consideration even as a WG document until we
resolve whether the IETF or the ITU-T (or both or neither) should work
on it.  Hopefully, we can get that resolved by the next IETF meeting.

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Thu, 18 Oct 2001 03:29:09 -0700
Date: Thu, 18 Oct 2001 03:28:05 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Moving right along ...

Hi Bert,

> Since (as you claim above) the WG chairs have been a bit lax

You're being kind -- there's little doubt that the chairs have
been lax.

> is a 1 week review peried not a bit aggressive?

My recollection is that we had decided on a one week final Last
Call.  In any case, it is moot, since the SG 15 meeting is on,
I think extending this to two weeks is justified.

> It is named a "IETF Last Call"... but this is admin detail...

Ah, thanks for the correction!

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Thu, 18 Oct 2001 03:05:31 -0700
Date: Thu, 18 Oct 2001 03:05:00 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Moving right along ...
Cc: [email-masked]

Hi Leen,

> You might not have noticed that the week you allow for comment 
> falls exactly in the middle of the two week ITU-T SG15 meeting 

You're right, sorry.  It would definitely be good to hear from
the very folks who would be in that meeting.

Let's move the comment period to end Oct 30th.

Thanks for bringing this up,
Kireeti.

Envelope-to: [email-masked]
Delivery-date: Thu, 18 Oct 2001 03:03:07 -0700
Date: Thu, 18 Oct 2001 02:59:30 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Moving right along ...
Cc: [email-masked]

Hi Zhi,

> Incidentally, what is the procedure for the length of time for last
> call?

The docs that have a one week Last Call have been Last Called at least
twice previously.  The process has to terminate at some point.  Also,
the docs were posted some time ago.  You don't have to wait for someone
to suggest that you comment -- please fire at will.

> <z>I think Yangguang mentioned some. If you look back at the email
> archive, I think some folks from Netplane and others also made some
> comments. And yes, these comments were made when the resync stuff was
> first added.

Alan Kullberg made a comment (and a valid one) on Sept 20.  The
resync stuff was sent out July 24.  Perhaps in your opinion, that
counts as "when the resync stuff was first added".

> The comments were simply not addressed adequately (in my
> opinion of course).

I don't know how to put this politely, so let me be blunt.  Using
the fact that others had comments to put roadblocks in the process
is not kosher.  If you said "Hey, there is an issue with ingress
LSRs", I buy that, and I too would like to see this fixed.  I hate
to speak for Alan, but I believe he wants a fix, not to hold up
progress.

I hate too to impute motives to you wrongly.  It's very likely
that you got confused with the loooong discussion on NTIP resync.
However, this is a Last Call process; vague references to "the
comments were simply not addressed adequately" just do not cut it.
State crisply and definitely the issues you feel exist, and let's
resolve them if we can, or get rough consensus if we cannot, and
put this behind us.

As for the rest, let me juxtapose your comments on switching type
and M0/M1; I will say nothing, hoping that the juxtaposition will
speak for itself.

> For example, I've commented on the "switching type" as part of signaling
> for some time, and never really understand why this was added.  Yes,
> there has been some explanations, but I don't think those are reasons
> for adding. It sounds like it is something that "seems" to be
> reasonable. If something can be added because it "seems" reasonable,
> then does that mean if I think there is something that "seems"
> reasonable, the authors would be compelled to add these or who makes the
> decision to add these?

> >       flag 13: M0
> >       flag 14: M1
...
> <z>My understanding is if someone uses this, then it can be included.
> Therefore the reason is that some company uses it. Hope this is reason
> enough!</z>

Kireeti.

Delivery-date: Thu, 18 Oct 2001 01:53:35 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 10:47:31 +0200

Kireeti writes
> 
> Despite the energetic subject line, we the WG chairs have been
> lax in our duties.  So, here goes:
> 
> Lou has submitted the latest versions of the generalized
> signaling documents quite some time ago (thanks, Lou):
> 
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> 
> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> 
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> All of these should have addressed the issues raised in the earlier
> versions.  Please read the new versions, and send your comments to
> the list by Tuesday Oct 23.  At that point, when the final round
>
Since (as you claim above) the WG chairs have been a bit lax in their
duties... is a 1 week review peried not a bit aggressive? In fact
I do like agressive schedules... but we should also be realistic and
be sensitive to the fact that some people may have other (non-IETF)
duties.

I would suggest that if anyone requests for a normal 2 week review
period that we should grant that, certainly if the requestor indeed
intends to seriously review.

> of comments have been addressed, these docs will go to IESG Last
> Call.  If any one objects to sending these docs to IESG Last Call,
> raise your issues now.
> 
It is named a "IETF Last Call"... but this is admin detail...

Bert

Delivery-date: Thu, 18 Oct 2001 00:44:55 -0700
Date: Thu, 18 Oct 2001 01:43:44 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mak, L (Leen)" <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ...

Leen and Kireeti,
In addition to the time crunch, we have the issue that some comment may
be derived from the status of related work in Study Group 15. This has
been communicated before, but to summarize some results that are expected
by 25 October:
We expect consent on the following documents related to GMPLS:
G.ason, now numbered G.8080/Y.1304 "Architecture for the Automatic Switched
  Optical Network"
G.dcm, now numbered G.7713/Y.1704 "Distributed Connection Management"
G.disc, now numbered G.7714/Y.1705 "Generalized Automatic Discovery"
G.dcn, now numbered G.7712/Y.1703 "Architecture and Specification of
  Data Communications Network"

We expect also to be able to report progress relating to the VBI/New
Equipment Partitioning work, related to OLI/LMP/NTIP work.

While full harmonization of the ITU-T/IETF work may be out of reach
for the first effort, people should at least have the opportunity to
read the ITU-T documents and consider the impact.
Regards,
Steve Trowbridge
Chair ITU-T WP3/15

"Mak, L (Leen)" wrote:
> 
> Kireeti,
> 
> You might not have noticed that the week you allow for comment
> falls exactly in the middle of the two week ITU-T SG15 meeting
> period. SG15 is the group where a.o. SDH and OTN are being
> worked.
> This implies that a lot of experts in these areas are fully occupied
> in Geneva. Of course they are able to work at night and over the
> weekend, however, a lot of them do already do that in editing
> sessions etc.
> 
> Wouldn't it be nice to give these people a break, and extend the
> period for comment by another week, so until Oct. 30?
> 
> Thanks for your consideration,
> 
> Leen Mak.

Delivery-date: Thu, 18 Oct 2001 00:31:58 -0700
Date: Thu, 18 Oct 2001 03:31:21 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

Hi Kireeti, all,

Kireeti Kompella wrote:
> 
> Hi Zhi,
> 
> > -- cr-ldp is in version 4, which means that the revisions done to
> > rsvp-te05 has not been reflected there...how do we resolve this
> > inconsistency?
> 
> Would bumping the version number of the cr ldp draft work for you? :-)
> 
> I see that Don has posted a new version -- thanks, Don.
> 

<z> :-) thanks. In that case, I assume that the -05 version is now that
one going for IESG last call.

Incidentally, what is the procedure for the length of time for last
call? I hope you do realize that there are many people who are involved
with this who are attending a SG 15 ITU meeting this and next week, and
therefore do not have time. I would request that the last call deadline
be extended to the end of the month, as many of the major individual
players are currently tied down...
</z>

> > -- rsvp-te-05 and signaling-06 has incorporated the restart capability
> > as proposed by Ping Pan. However, that work was never looked at
> > carefully and some issues remain on how this covers all the different
> > cases.
> 
> "that work was never looked at carefully" is a strong statement.
> The work *was* looked at carefully, at least by some folks.  There
> may well be corner cases that have been missed; it would be an
> excellent idea to point those out.
> 

<z>Yes, I agree it is a strong statement. But I think it's warranted.
Yes, it solves a problem, but there are many differnet solutions of
which Yangguang mentioned one such. Who made these decisions to include?
Is there a need to look at both these (and possibly other) methods first
prior to including in a WG document? IETF is a public standards forum
where discussions on what is chosen is done in public for everyone's
benefit, and therefore this decision should be considered by everyone
prior to adding anything...</z>

> > Is it correct to simply include content of individual drafts into
> > a WG draft that is in last call without adequate data on whether it
> > handles all the different cases?
> 
> Clearly not.  Are you suggesting that that was what was done?
> 
> It is a judgment call to include significant new material into a
> document in last call.  In this instance, handling restart of the
> control plane is of sufficient importance to warrant inclusion.
> That said, this inclusion happened some time ago (late July);
> your comment would have been more timely then.
> 
> In any case, it would be more helpful if you pointed out
> scenarios that are missing, and even better if you had concrete
> suggestions to fix things.
> 

<z>I think Yangguang mentioned some. If you look back at the email
archive, I think some folks from Netplane and others also made some
comments. And yes, these comments were made when the resync stuff was
first added. The comments were simply not addressed adequately (in my
opinion of course).</z>

> > -- signaling-06 also includes several new items in there that doesn't
> > seem to be added because of a identified need (do a diff to find the
> > differences). Why were they added to the document (I'm not questioning
> > them, just asking for clarifying explanation)?
> 
> Good question, but rather open-ended.  Can you mention a few
> specific items?  At that point, Lou et al could mail the list
> with answers.
> 

<z>As I said, that is easily seen by simply diff'ing the two versions.
One is RR object. Again, I think I understand the reason for it, but
this addition was never discussed in an open forum where everyone can
make a decision. It would be useful (for my education) if I can hear
what the reasons were for adding (why this is needed to support some
requirements), and see if everyone agrees to this...</z>

> > -- in signaling-06, since we've decided that this set of I-Ds are to be
> > consistent with the standards for the respective technologies, then
> > "Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something
> > that is used in G.709 or G.872 to describe the types of the signals...
> 
> I like being consistent with G.709/872.  Eric, Dimitri, others:
> comments on terminology?
> 

<z>Thanks</z>

> > -- There are still some technical questions remaining on some content of
> > the sonet-sdh-02 that are still been discussed in a private list (my
> > understanding). Shouldn't these be resolved first before it goes for
> > last call?
> 
> Can you take them up with the authors?
> 
> As a general comment, the operative phrase at the IETF is
> "rough consensus".  It would be ideal to have all comments
> addressed, and all issues resolved, but there is a point at
> which we have to declare that the remaining issues/comments
> are not significant enough to halt progress.
> 

<z>Yes, I agree with "rough consensus" (in a way), but if things that
are added are unclear or doesn't seem to address any requirements, and
the private discussions are just that: a private discussion. I would
think that the authors need to have these discussions in the open to get
as much participation and "buy-in" as possible.

For example, I've commented on the "switching type" as part of signaling
for some time, and never really understand why this was added. Yes,
there has been some explanations, but I don't think those are reasons
for adding. It sounds like it is something that "seems" to be
reasonable. If something can be added because it "seems" reasonable,
then does that mean if I think there is something that "seems"
reasonable, the authors would be compelled to add these or who makes the
decision to add these?

Of course, Juergen has provided some examples of issues as well, so
those still need to be resolved. And I believe they need to be resolved
in the open public email list so that everyone understand the decisions.
Let's open up the commenting and decision process to the "common folks"
like myself! 
</z>

> > -- in sonet-sdh-extension-00, we would like to add two new flags into
> > the list of flags for transparency (I have spoken to Eric already, and
> > I'm waiting to have these added in the next version):
> >       flag 13: M0
> >       flag 14: M1
> 
> I don't believe that that should be an issue; however, can you offer
> reasons for their inclusion, just so we know?
> 

<z>My understanding is if someone uses this, then it can be included.
Therefore the reason is that some company uses it. Hope this is reason
enough!</z>

> > -- I believe g709-00 is currently undergoing some changes to align with
> > standards positions and to reflect the work on OTN TDM that is been
> > discussed in ITU study group 15 meeting this week and next week.
> 
> Excellent!
> 
> Kireeti.

Delivery-date: Thu, 18 Oct 2001 00:16:45 -0700
From: "Mak, L (Leen)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Thu, 18 Oct 2001 09:11:41 +0200

Kireeti,

You might not have noticed that the week you allow for comment 
falls exactly in the middle of the two week ITU-T SG15 meeting 
period. SG15 is the group where a.o. SDH and OTN are being 
worked.
This implies that a lot of experts in these areas are fully occupied
in Geneva. Of course they are able to work at night and over the 
weekend, however, a lot of them do already do that in editing 
sessions etc.

Wouldn't it be nice to give these people a break, and extend the
period for comment by another week, so until Oct. 30?

Thanks for your consideration,

Leen Mak.

Delivery-date: Wed, 17 Oct 2001 15:01:54 -0700
Date: Wed, 17 Oct 2001 15:00:45 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Yangguang Xu <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

Yangguang:

Yangguang Xu wrote:

> Kireeti,
>
> >
> > > I still don't have good answers to (1), which is a hard requirement. I
> > > understand the solution may be a local decision. Yet, if local behavior may
> > > impact interworking, it's better be specified.
> >
> > One could make a statement along the lines of: "please try to
> > keep your data plane going if the control plane dies", if that
> > helps.  LMP talks about this ...
> >
>
> I am talking about RSVP-TE.

Both LMP and RSVP has work to do if a control plane dies. LMP on the
neighbor related information and RSVP on connection related information.

>
>
> > > For (2), I have a fundamental
> > > requirement question: does recover/resync from neighbor NE (what's being
> > > proposed by Ping Pan) acceptable to transport service providers? because this is
> > > not conventional done in transport network.
> >
> > Is running GMPLS conventional in transport networks? :-)
> >
>
> No, that's why GMPLS should learn some basic requirements first.
>

>
> > What is the conventional behaviour in transport networks if the
> > control plane goes down?  How is recovery done?  That would be
> > a useful data point (for me, anyway).
> >
>
> Retrieving from local NV storage or remote OS.
>

Retrieving from local storage will not satisfy global consistency.
Synching with the remote OS is what is achieved by the additions
made to RSVP.

>
> > As for the fundamental requirement, it is more like: do you
> > want your data plane to keep going if the control plane crashes?
> > Recovery/resync from neighbor is a mechanism, not a requirement.
> > Of course, there is also the question whether such a mechanism
> > is acceptable to carriers.
> >
>
> It is a requirement. Here is the difference between transport network and IP
> network. I agree with your point from the IP point of view. However, in
> transport network, we are talking about more expensive and less dynamic pipes.
> The data path information can be stored at multiple locations. Yet, there is
> normally a single trusted point. So my question is a fundamental requirement
> question. Is neighbor NE (may be a different vendor's NE) a trusted resource.
> BTW, I happened to work for a carrier for several years. When I talking about
> requirement, I used my previous experience and recent discussion with some other
> carriers.
>

Paranoia should have restricted application :-) Here we are talking about existing
connections in a single carrier domain. A carrier should trust all its NEs to do its
job during path setup (and hence keeping its database up-to-date). All we are
doing in the re-synch is querying the info in the database. For this reason, in my
opinion,
one should not vouch for a centralized approach.

Cheers,

sudheer

>
> Regards,
>
> Yangguang

Delivery-date: Wed, 17 Oct 2001 14:33:37 -0700
Date: Wed, 17 Oct 2001 14:32:29 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Yangguang Xu <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ...

Hi Yangguang:

Yangguang Xu wrote:

> Kireeti,
>
> >
> > > Is it correct to simply include content of individual drafts into
> > > a WG draft that is in last call without adequate data on whether it
> > > handles all the different cases?
> >
> > Clearly not.  Are you suggesting that that was what was done?
> >
> > It is a judgment call to include significant new material into a
> > document in last call.  In this instance, handling restart of the
> > control plane is of sufficient importance to warrant inclusion.
> > That said, this inclusion happened some time ago (late July);
> > your comment would have been more timely then.
> >
> > In any case, it would be more helpful if you pointed out
> > scenarios that are missing, and even better if you had concrete
> > suggestions to fix things.
>
> Besides some "corner" issues raised recently yet not answered or answered
> publicly. I've some non-corner questions.
>
> To me, what carriers want are (1) How to preserve data path when control
> channel/entity fails? (2) How to resync/recover data path information after
> failure recovers?
>

Agreed on the requirements.

>
> I still don't have good answers to (1), which is a hard requirement. I
> understand the solution may be a local decision. Yet, if local behavior may
> impact interworking, it's better be specified. For (2), I have a fundamental
> requirement question: does recover/resync from neighbor NE (what's being
> proposed by Ping Pan) acceptable to transport service providers? because this is
> not conventional done in transport network.
>

On (2) what other options do we have?

With distributed control plane (GMPLS), the neighboring entities
will preserve the information a failed NE needs. Yes
this may be little scary if we donot trust our control plane... in that case
we need to solve the scaring issues.

- sudheer

>
> Cheers,
>
> Yangguang

Delivery-date: Wed, 17 Oct 2001 14:31:58 -0700
Date: Wed, 17 Oct 2001 17:23:16 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Moving right along ...

Kireeti,

> 
> > I still don't have good answers to (1), which is a hard requirement. I
> > understand the solution may be a local decision. Yet, if local behavior may
> > impact interworking, it's better be specified.
> 
> One could make a statement along the lines of: "please try to
> keep your data plane going if the control plane dies", if that
> helps.  LMP talks about this ...
> 

I am talking about RSVP-TE.

> > For (2), I have a fundamental
> > requirement question: does recover/resync from neighbor NE (what's being
> > proposed by Ping Pan) acceptable to transport service providers? because this is
> > not conventional done in transport network.
> 
> Is running GMPLS conventional in transport networks? :-)
> 

No, that's why GMPLS should learn some basic requirements first. 

> What is the conventional behaviour in transport networks if the
> control plane goes down?  How is recovery done?  That would be
> a useful data point (for me, anyway).
> 

Retrieving from local NV storage or remote OS.

> As for the fundamental requirement, it is more like: do you
> want your data plane to keep going if the control plane crashes?
> Recovery/resync from neighbor is a mechanism, not a requirement.
> Of course, there is also the question whether such a mechanism
> is acceptable to carriers.
> 

It is a requirement. Here is the difference between transport network and IP
network. I agree with your point from the IP point of view. However, in
transport network, we are talking about more expensive and less dynamic pipes.
The data path information can be stored at multiple locations. Yet, there is
normally a single trusted point. So my question is a fundamental requirement
question. Is neighbor NE (may be a different vendor's NE) a trusted resource.
BTW, I happened to work for a carrier for several years. When I talking about
requirement, I used my previous experience and recent discussion with some other
carriers.

Regards,

Yangguang

Envelope-to: [email-masked]
Delivery-date: Wed, 17 Oct 2001 14:07:25 -0700
Date: Wed, 17 Oct 2001 14:05:40 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Moving right along ...
Cc: [email-masked], [email-masked]

Hi Yangguang,

> I still don't have good answers to (1), which is a hard requirement. I
> understand the solution may be a local decision. Yet, if local behavior may
> impact interworking, it's better be specified.

One could make a statement along the lines of: "please try to
keep your data plane going if the control plane dies", if that
helps.  LMP talks about this ...

> For (2), I have a fundamental
> requirement question: does recover/resync from neighbor NE (what's being
> proposed by Ping Pan) acceptable to transport service providers? because this is
> not conventional done in transport network.

Is running GMPLS conventional in transport networks? :-)

What is the conventional behaviour in transport networks if the
control plane goes down?  How is recovery done?  That would be
a useful data point (for me, anyway).

As for the fundamental requirement, it is more like: do you
want your data plane to keep going if the control plane crashes?
Recovery/resync from neighbor is a mechanism, not a requirement.
Of course, there is also the question whether such a mechanism
is acceptable to carriers.

Kireeti.

Delivery-date: Wed, 17 Oct 2001 13:42:57 -0700
From: Fugui Wang <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Moving right along ...
Date: Wed, 17 Oct 2001 16:39:24 -0400

Jonathan,

Thanks for the answer. But still have questions regarding your
answer. Please see in line.

Fugui

>> A couple of questions regarding the messages in the new
>> LMP draft:
>> 
>> (1) BeginVerifyAck message: 
>> Since REMOTE_LINK_ID is optional in the BeginVerify
>> message, how could LOCAL_LINK_ID be a required object
>> in the BeginVerifyAck message? When you compose the 
>> BeginVerifyAck message, you may not know the 
>> LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID
>> in the BeginVerify message.
>Assuming you don't receive the REMOTE_LINK_ID in BeginVerify message:
>If you have locally assigned the Interface to a TE Link, then you will
>know
>the LOCAL_LINK_ID.  If the Interface has not been assigned a TE link, >then
>you put a value of zero in the LOCAL_LINK_ID (same rule as BeginVerify
>message).

But if the node which received the BeginVerify message has multiple
TE links to the sender, how does it know which one to pick?

>> 
>> REMOTE_LINK_ID object should be within the 
>> BeginVerifyAck message. Otherwise when receiving
>> BeginVerifyAck, the node won't know for which 
>> TE link the BeginVerifyAck is for.
>The Message_ID_ACK object is sufficient to know which TE link the
>BeginVerifyAck is for.
Well, theoretically I agree with you. But doesn't that mean that
in the sender side, all TE links need to pick Message_ID from 
a global place? Also, in order to tell the TE link from the
Message_ID_ACK, the sender side need to buffer all of the 
unacknowledged message_ID <==> TE link mapping info. 
This would be an additional requirement for the send side.
Even if you decide to do so, you still need more sophisticated
schemes to discard those lost messages from the mapping info
list. 
However,if we simply add the REMOTE_LINK_ID in the 
BeginVerifyAck message, it would be much easier for the 
sender side to implement. Same problem also exists for 
the remaining two questions below.

>> 
>> So maybe we should change the BeginVerifyAck message to:
>> <BeginVerifyAck Message> ::= <Common Heade>
>>                              [<LOCAL_LINK_ID>]
>>                              <REMOTE_LINK_ID>
>>                              <MESSAGE_ID_ACK>
>>                              <BEGIN_VERIFY_ACK>
>>                              <VERIFY_ID>
>> Actually, I think LOCAL_LINK_ID could also be removed
>> because it won't be useful for the receiver side 
>> except providing a redundant check.
>> 
>> (2) LinkSummaryAck:
>> Again, REMOTE_LINK_ID object should be there. 
>> Otherwise, the remote node won't know for which
>> TE link the LinkSummaryAck is for. Using 
>> MESSAGE_ID_ACK to identify that is difficult
>> since that will require the MESSAGE_ID to be
>> unique over the node and we also need to use
>> the MESSAGE_ID as an index to locate the TE link
>> efficiently. (In the old LMP draft, I did see that 
>> "When combined with the Local TE Link Id ..., the 
>> MessageId field uniquely identifies a message.")
>The MESSAGE_ID_ACK is unique within the scope of the LMP adjacency and >is
>sufficient to identify the LinkSummaryAck message.
 
>> Changing the message to the following
>> format will make life much easier:
>> <LinkSummaryAck Message> ::= <Common Header>
>>                              <MESSAGE_ID_ACK>
>>                              <REMOTE_LINK_ID>
>> 
>> It would also be nice if we can add the REMOTE_LINK_ID
>> object to LinkSummaryNack message.
>> 
>> Thanks,
>> Fugui
>> 

Delivery-date: Wed, 17 Oct 2001 13:28:26 -0700
Date: Wed, 17 Oct 2001 16:24:15 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Moving right along ...

Kireeti,

> 
> > Is it correct to simply include content of individual drafts into
> > a WG draft that is in last call without adequate data on whether it
> > handles all the different cases?
> 
> Clearly not.  Are you suggesting that that was what was done?
> 
> It is a judgment call to include significant new material into a
> document in last call.  In this instance, handling restart of the
> control plane is of sufficient importance to warrant inclusion.
> That said, this inclusion happened some time ago (late July);
> your comment would have been more timely then.
> 
> In any case, it would be more helpful if you pointed out
> scenarios that are missing, and even better if you had concrete
> suggestions to fix things.

Besides some "corner" issues raised recently yet not answered or answered
publicly. I've some non-corner questions.

To me, what carriers want are (1) How to preserve data path when control
channel/entity fails? (2) How to resync/recover data path information after
failure recovers?

I still don't have good answers to (1), which is a hard requirement. I
understand the solution may be a local decision. Yet, if local behavior may
impact interworking, it's better be specified. For (2), I have a fundamental
requirement question: does recover/resync from neighbor NE (what's being
proposed by Ping Pan) acceptable to transport service providers? because this is
not conventional done in transport network.

Cheers,

Yangguang

Delivery-date: Wed, 17 Oct 2001 12:52:54 -0700
From: Heiles Juergen <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: AW: Moving right along ...
Date: Wed, 17 Oct 2001 21:50:50 +0200

Concerning draft-ietf-mpls-generalized-signaling-06.txt
I am in discussion with the authors on the G-PID values. An update is =
needed here.

Concerning the SDH/Sonet documents I want to raise a formal issue.
We have now two documents, a document that covers ITU/ANSI standard =
features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that =
covers non-standard features =
(draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in =
Appendix 1 of the standard feature document a non standard feature =
(Group signals) is listed. It is even mentioned that the use of groups =
(AUG, STSG, ...) is not described in standards.
So this feature should be moved to the non-standards document. =
Otherwise the split of the documents doesn't make sense.

For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt =
I prefer to have the same coding for Sonet and SDH. That makes the =
implementation for Sonet and SDH simpler. Furthermore ITU and T1 have =
tried over the last years to align Sonet and SDH as much as possible. =
The definition of different labels for Sonet and SDH contradicts these =
activities.

Juergen

=20
> -----Urspr=FCngliche Nachricht-----
> Von: Kireeti Kompella [mailto:[email-masked]]
> Gesendet: Mittwoch, 17. Oktober 2001 11:25
> An: [email-masked]
> Betreff: Moving right along ...
>=20
>=20
> Despite the energetic subject line, we the WG chairs have been
> lax in our duties.  So, here goes:
>=20
> Lou has submitted the latest versions of the generalized
> signaling documents quite some time ago (thanks, Lou):
>=20
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
>=20
> Also, Eric has posted the SONET/SDH documents (merci, Eric):
>=20
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
>=20
> All of these should have addressed the issues raised in the earlier
> versions.  Please read the new versions, and send your comments to
> the list by Tuesday Oct 23.  At that point, when the final round
> of comments have been addressed, these docs will go to IESG Last
> Call.  If any one objects to sending these docs to IESG Last Call,
> raise your issues now.
>=20
> I see that the GMPLS architecture document is a CCAMP WG doc, but
> the minutes say that we should look for consensus on the list.  So,
> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> will progress to WG Last Call.
>=20
> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> list know what your thinking is on these.  (BTW, both these docs
> were to have some edits done.  If the authors could do that before
> the next IETF, we can try to make more progress then.)
>=20
> The MIB overview doc was recently posted.  Please read and comment
> to the list.
>=20
> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> was generally thought to be useful; it will be published as a
> CCAMP informational doc.  This begins a two week Last Call on
> the doc, ending Tuesday Oct 30.
>=20
> There was no consensus on whether the GMPLS framework should be
> a CCAMP WG doc.  Please indicate your pleasure.
>=20
> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.
>=20
> The OLI requirements doc was broadly accepted.  Please let the
> list know if you think this doc should be a WG doc.
>=20
> It's still open whether we (the IETF) should be working on
> LMP-WDM.  I urge the authors to keep on working on the doc, and
> keeping it in sync with LMP; however, we will postpone making it
> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> happen in Salt Lake City.
>=20
> There was reasonable interest in the tunnel trace requirements
> doc.  Let's formalize this: do you think this should be made a
> CCAMP WG document?
>=20
> Summary:
>=20
> 1) Final comments and IESG Last Call readiness for:
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
>=20
> 2) Should the following documents be CCAMP WG docs?
> draft-bonica-tunneltrace-02.txt
> draft-fontana-ccamp-gmpls-g709-00.txt
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> draft-many-ccamp-gmpls-framework-00.txt
> draft-many-oli-reqts-00.txt
>=20
> 3) Comment on MIB overview.
>=20
> 4) Two week Last Call comments on
> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
>=20
> 5) Last Call readiness of
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-ietf-ccamp-lmp-01.txt
>=20
> Thanks,
> Kireeti.
>=20

Envelope-to: [email-masked]
Delivery-date: Wed, 17 Oct 2001 12:12:47 -0700
Date: Wed, 17 Oct 2001 12:03:58 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: GMPLS architecture draft

I've been corrected twice already, so just so everyone knows:
the GMPLS architecture document had good consensus on the list
to make it a CCAMP WG document.  Cross that off the list of
things you have to do.

Thanks, and apologies to Eric and the rest of the authors ...

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Wed, 17 Oct 2001 12:00:52 -0700
Date: Wed, 17 Oct 2001 11:52:29 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Moving right along ...
Cc: [email-masked]

Hi Zhi,

> -- cr-ldp is in version 4, which means that the revisions done to 
> rsvp-te05 has not been reflected there...how do we resolve this 
> inconsistency?

Would bumping the version number of the cr ldp draft work for you? :-)

I see that Don has posted a new version -- thanks, Don.

> -- rsvp-te-05 and signaling-06 has incorporated the restart capability 
> as proposed by Ping Pan. However, that work was never looked at 
> carefully and some issues remain on how this covers all the different 
> cases.

"that work was never looked at carefully" is a strong statement.
The work *was* looked at carefully, at least by some folks.  There
may well be corner cases that have been missed; it would be an
excellent idea to point those out.

> Is it correct to simply include content of individual drafts into 
> a WG draft that is in last call without adequate data on whether it 
> handles all the different cases?

Clearly not.  Are you suggesting that that was what was done?

It is a judgment call to include significant new material into a
document in last call.  In this instance, handling restart of the
control plane is of sufficient importance to warrant inclusion.
That said, this inclusion happened some time ago (late July);
your comment would have been more timely then.

In any case, it would be more helpful if you pointed out
scenarios that are missing, and even better if you had concrete
suggestions to fix things.

> -- signaling-06 also includes several new items in there that doesn't 
> seem to be added because of a identified need (do a diff to find the 
> differences). Why were they added to the document (I'm not questioning 
> them, just asking for clarifying explanation)?

Good question, but rather open-ended.  Can you mention a few
specific items?  At that point, Lou et al could mail the list
with answers.

> -- in signaling-06, since we've decided that this set of I-Ds are to be 
> consistent with the standards for the respective technologies, then 
> "Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something 
> that is used in G.709 or G.872 to describe the types of the signals...

I like being consistent with G.709/872.  Eric, Dimitri, others:
comments on terminology?

> -- There are still some technical questions remaining on some content of 
> the sonet-sdh-02 that are still been discussed in a private list (my 
> understanding). Shouldn't these be resolved first before it goes for 
> last call?

Can you take them up with the authors?

As a general comment, the operative phrase at the IETF is
"rough consensus".  It would be ideal to have all comments
addressed, and all issues resolved, but there is a point at
which we have to declare that the remaining issues/comments
are not significant enough to halt progress.

> -- in sonet-sdh-extension-00, we would like to add two new flags into 
> the list of flags for transparency (I have spoken to Eric already, and 
> I'm waiting to have these added in the next version):
>       flag 13: M0
>       flag 14: M1

I don't believe that that should be an issue; however, can you offer
reasons for their inclusion, just so we know?

> -- I believe g709-00 is currently undergoing some changes to align with 
> standards positions and to reflect the work on OTN TDM that is been 
> discussed in ITU study group 15 meeting this week and next week.

Excellent!

Kireeti.

Delivery-date: Wed, 17 Oct 2001 11:58:43 -0700
From: Jonathan Lang <[email-masked]>
To: 'Fugui Wang' <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Moving right along ...
Date: Wed, 17 Oct 2001 11:43:50 -0700

Fugui,
  Sorry for missing this one.  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 9:22 AM
> To: 'Kireeti Kompella'
> Cc: [email-masked]'
> Subject: RE: Moving right along ...
> 
> 
> Kireeti,
> 
> For LMP, the following questions regrading message format
> has not been answered yet.
> 
> Regards,
> Fugui
> 
> > draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> > raised that this draft is close to ready for WG Last Call.  Please
> > review it, and let us know if you disagree.
> 
> A couple of questions regarding the messages in the new
> LMP draft:
> 
> (1) BeginVerifyAck message: 
> Since REMOTE_LINK_ID is optional in the BeginVerify
> message, how could LOCAL_LINK_ID be a required object
> in the BeginVerifyAck message? When you compose the 
> BeginVerifyAck message, you may not know the 
> LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID
> in the BeginVerify message.
Assuming you don't receive the REMOTE_LINK_ID in BeginVerify message:
If you have locally assigned the Interface to a TE Link, then you will know
the LOCAL_LINK_ID.  If the Interface has not been assigned a TE link, then
you put a value of zero in the LOCAL_LINK_ID (same rule as BeginVerify
message).

> 
> REMOTE_LINK_ID object should be within the 
> BeginVerifyAck message. Otherwise when receiving
> BeginVerifyAck, the node won't know for which 
> TE link the BeginVerifyAck is for.
The Message_ID_ACK object is sufficient to know which TE link the
BeginVerifyAck is for.

> 
> So maybe we should change the BeginVerifyAck message to:
> <BeginVerifyAck Message> ::= <Common Heade>
>                              [<LOCAL_LINK_ID>]
>                              <REMOTE_LINK_ID>
>                              <MESSAGE_ID_ACK>
>                              <BEGIN_VERIFY_ACK>
>                              <VERIFY_ID>
> Actually, I think LOCAL_LINK_ID could also be removed
> because it won't be useful for the receiver side 
> except providing a redundant check.
> 
> (2) LinkSummaryAck:
> Again, REMOTE_LINK_ID object should be there. 
> Otherwise, the remote node won't know for which
> TE link the LinkSummaryAck is for. Using 
> MESSAGE_ID_ACK to identify that is difficult
> since that will require the MESSAGE_ID to be
> unique over the node and we also need to use
> the MESSAGE_ID as an index to locate the TE link
> efficiently. (In the old LMP draft, I did see that 
> "When combined with the Local TE Link Id ..., the 
> MessageId field uniquely identifies a message.")
The MESSAGE_ID_ACK is unique within the scope of the LMP adjacency and is
sufficient to identify the LinkSummaryAck message.
 
> Changing the message to the following
> format will make life much easier:
> <LinkSummaryAck Message> ::= <Common Header>
>                              <MESSAGE_ID_ACK>
>                              <REMOTE_LINK_ID>
> 
> It would also be nice if we can add the REMOTE_LINK_ID
> object to LinkSummaryNack message.
> 
> Thanks,
> Fugui
> 

Delivery-date: Wed, 17 Oct 2001 10:35:39 -0700
From: "Don Fedyk" <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ...
Date: Wed, 17 Oct 2001 13:23:39 -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_01C15730.7646C240
Content-Type: text/plain;
	charset="iso-8859-1"

Hi

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

Don

> 
> 

------_=_NextPart_001_01C15730.7646C240
Content-Type: text/html;
	charset="iso-8859-1"

<!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.2654.89">
<TITLE>RE: Moving right along ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Zhi-Wei Lin [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, October 17, 2001 12:54 PM</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: Moving right along ...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Kireeti, all,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regarding the GMPLS signaling set of I-Ds...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- cr-ldp is in version 4, which means that the revisions done to </FONT>
<BR><FONT SIZE=2>&gt; rsvp-te05 has not been reflected there...how do we resolve this </FONT>
<BR><FONT SIZE=2>&gt; inconsistency?</FONT>
<BR><FONT SIZE=2>I send Lou the updated CR-LDP version yesterday.&nbsp; This brings it in </FONT>
<BR><FONT SIZE=2>sync with RSVP-TE version 5. </FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15730.7646C240--

Delivery-date: Wed, 17 Oct 2001 10:16:15 -0700
Date: Wed, 17 Oct 2001 19:13:51 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

This is a multi-part message in MIME format.
--------------F0A577EE669BA3C714A298D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Kireeti, all.

Concerning the doc draft-fontana-ccamp-gmpls-g709-00.txt
the status is the following:
- updates performed as discussed during last meeting and
  distributed to co-authors (as well as potentially interested
  people) since 2 weeks to get comments and feedback; 
- people having shown interest to proactively contribute
  have been included in the contributor list (if others are
  interested don't hesitate to contact us)
- waiting for the ITU meeting plenary results for commitment
  wrt to the resulting draft-fontana-ccamp-gmpls-g709-01.txt
  version (for specific issues which shouldn't delay the
  process initiated during the last IETF meeting) and then
  re-submission

Regards,
Dimitri.
  
Kireeti Kompella wrote:
> 
> Despite the energetic subject line, we the WG chairs have been
> lax in our duties.  So, here goes:
> 
> Lou has submitted the latest versions of the generalized
> signaling documents quite some time ago (thanks, Lou):
> 
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> 
> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> 
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> All of these should have addressed the issues raised in the earlier
> versions.  Please read the new versions, and send your comments to
> the list by Tuesday Oct 23.  At that point, when the final round
> of comments have been addressed, these docs will go to IESG Last
> Call.  If any one objects to sending these docs to IESG Last Call,
> raise your issues now.
> 
> I see that the GMPLS architecture document is a CCAMP WG doc, but
> the minutes say that we should look for consensus on the list.  So,
> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> will progress to WG Last Call.
> 
> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> list know what your thinking is on these.  (BTW, both these docs
> were to have some edits done.  If the authors could do that before
> the next IETF, we can try to make more progress then.)
> 
> The MIB overview doc was recently posted.  Please read and comment
> to the list.
> 
> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> was generally thought to be useful; it will be published as a
> CCAMP informational doc.  This begins a two week Last Call on
> the doc, ending Tuesday Oct 30.
> 
> There was no consensus on whether the GMPLS framework should be
> a CCAMP WG doc.  Please indicate your pleasure.
> 
> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.
> 
> The OLI requirements doc was broadly accepted.  Please let the
> list know if you think this doc should be a WG doc.
> 
> It's still open whether we (the IETF) should be working on
> LMP-WDM.  I urge the authors to keep on working on the doc, and
> keeping it in sync with LMP; however, we will postpone making it
> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> happen in Salt Lake City.
> 
> There was reasonable interest in the tunnel trace requirements
> doc.  Let's formalize this: do you think this should be made a
> CCAMP WG document?
> 
> Summary:
> 
> 1) Final comments and IESG Last Call readiness for:
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> 2) Should the following documents be CCAMP WG docs?
> draft-bonica-tunneltrace-02.txt
> draft-fontana-ccamp-gmpls-g709-00.txt
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> draft-many-ccamp-gmpls-framework-00.txt
> draft-many-oli-reqts-00.txt
> 
> 3) Comment on MIB overview.
> 
> 4) Two week Last Call comments on
> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> 
> 5) Last Call readiness of
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-ietf-ccamp-lmp-01.txt
> 
> Thanks,
> Kireeti.
--------------F0A577EE669BA3C714A298D8
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------F0A577EE669BA3C714A298D8--

Delivery-date: Wed, 17 Oct 2001 09:57:16 -0700
Date: Wed, 17 Oct 2001 12:53:41 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

Hi Kireeti, all,

Regarding the GMPLS signaling set of I-Ds...

-- cr-ldp is in version 4, which means that the revisions done to 
rsvp-te05 has not been reflected there...how do we resolve this 
inconsistency?

-- rsvp-te-05 and signaling-06 has incorporated the restart capability 
as proposed by Ping Pan. However, that work was never looked at 
carefully and some issues remain on how this covers all the different 
cases. Is it correct to simply include content of individual drafts into 
a WG draft that is in last call without adequate data on whether it 
handles all the different cases?

-- signaling-06 also includes several new items in there that doesn't 
seem to be added because of a identified need (do a diff to find the 
differences). Why were they added to the document (I'm not questioning 
them, just asking for clarifying explanation)?

-- in signaling-06, since we've decided that this set of I-Ds are to be 
consistent with the standards for the respective technologies, then 
"Digital Wrapper, G.709" should be changed to "ODUk, G.709" or something 
that is used in G.709 or G.872 to describe the types of the signals...

-- There are still some technical questions remaining on some content of 
the sonet-sdh-02 that are still been discussed in a private list (my 
understanding). Shouldn't these be resolved first before it goes for 
last call?

-- in sonet-sdh-extension-00, we would like to add two new flags into 
the list of flags for transparency (I have spoken to Eric already, and 
I'm waiting to have these added in the next version):
      flag 13: M0
      flag 14: M1

-- I believe g709-00 is currently undergoing some changes to align with 
standards positions and to reflect the work on OTN TDM that is been 
discussed in ITU study group 15 meeting this week and next week.

Zhi

Kireeti Kompella wrote:

> Despite the energetic subject line, we the WG chairs have been
> lax in our duties.  So, here goes:
> 
> Lou has submitted the latest versions of the generalized
> signaling documents quite some time ago (thanks, Lou):
> 
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> 
> Also, Eric has posted the SONET/SDH documents (merci, Eric):
> 
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> All of these should have addressed the issues raised in the earlier
> versions.  Please read the new versions, and send your comments to
> the list by Tuesday Oct 23.  At that point, when the final round
> of comments have been addressed, these docs will go to IESG Last
> Call.  If any one objects to sending these docs to IESG Last Call,
> raise your issues now.
> 
> I see that the GMPLS architecture document is a CCAMP WG doc, but
> the minutes say that we should look for consensus on the list.  So,
> if you think this doc *shouldn't* be a WG doc, let us know.  (If we
> arrived at a consensus, remind me :-))  If nothing is heard, the doc
> will progress to WG Last Call.
> 
> The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
> draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
> CCAMP WG docs; consensus at the meeting was Yes.  Please let the
> list know what your thinking is on these.  (BTW, both these docs
> were to have some edits done.  If the authors could do that before
> the next IETF, we can try to make more progress then.)
> 
> The MIB overview doc was recently posted.  Please read and comment
> to the list.
> 
> The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> was generally thought to be useful; it will be published as a
> CCAMP informational doc.  This begins a two week Last Call on
> the doc, ending Tuesday Oct 30.
> 
> There was no consensus on whether the GMPLS framework should be
> a CCAMP WG doc.  Please indicate your pleasure.
> 
> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.
> 
> The OLI requirements doc was broadly accepted.  Please let the
> list know if you think this doc should be a WG doc.
> 
> It's still open whether we (the IETF) should be working on
> LMP-WDM.  I urge the authors to keep on working on the doc, and
> keeping it in sync with LMP; however, we will postpone making it
> a CCAMP WG doc until the issue is resolved.  Hopefully that will
> happen in Salt Lake City.
> 
> There was reasonable interest in the tunnel trace requirements
> doc.  Let's formalize this: do you think this should be made a
> CCAMP WG document?
> 
> Summary:
> 
> 1) Final comments and IESG Last Call readiness for:
> draft-ietf-mpls-generalized-cr-ldp-04.txt
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> draft-ietf-mpls-generalized-signaling-06.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> 2) Should the following documents be CCAMP WG docs?
> draft-bonica-tunneltrace-02.txt
> draft-fontana-ccamp-gmpls-g709-00.txt
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
> draft-many-ccamp-gmpls-framework-00.txt
> draft-many-oli-reqts-00.txt
> 
> 3) Comment on MIB overview.
> 
> 4) Two week Last Call comments on
> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
> 
> 5) Last Call readiness of
> draft-ietf-ccamp-gmpls-architecture-00.txt
> draft-ietf-ccamp-lmp-01.txt
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Wed, 17 Oct 2001 09:25:10 -0700
From: Fugui Wang <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Moving right along ...
Date: Wed, 17 Oct 2001 12:22:23 -0400

Kireeti,

For LMP, the following questions regrading message format
has not been answered yet.

Regards,
Fugui

> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.

A couple of questions regarding the messages in the new
LMP draft:

(1) BeginVerifyAck message: 
Since REMOTE_LINK_ID is optional in the BeginVerify
message, how could LOCAL_LINK_ID be a required object
in the BeginVerifyAck message? When you compose the 
BeginVerifyAck message, you may not know the 
LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID
in the BeginVerify message.

REMOTE_LINK_ID object should be within the 
BeginVerifyAck message. Otherwise when receiving
BeginVerifyAck, the node won't know for which 
TE link the BeginVerifyAck is for.

So maybe we should change the BeginVerifyAck message to:
<BeginVerifyAck Message> ::= <Common Heade>
                             [<LOCAL_LINK_ID>]
                             <REMOTE_LINK_ID>
                             <MESSAGE_ID_ACK>
                             <BEGIN_VERIFY_ACK>
                             <VERIFY_ID>
Actually, I think LOCAL_LINK_ID could also be removed
because it won't be useful for the receiver side 
except providing a redundant check.

(2) LinkSummaryAck:
Again, REMOTE_LINK_ID object should be there. 
Otherwise, the remote node won't know for which
TE link the LinkSummaryAck is for. Using 
MESSAGE_ID_ACK to identify that is difficult
since that will require the MESSAGE_ID to be
unique over the node and we also need to use
the MESSAGE_ID as an index to locate the TE link
efficiently. (In the old LMP draft, I did see that 
"When combined with the Local TE Link Id ..., the 
MessageId field uniquely identifies a message.")
Changing the message to the following
format will make life much easier:
<LinkSummaryAck Message> ::= <Common Header>
                             <MESSAGE_ID_ACK>
                             <REMOTE_LINK_ID>

It would also be nice if we can add the REMOTE_LINK_ID
object to LinkSummaryNack message.

Thanks,
Fugui

Delivery-date: Wed, 17 Oct 2001 09:09:53 -0700
Date: Wed, 17 Oct 2001 09:05:31 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ...

Kireeti:

My opinion on some of your questions are inline.

Regards,

sudheer

Kireeti Kompella wrote:

>
> 2) Should the following documents be CCAMP WG docs?
> draft-bonica-tunneltrace-02.txt - Yes

>
> draft-fontana-ccamp-gmpls-g709-00.txt - Yes
> draft-ietf-ccamp-gmpls-architecture-00.txt - Yes
> draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt - No opinion
> draft-many-ccamp-gmpls-framework-00.txt - No opinion
> draft-many-oli-reqts-00.txt - Yes
>
> 3) Comment on MIB overview.
>
> 4) Two week Last Call comments on
> draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt - No opinion
>
> 5) Last Call readiness of
> draft-ietf-ccamp-gmpls-architecture-00.txt - Not ready yet
> draft-ietf-ccamp-lmp-01.txt - Yes
>

Envelope-to: [email-masked]
Delivery-date: Wed, 17 Oct 2001 02:26:16 -0700
Date: Wed, 17 Oct 2001 02:25:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Moving right along ...

Despite the energetic subject line, we the WG chairs have been
lax in our duties.  So, here goes:

Lou has submitted the latest versions of the generalized
signaling documents quite some time ago (thanks, Lou):

draft-ietf-mpls-generalized-cr-ldp-04.txt
draft-ietf-mpls-generalized-rsvp-te-05.txt
draft-ietf-mpls-generalized-signaling-06.txt

Also, Eric has posted the SONET/SDH documents (merci, Eric):

draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

All of these should have addressed the issues raised in the earlier
versions.  Please read the new versions, and send your comments to
the list by Tuesday Oct 23.  At that point, when the final round
of comments have been addressed, these docs will go to IESG Last
Call.  If any one objects to sending these docs to IESG Last Call,
raise your issues now.

I see that the GMPLS architecture document is a CCAMP WG doc, but
the minutes say that we should look for consensus on the list.  So,
if you think this doc *shouldn't* be a WG doc, let us know.  (If we
arrived at a consensus, remind me :-))  If nothing is heard, the doc
will progress to WG Last Call.

The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and
draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be
CCAMP WG docs; consensus at the meeting was Yes.  Please let the
list know what your thinking is on these.  (BTW, both these docs
were to have some edits done.  If the authors could do that before
the next IETF, we can try to make more progress then.)

The MIB overview doc was recently posted.  Please read and comment
to the list.

The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt
was generally thought to be useful; it will be published as a
CCAMP informational doc.  This begins a two week Last Call on
the doc, ending Tuesday Oct 30.

There was no consensus on whether the GMPLS framework should be
a CCAMP WG doc.  Please indicate your pleasure.

draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
raised that this draft is close to ready for WG Last Call.  Please
review it, and let us know if you disagree.

The OLI requirements doc was broadly accepted.  Please let the
list know if you think this doc should be a WG doc.

It's still open whether we (the IETF) should be working on
LMP-WDM.  I urge the authors to keep on working on the doc, and
keeping it in sync with LMP; however, we will postpone making it
a CCAMP WG doc until the issue is resolved.  Hopefully that will
happen in Salt Lake City.

There was reasonable interest in the tunnel trace requirements
doc.  Let's formalize this: do you think this should be made a
CCAMP WG document?

Summary:

1) Final comments and IESG Last Call readiness for:
draft-ietf-mpls-generalized-cr-ldp-04.txt
draft-ietf-mpls-generalized-rsvp-te-05.txt
draft-ietf-mpls-generalized-signaling-06.txt
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

2) Should the following documents be CCAMP WG docs?
draft-bonica-tunneltrace-02.txt
draft-fontana-ccamp-gmpls-g709-00.txt
draft-ietf-ccamp-gmpls-architecture-00.txt
draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
draft-many-ccamp-gmpls-framework-00.txt
draft-many-oli-reqts-00.txt

3) Comment on MIB overview.

4) Two week Last Call comments on
draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt

5) Last Call readiness of
draft-ietf-ccamp-gmpls-architecture-00.txt
draft-ietf-ccamp-lmp-01.txt

Thanks,
Kireeti.

Delivery-date: Tue, 16 Oct 2001 16:13:14 -0700
Date: Tue, 16 Oct 2001 16:09:49 -0700 (PDT)
From: Vik Anantha <[email-masked]>
Subject: re: soft state
To: [email-masked]

I would like to highlight a issue about GMPLS
protocols in general and hopefully the community will
give me some insights and/or set me straight.

OSPF-TE/IS-IS-TE, RSVP-TE etc (with GMPLS extensions)
are all soft-state protocols. They all depend on a
state that would degrade in the absence of a refresh
message. The advantages of soft state being
 a> Provides built-in fault recovery (implicit fault
recovery). 
 b> Allows for easier interoperabilty.

However, the periodicity of the refresh messages is
too small for most high bandwidth applications and so
explicit fault recovery is also being proposed in the
signalling protocols for restoration features.

In this context, would there be any big argument
against going towards a hard-state approach to ensure
database consistency. 

Let me qualify what I mean by this. First of all I
would hate to get into a TCP vs UDP debate because
thats not what I mean here. I also appreciate the
usefulness of soft state in something like the
neighbor discovery aspect of LMP and I would not like
to get into that either. 

What I do mean is, can we have a transaction mechanism
that can ensure that the RSVP and OSPF MIBs on all the
nodes in the network/domain are always consistent.
Operations like setting up new paths and changes to
the link state database would always be transactioned.
There are a number of distributed database
transactions documented in literature (like the
two-phase commit etc), and I would assume some good
implementations too. This can potentially reduce path
setup/restoration time.

I would like to hear some views about the pros and
cons of replacing or augmenting the soft state refresh
mechanism with a transaction mechansim. This would be
useful when using GMPLS with high bandwidth pipes like
DWDM/SONET etc.

Thanks

Vik

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Delivery-date: Tue, 16 Oct 2001 10:10:59 -0700
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>
Cc: [email-masked], Jonathan Lang <[email-masked]>
Subject: RE: LMP Question: TE link FSM
Date: Tue, 16 Oct 2001 09:48:24 -0700

George,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 6:45 AM
> To: Jonathan Lang
> Cc: [email-masked]
> Subject: RE: LMP Question: TE link FSM
> 
> 
> Hello Jonathan,
> 
> The new Init state seems useful and I have no difficulties with it.
> However, I still have a couple of problems with the TE FSM:
> 
> 1) It appears that the DOWN state has a functioning CC but no links.
> Transition #9 moves from DEGRADED, where there are links but no CC, to
> DOWN, where there is a CC but no links. This looks like 2 transitions to
> me, because 2 independent things happened. At least it's different from
> transition #9 from UP, which has CC and links, to DOWN, which has CC and
> no links.
The DOWN state does not assume there is/isn't a functioning CC.  Transition
#9 moves from a state where there are links (but no CC) to DOWN where there
are no links (and in this case no CC).

> 
> 2) It seems to me that if there is an INIT state, the CC could go down
> there too.
I'm not sure I understand this comment.  The CC has its own FSM that it goes
through to come back up.

> 
> My goal here is to have a state machine which is useful (i.e.
> explanatory and representative) and has feasible transitions between
> states. I don't care about the labels of the states.
> 
> So here's another proposal which I believe keeps everything 
> in your Oct
> 15th version and addresses the two points above:
> 
> --------------------
> Off:	    No control channel, no data links
> Down:	    There are no data links allocated to the TE link.
> Init:	    Data links have been allocated to the TE link, but the
> 
> 	    configuration has not yet been synchronized with the LMP
> neighbor.
> Up:	    This is the normal operational state of the TE link.  At
> least 
> 	    one primary CC is required to be operational between the
> nodes 
> 	    sharing the TE link.
> Degraded: In this state, all primary CCs are down, but the TE 
> link still
> 	    includes some allocated data links.
> Inactive: No control channel, some data links locally allocated to TE.
> 
> 1 : evDCUp:    One or more data channels have been added to 
> the TE Link
> 2 : evSumAck:  LinkSummary message received and positively 
> acknowledged.
> 3 : evSumNack: LinkSummary message received and negatively 
> acknowledged.
> 4 : evRcvAck:  LinkSummaryAck message received acknowledging 
> the TE Link
> 	       Configuration.
> 5 : evRcvNack: LinkSummaryNack message received.
> 6 : evSumRet:  Retransmission timer has expired and 
> LinkSummary message
> is
> 	       resent.
> 7 : evCCUp:    First active control channel goes up.
> 8 : evCCDown:  Last active control channel goes down.
> 9 : evDCDown:  Last data channel of TE Link has been removed.
> 
>                                +--------+
>                                |        |
>                  +------------>|  Off   |
>                  |             |        |
>                  |             +--------+
>                  |                |  ^ 
>                  |               7|  |8
>                  |                v  |
>                  |             +--------+
>                  |             |        |
>                  |             |  Down  |<---------+
>                 9|             |        |          |
>                  |             +--------+          |
>                  |                |  ^             |
>                  |               1|  |9            |
>                  |                v  |             |
>               +--------+   7   +--------+          |
>               |        |------>|        |<-+       |
>               | Inact  |       |  Init  |  |3,5,6  |9
>               |        |<------|        |--+       |
>               +--------+   8   +--------+          |
>                                     |              |
>                                  2,4|              |
>                                     v              |
>               +--------+   7   +--------+          |
>               |        |------>|        |----------+
>               |  Deg   |       |   Up   |
>               |        |<------|        |
>               +--------+   8   +--------+
>                                   |  ^
>                                   |  |
>                                   +--+
>                                 2,3,4,5,6
> 
> 
> 
> Regards,
> George R. Young
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 
> >-----Original Message-----
> >From: Jonathan Lang [mailto:[email-masked]]
> >Sent: Monday, October 15, 2001 2:17 PM
> >To: George Young
> >Cc: Jonathan Lang
> >Subject: RE: LMP Question: TE link FSM
> >
> >
> >George,
> >  I agree that we need an intermediate state, but I don't 
> >think it should be
> >the Empty state.  We have modified the document as follows:
> >
> >Updated description
> >--------------------
> >Down:	There are no data links allocated to the TE link.
> >Init: Data links have been allocated to the TE link, but the 
> >configuration
> >has not
> >      yet been synchronized with the LMP neighbor.
> >Up: This is the normal operational state of the TE link.  At 
> least one
> >primary
> >    CC is required to be operational between the nodes sharing 
> >the TE link.
> >Degraded: In this state, all primary CCs are down, but the TE 
> >link still
> >includes
> >          some allocated data links.
> >
> >1 : evDCUp:    One or more data channels have been added to 
> the TE Link
> >2 : evSumAck:  LinkSummary message received and positively 
> >acknowledged.
> >3 : evSumNack: LinkSummary message received and negatively 
> >acknowledged.
> >4 : evRcvAck:  LinkSummaryAck message received acknowledging 
> >the TE Link
> >Configuration.
> >5 : evRcvNack: LinkSummaryNack message received.
> >6 : evSumRet:  Retransmission timer has expired and 
> >LinkSummary message is
> >resent.
> >7 : evCCUp:    First active control channel goes up.
> >8 : evCCDown:  Last active control channel goes down.
> >9 : evDCDown:  Last data channel of TE Link has been removed.
> >        
> >                               +--------+
> >                               |        |
> >                 +------------>|  Down  |<---------+
> >                 |             |        |          |
> >                 |             +--------+          |
> >                 |                |  ^             |
> >                 |               1|  |9            |
> >                 |                v  |             |
> >                 |             +--------+          |
> >                 |             |        |<-+       |
> >                 |             |  Init  |  |3,5,6  |9
> >                 |             |        |--+       |
> >                9|             +--------+          |
> >                 |                  |              |
> >                 |               2,4|              |
> >                 |                  v              |
> >              +--------+   7   +--------+          |
> >              |        |------>|        |----------+
> >              |  Deg   |       |   Up   |
> >              |        |<------|        |
> >              +--------+   8   +--------+
> >                                  |  ^
> >                                  |  |
> >                                  +--+
> >                                2,3,4,5,6
> >
> >
> >> -----Original Message-----
> >> From: George Young [mailto:[email-masked]]
> >> Sent: Tuesday, October 09, 2001 12:24 PM
> >> To: [email-masked]
> >> Subject: LMP Question: TE link FSM
> >> 
> >> 
> >> I have some problems with the TE FSM in 
> draft-ietf-ccamp-lmp-01.txt.
> >> 
> >> There are 4 combinations of CC UP/Down and None/Some Data Channels
> >> Allocated, but only 3 states in the FSM. Also, the TE Link 
> >> Events should
> >> be related to whether the links are allocated to the TE, 
> not whether
> >> they are currently carrying data. Transition 4 is shown 
> but the note
> >> indicates it should not happen.
> >> 
> >> Here is a proposal for a modified TE Link FSM.
> >> 
> >> 11.2.1. TE Link States 
> >>     
> >>    An LMP TE link can be in one of the states described 
> below. Every 
> >>    state corresponds to a certain condition of the TE link and is 
> >>    usually associated with a specific type of LMP message that is 
> >>    periodically transmitted to the far end via the 
> >associated control 
> >>    channel or in-band via the data links. 
> >>     
> >>    Down:       There are no control channels available and no data 
> >>                links are allocated to the TE link. 
> >>     
> >>    Empty:      At least one control channel is available 
> and no data 
> >>                links are allocated to the TE link. 
> >>     
> >>    Up:         This is the normal operational state of the TE 
> >> link.  At 
> >> 	         least one primary CC and one or more data-bearing links
> >> is
> >> 	         required to be operational between the nodes sharing
> >> the TE
> >> 	         link. 
> >>     
> >>    Degraded:   In this state, all primary CCs are down, but 
> >> the TE link 
> >>                still includes some allocated data links. 
> >> 
> >> 11.2.2. TE Link Events 
> >>     
> >>    Operation of the LMP TE link is described in terms of FSM 
> >> states and 
> >>    events. TE Link events are generated by the packet processing 
> >>    routines and by the FSMs of the associated primary control 
> >>    channel(s) and the data links. Every event has its number and a 
> >>    symbolic name. Description of possible control channel 
> events is 
> >>    given below. 
> >>     
> >>    1 : evCCUp:         First active CC goes Up. 
> >>    2 : evDCUp:         One or more data channels are UP and 
> >>                        LinkSummaryAck message has been received 
> >>                        acknowledging the TE link configuration. 
> >>    3 : evDCDown:       Last data channel of TE link has been 
> >> removed.  
> >>    4 : evCCDown:       Last active CC goes Down. 
> >>    5 : evReconfig:     Successful TE reconfiguration, 
> LinkSummaryAck
> >> message
> >>    6 : evReconfigFail: Unsuccessful TE reconfiguration attempt,
> >> LinkSummaryNack 
> >>                        message
> >> 
> >> 11.2.3. TE Link FSM Description 
> >>  
> >>    Figure 4 illustrates operation of the LMP TE Link FSM in 
> >a form of 
> >>    a state transition diagram. 
> >>     
> >>             
> >>                                   +--------+ 
> >>                                   |        |
> >>                                   |  Down  |
> >>                                   |        |
> >>                                   +--------+ 
> >>                                      |   ^   
> >>                                     1|  4|   
> >>                                      |   |   
> >>                                      v   |   
> >>                                   +--------+ 
> >>                                   |        |<---+
> >>                                   | Empty  |    | 6
> >>                                   |        |----+
> >>                                   +--------+ 
> >>                                      |   ^   
> >>                                     2|  3|   
> >>                                      |   |   
> >>                                      v   |   
> >>                  +--------+  1    +--------+ 
> >>                  |        |------>|        |<---+
> >>                  |  Deg   |       |   Up   |    | 6
> >>                  |        |<------|        |----+
> >>                  +--------+    4  +--------+ 
> >>                                      |   ^ 
> >>                                      |   | 
> >>                                      +---+ 
> >>                                        5 
> >>     
> >>                          Figure 4: LMP TE Link FSM 
> >>     
> >>    In the above FSM, the sub-states that may be 
> implemented when the 
> >>    link verification procedure is used have been omitted.
> >> 
> >> Regards,
> >> George R. Young
> >> edgeflow Inc.
> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> phone: +1 613-270-9279 Ext 287
> >> fax: +1 613-270-9268
> >> 
> >
> 

Delivery-date: Tue, 16 Oct 2001 06:49:03 -0700
content-class: urn:content-classes:message
Subject: RE: LMP Question: TE link FSM
Date:  Tue, 16 Oct 2001 09:45:10 -0400
From: "George Young" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>

Hello Jonathan,

The new Init state seems useful and I have no difficulties with it.
However, I still have a couple of problems with the TE FSM:

1) It appears that the DOWN state has a functioning CC but no links.
Transition #9 moves from DEGRADED, where there are links but no CC, to
DOWN, where there is a CC but no links. This looks like 2 transitions to
me, because 2 independent things happened. At least it's different from
transition #9 from UP, which has CC and links, to DOWN, which has CC and
no links.

2) It seems to me that if there is an INIT state, the CC could go down
there too.

My goal here is to have a state machine which is useful (i.e.
explanatory and representative) and has feasible transitions between
states. I don't care about the labels of the states.

So here's another proposal which I believe keeps everything in your Oct
15th version and addresses the two points above:

--------------------
Off:	    No control channel, no data links
Down:	    There are no data links allocated to the TE link.
Init:	    Data links have been allocated to the TE link, but the

	    configuration has not yet been synchronized with the LMP
neighbor.
Up:	    This is the normal operational state of the TE link.  At
least=20
	    one primary CC is required to be operational between the
nodes=20
	    sharing the TE link.
Degraded: In this state, all primary CCs are down, but the TE link still
	    includes some allocated data links.
Inactive: No control channel, some data links locally allocated to TE.

1 : evDCUp:    One or more data channels have been added to the TE Link
2 : evSumAck:  LinkSummary message received and positively acknowledged.
3 : evSumNack: LinkSummary message received and negatively acknowledged.
4 : evRcvAck:  LinkSummaryAck message received acknowledging the TE Link
	       Configuration.
5 : evRcvNack: LinkSummaryNack message received.
6 : evSumRet:  Retransmission timer has expired and LinkSummary message
is
	       resent.
7 : evCCUp:    First active control channel goes up.
8 : evCCDown:  Last active control channel goes down.
9 : evDCDown:  Last data channel of TE Link has been removed.

                               +--------+
                               |        |
                 +------------>|  Off   |
                 |             |        |
                 |             +--------+
                 |                |  ^=20
                 |               7|  |8
                 |                v  |
                 |             +--------+
                 |             |        |
                 |             |  Down  |<---------+
                9|             |        |          |
                 |             +--------+          |
                 |                |  ^             |
                 |               1|  |9            |
                 |                v  |             |
              +--------+   7   +--------+          |
              |        |------>|        |<-+       |
              | Inact  |       |  Init  |  |3,5,6  |9
              |        |<------|        |--+       |
              +--------+   8   +--------+          |
                                    |              |
                                 2,4|              |
                                    v              |
              +--------+   7   +--------+          |
              |        |------>|        |----------+
              |  Deg   |       |   Up   |
              |        |<------|        |
              +--------+   8   +--------+
                                  |  ^
                                  |  |
                                  +--+
                                2,3,4,5,6

Regards,
George R. Young
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

>-----Original Message-----
>From: Jonathan Lang [mailto:[email-masked]]
>Sent: Monday, October 15, 2001 2:17 PM
>To: George Young
>Cc: Jonathan Lang
>Subject: RE: LMP Question: TE link FSM
>
>
>George,
>  I agree that we need an intermediate state, but I don't=20
>think it should be
>the Empty state.  We have modified the document as follows:
>
>Updated description
>--------------------
>Down:	There are no data links allocated to the TE link.
>Init: Data links have been allocated to the TE link, but the=20
>configuration
>has not
>      yet been synchronized with the LMP neighbor.
>Up: This is the normal operational state of the TE link.  At least one
>primary
>    CC is required to be operational between the nodes sharing=20
>the TE link.
>Degraded: In this state, all primary CCs are down, but the TE=20
>link still
>includes
>          some allocated data links.
>
>1 : evDCUp:    One or more data channels have been added to the TE Link
>2 : evSumAck:  LinkSummary message received and positively=20
>acknowledged.
>3 : evSumNack: LinkSummary message received and negatively=20
>acknowledged.
>4 : evRcvAck:  LinkSummaryAck message received acknowledging=20
>the TE Link
>Configuration.
>5 : evRcvNack: LinkSummaryNack message received.
>6 : evSumRet:  Retransmission timer has expired and=20
>LinkSummary message is
>resent.
>7 : evCCUp:    First active control channel goes up.
>8 : evCCDown:  Last active control channel goes down.
>9 : evDCDown:  Last data channel of TE Link has been removed.
>       =20
>                               +--------+
>                               |        |
>                 +------------>|  Down  |<---------+
>                 |             |        |          |
>                 |             +--------+          |
>                 |                |  ^             |
>                 |               1|  |9            |
>                 |                v  |             |
>                 |             +--------+          |
>                 |             |        |<-+       |
>                 |             |  Init  |  |3,5,6  |9
>                 |             |        |--+       |
>                9|             +--------+          |
>                 |                  |              |
>                 |               2,4|              |
>                 |                  v              |
>              +--------+   7   +--------+          |
>              |        |------>|        |----------+
>              |  Deg   |       |   Up   |
>              |        |<------|        |
>              +--------+   8   +--------+
>                                  |  ^
>                                  |  |
>                                  +--+
>                                2,3,4,5,6
>
>
>> -----Original Message-----
>> From: George Young [mailto:[email-masked]]
>> Sent: Tuesday, October 09, 2001 12:24 PM
>> To: [email-masked]
>> Subject: LMP Question: TE link FSM
>>=20
>>=20
>> I have some problems with the TE FSM in draft-ietf-ccamp-lmp-01.txt.
>>=20
>> There are 4 combinations of CC UP/Down and None/Some Data Channels
>> Allocated, but only 3 states in the FSM. Also, the TE Link=20
>> Events should
>> be related to whether the links are allocated to the TE, not whether
>> they are currently carrying data. Transition 4 is shown but the note
>> indicates it should not happen.
>>=20
>> Here is a proposal for a modified TE Link FSM.
>>=20
>> 11.2.1. TE Link States=20
>>    =20
>>    An LMP TE link can be in one of the states described below. Every=20
>>    state corresponds to a certain condition of the TE link and is=20
>>    usually associated with a specific type of LMP message that is=20
>>    periodically transmitted to the far end via the=20
>associated control=20
>>    channel or in-band via the data links.=20
>>    =20
>>    Down:       There are no control channels available and no data=20
>>                links are allocated to the TE link.=20
>>    =20
>>    Empty:      At least one control channel is available and no data=20
>>                links are allocated to the TE link.=20
>>    =20
>>    Up:         This is the normal operational state of the TE=20
>> link.  At=20
>> 	         least one primary CC and one or more data-bearing links
>> is
>> 	         required to be operational between the nodes sharing
>> the TE
>> 	         link.=20
>>    =20
>>    Degraded:   In this state, all primary CCs are down, but=20
>> the TE link=20
>>                still includes some allocated data links.=20
>>=20
>> 11.2.2. TE Link Events=20
>>    =20
>>    Operation of the LMP TE link is described in terms of FSM=20
>> states and=20
>>    events. TE Link events are generated by the packet processing=20
>>    routines and by the FSMs of the associated primary control=20
>>    channel(s) and the data links. Every event has its number and a=20
>>    symbolic name. Description of possible control channel events is=20
>>    given below.=20
>>    =20
>>    1 : evCCUp:         First active CC goes Up.=20
>>    2 : evDCUp:         One or more data channels are UP and=20
>>                        LinkSummaryAck message has been received=20
>>                        acknowledging the TE link configuration.=20
>>    3 : evDCDown:       Last data channel of TE link has been=20
>> removed. =20
>>    4 : evCCDown:       Last active CC goes Down.=20
>>    5 : evReconfig:     Successful TE reconfiguration, LinkSummaryAck
>> message
>>    6 : evReconfigFail: Unsuccessful TE reconfiguration attempt,
>> LinkSummaryNack=20
>>                        message
>>=20
>> 11.2.3. TE Link FSM Description=20
>> =20
>>    Figure 4 illustrates operation of the LMP TE Link FSM in=20
>a form of=20
>>    a state transition diagram.=20
>>    =20
>>            =20
>>                                   +--------+=20
>>                                   |        |
>>                                   |  Down  |
>>                                   |        |
>>                                   +--------+=20
>>                                      |   ^  =20
>>                                     1|  4|  =20
>>                                      |   |  =20
>>                                      v   |  =20
>>                                   +--------+=20
>>                                   |        |<---+
>>                                   | Empty  |    | 6
>>                                   |        |----+
>>                                   +--------+=20
>>                                      |   ^  =20
>>                                     2|  3|  =20
>>                                      |   |  =20
>>                                      v   |  =20
>>                  +--------+  1    +--------+=20
>>                  |        |------>|        |<---+
>>                  |  Deg   |       |   Up   |    | 6
>>                  |        |<------|        |----+
>>                  +--------+    4  +--------+=20
>>                                      |   ^=20
>>                                      |   |=20
>>                                      +---+=20
>>                                        5=20
>>    =20
>>                          Figure 4: LMP TE Link FSM=20
>>    =20
>>    In the above FSM, the sub-states that may be implemented when the=20
>>    link verification procedure is used have been omitted.
>>=20
>> Regards,
>> George R. Young
>> edgeflow Inc.
>> 329 March Rd., Kanata, ON, Canada, K2K 2E1
>> phone: +1 613-270-9279 Ext 287
>> fax: +1 613-270-9268
>>=20
>

Delivery-date: Tue, 16 Oct 2001 01:17:57 -0700
From: "Roberto Mameli (ERI)" <[email-masked]>
To: "Lista CCAMP (E-mail)" <[email-masked]>, "Lista Mpls (E-mail)" <[email-masked]>, "Lista TE-WG (E-mail)" <[email-masked]>
Cc: "Paola Iovanna (ERI)" <[email-masked]>, "Roberto Mameli (ERI)" <[email-masked]>, "Giovanna Piantanida (ERI)" <[email-masked]>, "Stefano Salsano (E-mail)" <[email-masked]>
Subject: Submission of draft-iovanna-rsvp-mpls-flowspec-00.txt
Date: Tue, 16 Oct 2001 10:11:51 +0200

Hello all,

a new Internet-Draft is available from the on-line Internet-Drafts directories (http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt).

	Title		: Definition of the MPLS FlowSpec for RSVP-TE
	Author(s)	: P. Iovanna, R. Mameli, G. Piantanida, S. Salsano
	Filename	: draft-iovanna-rsvp-mpls-flowspec-00.txt
	Pages		: 12
	Date		: 15-Oct-01

The abstract is reported below. Of course comments and suggestions are welcome.

Regards
The authors

Abstract	
The support of QoS Differentiation in MPLS is based on the definition of 
two types of LSP, respectively E-LSP and L-LSP (see [11]). Both E-LSP 
and L-LSP can be established with bandwidth reservation. In this case 
bandwidth requirements for the LSP must be signaled at LSP establishment 
time, in order to perform admission control in the LSRs in the path. If 
RSVP-TE is used as setup protocol, it has to support the signaling of 
bandwidth requirements for the LSPs. In this document we extend the 
RSVP-TE capability by defining a new type of Sender_Tspec (and 
FlowSpec), explicitly designed to allow signaling of bandwidth 
requirements for E-LSP and L-LSP set up. This new type, called MPLS 
Sender_Tspec (MPLS FlowSpec), can include bandwidth requirements for 
different classes inside the LSP.

Delivery-date: Mon, 15 Oct 2001 10:29:27 -0700
From: Dimitrios Pendarakis <[email-masked]>
To: "'Bradford, Richard'" <[email-masked]>, [email-masked]
Cc: CCAMP <[email-masked]>
Subject: RE: LMP Procedure in UNI 1.0 - Doubts
Date: Mon, 15 Oct 2001 13:25:34 -0400

Hi all,

The mapping between IPCC and CCID should indeed be one-to-one.
IPCC is a term for the data channel that is used to exchange 
IP control messages between a UNI-C and UNI-N. CCID is the 
identifier for the IPCC. So, its basically a matter of definition.
Of course, as pointed out in the document, the CCID may be 
different in each direction.

Thanks,
Dimitris

> -----Original Message-----
> From: Bradford, Richard [mailto:[email-masked]]
> Sent: Monday, October 15, 2001 12:19 PM
> To: [email-masked]
> Cc: CCAMP
> Subject: Re: LMP Procedure in UNI 1.0 - Doubts
> 
> 
> At 01:54 AM 10/15/2001 -0800, Dipnarayan Guha wrote:
> >Hello Ramesh,
> >
> >  Rather you may say that a
> >corresponding IPCC may have one or more CCID's.
> 
> I do not believe this last statement is correct. It seems 
> that an IPCC 
> should (must?) have one and only one node-wide unique CCID. Having a 
> many-to-one mapping leads to problems. For example, there is 
> a one-to-one 
> correspondence between MessageID fields and CCIDs (See 
> section 2, paragraph 5).
> 
> >For in-fibre signalling, Interface ID has to be assigned by 
> the initiating 
> >node. This can be done
> >and then the CCID will again change (provided in-fibre signalling is
> >present again), but the original CC that is already 
> established will NOT
> >change.
> I believe there is a flaw in this interpretation. If the CCID 
> is reassigned 
> then the old CCID would no longer be valid. In the case 
> described, the old 
> Interface ID for the data link has been changed so an in-band 
> CCID using 
> the old value would be invalid, since it would no longer 
> match the TE-link ID.
> 
> Sincerely,
>          Rich
> 
> 
> 
> 
> --
> Rich Bradford          Email: [email-masked]
> Cisco Systems, Inc.    Tel: 978-244-3079
> 300 Apollo Drive       Fax: 978-244-3079
> Chelmsford, Mass 01824
> 
> 
> 
> 
> 

Delivery-date: Mon, 15 Oct 2001 09:23:50 -0700
Date: Mon, 15 Oct 2001 12:18:54 -0400
To: [email-masked]
From: "Bradford, Richard" <[email-masked]>
Subject: Re: LMP Procedure in UNI 1.0 - Doubts
Cc: "CCAMP" <[email-masked]>

At 01:54 AM 10/15/2001 -0800, Dipnarayan Guha wrote:
>Hello Ramesh,
>
>  Rather you may say that a
>corresponding IPCC may have one or more CCID's.

I do not believe this last statement is correct. It seems that an IPCC 
should (must?) have one and only one node-wide unique CCID. Having a 
many-to-one mapping leads to problems. For example, there is a one-to-one 
correspondence between MessageID fields and CCIDs (See section 2, paragraph 5).

>For in-fibre signalling, Interface ID has to be assigned by the initiating 
>node. This can be done
>and then the CCID will again change (provided in-fibre signalling is
>present again), but the original CC that is already established will NOT
>change.
I believe there is a flaw in this interpretation. If the CCID is reassigned 
then the old CCID would no longer be valid. In the case described, the old 
Interface ID for the data link has been changed so an in-band CCID using 
the old value would be invalid, since it would no longer match the TE-link ID.

Sincerely,
         Rich

--
Rich Bradford          Email: [email-masked]
Cisco Systems, Inc.    Tel: 978-244-3079
300 Apollo Drive       Fax: 978-244-3079
Chelmsford, Mass 01824

Delivery-date: Mon, 15 Oct 2001 07:32:49 -0700
From: Bala Rajagopalan <[email-masked]>
To: 'S Ramesh' <[email-masked]>, CCAMP <[email-masked]>
Cc: [email-masked]
Subject: RE: LMP Procedure in UNI 1.0 - Doubts
Date: Mon, 15 Oct 2001 10:23:58 -0400

Ramesh:

At least the 1st question of your message belongs to the OIF
lists and not to the IETF lists. If you want to follow up,
please post to [email-masked] <mailto:[email-masked]>  or
send private mail.
 
In any case, let me just briefly answer the questions:
 
(1) Neighbor discovery runs only between network elements
and not proxies. If there is a proxy, information must be configured.
 
(2) Node ID refers to the single unique Id of the node (an IP address)
     Interface ID is an ID for a data link interface. E.g., could be a
locally
     unique index. 
     CCID is an ID for the control channel. One CC could be used to
     control interactions over multiple link interfaces. In the in-fiber
case,
     a one-to-one association between CC and data link is assumed, hence
    the relation CCID = interface ID.
 
regards,
 
Bala

-----Original Message-----
From: S Ramesh [mailto:[email-masked]]
Sent: Sunday, October 14, 2001 3:40 PM
To: CCAMP; GMPLS
Cc: [email-masked]
Subject: LMP Procedure in UNI 1.0 - Doubts

Hi,
 
I have some doubts in UNI 1.0 Whitepaper published by OIF.
 
1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is
based on the LMP protocol mechanism. It is defined some three identifiers
for LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST
be equal to the Interface ID. if this is the case then under direct service
invocation model which supports In-fiber method, there exists a proxy UNI-N
on the TNE side. So here the CCID cannot be the the same as the interface id
because interface id is the port address for data transfer and the CCID is
the IP control channel which can be a seperate point to point link between
the UNI-C and the proxy UNI-N. Then how comes the criteria
 
CCID == Interface ID ( MUST in in-fiber case) can be satisfied.
 
2. Also there is some confusion exists regarding the three IDs as i
mentioned above. When Config messages are sent under IP encapsulation they
use the destination address as the Node ID of the destination. So what is
the interface ID. Can anybody kindly explain these three IDs with a specific
scenario.
 
Thanks,
Ramesh

Delivery-date: Sun, 14 Oct 2001 01:51:30 -0700
From: "S Ramesh" <[email-masked]>
To: "CCAMP" <[email-masked]>, "GMPLS" <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: LMP Procedure in UNI 1.0 - Doubts
Date: Sun, 14 Oct 2001 14:16:17 -0700
Organization: HCL Technologies Ltd.

This is a multi-part message in MIME format.

------=_NextPart_000_01E0_01C154BA.C9EF54C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry in  the second question it is not config messages.. it is the =
Hello messages.

Ramesh

----- Original Message -----=20
From: S Ramesh=20
To: CCAMP ; GMPLS=20
Cc: [email-masked]=20
Sent: Sunday, October 14, 2001 12:39 PM
Subject: LMP Procedure in UNI 1.0 - Doubts

Hi,

I have some doubts in UNI 1.0 Whitepaper published by OIF.

1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is =
based on the LMP protocol mechanism. It is defined some three =
identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber =
case the CCID MUST be equal to the Interface ID. if this is the case =
then under direct service invocation model which supports In-fiber =
method, there exists a proxy UNI-N on the TNE side. So here the CCID =
cannot be the the same as the interface id because interface id is the =
port address for data transfer and the CCID is the IP control channel =
which can be a seperate point to point link between the UNI-C and the =
proxy UNI-N. Then how comes the criteria

CCID =3D=3D Interface ID ( MUST in in-fiber case) can be satisfied.

2. Also there is some confusion exists regarding the three IDs as i =
mentioned above. When Config messages are sent under IP encapsulation =
they use the destination address as the Node ID of the destination. So =
what is the interface ID. Can anybody kindly explain these three IDs =
with a specific scenario.

Thanks,
Ramesh

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

<!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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Sorry in  the second question it is not config messages.. it is the =
Hello=20
messages.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:[email-masked]" =
title=[email-masked]>S=20
Ramesh</A> </DIV>
<DIV><B>To:</B> <A href=3D"mailto:[email-masked]"=20
title=[email-masked]>CCAMP</A> ; <A =
href=3D"mailto:[email-masked]"=20
title=[email-masked]>GMPLS</A> </DIV>
<DIV><B>Cc:</B> <A href=3D"mailto:[email-masked]" =
title=[email-masked]>[email-masked]</A>=20
</DIV>
<DIV><B>Sent:</B> Sunday, October 14, 2001 12:39 PM</DIV>
<DIV><B>Subject:</B> LMP Procedure in UNI 1.0 - Doubts</DIV></DIV>
<DIV><BR></DIV>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have some doubts in UNI 1.0 Whitepaper published by OIF.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. IN section 8.2 it is given the UNI neighbour discovery&nbsp; =
mechanism=20
is based on the LMP protocol mechanism. It is defined some three =
identifiers for=20
LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST =
be=20
equal to the Interface ID. if this is the case then under direct service =

invocation model which supports In-fiber method, there exists a proxy =
UNI-N on=20
the TNE side. So here the CCID cannot be the the same as the interface =
id=20
because interface id&nbsp;is the port address for data transfer and the=20
CCID&nbsp;is the IP control channel which can be a seperate point to =
point link=20
between the UNI-C and the proxy UNI-N. Then how comes the criteria</DIV>
<DIV>&nbsp;</DIV>
<DIV>CCID =3D=3D Interface ID ( <STRONG>MUST in in-fiber case</STRONG>) =
can be=20
satisfied.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. Also there is some confusion exists regarding the three IDs as i =

mentioned above. When Config messages are sent under IP encapsulation =
they use=20
the destination address as the Node ID of the destination. So what is =
the=20
interface ID. Can anybody kindly explain these three IDs with a specific =

scenario.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_01E0_01C154BA.C9EF54C0--

Delivery-date: Sun, 14 Oct 2001 00:19:11 -0700
From: "S Ramesh" <[email-masked]>
To: "CCAMP" <[email-masked]>, "GMPLS" <[email-masked]>
Cc: <[email-masked]>
Subject: LMP Procedure in UNI 1.0 - Doubts
Date: Sun, 14 Oct 2001 12:39:53 -0700
Organization: HCL Technologies Ltd.

This is a multi-part message in MIME format.

------=_NextPart_000_0162_01C154AD.52DD1320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I have some doubts in UNI 1.0 Whitepaper published by OIF.

1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is =
based on the LMP protocol mechanism. It is defined some three =
identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber =
case the CCID MUST be equal to the Interface ID. if this is the case =
then under direct service invocation model which supports In-fiber =
method, there exists a proxy UNI-N on the TNE side. So here the CCID =
cannot be the the same as the interface id because interface id is the =
port address for data transfer and the CCID is the  IP control channel =
which can be a seperate point to point link between the UNI-C and the =
proxy UNI-N. Then how comes the criteria

CCID =3D=3D Interface ID ( MUST in in-fiber case) can be satisfied.

2. Also there is some confusion exists regarding the three IDs as i =
mentioned above. When Config messages are sent under IP encapsulation =
they use the destination address as the Node ID of the destination. So =
what is the interface ID. Can anybody kindly explain these three IDs =
with a specific scenario.

Thanks,
Ramesh

------=_NextPart_000_0162_01C154AD.52DD1320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have some doubts in UNI 1.0 Whitepaper published by OIF.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. IN section 8.2 it is given the UNI neighbour discovery&nbsp; =
mechanism=20
is based on the LMP protocol mechanism. It is defined some three =
identifiers for=20
LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST =
be=20
equal to the Interface ID. if this is the case then under direct service =

invocation model which supports In-fiber method, there exists a proxy =
UNI-N on=20
the TNE side. So here the CCID cannot be the the same as the interface =
id=20
because interface id&nbsp;is the port address for data transfer and the=20
CCID&nbsp;is the  IP control channel which can be a seperate point to =
point link=20
between the UNI-C and the proxy UNI-N. Then how comes the criteria</DIV>
<DIV>&nbsp;</DIV>
<DIV>CCID =3D=3D Interface ID ( <STRONG>MUST in in-fiber case</STRONG>) =
can be=20
satisfied.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. Also there is some confusion exists regarding the three IDs as i =

mentioned above. When Config messages are sent under IP encapsulation =
they use=20
the destination address as the Node ID of the destination. So what is =
the=20
interface ID. Can anybody kindly explain these three IDs with a specific =

scenario.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0162_01C154AD.52DD1320--

Delivery-date: Thu, 11 Oct 2001 20:20:42 -0700
Date: Thu, 11 Oct 2001 23:18:10 -0400 (EDT)
From: Jim Boyle <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-tewg-restore-hierarchy-00.txt => CCAMP Attention

This message is to announce that the document:

        draft-ietf-tewg-restore-hierarchy-00.txt

which was originated out of a service provider focussed design team, and
then discussed within the TEWG and adopted as a WG item is ready for
consideration by CCAMP.  IPO members were also solicited for feedback on
this document via the TEWG mailing list.

The requirements for restoration and hieararchy that are expressly needed
at this time are summarized in the introduction of the document.

   A. Survivability Requirements

   @ need to define a small set of interoperable survivability
     approaches in packet and non-packet networks
   @ suggested survivability mechanisms include
     -  1:1 path protection with pre-established backup capacity (non-
         shared)
     -  1:1 path protection with pre-planned backup capacity (shared)
     -  local restoration with repairs in proximity to the network
         fault
     -  path restoration through source-based rerouting
   @ timing bounds for service restoration to support voice call cutoff
     (140 msec to 2 sec), protocol timer requirements in premium data
     services, and mission critical applications
   @ use of restoration priority for service differentiation

   B. Hierarchy Requirements

   B.1. Horizontally Oriented Hierarchy (Intra-Domain)

   @ ability to set up many LSPs in a service provider network with
     hierarchical IGP, for the support layer 2 and layer 3 VPN services
   @ requirements for multi-area traffic engineering need to be
     developed to provide guidance for any necessary protocol
     extensions

   B.2. Vertically Oriented Hierarchy

   The following functionality for survivability is common on most
   routing equipment today.

   @ near-term need is some loose form of coordination and
     communication based on the use of nested hold-off timers, instead
     of direct exchange of signaling and routing between vertical
     layers
   @ means for an upper layer to immediately begin recovery actions in
     the event that a lower layer is not configured to perform recovery

   C. Survivability Requirements in Horizontal Hierarchy

   @ protection of end-to-end connection is based on a concatenated set
     of connections, each protected within their area
   @ mechanisms for connection routing may include (1) a network
     element that participates on both sides of a boundary (e.g., OSPF
     ABR) - note that this is a common point of failure; (2) route
     server
   @ need for inter-area signaling of survivability information (1) to
     enable a "least common denominator" survivability mechanism at the
     boundary; (2) to convey the success or failure of the service
     restoration action;  e.g., if a part of a "connection" is down on
     one side of a boundary, there is no need for the other side to
     recover from failures

Regards,

Jim Boyle, Ed Kern, & TEWG

Delivery-date: Thu, 11 Oct 2001 15:54:39 -0700
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Questions for draft-ietf-ccamp-lmp-01.txt
Date: Thu, 11 Oct 2001 18:49:47 -0400

A couple of questions regarding the messages in the new
LMP draft:

(1) BeginVerifyAck message: 
Since REMOTE_LINK_ID is optional in the BeginVerify
message, how could LOCAL_LINK_ID be a required object
in the BeginVerifyAck message? When you compose the 
BeginVerifyAck message, you may not know the 
LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID
in the BeginVerify message.

REMOTE_LINK_ID object should be within the 
BeginVerifyAck message. Otherwise when receiving
BeginVerifyAck, the node won't know for which 
TE link the BeginVerifyAck is for.

So maybe we should change the BeginVerifyAck message to:
<BeginVerifyAck Message> ::= <Common Heade>
                             [<LOCAL_LINK_ID>]
                             <REMOTE_LINK_ID>
                             <MESSAGE_ID_ACK>
                             <BEGIN_VERIFY_ACK>
                             <VERIFY_ID>
Actually, I think LOCAL_LINK_ID could also be removed
because it won't be useful for the receiver side 
except providing a redundant check.

(2) LinkSummaryAck:
Again, REMOTE_LINK_ID object should be there. 
Otherwise, the remote node won't know for which
TE link the LinkSummaryAck is for. Using 
MESSAGE_ID_ACK to identify that is difficult
since that will require the MESSAGE_ID to be
unique over the node and we also need to use
the MESSAGE_ID as an index to locate the TE link
efficiently. (In the old LMP draft, I did see that 
"When combined with the Local TE Link Id ..., the 
MessageId field uniquely identifies a message.")
Changing the message to the following
format will make life much easier:
<LinkSummaryAck Message> ::= <Common Header>
                             <MESSAGE_ID_ACK>
                             <REMOTE_LINK_ID>

It would also be nice if we can add the REMOTE_LINK_ID
object to LinkSummaryNack message.

Thanks,
Fugui

Delivery-date: Tue, 09 Oct 2001 13:19:55 -0700
From: "Sameh M. Elsharkawy" <[email-masked]>
To: [email-masked]
Subject: LMP Addressing
Date: Tue, 9 Oct 2001 16:17:37 -0400 

I have a couple of questions regarding the Addressing section (section 9) in
the latest LMP draft (draft-ietf-ccamp-lmp-01.txt).

1. The draft states that:

     "The destination address of the IP packet MUST be the 
   address learned in the Configuration procedure (i.e., the Source IP 
   address found in the IP header of the received Config message)"

I think that LOCAL_NODE_ID field in the Config message should be used for
this purpose instead of the IP header information.

2. Why is RAW IP used for LMP and not UDP for example ?

Thanks,

Sameh M. Elsharkawy
Senior Member of Technical Staff
FirstWave Intelligent Optical Networks
6301 Ivy Lane, Suite 700, Greenbelt, MD 20770
(301) 345-2137 x1034

Delivery-date: Tue, 09 Oct 2001 12:30:12 -0700
content-class: urn:content-classes:message
Subject: LMP Question: TE link FSM
Date:  Tue, 9 Oct 2001 15:23:39 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>

I have some problems with the TE FSM in draft-ietf-ccamp-lmp-01.txt.

There are 4 combinations of CC UP/Down and None/Some Data Channels
Allocated, but only 3 states in the FSM. Also, the TE Link Events should
be related to whether the links are allocated to the TE, not whether
they are currently carrying data. Transition 4 is shown but the note
indicates it should not happen.

Here is a proposal for a modified TE Link FSM.

11.2.1. TE Link States=20
   =20
   An LMP TE link can be in one of the states described below. Every=20
   state corresponds to a certain condition of the TE link and is=20
   usually associated with a specific type of LMP message that is=20
   periodically transmitted to the far end via the associated control=20
   channel or in-band via the data links.=20
   =20
   Down:       There are no control channels available and no data=20
               links are allocated to the TE link.=20
   =20
   Empty:      At least one control channel is available and no data=20
               links are allocated to the TE link.=20
   =20
   Up:         This is the normal operational state of the TE link.  At=20
	         least one primary CC and one or more data-bearing links
is
	         required to be operational between the nodes sharing
the TE
	         link.=20
   =20
   Degraded:   In this state, all primary CCs are down, but the TE link=20
               still includes some allocated data links.=20

11.2.2. TE Link Events=20
   =20
   Operation of the LMP TE link is described in terms of FSM states and=20
   events. TE Link events are generated by the packet processing=20
   routines and by the FSMs of the associated primary control=20
   channel(s) and the data links. Every event has its number and a=20
   symbolic name. Description of possible control channel events is=20
   given below.=20
   =20
   1 : evCCUp:         First active CC goes Up.=20
   2 : evDCUp:         One or more data channels are UP and=20
                       LinkSummaryAck message has been received=20
                       acknowledging the TE link configuration.=20
   3 : evDCDown:       Last data channel of TE link has been removed. =20
   4 : evCCDown:       Last active CC goes Down.=20
   5 : evReconfig:     Successful TE reconfiguration, LinkSummaryAck
message
   6 : evReconfigFail: Unsuccessful TE reconfiguration attempt,
LinkSummaryNack=20
                       message

11.2.3. TE Link FSM Description=20
=20
   Figure 4 illustrates operation of the LMP TE Link FSM in a form of=20
   a state transition diagram.=20
   =20
           =20
                                  +--------+=20
                                  |        |
                                  |  Down  |
                                  |        |
                                  +--------+=20
                                     |   ^  =20
                                    1|  4|  =20
                                     |   |  =20
                                     v   |  =20
                                  +--------+=20
                                  |        |<---+
                                  | Empty  |    | 6
                                  |        |----+
                                  +--------+=20
                                     |   ^  =20
                                    2|  3|  =20
                                     |   |  =20
                                     v   |  =20
                 +--------+  1    +--------+=20
                 |        |------>|        |<---+
                 |  Deg   |       |   Up   |    | 6
                 |        |<------|        |----+
                 +--------+    4  +--------+=20
                                     |   ^=20
                                     |   |=20
                                     +---+=20
                                       5=20
   =20
                         Figure 4: LMP TE Link FSM=20
   =20
   In the above FSM, the sub-states that may be implemented when the=20
   link verification procedure is used have been omitted.

Regards,
George R. Young
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

Delivery-date: Tue, 09 Oct 2001 11:28:51 -0700
content-class: urn:content-classes:message
Subject: LMP Question: data link FSMs
Date:  Tue, 9 Oct 2001 14:22:49 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>

I have a couple of problems with the Data Link FSMs in
draft-ietf-ccamp-lmp-01.txt. Event 14:evdcDown appears to be an
administrative action, as opposed to the failure event
13:evLocalizeFail. That being the case, event 14:evdcDown should only
transit from Up/Free to Down.

If this understanding is correct, suggested FSMs are included below. In
the passive case, transition 13 would need something like
ChannelFailNack to trigger it.

   Figure 5 illustrates operation of the LMP active data link FSM in a=20
   form of FSM state transition diagram.=20
   =20
                             +------+=20
              +------------->|      | =20
              |   +--------->| Down |<---------+
              |   |     +----|      |<-----+   |
              |   |     |    +------+      |   |
              |   |     |5b   3|  ^        |   |
              |   |     |      |  |2,7     |   |
              |   |     |      v  |        |   |
              |   |     |    +------+      |   |
              |   |     |    |      |<-+   |   |
              |   |     |    | Test |  |11 |   |
              |   |     |    |      |--+   |   |
              |   |     |    +------+      |   |
              |   |     |     5a| 3^       |   |
              |   |     |       |  |       |   |
              |   |     |       v  |       |   |
              |   |2,12 |   +---------+    |   |
              |   |     +-->|         |14  |   |
              |   |         | Up/Free |----+   |
              |   +---------|         |        |
              |             +---------+        |
              |                9| ^            |
              |                 | |            |
              |10               v |10          |
            +-----+  2      +---------+        |
            |     |<--------|         |     13 |
            | Deg |         |Up/Alloc |--------+
            |     |-------->|         |=20
            +-----+  1      +---------+=20
   =20
                    Figure 5: Active LMP Data Link FSM=20
   =20

   Figure 6 illustrates operation of the LMP passive data link FSM in a=20
   form of FSM state transition diagram.=20
   =20
                             +------+=20
              +------------->|      |=20
              |  +---------->| Down |<---------+
              |  |     +-----|      |<----+    |
              |  |     |     +------+     |    |
              |  |     |5b    4|  ^       |    |
              |  |     |       |  |2,8    |    |
              |  |     |       v  |       |    |
              |  |     |    +----------+  |    |
              |  |     |    | PasvTest |  |    |
              |  |     |    +----------+  |    |
              |  |     |       6|  4^     |    |
              |  |     |        |   |     |14  |
              |  |     |        v   |     |    |
              |  |2,12 |    +---------+   |    |
              |  |     +--->| Up/Free |   |    |
              |  |          |         |---+    |
              |  +----------|         |        |
              |             +---------+        |
              |                 9| ^           |
              |                  | |           |
              |10                v |10         |
            +-----+         +---------+        |
            |     |  2      |         |     13 |
            | Deg |<--------|Up/Alloc |--------+
            |     |-------->|         |=20
            +-----+  1      +---------+=20
   =20
                    Figure 6: Passive LMP Data Link FSM=20

Regards,
George R. Young
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

Delivery-date: Tue, 09 Oct 2001 11:05:27 -0700
content-class: urn:content-classes:message
Subject: LMP Question: fault management messages
Date:  Tue, 9 Oct 2001 13:56:31 -0400
From: "George Young" <[email-masked]>
To: <[email-masked]>

I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus
message and its friends.

In Section 6.2. Fault Localization Procedure, LMP states "Once the
failure has been localized, the signaling protocols can be used to
initiate span or path protection/restoration procedures". This is
workable and signalling can reroute around the link or the path,
releasing resources as appropriate. However, with the departure of the
ChannelFailNack, the node at the receive end of the faulty link does not
find out about the fault from either the signalling protocol or LMP. As
bidirectional paths are allocated, there is a chance that the failed
link will be allocated to a subsequent call through this node.

Furthermore, assuming a signalling protocol has established paths, and
indicated their active or backup status with the Administrative Status
object in GMPLS, there does not appear to be any need in LMP for the
Active/Deactive indications in the CHANNEL_STATUS object. This
information has already been conveyed by the signalling protocol during
path establishment. =20

If my understanding is correct, ChannelFailNack functionality is needed
and the Active and Deactive values of the CHANNEL_STATUS object are not.

Regards,
George R. Young
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268

Delivery-date: Thu, 04 Oct 2001 08:56:43 -0700
Date: Thu, 04 Oct 2001 11:52:58 -0400
To: "Balasubramania N. Pillai" <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: Re: LMP Messages
Cc: [email-masked]

Comments inline.
At 06:06 PM 10/2/2001 -0400, Balasubramania N. Pillai wrote:
>Hi
>
>I have a basic doubt regarding LMP Messages based on the latest LMP draft.
>
>Section 3, paragraph 5 of the draft says
>
> > There are four LMP messages that are used to manage individual
> > control channels.  They are the Config, ConfigAck, ConfigNack, and
> > Hello messages. These messages MUST be transmitted on the channel to
> > which they refer.  All other LMP messages may be transmitted over
> > any of the active control channels between a pair of LMP adjacent
> > nodes.
>
>Why is it that these messages MUST be transmitted on the channel to which
>they refer. I can understand why LMP Hello messages need to be sent over the
>control channel, which it refers to. But is it necessary to force the other
>messages.
>
>
>
>          ----------                      ----------
>         |          |         C1         |          |
>         |          |--------------------|          |
>         | Switch 1 |                    | Switch 1 |
>         |          |--------------------|          |
>         |          |         C2         |          |
>          ----------                      ----------
>
>
>Based on the above picture assume that there are 2 control channels between
>Switches 1 & 2. LMP messages are sent over IP. If I have to force messages
>over individual channels then I need to get down to Layer 2. If I don't have
>to force it, I can let IP routing pick any one of the available channels to
>carry the message.
Here's my take. You COULD do what you want by defining a single control 
channel, where that IPCC is routed (Note following argument applies to a 
single IPCC where underlying links are load shared/bundled).
What you would lose is an indication that either C1 or C2 was no longer 
passing data. Let's say routing prefers C1 and somewhere along C2 there's a 
disruption. At this point the switches have no backups but have no 
indication that there are no backups.  If LMP is configured with multiple 
IPCCs and IFF hello's are going over those IPCCs, then you will know if 
there's a problem with one of the IPCCs.
Another reason is that the CONFIG for inband IPCC can be used in lieu of 
LinkVerify for determining  the mapping of links between the switches, but 
only if the CONFIG message goes over the correct link.
-- rich

--
Rich Bradford          Email: [email-masked]
Cisco Systems, Inc.    Tel: 978-244-3079
300 Apollo Drive       Fax: 978-244-3079
Chelmsford, Mass 01824

Delivery-date: Thu, 04 Oct 2001 02:16:55 -0700
To: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>, oif-architecture-group <[email-masked]>
Cc: q11/15 <[email-masked]>
Date: Thu, 04 Oct 2001 11:15:16 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>, oif-architecture-group <[email-masked]>
Original-CC: q11/15 <[email-masked]>
Subject: OLI/LMP-WDM/NTIP => next step in ITU-T SG15

This is a multi-part message in MIME format.
--------------25E5C527A558CF0435049F1B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

I am pleased to announce the availability of 4 contributions for the upcoming
SG15 meeting addressing the rationale/architecture, applications, physical and
performance aspects of the interface between an OLS and an PXC. 

These contributions resulted from interaction with key players(*) in the IETF
ccamp WG concerning the OLI, LMP-WDM and NTIP activities. 

	(*) Osama Aboul-Magd, Curtis Brownmiller, John Drake, Andre Fredette
	    and Jonathan Lang

You will find the contributions (in word97 and pdf formats) in 
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q11/0110

This interface is referred to by many names so far: LMP-WDM, OLI, NTIP, OTM-LF. 
In the contributions, it is referred to as Virtual Backplane Interface (VBI),
but a better name is urgently needed... 

This interface is a true transport plane interface and once standardized by
ITU-T SG15 it should be usable for the purposes needed by ITU-T/T1, IETF ccamp
WG and OIF. 

Please review the contributions and provide comment either during the upcoming
SG15 meeting in Geneva (Oct. 15-26) or via correspondence. These contributions
are intended to provide a framework for the new interface specification. The
specification work itself is obviously the next step and a united ITU-T/T1/IETF
CCAMP/OIF effort to progress this specification would be an excellent way
forward.

Regards,

Maarten
--------------25E5C527A558CF0435049F1B
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

--------------25E5C527A558CF0435049F1B--

Delivery-date: Wed, 03 Oct 2001 17:49:25 -0700
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>
Subject: Separation of IP control and data channels
Date: Wed, 3 Oct 2001 17:44:06 -0700

Folks,

There appears to be an issue about how to separate IP control channels
from IP data channels within OSPF-TE for GMPLS, when one focuses on the
peer model.

In the peer model, a router/switch will get OSPF-TE opaque LSAs from the
the entire network, and needs a way to distinguish between data-capable
IP links in the network from IP control channels. This is to prevent
the calculation of routes for IP data packets that traverse any IP control
channels.

While draft-ietf-ccamp-routing-00.txt mentions a couple of ways to
try to avoid this, they may not be enough, especially if one does not
have the flexibility to seggregate control and data channel address
spaces, and/or if one is focusing only on the IGP case.

A simple way to achieve this goal is to extend
the Switching Cap field in the Interface Switching Capability 
Descriptor to separate an "IP Data packet switch capable" link/interface
from an "IP control packet swich capable" link.

We would like to propose that this be added to the relevant drafts.

Thanks,

-Vishal

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Delivery-date: Wed, 03 Oct 2001 13:27:09 -0700
From: "Fong Liaw" <[email-masked]>
To: "Yangguang Xu" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: update GMPLS signaling documents
Date: Wed, 3 Oct 2001 13:20:53 -0700

Yanguang

I am jumping in here, Lou can certainly add or
clarify further. see below.

> This one was sent to MPLS WG.
> 
> ///////////////////////////////////////////////////////////
> I have some questions/concerns on the restart mechanism as
> specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
> have listed them below.
> 
> If a node that is terminating hierarchical LSPs restarts,
> there is an ordering issue during resynchronization, since
> the LSPs would depend on other FA-LSPs the interface IDs for
> which would have been generated dynamically. So the
> mechanism as described will not work, unless this
> information is preserved across restarts - in which case we
> might as well preserve other information as well, and avoid
> resynchronization.

Since transit node of the FA-LSP does not see the RSVP
messages that use the FA, we only need to consider 
the ingress and egress node. If the egress node restarts, 
the worst case is that its upstream node sends an ERO 
consisting a unrecognized interface address. Since the 
Path message will carry RECOVERY_LABEL (replacing 
SUGGESTED_LABEL), the egress node knows that it might 
not have complete information yet, and can hold on to 
the Path message until the FA-LSP is established.  
All the information is there, so implementation 
can be completely within the egress node. It does work, 
just not specified enough.

Ingress node will have to know the dependency, so not
a problem there.

> 
> Also, let us consider a node that can preserve state across
> restarts, and hence does not need its state to be synced by
> its peer.  How will it advertise this in the RESTART_CAP
> object?
> 

We still need to resynchronize the state since the other
side might have connections that are in progress. The 
reason for resynchronization is to make sure both side
have done the same to the in-progress connections, not
just to synchronize the established states.

The value of the RESTART_CAP will set to non-zero values.

> If a node supports PSC as well as TDM or LSC interfaces, it
> might want to advertise different set of parameters in the
> RESTART_CAP object for data LSPs as opposed to SONET/WDM
> LSPs which form bearer channels in transport networks.
> Currently this is not possible.

Can you give us explicit examples as to why and what do 
you gain by giving different values for PSC, TDM ?

> 
> According to 9.5.1. (procedures for restarting LSR): "When
> sending the corresponding outgoing Path message the node
> SHOULD include a SUGGESTED_LABEL object with a label value
> ^^^^^^
> matching the outgoing label from the now restored forwarding
> entry."
> 
> This has a conflict with 9.5.2.  Consider the case where
> adjacent nodes B and C restart, and B has another adjacent
> node A, and C has another adjacent node D.  B and C will get
> resynced by A and D, and during this process, they will
> resync. each other. While resyncing each other, they act as
> neighbors of a restarting LSR, and hence according to 9.5.2,
> MUST include the SUGGESTED_LABEL.
> 
> Also according to 9.5.2: "During the recovery period, new
> Path state being advertised to the restarted neighbor SHOULD
> not include the SUGGESTED_LABEL object in the corresponding
> outgoing Path message.  This will prevent the restarting
> node from erroneously reusing a saved forwarding entry."
> 
> I guess this would mean that if suggested labels are used
> during new LSP setup (as they are likely to be while
> provisioning lightpaths - to reduce latency), then new LSP
> setup will not be allowed during resyncing?
> 

The use of RECOVERY_LABEL address all the above questions.

> In section 9.3: "When a new Hello message is received from
> the neighbor, the LSR must determine if the fault was
> limited to the control channel or was a nodal fault.  This
> determination is based on the Src_Instance received from the
> neighbor.  If the value is different than the value that was
> received from the neighbor prior to the fault, then the
> neighbor should be treated as if it has restarted.
> Otherwise, the the fault was limited control channel."
> 
> If two adjacent nodes restart, how can each of them
> determine that the other also just restarted?  This would
> need that the src_instance received from the neighbor is
> preserved across restarts - was that the intent?
> 

The use of same src_instance is just to help speed up
the resynchronization using Srefresh message. If the
instance number is different, the resynchronization
uses Path message. Both procedure will recover to 
the same state.

> 
> Another one
> 
> ///////////////////////////////////////////////////////
> I think I've found a problem with the nodal fault recovery mechanism
> in draft-ietf-mpls-generalized-rsvp-te-04.txt, section 9.5.
> 
> If the node that fails is the ingress node (i.e., an LER), then the LSP
> won't recover since there is no upstream neighbor from which this
> restarting LER will receive a PATH message.  Therefore, the LER
> won't send a PATH message to its downstream neighbor, and the
> LSP recovery fails.
> 
> In other words, recovery only seems to work if an LSR or an Egress
> LER experiences nodal failure.
> 
> Perhaps this could be fixed by having neighbors of the restarting
> node send a RESV for any Resv state held?
> 
> 

This has been discussed in the initial restart draft
and was decided that if an ingress node wants to preserve
the LSP, it needs to remember enough information in the
configuaration file/storage. I believe any developer will
be able to figure out what to save in the configuration
store to make this happen if the vendor decides to offer
this as a feature. Not sure there is much to be specified
if we take this approach.  

If people want to allow configuration-file-less procedure,
would they care to give explicit application examples ?

Regards, 
-Fong

> 
> 
> 
> 
> Lou Berger wrote:
> > 
> > FYI -
> > 
> > Updated versions of the signaling and RSVP-TE documents have been
> > submitted. The CR-LDP version is forthcoming.  The updates 
> address comments
> > received during the August meeting and comment period.
> > 
> > Here's a summary of changes:
> > 
> > draft-ietf-mpls-generalized-signaling-06.txt
> > Changes from previous version:
> > o Removed redundant encoding type
> > o Revised Admin Status Usage (per comments and also removed 
> potential race
> > condition) o Clarified text related to interface bundling (To 
> be consistent
> > with updated bundling draft.)
> > o Minor editorial changes and clarifications
> > o Revised G-PID (per comments on list)
> > 
> > draft-ietf-mpls-generalized-rsvp-te-05.txt
> > Changes from previous version:
> > o Revised Admin Status Usage (per comments and also removed 
> potential race
> > condition)
> > o Clarified text related to interface bundling (To be consistent with
> > updated bundling draft.)
> > o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel
> > Separation by allowing identification of errored interface.)
> > o Added U bit to Label RRO subobject (Per comment, to match 
> defined ERO.)
> > o Clarified usage of Restart_Cap o Replaced use of 
> Suggested_Label during
> > recovery with new Recovery_Label (Per last WG session)
> > o Added IANA Considerations
> > o Minor editorial changes and clarifications
> > 
> > For those who don't want to wait, the drafts are available from:
> > http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt
> > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt
> > 
> > Lou

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Delivery-date: Wed, 03 Oct 2001 07:01:58 -0700
Date: Wed, 03 Oct 2001 09:57:56 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Lou Berger <[email-masked]>
CC: [email-masked]
Subject: Re: update GMPLS signaling documents

Lou,

There were two emails (see below) raising some good questions about the re-start
procedure for RSVP-TE. I haven't seen any open discussion on these two emails,
nor changes in the new drafts. Are those issues solved? Would you please update
us?

Thanks,

Yangguang

This one was sent to MPLS WG.

///////////////////////////////////////////////////////////
I have some questions/concerns on the restart mechanism as
specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
have listed them below.

If a node that is terminating hierarchical LSPs restarts,
there is an ordering issue during resynchronization, since
the LSPs would depend on other FA-LSPs the interface IDs for
which would have been generated dynamically. So the
mechanism as described will not work, unless this
information is preserved across restarts - in which case we
might as well preserve other information as well, and avoid
resynchronization.

Also, let us consider a node that can preserve state across
restarts, and hence does not need its state to be synced by
its peer.  How will it advertise this in the RESTART_CAP
object?

If a node supports PSC as well as TDM or LSC interfaces, it
might want to advertise different set of parameters in the
RESTART_CAP object for data LSPs as opposed to SONET/WDM
LSPs which form bearer channels in transport networks.
Currently this is not possible.

According to 9.5.1. (procedures for restarting LSR): "When
sending the corresponding outgoing Path message the node
SHOULD include a SUGGESTED_LABEL object with a label value
^^^^^^
matching the outgoing label from the now restored forwarding
entry."

This has a conflict with 9.5.2.  Consider the case where
adjacent nodes B and C restart, and B has another adjacent
node A, and C has another adjacent node D.  B and C will get
resynced by A and D, and during this process, they will
resync. each other. While resyncing each other, they act as
neighbors of a restarting LSR, and hence according to 9.5.2,
MUST include the SUGGESTED_LABEL.

Also according to 9.5.2: "During the recovery period, new
Path state being advertised to the restarted neighbor SHOULD
not include the SUGGESTED_LABEL object in the corresponding
outgoing Path message.  This will prevent the restarting
node from erroneously reusing a saved forwarding entry."

I guess this would mean that if suggested labels are used
during new LSP setup (as they are likely to be while
provisioning lightpaths - to reduce latency), then new LSP
setup will not be allowed during resyncing?

In section 9.3: "When a new Hello message is received from
the neighbor, the LSR must determine if the fault was
limited to the control channel or was a nodal fault.  This
determination is based on the Src_Instance received from the
neighbor.  If the value is different than the value that was
received from the neighbor prior to the fault, then the
neighbor should be treated as if it has restarted.
Otherwise, the the fault was limited control channel."

If two adjacent nodes restart, how can each of them
determine that the other also just restarted?  This would
need that the src_instance received from the neighbor is
preserved across restarts - was that the intent?

Another one

///////////////////////////////////////////////////////
I think I've found a problem with the nodal fault recovery mechanism
in draft-ietf-mpls-generalized-rsvp-te-04.txt, section 9.5.

If the node that fails is the ingress node (i.e., an LER), then the LSP
won't recover since there is no upstream neighbor from which this
restarting LER will receive a PATH message.  Therefore, the LER
won't send a PATH message to its downstream neighbor, and the
LSP recovery fails.

In other words, recovery only seems to work if an LSR or an Egress
LER experiences nodal failure.

Perhaps this could be fixed by having neighbors of the restarting
node send a RESV for any Resv state held?

Lou Berger wrote:
> 
> FYI -
> 
> Updated versions of the signaling and RSVP-TE documents have been
> submitted. The CR-LDP version is forthcoming.  The updates address comments
> received during the August meeting and comment period.
> 
> Here's a summary of changes:
> 
> draft-ietf-mpls-generalized-signaling-06.txt
> Changes from previous version:
> o Removed redundant encoding type
> o Revised Admin Status Usage (per comments and also removed potential race
> condition) o Clarified text related to interface bundling (To be consistent
> with updated bundling draft.)
> o Minor editorial changes and clarifications
> o Revised G-PID (per comments on list)
> 
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> Changes from previous version:
> o Revised Admin Status Usage (per comments and also removed potential race
> condition)
> o Clarified text related to interface bundling (To be consistent with
> updated bundling draft.)
> o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel
> Separation by allowing identification of errored interface.)
> o Added U bit to Label RRO subobject (Per comment, to match defined ERO.)
> o Clarified usage of Restart_Cap o Replaced use of Suggested_Label during
> recovery with new Recovery_Label (Per last WG session)
> o Added IANA Considerations
> o Minor editorial changes and clarifications
> 
> For those who don't want to wait, the drafts are available from:
> http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt
> http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt
> 
> Lou

Delivery-date: Tue, 02 Oct 2001 15:05:45 -0700
From: "Balasubramania N. Pillai" <[email-masked]>
To: [email-masked]
Subject: LMP Messages
Date: Tue, 2 Oct 2001 18:06:13 -0400 

Hi

I have a basic doubt regarding LMP Messages based on the latest LMP draft.

Section 3, paragraph 5 of the draft says

> There are four LMP messages that are used to manage individual 
> control channels.  They are the Config, ConfigAck, ConfigNack, and 
> Hello messages. These messages MUST be transmitted on the channel to 
> which they refer.  All other LMP messages may be transmitted over 
> any of the active control channels between a pair of LMP adjacent 
> nodes. 

Why is it that these messages MUST be transmitted on the channel to which
they refer. I can understand why LMP Hello messages need to be sent over the
control channel, which it refers to. But is it necessary to force the other
messages.

         ----------                      ----------
        |          |         C1         |          |
        |          |--------------------|          |
        | Switch 1 |                    | Switch 1 |
        |          |--------------------|          |
        |          |         C2         |          |
         ----------                      ----------

Based on the above picture assume that there are 2 control channels between
Switches 1 & 2. LMP messages are sent over IP. If I have to force messages
over individual channels then I need to get down to Layer 2. If I don't have
to force it, I can let IP routing pick any one of the available channels to
carry the message. 

Thanks
Balu

Delivery-date: Tue, 02 Oct 2001 08:34:09 -0700
Date: Tue, 02 Oct 2001 17:16:26 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG-NA
To: "Saha, Sayandeb" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt query

This is a multi-part message in MIME format.
--------------2FD3A4E6CD933087CBB1F979
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Just notice that 

     Note 2: when requesting a transparent STM-N/STS-N signal 
     limited to a single contiguously concatenated VC-4-Nc/STS-Nc-
     SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and 
     NCC set to 1.

The reference you have made applies to non-transparent signals.

Regards,
Dimitri.

"Saha, Sayandeb" wrote:
> 
> Shouldn't the following examples in draft
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> 3. An STS-48c signal with LOH DCC and E2 transparency is formed by the
> application of RCC with flag 1, NCC with value 1, NVC with value 0, MT with
> value 1 and T with flag 5 and 10 to an STS-48 Elementary Signal.
> 
> be
> 
> An STS-48c signal with LOH DCC and E2 transparency is formed by the
> application of RCC with flag 1, NCC with value 16, NVC with value 0, MT with
> value 1 and T with flag 5 and 10 to an STS-3c SPE elementary signal,
> according to  the following ...
> 
> "when requesting a SONET STS-Nc SPE with N=3*X, the elementary signal to use
> must always be an STS-3c SPE signal type and the value of NCC must always be
> equal to X. This allows also facilitating the interworking between SONET and
> SDH. In particular, it means that the contiguous concatenation of three
> STS-1 SPEs cannot not be requested because according to this specification,
> this type of signal must be coded using the STS-3c SPE signal type. "
> 
> in the draft-ietf-ccamp-gmpls-sonet-sdh-02.txt .
> There's a similar problem with example 4 too.
> -Sayan
--------------2FD3A4E6CD933087CBB1F979
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------2FD3A4E6CD933087CBB1F979--

Delivery-date: Tue, 02 Oct 2001 07:46:39 -0700
From: "Saha, Sayandeb" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt query
Date: Tue, 2 Oct 2001 10:44:55 -0400 

Shouldn't the following examples in draft
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

3. An STS-48c signal with LOH DCC and E2 transparency is formed by the
application of RCC with flag 1, NCC with value 1, NVC with value 0, MT with
value 1 and T with flag 5 and 10 to an STS-48 Elementary Signal.

be

An STS-48c signal with LOH DCC and E2 transparency is formed by the
application of RCC with flag 1, NCC with value 16, NVC with value 0, MT with
value 1 and T with flag 5 and 10 to an STS-3c SPE elementary signal,
according to  the following ...

"when requesting a SONET STS-Nc SPE with N=3*X, the elementary signal to use
must always be an STS-3c SPE signal type and the value of NCC must always be
equal to X. This allows also facilitating the interworking between SONET and
SDH. In particular, it means that the contiguous concatenation of three
STS-1 SPEs cannot not be requested because according to this specification,
this type of signal must be coded using the STS-3c SPE signal type. "

in the draft-ietf-ccamp-gmpls-sonet-sdh-02.txt .
There's a similar problem with example 4 too.
-Sayan

Delivery-date: Tue, 02 Oct 2001 04:04:47 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
Date: Tue, 02 Oct 2001 07:01:55 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS Extensions for SONET and SDH Control
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
	Pages		: 20
	Date		: 01-Oct-01
	
This document is a companion to the Generalized MPLS signaling 
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines 
the SONET/SDH technology specific information needed when using 
GMPLS signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 02 Oct 2001 04:04:41 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
Date: Tue, 02 Oct 2001 07:02:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS Extensions to Control Non-Standard SONET and SDH
                          Features
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
	Pages		: 11
	Date		: 01-Oct-01
	
This document is a companion to the GMPLS signaling extensions to 
control SONET and SDH document [GMPLS-SONET-SDH] that defines the 
SONET/SDH technology specific information needed when using GMPLS 
signaling. 
This informational document defines GMPLS signaling extensions to 
control three optional non-standard (i.e. proprietary) SONET and 
SDH features: arbitrary concatenation, per byte transparency and 
the virtual concatenation of contiguously concatenated signals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 02 Oct 2001 04:04:34 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-01.txt
Date: Tue, 02 Oct 2001 07:02:06 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Link Management Protocol (LMP)
	Author(s)	: J. Lang et al.
	Filename	: draft-ietf-ccamp-lmp-01.txt
	Pages		: 62
	Date		: 01-Oct-01
	
Future networks will consist of photonic switches, optical 
crossconnects, and routers that may be configured with control 
channels and data links.  Furthermore, multiple data links may be 
combined to form a single traffic engineering (TE) link for routing 
purposes. This draft specifies a link management protocol (LMP) that 
runs between neighboring nodes and is used to manage TE links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lmp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 01 Oct 2001 12:59:24 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bi-directional LSPs [Contention Resolution]
Date: Mon, 01 Oct 2001 12:55:54 -0700

Hi All,
        I have a basic doubt regarding contention resolution. The draft
explains the example with upstream label and suggested label. Suggested
label is optional. If a node is not able to allocate the suggested
label then it may override the suggestged label. The actual contention
arises when it is the last label. Am I right ?

Another case, the contention will also occur when say request for
two bi-directional LSPs are initiated in opposite directions and both the 
requests include same upstream label. In addition to this, the label set 
contains one label,  same as upstream label (i.e. sender wants to have 
samelabel in both the directions).

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Delivery-date: Mon, 01 Oct 2001 12:58:03 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Doubt Related to SDH/SONET interface : GMPLS
Date: Mon, 01 Oct 2001 12:51:40 -0700

Hi All,
       If minimum reservable bandwidth of an STM-16 link in interface 
switching capability TLV is VC-3, does this mean it can't switch VC
-2/VC-11 etc ? In other words, if a request comes for establishing
an LSP with signal type as VC-11, it can't establish this LSP ?
STM-16 has 16 branches, if each of these branches support different min. 
reservable bandwidth then does this mean it will be having 16 interface 
switching capability TLVs ?
Is this a deviation from SDH/SONET where u can't assume that if
minimum reservable bandwidth is say VC-2 and max. reservable bandwidth is 
say STM-1, it doesn't mean that all the signals viz. VC-4, VC-12, VC-3 
etc.(i.e. that fall under STM-1 and VC-2) are supported ?

Please correct me if I am wrong.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp