RE: disman MIB Followup on gmpls-alarm-spec-

["Wijnen, Bert (Bert)" <[e-mail]>]

TO me this looks fine

Thanks,
Bert 

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: vrijdag 30 januari 2004 16:01
> To: Tom Petch; Randy Presuhn
> Cc: Wijnen, Bert (Bert); [e-mail]
> Subject: disman MIB Followup on gmpls-alarm-spec-
> 
> 
> Tom, (Randy)
> 
>          Thank you for providing this input.  What we're 
> looking for is a 
> reference that provides enumerated values for alarms.  The 
> ITU specs that 
> we found all provide text strings, which is what we're trying 
> to avoid.  It 
> seems that the disman MIB provides exactly what we're looking for.
> 
> Please let us know if our intended use of the values defined 
> in the MIB 
> makes sense from your (disman WG's) perspective, or if you 
> recommend an 
> alternate approach.
> 
> Thank you,
> Lou
> 
> PS The text in the new rev (submitted today) of the draft reads:
> [from: 
> http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
> 3.1.3. Error Codes and Values
> 
>     The Error Codes and Values used in ALARM_SPEC objects are 
> the same as
>     those used in ERROR_SPEC objects.  New Error Code values 
> for use with
>     both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
>     alarm types defined by other standards.
> 
>     In this document we define one new Error Code.  The Error 
> Code uses
>     the value TBA (by IANA) and is referred to as "Alarms".  
> The values
>     used in the Error Values field are the same as the values used for
>     IANAItuProbableCause in the Alarm MIB [ALARM-MIB].
> 
> The error values field is carried in an object with the format:
> [from: rfc3473]
>      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |            Length             | Class-Num (6) | C-Type (3)    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                     IPv4 Error Node Address                   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Flags     |   Error Code  |          Error Value          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     ~                              TLVs                             ~
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> At 10:20 AM 11/19/2003, Tom Petch wrote:
> >FYI
> >
> >
> >As a member of the disman WG, I have followed the 
> development of the alarm 
> >mib,
> >currently draft-ietf-disman-alarm-mib-15.txt, over some 
> years and this has
> >included formal liaison with SG4 and some contact with SG15 
> over such 
> >issues as
> >who owns the code points and who can define them.  SG4 have expressed
> >satisfaction with the way in which the liaison with disman 
> WG has worked 
> >(as on
> >the IETF web site).
> >
> >But
> >
> >1) not knowing the working procedures of the ITU, I don't 
> know if the 
> >agreement
> >with disman extends to other IETF WG - the wording suggests 
> not to me.
> >
> >2) the alarm mib is currently under debate between authors 
> and WG chair with a
> >list of some 80 issues being resolved; the most difficult to resolve 
> >appear IMO
> >to be the ones relating to the existence of the ITU alarm table as an
> >augmentation of the basic disman alarm table (and perhaps 
> IMHO the lack of
> >suitable features in SMIv2).  The alarm mib is complex, not 
> one I would expect
> >people to be able to dip into and readily extract a part thereof.
> >
> >3) I have lost track of the start of this thread and just 
> what it was that 
> >this,
> >ccamp, WG
> >wanted to include in what (and my Acrobat viewer renders the 
> text of the 
> >bullet
> >points in AlarmSpec as black blobs of varying size:-(!  But 
> whatever it is, I
> >suggest you contact the
> >disman chair, randy presuhn, to clarify the niceties of any 
> interaction 
> >with the
> >output of disman, whatever form that finally takes.  It may 
> be that M.3100
> >related material should be in a common MIB module and not 
> included in the 
> >alarm
> >mib because of issues of future updates and cross references 
> from multiple 
> >WGs..
> >
> >I think this is known as cross-functional review:-)
> >
> >Tom Petch
> >
> >
> >-----Original Message-----
> >From: Wijnen, Bert (Bert) <[e-mail]>
> >To: Brungard, Deborah A, ALABS <[e-mail]>; Wijnen, 
> Bert (Bert)
> ><[e-mail]>; Adrian Farrel <[e-mail]>; Lou Berger
> ><[e-mail]>
> >Cc: [e-mail] <[e-mail]>
> >Date: 18 November 2003 23:10
> >Subject: RE: Taking to the 
> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >
> >
> > >the disman mib has enumerations I believe!
> > >
> > >Thanks,
> > >Bert
> > >
> > >> -----Original Message-----
> > >> From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
> > >> Sent: dinsdag 18 november 2003 23:06
> > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> > >> Cc: [e-mail]
> > >> Subject: RE: Taking to the
> > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> > >>
> > >>
> > >> Thanks Bert.
> > >>
> > >> M.3100 provides the generic information model, X.733 and
> > >> X.736 define OSI generics pointing to X.721, and X.721
> > >> provides abstract syntax. We were looking for an enumeration
> > >> to use vs. needing to support abstract syntax strings in
> > >> signaling. Any suggestions are welcome.
> > >> Deborah
> > >>
> > >> -----Original Message-----
> > >> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> > >> Sent: Tuesday, November 11, 2003 11:46 AM
> > >> To: Adrian Farrel; Lou Berger
> > >> Cc: [e-mail]
> > >> Subject: RE: Taking to the
> > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> > >>
> > >>
> > >> Things to potentially look at:
> > >>
> > >>   draft-ietf-disman-alarm-mib-15.txt
> > >>
> > >>   [M.3100]    ITU Recommendation M.3100, "Generic 
> Network Information
> > >>               Model", 1995
> > >>
> > >>   [X.733]     ITU Recommendation X.733, "Information 
> Technology - Open
> > >>               Systems Interconnection - System Management: Alarm
> > >>               Reporting Function", 1992
> > >>
> > >>   [X.736]     ITU Recommendation X.736, "Information 
> Technology - Open
> > >>               Systems Interconnection - System 
> Management: Security
> > >>               Alarm Reporting Function", 1992
> > >>
> > >> Thanks,
> > >> Bert
> > >>
> > >> > -----Original Message-----
> > >> > From: Adrian Farrel [mailto:[e-mail]]
> > >> > Sent: dinsdag 11 november 2003 17:28
> > >> > To: Lou Berger
> > >> > Cc: [e-mail]
> > >> > Subject: Re: Taking to the
> > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> > >> >
> > >> >
> > >> > Lou,
> > >> >
> > >> > I believe the alarm reference was M.3100.
> > >> >
> > >> > Can someone confirm?
> > >> >
> > >> > Adrian
> > >> >
> > >> >
> > >> > > In the morning's meeting the AD's asked to bring the
> > >> proposed Alarm
> > >> > > communication extension to "the list".  For today's
> > >> > presentation see:
> > >> > > http://www.labn.net/docs/AlarmSpec00.pdf
> > >> > >
> > >> > > I believe the issues to be discussed are:
> > >> > > 1) Is there general interest in this work?
> > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
> > >> > >          (We think there's some value, particularly 
> with string
> > >> > >           and timestamp)
> > >> > > 3) Are there good references for alarm code points?
> > >> > >
> > >> > > Thank,
> > >> > > Lou (and co-authors)
> > >> >
> > >> >
> > >>
> > >
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 31 Jan 2004 00:13:57 +0000
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: "'Lou Berger'" <[e-mail]>, Tom Petch <[e-mail]>, Randy Presuhn <[e-mail]>
Cc: "Wijnen, Bert (Bert)" <[e-mail]>, [e-mail]
Subject: RE: disman MIB Followup on gmpls-alarm-spec-
Date: Sat, 31 Jan 2004 01:11:38 +0100
MIME-Version: 1.0
Content-Type: text/plain

TO me this looks fine

Thanks,
Bert 

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: vrijdag 30 januari 2004 16:01
> To: Tom Petch; Randy Presuhn
> Cc: Wijnen, Bert (Bert); [e-mail]
> Subject: disman MIB Followup on gmpls-alarm-spec-
> 
> 
> Tom, (Randy)
> 
>          Thank you for providing this input.  What we're 
> looking for is a 
> reference that provides enumerated values for alarms.  The 
> ITU specs that 
> we found all provide text strings, which is what we're trying 
> to avoid.  It 
> seems that the disman MIB provides exactly what we're looking for.
> 
> Please let us know if our intended use of the values defined 
> in the MIB 
> makes sense from your (disman WG's) perspective, or if you 
> recommend an 
> alternate approach.
> 
> Thank you,
> Lou
> 
> PS The text in the new rev (submitted today) of the draft reads:
> [from: 
> http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
> 3.1.3. Error Codes and Values
> 
>     The Error Codes and Values used in ALARM_SPEC objects are 
> the same as
>     those used in ERROR_SPEC objects.  New Error Code values 
> for use with
>     both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
>     alarm types defined by other standards.
> 
>     In this document we define one new Error Code.  The Error 
> Code uses
>     the value TBA (by IANA) and is referred to as "Alarms".  
> The values
>     used in the Error Values field are the same as the values used for
>     IANAItuProbableCause in the Alarm MIB [ALARM-MIB].
> 
> The error values field is carried in an object with the format:
> [from: rfc3473]
>      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |            Length             | Class-Num (6) | C-Type (3)    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                     IPv4 Error Node Address                   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Flags     |   Error Code  |          Error Value          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     ~                              TLVs                             ~
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> At 10:20 AM 11/19/2003, Tom Petch wrote:
> >FYI
> >
> >
> >As a member of the disman WG, I have followed the 
> development of the alarm 
> >mib,
> >currently draft-ietf-disman-alarm-mib-15.txt, over some 
> years and this has
> >included formal liaison with SG4 and some contact with SG15 
> over such 
> >issues as
> >who owns the code points and who can define them.  SG4 have expressed
> >satisfaction with the way in which the liaison with disman 
> WG has worked 
> >(as on
> >the IETF web site).
> >
> >But
> >
> >1) not knowing the working procedures of the ITU, I don't 
> know if the 
> >agreement
> >with disman extends to other IETF WG - the wording suggests 
> not to me.
> >
> >2) the alarm mib is currently under debate between authors 
> and WG chair with a
> >list of some 80 issues being resolved; the most difficult to resolve 
> >appear IMO
> >to be the ones relating to the existence of the ITU alarm table as an
> >augmentation of the basic disman alarm table (and perhaps 
> IMHO the lack of
> >suitable features in SMIv2).  The alarm mib is complex, not 
> one I would expect
> >people to be able to dip into and readily extract a part thereof.
> >
> >3) I have lost track of the start of this thread and just 
> what it was that 
> >this,
> >ccamp, WG
> >wanted to include in what (and my Acrobat viewer renders the 
> text of the 
> >bullet
> >points in AlarmSpec as black blobs of varying size:-(!  But 
> whatever it is, I
> >suggest you contact the
> >disman chair, randy presuhn, to clarify the niceties of any 
> interaction 
> >with the
> >output of disman, whatever form that finally takes.  It may 
> be that M.3100
> >related material should be in a common MIB module and not 
> included in the 
> >alarm
> >mib because of issues of future updates and cross references 
> from multiple 
> >WGs..
> >
> >I think this is known as cross-functional review:-)
> >
> >Tom Petch
> >
> >
> >-----Original Message-----
> >From: Wijnen, Bert (Bert) <[e-mail]>
> >To: Brungard, Deborah A, ALABS <[e-mail]>; Wijnen, 
> Bert (Bert)
> ><[e-mail]>; Adrian Farrel <[e-mail]>; Lou Berger
> ><[e-mail]>
> >Cc: [e-mail] <[e-mail]>
> >Date: 18 November 2003 23:10
> >Subject: RE: Taking to the 
> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >
> >
> > >the disman mib has enumerations I believe!
> > >
> > >Thanks,
> > >Bert
> > >
> > >> -----Original Message-----
> > >> From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
> > >> Sent: dinsdag 18 november 2003 23:06
> > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> > >> Cc: [e-mail]
> > >> Subject: RE: Taking to the
> > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> > >>
> > >>
> > >> Thanks Bert.
> > >>
> > >> M.3100 provides the generic information model, X.733 and
> > >> X.736 define OSI generics pointing to X.721, and X.721
> > >> provides abstract syntax. We were looking for an enumeration
> > >> to use vs. needing to support abstract syntax strings in
> > >> signaling. Any suggestions are welcome.
> > >> Deborah
> > >>
> > >> -----Original Message-----
> > >> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> > >> Sent: Tuesday, November 11, 2003 11:46 AM
> > >> To: Adrian Farrel; Lou Berger
> > >> Cc: [e-mail]
> > >> Subject: RE: Taking to the
> > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> > >>
> > >>
> > >> Things to potentially look at:
> > >>
> > >>   draft-ietf-disman-alarm-mib-15.txt
> > >>
> > >>   [M.3100]    ITU Recommendation M.3100, "Generic 
> Network Information
> > >>               Model", 1995
> > >>
> > >>   [X.733]     ITU Recommendation X.733, "Information 
> Technology - Open
> > >>               Systems Interconnection - System Management: Alarm
> > >>               Reporting Function", 1992
> > >>
> > >>   [X.736]     ITU Recommendation X.736, "Information 
> Technology - Open
> > >>               Systems Interconnection - System 
> Management: Security
> > >>               Alarm Reporting Function", 1992
> > >>
> > >> Thanks,
> > >> Bert
> > >>
> > >> > -----Original Message-----
> > >> > From: Adrian Farrel [mailto:[e-mail]]
> > >> > Sent: dinsdag 11 november 2003 17:28
> > >> > To: Lou Berger
> > >> > Cc: [e-mail]
> > >> > Subject: Re: Taking to the
> > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> > >> >
> > >> >
> > >> > Lou,
> > >> >
> > >> > I believe the alarm reference was M.3100.
> > >> >
> > >> > Can someone confirm?
> > >> >
> > >> > Adrian
> > >> >
> > >> >
> > >> > > In the morning's meeting the AD's asked to bring the
> > >> proposed Alarm
> > >> > > communication extension to "the list".  For today's
> > >> > presentation see:
> > >> > > http://www.labn.net/docs/AlarmSpec00.pdf
> > >> > >
> > >> > > I believe the issues to be discussed are:
> > >> > > 1) Is there general interest in this work?
> > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
> > >> > >          (We think there's some value, particularly 
> with string
> > >> > >           and timestamp)
> > >> > > 3) Are there good references for alarm code points?
> > >> > >
> > >> > > Thank,
> > >> > > Lou (and co-authors)
> > >> >
> > >> >
> > >>
> > >
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 30 Jan 2004 15:04:20 +0000
Message-Id: <4.3.2.7.2.20040130092632.03e9af00@mo-ex1>
Date: Fri, 30 Jan 2004 10:01:14 -0500
To: "Tom Petch" <[e-mail]>, "Randy Presuhn" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: disman MIB Followup on gmpls-alarm-spec-
Cc: "Wijnen, Bert (Bert)" <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tom, (Randy)

         Thank you for providing this input.  What we're looking for is a 
reference that provides enumerated values for alarms.  The ITU specs that 
we found all provide text strings, which is what we're trying to avoid.  It 
seems that the disman MIB provides exactly what we're looking for.

Please let us know if our intended use of the values defined in the MIB 
makes sense from your (disman WG's) perspective, or if you recommend an 
alternate approach.

Thank you,
Lou

PS The text in the new rev (submitted today) of the draft reads:
[from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
3.1.3. Error Codes and Values

    The Error Codes and Values used in ALARM_SPEC objects are the same as
    those used in ERROR_SPEC objects.  New Error Code values for use with
    both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
    alarm types defined by other standards.

    In this document we define one new Error Code.  The Error Code uses
    the value TBA (by IANA) and is referred to as "Alarms".  The values
    used in the Error Values field are the same as the values used for
    IANAItuProbableCause in the Alarm MIB [ALARM-MIB].

The error values field is carried in an object with the format:
[from: rfc3473]
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Length             | Class-Num (6) | C-Type (3)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     IPv4 Error Node Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |   Error Code  |          Error Value          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                              TLVs                             ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



At 10:20 AM 11/19/2003, Tom Petch wrote:
>FYI
>
>
>As a member of the disman WG, I have followed the development of the alarm 
>mib,
>currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has
>included formal liaison with SG4 and some contact with SG15 over such 
>issues as
>who owns the code points and who can define them.  SG4 have expressed
>satisfaction with the way in which the liaison with disman WG has worked 
>(as on
>the IETF web site).
>
>But
>
>1) not knowing the working procedures of the ITU, I don't know if the 
>agreement
>with disman extends to other IETF WG - the wording suggests not to me.
>
>2) the alarm mib is currently under debate between authors and WG chair with a
>list of some 80 issues being resolved; the most difficult to resolve 
>appear IMO
>to be the ones relating to the existence of the ITU alarm table as an
>augmentation of the basic disman alarm table (and perhaps IMHO the lack of
>suitable features in SMIv2).  The alarm mib is complex, not one I would expect
>people to be able to dip into and readily extract a part thereof.
>
>3) I have lost track of the start of this thread and just what it was that 
>this,
>ccamp, WG
>wanted to include in what (and my Acrobat viewer renders the text of the 
>bullet
>points in AlarmSpec as black blobs of varying size:-(!  But whatever it is, I
>suggest you contact the
>disman chair, randy presuhn, to clarify the niceties of any interaction 
>with the
>output of disman, whatever form that finally takes.  It may be that M.3100
>related material should be in a common MIB module and not included in the 
>alarm
>mib because of issues of future updates and cross references from multiple 
>WGs..
>
>I think this is known as cross-functional review:-)
>
>Tom Petch
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) <[e-mail]>
>To: Brungard, Deborah A, ALABS <[e-mail]>; Wijnen, Bert (Bert)
><[e-mail]>; Adrian Farrel <[e-mail]>; Lou Berger
><[e-mail]>
>Cc: [e-mail] <[e-mail]>
>Date: 18 November 2003 23:10
>Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>
>
> >the disman mib has enumerations I believe!
> >
> >Thanks,
> >Bert
> >
> >> -----Original Message-----
> >> From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
> >> Sent: dinsdag 18 november 2003 23:06
> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> >> Cc: [e-mail]
> >> Subject: RE: Taking to the
> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >>
> >>
> >> Thanks Bert.
> >>
> >> M.3100 provides the generic information model, X.733 and
> >> X.736 define OSI generics pointing to X.721, and X.721
> >> provides abstract syntax. We were looking for an enumeration
> >> to use vs. needing to support abstract syntax strings in
> >> signaling. Any suggestions are welcome.
> >> Deborah
> >>
> >> -----Original Message-----
> >> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> >> Sent: Tuesday, November 11, 2003 11:46 AM
> >> To: Adrian Farrel; Lou Berger
> >> Cc: [e-mail]
> >> Subject: RE: Taking to the
> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >>
> >>
> >> Things to potentially look at:
> >>
> >>   draft-ietf-disman-alarm-mib-15.txt
> >>
> >>   [M.3100]    ITU Recommendation M.3100, "Generic Network Information
> >>               Model", 1995
> >>
> >>   [X.733]     ITU Recommendation X.733, "Information Technology - Open
> >>               Systems Interconnection - System Management: Alarm
> >>               Reporting Function", 1992
> >>
> >>   [X.736]     ITU Recommendation X.736, "Information Technology - Open
> >>               Systems Interconnection - System Management: Security
> >>               Alarm Reporting Function", 1992
> >>
> >> Thanks,
> >> Bert
> >>
> >> > -----Original Message-----
> >> > From: Adrian Farrel [mailto:[e-mail]]
> >> > Sent: dinsdag 11 november 2003 17:28
> >> > To: Lou Berger
> >> > Cc: [e-mail]
> >> > Subject: Re: Taking to the
> >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
> >> >
> >> >
> >> > Lou,
> >> >
> >> > I believe the alarm reference was M.3100.
> >> >
> >> > Can someone confirm?
> >> >
> >> > Adrian
> >> >
> >> >
> >> > > In the morning's meeting the AD's asked to bring the
> >> proposed Alarm
> >> > > communication extension to "the list".  For today's
> >> > presentation see:
> >> > > http://www.labn.net/docs/AlarmSpec00.pdf
> >> > >
> >> > > I believe the issues to be discussed are:
> >> > > 1) Is there general interest in this work?
> >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
> >> > >          (We think there's some value, particularly with string
> >> > >           and timestamp)
> >> > > 3) Are there good references for alarm code points?
> >> > >
> >> > > Thank,
> >> > > Lou (and co-authors)
> >> >
> >> >
> >>
> >




Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jan 2004 18:54:51 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
Date: Wed, 28 Jan 2004 11:05:56 -0500

--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		: Generalized MPLS (GMPLS) RSVP-TE Signalling in support
			  of Automatically Switched Optical Network (ASON)
	Author(s)	: J. Drake
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
	Pages		: 41
	Date		: 2004-1-27
	
This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of
the Automatically Switched Optical Network (ASON) architecture
specified by the ITU-T. The requirements are in a companion document
'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON).'

In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures,
extended label usage and crankback signalling capability.

The mechanisms proposed in the present document are applicable to
any environment (including multi-area) and for any type of
interface: packet, layer-2, time-division multiplexed, lambda or
fiber switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-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-gmpls-rsvp-te-ason-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--






Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jan 2004 16:07:52 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
Date: Wed, 28 Jan 2004 11:06:01 -0500

--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		: Recovery (Protection and Restoration) Terminology for GMPLS
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
	Pages		: 20
	Date		: 2004-1-27
	
This document defines a common terminology for Generalized Multi-
Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
protection and restoration) that are under consideration by the
CCAMP Working Group. The proposed terminology is intended to be
independent of the underlying transport technologies covered by
GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.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-recovery-terminology-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--






Envelope-to: [e-mail]
Delivery-date: Thu, 29 Jan 2004 00:09:07 +0000
Message-ID: <017a01c3e5fb$c2d18990$b8849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Requests for agenda slots
Date: Thu, 29 Jan 2004 00:03:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK folks,
Time to start requesting agenda slots.

Please mail to me and Kireeti. Make the Subject line start with AGENDA:

Please state the name and version number of the draft.
Please suggest how long you need to describe progress and plans, and hear questions.

Recall - you are not presenting your drafts!

Authors of new drafts would be well advised to ensure that their draft clearly falls
within the charter. The best way to do this is to write a summary section that highlights
the line items in the charter that your draft addresses.. Have a look at
draft-ietf-ccamp-crankback-00.txt if you need a model.

Authors/editors of working group drafts can expect to be prodded by me for contributions.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jan 2004 16:09:19 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
Date: Wed, 28 Jan 2004 11:06:01 -0500

--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		: Recovery (Protection and Restoration) Terminology for GMPLS
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
	Pages		: 20
	Date		: 2004-1-27
	
This document defines a common terminology for Generalized Multi-
Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
protection and restoration) that are under consideration by the
CCAMP Working Group. The proposed terminology is intended to be
independent of the underlying transport technologies covered by
GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.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-recovery-terminology-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Wed, 28 Jan 2004 16:09:03 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
Date: Wed, 28 Jan 2004 11:05:56 -0500

--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		: Generalized MPLS (GMPLS) RSVP-TE Signalling in support
			  of Automatically Switched Optical Network (ASON)
	Author(s)	: J. Drake
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
	Pages		: 41
	Date		: 2004-1-27
	
This document specifies how Generalized MPLS (GMPLS) RSVP-TE
signaling may be used and extended to satisfy the requirements of
the Automatically Switched Optical Network (ASON) architecture
specified by the ITU-T. The requirements are in a companion document
'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for
Automatically Switched Optical Network (ASON).'

In particular, this document details the mechanisms for setting up
Soft Permanent Connections (SPC), the necessary extensions in
delivering full and logical call/connection separation support, the
extended restart capabilities during control plane failures,
extended label usage and crankback signalling capability.

The mechanisms proposed in the present document are applicable to
any environment (including multi-area) and for any type of
interface: packet, layer-2, time-division multiplexed, lambda or
fiber switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-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-gmpls-rsvp-te-ason-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jan 2004 23:15:08 +0000
Date: Tue, 27 Jan 2004 18:13:48 -0500 (EST)
From: IESG Secretary <[e-mail]>
To: [e-mail]
cc: [e-mail], <[e-mail]>, <[e-mail]>
Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

The IESG has reviewed the situation with RSVP C-Type allocations
performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more
information). The IESG recommends that IANA allocates C-Type value 4
in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks
value 3 in these ranges as "deprecated".

Note well: this does not set a precedent for IESG support of changing
IANA allocations based on implementation circumstances.

The IESG also requests that CCAMP WG takes on the effort of reviewing
the situation and takes measures to prevent similar problems from
happening in the future.

[1] IESG, "Short Last Call: IANA allocations for
        ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message,

http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jan 2004 20:42:23 +0000
Date: Tue, 27 Jan 2004 12:40:39 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: Ben Mack-Crane <[e-mail]>
CC: [e-mail]
Subject: Re: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben,

  [cc'ing the ccamp list]

  Yup. I checked the TSPEC right after I hit the send button.
  I'm following up with IANA already.

-- 
Alex

Tuesday, January 27, 2004, 12:35:03 PM, Ben Mack-Crane wrote:
> Alex,

> I just checked the IANA website and found the following:

>       9  FLOWSPEC                             [RFC2205]

>          Class Types or C-Types:

>            1   Reserved                       [RFC2205]
>            2   Int-serv Flowspec              [RFC2210]
>            3   Deprecated                     [IESG]
>            4   SONET/SDH FLOWSPEC             [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt]

> ...

>     12  SENDER_TSPEC                          [RFC2205]

>         Class Types or C-Types:

>           2   Int-serv                        [RFC2210]
>           3   SONET/SDH SENDER_TSPEC          [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt]


> It looks like the FLOWSPEC is changed but the TSPEC is not.  So there 
> may be a bit of fixing yet to do.

> Regards,
> Ben

> Alex Zinin wrote:

>>Folks-
>>
>> I haven't been successful in getting the secretariat to send the IESG
>> message on the subj to the right recipients, so I am forwarding the
>> original of the IESG statement that we agreed on Thursday last week.
>> I believe IANA guys already made necessary corrections in the
>> registry.
>>
>> On a related topic, we're working with the WG chairs on the long-term
>> solutions to the problem. Ideas should be documented in an I-D soon.
>>
>> Cheers.




Envelope-to: [e-mail]
Delivery-date: Tue, 27 Jan 2004 20:17:15 +0000
Date: Tue, 27 Jan 2004 12:13:58 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks-

 I haven't been successful in getting the secretariat to send the IESG
 message on the subj to the right recipients, so I am forwarding the
 original of the IESG statement that we agreed on Thursday last week.
 I believe IANA guys already made necessary corrections in the
 registry.

 On a related topic, we're working with the WG chairs on the long-term
 solutions to the problem. Ideas should be documented in an I-D soon.

 Cheers.
 
-- 
Alex Zinin

> From: [e-mail]
> To: [e-mail]
> Cc: [e-mail]
> Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh
> 
> The IESG has reviewed the situation with RSVP C-Type allocations
> performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more
> information). The IESG recommends that IANA allocates C-Type value 4
> in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks
> value 3 in these ranges as "deprecated".
> 
> Note well: this does not set a precedent for IESG support of changing
> IANA allocations based on implementation circumstances.
> 
> The IESG also requests that CCAMP WG takes on the effort of reviewing
> the situation and takes measures to prevent similar problems from
> happening in the future.
> 
> [1] IESG, "Short Last Call: IANA allocations for
>     ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message,
>     http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html




Envelope-to: [e-mail]
Delivery-date: Sat, 24 Jan 2004 15:23:56 +0000
Message-Id: <4.3.2.7.2.20040124101905.0279dee8@mo-ex1>
Date: Sat, 24 Jan 2004 10:21:28 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Adrian,

oh well, I asked for notification to be sent to the list.

I was thinking of this as an individual draft, but you are probably right 
that it should go through WG review as it clarifies a protocol produced by 
the group.  Moving it forward as a BCP probably is the right call...

Thanks for forwarding the announcement.

Lou

At 05:43 PM 1/23/2004, Adrian Farrel wrote:

>All,
>
>I didn't see notification of this to the list, but it sure is relevant.
>
>Would appreciate review input from everyone, but especially those who were 
>not clear about
>how/whether GMPLS supported egress port/label control.
>
>Also, can you think about whether this draft should be run through the WG.
>
>Thanks,
>Adrian
>
>----- Original Message -----
>From: <[e-mail]>
>To: <IETF-Announce:>
>Sent: Friday, January 23, 2004 8:59 PM
>Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt
>
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> >
> >
> > Title : GMPLS Signaling Procedure For Egress Control
> > Author(s) : L. Berger
> > Filename : draft-berger-gmpls-egress-control-01.txt
> > Pages : 5
> > Date : 2004-1-23
> >
> > This note clarifies the procedures for the control of a label used on
> > an egress output/downstream interface.  Such control is also know and
> > 'Egress Control'.  Support for Egress Control is implicit in
> > Generalized Multi-Protocol Label Switching (GMPLS) Signaling
> > [RFC3471] and [RFC3473].  This note does not modify GMPLS signaling
> > mechanisms and procedures and should be viewed as an informative
> > clarification of [RFC3473].
> >
> > A URL for this Internet-Draft is:
> > 
> <http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt 
>
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the 
> message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-berger-gmpls-egress-control-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
> > or 
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > [e-mail].
> > In the body type:
> > "FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>




Envelope-to: [e-mail]
Delivery-date: Fri, 23 Jan 2004 22:47:17 +0000
Message-ID: <0f6901c3e202$5736d890$715708c3@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt
Date: Fri, 23 Jan 2004 22:43:32 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0F66_01C3E202.54330E70"

This is a multi-part message in MIME format.

------=_NextPart_000_0F66_01C3E202.54330E70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I didn't see notification of this to the list, but it sure is relevant.

Would appreciate review input from everyone, but especially those who were not clear about
how/whether GMPLS supported egress port/label control.

Also, can you think about whether this draft should be run through the WG.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <IETF-Announce:>
Sent: Friday, January 23, 2004 8:59 PM
Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : GMPLS Signaling Procedure For Egress Control
> Author(s) : L. Berger
> Filename : draft-berger-gmpls-egress-control-01.txt
> Pages : 5
> Date : 2004-1-23
>
> This note clarifies the procedures for the control of a label used on
> an egress output/downstream interface.  Such control is also know and
> 'Egress Control'.  Support for Egress Control is implicit in
> Generalized Multi-Protocol Label Switching (GMPLS) Signaling
> [RFC3471] and [RFC3473].  This note does not modify GMPLS signaling
> mechanisms and procedures and should be viewed as an informative
> clarification of [RFC3473].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-berger-gmpls-egress-control-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

------=_NextPart_000_0F66_01C3E202.54330E70
Content-Type: application/octet-stream;
	name="ATT03937.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT03937.dat"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt

------=_NextPart_000_0F66_01C3E202.54330E70
Content-Type: text/plain;
	name="draft-berger-gmpls-egress-control-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-berger-gmpls-egress-control-01.txt"

Content-Type: text/plain
Content-ID:	<[e-mail]>

------=_NextPart_000_0F66_01C3E202.54330E70--




Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jan 2004 12:30:10 +0000
Message-ID: <0d3201c3e0e3$23cf6be0$715708c3@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ronald Bonica" <[e-mail]>
Subject: Re: GTTP Draft
Date: Thu, 22 Jan 2004 12:26:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

Recall that a tunnel trace protocol is now in our charter.
If the WG considers that GTTP is suitable, we should adopt it and drive it to conclusion.
If the WG thinks that GTTP is not suitable (or that there is no need for a tunnel trace
protocol) voices should be raised.

Cheers,
Adrian
----- Original Message ----- 
From: "Ronald Bonica" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, January 22, 2004 3:04 AM
Subject: GTTP Draft


> Folks,
>
> I have updated the generic tunnel tracing draft. It is available at
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please
> review and comment.
>
>                                                Ron
>
> Abstract
> This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP
> supports enhanced route-tracing applications. Network operators use enhanced
> route-tracing applications to trace the path between any two points in an IP
> network. Enhanced route-tracing applications can trace through a network's
> forwarding plane, its control plane or both. Furthermore, enhanced
> route-tracing applications can reveal details concerning tunnels that
> support the traced path. Tunnel details can be revealed regardless of
> tunneling technology. For example, enhanced route-tracing applications can
> trace through an MPLS LSP as well as they can trace through an IP-in-IP
> tunnel.
>
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "There is more to life than simply
>                   increasing its speed."
>                       -- Mahatma Gandhi
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jan 2004 03:12:56 +0000
Date: Wed, 21 Jan 2004 22:04:03 -0500
From: Ronald Bonica <[e-mail]>
Subject: GTTP Draft
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

Folks,

I have updated the generic tunnel tracing draft. It is available at
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please
review and comment.

                                               Ron

Abstract
This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP
supports enhanced route-tracing applications. Network operators use enhanced
route-tracing applications to trace the path between any two points in an IP
network. Enhanced route-tracing applications can trace through a network's
forwarding plane, its control plane or both. Furthermore, enhanced
route-tracing applications can reveal details concerning tunnels that
support the traced path. Tunnel details can be revealed regardless of
tunneling technology. For example, enhanced route-tracing applications can
trace through an MPLS LSP as well as they can trace through an IP-in-IP
tunnel.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"There is more to life than simply
                  increasing its speed."
                      -- Mahatma Gandhi




Envelope-to: [e-mail]
Delivery-date: Wed, 21 Jan 2004 13:47:25 +0000
Message-ID: <0c0b01c3e024$db11d7d0$715708c3@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Submission deadlines for Seoul
Date: Wed, 21 Jan 2004 13:45:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

Please be aware of the following deadlines.

February 9, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00
ET
February 16, Monday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET

Also, be warned!
We plan to require submission of slides in advance of the meeting so that the attendees
can follow along at their own speed.
There will be something like a 24 hour deadline on this so you won't have to write slides
until you know you are on the agenda.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jan 2004 19:35:16 +0000
Date: Tue, 20 Jan 2004 11:32:26 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Liaison response posted
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

The Liaison response that the CCAMP WG sent to the ITU-T re G.7713.2
has been posted to the IETF "Liaison Statements" page at
http://ietf.org/IESG/liaison.html .

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jan 2004 18:01:46 +0000
Message-Id: <[e-mail]>
From: The IESG <[e-mail]>
cc: [e-mail]
Subject: Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh
Date: Mon, 19 Jan 2004 18:37:35 -0500

The IESG is considering the situation with IANA allocation of the RSVP
FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that
has been recently approved by the IESG for publication as an RFC.

While the long-term measures to prevent similar situations in future
are being discussed, the issue at hand needs to be quickly resolved.
The proposed solution is to change the assignment of the above C-Types
from value 3 (currently assigned by IANA) to 4, and mark value 3 as
"reserved".

The IESG would like to solicit comments on the proposed solution from
the community. More details are given below. Please send your comments
by January 22nd, 2004.

Description of the situation with IANA assignments for
ietf-ccamp-gmpls-sonet-sdh:

1. After the approval of the document by the IESG, an IANA action has
   been performed for the document, in which IANA correctly picked the
   next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC
   ranges and assigned it to the document.

2. However, the CCAMP WG has been informed that value 3 is being used
   by implementations of an another (expired) Internet draft that
   also picked next available value in the same ranges. Because the
   draft never progressed, these values have never been formally
   allocated by IANA within the RSVP registry.

3. Because implementations of the expired Internet draft have been
   deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would
   create interoperability problems.

4. An implementation survey performed in the CCAMP WG showed that
   most early implementations of ietf-ccamp-gmpls-sonet-sdh use
   value 4, and those few that use the IANA-assigned value 3 would
   be willing to change it to 4 to avoid interoperability problems.



Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jan 2004 12:43:46 +0000
Message-ID: <00dd01c3df53$0d3a25a0$90256497@coritel>
From: "alessio d'achille" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: revised version of the draft
Date: Tue, 20 Jan 2004 13:43:25 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01C3DF5B.611526E0"

This is a multi-part message in MIME format.

------=_NextPart_000_00D8_01C3DF5B.611526E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks,=20

Wer have just submitted a revised version of our draft: =
<draft-dachille-inter-area-path-protection-01.txt>, since the previous =
version included few errors; you will find the new version soon, and we =
ask you to send your feedback to us about this new version and not about =
the previous one.

As Vishal said in a previous e-mail, we would be particularly interested =
in feedback from some of the principal WG members who are involved in =
the inter-AS/inter-area activity.

Best regards,=20

Alessio D'Achille=20

on behalf of Vishal Sharma, Marco Listanti, Fabio Ricciato, and Ugo =
monaco

------=_NextPart_000_00D8_01C3DF5B.611526E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Wer have just submitted a revised =
version of our=20
draft: &lt;draft-dachille-inter-area-path-protection-01.txt&gt;, since =
the=20
previous version included few errors; you will find the new version =
soon, and we=20
ask you to send your feedback to us about this new version and not about =
the=20
previous one.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As Vishal said in a previous e-mail, =
we&nbsp;would=20
be particularly interested in feedback from some of the <FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN class=3D798550518-19012004><FONT =
color=3D#000000>principal=20
WG members who are involved in the inter-AS/inter-area=20
activity</FONT>.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Best regards, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Alessio D'Achille </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>on behalf of Vishal Sharma, Marco =
Listanti, Fabio=20
Ricciato, and Ugo monaco</FONT></DIV></BODY></HTML>

------=_NextPart_000_00D8_01C3DF5B.611526E0--




Envelope-to: [e-mail]
Delivery-date: Tue, 20 Jan 2004 00:11:09 +0000
Date: Mon, 19 Jan 2004 23:37:52 +0000
From: [e-mail]
To: [e-mail]
Subject: BOUNCE [e-mail]:    Non-member submission from [The IESG <[e-mail]>]
Message-Id: <[e-mail]>

>From [e-mail] Mon Jan 19 23:37:40 2004
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.24; FreeBSD)
	id 1Aiixf-000PR6-IC
	for [e-mail]; Mon, 19 Jan 2004 23:37:39 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16365;
	Mon, 19 Jan 2004 18:37:35 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
From: The IESG <[e-mail]>
cc: [e-mail]
Subject: Short Last Call: IANA allocations for
         ietf-ccamp-gmpls-sonet-sdh
Date: Mon, 19 Jan 2004 18:37:35 -0500
Sender: [e-mail]
X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
	psg.com
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=2.61


The IESG is considering the situation with IANA allocation of the RSVP
FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that
has been recently approved by the IESG for publication as an RFC.

While the long-term measures to prevent similar situations in future
are being discussed, the issue at hand needs to be quickly resolved.
The proposed solution is to change the assignment of the above C-Types
from value 3 (currently assigned by IANA) to 4, and mark value 3 as
"reserved".

The IESG would like to solicit comments on the proposed solution from
the community. More details are given below. Please send your comments
by January 22nd, 2004.

Description of the situation with IANA assignments for
ietf-ccamp-gmpls-sonet-sdh:

1. After the approval of the document by the IESG, an IANA action has
   been performed for the document, in which IANA correctly picked the
   next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC
   ranges and assigned it to the document.

2. However, the CCAMP WG has been informed that value 3 is being used
   by implementations of an another (expired) Internet draft that
   also picked next available value in the same ranges. Because the
   draft never progressed, these values have never been formally
   allocated by IANA within the RSVP registry.

3. Because implementations of the expired Internet draft have been
   deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would
   create interoperability problems.

4. An implementation survey performed in the CCAMP WG showed that
   most early implementations of ietf-ccamp-gmpls-sonet-sdh use
   value 4, and those few that use the IANA-assigned value 3 would
   be willing to change it to 4 to avoid interoperability problems.



Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jan 2004 18:32:29 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>, "TE" <[e-mail]>
Cc: "alessio d'achille" <[e-mail]>
Subject: Inter-region TE
Date: Mon, 19 Jan 2004 10:29:58 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C3DE77.2FD8D5C0"

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C3DE77.2FD8D5C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

I just wanted to add that this work ties in to the recent
inter-AS/inter-area TE
work that has been a focus of the TE and CCAMP WGs.

As Alessio mentioned, this work takes a unified view of areas and AS's, and
is applicable to both inter-AS and inter-area scenarios.

Therefore, we would be particularly interested in feedback from some of the
principal WG members who are involved in the inter-AS/inter-area activity.

Regards,
-Vishal
  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On Behalf
Of alessio d'achille
  Sent: Monday, January 19, 2004 7:19 AM
  To: [e-mail]
  Cc: [e-mail]
  Subject: A new draft is available


  Hi all,

  we have just submitted to the IETF a new draft about inter-area path
protection; in this document we addressed the problem of establishing two
disjoint LSPs between two nodes which belongs to different areas (with the
term "areas" we refer to an
  - OSPF area or
  - Autonomous System or
  - Optical island      )

  The draft is now available in the IETF draft directory and its name is :

  <draft-dachille-inter-area-path-protection-00.txt>

  A URL for this Internet-Draft is:


http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio
n-00.txt

  Best regards to all,

  Alessio D'Achille (one of the authors of this draft),
  on behalf of

  Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti
(Author) and Ugo Monaco (Author).


  P.S. We have noticed that there is an error in the authors' referencs in
the very first page in the version of the draft in the IETF draft directory
(in fact, in the very first page, "Ed." figures next to Vishal Sharma, but
he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio
Ricciato, Marco Listanti and Ugo Monaco)





------=_NextPart_000_002C_01C3DE77.2FD8D5C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>I just=20
wanted to add that this work ties in&nbsp;to the recent =
inter-AS/inter-area=20
TE</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>work&nbsp;that has been&nbsp;a&nbsp;focus =
of&nbsp;the=20
TE and CCAMP WGs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>As=20
Alessio mentioned, this work takes a unified view of areas and AS's,=20
and</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>is=20
applicable to both inter-AS and inter-area =
scenarios.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Therefore, we would be particularly =
interested in=20
feedback from some of the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>principal WG members who are involved in the=20
inter-AS/inter-area activity.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>-Vishal</SPAN></FONT></DIV></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>alessio=20
  d'achille<BR><B>Sent:</B> Monday, January 19, 2004 7:19 =
AM<BR><B>To:</B>=20
  [e-mail]<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> =
A new=20
  draft is available<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi all, </FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>we have =
just submitted to=20
  the IETF a new draft about inter-area path protection; in this =
document we=20
  addressed the problem of establishing two disjoint LSPs between two =
nodes=20
  which belongs to different areas (with the term "areas" we refer to=20
  an</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- OSPF =
area=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- =
Autonomous System=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- Optical =

  island&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>The draft is now available in the =
IETF draft=20
  directory and its name is :</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&lt;draft-dachille-inter-area-path-protection-00.txt&gt;</FONT><=
/DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>A URL for this Internet-Draft is: =
</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial size=3D2><U><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-dachille-inter-area-pat=
h-protection-00.txt">http://www.ietf.org/internet-drafts/draft-dachille-i=
nter-area-path-protection-00.txt</A></U></FONT></FONT></FONT></DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
  size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Best =
regards to=20
  all,</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessio =
D'Achille (one of=20
  the authors of this draft), </FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>on behalf of</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Vishal Sharma (co-author), Fabio =
Ricciato=20
  (author), Marco Listanti (Author) and Ugo Monaco =
(Author).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>P.S. We have noticed that there is an =
error in=20
  the authors' referencs in the very first page in the version of the =
draft in=20
  the IETF draft directory (in fact, in the very first page, "Ed." =
figures next=20
  to Vishal Sharma, but he is a co-author, and "Ed." should be next to =
Alessio=20
  D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-inter-area"></A></FONT>=
</FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002C_01C3DE77.2FD8D5C0--




Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jan 2004 18:15:44 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "alessio d'achille" <[e-mail]>
Subject: RE: Inter-region TE
Date: Mon, 19 Jan 2004 10:12:31 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C3DE74.C0106B60"

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C3DE74.C0106B60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

I just wanted to add that this work ties in to the recent
inter-AS/inter-area TE
work that has been a focus of the TE and CCAMP WGs.

As Alessio mentioned, this work takes a unified view of areas and AS's, and
is applicable to both inter-AS and inter-area scenarios.

Therefore, we would be particularly interested in feedback from some of the
principal WG members who are involved in the inter-AS/inter-area activity.

Regards,
-Vishal
  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On Behalf
Of alessio d'achille
  Sent: Monday, January 19, 2004 7:19 AM
  To: [e-mail]
  Cc: [e-mail]
  Subject: A new draft is available


  Hi all,

  we have just submitted to the IETF a new draft about inter-area path
protection; in this document we addressed the problem of establishing two
disjoint LSPs between two nodes which belongs to different areas (with the
term "areas" we refer to an
  - OSPF area or
  - Autonomous System or
  - Optical island      )

  The draft is now available in the IETF draft directory and its name is :

  <draft-dachille-inter-area-path-protection-00.txt>

  A URL for this Internet-Draft is:


http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio
n-00.txt

  Best regards to all,

  Alessio D'Achille (one of the authors of this draft),
  on behalf of

  Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti
(Author) and Ugo Monaco (Author).


  P.S. We have noticed that there is an error in the authors' referencs in
the very first page in the version of the draft in the IETF draft directory
(in fact, in the very first page, "Ed." figures next to Vishal Sharma, but
he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio
Ricciato, Marco Listanti and Ugo Monaco)





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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>I just=20
wanted to add that this work ties in&nbsp;to the recent =
inter-AS/inter-area=20
TE</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>work&nbsp;that has been&nbsp;a&nbsp;focus =
of&nbsp;the=20
TE and CCAMP WGs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>As=20
Alessio mentioned, this work takes a unified view of areas and AS's,=20
and</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D798550518-19012004>is=20
applicable to both inter-AS and inter-area =
scenarios.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Therefore, we would be particularly =
interested in=20
feedback from some of the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>principal WG members who are involved in the=20
inter-AS/inter-area activity.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D798550518-19012004>-Vishal</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>alessio=20
  d'achille<BR><B>Sent:</B> Monday, January 19, 2004 7:19 =
AM<BR><B>To:</B>=20
  [e-mail]<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> =
A new=20
  draft is available<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi all, </FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>we have =
just submitted to=20
  the IETF a new draft about inter-area path protection; in this =
document we=20
  addressed the problem of establishing two disjoint LSPs between two =
nodes=20
  which belongs to different areas (with the term "areas" we refer to=20
  an</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- OSPF =
area=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- =
Autonomous System=20
  or</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- Optical =

  island&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>The draft is now available in the =
IETF draft=20
  directory and its name is :</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&lt;draft-dachille-inter-area-path-protection-00.txt&gt;</FONT><=
/DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>A URL for this Internet-Draft is: =
</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial size=3D2><U><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-dachille-inter-area-pat=
h-protection-00.txt">http://www.ietf.org/internet-drafts/draft-dachille-i=
nter-area-path-protection-00.txt</A></U></FONT></FONT></FONT></DIV>
  <DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
  size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Best =
regards to=20
  all,</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessio =
D'Achille (one of=20
  the authors of this draft), </FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>on behalf of</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Vishal Sharma (co-author), Fabio =
Ricciato=20
  (author), Marco Listanti (Author) and Ugo Monaco =
(Author).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>P.S. We have noticed that there is an =
error in=20
  the authors' referencs in the very first page in the version of the =
draft in=20
  the IETF draft directory (in fact, in the very first page, "Ed." =
figures next=20
  to Vishal Sharma, but he is a co-author, and "Ed." should be next to =
Alessio=20
  D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-inter-area"></A></FONT>=
</FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0023_01C3DE74.C0106B60--




Envelope-to: [e-mail]
Delivery-date: Mon, 19 Jan 2004 15:20:09 +0000
Message-ID: <00ac01c3de9f$98153980$90256497@coritel>
From: "alessio d'achille" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: A new draft is available
Date: Mon, 19 Jan 2004 16:18:37 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01C3DEA7.E4A18080"

This is a multi-part message in MIME format.

------=_NextPart_000_00A7_01C3DEA7.E4A18080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,=20

we have just submitted to the IETF a new draft about inter-area path =
protection; in this document we addressed the problem of establishing =
two disjoint LSPs between two nodes which belongs to different areas =
(with the term "areas" we refer to an
- OSPF area or
- Autonomous System or
- Optical island      )

The draft is now available in the IETF draft directory and its name is :

<draft-dachille-inter-area-path-protection-00.txt>

A URL for this Internet-Draft is:=20

http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protec=
tion-00.txt

Best regards to all,

Alessio D'Achille (one of the authors of this draft),=20
on behalf of

Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti =
(Author) and Ugo Monaco (Author).


P.S. We have noticed that there is an error in the authors' referencs in =
the very first page in the version of the draft in the IETF draft =
directory (in fact, in the very first page, "Ed." figures next to Vishal =
Sharma, but he is a co-author, and "Ed." should be next to Alessio =
D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)






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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>we have =
just submitted to=20
the IETF a new draft about inter-area path protection; in this document =
we=20
addressed the problem of establishing two disjoint LSPs between two =
nodes which=20
belongs to different areas (with the term "areas" we refer to=20
an</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- OSPF area =

or</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- =
Autonomous System=20
or</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>- Optical=20
island&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The draft is now available in the IETF =
draft=20
directory and its name is :</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&lt;draft-dachille-inter-area-path-protection-00.txt&gt;</FONT><=
/DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A URL for this Internet-Draft is: =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial size=3D2><U><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-dachille-inter-area-pat=
h-protection-00.txt">http://www.ietf.org/internet-drafts/draft-dachille-i=
nter-area-path-protection-00.txt</A></U></FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#0000ff><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Best =
regards to=20
all,</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>Alessio =
D'Achille (one of=20
the authors of this draft), </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>on behalf of</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Vishal Sharma (co-author), Fabio =
Ricciato (author),=20
Marco Listanti (Author) and Ugo Monaco (Author).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>P.S. We have noticed that there is an =
error in the=20
authors' referencs in the very first page in the version of the draft in =
the=20
IETF draft directory (in fact, in the very first page, "Ed." figures =
next to=20
Vishal Sharma, but he is a co-author, and "Ed." should be next to =
Alessio=20
D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial =
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-inter-area"></A></FONT>=
</FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00A7_01C3DEA7.E4A18080--




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 22:04:41 +0000
Date: Fri, 16 Jan 2004 14:02:47 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: Kireeti Kompella <[e-mail]>
CC: Thomas Narten <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IANA assignments
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kireeti,

>> It might be possible to change this assignment if people can make a
>> clear case that:
>>
>>  - leaving the assignment of 3 is clearly worse than changing  to 4,

> This is clear: all implementations that reported (with the exception
> of the new revision from cisco) use the value of 4.

Agreed. Taking care of this.

We also need to make sure we don't have situations like this in
future. The solution with Expert Review Thomas proposed seems to be
reasonable.

Alex

>>    and
>>  - changing to 4 doesn't cause hardship and confusion for those that
>>    have picked up the IANA-assigned value of 3.

> Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on
> this list that reverting to 4 is acceptable *if done quickly*.  So,
> can we do this quickly?

> Kireeti.
> -------




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 18:30:12 +0000
Date: Fri, 16 Jan 2004 10:28:53 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Ben Mack-Crane <[e-mail]>
cc: [e-mail]
Subject: Re: IANA assignments
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 16 Jan 2004, Ben Mack-Crane wrote:

> Adrian and all,
>
> After checking with the OIF, I understand that UNI1.0r2 has passed Straw
> Ballot but
> not Principal Ballot.  The value in question could be adjusted as an
> editorial change before
> going to Principal Ballot.  The OIF is meeting next week and UNI1.0r2 is
> likely to go
> to Principal Ballot soon.

Thanks for the update, Ben.  We'll try to resolve this quickly.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 18:29:57 +0000
Date: Fri, 16 Jan 2004 10:27:13 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Thomas Narten <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: IANA assignments 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 16 Jan 2004, Thomas Narten wrote:

> It might be possible to change this assignment if people can make a
> clear case that:
>
>  - leaving the assignment of 3 is clearly worse than changing  to 4,

This is clear: all implementations that reported (with the exception
of the new revision from cisco) use the value of 4.

>    and
>  - changing to 4 doesn't cause hardship and confusion for those that
>    have picked up the IANA-assigned value of 3.

Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on
this list that reverting to 4 is acceptable *if done quickly*.  So,
can we do this quickly?

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 15:25:26 +0000
Message-ID: <[e-mail]>
Date: Fri, 16 Jan 2004 09:05:25 -0600
From: Ben Mack-Crane <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: [e-mail]
CC: Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IANA assignments
Content-Type: multipart/alternative; boundary="------------080207010105030209060601"

--------------080207010105030209060601
Content-Type: text/plain;
	charset="us-ascii";
	format="flowed"
Content-Transfer-Encoding: 7bit

Adrian and all,

After checking with the OIF, I understand that UNI1.0r2 has passed Straw 
Ballot but
not Principal Ballot.  The value in question could be adjusted as an 
editorial change before
going to Principal Ballot.  The OIF is meeting next week and UNI1.0r2 is 
likely to go
to Principal Ballot soon.

Regards,
Ben

[e-mail] wrote:

> Adrian,
>
> Initially OIF used the value (4) in UNI1.0.  I do not know how this value
> was chosen, or who chose it, but this is probably how it came into 
> common use, since UNI
> interop was done quite a while ago.
>
> While making minor corrections and updates to conform with IETF RFCs 
> (since UNI1.0
> was based on drafts) we consulted the IANA assignments and found (3), 
> so that value
> was used as the corrected value in UNI1.0r2.
>
> So, OIF has followed the official IANA assignment.
>
> Regards,
> Ben
>
> Adrian Farrel wrote:
>
>>Erm,
>>Which order this happen Ben?
>>
>>IANA or OIF first?
>>
>>Thanks,
>>Adrian
>>----- Original Message ----- 
>>From: "Ben Mack-Crane" <[e-mail]>
>>To: <[e-mail]>
>>Cc: <[e-mail]>
>>Sent: Wednesday, January 14, 2004 4:02 PM
>>Subject: Re: IANA assignments
>>
>>
>>  
>>
>>>To add to Andy's factual response on Tellabs' implementations,
>>>I would like to support Bert's messages on following the process
>>>and also state that we are willing to update our implementation
>>>to support the "right" codepoint.
>>>
>>>Other standards organizations depend on the stability of the
>>>IANA process.  For example, the recently approved OIF UNI1.0r2 IA
>>>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
>>>This will be a problem if the IANA assignment is changed.
>>>
>>>Regards,
>>>Ben Mack-Crane
>>>
>>>[e-mail] wrote:
>>>
>>>    
>>>
>>>>Ditto for Tellabs (the same as Kireeti's answer).
>>>>
>>>>Andy
>>>>
>>>>------------
>>>>
>>>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>>>>
>>>>      
>>>>
>>>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>>>>>
>>>>>For the record, here is the answer from Juniper's implementation:
>>>>>
>>>>>        
>>>>>
>>>>>>a) do you use the FLOWSPEC C-Type 3 for CoS?
>>>>>>          
>>>>>>
>>>>>We parse this, but don't really use it.
>>>>>
>>>>>        
>>>>>
>>>>>>b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>>>>>>   you use for the C-Type?
>>>>>>          
>>>>>>
>>>>>Yes. Value 4.
>>>>>
>>>>>        
>>>>>
>>>>>>c) do you use the TSPEC C-Type 3 for CoS?
>>>>>>          
>>>>>>
>>>>>We parse this, but don't really use it.
>>>>>
>>>>>        
>>>>>
>>>>>>d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>>>>>>   you use for the C-Type?
>>>>>>          
>>>>>>
>>>>>Yes. Value 4.
>>>>>
>>>>>Kireeti.
>>>>>-------
>>>>>        
>>>>>
>>>>      
>>>>
>>>-----------------------------------------
>>>============================================================
>>>The information contained in this message may be privileged 
>>>and confidential and protected from disclosure.  If the 
>>>reader of this message is not the intended recipient, or an 
>>>employee or agent responsible for delivering this message to 
>>>the intended recipient, you are hereby notified that any 
>>>reproduction, dissemination or distribution of this 
>>>communication is strictly prohibited. If you have received 
>>>this communication in error, please notify us immediately by 
>>>replying to the message and deleting it from your computer.
>>>
>>>Thank you.
>>>Tellabs
>>>============================================================
>>>
>>>
>>>
>>>
>>>    
>>>
>>
>>  
>>
>
> ------------------------------------------------------------------------
>
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
>
> Thank you.
> Tellabs
> ============================================================
>




-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================
--------------080207010105030209060601
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Adrian and all,<br>
<br>
After checking with the OIF, I understand that UNI1.0r2 has passed Straw
Ballot but<br>
not Principal Ballot. &nbsp;The value in question could be adjusted as an editorial
change before<br>
going to Principal Ballot. &nbsp;The OIF is meeting next week and UNI1.0r2 is
likely to go<br>
to Principal Ballot soon.<br>
<br>
Regards,<br>
Ben<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <title></title>
         Adrian,<br>
 <br>
 Initially OIF used the value (4) in UNI1.0. &nbsp;I do not know how this value<br>
 was chosen, or who chose it, but this is probably how it came into common 
use, since UNI<br>
 interop was done quite a while ago.<br>
 <br>
 While making minor corrections and updates to conform with IETF RFCs (since 
UNI1.0<br>
 was based on drafts) we consulted the IANA assignments and found (3), so 
that value<br>
 was used as the corrected value in UNI1.0r2.<br>
 <br>
 So, OIF has followed the official IANA assignment.<br>
 <br>
 Regards,<br>
 Ben<br>
 <br>
 Adrian Farrel wrote:<br>
 
  <blockquote type="cite" cite="mid033b01c3daed$aa9ee430$715708c3@Puppy"> 
  
    <pre wrap="">Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <a class="moz-txt-link-rfc2396E"
 href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
To: <a class="moz-txt-link-rfc2396E"
 href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments


  </pre>
   
    <blockquote type="cite">     
      <pre wrap="">To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> wrote:

    </pre>
     
      <blockquote type="cite">       
        <pre wrap="">Ditto for Tellabs (the same as Kireeti's answer).

Andy

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

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      </pre>
       
        <blockquote type="cite">         
          <pre wrap="">On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">a) do you use the FLOWSPEC C-Type 3 for CoS?
          </pre>
         </blockquote>
         
          <pre wrap="">We parse this, but don't really use it.

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
         </blockquote>
         
          <pre wrap="">Yes. Value 4.

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">c) do you use the TSPEC C-Type 3 for CoS?
          </pre>
         </blockquote>
         
          <pre wrap="">We parse this, but don't really use it.

        </pre>
         
          <blockquote type="cite">           
            <pre wrap="">d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
         </blockquote>
         
          <pre wrap="">Yes. Value 4.

Kireeti.
-------
        </pre>
       </blockquote>
       
        <pre wrap="">      </pre>
     </blockquote>
     
      <pre wrap="">
-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================




    </pre>
   </blockquote>
   
    <pre wrap=""><!---->
  </pre>
 </blockquote>
 <br>
 
  <hr size="1"> 
  <p><strong>============================================================<br>
The information contained in this message may be privileged <br>
and confidential and protected from disclosure.  If the <br>
reader of this message is not the intended recipient, or an <br>
employee or agent responsible for delivering this message to <br>
the intended recipient, you are hereby notified that any <br>
reproduction, dissemination or distribution of this <br>
communication is strictly prohibited. If you have received <br>
this communication in error, please notify us immediately by <br>
replying to the message and deleting it from your computer.<br>
  <br>
Thank you.<br>
Tellabs<br>
============================================================</strong></p>
 </blockquote>
<br>
</body>
</html>


<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------080207010105030209060601--




Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 12:23:27 +0000
Message-Id: <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: "Wijnen, Bert (Bert)" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:16:42 -0500
From: Thomas Narten <[e-mail]>

> The priority here is simple: the *IETF* has asked IANA for assignment
> of a code point; the most reasonable value of that code point *based
> on implementations of the IETF draft/RFC* is 4.

This may well be a correct statement, prior to IANA having made the
assignment. Now that they have published 3 as the "correct" value,
things are no longer so simple.

> The OIF is *not* a standards organization; for the IETF to change
> what is the right decision based on premature actions of the OIF is
> a sign of weakness.  In any case, 'signs of weakness' should NOT be
> our guiding principle -- we should do what is right and reasonable.

This is not about weakness. A fundamental property of assignments is
that they are stable and do not change. Once IANA makes an assignment,
it needs to have very very very good reasons for backing out and
making a change.

> BTW, to put this in perspective, OIF UNI1.0 uses a code point value
> of 4.  If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
> seems to me that the OIF really jumped the gun: the RFC has not been
> published and discussion of code point assignments is not complete.

Actually, the IANA assignment step and RFC publication are
different. The IANA step occurs when IANA announces its assignment
(whether via email, by posting a message, by updating their web pages,
etc.). An RFC can't be published until after IANA makes any relevant
assignments. So even though the RFC may not be out, the code point
assignment has been completed, officially.

> Perhaps the OIF can approve (as soon as we complete the discussion and
> reach the right conclusion) UNI1.0r3 with the correct value.

It would be extremely useful for someone to ask OIF about the
feasibility of this. And to comment on what other organization may
have picked up the IANA-published value at this point.

> I stand by my recommendation that IANA assign a value of 4 for the
> SDH/SONET C-Types for FLOWSPEC and TSPEC.

I think we all agree that would have been the logical assignment.
Problem is, we're past that point now and reversing an assignment is
not so simple.

Thomas



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 12:20:12 +0000
Message-Id: <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:14:50 -0500
From: Thomas Narten <[e-mail]>

> On that basis, I would strongly recommend IANA to assign 4 for both
> the C-Types of SONET/SDH TSPEC and FLOWSPEC.

Too late. IANA has already assigned 3 for that value. Given that IANA
is the authority and people may have already taken IANA's published
value (assuming it was the legit value to use) and added it to their
documents, simply changing the assignment is no longer a simple matter
anymore.

It might be possible to change this assignment if people can make a
clear case that:

 - leaving the assignment of 3 is clearly worse than changing  to 4,
   and
 - changing to 4 doesn't cause hardship and confusion for those that
   have picked up the IANA-assigned value of 3.

Thomas



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 12:19:55 +0000
Message-Id: <[e-mail]>
To: "Naidu, Venkata" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, "'Wijnen, Bert (Bert)'" <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:13:44 -0500
From: Thomas Narten <[e-mail]>

>   All I am saying is, IANA can have a guideline for long lived
>   drafts, such as:
>   
>      If there is a shipped implementation with an old deprecated
>      value, that value MUST be reserved to prevent future misuse.
>      It MUST be noted in the subsequent drafts and final RFC.

Well, a more proper way to express the above (process wise) would be
to have an IANA considerations Section (for the name space at issue)
of something like:

   values in the range 0-128 are assigned via Standards Action or
   Expert Review. The purpose of Expert Review assignments is for the
   assignment of code points in cases where the document is expected
   to become published as a standards track RFC (e.g., it is a Working
   Group document), but for which experimentation is desired before
   the RFC is published.

Tune further as appropriate. Then, when a WG needs an assignment, it
asks IANA to make the assignment, IANA checks with the expert, and
assuming the request is proper, the assignment gets made.

The point is that there are ways for the WG to retain control over
assignments that IANA is managing. That is what IANA Considerations
sections are for.

Thomas



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 12:19:43 +0000
Message-Id: <[e-mail]>
To: "Naidu, Venkata" <[e-mail]>
cc: "'Wijnen, Bert (Bert)'" <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: Re: IANA assignments 
Date: Fri, 16 Jan 2004 07:12:18 -0500
From: Thomas Narten <[e-mail]>

>   Is it possible for IANA to initiate a discussion in the mailing-list
>   before publishing a value, at least, for long lived drafts ?

Not really practical. Please see RFC 2434, where it talks about
mailing lists. Bottom line: IANA doesn't have the resources or
subject-matter expertise to read mailing list discussions and make
sense out of the diverse opinions that tend to get expressed.

But one can certainly write an IANA considerations section (again see
RFC 2434) that specifies that a Designated Expert should make the
evaluation, and one of the steps of that process could be to check
with relevant WGs first, and so forth.

WGs have a lot of flexibility in defining how they want their name
spaces managed. But IANA certainly can't guess what the right thing to
do is. That's why it's so important the authors/WGs pay attention to
IANA considerations and specify them carefully.

Thomas



Envelope-to: [e-mail]
Delivery-date: Fri, 16 Jan 2004 01:33:05 +0000
Date: Thu, 15 Jan 2004 17:30:01 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: "Thomas D. Nadeau" <[e-mail]>
CC: "'Vishal Sharma'" <[e-mail]>, [e-mail], "'CCAMP'" <[e-mail]>,  "'MPLS'" <[e-mail]>
Subject: Re: Outdated WG charters?!
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks-

 There was a problem with the IETF WG database, which the secretariat
 should have fixed. The WG web-pages are regenerated nightly, so if
 everything is fixed, we should not see any problems tomorrow.

-- 
Alex
http://www.psg.com/~zinin/

Thursday, January 15, 2004, 7:50:22 AM, Thomas D. Nadeau wrote:

>         BTW, there are other errors I noticed with
> the PWE3 and MPLS WG pages pointing at other
> out-dated drafts.  Looks like the web server
> was restored from some (really) old backups.

>         --Tom


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf 
>> Of Vishal Sharma
>> Sent: Wednesday, January 14, 2004 10:54 PM
>> To: [e-mail]
>> Cc: CCAMP; MPLS
>> Subject: Outdated WG charters?!
>> Importance: High
>> 
>> 
>> Hello,
>> 
>> It appears that the Charter updates posted by the IETF Secretariat
>> at
>> http://www.ietf.org/html.charters/wg-dir.html just this evening
>> (at least) for CCAMP and MPLS WGs are completely outdated (over
>> a year old).
>> 
>> I believe an error was made in posting these, and it would be
>> great if this could be corrected at the earliest (otherwise
>> it's very difficult to access the latest WG documents).
>> 
>> Thanks much!
>> 
>> -Vishal
>> 
>> PS: If I am the only one experiencing this problem, please let
>> me know. I've flushed all caches and buffers, so I don't think
>> the problem is at my end.
>> 




Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 16:25:55 +0000
Message-Id: <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: [e-mail], [e-mail]
cc: [e-mail]
Subject: Re: IANA assignments 
Date: Thu, 15 Jan 2004 11:23:17 -0500
From: George Swallow <[e-mail]>

> Let me start with the second issue, as it is more relevant to CCAMP.
> The responses I got unanimously state that the codepoint value used
> for SONET/SDH TSPEC and FLOWSPEC is 4.  There is a minor wrinkle here
> that in Cisco's implementation, the initial version used 4 and a later
> revision uses 3.  Apart from that, all responses (from about 10
> independent implementations, if memory serves) indicated that they use
> the value 4.

Cisco doesn't care which value is used.  We DO want the issue resolved
SOON.

> On that basis, I would strongly recommend IANA to assign 4 for both
> the C-Types of SONET/SDH TSPEC and FLOWSPEC.
> 
> The other issue, what to do with the value of 3, is less clear.  Most
> responses indicated that they either parsed and ignored or simply
> ignored this value.  As CCAMP WG chair, I don't have a stand on
> whether this value should be set aside as reserved, or left as a hole
> in the address space, to be assigned to the next request for a code
> point for a TSPEC/FLOWSPEC C-Type.

I say leave it as a hole but have a note that says it won't get assigned
until at least 2005.  (To give folks time to field versions that don't
parse this.)

...George

========================================================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719




Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 15:53:49 +0000
Message-ID: <[e-mail]>
Date: Thu, 15 Jan 2004 09:50:48 -0600
From: Ben Mack-Crane <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: "Wijnen, Bert (Bert)" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IANA assignments
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format="flowed"

Kireeti,

I don't understand how OIF "jumped the gun" by using a value from the 
IANA website,
which I understand is the authoritative source for number assignments.

Regards,
Ben

Kireeti Kompella wrote:

<snip>

>If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
>seems to me that the OIF really jumped the gun: the RFC has not been
>published and discussion of code point assignments is not complete.
>
<snip>

>
>Kireeti.
>-------
>
>  
>



-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================




Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 15:51:38 +0000
Reply-To: <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
To: "'Vishal Sharma'" <[e-mail]>, <[e-mail]>
Cc: "'CCAMP'" <[e-mail]>, "'MPLS'" <[e-mail]>
Subject: RE: Outdated WG charters?!
Date: Thu, 15 Jan 2004 10:50:22 -0500
Organization: Cisco Systems, inc.
Message-ID: <007601c3db7f$4d64d850$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

	BTW, there are other errors I noticed with
the PWE3 and MPLS WG pages pointing at other
out-dated drafts.  Looks like the web server
was restored from some (really) old backups.

	--Tom


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Vishal Sharma
> Sent: Wednesday, January 14, 2004 10:54 PM
> To: [e-mail]
> Cc: CCAMP; MPLS
> Subject: Outdated WG charters?!
> Importance: High
> 
> 
> Hello,
> 
> It appears that the Charter updates posted by the IETF Secretariat
> at
> http://www.ietf.org/html.charters/wg-dir.html just this evening
> (at least) for CCAMP and MPLS WGs are completely outdated (over
> a year old).
> 
> I believe an error was made in posting these, and it would be
> great if this could be corrected at the earliest (otherwise
> it's very difficult to access the latest WG documents).
> 
> Thanks much!
> 
> -Vishal
> 
> PS: If I am the only one experiencing this problem, please let
> me know. I've flushed all caches and buffers, so I don't think
> the problem is at my end.
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 15:22:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 15 Jan 2004 09:17:48 -0600
From: Ben Mack-Crane <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: IANA assignments
Content-Type: multipart/alternative; boundary="------------010705070204010203070609"

--------------010705070204010203070609
Content-Type: text/plain;
	charset="us-ascii";
	format="flowed"
Content-Transfer-Encoding: 7bit

Adrian,

Initially OIF used the value (4) in UNI1.0.  I do not know how this value
was chosen, or who chose it, but this is probably how it came into 
common use, since UNI
interop was done quite a while ago.

While making minor corrections and updates to conform with IETF RFCs 
(since UNI1.0
was based on drafts) we consulted the IANA assignments and found (3), so 
that value
was used as the corrected value in UNI1.0r2.

So, OIF has followed the official IANA assignment.

Regards,
Ben

Adrian Farrel wrote:

>Erm,
>Which order this happen Ben?
>
>IANA or OIF first?
>
>Thanks,
>Adrian
>----- Original Message ----- 
>From: "Ben Mack-Crane" <[e-mail]>
>To: <[e-mail]>
>Cc: <[e-mail]>
>Sent: Wednesday, January 14, 2004 4:02 PM
>Subject: Re: IANA assignments
>
>
>  
>
>>To add to Andy's factual response on Tellabs' implementations,
>>I would like to support Bert's messages on following the process
>>and also state that we are willing to update our implementation
>>to support the "right" codepoint.
>>
>>Other standards organizations depend on the stability of the
>>IANA process.  For example, the recently approved OIF UNI1.0r2 IA
>>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
>>This will be a problem if the IANA assignment is changed.
>>
>>Regards,
>>Ben Mack-Crane
>>
>>[e-mail] wrote:
>>
>>    
>>
>>>Ditto for Tellabs (the same as Kireeti's answer).
>>>
>>>Andy
>>>
>>>------------
>>>
>>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>>>
>>>      
>>>
>>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>>>>
>>>>For the record, here is the answer from Juniper's implementation:
>>>>
>>>>        
>>>>
>>>>>a) do you use the FLOWSPEC C-Type 3 for CoS?
>>>>>          
>>>>>
>>>>We parse this, but don't really use it.
>>>>
>>>>        
>>>>
>>>>>b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>>>>>   you use for the C-Type?
>>>>>          
>>>>>
>>>>Yes. Value 4.
>>>>
>>>>        
>>>>
>>>>>c) do you use the TSPEC C-Type 3 for CoS?
>>>>>          
>>>>>
>>>>We parse this, but don't really use it.
>>>>
>>>>        
>>>>
>>>>>d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>>>>>   you use for the C-Type?
>>>>>          
>>>>>
>>>>Yes. Value 4.
>>>>
>>>>Kireeti.
>>>>-------
>>>>        
>>>>
>>>      
>>>
>>
>>-----------------------------------------
>>============================================================
>>The information contained in this message may be privileged 
>>and confidential and protected from disclosure.  If the 
>>reader of this message is not the intended recipient, or an 
>>employee or agent responsible for delivering this message to 
>>the intended recipient, you are hereby notified that any 
>>reproduction, dissemination or distribution of this 
>>communication is strictly prohibited. If you have received 
>>this communication in error, please notify us immediately by 
>>replying to the message and deleting it from your computer.
>>
>>Thank you.
>>Tellabs
>>============================================================
>>
>>
>>
>>
>>    
>>
>
>  
>




-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================
--------------010705070204010203070609
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Adrian,<br>
<br>
Initially OIF used the value (4) in UNI1.0. &nbsp;I do not know how this value<br>
was chosen, or who chose it, but this is probably how it came into common
use, since UNI<br>
interop was done quite a while ago.<br>
<br>
While making minor corrections and updates to conform with IETF RFCs (since
UNI1.0<br>
was based on drafts) we consulted the IANA assignments and found (3), so
that value<br>
was used as the corrected value in UNI1.0r2.<br>
<br>
So, OIF has followed the official IANA assignment.<br>
<br>
Regards,<br>
Ben<br>
<br>
Adrian Farrel wrote:<br>
<blockquote type="cite" cite="mid033b01c3daed$aa9ee430$715708c3@Puppy">
  <pre wrap="">Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments


  </pre>
  <blockquote type="cite">
    <pre wrap="">To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Ditto for Tellabs (the same as Kireeti's answer).

Andy

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

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      </pre>
      <blockquote type="cite">
        <pre wrap="">On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        </pre>
        <blockquote type="cite">
          <pre wrap="">a) do you use the FLOWSPEC C-Type 3 for CoS?
          </pre>
        </blockquote>
        <pre wrap="">We parse this, but don't really use it.

        </pre>
        <blockquote type="cite">
          <pre wrap="">b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
        </blockquote>
        <pre wrap="">Yes. Value 4.

        </pre>
        <blockquote type="cite">
          <pre wrap="">c) do you use the TSPEC C-Type 3 for CoS?
          </pre>
        </blockquote>
        <pre wrap="">We parse this, but don't really use it.

        </pre>
        <blockquote type="cite">
          <pre wrap="">d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          </pre>
        </blockquote>
        <pre wrap="">Yes. Value 4.

Kireeti.
-------
        </pre>
      </blockquote>
      <pre wrap="">
      </pre>
    </blockquote>
    <pre wrap="">

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================




    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>


<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------010705070204010203070609--




Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 08:15:51 +0000
Date: Thu, 15 Jan 2004 00:14:14 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Wijnen, Bert (Bert)" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: RE: IANA assignments
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 15 Jan 2004, Wijnen, Bert (Bert) wrote:

> I hope you also realize that it was pointed out that OIF has assumed
> the assigned value of 3 (probably because IANA had assigned it and
> published it on the iana web pages... Adrian has asked the question
> if it is indeed so or not). So if IANA changes it, it may be perceived
> by outside world as a weakness. Not sure it is.. but we should check
> (or so I think... IANA pls let us know what you think about this).

I do realize that.

The priority here is simple: the *IETF* has asked IANA for assignment
of a code point; the most reasonable value of that code point *based
on implementations of the IETF draft/RFC* is 4.  The OIF is *not* a
standards organization; for the IETF to change what is the right
decision based on premature actions of the OIF is a sign of weakness.
In any case, 'signs of weakness' should NOT be our guiding principle
-- we should do what is right and reasonable.

BTW, to put this in perspective, OIF UNI1.0 uses a code point value
of 4.  If the value of 3 was 'approved' by the OIF for UNI1.0r2, it
seems to me that the OIF really jumped the gun: the RFC has not been
published and discussion of code point assignments is not complete.
Perhaps the OIF can approve (as soon as we complete the discussion and
reach the right conclusion) UNI1.0r3 with the correct value.  Note
that many participants in the CCAMP mailing list have implemented OIF
UNI1.0, and I have not heard that we should change the value to 3; in
fact, Tellabs' own implementation uses 4 today.

I stand by my recommendation that IANA assign a value of 4 for the
SDH/SONET C-Types for FLOWSPEC and TSPEC.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 06:20:35 +0000
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: IANA assignments
Date: Thu, 15 Jan 2004 07:18:23 +0100
MIME-Version: 1.0
Content-Type: text/plain

> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
> 
> > a) do you use the FLOWSPEC C-Type 3 for CoS?
> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, 
> what value did
> >    you use for the C-Type?
> > c) do you use the TSPEC C-Type 3 for CoS?
> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
> >    you use for the C-Type?
> 
> There are two issues at hand:
>  i) what should be done about the codepoint value of 3? and
> ii) what value should be assigned for the SONET/SDH TSPEC and 
> FLOWSPEC?
> 
> Let me start with the second issue, as it is more relevant to CCAMP.
> The responses I got unanimously state that the codepoint value used
> for SONET/SDH TSPEC and FLOWSPEC is 4.  There is a minor wrinkle here
> that in Cisco's implementation, the initial version used 4 and a later
> revision uses 3.  Apart from that, all responses (from about 10
> independent implementations, if memory serves) indicated that they use
> the value 4.
> 
> On that basis, I would strongly recommend IANA to assign 4 for both
> the C-Types of SONET/SDH TSPEC and FLOWSPEC.
> 
I hope you also realize that it was pointed out that OIF has assumed 
the assigned value of 3 (probably because IANA had assigned it and 
published it on the iana web pages... Adrian has asked the question
if it is indeed so or not). So if IANA changes it, it may be perceived
by outside world as a weakness. Not sure it is.. but we should check
(or so I think... IANA pls let us know what you think about this).

Bert



Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 03:55:06 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "CCAMP" <[e-mail]>, "MPLS" <[e-mail]>
Subject: Outdated WG charters?!
Date: Wed, 14 Jan 2004 19:53:47 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

It appears that the Charter updates posted by the IETF Secretariat
at
http://www.ietf.org/html.charters/wg-dir.html just this evening
(at least) for CCAMP and MPLS WGs are completely outdated (over
a year old).

I believe an error was made in posting these, and it would be
great if this could be corrected at the earliest (otherwise
it's very difficult to access the latest WG documents).

Thanks much!

-Vishal

PS: If I am the only one experiencing this problem, please let
me know. I've flushed all caches and buffers, so I don't think
the problem is at my end.



Envelope-to: [e-mail]
Delivery-date: Thu, 15 Jan 2004 03:15:20 +0000
Date: Wed, 14 Jan 2004 19:13:22 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: RE: IANA assignments
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi All,

On Fri, 9 Jan 2004, Kireeti Kompella wrote:

> a) do you use the FLOWSPEC C-Type 3 for CoS?
> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?
> c) do you use the TSPEC C-Type 3 for CoS?
> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

There are two issues at hand:
 i) what should be done about the codepoint value of 3? and
ii) what value should be assigned for the SONET/SDH TSPEC and FLOWSPEC?

Let me start with the second issue, as it is more relevant to CCAMP.
The responses I got unanimously state that the codepoint value used
for SONET/SDH TSPEC and FLOWSPEC is 4.  There is a minor wrinkle here
that in Cisco's implementation, the initial version used 4 and a later
revision uses 3.  Apart from that, all responses (from about 10
independent implementations, if memory serves) indicated that they use
the value 4.

On that basis, I would strongly recommend IANA to assign 4 for both
the C-Types of SONET/SDH TSPEC and FLOWSPEC.

The other issue, what to do with the value of 3, is less clear.  Most
responses indicated that they either parsed and ignored or simply
ignored this value.  As CCAMP WG chair, I don't have a stand on
whether this value should be set aside as reserved, or left as a hole
in the address space, to be assigned to the next request for a code
point for a TSPEC/FLOWSPEC C-Type.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2004 22:28:38 +0000
Message-ID: <033b01c3daed$aa9ee430$715708c3@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ben Mack-Crane" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: IANA assignments
Date: Wed, 14 Jan 2004 22:27:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments


> To add to Andy's factual response on Tellabs' implementations,
> I would like to support Bert's messages on following the process
> and also state that we are willing to update our implementation
> to support the "right" codepoint.
> 
> Other standards organizations depend on the stability of the
> IANA process.  For example, the recently approved OIF UNI1.0r2 IA
> specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
> This will be a problem if the IANA assignment is changed.
> 
> Regards,
> Ben Mack-Crane
> 
> [e-mail] wrote:
> 
> > Ditto for Tellabs (the same as Kireeti's answer).
> >
> > Andy
> >
> > ------------
> >
> > At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
> >
> >> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
> >>
> >> For the record, here is the answer from Juniper's implementation:
> >>
> >> > a) do you use the FLOWSPEC C-Type 3 for CoS?
> >>
> >> We parse this, but don't really use it.
> >>
> >> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
> >> >    you use for the C-Type?
> >>
> >> Yes. Value 4.
> >>
> >> > c) do you use the TSPEC C-Type 3 for CoS?
> >>
> >> We parse this, but don't really use it.
> >>
> >> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
> >> >    you use for the C-Type?
> >>
> >> Yes. Value 4.
> >>
> >> Kireeti.
> >> -------
> >
> >
> 
> 
> 
> -----------------------------------------
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2004 22:27:21 +0000
Message-ID: <033801c3daed$7c458120$715708c3@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: RFC3473
Date: Wed, 14 Jan 2004 22:26:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi M,

I see the following in RFC3473...

2.3. Generalized Label Object

   The format of a Generalized Label object 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class-Num (16)|   C-Type (2)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Label                             |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See [RFC3471] for a description of parameters and encoding of labels.


Looks like a C-Num and a C-Type from where I'm standing.

Cheers,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, January 14, 2004 4:35 PM
Subject: RFC3473


> Hi, I was reading the RFC 3473 and observed that Class-Num and C-Type in label were not
specified and it gives only reference to the RFC 3471 but there are no definition of
Class-Num or C-Type defined in RFC 3471.
>
> So what is Class-Num and C-Type?
>
> M
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2004 22:24:07 +0000
Message-ID: <032c01c3daec$eec4d580$715708c3@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, <[e-mail]>
Subject: Temporary Registy for LSP-ATTRIBUTE flags
Date: Wed, 14 Jan 2004 13:20:29 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have created a temporary registry for flags in the new LSP Attribute Flags TLV and RRO
Attribute Flags RRO subobject as defined in draft-ietf-mpls-rsvpte-attributes.

Please note that this is a temporary and provisional registry. It does not replace the
IANA registration of these flags. Implementers are advised that an entry in this temporary
registry does not guarantee the use of a particular bit in the final RFC.

This registry does provide a place to register provisional bit assignments so that
experimental implementations may hope to interwork and so that new Internet Drafts may
suggest bit numbers that do not conflict.

You can reach the registry at http://www.olddog.co.uk/lsp-attrib.txt

If it would help you to have your bit-usage registered, please send me your registration
requests.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2004 16:36:24 +0000
From: <[e-mail]>
Reply-To: [e-mail]
To: <[e-mail]>
Subject: RFC3473
Date: Wed, 14 Jan 2004 17:35:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <20040114163506.XUDS10991.amsfep18-int.chello.nl@localhost>

Hi, I was reading the RFC 3473 and observed that Class-Num and C-Type in label were not specified and it gives only reference to the RFC 3471 but there are no definition of Class-Num or C-Type defined in RFC 3471.

So what is Class-Num and C-Type?

M 




Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2004 16:09:46 +0000
Message-ID: <[e-mail]>
Date: Wed, 14 Jan 2004 10:02:14 -0600
From: Ben Mack-Crane <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: IANA assignments
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format="flowed"

To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

[e-mail] wrote:

> Ditto for Tellabs (the same as Kireeti's answer).
>
> Andy
>
> ------------
>
> At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>
>> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>>
>> For the record, here is the answer from Juniper's implementation:
>>
>> > a) do you use the FLOWSPEC C-Type 3 for CoS?
>>
>> We parse this, but don't really use it.
>>
>> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>> >    you use for the C-Type?
>>
>> Yes. Value 4.
>>
>> > c) do you use the TSPEC C-Type 3 for CoS?
>>
>> We parse this, but don't really use it.
>>
>> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>> >    you use for the C-Type?
>>
>> Yes. Value 4.
>>
>> Kireeti.
>> -------
>
>



-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================




Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jan 2004 19:40:14 +0000
Message-Id: <[e-mail]>
Date: Tue, 13 Jan 2004 14:04:00 -0500
To: [e-mail]
From: "Andrew G. Malis" <[e-mail]>
Subject: RE: IANA assignments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Ditto for Tellabs (the same as Kireeti's answer).

Andy

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

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:
>On Fri, 9 Jan 2004, Kireeti Kompella wrote:
>
>For the record, here is the answer from Juniper's implementation:
>
> > a) do you use the FLOWSPEC C-Type 3 for CoS?
>
>We parse this, but don't really use it.
>
> > b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
> >    you use for the C-Type?
>
>Yes. Value 4.
>
> > c) do you use the TSPEC C-Type 3 for CoS?
>
>We parse this, but don't really use it.
>
> > d) have you implemented the SONET/SDH TSPEC?  If so, what value did
> >    you use for the C-Type?
>
>Yes. Value 4.
>
>Kireeti.
>-------



Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jan 2004 18:38:42 +0000
Message-Id: <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: [e-mail], [e-mail]
cc: [e-mail]
Subject: Re: IANA assignments 
Date: Tue, 13 Jan 2004 13:36:25 -0500
From: George Swallow <[e-mail]>

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
> 
> a) do you use the FLOWSPEC C-Type 3 for CoS?

No.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

Yes,  The initial release used 4.  We have an updated release that uses 3.

> c) do you use the TSPEC C-Type 3 for CoS?

No,

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

Yes,  The initial release used 4.  We have an updated release that uses 3.

> Please send your answers to the mailing list or to the chairs AND ADs
> at the latest by Wed Jan 14, 2004, 5pm PST.

...George

========================================================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719




Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jan 2004 15:25:35 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
Date: Tue, 13 Jan 2004 07:22:58 -0800
Message-ID: <[e-mail]>
Thread-Topic: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
thread-index: AcPWCY/ydztsK/XzQI+bP4OvcrnVogD3aLxQ
From: "Jonathan Lang" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

All,
  The following typo has been pointed out in
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt and will be fixed during
AUTH48.

"0x0080 J2-trace: J2 Section Trace Correlation

                 Capable of transmitting SONET/SDH VT SPE/LOVC Path
                 trace over J2 Path overhead byte as defined in [T1.105]
                 and [G.707]."

should read

"0x0080 J2-trace: J2 Path Trace Correlation

                 Capable of transmitting SONET/SDH VT SPE/LOVC Path
                 trace over J2 Path overhead byte as defined in [T1.105]
                 and [G.707]."

Thanks,
Jonathan





Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jan 2004 03:14:23 +0000
Message-ID: <1037EB10994D094790FC003F87DCC0BC024D3865@pine>
From: "Pandian, Vijay" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
Date: Mon, 12 Jan 2004 22:10:37 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

	Hi,

	In section 1.4, the Switching Capability-specific information is
described for all types of switching capabilities except for FSC. 

	I assume there is no Switching Capability specific information
present for FSC. Please clarify.

	Regards,

	Vijay





Envelope-to: [e-mail]
Delivery-date: Tue, 13 Jan 2004 03:11:04 +0000
Message-ID: <1037EB10994D094790FC003F87DCC0BC024D3864@pine>
From: "Pandian, Vijay" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
Date: Mon, 12 Jan 2004 22:05:12 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi,

In section 1.4, the Switching Capability-specific information is not
described for all types of switching capabilities except for FSC. 

I assume there is no Switching Capability specific information present for
FSC. Please clarify.

Regards,

Vijay




Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jan 2004 10:39:30 +0000
Message-ID: <[e-mail]>
Date: Mon, 12 Jan 2004 11:39:29 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: draft-ietf-mpls-lsp-hierarchy-08
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

diego, the document is in the RFC Editor queue (per i-d
status tracker) since nov'02 - thanks, d.

Diego Caviglia wrote:

> Hi all,
>               the ID in the subject expired in March 2002 is there any
> intention to go on with work on FA?
> 
> IMHO that was a good and very usefull work.
> 
> Regards.
> 
> Diego
> 
> 
> 
> ------------------------------------------
> Diego Caviglia
> Marconi - Optical Networks
> ASTN/GMPLS - System Design Manager
> Via A. Negrone 1/A
> 16153 Genoa - Italy
> Phone: [phone]
> 
> "Timeo Danae et Dona Ferentes"
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Mon, 12 Jan 2004 09:27:35 +0000
Sensitivity: 
Subject: draft-ietf-mpls-lsp-hierarchy-08
To: [e-mail]
Cc: [e-mail]
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 12 Jan 2004 10:25:10 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"

Hi all,
              the ID in the subject expired in March 2002 is there any
intention to go on with work on FA?

IMHO that was a good and very usefull work.

Regards.

Diego



------------------------------------------
Diego Caviglia
Marconi - Optical Networks
ASTN/GMPLS - System Design Manager
Via A. Negrone 1/A
16153 Genoa - Italy
Phone: [phone]

"Timeo Danae et Dona Ferentes"





Envelope-to: [e-mail]
Delivery-date: Sun, 11 Jan 2004 20:44:55 +0000
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: David Charlap <[e-mail]>, IETF CCAMP List <[e-mail]>
Subject: RE: IANA assignments
Date: Sun, 11 Jan 2004 21:39:18 +0100
MIME-Version: 1.0
Content-Type: text/plain

Maybe... it might be good if people who have used
un-reserved values for implementing ID-level specifications
take a look at draft-narten-iana-experimental-allocations-05.txt
and specifically section 1.1. It is only a page long that section.

It explains why doing such things might be bad.

Thanks,
Bert 



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 22:08:36 +0000
Message-ID: <[e-mail]>
Date: Fri, 09 Jan 2004 23:08:08 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: IANA assignments
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

kireeti, historically value 4 has been considered for the
TSPEC/FLOWSPEC, so this value has been used for our main
implementation (started before the official IANA value
assignment)

note: it would be of interest to reach rapidly agreement
on this since from my side any development initiated/
started after this consider the use the value assigned by
IANA

thanks,
- dimitri.

Kireeti Kompella wrote:
> On Fri, 9 Jan 2004, Kireeti Kompella wrote:
> 
> 
>>Okay, in order to come to some conclusion here, those of you who have
>>implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
> 
> 
> <WG chair hat OFF>
> 
> For the record, here is the answer from Juniper's implementation:
> 
> 
>>a) do you use the FLOWSPEC C-Type 3 for CoS?
> 
> 
> We parse this, but don't really use it.
> 
> 
>>b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>>   you use for the C-Type?
> 
> 
> Yes. Value 4.
> 
> 
>>c) do you use the TSPEC C-Type 3 for CoS?
> 
> 
> We parse this, but don't really use it.
> 
> 
>>d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>>   you use for the C-Type?
> 
> 
> Yes. Value 4.
> 
> Kireeti.
> -------
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 20:33:11 +0000
Message-ID: <[e-mail]>
Date: Fri, 09 Jan 2004 15:34:03 -0500
From: David Charlap <[e-mail]>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: IETF CCAMP List <[e-mail]>
Subject: RE: IANA assignments
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kireeti Kompella wrote:
> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

This is for Marconi's RSVP-TE implementation.

> a) do you use the FLOWSPEC C-Type 3 for CoS?

Yes - for interoperability with other vendors that required it in the
recent past and might still require it.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

Not at this time.

> c) do you use the TSPEC C-Type 3 for CoS?

Yes - for interoperability.

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

Not at this time.

> Please send your answers to the mailing list or to the chairs AND ADs
> at the latest by Wed Jan 14, 2004, 5pm PST.






Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 20:26:20 +0000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: IANA assignments 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Jan 2004 15:25:12 -0500
From: Markus Jork <[e-mail]>

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
> 
> a) do you use the FLOWSPEC C-Type 3 for CoS?

Yes. It's implemented but not being used. We already thought about
taking the code out in future releases.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

yes, 4

> c) do you use the TSPEC C-Type 3 for CoS?

yes (plus same comment as in a)

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

yes, 4

Markus





Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 20:00:25 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>, [e-mail]
Subject: RE: IANA assignments
Date: Fri, 9 Jan 2004 11:59:28 -0800 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Kireeti,

We assume 3 for CoS (but have not used it so far)
and 4 for SONET/SDH FLOWSPEC/TSPEC.

Cheers,

Lyndon (Ciena)

-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Friday, January 09, 2004 10:34 AM
To: [e-mail]
Cc: [e-mail]
Subject: RE: IANA assignments


Okay, in order to come to some conclusion here, those of you who have
implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

a) do you use the FLOWSPEC C-Type 3 for CoS?
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
c) do you use the TSPEC C-Type 3 for CoS?
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?

Please send your answers to the mailing list or to the chairs AND ADs
at the latest by Wed Jan 14, 2004, 5pm PST.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 19:50:26 +0000
Date: Fri, 9 Jan 2004 11:49:53 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: RE: IANA assignments
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 9 Jan 2004, Kireeti Kompella wrote:

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:
...
> Please send your answers to the mailing list or to the chairs AND ADs
> at the latest by Wed Jan 14, 2004, 5pm PST.

Please don't copy IANA on the replies -- the chairs will summarize the
results and conclusions to IANA.

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 19:49:37 +0000
Date: Fri, 9 Jan 2004 11:48:49 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: RE: IANA assignments
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 9 Jan 2004, Kireeti Kompella wrote:

> Okay, in order to come to some conclusion here, those of you who have
> implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

<WG chair hat OFF>

For the record, here is the answer from Juniper's implementation:

> a) do you use the FLOWSPEC C-Type 3 for CoS?

We parse this, but don't really use it.

> b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
>    you use for the C-Type?

Yes. Value 4.

> c) do you use the TSPEC C-Type 3 for CoS?

We parse this, but don't really use it.

> d) have you implemented the SONET/SDH TSPEC?  If so, what value did
>    you use for the C-Type?

Yes. Value 4.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 19:37:34 +0000
Message-ID: <[e-mail]>
Date: Fri, 09 Jan 2004 20:37:18 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: rick king <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

thanks, i encourage the ccamp community to share any
feedback they think relevant to make progress with
this wg i-d and reach consensus toward a second rev.
of this document (that i hope will be ready for last
call, as expected)

thanks,
- dimitri.

rick king wrote:
> I think it's better now. Thank you for your kindly clarifying.
> 
> Rick
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, January 09, 2004 7:34 AM
> To: rick king
> Cc: [e-mail]
> Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
> 
> 
> the RA represents a partition of the data plane and is used as the 
> representation of the data plane within the control plane, in the
> next revision will include a statement on this since this may be
> where the mis-understanding comes from, wrt to relationship with
> the RC, the text will be clarified from:
> 
>    " - A RA MAY support different routing protocols. There SHOULD NOT be
>        any dependencies on the different routing protocols used.
>      - For a RA, the cluster of RCs is referred to as a routing domain.
>        The routing information exchanged between routing domains (i.e.
>        inter-domain) is independent of both the intra-domain routing
>        protocol and the intra-domain control distribution choice(s), e.g.
>        centralized, fully distributed."
> 
> to:
> 
>     "- For a RA, the cluster of RCs is referred to as a routing (control)
>        domain. The RC MAY support more than one routing protocol. There
>        SHOULD NOT be any dependencies on the different routing protocols
>        used.
>      - The routing information exchanged between routing domains (i.e.
>        inter-domain) is independent of both the intra-domain routing
>        protocol and the intra-domain control distribution choice(s), e.g.
>        centralized, fully distributed."
> 
> well hope this clarifies,
> - dimitri.
> 
> rick king wrote:
> 
> 
>>Then what's relationship between a RA and a routing control domain?
>>
>>thanks
>>
>>Rick
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On Behalf Of [e-mail]
>>Sent: Wednesday, January 07, 2004 6:57 AM
>>To: rick king
>>Cc: [e-mail]
>>Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
>>
>>
>>hi, thanks for commenting, see in-line:
>>
>>rick king wrote:
>>
>>
>>
>>>Some comments. Section 3.   ......The  ASON model allows for the protocols
>>>used within different control domains to be different; and for the protocol
>>>used between control domains to be different than the protocols used within
>>>control domains. ......
>>>
>>>The routing requirements contained in this draft apply to protocols used
>>>between control domains(E-NNI routing) or protocols used within control
>>>domains(I-NNI routing) or both?
>>
>>
>>-> both
>>
>>
>>
>>>...... - For a RA, the cluster of RCs is referred to as a routing
>>>domain......
>>>
>>>Does this means that RA=routing domain? Maybe routing control domain is more
>>>align with G.7715.
>>
>>
>>-> yes, it is "routing (control) domain", we will clarify in the
>>    next version
>>
>>
>>
>>>Section 4.2.1    ......   - The second approach places the Level N routing
>>>function on a separate system from the Level N+1 routing function. In this 
>>>case, a communication interface must be used between the systems containing
>>>the routing functions for different levels. This communication interface and
>>>mechanisms are outside the scope of this document. .......
>>>
>>>Is it possible that the Level N routing function and  the Level N+1 routing
>>>function are from different vendors? If the answer is yes, then I think the
>>>communication interface and mechanisms should be defined. Otherwise how can
>>>you achieve inter-operate?
>>
>>
>>-> it is expected to cover multi-vendor case (note that the other
>>    alternative is single vendor only) so that this "communication
>>    interface" is expected to be defined but it is not within the
>>    scope of this document, what's within the scope is the routing
>>    information exchanged (ie ways to achieve the communication
>>    interface between these systems is not)
>>
>>thanks,
>>- dimitri.
>>
>>
>>
>>>Thank you.
>>>
>>>rick
>>>
>>>-----Original Message----- From: [e-mail]
>>>[mailto:[e-mail]]On Behalf Of
>>>[e-mail] Sent: Tuesday, December 30, 2003 5:19 AM To:
>>>[e-mail] Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
>>>
>>>
>>>all,
>>>
>>>the following version of the "ASON routing requirements" document completes
>>>the template proposed in the v00.txt:
>>>
>>><http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
>>>
>>>
>>>please provide any comment you think relevant in order to progress this wg
>>>i-d
>>>
>>>thanks, - dimitri.
>>>
>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 18:35:56 +0000
Date: Fri, 9 Jan 2004 10:34:16 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: RE: IANA assignments
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Okay, in order to come to some conclusion here, those of you who have
implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following:

a) do you use the FLOWSPEC C-Type 3 for CoS?
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
c) do you use the TSPEC C-Type 3 for CoS?
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?

Please send your answers to the mailing list or to the chairs AND ADs
at the latest by Wed Jan 14, 2004, 5pm PST.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 09 Jan 2004 04:56:37 +0000
From: "rick king" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Date: Fri, 9 Jan 2004 12:53:23 +0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64

SSB0aGluayBpdCdzIGJldHRlciBub3cuIFRoYW5rIHlvdSBmb3IgeW91ciBraW5kbHkgY2xhcmlm
eWluZy4NCg0KUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGltaXRy
aS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgW21haWx0bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VA
YWxjYXRlbC5iZV0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAwOSwgMjAwNCA3OjM0IEFNDQpUbzog
cmljayBraW5nDQpDYzogY2NhbXBAb3BzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDEudHh0DQoNCg0KdGhlIFJBIHJlcHJl
c2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5kIGlzIHVzZWQgYXMgdGhlIA0K
cmVwcmVzZW50YXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgd2l0aGluIHRoZSBjb250cm9sIHBsYW5l
LCBpbiB0aGUNCm5leHQgcmV2aXNpb24gd2lsbCBpbmNsdWRlIGEgc3RhdGVtZW50IG9uIHRoaXMg
c2luY2UgdGhpcyBtYXkgYmUNCndoZXJlIHRoZSBtaXMtdW5kZXJzdGFuZGluZyBjb21lcyBmcm9t
LCB3cnQgdG8gcmVsYXRpb25zaGlwIHdpdGgNCnRoZSBSQywgdGhlIHRleHQgd2lsbCBiZSBjbGFy
aWZpZWQgZnJvbToNCg0KICAgIiAtIEEgUkEgTUFZIHN1cHBvcnQgZGlmZmVyZW50IHJvdXRpbmcg
cHJvdG9jb2xzLiBUaGVyZSBTSE9VTEQgTk9UIGJlDQogICAgICAgYW55IGRlcGVuZGVuY2llcyBv
biB0aGUgZGlmZmVyZW50IHJvdXRpbmcgcHJvdG9jb2xzIHVzZWQuDQogICAgIC0gRm9yIGEgUkEs
IHRoZSBjbHVzdGVyIG9mIFJDcyBpcyByZWZlcnJlZCB0byBhcyBhIHJvdXRpbmcgZG9tYWluLg0K
ICAgICAgIFRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIHJvdXRpbmcg
ZG9tYWlucyAoaS5lLg0KICAgICAgIGludGVyLWRvbWFpbikgaXMgaW5kZXBlbmRlbnQgb2YgYm90
aCB0aGUgaW50cmEtZG9tYWluIHJvdXRpbmcNCiAgICAgICBwcm90b2NvbCBhbmQgdGhlIGludHJh
LWRvbWFpbiBjb250cm9sIGRpc3RyaWJ1dGlvbiBjaG9pY2UocyksIGUuZy4NCiAgICAgICBjZW50
cmFsaXplZCwgZnVsbHkgZGlzdHJpYnV0ZWQuIg0KDQp0bzoNCg0KICAgICItIEZvciBhIFJBLCB0
aGUgY2x1c3RlciBvZiBSQ3MgaXMgcmVmZXJyZWQgdG8gYXMgYSByb3V0aW5nIChjb250cm9sKQ0K
ICAgICAgIGRvbWFpbi4gVGhlIFJDIE1BWSBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgcm91dGluZyBw
cm90b2NvbC4gVGhlcmUNCiAgICAgICBTSE9VTEQgTk9UIGJlIGFueSBkZXBlbmRlbmNpZXMgb24g
dGhlIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scw0KICAgICAgIHVzZWQuDQogICAgIC0gVGhl
IHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGJldHdlZW4gcm91dGluZyBkb21haW5zIChp
LmUuDQogICAgICAgaW50ZXItZG9tYWluKSBpcyBpbmRlcGVuZGVudCBvZiBib3RoIHRoZSBpbnRy
YS1kb21haW4gcm91dGluZw0KICAgICAgIHByb3RvY29sIGFuZCB0aGUgaW50cmEtZG9tYWluIGNv
bnRyb2wgZGlzdHJpYnV0aW9uIGNob2ljZShzKSwgZS5nLg0KICAgICAgIGNlbnRyYWxpemVkLCBm
dWxseSBkaXN0cmlidXRlZC4iDQoNCndlbGwgaG9wZSB0aGlzIGNsYXJpZmllcywNCi0gZGltaXRy
aS4NCg0KcmljayBraW5nIHdyb3RlOg0KDQo+IFRoZW4gd2hhdCdzIHJlbGF0aW9uc2hpcCBiZXR3
ZWVuIGEgUkEgYW5kIGEgcm91dGluZyBjb250cm9sIGRvbWFpbj8NCj4gDQo+IHRoYW5rcw0KPiAN
Cj4gUmljaw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXIt
Y2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXU9uIEJl
aGFsZiBPZiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0KPiBTZW50OiBXZWRuZXNk
YXksIEphbnVhcnkgMDcsIDIwMDQgNjo1NyBBTQ0KPiBUbzogcmljayBraW5nDQo+IENjOiBjY2Ft
cEBvcHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNv
bi1yb3V0aW5nLXJlcXRzLTAxLnR4dA0KPiANCj4gDQo+IGhpLCB0aGFua3MgZm9yIGNvbW1lbnRp
bmcsIHNlZSBpbi1saW5lOg0KPiANCj4gcmljayBraW5nIHdyb3RlOg0KPiANCj4gDQo+PlNvbWUg
Y29tbWVudHMuIFNlY3Rpb24gMy4gICAuLi4uLi5UaGUgIEFTT04gbW9kZWwgYWxsb3dzIGZvciB0
aGUgcHJvdG9jb2xzDQo+PnVzZWQgd2l0aGluIGRpZmZlcmVudCBjb250cm9sIGRvbWFpbnMgdG8g
YmUgZGlmZmVyZW50OyBhbmQgZm9yIHRoZSBwcm90b2NvbA0KPj51c2VkIGJldHdlZW4gY29udHJv
bCBkb21haW5zIHRvIGJlIGRpZmZlcmVudCB0aGFuIHRoZSBwcm90b2NvbHMgdXNlZCB3aXRoaW4N
Cj4+Y29udHJvbCBkb21haW5zLiAuLi4uLi4NCj4+DQo+PlRoZSByb3V0aW5nIHJlcXVpcmVtZW50
cyBjb250YWluZWQgaW4gdGhpcyBkcmFmdCBhcHBseSB0byBwcm90b2NvbHMgdXNlZA0KPj5iZXR3
ZWVuIGNvbnRyb2wgZG9tYWlucyhFLU5OSSByb3V0aW5nKSBvciBwcm90b2NvbHMgdXNlZCB3aXRo
aW4gY29udHJvbA0KPj5kb21haW5zKEktTk5JIHJvdXRpbmcpIG9yIGJvdGg/DQo+IA0KPiANCj4g
LT4gYm90aA0KPiANCj4gDQo+Pi4uLi4uLiAtIEZvciBhIFJBLCB0aGUgY2x1c3RlciBvZiBSQ3Mg
aXMgcmVmZXJyZWQgdG8gYXMgYSByb3V0aW5nDQo+PmRvbWFpbi4uLi4uLg0KPj4NCj4+RG9lcyB0
aGlzIG1lYW5zIHRoYXQgUkE9cm91dGluZyBkb21haW4/IE1heWJlIHJvdXRpbmcgY29udHJvbCBk
b21haW4gaXMgbW9yZQ0KPj5hbGlnbiB3aXRoIEcuNzcxNS4NCj4gDQo+IA0KPiAtPiB5ZXMsIGl0
IGlzICJyb3V0aW5nIChjb250cm9sKSBkb21haW4iLCB3ZSB3aWxsIGNsYXJpZnkgaW4gdGhlDQo+
ICAgICBuZXh0IHZlcnNpb24NCj4gDQo+IA0KPj5TZWN0aW9uIDQuMi4xICAgIC4uLi4uLiAgIC0g
VGhlIHNlY29uZCBhcHByb2FjaCBwbGFjZXMgdGhlIExldmVsIE4gcm91dGluZw0KPj5mdW5jdGlv
biBvbiBhIHNlcGFyYXRlIHN5c3RlbSBmcm9tIHRoZSBMZXZlbCBOKzEgcm91dGluZyBmdW5jdGlv
bi4gSW4gdGhpcyANCj4+Y2FzZSwgYSBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBtdXN0IGJlIHVz
ZWQgYmV0d2VlbiB0aGUgc3lzdGVtcyBjb250YWluaW5nDQo+PnRoZSByb3V0aW5nIGZ1bmN0aW9u
cyBmb3IgZGlmZmVyZW50IGxldmVscy4gVGhpcyBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBhbmQN
Cj4+bWVjaGFuaXNtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gLi4u
Li4uLg0KPj4NCj4+SXMgaXQgcG9zc2libGUgdGhhdCB0aGUgTGV2ZWwgTiByb3V0aW5nIGZ1bmN0
aW9uIGFuZCAgdGhlIExldmVsIE4rMSByb3V0aW5nDQo+PmZ1bmN0aW9uIGFyZSBmcm9tIGRpZmZl
cmVudCB2ZW5kb3JzPyBJZiB0aGUgYW5zd2VyIGlzIHllcywgdGhlbiBJIHRoaW5rIHRoZQ0KPj5j
b21tdW5pY2F0aW9uIGludGVyZmFjZSBhbmQgbWVjaGFuaXNtcyBzaG91bGQgYmUgZGVmaW5lZC4g
T3RoZXJ3aXNlIGhvdyBjYW4NCj4+eW91IGFjaGlldmUgaW50ZXItb3BlcmF0ZT8NCj4gDQo+IA0K
PiAtPiBpdCBpcyBleHBlY3RlZCB0byBjb3ZlciBtdWx0aS12ZW5kb3IgY2FzZSAobm90ZSB0aGF0
IHRoZSBvdGhlcg0KPiAgICAgYWx0ZXJuYXRpdmUgaXMgc2luZ2xlIHZlbmRvciBvbmx5KSBzbyB0
aGF0IHRoaXMgImNvbW11bmljYXRpb24NCj4gICAgIGludGVyZmFjZSIgaXMgZXhwZWN0ZWQgdG8g
YmUgZGVmaW5lZCBidXQgaXQgaXMgbm90IHdpdGhpbiB0aGUNCj4gICAgIHNjb3BlIG9mIHRoaXMg
ZG9jdW1lbnQsIHdoYXQncyB3aXRoaW4gdGhlIHNjb3BlIGlzIHRoZSByb3V0aW5nDQo+ICAgICBp
bmZvcm1hdGlvbiBleGNoYW5nZWQgKGllIHdheXMgdG8gYWNoaWV2ZSB0aGUgY29tbXVuaWNhdGlv
bg0KPiAgICAgaW50ZXJmYWNlIGJldHdlZW4gdGhlc2Ugc3lzdGVtcyBpcyBub3QpDQo+IA0KPiB0
aGFua3MsDQo+IC0gZGltaXRyaS4NCj4gDQo+IA0KPj5UaGFuayB5b3UuDQo+Pg0KPj5yaWNrDQo+
Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0
Zi5vcmcNCj4+W21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+
PkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlIFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy
IDMwLCAyMDAzIDU6MTkgQU0gVG86DQo+PmNjYW1wQG9wcy5pZXRmLm9yZyBTdWJqZWN0OiBkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMS50eHQNCj4+DQo+Pg0KPj5h
bGwsDQo+Pg0KPj50aGUgZm9sbG93aW5nIHZlcnNpb24gb2YgdGhlICJBU09OIHJvdXRpbmcgcmVx
dWlyZW1lbnRzIiBkb2N1bWVudCBjb21wbGV0ZXMNCj4+dGhlIHRlbXBsYXRlIHByb3Bvc2VkIGlu
IHRoZSB2MDAudHh0Og0KPj4NCj4+PGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAxLnR4dD4NCj4+DQo+
Pg0KPj5wbGVhc2UgcHJvdmlkZSBhbnkgY29tbWVudCB5b3UgdGhpbmsgcmVsZXZhbnQgaW4gb3Jk
ZXIgdG8gcHJvZ3Jlc3MgdGhpcyB3Zw0KPj5pLWQNCj4+DQo+PnRoYW5rcywgLSBkaW1pdHJpLg0K
Pj4NCj4gDQo+IA0KDQotLSANClBhcGFkaW1pdHJpb3UgRGltaXRyaQ0KRS1tYWlsIDogZGltaXRy
aS5wYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCkUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBzZy5j
b20NCldlYnBhZ2U6IGh0dHA6Ly9wc2cuY29tL35kcGFwYWRpbWl0cmlvdS8NCkFkZHJlc3M6IEZy
LiBXZWxsZXNwbGVpbiAxLCBCLTIwMTggQW50d2VycGVuLCBCZWxnaXVtDQpQaG9uZSAgOiArMzIg
MyAyNDAtODQ5MQ0K





Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 23:33:53 +0000
Message-ID: <[e-mail]>
Date: Fri, 09 Jan 2004 00:33:30 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: rick king <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

the RA represents a partition of the data plane and is used as the 
representation of the data plane within the control plane, in the
next revision will include a statement on this since this may be
where the mis-understanding comes from, wrt to relationship with
the RC, the text will be clarified from:

   " - A RA MAY support different routing protocols. There SHOULD NOT be
       any dependencies on the different routing protocols used.
     - For a RA, the cluster of RCs is referred to as a routing domain.
       The routing information exchanged between routing domains (i.e.
       inter-domain) is independent of both the intra-domain routing
       protocol and the intra-domain control distribution choice(s), e.g.
       centralized, fully distributed."

to:

    "- For a RA, the cluster of RCs is referred to as a routing (control)
       domain. The RC MAY support more than one routing protocol. There
       SHOULD NOT be any dependencies on the different routing protocols
       used.
     - The routing information exchanged between routing domains (i.e.
       inter-domain) is independent of both the intra-domain routing
       protocol and the intra-domain control distribution choice(s), e.g.
       centralized, fully distributed."

well hope this clarifies,
- dimitri.

rick king wrote:

> Then what's relationship between a RA and a routing control domain?
> 
> thanks
> 
> Rick
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of [e-mail]
> Sent: Wednesday, January 07, 2004 6:57 AM
> To: rick king
> Cc: [e-mail]
> Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
> 
> 
> hi, thanks for commenting, see in-line:
> 
> rick king wrote:
> 
> 
>>Some comments. Section 3.   ......The  ASON model allows for the protocols
>>used within different control domains to be different; and for the protocol
>>used between control domains to be different than the protocols used within
>>control domains. ......
>>
>>The routing requirements contained in this draft apply to protocols used
>>between control domains(E-NNI routing) or protocols used within control
>>domains(I-NNI routing) or both?
> 
> 
> -> both
> 
> 
>>...... - For a RA, the cluster of RCs is referred to as a routing
>>domain......
>>
>>Does this means that RA=routing domain? Maybe routing control domain is more
>>align with G.7715.
> 
> 
> -> yes, it is "routing (control) domain", we will clarify in the
>     next version
> 
> 
>>Section 4.2.1    ......   - The second approach places the Level N routing
>>function on a separate system from the Level N+1 routing function. In this 
>>case, a communication interface must be used between the systems containing
>>the routing functions for different levels. This communication interface and
>>mechanisms are outside the scope of this document. .......
>>
>>Is it possible that the Level N routing function and  the Level N+1 routing
>>function are from different vendors? If the answer is yes, then I think the
>>communication interface and mechanisms should be defined. Otherwise how can
>>you achieve inter-operate?
> 
> 
> -> it is expected to cover multi-vendor case (note that the other
>     alternative is single vendor only) so that this "communication
>     interface" is expected to be defined but it is not within the
>     scope of this document, what's within the scope is the routing
>     information exchanged (ie ways to achieve the communication
>     interface between these systems is not)
> 
> thanks,
> - dimitri.
> 
> 
>>Thank you.
>>
>>rick
>>
>>-----Original Message----- From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of
>>[e-mail] Sent: Tuesday, December 30, 2003 5:19 AM To:
>>[e-mail] Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
>>
>>
>>all,
>>
>>the following version of the "ASON routing requirements" document completes
>>the template proposed in the v00.txt:
>>
>><http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
>>
>>
>>please provide any comment you think relevant in order to progress this wg
>>i-d
>>
>>thanks, - dimitri.
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 16:30:13 +0000
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: David Charlap <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 17:13:03 +0100 
MIME-Version: 1.0
Content-Type: text/plain

> [e-mail] wrote:
> > to what *change* do you refer here, when you say
> > 
> > " If not, at least, isn't it a good idea to let the WG know
> > the rational reason behind changing the proposed value in the
> > draft ?"
> > 
> > The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
> > and value 3 has never been reserved -
> 
> The value 3 was specified for the old RSVP-TE draft.
> 
> Yes, there was no value specified in the GMPLS-SONET/SDH draft.
> 
> So how did IANA assign a value?  And why did they choose to assign a 
> value to this draft, when they aren't assigning values to other 
> important drafts (like DiffServ-TE)?
> 
They do NOT assign a value to just a DRAFT 
They assign a value to a DRAFT AFTER it has been approved by IESG
and put into RFC-Editor and IANA queues for final processing.

That NEVER happend to the old RSVP draft, and so that old draft
NEVER HAD a VALID assignment.

Bert
> -- David
> 
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 16:21:24 +0000
Message-ID: <[e-mail]>
Date: Thu, 08 Jan 2004 17:21:54 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: David Charlap <[e-mail]>
Cc: IETF CCAMP List <[e-mail]>, [e-mail]
Subject: Re: IANA assignments
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

the "draft" is in the RFC Editor queue and blocked due to
a reference to [GMPLS-ARCH] otherwise it should have been
out now with an RFC number.

David Charlap wrote:

> [e-mail] wrote:
> 
>> to what *change* do you refer here, when you say
>>
>> " If not, at least, isn't it a good idea to let the WG know
>> the rational reason behind changing the proposed value in the
>> draft ?"
>>
>> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
>> and value 3 has never been reserved -
> 
> 
> The value 3 was specified for the old RSVP-TE draft.
> 
> Yes, there was no value specified in the GMPLS-SONET/SDH draft.
> 
> So how did IANA assign a value?  And why did they choose to assign a 
> value to this draft, when they aren't assigning values to other 
> important drafts (like DiffServ-TE)?
> 
> -- David
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 16:02:36 +0000
Message-ID: <[e-mail]>
Date: Thu, 08 Jan 2004 11:03:44 -0500
From: David Charlap <[e-mail]>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: IETF CCAMP List <[e-mail]>, [e-mail]
Subject: Re: IANA assignments
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> to what *change* do you refer here, when you say
> 
> " If not, at least, isn't it a good idea to let the WG know
> the rational reason behind changing the proposed value in the
> draft ?"
> 
> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
> and value 3 has never been reserved -

The value 3 was specified for the old RSVP-TE draft.

Yes, there was no value specified in the GMPLS-SONET/SDH draft.

So how did IANA assign a value?  And why did they choose to assign a 
value to this draft, when they aren't assigning values to other 
important drafts (like DiffServ-TE)?

-- David




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 16:02:20 +0000
Message-ID: <[e-mail]>
From: "Naidu, Venkata" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Wijnen, Bert (Bert)'" <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 11:00:47 -0500 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Dimitri,

-> to what *change* do you refer here, when you say
-> 
-> " If not, at least, isn't it a good idea to let the WG know
-> the rational reason behind changing the proposed value in the
-> draft ?"
-> 
-> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
-> and value 3 has never been reserved -

  I am referring to old expired long lived RSVP-TE drafts which
  used C-Type 3 and we all implemented and shipped with 3.
  When we decide to remove C-Type, isn't it good to reserve
  at the change/deprecating time ?
  (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt was published in Aug 2000 
  and draft-ietf-mpls-rsvp-lsp-tunnel-08.txt was published in 
  Feb 2001)

  All I am saying is, IANA can have a guideline for long lived
  drafts, such as:
  
     If there is a shipped implementation with an old deprecated
     value, that value MUST be reserved to prevent future misuse.
     It MUST be noted in the subsequent drafts and final RFC.

Venkata.



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 15:35:41 +0000
Message-ID: <[e-mail]>
Date: Thu, 08 Jan 2004 16:36:00 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Naidu, Venkata" <[e-mail]>
Cc: "'Wijnen, Bert (Bert)'" <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: Re: IANA assignments
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

to what *change* do you refer here, when you say

" If not, at least, isn't it a good idea to let the WG know
the rational reason behind changing the proposed value in the
draft ?"

The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA
and value 3 has never been reserved -

Naidu, Venkata wrote:

> Bert,
> 
> -> NOPE, cause it would not have been assigned based on the fact that
> -> it is in some ID.
> -> 
> -> > IMO this is an IANA process issue, but we've been here before 
> -> > (at least some of us), and never really resolved anything.
> -> > (A simple solution would be to reserve values for long lived drafts
> -> > and formally assign on RFC publication or return the values if/when
> -> > the draft dies.)
> -> >
> -> NOPE. The simple solution is that you request a value in 
> -> experimental 
> -> space while the ID is progressing and being discussed. Only at final
> -> ID approval and RFC-publication will a value in the STDS track space
> -> be assigned.
> 
>   Is it possible for IANA to initiate a discussion in the mailing-list
>   before publishing a value, at least, for long lived drafts ? So that
>   we come to a consensus before assigning a value. If not, at least,
>   isn't it a good idea to let the WG know the rational reason behind 
>   changing the proposed value in the draft ?
> 
> Venkata.
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 15:28:11 +0000
Message-ID: <[e-mail]>
From: "Naidu, Venkata" <[e-mail]>
To: "'Wijnen, Bert (Bert)'" <[e-mail]>, IETF CCAMP List <[e-mail]>
Cc: [e-mail]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 10:27:01 -0500 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Bert,

-> NOPE, cause it would not have been assigned based on the fact that
-> it is in some ID.
-> 
-> > IMO this is an IANA process issue, but we've been here before 
-> > (at least some of us), and never really resolved anything.
-> > (A simple solution would be to reserve values for long lived drafts
-> > and formally assign on RFC publication or return the values if/when
-> > the draft dies.)
-> >
-> NOPE. The simple solution is that you request a value in 
-> experimental 
-> space while the ID is progressing and being discussed. Only at final
-> ID approval and RFC-publication will a value in the STDS track space
-> be assigned.

  Is it possible for IANA to initiate a discussion in the mailing-list
  before publishing a value, at least, for long lived drafts ? So that
  we come to a consensus before assigning a value. If not, at least,
  isn't it a good idea to let the WG know the rational reason behind 
  changing the proposed value in the draft ?

Venkata.



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 15:17:04 +0000
Message-Id: <[e-mail]>
To: "Wijnen, Bert (Bert)" <[e-mail]>
cc: Lou Berger <[e-mail]>, David Charlap <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: Re: IANA assignments 
Reply-To: [e-mail]
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 08 Jan 2004 10:15:26 -0500
From: Eric Rosen <[e-mail]>

Bert> The simple solution is that  you request a value in experimental space
Bert> while  the ID is  progressing and  being discussed.  Only at  final ID
Bert> approval and RFC-publication  will a value in the  STDS track space be
Bert> assigned. 

This will result in a situation  where the value from the experimental space
becomes the de facto standard.  That seems a bit silly. 




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 13:44:33 +0000
Message-Id: <4.3.2.7.2.20040108081533.02859140@mo-ex1>
Date: Thu, 08 Jan 2004 08:42:49 -0500
To: "Wijnen, Bert (Bert)" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: IANA assignments
Cc: "David Charlap" <[e-mail]>, "IETF CCAMP List" <[e-mail]>, <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

humm, I think we're debating two points.  One we agree on the other I'm not 
sure about.

Point 1: (re)assignment of values removed from or used in dead drafts.

I'm all for this and agree that these values should be reused.

Point 2: temporary assignment of *real* values for long lived drafts.

I think we disagree here, but am not sure.  There needs to be a way to 
tentatively assign values to ensure interoperable implementations of 
drafts.  Sure when the draft doesn't make it to RFC, point 1 applies and 
the values are free for reuse.

As there is no IANA process that supports this, the implementation 
community resorts to agreeing on values.   Changing these values at RFC 
publication time serves no purpose other than disrupting the vendor and 
service provider communities.

In this case, the draft has been stable for 2+ years.  There have been 
*many* implementations, many interop tests, and even deployments.  There 
are also derivative works (OIF and ITU).  All use the same value here.  It 
serves no one in the community to change the value at this time.   All it 
does is destabilize an otherwise stable technology.

In short, IANA should formally assign the values that have been used for 
the past few years.

I would love for IANA/IESG to come up with a formal procedure to deal with 
this real interoperability issue.

Lou

At 06:43 AM 1/8/2004, Wijnen, Bert (Bert) wrote:

> > Bert,
> >          Got to say I agree with David on this.  There is a
> > long standing issue with IANA assignments for long lived drafts.
> > We hit this with MPLS, GMPLS and now this document.
> >
> > The way this was resolved in the past was to make a formal request to IANA
> > that included specific values and then for implementations to use these
> > values until the formal assignment was made.
>
>NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are
>OK with a WG asking for a specific value (in a ID), but that does NOT
>mean that early implementors can or should use that value.
>Because it CAN and WILL be taken away for otehr assignments when the
>ID does not make it to RFC.
>
> > I think that the request for assignment of a specific value (3) got
> > dropped in this case.
> > If that had been made, all would be good.
> >
>NOPE, cause it would not have been assigned based on the fact that
>it is in some ID.
>
> > IMO this is an IANA process issue, but we've been here before
> > (at least some of us), and never really resolved anything.
> > (A simple solution would be to reserve values for long lived drafts
> > and formally assign on RFC publication or return the values if/when
> > the draft dies.)
> >
>NOPE. The simple solution is that you request a value in experimental
>space while the ID is progressing and being discussed. Only at final
>ID approval and RFC-publication will a value in the STDS track space
>be assigned.
>
>Bert
> > Lou
> >
> >  > -----Original Message-----
> > > > From: David Charlap
> > > 
> [<<mailto:[e-mail]>mailto:[e-mail]>mailto:[e-mail]] 
>
> > > > Sent: dinsdag 6 januari 2004 18:34
> > > > To: IETF CCAMP List
> > > > Subject: IANA assignments
> > > >
> > > >
> > > > Today, I was going through the IANA assignements for RSVP
> > > >
> > >
> > 
> (<<http://www.iana.org/assignments/rsvp-parameters>http://www.iana.org/assignments/rsvp-parameters>http://www.i 
>
>ana.org/assignments/rsvp-parameters)
> > and noticed
> > > what may be a problem.
> > >
> > > The SONET/SDH FLOWSPEC C-Type
> > > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > > is assigned the value 3.
> > >




Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 11:45:28 +0000
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: Lou Berger <[e-mail]>, "Wijnen, Bert (Bert)" <[e-mail]>
Cc: David Charlap <[e-mail]>, IETF CCAMP List <[e-mail]>, [e-mail]
Subject: RE: IANA assignments
Date: Thu, 8 Jan 2004 12:43:26 +0100 
MIME-Version: 1.0
Content-Type: text/plain

> Bert,
>          Got to say I agree with David on this.  There is a 
> long standing issue with IANA assignments for long lived drafts.
> We hit this with MPLS, GMPLS and now this document.
> 
> The way this was resolved in the past was to make a formal request to IANA 
> that included specific values and then for implementations to use these 
> values until the formal assignment was made. 

NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are
OK with a WG asking for a specific value (in a ID), but that does NOT
mean that early implementors can or should use that value. 
Because it CAN and WILL be taken away for otehr assignments when the
ID does not make it to RFC.

> I think that the request for assignment of a specific value (3) got
> dropped in this case.  
> If that had been made, all would be good.
> 
NOPE, cause it would not have been assigned based on the fact that
it is in some ID.

> IMO this is an IANA process issue, but we've been here before 
> (at least some of us), and never really resolved anything.
> (A simple solution would be to reserve values for long lived drafts
> and formally assign on RFC publication or return the values if/when
> the draft dies.)
>
NOPE. The simple solution is that you request a value in experimental 
space while the ID is progressing and being discussed. Only at final
ID approval and RFC-publication will a value in the STDS track space
be assigned.

Bert 
> Lou
> 
>  > -----Original Message-----
> > > From: David Charlap 
> > [<mailto:[e-mail]>mailto:[e-mail]]
> > > Sent: dinsdag 6 januari 2004 18:34
> > > To: IETF CCAMP List
> > > Subject: IANA assignments
> > >
> > >
> > > Today, I was going through the IANA assignements for RSVP
> > > 
> > 
> (<http://www.iana.org/assignments/rsvp-parameters>http://www.i
ana.org/assignments/rsvp-parameters) 
> and noticed
> > what may be a problem.
> >
> > The SONET/SDH FLOWSPEC C-Type
> > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > is assigned the value 3.
> >



Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2004 00:37:53 +0000
Message-Id: <4.3.2.7.2.20040107192604.00b231a0@mo-ex1>
Date: Wed, 07 Jan 2004 19:35:02 -0500
To: "Wijnen, Bert (Bert)" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: IANA assignments
Cc: "David Charlap" <[e-mail]>, "IETF CCAMP List" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bert,
         Got to say I agree with David on this.  There is a long standing 
issue with IANA assignments for long lived drafts.  We hit this with MPLS, 
GMPLS and now this document.

The way this was resolved in the past was to make a formal request to IANA 
that included specific values and then for implementations to use these 
values until the formal assignment was made.  I think that the request for 
assignment of a specific value (3) got dropped in this case.  If that had 
been made, all would be good.

IMO this is an IANA process issue, but we've been here before (at least 
some of us), and never really resolved anything.  (A simple solution would 
be to reserve values for long lived drafts and formally assign on RFC 
publication or return the values if/when the draft dies.)

Lou

 > -----Original Message-----
> > From: David Charlap 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: dinsdag 6 januari 2004 18:34
> > To: IETF CCAMP List
> > Subject: IANA assignments
> >
> >
> > Today, I was going through the IANA assignements for RSVP
> > 
> (<http://www.iana.org/assignments/rsvp-parameters>http://www.iana.org/assignments/rsvp-parameters) 
> and noticed
> > what may be a problem.
> >
> > The SONET/SDH FLOWSPEC C-Type
> > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > is assigned the value 3.
> >




Envelope-to: [e-mail]
Delivery-date: Wed, 07 Jan 2004 17:29:15 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: [e-mail]
Subject: FW: ITU-T Q14/15, and Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp.  Mtgs., 16-20 Feb. 2004, Chicago, USA
Date: Wed, 7 Jan 2004 12:25:58 -0500 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

This is a re-send. It bounced on the ccamp list.

>  -----Original Message-----
> From: 	Lam, Hing-Kam (Kam)  
> Sent:	Wednesday, January 07, 2004 9:53 AM
> To:	'[e-mail]'; '[e-mail]'; '[e-mail]'
> Cc:	'[e-mail]'; '[e-mail]'; 'Kireeti Kompella'; '[e-mail]'; 'Alex Zinin'; 'Bill Fenner'; '[e-mail]'; '[e-mail]'
> Subject:	ITU-T Q14/15, and Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Mtgs., 16-20 Feb. 2004, Chicago, USA
> 
> Dear all,
> 
> Based on the information available at this time, i.e. number of expected participants (>20), the topics for discussion, and number of expected contributions (>15), the SG15 management team has authorized Q14/15 to hold the Q14/15, and the Joint Q14/15,  Q12/4, Q14/4 Rapporteur Group meetings as planned (16-20 February 2004, Chicago, Ill., USA).
> Note that the Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Meeting will occur on the second part of the week from Wednesday to Friday (i.e., 18-20 Feb. 2004). 
> 
> I have created a directory in the ITU-T informal FTP site for contributons and logistic information
> http://ties.itu.int/u/tsg15/sg15/wp3/q14/0402/
> 
> Deadline for contribution submission is noon (U.S. EST) 9th February 2004.
> 
> If you plan to provide contributions, please send me the title as soon as possible so that I can assign Working Document (WD) numbers. Please upload your contributions BY Noon (U.S. EST) Monday 9th February 2004 to the above TIES ftp directory with the file name wdxx_company-name_short-title.doc, where xx is the WD number. Please include the leading 0 in the WD number and use all lower case and _ for spaces. After uploading, please send me a note so that I can update the document list. If you want me to upload the contributions for you, email me the file.
> 
> As the IETF experts have been invited to attend this interim meeting, 
> I have also created a directory in the ITU-T public site at
> ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/wp3/q14/0402 for them to access the contributions and logistic information without the need of an ITU-T TIES account. I will try to synchronize the information in this public directory with the TIES directory as often as possible.
> 
> Regards,
> Kam Lam
> ITU-T Q14/15 Rapporteur
> 1-732-949-8338
> [e-mail]
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 07 Jan 2004 06:41:46 +0000
From: "rick king" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Date: Wed, 7 Jan 2004 14:39:33 +0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64

VGhlbiB3aGF0J3MgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBSQSBhbmQgYSByb3V0aW5nIGNvbnRy
b2wgZG9tYWluPw0KDQp0aGFua3MNCg0KUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3Bz
LmlldGYub3JnXU9uIEJlaGFsZiBPZiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0K
U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA3LCAyMDA0IDY6NTcgQU0NClRvOiByaWNrIGtpbmcN
CkNjOiBjY2FtcEBvcHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWNjYW1wLWdt
cGxzLWFzb24tcm91dGluZy1yZXF0cy0wMS50eHQNCg0KDQpoaSwgdGhhbmtzIGZvciBjb21tZW50
aW5nLCBzZWUgaW4tbGluZToNCg0KcmljayBraW5nIHdyb3RlOg0KDQo+IFNvbWUgY29tbWVudHMu
IFNlY3Rpb24gMy4gICAuLi4uLi5UaGUgIEFTT04gbW9kZWwgYWxsb3dzIGZvciB0aGUgcHJvdG9j
b2xzDQo+IHVzZWQgd2l0aGluIGRpZmZlcmVudCBjb250cm9sIGRvbWFpbnMgdG8gYmUgZGlmZmVy
ZW50OyBhbmQgZm9yIHRoZSBwcm90b2NvbA0KPiB1c2VkIGJldHdlZW4gY29udHJvbCBkb21haW5z
IHRvIGJlIGRpZmZlcmVudCB0aGFuIHRoZSBwcm90b2NvbHMgdXNlZCB3aXRoaW4NCj4gY29udHJv
bCBkb21haW5zLiAuLi4uLi4NCj4gDQo+IFRoZSByb3V0aW5nIHJlcXVpcmVtZW50cyBjb250YWlu
ZWQgaW4gdGhpcyBkcmFmdCBhcHBseSB0byBwcm90b2NvbHMgdXNlZA0KPiBiZXR3ZWVuIGNvbnRy
b2wgZG9tYWlucyhFLU5OSSByb3V0aW5nKSBvciBwcm90b2NvbHMgdXNlZCB3aXRoaW4gY29udHJv
bA0KPiBkb21haW5zKEktTk5JIHJvdXRpbmcpIG9yIGJvdGg/DQoNCi0+IGJvdGgNCg0KPiAuLi4u
Li4gLSBGb3IgYSBSQSwgdGhlIGNsdXN0ZXIgb2YgUkNzIGlzIHJlZmVycmVkIHRvIGFzIGEgcm91
dGluZw0KPiBkb21haW4uLi4uLi4NCj4gDQo+IERvZXMgdGhpcyBtZWFucyB0aGF0IFJBPXJvdXRp
bmcgZG9tYWluPyBNYXliZSByb3V0aW5nIGNvbnRyb2wgZG9tYWluIGlzIG1vcmUNCj4gYWxpZ24g
d2l0aCBHLjc3MTUuDQoNCi0+IHllcywgaXQgaXMgInJvdXRpbmcgKGNvbnRyb2wpIGRvbWFpbiIs
IHdlIHdpbGwgY2xhcmlmeSBpbiB0aGUNCiAgICBuZXh0IHZlcnNpb24NCg0KPiBTZWN0aW9uIDQu
Mi4xICAgIC4uLi4uLiAgIC0gVGhlIHNlY29uZCBhcHByb2FjaCBwbGFjZXMgdGhlIExldmVsIE4g
cm91dGluZw0KPiBmdW5jdGlvbiBvbiBhIHNlcGFyYXRlIHN5c3RlbSBmcm9tIHRoZSBMZXZlbCBO
KzEgcm91dGluZyBmdW5jdGlvbi4gSW4gdGhpcyANCj4gY2FzZSwgYSBjb21tdW5pY2F0aW9uIGlu
dGVyZmFjZSBtdXN0IGJlIHVzZWQgYmV0d2VlbiB0aGUgc3lzdGVtcyBjb250YWluaW5nDQo+IHRo
ZSByb3V0aW5nIGZ1bmN0aW9ucyBmb3IgZGlmZmVyZW50IGxldmVscy4gVGhpcyBjb21tdW5pY2F0
aW9uIGludGVyZmFjZSBhbmQNCj4gbWVjaGFuaXNtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg
dGhpcyBkb2N1bWVudC4gLi4uLi4uLg0KPiANCj4gSXMgaXQgcG9zc2libGUgdGhhdCB0aGUgTGV2
ZWwgTiByb3V0aW5nIGZ1bmN0aW9uIGFuZCAgdGhlIExldmVsIE4rMSByb3V0aW5nDQo+IGZ1bmN0
aW9uIGFyZSBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzPyBJZiB0aGUgYW5zd2VyIGlzIHllcywgdGhl
biBJIHRoaW5rIHRoZQ0KPiBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBhbmQgbWVjaGFuaXNtcyBz
aG91bGQgYmUgZGVmaW5lZC4gT3RoZXJ3aXNlIGhvdyBjYW4NCj4geW91IGFjaGlldmUgaW50ZXIt
b3BlcmF0ZT8NCg0KLT4gaXQgaXMgZXhwZWN0ZWQgdG8gY292ZXIgbXVsdGktdmVuZG9yIGNhc2Ug
KG5vdGUgdGhhdCB0aGUgb3RoZXINCiAgICBhbHRlcm5hdGl2ZSBpcyBzaW5nbGUgdmVuZG9yIG9u
bHkpIHNvIHRoYXQgdGhpcyAiY29tbXVuaWNhdGlvbg0KICAgIGludGVyZmFjZSIgaXMgZXhwZWN0
ZWQgdG8gYmUgZGVmaW5lZCBidXQgaXQgaXMgbm90IHdpdGhpbiB0aGUNCiAgICBzY29wZSBvZiB0
aGlzIGRvY3VtZW50LCB3aGF0J3Mgd2l0aGluIHRoZSBzY29wZSBpcyB0aGUgcm91dGluZw0KICAg
IGluZm9ybWF0aW9uIGV4Y2hhbmdlZCAoaWUgd2F5cyB0byBhY2hpZXZlIHRoZSBjb21tdW5pY2F0
aW9uDQogICAgaW50ZXJmYWNlIGJldHdlZW4gdGhlc2Ugc3lzdGVtcyBpcyBub3QpDQoNCnRoYW5r
cywNCi0gZGltaXRyaS4NCg0KPiBUaGFuayB5b3UuDQo+IA0KPiByaWNrDQo+IA0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCj4gW21h
aWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+IERpbWl0cmkuUGFw
YWRpbWl0cmlvdUBhbGNhdGVsLmJlIFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDMwLCAyMDAzIDU6
MTkgQU0gVG86DQo+IGNjYW1wQG9wcy5pZXRmLm9yZyBTdWJqZWN0OiBkcmFmdC1pZXRmLWNjYW1w
LWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMS50eHQNCj4gDQo+IA0KPiBhbGwsDQo+IA0KPiB0
aGUgZm9sbG93aW5nIHZlcnNpb24gb2YgdGhlICJBU09OIHJvdXRpbmcgcmVxdWlyZW1lbnRzIiBk
b2N1bWVudCBjb21wbGV0ZXMNCj4gdGhlIHRlbXBsYXRlIHByb3Bvc2VkIGluIHRoZSB2MDAudHh0
Og0KPiANCj4gPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt
Y2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAxLnR4dD4NCj4gDQo+IA0KPiBwbGVhc2Ug
cHJvdmlkZSBhbnkgY29tbWVudCB5b3UgdGhpbmsgcmVsZXZhbnQgaW4gb3JkZXIgdG8gcHJvZ3Jl
c3MgdGhpcyB3Zw0KPiBpLWQNCj4gDQo+IHRoYW5rcywgLSBkaW1pdHJpLg0KPiANCg0KLS0gDQpQ
YXBhZGltaXRyaW91IERpbWl0cmkNCkUtbWFpbCA6IGRpbWl0cmkucGFwYWRpbWl0cmlvdUBhbGNh
dGVsLmJlDQpFLW1haWwgOiBkcGFwYWRpbWl0cmlvdUBwc2cuY29tDQpXZWJwYWdlOiBodHRwOi8v
cHNnLmNvbS9+ZHBhcGFkaW1pdHJpb3UvDQpBZGRyZXNzOiBGci4gV2VsbGVzcGxlaW4gMSwgQi0y
MDE4IEFudHdlcnBlbiwgQmVsZ2l1bQ0KUGhvbmUgIDogKzMyIDMgMjQwLTg0OTENCg0K





Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jan 2004 22:56:06 +0000
Message-ID: <[e-mail]>
Date: Tue, 06 Jan 2004 23:56:49 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: rick king <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi, thanks for commenting, see in-line:

rick king wrote:

> Some comments. Section 3.   ......The  ASON model allows for the protocols
> used within different control domains to be different; and for the protocol
> used between control domains to be different than the protocols used within
> control domains. ......
> 
> The routing requirements contained in this draft apply to protocols used
> between control domains(E-NNI routing) or protocols used within control
> domains(I-NNI routing) or both?

-> both

> ...... - For a RA, the cluster of RCs is referred to as a routing
> domain......
> 
> Does this means that RA=routing domain? Maybe routing control domain is more
> align with G.7715.

-> yes, it is "routing (control) domain", we will clarify in the
    next version

> Section 4.2.1    ......   - The second approach places the Level N routing
> function on a separate system from the Level N+1 routing function. In this 
> case, a communication interface must be used between the systems containing
> the routing functions for different levels. This communication interface and
> mechanisms are outside the scope of this document. .......
> 
> Is it possible that the Level N routing function and  the Level N+1 routing
> function are from different vendors? If the answer is yes, then I think the
> communication interface and mechanisms should be defined. Otherwise how can
> you achieve inter-operate?

-> it is expected to cover multi-vendor case (note that the other
    alternative is single vendor only) so that this "communication
    interface" is expected to be defined but it is not within the
    scope of this document, what's within the scope is the routing
    information exchanged (ie ways to achieve the communication
    interface between these systems is not)

thanks,
- dimitri.

> Thank you.
> 
> rick
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> [e-mail] Sent: Tuesday, December 30, 2003 5:19 AM To:
> [e-mail] Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
> 
> 
> all,
> 
> the following version of the "ASON routing requirements" document completes
> the template proposed in the v00.txt:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
> 
> 
> please provide any comment you think relevant in order to progress this wg
> i-d
> 
> thanks, - dimitri.
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jan 2004 22:49:22 +0000
Date: Tue, 30 Dec 2003 18:57:31 -0800 (PST)
From: Jim Boyle <[e-mail]>
To: Jean Philippe Vasseur <[e-mail]>
cc: [e-mail]
Subject: Re: Fwd: MPLS Inter-area TE requirement draft
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I also encourage the members of CCAMP to review my original draft, at

http://www.ietf.org/internet-drafts/draft-boyle-tewg-interarea-reqts-01.txt

I solicit comments on these 2 inter-area drafts, as well as the TEWG doc
on inter-as requirements be directed to [e-mail]

thanks!

Jim

On Tue, 30 Dec 2003, Jean Philippe Vasseur wrote:

> copying CCAMP for comments.
>
> Thanks.
>
> JP.
>
> >Date: Tue, 30 Dec 2003 15:25:20 -0500
> >To: [e-mail]
> >From: Jean Philippe Vasseur <[e-mail]>
> >Subject: MPLS Inter-area TE requirement draft
> >Cc: [e-mail], Jim Boyle <[e-mail]>, [e-mail],
> >[e-mail], [e-mail], Kenji
> >Kumaki <[e-mail]>, Yuichi Ikejiri <[e-mail]>, Parantap
> >Lahiri <[e-mail]>, [e-mail]
> >
> >Hi,
> >
> >Please find attached a new MPLS Inter-area TE requirement draft, which is
> >truly the collective effort of the SPs on this draft along with comments
> >we received form others. I took the liberty to send the draft to the list
> >since it is still not on the IETF site and Bert mentioned that quick
> >progress should be made on this item.
> >
> >Jim, as already mentioned on the list, we would be happy to work with you
> >on this draft in order to quickly come up with a single draft if you will.
> >
> >Thanks in advance for your comment.
> >
> >JP.
>



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jan 2004 22:49:11 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Dec 2003 00:44:56 -0800 (PST)
From: rick king <[e-mail]>
Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-333418823-1072773896=:70951"

--0-333418823-1072773896=:70951
Content-Type: text/plain; charset=us-ascii

Some comments.
Section 3.   ......The  ASON model allows for the protocols used within different control
   domains to be different; and for the protocol used between control
   domains to be different than the protocols used within control
   domains. ......
    The routing requirements contained in this draft apply to protocols used between control
   domains(E-NNI routing) or protocols used within control  domains(I-NNI routing) or both?
  ...... - For a RA, the cluster of RCs is referred to as a routing domain......

   Does this means that RA=routing domain? Maybe routing control domain is
   more align with G.7715.
Section 4.2.1    ......   - The second approach places the Level N routing function on a
        separate system from the Level N+1 routing function. In this
        case, a communication interface must be used between the
        systems containing the routing functions for different levels.
        This communication interface and mechanisms are outside the
        scope of this document. .......
  Is it possible that the Level N routing function and  the Level N+1 routing function are
from different vendors? If the answer is yes, then I think the  communication interface and mechanisms should be defined. Otherwise how can you achieve inter-operate?

Thank you.

-rick
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of [e-mail]
Sent: Tuesday, December 30, 2003 5:19 AM
To: [e-mail]
Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt

all,
the following version of the "ASON routing requirements" document
completes the template proposed in the v00.txt:
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt>
please provide any comment you think relevant in order to progress
this wg i-d
thanks,
- dimitri.



---------------------------------
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
--0-333418823-1072773896=:70951
Content-Type: text/html; charset=us-ascii

<DIV>Some comments.<BR>Section 3.&nbsp;&nbsp; ......The&nbsp; ASON model allows for the protocols used within different control<BR>&nbsp;&nbsp; domains to be different; and for the protocol used between control<BR>&nbsp;&nbsp; domains to be different than the protocols used within control<BR>&nbsp;&nbsp; domains. ......</DIV>
<DIV>&nbsp;&nbsp;&nbsp; The routing requirements contained in this draft apply to protocols used between control<BR>&nbsp;&nbsp; domains(E-NNI routing) or protocols used within control&nbsp; domains(I-NNI routing) or both?</DIV>
<DIV>&nbsp; ...... - For a RA, the cluster of RCs is referred to as a routing domain......<BR>&nbsp;&nbsp; <BR>&nbsp;&nbsp; Does this means that RA=routing domain? Maybe routing control domain is<BR>&nbsp;&nbsp; more align with G.7715.</DIV>
<DIV>Section 4.2.1&nbsp;&nbsp;&nbsp; ......&nbsp;&nbsp; - The second approach places the Level N routing function on a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; separate system from the Level N+1 routing function. In this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case, a communication interface must be used between the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; systems containing the routing functions for different levels.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This communication interface and mechanisms are outside the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; scope of this document. .......</DIV>
<DIV>&nbsp; Is it possible that the Level N routing function and&nbsp; the Level N+1 routing function are <BR>from different vendors? If the answer is yes, then I think the&nbsp; communication interface and mechanisms should be defined. Otherwise how can you achieve inter-operate?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-rick</DIV>
<DIV>-----Original Message-----<BR>From: <A href="mailto:[e-mail]">[e-mail]</A> [mailto:[e-mail]]On Behalf Of <A href="mailto:[e-mail]">[e-mail]</A><BR>Sent: Tuesday, December 30, 2003 5:19 AM<BR>To: <A href="mailto:[e-mail]">[e-mail]</A><BR>Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt</DIV>
<DIV><BR>all,</DIV>
<DIV>the following version of the "ASON routing requirements" document<BR>completes the template proposed in the v00.txt:</DIV>
<DIV>&lt;<A href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt</A>&gt;</DIV>
<DIV>please provide any comment you think relevant in order to progress<BR>this wg i-d</DIV>
<DIV>thanks,<BR>- dimitri.</DIV>
<DIV>&nbsp;</DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://search.yahoo.com/top2003">Find out what made the Top Yahoo! Searches of 2003
</a>
--0-333418823-1072773896=:70951--



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jan 2004 22:23:40 +0000
Message-ID: <[e-mail]>
Date: Tue, 06 Jan 2004 17:23:21 -0500
From: David Charlap <[e-mail]>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: IETF CCAMP List <[e-mail]>
Subject: Re: IANA assignments
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Wijnen, Bert (Bert) wrote:
> The BAD thing is that someone else (some vendor) has used a value
> from some other draft document... and THAT WAS and IS BAD.
> If you want to use a value, you better MAKE SURE it is a value that
> has been assigned and registered by IANA, that is if it is in IANA
> maintained namespace.

The use of 3 for the CoS object was defined in many revisions of 
RSVP-TE.  Nearly every vendor shipped an implementation at the time.

Even though there are other proper methods for signaling best-effort 
today (the Null-Service IntServ class), I doubt anybody will want to 
remove their old pre-standard code, because they won't want to break 
backward-compatibility with their older system software revisions.

This sort of thing has happened in the past, and IANA usually responded 
by marking the pre-standard value as "Reserved".  For example, RSVP 
message type 14 was the pre-standard value used for Hello messages, and 
is now marked Reserved.

>> I realize that expired drafts aren't supposed to have an impact on these 
>> kinds of decisions, but there are shipping products currently on the 
>> market that still use this C-Type.
> 
> It migth be good to point out which products did this BAD move.
> And which document did they find them in?

Considering that the GMPLS-SONET/SDH draft version 0 was written years 
after RSVP-TE draft 01, where the CoS C-Type was originally defined, and 
after several vendors had already shipped product with it, I think the 
decision should be obvious.

draft-ietf-mpls-rsvp-lsp-tunnel-**.txt is not some fly-by-night 
proposal.  And the C-Type in question (including its value) was in the 
draft for seven revisions (that's 3.5 years).  This isn't something you 
casually ignore.

>> The person responsible for this draft should make sure to choose a 
>> different value before the draft becomes an RFC.
> 
> I am not so sure I agree.
> We should try to not make things break in the market. 
> But at the other hand, if we give into this kind of thing, it seems
> we might also do away with IANA... and that seems not right to me.

Who is "we"?  You sound as if there's a war on or something.

Last I heard, we (meaning all of us) were interested in making our 
routers work.  And you can't do that if someone defines a new standard 
that contradicts current (and popular) implementations.

-- David





Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jan 2004 21:47:04 +0000
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: David Charlap <[e-mail]>, IETF CCAMP List <[e-mail]>
Subject: RE: IANA assignments
Date: Tue, 6 Jan 2004 22:44:52 +0100 
MIME-Version: 1.0
Content-Type: text/plain

Inline:

> -----Original Message-----
> From: David Charlap [mailto:[e-mail]]
> Sent: dinsdag 6 januari 2004 18:34
> To: IETF CCAMP List
> Subject: IANA assignments
> 
> 
> Today, I was going through the IANA assignements for RSVP 
> (http://www.iana.org/assignments/rsvp-parameters) and noticed 
> what may be a problem.
> 
> The SONET/SDH FLOWSPEC C-Type 
> (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) 
> is assigned the value 3.
> 
Actually, if it is on that IANA web page, as it indeed is, then that
means that IANA has already assigned it. 

The internet draft in fact has: TBA (means To Be Assigned).

> This is bad.  The value 3 was already used in some (now 
> expired) RSVP-TE drafts to represent the class-of-service C-Type.
> 
The BAD thing is that someone else (some vendor) has used a value
from some other draft document... and THAT WAS and IS BAD.
If you want to use a value, you better MAKE SURE it is a value that
has been assigned and registered by IANA, that is if it is in IANA
maintained namespace.

> The same problem exists for the SONET/SDH TSPEC.
> 
SAME answer!

> I realize that expired drafts aren't supposed to have an impact on these 
> kinds of decisions, but there are shipping products currently on the 
> market that still use this C-Type.
> 
It migth be good to point out which products did this BAD move.
And which document did they find them in?

> The person responsible for this draft should make sure to choose a 
> different value before the draft becomes an RFC.
> 
I am not so sure I agree.
We should try to not make things break in the market. 
But at the other hand, if we give into this kind of thing, it seems
we might also do away with IANA... and that seems not right to me.

Bert

> -- David
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 06 Jan 2004 21:11:07 +0000
Message-ID: <[e-mail]>
Date: Tue, 06 Jan 2004 12:34:01 -0500
From: David Charlap <[e-mail]>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: IETF CCAMP List <[e-mail]>
Subject: IANA assignments
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Today, I was going through the IANA assignements for RSVP 
(http://www.iana.org/assignments/rsvp-parameters) and noticed what may 
be a problem.

The SONET/SDH FLOWSPEC C-Type (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) 
is assigned the value 3.

This is bad.  The value 3 was already used in some (now expired) RSVP-TE 
drafts to represent the class-of-service C-Type.

The same problem exists for the SONET/SDH TSPEC.

I realize that expired drafts aren't supposed to have an impact on these 
kinds of decisions, but there are shipping products currently on the 
market that still use this C-Type.

The person responsible for this draft should make sure to choose a 
different value before the draft becomes an RFC.

-- David





Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2004 21:23:51 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Alex Zinin'" <[e-mail]>, "'Bill Fenner'" <[e-mail]>
Subject: Location Change: ITU-T Q14/15 Interim meeting
Date: Fri, 2 Jan 2004 16:21:32 -0500 
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"

Dear Mr. Kompella and Mr. Farrel,

I was informed by Mr. McDonough of Cisco that the Cisco facility will be closed on February 16. Since we need a full week to get the work done, we have decided to change the location of the meeting to Chicago, USA hosted by Tellabs. The meeting date remain unchange, i.e., February 16 - 20, 2004.

For those ccamp WG experts interested in attending the interim meeting, please let me know by 13 January 2004 and also indicate how many contributions (if any) you plan to submit. The cut-off date for submitting contributions to the meeting is 9 February 2004.

Regards,
Kam Lam
ITU-T Q14/15 Rapporteur
1-732-949-8338

>  -----Original Message-----
> From: 	Lam, Hing-Kam (Kam)  
> Sent:	Monday, December 08, 2003 3:08 PM
> To:	'Kireeti Kompella'; '[e-mail]'
> Cc:	[e-mail]; 'Alex Zinin'; 'Bill Fenner'; 'Scott 
> Bradner'; Wijnen, Bert (Bert)
> Subject:	ITU-T Q14/15 Interim meeting
> 
> Dear Mr. Kompella and Mr. Farrel,
> 
> In the ITU-T Q14/15 to CCAMP WG liaison (7th November 2003) 
> and in the 58th IETF meeting, 
> we invited the participation of the CCAMP WG experts to the 
> upcoming Q14/15 Interim meeting, 
> in the week of 16 February 2004 in North Carolina (or San Jose). 
> 
> Now I have received confirmation from the host that the location
> will be at the Cisco campus in Research Triangle Park 
> in Raleigh, North Carolina, USA. 
> 
> For those ccamp WG experts interested in attending the 
> interim meeting, please reply by 13 January 2004 and
> also indicate how many contributions (if any) you plan to submit.  
> The cut-off date for submitting contributions to the meeting 
> is 9 February 2004.
> 
> The terms of Reference of the Q14/15 Rapporteur meeting are:
> 	-	Continue development of G.fame (Framework for 
> ASON Management)
> 	-	Revision to G.7710, G.784, and G.874
> 	-	Revision to G.7713 and G.7713.x
> 	-	Revision to G.7714 and G.7714.1
> 	-	Continue the specification of G.7716
> 	-	Consideration of protocol-specific link-state 
> routing protocols
> 
> Further information about the meeting, including logistic and 
> travel information, will
> be available later on.
> 
> Regards, 
> Kam Lam (Q14/15 Rapporteur) 
> [phone]
>