Subject: Re: WG Review: Recharter of Common Control and Measurement Plane (ccamp)
From: Stephen J Trowbridge <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], Ronald Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Tue, 30 Sep 2003 16:20:50 -0600

Bert,
I think the remark you point out is a good "catch-all" for these
types of things and should remain, but I suggested the rewording
for a couple of reasons:
- The original sentence wording is clumsy and could be misunderstood:
"Identify requirements for signaling and routing for ASON not currently met ..."

When I see a statement like "Identify requirements for ...", I tend
to think of identifying new requirements, and if it is a new requirement,
of course it is not currently met, but when I get to the end of the
sentence, I understand that what must have really been meant by the
beginning of the sentence must have been:
"Identify WHICH requirements for signaling and routing for ASON ARE not
currently met". I think the addition of the words WHICH and ARE are
the minimum to make sure that the sentence is well constructed and not
misunderstood.

The reason I thought that mention of ITU-T explicitly in this bullet point
is that ASON requirements come from ITU-T - after all, we are talking
about (not necessarily IP) transport networks, and by making sure that
any such work is always joint with ITU-T, we can avoid the famous
question "What does this have to do with IP?"
Regards,
Steve

On 9/30/2003 3:51 PM, Wijnen, Bert (Bert) wrote:
> Ooops pressed send to quickly on previous email
> 
> Steve, do you not think this is covered by:
> 
>>   In doing this work, the WG will work closely with at least the following
>>   other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
>>   ITU-T.
>>
> 
> The idea is that the WG will cooperate with ITU-T on ALL items
> that warrant/need such coopration and which would improve the
> outcome.
> 
> Thanks,
> Bert 
> 
> 
>>-----Original Message-----
>>From: Stephen J Trowbridge [mailto:[email-masked]]
>>Sent: dinsdag 30 september 2003 23:36
>>To: [email-masked]
>>Cc: Ronald Bonica; Kireeti Kompella; [email-masked]
>>Subject: Re: WG Review: Recharter of Common Control and Measurement
>>Plane (ccamp)
>>
>>
>>All,
>>I suggest rewording the bullet point:
>>"- Identify requirements for signaling and routing for ASON 
>>not currently
>>       met; based on these, define mechanisms to address 
>>these requirements."
>>
>>to read:
>>"- Work with ITU-T to identify which ASON signaling and 
>>routing requirements are
>>        not met by existing protocol specifications.  Based 
>>upon results of this
>>assessment, define mechanisms to address identified gaps."
>>
>>I think this more accurately reflects the intent.
>>Regards,
>>Steve
>>
>>On 9/24/2003 1:29 PM, The IESG wrote:
>>
>>>A modified charter has been submitted for the Common 
>>
>>Control and Measurement Plane (ccamp)
>>
>>>Working Group in the Routing Area of the IETF. The IESG has 
>>
>>not made any determination as yet.
>>
>>>The following description was submitted, and is provided 
>>
>>for informational purposes only.
>>
>>>Please send your comments to the IESG mailing 
>>
>>([email-masked]) by September 30. 
>>
>>>   Common Control and Measurement Plane (ccamp)
>>>   --------------------------------------------
>>>
>>>   Current Status: Active Working Group
>>>   
>>>   Chair(s):
>>>       Ronald Bonica <[email-masked]>
>>>       Kireeti Kompella <[email-masked]>
>>>       
>>>   Routing Area Director(s):
>>>       Bill Fenner <[email-masked]>
>>>       Alex Zinin <[email-masked]>
>>>       
>>>   Routing Area Advisor:
>>>       Alex Zinin <[email-masked]>
>>>
>>>   Mailing Lists:
>>>   General Discussion: [email-masked]
>>>   To Subscribe: [email-masked]
>>>   In Body: subscribe ccamp
>>>   Archive: http://ops.ietf.org/lists/ccamp
>>>
>>>   Description of Working Group:
>>>
>>>   Organizational Overview
>>>
>>>   The CCAMP working group coordinates the work within the 
>>
>>IETF defining
>>
>>>   a common control plane and a separate common measurement 
>>
>>plane for
>>
>>>   physical path and core tunneling technologies of 
>>
>>Internet and telecom
>>
>>>   service providers (ISPs and SPs), e.g. O-O and O-E-O optical
>>>   switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
>>>   with the MPLS WG. In this context, measurement refers to the
>>>   acquisition and distribution of attributes relevant to 
>>
>>the setting up
>>
>>>   of tunnels and paths.
>>>
>>>   CCAMP WG work scope includes:
>>>
>>>   - Definition of protocol-independent metrics and parameters
>>>       (measurement attributes) for describing links and 
>>
>>paths that are
>>
>>>       required for routing and signaling. These will be 
>>
>>developed in
>>
>>>       conjunction with requests and requirements from 
>>
>>other WGs (e.g.
>>
>>>       TEWG) to insure overall usefulness.
>>>
>>>   - Definition of protocol(s) and extensions to them required for
>>>       link and path attribute measurement. Link Management 
>>
>>Protocol (LMP)
>>
>>>       is included here.
>>>
>>>   - Functional specification of extensions for routing 
>>
>>(OSPF, ISIS) and
>>
>>>       signalling (RSVP-TE) required for path 
>>
>>establishment. Protocol formats
>>
>>>       and procedures that embody these extensions will be 
>>
>>done jointly with
>>
>>>       the WGs supervising those protocols.
>>>
>>>   - Definition of the mechanisms required to determine the 
>>
>>route and
>>
>>>       properties of an established path (tunnel tracing).
>>>
>>>   - Definition of MIB modules relevant to the protocols 
>>
>>and extensions
>>
>>>       specified within the WG.
>>>
>>>   CCAMP WG currently works on the following tasks:
>>>           
>>>   - Define how the properties of network resources gathered by a
>>>       measurement protocol can be distributed in existing routing
>>>       protocols, such as OSPF and IS-IS. CCAMP defines the generic
>>>       description of the properties and how they are 
>>
>>distributed in OSPF.
>>
>>>       The specifics of distribution within IS-IS are being 
>>
>>addressed in
>>
>>>       the ISIS WG.
>>>
>>>   - Define signaling and routing mechanisms to make 
>>
>>possible the creation
>>
>>>       of paths that span multiple IGP areas, multiple 
>>
>>ASes, and multiple
>>
>>>       providers, including techniques for crankback.
>>>
>>>   - Define abstract link and path properties needed for 
>>
>>link and path
>>
>>>       protection. Specify signalling mechanisms for path 
>>
>>protection,
>>
>>>       diverse routing and fast path restoration. Ensure 
>>
>>that multi-layer
>>
>>>       path protection and restoration functions are 
>>
>>achievable using the
>>
>>>       defined signalling, routing, and measurement 
>>
>>protocols, either
>>
>>>       separately or in combination.
>>>
>>>   - Identify requirements for signaling and routing for 
>>
>>ASON not currently
>>
>>>       met; based on these, define mechanisms to address 
>>
>>these requirements.
>>
>>>   - Define a protocol that can determine the actual route and other
>>>       properties of paths set up by CCAMP signaling 
>>
>>protocols, as well
>>
>>>       as other types of tunnels (tunnel tracing).
>>>
>>>   In doing this work, the WG will work closely with at 
>>
>>least the following
>>
>>>   other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also 
>>
>>cooperate with
>>
>>>   ITU-T.
>>>
>>>   Goals and Milestones:
>>>   Done Post strawman WG goals and charter
>>>   Done Identify and document a limited set of candidate 
>>
>>solutions for signalling 
>>
>>>             and for measurement. Among candidate control 
>>
>>solutions to be considered are the
>>
>>>             existing GMPLS drafts
>>>   Done Build appropriate design teams
>>>   Done Submit WG document defining path setup portions of 
>>
>>common control plane protocol
>>
>>>   Done Submit WG document defining common measurement 
>>
>>plane protocol
>>
>>>   Nov 03 Submit LMP MIB to IESG
>>>   Dec 03 Submit GMPLS MIBs to IESG
>>>   Dec 03 Submit protection & restoration documents to IESG
>>>   Dec 03 Submit ASON signaling requirements doc to IESG
>>>   Jan 04 Produce CCAMP WG document for multi-area/AS 
>>
>>signaling and routing
>>
>>>   Jan 04 Produce CCAMP WG document for generic tunnel 
>>
>>tracing protocol
>>
>>>   Feb 04 Submit ASON routing requirements doc to IESG
>>>   Mar 04 Submit revised charter and milestones to IESG for 
>>
>>IESG consideration of more 
>>
>>>                 detailed deliverables and determination of 
>>
>>usefulness of continuation of WG
>>
>>>
>>
>>

Delivery-date: Tue, 30 Sep 2003 21:52:52 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Stephen J Trowbridge'" <[email-masked]>, [email-masked]
Cc: Ronald Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: WG Review: Recharter of Common Control and Measurement Plane  (ccamp)
Date: Tue, 30 Sep 2003 23:51:01 +0200

Ooops pressed send to quickly on previous email

Steve, do you not think this is covered by:
>    In doing this work, the WG will work closely with at least the following
>    other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
>    ITU-T.
> 
The idea is that the WG will cooperate with ITU-T on ALL items
that warrant/need such coopration and which would improve the
outcome.

Thanks,
Bert 

> -----Original Message-----
> From: Stephen J Trowbridge [mailto:[email-masked]]
> Sent: dinsdag 30 september 2003 23:36
> To: [email-masked]
> Cc: Ronald Bonica; Kireeti Kompella; [email-masked]
> Subject: Re: WG Review: Recharter of Common Control and Measurement
> Plane (ccamp)
> 
> 
> All,
> I suggest rewording the bullet point:
> "- Identify requirements for signaling and routing for ASON 
> not currently
>        met; based on these, define mechanisms to address 
> these requirements."
> 
> to read:
> "- Work with ITU-T to identify which ASON signaling and 
> routing requirements are
>         not met by existing protocol specifications.  Based 
> upon results of this
> assessment, define mechanisms to address identified gaps."
> 
> I think this more accurately reflects the intent.
> Regards,
> Steve
> 
> On 9/24/2003 1:29 PM, The IESG wrote:
> > A modified charter has been submitted for the Common 
> Control and Measurement Plane (ccamp)
> > Working Group in the Routing Area of the IETF. The IESG has 
> not made any determination as yet.
> > The following description was submitted, and is provided 
> for informational purposes only.
> > Please send your comments to the IESG mailing 
> ([email-masked]) by September 30. 
> > 
> >    Common Control and Measurement Plane (ccamp)
> >    --------------------------------------------
> > 
> >    Current Status: Active Working Group
> >    
> >    Chair(s):
> >        Ronald Bonica <[email-masked]>
> >        Kireeti Kompella <[email-masked]>
> >        
> >    Routing Area Director(s):
> >        Bill Fenner <[email-masked]>
> >        Alex Zinin <[email-masked]>
> >        
> >    Routing Area Advisor:
> >        Alex Zinin <[email-masked]>
> > 
> >    Mailing Lists:
> >    General Discussion: [email-masked]
> >    To Subscribe: [email-masked]
> >    In Body: subscribe ccamp
> >    Archive: http://ops.ietf.org/lists/ccamp
> > 
> >    Description of Working Group:
> > 
> >    Organizational Overview
> > 
> >    The CCAMP working group coordinates the work within the 
> IETF defining
> >    a common control plane and a separate common measurement 
> plane for
> >    physical path and core tunneling technologies of 
> Internet and telecom
> >    service providers (ISPs and SPs), e.g. O-O and O-E-O optical
> >    switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
> >    with the MPLS WG. In this context, measurement refers to the
> >    acquisition and distribution of attributes relevant to 
> the setting up
> >    of tunnels and paths.
> > 
> >    CCAMP WG work scope includes:
> > 
> >    - Definition of protocol-independent metrics and parameters
> >        (measurement attributes) for describing links and 
> paths that are
> >        required for routing and signaling. These will be 
> developed in
> >        conjunction with requests and requirements from 
> other WGs (e.g.
> >        TEWG) to insure overall usefulness.
> > 
> >    - Definition of protocol(s) and extensions to them required for
> >        link and path attribute measurement. Link Management 
> Protocol (LMP)
> >        is included here.
> > 
> >    - Functional specification of extensions for routing 
> (OSPF, ISIS) and
> >        signalling (RSVP-TE) required for path 
> establishment. Protocol formats
> >        and procedures that embody these extensions will be 
> done jointly with
> >        the WGs supervising those protocols.
> > 
> >    - Definition of the mechanisms required to determine the 
> route and
> >        properties of an established path (tunnel tracing).
> > 
> >    - Definition of MIB modules relevant to the protocols 
> and extensions
> >        specified within the WG.
> > 
> >    CCAMP WG currently works on the following tasks:
> >            
> >    - Define how the properties of network resources gathered by a
> >        measurement protocol can be distributed in existing routing
> >        protocols, such as OSPF and IS-IS. CCAMP defines the generic
> >        description of the properties and how they are 
> distributed in OSPF.
> >        The specifics of distribution within IS-IS are being 
> addressed in
> >        the ISIS WG.
> > 
> >    - Define signaling and routing mechanisms to make 
> possible the creation
> >        of paths that span multiple IGP areas, multiple 
> ASes, and multiple
> >        providers, including techniques for crankback.
> > 
> >    - Define abstract link and path properties needed for 
> link and path
> >        protection. Specify signalling mechanisms for path 
> protection,
> >        diverse routing and fast path restoration. Ensure 
> that multi-layer
> >        path protection and restoration functions are 
> achievable using the
> >        defined signalling, routing, and measurement 
> protocols, either
> >        separately or in combination.
> > 
> >    - Identify requirements for signaling and routing for 
> ASON not currently
> >        met; based on these, define mechanisms to address 
> these requirements.
> > 
> >    - Define a protocol that can determine the actual route and other
> >        properties of paths set up by CCAMP signaling 
> protocols, as well
> >        as other types of tunnels (tunnel tracing).
> > 
> >    In doing this work, the WG will work closely with at 
> least the following
> >    other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also 
> cooperate with
> >    ITU-T.
> > 
> >    Goals and Milestones:
> >    Done Post strawman WG goals and charter
> >    Done Identify and document a limited set of candidate 
> solutions for signalling 
> >              and for measurement. Among candidate control 
> solutions to be considered are the
> >              existing GMPLS drafts
> >    Done Build appropriate design teams
> >    Done Submit WG document defining path setup portions of 
> common control plane protocol
> >    Done Submit WG document defining common measurement 
> plane protocol
> >    Nov 03 Submit LMP MIB to IESG
> >    Dec 03 Submit GMPLS MIBs to IESG
> >    Dec 03 Submit protection & restoration documents to IESG
> >    Dec 03 Submit ASON signaling requirements doc to IESG
> >    Jan 04 Produce CCAMP WG document for multi-area/AS 
> signaling and routing
> >    Jan 04 Produce CCAMP WG document for generic tunnel 
> tracing protocol
> >    Feb 04 Submit ASON routing requirements doc to IESG
> >    Mar 04 Submit revised charter and milestones to IESG for 
> IESG consideration of more 
> >                  detailed deliverables and determination of 
> usefulness of continuation of WG
> > 
> > 
> 
> 
> 

Delivery-date: Tue, 30 Sep 2003 21:52:01 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Stephen J Trowbridge'" <[email-masked]>, [email-masked]
Cc: Ronald Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: WG Review: Recharter of Common Control and Measurement Plane  (ccamp)
Date: Tue, 30 Sep 2003 23:49:16 +0200

Steve, do you not think that this is covered by:

Thanks,
Bert 

> -----Original Message-----
> From: Stephen J Trowbridge [mailto:[email-masked]]
> Sent: dinsdag 30 september 2003 23:36
> To: [email-masked]
> Cc: Ronald Bonica; Kireeti Kompella; [email-masked]
> Subject: Re: WG Review: Recharter of Common Control and Measurement
> Plane (ccamp)
> 
> 
> All,
> I suggest rewording the bullet point:
> "- Identify requirements for signaling and routing for ASON 
> not currently
>        met; based on these, define mechanisms to address 
> these requirements."
> 
> to read:
> "- Work with ITU-T to identify which ASON signaling and 
> routing requirements are
>         not met by existing protocol specifications.  Based 
> upon results of this
> assessment, define mechanisms to address identified gaps."
> 
> I think this more accurately reflects the intent.
> Regards,
> Steve
> 
> On 9/24/2003 1:29 PM, The IESG wrote:
> > A modified charter has been submitted for the Common 
> Control and Measurement Plane (ccamp)
> > Working Group in the Routing Area of the IETF. The IESG has 
> not made any determination as yet.
> > The following description was submitted, and is provided 
> for informational purposes only.
> > Please send your comments to the IESG mailing 
> ([email-masked]) by September 30. 
> > 
> >    Common Control and Measurement Plane (ccamp)
> >    --------------------------------------------
> > 
> >    Current Status: Active Working Group
> >    
> >    Chair(s):
> >        Ronald Bonica <[email-masked]>
> >        Kireeti Kompella <[email-masked]>
> >        
> >    Routing Area Director(s):
> >        Bill Fenner <[email-masked]>
> >        Alex Zinin <[email-masked]>
> >        
> >    Routing Area Advisor:
> >        Alex Zinin <[email-masked]>
> > 
> >    Mailing Lists:
> >    General Discussion: [email-masked]
> >    To Subscribe: [email-masked]
> >    In Body: subscribe ccamp
> >    Archive: http://ops.ietf.org/lists/ccamp
> > 
> >    Description of Working Group:
> > 
> >    Organizational Overview
> > 
> >    The CCAMP working group coordinates the work within the 
> IETF defining
> >    a common control plane and a separate common measurement 
> plane for
> >    physical path and core tunneling technologies of 
> Internet and telecom
> >    service providers (ISPs and SPs), e.g. O-O and O-E-O optical
> >    switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
> >    with the MPLS WG. In this context, measurement refers to the
> >    acquisition and distribution of attributes relevant to 
> the setting up
> >    of tunnels and paths.
> > 
> >    CCAMP WG work scope includes:
> > 
> >    - Definition of protocol-independent metrics and parameters
> >        (measurement attributes) for describing links and 
> paths that are
> >        required for routing and signaling. These will be 
> developed in
> >        conjunction with requests and requirements from 
> other WGs (e.g.
> >        TEWG) to insure overall usefulness.
> > 
> >    - Definition of protocol(s) and extensions to them required for
> >        link and path attribute measurement. Link Management 
> Protocol (LMP)
> >        is included here.
> > 
> >    - Functional specification of extensions for routing 
> (OSPF, ISIS) and
> >        signalling (RSVP-TE) required for path 
> establishment. Protocol formats
> >        and procedures that embody these extensions will be 
> done jointly with
> >        the WGs supervising those protocols.
> > 
> >    - Definition of the mechanisms required to determine the 
> route and
> >        properties of an established path (tunnel tracing).
> > 
> >    - Definition of MIB modules relevant to the protocols 
> and extensions
> >        specified within the WG.
> > 
> >    CCAMP WG currently works on the following tasks:
> >            
> >    - Define how the properties of network resources gathered by a
> >        measurement protocol can be distributed in existing routing
> >        protocols, such as OSPF and IS-IS. CCAMP defines the generic
> >        description of the properties and how they are 
> distributed in OSPF.
> >        The specifics of distribution within IS-IS are being 
> addressed in
> >        the ISIS WG.
> > 
> >    - Define signaling and routing mechanisms to make 
> possible the creation
> >        of paths that span multiple IGP areas, multiple 
> ASes, and multiple
> >        providers, including techniques for crankback.
> > 
> >    - Define abstract link and path properties needed for 
> link and path
> >        protection. Specify signalling mechanisms for path 
> protection,
> >        diverse routing and fast path restoration. Ensure 
> that multi-layer
> >        path protection and restoration functions are 
> achievable using the
> >        defined signalling, routing, and measurement 
> protocols, either
> >        separately or in combination.
> > 
> >    - Identify requirements for signaling and routing for 
> ASON not currently
> >        met; based on these, define mechanisms to address 
> these requirements.
> > 
> >    - Define a protocol that can determine the actual route and other
> >        properties of paths set up by CCAMP signaling 
> protocols, as well
> >        as other types of tunnels (tunnel tracing).
> > 
> >    In doing this work, the WG will work closely with at 
> least the following
> >    other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also 
> cooperate with
> >    ITU-T.
> > 
> >    Goals and Milestones:
> >    Done Post strawman WG goals and charter
> >    Done Identify and document a limited set of candidate 
> solutions for signalling 
> >              and for measurement. Among candidate control 
> solutions to be considered are the
> >              existing GMPLS drafts
> >    Done Build appropriate design teams
> >    Done Submit WG document defining path setup portions of 
> common control plane protocol
> >    Done Submit WG document defining common measurement 
> plane protocol
> >    Nov 03 Submit LMP MIB to IESG
> >    Dec 03 Submit GMPLS MIBs to IESG
> >    Dec 03 Submit protection & restoration documents to IESG
> >    Dec 03 Submit ASON signaling requirements doc to IESG
> >    Jan 04 Produce CCAMP WG document for multi-area/AS 
> signaling and routing
> >    Jan 04 Produce CCAMP WG document for generic tunnel 
> tracing protocol
> >    Feb 04 Submit ASON routing requirements doc to IESG
> >    Mar 04 Submit revised charter and milestones to IESG for 
> IESG consideration of more 
> >                  detailed deliverables and determination of 
> usefulness of continuation of WG
> > 
> > 
> 
> 
> 

Delivery-date: Tue, 30 Sep 2003 21:39:33 +0000
Date: Tue, 30 Sep 2003 15:36:17 -0600
From: Stephen J Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: Ronald Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: WG Review: Recharter of Common Control and Measurement Plane (ccamp)

All,
I suggest rewording the bullet point:
"- Identify requirements for signaling and routing for ASON not currently
       met; based on these, define mechanisms to address these requirements."

to read:
"- Work with ITU-T to identify which ASON signaling and routing requirements are
        not met by existing protocol specifications.  Based upon results of this
assessment, define mechanisms to address identified gaps."

I think this more accurately reflects the intent.
Regards,
Steve

On 9/24/2003 1:29 PM, The IESG wrote:
> A modified charter has been submitted for the Common Control and Measurement Plane (ccamp)
> Working Group in the Routing Area of the IETF. The IESG has not made any determination as yet.
> The following description was submitted, and is provided for informational purposes only.
> Please send your comments to the IESG mailing ([email-masked]) by September 30. 
> 
>    Common Control and Measurement Plane (ccamp)
>    --------------------------------------------
> 
>    Current Status: Active Working Group
>    
>    Chair(s):
>        Ronald Bonica <[email-masked]>
>        Kireeti Kompella <[email-masked]>
>        
>    Routing Area Director(s):
>        Bill Fenner <[email-masked]>
>        Alex Zinin <[email-masked]>
>        
>    Routing Area Advisor:
>        Alex Zinin <[email-masked]>
> 
>    Mailing Lists:
>    General Discussion: [email-masked]
>    To Subscribe: [email-masked]
>    In Body: subscribe ccamp
>    Archive: http://ops.ietf.org/lists/ccamp
> 
>    Description of Working Group:
> 
>    Organizational Overview
> 
>    The CCAMP working group coordinates the work within the IETF defining
>    a common control plane and a separate common measurement plane for
>    physical path and core tunneling technologies of Internet and telecom
>    service providers (ISPs and SPs), e.g. O-O and O-E-O optical
>    switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
>    with the MPLS WG. In this context, measurement refers to the
>    acquisition and distribution of attributes relevant to the setting up
>    of tunnels and paths.
> 
>    CCAMP WG work scope includes:
> 
>    - Definition of protocol-independent metrics and parameters
>        (measurement attributes) for describing links and paths that are
>        required for routing and signaling. These will be developed in
>        conjunction with requests and requirements from other WGs (e.g.
>        TEWG) to insure overall usefulness.
> 
>    - Definition of protocol(s) and extensions to them required for
>        link and path attribute measurement. Link Management Protocol (LMP)
>        is included here.
> 
>    - Functional specification of extensions for routing (OSPF, ISIS) and
>        signalling (RSVP-TE) required for path establishment. Protocol formats
>        and procedures that embody these extensions will be done jointly with
>        the WGs supervising those protocols.
> 
>    - Definition of the mechanisms required to determine the route and
>        properties of an established path (tunnel tracing).
> 
>    - Definition of MIB modules relevant to the protocols and extensions
>        specified within the WG.
> 
>    CCAMP WG currently works on the following tasks:
>            
>    - Define how the properties of network resources gathered by a
>        measurement protocol can be distributed in existing routing
>        protocols, such as OSPF and IS-IS. CCAMP defines the generic
>        description of the properties and how they are distributed in OSPF.
>        The specifics of distribution within IS-IS are being addressed in
>        the ISIS WG.
> 
>    - Define signaling and routing mechanisms to make possible the creation
>        of paths that span multiple IGP areas, multiple ASes, and multiple
>        providers, including techniques for crankback.
> 
>    - Define abstract link and path properties needed for link and path
>        protection. Specify signalling mechanisms for path protection,
>        diverse routing and fast path restoration. Ensure that multi-layer
>        path protection and restoration functions are achievable using the
>        defined signalling, routing, and measurement protocols, either
>        separately or in combination.
> 
>    - Identify requirements for signaling and routing for ASON not currently
>        met; based on these, define mechanisms to address these requirements.
> 
>    - Define a protocol that can determine the actual route and other
>        properties of paths set up by CCAMP signaling protocols, as well
>        as other types of tunnels (tunnel tracing).
> 
>    In doing this work, the WG will work closely with at least the following
>    other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
>    ITU-T.
> 
>    Goals and Milestones:
>    Done Post strawman WG goals and charter
>    Done Identify and document a limited set of candidate solutions for signalling 
>              and for measurement. Among candidate control solutions to be considered are the
>              existing GMPLS drafts
>    Done Build appropriate design teams
>    Done Submit WG document defining path setup portions of common control plane protocol
>    Done Submit WG document defining common measurement plane protocol
>    Nov 03 Submit LMP MIB to IESG
>    Dec 03 Submit GMPLS MIBs to IESG
>    Dec 03 Submit protection & restoration documents to IESG
>    Dec 03 Submit ASON signaling requirements doc to IESG
>    Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
>    Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
>    Feb 04 Submit ASON routing requirements doc to IESG
>    Mar 04 Submit revised charter and milestones to IESG for IESG consideration of more 
>                  detailed deliverables and determination of usefulness of continuation of WG
> 
> 

Delivery-date: Tue, 30 Sep 2003 17:38:45 +0000
content-class: urn:content-classes:message
Subject: RE: FW: draft-ietf-ccamp-lmp
Date: Tue, 30 Sep 2003 10:35:23 -0700
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>, "Steve Bellovin (E-mail)" <[email-masked]>

Dimitri, Bert, Steve,
  The LMP version on the IETF website isn't up-to-date with the Security
Considerations changes because we were waiting for Steve's last comment
on the selector issue.  We ran the other changes by him back in August
and I believe they were addressed to his satisfaction.  I'll post the
latest version of LMP tonight/tomorrow with his new comments in mind.

Thanks,
Jonathan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]=20
> Sent: Tuesday, September 30, 2003 4:18 AM
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail); Jonathan Lang; Steve Bellovin (E-mail)
> Subject: Re: FW: draft-ietf-ccamp-lmp
>=20
>=20
> bert, what we've addressed what was on the tracker webpage
> i think this address what steve was referring here below
> but now you're right that additional text migth be needed
> if we further nail down flexibility, we'll come back with=20
> structured text proposal - also i've rephrased one of the=20
> comment made below - hope this will help jonathan -
>=20
>  >>4.
>  >>
>  >>   >     IKE is listed as a SHOULD, not a MUST, but the=20
> requirements
>  >>   >     mandate replay detection. You can't do that with
>  >>manual keying.
>  >>   >     (The requirements also mandate support for manual keying.)
>  >>   >     If replay protection is needed, either IKE must=20
> be required,
>  >>   >     or an application-specific replay protection=20
> mechanism must
>  >>   >     be defined.
>  >>   >
>  >>   > 16.1 now speaks of automatic key management, but it says
>  >>"should" (not
>  >>   > SHOULD), when it needs to say MUST, and point 2 of 16.2
>  >>still mandates
>  >>   > manual keying.  That has to be deleted.
>=20
> Section 16.1:
> - "Security mechanism should provide for well defined key
>    management schemes."
>=20
> to be replaced by:
> - "Security mechanism MUST provide for well defined key
>    management schemes."
>=20
> and
>=20
> Section 16.2:
> - "Implementations of LMP over IPsec protocol MUST support manual
>    keying mode and dynamic key exchange protocol using IKE."
>=20
> to be replaced by:
> - "Implementations of LMP over IPsec protocol MUST support
>    dynamic key exchange protocol using IKE."
>=20
> ---
>=20
> Wijnen, Bert (Bert) wrote:
> > [ I have cc:-ed the ccamp WG list again, we MUST keep the WG
> >   involved in this. Or at least allow any WG memebr to jump in
> >   if they have opinions or contributions]
> >=20
> > Thanks Dimitri.
> > I am not sure though that you have answered:
> >=20
> >=20
> >>   The document does not spell out the foundation for=20
> trust, and this
> >>   makes it difficult to understand what problem is being=20
> solved.  Why
> >>   does one need authentication of the IP address?  Why=20
> would one use
> >>   identity protection in this scenario?  And why not=20
> simply use one IKE
> >>   pathway as a MUST and be done with it (e.g. aggressive=20
> mode digital
> >>   signature)?  IKE's flexibility is there to support various usage
> >>   scenarios, and this seems like an ideal situation to=20
> say, "we know the
> >>   scenario and we don't need flexibility."  Nail it down.
> >=20
> >=20
> > Can you rty to compose an answer to that.
> > Possibly some text to address these questions needs to go in the
> > document itself as well.
> >=20
> > Thanks,
> > Bert
> >=20
> >=20
> >>-----Original Message-----
> >>From: [email-masked]=20
> >>[mailto:[email-masked]]
> >>Sent: dinsdag 30 september 2003 12:33
> >>To: Wijnen, Bert (Bert)
> >>Cc: Jonathan Lang; Steve Bellovin (E-mail)
> >>Subject: Re: FW: draft-ietf-ccamp-lmp
> >>
> >>
> >>hi bert, to address these i would propose the following (i've work=20
> >>this out with o.paridaens) - note we did this some time ago and=20
> >>propose this in order to move this forward, jonathan is=20
> free to take=20
> >>these into consideration or leave them:
> >>
> >>1.  > SMB:
> >>   > Most of my comments have not been addressed.  I said the
> >>following
> >>   > about 16.2:
> >>   >
> >>   >     The IPsec selectors are all SHOULDs -- what are the MUSTs?
> >>   >     Setting the port number to 0 means that all UDP=20
> >>traffic between
> >>   >     those nodes is protected -- is that right? I though the
> >>   >     document spoke of an LMP port.
> >>
> >>Section 16.2:
> >>- "2. IKE [RFC2409] SHOULD be used as the key exchange mechanism."
> >>
> >>to be replaced by:
> >>- "2. IKE [RFC2409] MUST be used as the key exchange mechanism."
> >>
> >>
> >>2.  > Point 2 still has SHOULD instead of MUST, and still
> >>says UDP port 0.
> >>
> >>note: i don't know about steve's views here but it seems to=20
> accept the=20
> >>previous version of it
> >>
> >>Section 16.2:
> >>- "The identities SHOULD be of type IP addresses
> >>     and the value of the identities SHOULD be the IP=20
> addresses of the
> >>     communicating peers. The protocol field SHOULD be IP=20
> protocol UDP
> >>     (17). The port field SHOULD be set to zero to indicate
> >>port fields
> >>     should be ignored."
> >>
> >>to be replaced by:
> >>- "The identities MUST be of type IP addresses
> >>     and the value of the identities MUST be the IP addresses of the
> >>     communicating peers. The protocol field MUST be IP protocol UDP
> >>     (17). The port field SHOULD be set to the LMP UDP port
> >>as assigned
> >>     by IANA."
> >>
> >>   >     The channel identifer is part of the payload, not=20
> >>the IP or UDP
> >>   >     headers, and thus can't be a selector.
> >>   >
> >>   > There is still text about the channel identifier, in a
> >>context that
> >>   > makes it appear like part of the selector.
> >>
> >>3. Section 16.2:
> >>
> >>- "In LMP exchanges, the channel identifier user by the peer is not
> >>     known beforehand, and hence cannot be used in the SA."
> >>
> >>is suggested to be to be removed.
> >>
> >>4.
> >>
> >>   >     IKE is listed as a SHOULD, not a MUST, but the requirements
> >>   >     mandate replay detection. You can't do that with=20
> >>manual keying.
> >>   >     (The requirements also mandate support for manual keying.)
> >>   >     If replay protection is needed, either IKE must be=20
> required,
> >>   >     or an application-specific replay protection mechanism must
> >>   >     be defined.
> >>   >
> >>   > 16.1 now speaks of automatic key management, but it says
> >>"should" (not
> >>   > SHOULD), when it needs to say MUST, and point 2 of 16.2=20
> >>still mandates
> >>   > manual keying.  That has to be deleted.
> >>
> >>Section 16.1:
> >>- "Security mechanism should provide for well defined key
> >>management schemes."
> >>
> >>to be replaced by:
> >>- "Security mechanism MUST provide for well defined key
> >>management schemes."
> >>
> >>and
> >>
> >>Section 16.2:
> >>- "Implementations of LMP over IPsec protocol MUST support manual
> >>     keying mode and dynamic key exchange protocol using IKE."
> >>
> >>to be replaced by:
> >>- "Implementations of LMP over IPsec protocol MUST support manual
> >>     dynamic key exchange protocol using IKE."
> >>
> >>5. IPSEC Tunnels
> >>
> >> >       All LMP messages are expected to be sent over the
> >>IPsec tunnel.
> >> >       However, all LMP messages should be sent through the
> >>IPsec tunnel,
> >> >       which will have been established earlier or on an
> >>as-needed basis.
> >>
> >>proposal to rephrase but might need to be discussed in case=20
> of change=20
> >>of semantic:
> >>
> >>"All LMP messages should be sent through the IPsec tunnel,=20
> which will=20
> >>have been established earlier or on an as-needed basis."
> >>
> >>---
> >>
> >>Wijnen, Bert (Bert) wrote:
> >>
> >>
> >>>I think it is important that the whole ccamp list sees=20
> this. If there=20
> >>>are people who want to help Jonathan formulating an answer and=20
> >>>possible updates to the draft, please do so!
> >>>
> >>>Thanks,
> >>>Bert
> >>>
> >>>-----Original Message-----
> >>>From: Steven M. Bellovin [mailto:[email-masked]]
> >>>Sent: maandag 29 september 2003 20:26
> >>>To: Wijnen, Bert (Bert)
> >>>Cc: 'Jonathan Lang'
> >>>Subject: Re: draft-ietf-ccamp-lmp
> >>>
> >>>
> >>>In message
> >>
> >><[email-masked]
> >>
> >>>om>, "Wijnen, Bert (Bert)" writes:
> >>>
> >>>
> >>>>>>Steve, to be fair to Jonathan and the WG, I do think=20
> that this is=20
> >>>>>>taking too long now. PLEASE ?
> >>>>>>
> >>>>>
> >>>>>Sorry, I'd meant to send you this on Friday.
> >>>>>
> >>>>>I've been unable to get much input from the security
> >>
> >>directorate on my
> >>
> >>>>>main complaint, but that's a problem I'll have to deal
> >>
> >>with. I did get
> >>
> >>>>>a few comparatively minor issues, which I'll write up and
> >>
> >>forward to
> >>
> >>>>>you in the next day or two.  They'll likely require a new I-D to
> >>>>>clarify a few points, but (I believe) nothing substantive;=20
> >>
> >>it's just
> >>
> >>>>>that there are too many to make an RFC Editor's note practical.
> >>>>>
> >>>>
> >>>>Steve, pls make sure your comment are against the latest=20
> revision,=20
> >>>>draft-ietf-ccamp-lmp-09.txt
> >>>
> >>>
> >>>
> >>>After checking the comments I received against the latest
> >>
> >>version, I'm
> >>
> >>>more confused than ever, since some of them don't seem to
> >>
> >>apply to any
> >>
> >>>version of the document...  That said, there are two
> >>
> >>comments that do
> >>
> >>>seem to apply:
> >>>
> >>>   The document does not spell out the foundation for
> >>
> >>trust, and this
> >>
> >>>   makes it difficult to understand what problem is being
> >>
> >>solved.  Why
> >>
> >>>   does one need authentication of the IP address?  Why
> >>
> >>would one use
> >>
> >>>   identity protection in this scenario?  And why not
> >>
> >>simply use one IKE
> >>
> >>>   pathway as a MUST and be done with it (e.g. aggressive
> >>
> >>mode digital
> >>
> >>>   signature)?  IKE's flexibility is there to support various usage
> >>>   scenarios, and this seems like an ideal situation to
> >>
> >>say, "we know the
> >>
> >>>   scenario and we don't need flexibility."  Nail it down.
> >>>
> >>>and
> >>>
> >>>   I admit the following completely defeats me:
> >>>  =20
> >>>      All LMP messages are expected to be sent over the
> >>
> >>IPsec tunnel.
> >>
> >>>      However, all LMP messages should be sent through the
> >>
> >>IPsec tunnel,
> >>
> >>>      which will have been established earlier or on an
> >>
> >>as-needed basis.
> >>
> >>>  =20
> >>>   "over" vs. "through"?  "However" as opposed to what?
> >>>
> >>>I'm still unhappy about using port number zero, but I'll
> >>
> >>let that pass.
> >>
> >>>
> >>>		--Steve Bellovin, http://www.research.att.com/~smb
> >>>
> >>>
> >>
> >>--
> >>Papadimitriou Dimitri
> >>E-mail : [email-masked]
> >>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> >>E-mail : [email-masked]
> >>Public : http://psg.com/~dpapadimitriou/
> >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>Phone  : +32 3 240-8491
> >>
> >>
>=20
> --=20
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
>=20
>=20

Delivery-date: Tue, 30 Sep 2003 11:18:23 +0000
Date: Tue, 30 Sep 2003 13:18:04 +0200
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>, Jonathan Lang <[email-masked]>, "Steve Bellovin (E-mail)" <[email-masked]>
Subject: Re: FW: draft-ietf-ccamp-lmp

bert, what we've addressed what was on the tracker webpage
i think this address what steve was referring here below
but now you're right that additional text migth be needed
if we further nail down flexibility, we'll come back with
structured text proposal - also i've rephrased one of the
comment made below - hope this will help jonathan -

 >>4.
 >>
 >>   >     IKE is listed as a SHOULD, not a MUST, but the requirements
 >>   >     mandate replay detection. You can't do that with
 >>manual keying.
 >>   >     (The requirements also mandate support for manual keying.)
 >>   >     If replay protection is needed, either IKE must be required,
 >>   >     or an application-specific replay protection mechanism must
 >>   >     be defined.
 >>   >
 >>   > 16.1 now speaks of automatic key management, but it says
 >>"should" (not
 >>   > SHOULD), when it needs to say MUST, and point 2 of 16.2
 >>still mandates
 >>   > manual keying.  That has to be deleted.

Section 16.1:
- "Security mechanism should provide for well defined key
   management schemes."

to be replaced by:
- "Security mechanism MUST provide for well defined key
   management schemes."

and

Section 16.2:
- "Implementations of LMP over IPsec protocol MUST support manual
   keying mode and dynamic key exchange protocol using IKE."

to be replaced by:
- "Implementations of LMP over IPsec protocol MUST support
   dynamic key exchange protocol using IKE."

---

Wijnen, Bert (Bert) wrote:
> [ I have cc:-ed the ccamp WG list again, we MUST keep the WG
>   involved in this. Or at least allow any WG memebr to jump in
>   if they have opinions or contributions]
> 
> Thanks Dimitri. 
> I am not sure though that you have answered:
> 
> 
>>   The document does not spell out the foundation for trust, and this
>>   makes it difficult to understand what problem is being solved.  Why
>>   does one need authentication of the IP address?  Why would one use
>>   identity protection in this scenario?  And why not simply use one IKE
>>   pathway as a MUST and be done with it (e.g. aggressive mode digital
>>   signature)?  IKE's flexibility is there to support various usage
>>   scenarios, and this seems like an ideal situation to say, "we know the
>>   scenario and we don't need flexibility."  Nail it down.
> 
> 
> Can you rty to compose an answer to that. 
> Possibly some text to address these questions needs to go in the
> document itself as well.
> 
> Thanks,
> Bert 
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: dinsdag 30 september 2003 12:33
>>To: Wijnen, Bert (Bert)
>>Cc: Jonathan Lang; Steve Bellovin (E-mail)
>>Subject: Re: FW: draft-ietf-ccamp-lmp
>>
>>
>>hi bert, to address these i would propose the following (i've
>>work this out with o.paridaens) - note we did this some time
>>ago and propose this in order to move this forward, jonathan
>>is free to take these into consideration or leave them:
>>
>>1.  > SMB:
>>   > Most of my comments have not been addressed.  I said the 
>>following
>>   > about 16.2:
>>   >
>>   >     The IPsec selectors are all SHOULDs -- what are the MUSTs?
>>   >     Setting the port number to 0 means that all UDP 
>>traffic between
>>   >     those nodes is protected -- is that right? I though the
>>   >     document spoke of an LMP port.
>>
>>Section 16.2:
>>- "2. IKE [RFC2409] SHOULD be used as the key exchange mechanism."
>>
>>to be replaced by:
>>- "2. IKE [RFC2409] MUST be used as the key exchange mechanism."
>>
>>
>>2.  > Point 2 still has SHOULD instead of MUST, and still 
>>says UDP port 0.
>>
>>note: i don't know about steve's views here but it seems to accept
>>the previous version of it
>>
>>Section 16.2:
>>- "The identities SHOULD be of type IP addresses
>>     and the value of the identities SHOULD be the IP addresses of the
>>     communicating peers. The protocol field SHOULD be IP protocol UDP
>>     (17). The port field SHOULD be set to zero to indicate 
>>port fields
>>     should be ignored."
>>
>>to be replaced by:
>>- "The identities MUST be of type IP addresses
>>     and the value of the identities MUST be the IP addresses of the
>>     communicating peers. The protocol field MUST be IP protocol UDP
>>     (17). The port field SHOULD be set to the LMP UDP port 
>>as assigned
>>     by IANA."
>>
>>   >     The channel identifer is part of the payload, not 
>>the IP or UDP
>>   >     headers, and thus can't be a selector.
>>   >
>>   > There is still text about the channel identifier, in a 
>>context that
>>   > makes it appear like part of the selector.
>>
>>3. Section 16.2:
>>
>>- "In LMP exchanges, the channel identifier user by the peer is not
>>     known beforehand, and hence cannot be used in the SA."
>>
>>is suggested to be to be removed.
>>
>>4.
>>
>>   >     IKE is listed as a SHOULD, not a MUST, but the requirements
>>   >     mandate replay detection. You can't do that with 
>>manual keying.
>>   >     (The requirements also mandate support for manual keying.)
>>   >     If replay protection is needed, either IKE must be required,
>>   >     or an application-specific replay protection mechanism must
>>   >     be defined.
>>   >
>>   > 16.1 now speaks of automatic key management, but it says 
>>"should" (not
>>   > SHOULD), when it needs to say MUST, and point 2 of 16.2 
>>still mandates
>>   > manual keying.  That has to be deleted.
>>
>>Section 16.1:
>>- "Security mechanism should provide for well defined key 
>>management schemes."
>>
>>to be replaced by:
>>- "Security mechanism MUST provide for well defined key 
>>management schemes."
>>
>>and
>>
>>Section 16.2:
>>- "Implementations of LMP over IPsec protocol MUST support manual
>>     keying mode and dynamic key exchange protocol using IKE."
>>
>>to be replaced by:
>>- "Implementations of LMP over IPsec protocol MUST support manual
>>     dynamic key exchange protocol using IKE."
>>
>>5. IPSEC Tunnels
>>
>> >       All LMP messages are expected to be sent over the 
>>IPsec tunnel.
>> >       However, all LMP messages should be sent through the 
>>IPsec tunnel,
>> >       which will have been established earlier or on an 
>>as-needed basis.
>>
>>proposal to rephrase but might need to be discussed in case of
>>change of semantic:
>>
>>"All LMP messages should be sent through the IPsec tunnel, which
>>will have been established earlier or on an as-needed basis."
>>
>>---
>>
>>Wijnen, Bert (Bert) wrote:
>>
>>
>>>I think it is important that the whole ccamp list sees this.
>>>If there are people who want to help Jonathan formulating an
>>>answer and possible updates to the draft, please do so!
>>>
>>>Thanks,
>>>Bert 
>>>
>>>-----Original Message-----
>>>From: Steven M. Bellovin [mailto:[email-masked]]
>>>Sent: maandag 29 september 2003 20:26
>>>To: Wijnen, Bert (Bert)
>>>Cc: 'Jonathan Lang'
>>>Subject: Re: draft-ietf-ccamp-lmp 
>>>
>>>
>>>In message 
>>
>><[email-masked]
>>
>>>om>, "Wijnen, Bert (Bert)" writes:
>>>
>>>
>>>>>>Steve, to be fair to Jonathan and the WG, I do think that
>>>>>>this is taking too long now. PLEASE ?
>>>>>>
>>>>>
>>>>>Sorry, I'd meant to send you this on Friday.
>>>>>
>>>>>I've been unable to get much input from the security 
>>
>>directorate on my 
>>
>>>>>main complaint, but that's a problem I'll have to deal 
>>
>>with. I did get 
>>
>>>>>a few comparatively minor issues, which I'll write up and 
>>
>>forward to 
>>
>>>>>you in the next day or two.  They'll likely require a new I-D to 
>>>>>clarify a few points, but (I believe) nothing substantive; 
>>
>>it's just 
>>
>>>>>that there are too many to make an RFC Editor's note practical.
>>>>>
>>>>
>>>>Steve, pls make sure your comment are against the latest revision,
>>>>draft-ietf-ccamp-lmp-09.txt
>>>
>>>
>>>
>>>After checking the comments I received against the latest 
>>
>>version, I'm  
>>
>>>more confused than ever, since some of them don't seem to 
>>
>>apply to any 
>>
>>>version of the document...  That said, there are two 
>>
>>comments that do 
>>
>>>seem to apply:
>>>
>>>   The document does not spell out the foundation for 
>>
>>trust, and this
>>
>>>   makes it difficult to understand what problem is being 
>>
>>solved.  Why
>>
>>>   does one need authentication of the IP address?  Why 
>>
>>would one use
>>
>>>   identity protection in this scenario?  And why not 
>>
>>simply use one IKE
>>
>>>   pathway as a MUST and be done with it (e.g. aggressive 
>>
>>mode digital
>>
>>>   signature)?  IKE's flexibility is there to support various usage
>>>   scenarios, and this seems like an ideal situation to 
>>
>>say, "we know the
>>
>>>   scenario and we don't need flexibility."  Nail it down.
>>>
>>>and
>>>
>>>   I admit the following completely defeats me:
>>>   
>>>      All LMP messages are expected to be sent over the 
>>
>>IPsec tunnel.
>>
>>>      However, all LMP messages should be sent through the 
>>
>>IPsec tunnel,
>>
>>>      which will have been established earlier or on an 
>>
>>as-needed basis.
>>
>>>   
>>>   "over" vs. "through"?  "However" as opposed to what?
>>>
>>>I'm still unhappy about using port number zero, but I'll 
>>
>>let that pass.
>>
>>>
>>>		--Steve Bellovin, http://www.research.att.com/~smb
>>>
>>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : [email-masked]
>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>E-mail : [email-masked]
>>Public : http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : +32 3 240-8491
>>
>>

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 30 Sep 2003 10:44:12 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ccamp-wg (E-mail)" <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, "Steve Bellovin (E-mail)" <[email-masked]>
Subject: RE: FW: draft-ietf-ccamp-lmp
Date: Tue, 30 Sep 2003 12:39:58 +0200

[ I have cc:-ed the ccamp WG list again, we MUST keep the WG
  involved in this. Or at least allow any WG memebr to jump in
  if they have opinions or contributions]

Thanks Dimitri. 
I am not sure though that you have answered:

>    The document does not spell out the foundation for trust, and this
>    makes it difficult to understand what problem is being solved.  Why
>    does one need authentication of the IP address?  Why would one use
>    identity protection in this scenario?  And why not simply use one IKE
>    pathway as a MUST and be done with it (e.g. aggressive mode digital
>    signature)?  IKE's flexibility is there to support various usage
>    scenarios, and this seems like an ideal situation to say, "we know the
>    scenario and we don't need flexibility."  Nail it down.

Can you rty to compose an answer to that. 
Possibly some text to address these questions needs to go in the
document itself as well.

Thanks,
Bert 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: dinsdag 30 september 2003 12:33
> To: Wijnen, Bert (Bert)
> Cc: Jonathan Lang; Steve Bellovin (E-mail)
> Subject: Re: FW: draft-ietf-ccamp-lmp
> 
> 
> hi bert, to address these i would propose the following (i've
> work this out with o.paridaens) - note we did this some time
> ago and propose this in order to move this forward, jonathan
> is free to take these into consideration or leave them:
> 
> 1.  > SMB:
>    > Most of my comments have not been addressed.  I said the 
> following
>    > about 16.2:
>    >
>    >     The IPsec selectors are all SHOULDs -- what are the MUSTs?
>    >     Setting the port number to 0 means that all UDP 
> traffic between
>    >     those nodes is protected -- is that right? I though the
>    >     document spoke of an LMP port.
> 
> Section 16.2:
> - "2. IKE [RFC2409] SHOULD be used as the key exchange mechanism."
> 
> to be replaced by:
> - "2. IKE [RFC2409] MUST be used as the key exchange mechanism."
> 
> 
> 2.  > Point 2 still has SHOULD instead of MUST, and still 
> says UDP port 0.
> 
> note: i don't know about steve's views here but it seems to accept
> the previous version of it
> 
> Section 16.2:
> - "The identities SHOULD be of type IP addresses
>      and the value of the identities SHOULD be the IP addresses of the
>      communicating peers. The protocol field SHOULD be IP protocol UDP
>      (17). The port field SHOULD be set to zero to indicate 
> port fields
>      should be ignored."
> 
> to be replaced by:
> - "The identities MUST be of type IP addresses
>      and the value of the identities MUST be the IP addresses of the
>      communicating peers. The protocol field MUST be IP protocol UDP
>      (17). The port field SHOULD be set to the LMP UDP port 
> as assigned
>      by IANA."
> 
>    >     The channel identifer is part of the payload, not 
> the IP or UDP
>    >     headers, and thus can't be a selector.
>    >
>    > There is still text about the channel identifier, in a 
> context that
>    > makes it appear like part of the selector.
> 
> 3. Section 16.2:
> 
> - "In LMP exchanges, the channel identifier user by the peer is not
>      known beforehand, and hence cannot be used in the SA."
> 
> is suggested to be to be removed.
> 
> 4.
> 
>    >     IKE is listed as a SHOULD, not a MUST, but the requirements
>    >     mandate replay detection. You can't do that with 
> manual keying.
>    >     (The requirements also mandate support for manual keying.)
>    >     If replay protection is needed, either IKE must be required,
>    >     or an application-specific replay protection mechanism must
>    >     be defined.
>    >
>    > 16.1 now speaks of automatic key management, but it says 
> "should" (not
>    > SHOULD), when it needs to say MUST, and point 2 of 16.2 
> still mandates
>    > manual keying.  That has to be deleted.
> 
> Section 16.1:
> - "Security mechanism should provide for well defined key 
> management schemes."
> 
> to be replaced by:
> - "Security mechanism MUST provide for well defined key 
> management schemes."
> 
> and
> 
> Section 16.2:
> - "Implementations of LMP over IPsec protocol MUST support manual
>      keying mode and dynamic key exchange protocol using IKE."
> 
> to be replaced by:
> - "Implementations of LMP over IPsec protocol MUST support manual
>      dynamic key exchange protocol using IKE."
> 
> 5. IPSEC Tunnels
> 
>  >       All LMP messages are expected to be sent over the 
> IPsec tunnel.
>  >       However, all LMP messages should be sent through the 
> IPsec tunnel,
>  >       which will have been established earlier or on an 
> as-needed basis.
> 
> proposal to rephrase but might need to be discussed in case of
> change of semantic:
> 
> "All LMP messages should be sent through the IPsec tunnel, which
> will have been established earlier or on an as-needed basis."
> 
> ---
> 
> Wijnen, Bert (Bert) wrote:
> 
> > I think it is important that the whole ccamp list sees this.
> > If there are people who want to help Jonathan formulating an
> > answer and possible updates to the draft, please do so!
> > 
> > Thanks,
> > Bert 
> > 
> > -----Original Message-----
> > From: Steven M. Bellovin [mailto:[email-masked]]
> > Sent: maandag 29 september 2003 20:26
> > To: Wijnen, Bert (Bert)
> > Cc: 'Jonathan Lang'
> > Subject: Re: draft-ietf-ccamp-lmp 
> > 
> > 
> > In message 
> <[email-masked]
> > om>, "Wijnen, Bert (Bert)" writes:
> > 
> >>>>Steve, to be fair to Jonathan and the WG, I do think that
> >>>>this is taking too long now. PLEASE ?
> >>>>
> >>>
> >>>Sorry, I'd meant to send you this on Friday.
> >>>
> >>>I've been unable to get much input from the security 
> directorate on my 
> >>>main complaint, but that's a problem I'll have to deal 
> with. I did get 
> >>>a few comparatively minor issues, which I'll write up and 
> forward to 
> >>>you in the next day or two.  They'll likely require a new I-D to 
> >>>clarify a few points, but (I believe) nothing substantive; 
> it's just 
> >>>that there are too many to make an RFC Editor's note practical.
> >>>
> >>
> >>Steve, pls make sure your comment are against the latest revision,
> >>draft-ietf-ccamp-lmp-09.txt
> > 
> > 
> > 
> > After checking the comments I received against the latest 
> version, I'm  
> > more confused than ever, since some of them don't seem to 
> apply to any 
> > version of the document...  That said, there are two 
> comments that do 
> > seem to apply:
> > 
> >    The document does not spell out the foundation for 
> trust, and this
> >    makes it difficult to understand what problem is being 
> solved.  Why
> >    does one need authentication of the IP address?  Why 
> would one use
> >    identity protection in this scenario?  And why not 
> simply use one IKE
> >    pathway as a MUST and be done with it (e.g. aggressive 
> mode digital
> >    signature)?  IKE's flexibility is there to support various usage
> >    scenarios, and this seems like an ideal situation to 
> say, "we know the
> >    scenario and we don't need flexibility."  Nail it down.
> > 
> > and
> > 
> >    I admit the following completely defeats me:
> >    
> >       All LMP messages are expected to be sent over the 
> IPsec tunnel.
> >       However, all LMP messages should be sent through the 
> IPsec tunnel,
> >       which will have been established earlier or on an 
> as-needed basis.
> >    
> >    "over" vs. "through"?  "However" as opposed to what?
> > 
> > I'm still unhappy about using port number zero, but I'll 
> let that pass.
> > 
> > 
> > 		--Steve Bellovin, http://www.research.att.com/~smb
> > 
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 
> 

Delivery-date: Tue, 30 Sep 2003 09:03:53 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Cc: "Steve Bellovin (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-lmp 
Date: Tue, 30 Sep 2003 11:01:12 +0200

I think it is important that the whole ccamp list sees this.
If there are people who want to help Jonathan formulating an
answer and possible updates to the draft, please do so!

Thanks,
Bert 

-----Original Message-----
From: Steven M. Bellovin [mailto:[email-masked]]
Sent: maandag 29 september 2003 20:26
To: Wijnen, Bert (Bert)
Cc: 'Jonathan Lang'
Subject: Re: draft-ietf-ccamp-lmp 

In message <[email-masked]
om>, "Wijnen, Bert (Bert)" writes:
>> >Steve, to be fair to Jonathan and the WG, I do think that
>> >this is taking too long now. PLEASE ?
>> >
>> 
>> Sorry, I'd meant to send you this on Friday.
>> 
>> I've been unable to get much input from the security directorate on my 
>> main complaint, but that's a problem I'll have to deal with. I did get 
>> a few comparatively minor issues, which I'll write up and forward to 
>> you in the next day or two.  They'll likely require a new I-D to 
>> clarify a few points, but (I believe) nothing substantive; it's just 
>> that there are too many to make an RFC Editor's note practical.
>> 
>Steve, pls make sure your comment are against the latest revision,
>draft-ietf-ccamp-lmp-09.txt

After checking the comments I received against the latest version, I'm  
more confused than ever, since some of them don't seem to apply to any 
version of the document...  That said, there are two comments that do 
seem to apply:

   The document does not spell out the foundation for trust, and this
   makes it difficult to understand what problem is being solved.  Why
   does one need authentication of the IP address?  Why would one use
   identity protection in this scenario?  And why not simply use one IKE
   pathway as a MUST and be done with it (e.g. aggressive mode digital
   signature)?  IKE's flexibility is there to support various usage
   scenarios, and this seems like an ideal situation to say, "we know the
   scenario and we don't need flexibility."  Nail it down.

and

   I admit the following completely defeats me:
   
      All LMP messages are expected to be sent over the IPsec tunnel.
      However, all LMP messages should be sent through the IPsec tunnel,
      which will have been established earlier or on an as-needed basis.
   
   "over" vs. "through"?  "However" as opposed to what?

I'm still unhappy about using port number zero, but I'll let that pass.

		--Steve Bellovin, http://www.research.att.com/~smb

Delivery-date: Tue, 30 Sep 2003 07:23:54 +0000
Sensitivity: 
Subject: Upgrade of a classical Transport network to a GMPLS one
To: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Tue, 30 Sep 2003 09:18:33 +0200

Hi all,
               are there out any procedure in order to upgrade a non GMPLS
transport network to a GMPLS one?

Suppose a Network operator wants to introduce GMPLS in its transport
network, that is running thousands of circuts, how can he move the NMS
created circuit already present in its network under the control of GMPLS?

Is this issue an implementator specific one or can be covered by CCAMP?

Regards,

Diego

Delivery-date: Mon, 29 Sep 2003 17:27:23 +0000
Reply-To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Martin Dubuc'" <[email-masked]>
Cc: "'Ccamp-wg \(E-mail\)'" <[email-masked]>
Subject: RE: LMP MIB revision 6
Date: Mon, 29 Sep 2003 13:20:58 -0400
Organization: Cisco Systems, inc.

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
>Sent: Sunday, September 28, 2003 5:01 AM
>To: 'Martin Dubuc'; Wijnen, Bert (Bert)
>Cc: Ccamp-wg (E-mail)
>Subject: RE: LMP MIB revision 6
>
>
>So below you give me a lot of explanation what kind of 
>notifications can get generated and how many would be generated 
>under which conditions. I think that is exactly the type of
>information that we would like to see somewhere (best uis probably
>in DESCRITPION clauses so that it stays with the MIB module when
>it gets extracted). You might also add some warnings that people
>should be carefull NOT to configure too short verification times
>and at least take the potential notification rate into consideration
>when doing so. 

	Sounds fair to me.

>The question then becomes: should there be an object to throttle
>the max rate?

	Yes, there should. We added one to the other MIBs.

	--Tom

>
>Thanks,
>Bert 
>
>> -----Original Message-----
>> From: Martin Dubuc [mailto:[email-masked]]
>> Sent: zondag 28 september 2003 3:31
>> To: Wijnen, Bert (Bert)
>> Cc: Ccamp-wg (E-mail)
>> Subject: Re: LMP MIB revision 6
>> 
>> 
>> Bert,
>> 
>> I am almost done updating the LMP MIB to address your 
>> comments. However, I
>> am stuck on comment 16 (notifications). You would like to 
>> know what rate per
>> second we should fear in the worst conditions. It is very 
>difficult to
>> answer this one. I have thought a lot about this, and I don't 
>> think I can
>> come up with a number. The notification rate distribution 
>> depends too much
>> on the type of network, the size of network, the network 
>> configuration, the
>> type of the links, the reliability of the network, etc.
>> 
>> I can add some text in some of the notifications to explain 
>> some of the
>> expected limits (for instance, there are some notifications 
>> that can only
>> happen once per link verification interval), but to give one 
>> number for the
>> worst case is next to impossible.
>> 
>> In general, I think the LMP MIB is not resource hungry when 
>> it comes to
>> notifications because all of the transitions are state driven 
>> (meaning the
>> notification are only sent when the system changes state), 
>> cover some very
>> specific error conditions (like configuration errors) and are mainly
>> associated with entities that are limited in numbers (TE 
>> links and control
>> channels). The only notifications that might have caused a 
>> problem are the
>> ones associated with data links (because of the potential 
>> high number of
>> data links) but since the data links can happen only once per 
>> data link per
>> link verification interval, the notification rate should be 
>> sustainable if
>> one chooses an appropriate link verification interval and 
>> engineers the
>> network properly. For instance, a network of 100 nodes with 5 
>> links of 128
>> wavelengths each and a link verification of 1 minute with say 
>> 10% of the
>> links failed at any given time would have 1 notification per 
>> second sent
>> from each node (100 notifications per second for the whole 
>> network). The
>> rest of the notifications are negligeable compared to this number.
>> 
>> Martin
>> 
>> ----- Original Message -----
>> From: "Wijnen, Bert (Bert)" <[email-masked]>
>> To: "'Martin Dubuc'" <[email-masked]>
>> Cc: "Ccamp-wg (E-mail)" <[email-masked]>
>> Sent: Monday, September 01, 2003 4:42 PM
>> Subject: RE: LMP MIB revision 6
>> 
>> 
>> > Well well...
>> >
>> > SMICng says:
>> >    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
>> >       "lmpDataLinkPropertyMismatch" is an index for a table
>> >    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
>> >       "lmpTeLinkDegraded" is an index for a table
>> >    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
>> >       "lmpTeLinkNotDegraded" is an index for a table
>> >    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
>> >       "lmpDataLinkVerificationFailure" is an index for a table
>> >    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
>> >       specified for "lmpCcOperStatus"
>> >    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
>> >       specified for "lmpTeLinkOperStatus"
>> >    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
>> >       specified for "lmpDataLinkActiveOperStatus"
>> >    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
>> >       specified for "lmpDataLinkPassiveOperStatus"
>> >
>> > smilint says:
>> >    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
>> >      `degraded(4)' illegal in sub-type
>> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>> >      `up(1)' illegal in sub-type
>> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>> >      `down(2)' illegal in sub-type
>> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
>> >      `degraded(4)' illegal in sub-type
>> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>> >      `up(1)' illegal in sub-type
>> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>> >      `down(2)' illegal in sub-type
>> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
>> >      `degraded(4)' illegal in sub-type
>> >    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
>> >      `degraded(4)' illegal in sub-type
>> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>> >      `up(1)' illegal in sub-type
>> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>> >      `down(2)' illegal in sub-type
>> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
>> >      `degraded(4)' illegal in sub-type
>> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>> >      `up(1)' illegal in sub-type
>> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>> >      `down(2)' illegal in sub-type
>> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
>> >      `degraded(4)' illegal in sub-type
>> >    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
>> >      `InetAddress' object should have an accompanied preceding
>> >      `InetAdressType' object
>> >    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
>> >      `InetAddress' object should have an accompanied preceding
>> >      `InetAdressType' object
>> >    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
>> >      `InetAddress' objectshould have an accompanied preceding
>> >      `InetAdressType' object
>> >
>> > Some details:
>> > 1. lmpNbrNodeId OBJECT-TYPE
>> >       SYNTAX        InetAddress (SIZE(4))
>> >       MAX-ACCESS    not-accessible
>> >       STATUS        current
>> >       DESCRIPTION
>> >        "This is a unique index for an entry in the LmpNbrTable.
>> >         This value represents the remote Node ID. The Node ID
>> >         address type must be IPv4."
>> >       ::= { lmpNbrEntry 1 }
>> >    You do know that MIB modules need to be IPv6 friendly, no?
>> >    Is LMP itself such that it only works with IPv4? I doubt that
>> >    IESG will approve new protocols that do not support IPv6.
>> > 2. For these 2 objects:
>> >      lmpNbrRetransmitInterval  LmpRetransmitInterval,
>> >      lmpNbrRetryLimit          Unsigned32,
>> >    You may want to add some text as to howyou intend to deal with
>> >    congestion (RFC 2914). This over UDP if I remember well?
>> >    I think it would be good to point explicitly to the text in lmp
>> >    document (sect 10).
>> > 3. lmpNbrRowStatus OBJECT-TYPE
>> >      SYNTAX        RowStatus
>> >      MAX-ACCESS    read-create
>> >      STATUS        current
>> >      DESCRIPTION
>> >        "This variable is used to create, modify, and/or
>> >         delete a row in this table. All read-create objects
>> >         can only be changed when lmpNbrRowStatus is active."
>> >    That sounds strange. The notInService status was specifically
>> >    created to allow changes for cases where changes were 
>not allowed
>> >    while row was active. Here you say it MUST be active in order
>> >    to make changes? Or did you mean "can not be changed"?
>> >    This occurs in more (maybe all) RowStatus objects in this doc.
>> > 4. You have some objedts that are not part of a table, yet are
>> >    read-write. For example
>> >        lmpAdminStatus
>> >        lmpCcHelloIntervalDefault
>> >        lmpCcHelloIntervalDefaultMin
>> >        ... and more ...
>> >    What is the persistency behaviour of these objects?
>> >    In other words: is the value preserved over a reboot?
>> > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
>> >    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
>> >    an interface, no?
>> > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
>> >    In the telink MIB you have done things correctly and as 
>> presscribe
>> >    by RFC3291. Here you have not. Why ?
>> >    Even in this doc you have done it correctly in some places.
>> > 7. Mmmmmm??? 52 counters to "measure the performance" of 
>> the LMP channels?
>> >    Sounds overwhelming to me.
>> > 8. Formally, every Counterxx object needs to include in its 
>> descritpion
>> >    clause which object indicates a potential discontinuity. 
>> I understand
>> >    that they all are covered by 
>lmpCcCounterDiscontinuityTime in the
>> >    same row. Maybe write something about that in the 
>> ...Entry description
>> >    clause as well if you do not want to add text to every Counter
>> > 9. lmpTeLinkTable
>> >    DESCRIPTION
>> >        "This table contains a collection of TE link."
>> >    Means what??
>> > 10. lmpLinkVerificationInterval
>> >     What does a value of zero mean?
>> >     Any comments regarding possible congestiuon if the 
>> value is set to
>> >     a very small number of msecs?
>> > 11. lmpLinkVerificationTable
>> >     Or is it better namep lmpTeLinkLinkVerificationTable
>> >     and then rename objects as well? If is correct name,
>> >     Then maybe rename
>> >        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
>> >        lmpTeLinkWavelength     to 
>> lmpLinkVerificationTeLinkWavelength
>> > 12. lmpVerifyTransportMechanism
>> >     There are a few TBDs in there. Better decide before you 
>> submit to AD
>> > 13. lmpTeLinkBitRate
>> >      DESCRIPTION
>> >        "This is the bit rate at which the Test messages will be
>> >         transmitted and is expressed in bytes per second."
>> >     A BIT rate that gest expressed in BYTES per second?
>> >     Possible of course but strange, no? Why not call it ByteRate?
>> > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
>> > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
>> >        OBJECTS       { ifIndex,
>> >                        lmpDataLinkRemoteIfId }
>> >     The second object already (implicitly) also contains the value
>> >     of the first object (it is the index part of the OID).
>> > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
>> >     them. But when they are enabled, what kind of rates per second
>> >     should we fear for in a worst case conidition?
>> >     Pls think about both an agent (i.e. an LMP node) generating
>> >     them, but also think about a SNMP management station receiving
>> >     them from potentially 100s or 1000s of LMP nodes.
>> > 17. On page 7 I see:
>> >       lmpDataLinkAddressType          = unnumbered(1),
>> >     Mm... that is not a valid value for an InetAddressType
>> >
>> > 18. Security COnsiderations
>> >     You are not following the guidelines to describe first the
>> >     SET (read-write, read-create) issues/concerns/vulnerabilities
>> >     and then the read-only sensistivities. So I would not be
>> >     surprised to see push back from the Security front.
>> >
>> > I have done a pretty serious review... but not exhaustive.
>> >
>> > Thanks,
>> >
>> > Bert
>> > -----Original Message-----
>> > From: Wijnen, Bert (Bert)
>> > Sent: maandag 1 september 2003 20:14
>> > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
>> > Subject: RE: LMP MIB
>> >
>> >
>> > I have it on my todo-list. I am currently checking te-link mib.
>> >
>> >
>> > Thanks,
>> > Bert
>> > -----Original Message-----
>> > From: Martin Dubuc [mailto:[email-masked]]
>> > Sent: maandag 1 september 2003 19:55
>> > To: Bert Wijnen
>> > Subject: LMP MIB
>> >
>> >
>> > Bert,
>> >
>> > I know you have been quite busy with all the MPLS drafts. I 
>> just wanted to
>> know if you had time review the LMP MIB draft and if not, 
>> when you think
>> you'll get around reviewing it.
>> >
>> > Regards,
>> >
>> > Martin
>> 
>

Delivery-date: Sun, 28 Sep 2003 09:04:42 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: LMP MIB revision 6
Date: Sun, 28 Sep 2003 11:01:17 +0200

So below you give me a lot of explanation what kind of 
notifications can get generated and how many would be generated 
under which conditions. I think that is exactly the type of
information that we would like to see somewhere (best uis probably
in DESCRITPION clauses so that it stays with the MIB module when
it gets extracted). You might also add some warnings that people
should be carefull NOT to configure too short verification times
and at least take the potential notification rate into consideration
when doing so. 

The question then becomes: should there be an object to throttle
the max rate?

Thanks,
Bert 

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: zondag 28 september 2003 3:31
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: LMP MIB revision 6
> 
> 
> Bert,
> 
> I am almost done updating the LMP MIB to address your 
> comments. However, I
> am stuck on comment 16 (notifications). You would like to 
> know what rate per
> second we should fear in the worst conditions. It is very difficult to
> answer this one. I have thought a lot about this, and I don't 
> think I can
> come up with a number. The notification rate distribution 
> depends too much
> on the type of network, the size of network, the network 
> configuration, the
> type of the links, the reliability of the network, etc.
> 
> I can add some text in some of the notifications to explain 
> some of the
> expected limits (for instance, there are some notifications 
> that can only
> happen once per link verification interval), but to give one 
> number for the
> worst case is next to impossible.
> 
> In general, I think the LMP MIB is not resource hungry when 
> it comes to
> notifications because all of the transitions are state driven 
> (meaning the
> notification are only sent when the system changes state), 
> cover some very
> specific error conditions (like configuration errors) and are mainly
> associated with entities that are limited in numbers (TE 
> links and control
> channels). The only notifications that might have caused a 
> problem are the
> ones associated with data links (because of the potential 
> high number of
> data links) but since the data links can happen only once per 
> data link per
> link verification interval, the notification rate should be 
> sustainable if
> one chooses an appropriate link verification interval and 
> engineers the
> network properly. For instance, a network of 100 nodes with 5 
> links of 128
> wavelengths each and a link verification of 1 minute with say 
> 10% of the
> links failed at any given time would have 1 notification per 
> second sent
> from each node (100 notifications per second for the whole 
> network). The
> rest of the notifications are negligeable compared to this number.
> 
> Martin
> 
> ----- Original Message -----
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "'Martin Dubuc'" <[email-masked]>
> Cc: "Ccamp-wg (E-mail)" <[email-masked]>
> Sent: Monday, September 01, 2003 4:42 PM
> Subject: RE: LMP MIB revision 6
> 
> 
> > Well well...
> >
> > SMICng says:
> >    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
> >       "lmpDataLinkPropertyMismatch" is an index for a table
> >    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
> >       "lmpTeLinkDegraded" is an index for a table
> >    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
> >       "lmpTeLinkNotDegraded" is an index for a table
> >    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
> >       "lmpDataLinkVerificationFailure" is an index for a table
> >    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
> >       specified for "lmpCcOperStatus"
> >    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
> >       specified for "lmpTeLinkOperStatus"
> >    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
> >       specified for "lmpDataLinkActiveOperStatus"
> >    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
> >       specified for "lmpDataLinkPassiveOperStatus"
> >
> > smilint says:
> >    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
> >      `InetAddress' object should have an accompanied preceding
> >      `InetAdressType' object
> >    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
> >      `InetAddress' object should have an accompanied preceding
> >      `InetAdressType' object
> >    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
> >      `InetAddress' objectshould have an accompanied preceding
> >      `InetAdressType' object
> >
> > Some details:
> > 1. lmpNbrNodeId OBJECT-TYPE
> >       SYNTAX        InetAddress (SIZE(4))
> >       MAX-ACCESS    not-accessible
> >       STATUS        current
> >       DESCRIPTION
> >        "This is a unique index for an entry in the LmpNbrTable.
> >         This value represents the remote Node ID. The Node ID
> >         address type must be IPv4."
> >       ::= { lmpNbrEntry 1 }
> >    You do know that MIB modules need to be IPv6 friendly, no?
> >    Is LMP itself such that it only works with IPv4? I doubt that
> >    IESG will approve new protocols that do not support IPv6.
> > 2. For these 2 objects:
> >      lmpNbrRetransmitInterval  LmpRetransmitInterval,
> >      lmpNbrRetryLimit          Unsigned32,
> >    You may want to add some text as to howyou intend to deal with
> >    congestion (RFC 2914). This over UDP if I remember well?
> >    I think it would be good to point explicitly to the text in lmp
> >    document (sect 10).
> > 3. lmpNbrRowStatus OBJECT-TYPE
> >      SYNTAX        RowStatus
> >      MAX-ACCESS    read-create
> >      STATUS        current
> >      DESCRIPTION
> >        "This variable is used to create, modify, and/or
> >         delete a row in this table. All read-create objects
> >         can only be changed when lmpNbrRowStatus is active."
> >    That sounds strange. The notInService status was specifically
> >    created to allow changes for cases where changes were not allowed
> >    while row was active. Here you say it MUST be active in order
> >    to make changes? Or did you mean "can not be changed"?
> >    This occurs in more (maybe all) RowStatus objects in this doc.
> > 4. You have some objedts that are not part of a table, yet are
> >    read-write. For example
> >        lmpAdminStatus
> >        lmpCcHelloIntervalDefault
> >        lmpCcHelloIntervalDefaultMin
> >        ... and more ...
> >    What is the persistency behaviour of these objects?
> >    In other words: is the value preserved over a reboot?
> > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
> >    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
> >    an interface, no?
> > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
> >    In the telink MIB you have done things correctly and as 
> presscribe
> >    by RFC3291. Here you have not. Why ?
> >    Even in this doc you have done it correctly in some places.
> > 7. Mmmmmm??? 52 counters to "measure the performance" of 
> the LMP channels?
> >    Sounds overwhelming to me.
> > 8. Formally, every Counterxx object needs to include in its 
> descritpion
> >    clause which object indicates a potential discontinuity. 
> I understand
> >    that they all are covered by lmpCcCounterDiscontinuityTime in the
> >    same row. Maybe write something about that in the 
> ...Entry description
> >    clause as well if you do not want to add text to every Counter
> > 9. lmpTeLinkTable
> >    DESCRIPTION
> >        "This table contains a collection of TE link."
> >    Means what??
> > 10. lmpLinkVerificationInterval
> >     What does a value of zero mean?
> >     Any comments regarding possible congestiuon if the 
> value is set to
> >     a very small number of msecs?
> > 11. lmpLinkVerificationTable
> >     Or is it better namep lmpTeLinkLinkVerificationTable
> >     and then rename objects as well? If is correct name,
> >     Then maybe rename
> >        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
> >        lmpTeLinkWavelength     to 
> lmpLinkVerificationTeLinkWavelength
> > 12. lmpVerifyTransportMechanism
> >     There are a few TBDs in there. Better decide before you 
> submit to AD
> > 13. lmpTeLinkBitRate
> >      DESCRIPTION
> >        "This is the bit rate at which the Test messages will be
> >         transmitted and is expressed in bytes per second."
> >     A BIT rate that gest expressed in BYTES per second?
> >     Possible of course but strange, no? Why not call it ByteRate?
> > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> >        OBJECTS       { ifIndex,
> >                        lmpDataLinkRemoteIfId }
> >     The second object already (implicitly) also contains the value
> >     of the first object (it is the index part of the OID).
> > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
> >     them. But when they are enabled, what kind of rates per second
> >     should we fear for in a worst case conidition?
> >     Pls think about both an agent (i.e. an LMP node) generating
> >     them, but also think about a SNMP management station receiving
> >     them from potentially 100s or 1000s of LMP nodes.
> > 17. On page 7 I see:
> >       lmpDataLinkAddressType          = unnumbered(1),
> >     Mm... that is not a valid value for an InetAddressType
> >
> > 18. Security COnsiderations
> >     You are not following the guidelines to describe first the
> >     SET (read-write, read-create) issues/concerns/vulnerabilities
> >     and then the read-only sensistivities. So I would not be
> >     surprised to see push back from the Security front.
> >
> > I have done a pretty serious review... but not exhaustive.
> >
> > Thanks,
> >
> > Bert
> > -----Original Message-----
> > From: Wijnen, Bert (Bert)
> > Sent: maandag 1 september 2003 20:14
> > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> > Subject: RE: LMP MIB
> >
> >
> > I have it on my todo-list. I am currently checking te-link mib.
> >
> >
> > Thanks,
> > Bert
> > -----Original Message-----
> > From: Martin Dubuc [mailto:[email-masked]]
> > Sent: maandag 1 september 2003 19:55
> > To: Bert Wijnen
> > Subject: LMP MIB
> >
> >
> > Bert,
> >
> > I know you have been quite busy with all the MPLS drafts. I 
> just wanted to
> know if you had time review the LMP MIB draft and if not, 
> when you think
> you'll get around reviewing it.
> >
> > Regards,
> >
> > Martin
> 

Delivery-date: Sun, 28 Sep 2003 00:46:25 +0000
From: "ramasamy ramanathan" <[email-masked]>
To: <[email-masked]>
Subject: doubts
Date: Sat, 27 Sep 2003 17:55:15 -0700

Hi all,

I have few doubts, could u please explain me?

For Contrl Channel Separation in GMPLS, IF_ID_RSVP_HOP object is used to
control the particlar data channel.

In case of unnumbered data links, we have unnumbered interface id
object[RFC3477] to specify the explicit path.  so when we form the
IF_ID_RSVP_HOP object we can take the router id and interface id from
unnumbered interface id subobject  of explcit route obect.

In case of numbered data links,  In explicit route object we don't have any
subobject to mention the data channel's interface address. Whatever present
in ERO object gives the control channel's interface address right? so when
we form the IF_ID_RSVP_HOP object, from where do we get the actual data
channel address along which the label has to be allocated? how to carry the
explcit route( RouterID and Data channel's address) computed by CSPF along
the PATH.

If my assumptions are wrong please correct me.

thanks
rams.

Delivery-date: Sat, 27 Sep 2003 13:53:18 +0000
Subject: Re: SONET/SDH Encoding for LMP Test messages
To: [email-masked] (Shiba, Sidney)
Date: Sat, 27 Sep 2003 13:48:08 +0000 (GMT)
Cc: [email-masked]
From: Dimitri Papadimitriou <[email-masked]>

hi sidney, this i-d doesn't make any assumption concerning
the "origin" of the Jx trace message field this is why i 
didn't say "provisioned" in my previous reply (i mentioned 
only "available") now concerning its exact value the current
i-d refers to specific technology being used and as such i'd 
say that the concern you've raised is covered (meaning any 
value which is suitable for the specific technology is here
considered as valid) but for clarity it might be useful to 
include also a statement concerning the uniqueness of the 
value as processed by the control plane - thanks for the 
pointer, dimitri.
> 
> Dimitri,
> 
> Some carriers do not provision the trace message, specially 
> the J0 trace. In the case Jx is not provisioned, is the NE
> expected to generate the Jx trace message? If so, the draft 
> should explicitly indicate it and message formats should be 
> suggested for uniqueness (e.g., that specified in Rec. G.831 
> Appendix I).
> 
> Thanks,
> 
> Sidney
> 
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 3:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: SONET/SDH Encoding for LMP Test messages
> 
> 
> hi, the Trace Message field value of the TRACE object used 
> in the Test message (and that is sent over the control 
> channel) corresponds to the Jx pattern being sent in-band,
> The Trace Message value is assumed to be available at the 
> transmitter side before the Test message is sent - thanks, 
> dimitri.
> 
> > Dimitri,
> > 
> > Reading the "draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt" I had the
> > impression that Jx Trace messages MUST be provisioned prior to
> > link verification process can take place as described in this document.
> > Is this assumption correct?
> > 
> > Thanks,
> > 
> > Sidney Shiba
> > Fujitsu Network Communications
> > 2801 Telecom Parkway
> > Richardson, TX 75082
> > 
> > 
> > 
> > 
> > 
> 

Delivery-date: Fri, 26 Sep 2003 21:24:40 +0000
From: "Shiba, Sidney" <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SONET/SDH Encoding for LMP Test messages
Date: Fri, 26 Sep 2003 16:20:32 -0500

Dimitri,

Some carriers do not provision the trace message, specially 
the J0 trace. In the case Jx is not provisioned, is the NE
expected to generate the Jx trace message? If so, the draft 
should explicitly indicate it and message formats should be 
suggested for uniqueness (e.g., that specified in Rec. G.831 
Appendix I).

Thanks,

Sidney

-----Original Message-----
From: Dimitri Papadimitriou [mailto:[email-masked]]
Sent: Friday, September 26, 2003 3:01 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: SONET/SDH Encoding for LMP Test messages

hi, the Trace Message field value of the TRACE object used 
in the Test message (and that is sent over the control 
channel) corresponds to the Jx pattern being sent in-band,
The Trace Message value is assumed to be available at the 
transmitter side before the Test message is sent - thanks, 
dimitri.

> Dimitri,
> 
> Reading the "draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt" I had the
> impression that Jx Trace messages MUST be provisioned prior to
> link verification process can take place as described in this document.
> Is this assumption correct?
> 
> Thanks,
> 
> Sidney Shiba
> Fujitsu Network Communications
> 2801 Telecom Parkway
> Richardson, TX 75082
> 
> 
> 
> 
> 

Delivery-date: Fri, 26 Sep 2003 20:02:27 +0000
Subject: Re: SONET/SDH Encoding for LMP Test messages
To: [email-masked] (Shiba, Sidney)
Date: Fri, 26 Sep 2003 20:00:45 +0000 (GMT)
Cc: [email-masked]
From: Dimitri Papadimitriou <[email-masked]>

hi, the Trace Message field value of the TRACE object used 
in the Test message (and that is sent over the control 
channel) corresponds to the Jx pattern being sent in-band,
The Trace Message value is assumed to be available at the 
transmitter side before the Test message is sent - thanks, 
dimitri.

> Dimitri,
> 
> Reading the "draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt" I had the
> impression that Jx Trace messages MUST be provisioned prior to
> link verification process can take place as described in this document.
> Is this assumption correct?
> 
> Thanks,
> 
> Sidney Shiba
> Fujitsu Network Communications
> 2801 Telecom Parkway
> Richardson, TX 75082
> 
> 
> 
> 
> 

Delivery-date: Fri, 26 Sep 2003 18:57:55 +0000
From: "Shiba, Sidney" <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>
Cc: [email-masked]
Subject: SONET/SDH Encoding for LMP Test messages
Date: Fri, 26 Sep 2003 13:51:34 -0500

Dimitri,

Reading the "draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt" I had the
impression that Jx Trace messages MUST be provisioned prior to
link verification process can take place as described in this document.
Is this assumption correct?

Thanks,

Sidney Shiba
Fujitsu Network Communications
2801 Telecom Parkway
Richardson, TX 75082

Delivery-date: Thu, 25 Sep 2003 16:11:44 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
Date: Thu, 25 Sep 2003 12:07:55 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Analysis of Generalized Multi-Protocol Label Switching
                          (GMPLS)-based Recovery Mechanisms (including 
                          Protection and Restoration)
	Author(s)	: D. Papadimitriou, E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
	Pages		: 41
	Date		: 2003-9-25
	
This document provides an analysis grid to evaluate, compare and
contrast the Generalized Multi-Protocol Label Switching (GMPLS)
protocol suite capabilities with respect to the recovery mechanisms
currently proposed at the IETF CCAMP Working Group. A detailed
analysis of each of the recovery phases is provided using the
terminology defined in a companion document. This document focuses
on transport plane survivability and recovery issues and not on
control plane resilience and related aspects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-recovery-analysis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt

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

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Wed, 24 Sep 2003 19:36:50 +0000
Message-Id: <[email-masked]>
From: The IESG <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked], Ronald Bonica <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: WG Review: Recharter of Common Control and Measurement Plane (ccamp)
Date: Wed, 24 Sep 2003 15:29:35 -0400

A modified charter has been submitted for the Common Control and Measurement Plane (ccamp)
Working Group in the Routing Area of the IETF. The IESG has not made any determination as yet.
The following description was submitted, and is provided for informational purposes only.
Please send your comments to the IESG mailing ([email-masked]) by September 30. 

   Common Control and Measurement Plane (ccamp)
   --------------------------------------------

   Current Status: Active Working Group
   
   Chair(s):
       Ronald Bonica <[email-masked]>
       Kireeti Kompella <[email-masked]>
       
   Routing Area Director(s):
       Bill Fenner <[email-masked]>
       Alex Zinin <[email-masked]>
       
   Routing Area Advisor:
       Alex Zinin <[email-masked]>

   Mailing Lists:
   General Discussion: [email-masked]
   To Subscribe: [email-masked]
   In Body: subscribe ccamp
   Archive: http://ops.ietf.org/lists/ccamp

   Description of Working Group:

   Organizational Overview

   The CCAMP working group coordinates the work within the IETF defining
   a common control plane and a separate common measurement plane for
   physical path and core tunneling technologies of Internet and telecom
   service providers (ISPs and SPs), e.g. O-O and O-E-O optical
   switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
   with the MPLS WG. In this context, measurement refers to the
   acquisition and distribution of attributes relevant to the setting up
   of tunnels and paths.

   CCAMP WG work scope includes:

   - Definition of protocol-independent metrics and parameters
       (measurement attributes) for describing links and paths that are
       required for routing and signaling. These will be developed in
       conjunction with requests and requirements from other WGs (e.g.
       TEWG) to insure overall usefulness.

   - Definition of protocol(s) and extensions to them required for
       link and path attribute measurement. Link Management Protocol (LMP)
       is included here.

   - Functional specification of extensions for routing (OSPF, ISIS) and
       signalling (RSVP-TE) required for path establishment. Protocol formats
       and procedures that embody these extensions will be done jointly with
       the WGs supervising those protocols.

   - Definition of the mechanisms required to determine the route and
       properties of an established path (tunnel tracing).

   - Definition of MIB modules relevant to the protocols and extensions
       specified within the WG.

   CCAMP WG currently works on the following tasks:
           
   - Define how the properties of network resources gathered by a
       measurement protocol can be distributed in existing routing
       protocols, such as OSPF and IS-IS. CCAMP defines the generic
       description of the properties and how they are distributed in OSPF.
       The specifics of distribution within IS-IS are being addressed in
       the ISIS WG.

   - Define signaling and routing mechanisms to make possible the creation
       of paths that span multiple IGP areas, multiple ASes, and multiple
       providers, including techniques for crankback.

   - Define abstract link and path properties needed for link and path
       protection. Specify signalling mechanisms for path protection,
       diverse routing and fast path restoration. Ensure that multi-layer
       path protection and restoration functions are achievable using the
       defined signalling, routing, and measurement protocols, either
       separately or in combination.

   - Identify requirements for signaling and routing for ASON not currently
       met; based on these, define mechanisms to address these requirements.

   - Define a protocol that can determine the actual route and other
       properties of paths set up by CCAMP signaling protocols, as well
       as other types of tunnels (tunnel tracing).

   In doing this work, the WG will work closely with at least the following
   other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
   ITU-T.

   Goals and Milestones:
   Done Post strawman WG goals and charter
   Done Identify and document a limited set of candidate solutions for signalling 
             and for measurement. Among candidate control solutions to be considered are the
             existing GMPLS drafts
   Done Build appropriate design teams
   Done Submit WG document defining path setup portions of common control plane protocol
   Done Submit WG document defining common measurement plane protocol
   Nov 03 Submit LMP MIB to IESG
   Dec 03 Submit GMPLS MIBs to IESG
   Dec 03 Submit protection & restoration documents to IESG
   Dec 03 Submit ASON signaling requirements doc to IESG
   Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
   Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
   Feb 04 Submit ASON routing requirements doc to IESG
   Mar 04 Submit revised charter and milestones to IESG for IESG consideration of more 
                 detailed deliverables and determination of usefulness of continuation of WG

Delivery-date: Wed, 24 Sep 2003 13:37:30 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: LMP MIB revision 6
Date: Wed, 24 Sep 2003 15:34:28 +0200

Inline

Thanks,
Bert 

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: woensdag 24 september 2003 13:56
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: LMP MIB revision 6
> 
> 
> Bert,
> 
> After working on the document yesterday, I have some comments on your
> original message.
> 
> First, with regards to the Node ID, LMP defines Node ID as a 4 octet field.
> It usually maps to a 4-bytes IP address and is usually more of an internal
> network address. I am not sure it makes sense to support IPv6 for this
> field. I haven't heard that there was any proposal to change the Node ID to
> support IPv6 format.
> 
If you are sure it is gonna be just an IPv4 address, then the proper
SYNTAX would be InetAddressIPv4 instead of InetAddress.
But it seems it (at least theoretically) it can also be some random
32 bit number (Node_Id). Maybe the proper syntax is OCTET STRING SIZE (4)
and then specify that it is the Node_Id in network byte order?

In any event, you CANNOT use InetAddres without also having a
InetAddressType for it. 

And also you better add a REFERENCE clause that explains where 
Node ID is defined. 
So add a reference to the terminology section of the base
LMP document where Node_Id is defined.

> lmpCcIsIf is not redundant. In some implementations, control channel will be
> mapped to interfaces, in other implementations, they will not. This object
> is used as such indicator. In cases where the control channel is not mapped
> as interface, it is true that the value of lmpCcUnderlyingIfIndex will be 0.
> But in cases where control channels are mapped to interfaces,
> lmpCcUnderlyingIfIndex could be set to 0 to indicate that the control
> channels are not yet assigned/configured/discovered. So a  value of 0 for
> lmpCcUnderlyingIfIndex does not necessarily mean that control channel is not
> an interface.
> 
So that is/was not so clear from the DESCRIPTION clauses. Maybe you can clarify
that a bit.

> Concerning lmpCcRemoteAddressType and lmpCcRemoteCcAddr, I am not sure what
> it is from TE link MIB that you like that you would like to see here as
> well.
> 

It MUST explain WHICH object of syntax InetAddressType specifies the format
of these objects. You did it correctly for example in:
lmpDataLinkIpAddr OBJECT-TYPE
   SYNTAX        InetAddress
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "The local Internet address for numbered links. The type
        of this address is determined by the value of
        lmpDataLinkAddressType object.

        ... more stuff ...

> Regards,
> 
> Martin
> 
Hope this helps,
Bert

> ----- Original Message -----
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "'Martin Dubuc'" <[email-masked]>
> Cc: "Ccamp-wg (E-mail)" <[email-masked]>
> Sent: Monday, September 01, 2003 4:42 PM
> Subject: RE: LMP MIB revision 6
> 
> 
> > Well well...
> >
> > SMICng says:
> >    W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
> >       "lmpDataLinkPropertyMismatch" is an index for a table
> >    W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
> >       "lmpTeLinkDegraded" is an index for a table
> >    W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
> >       "lmpTeLinkNotDegraded" is an index for a table
> >    W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
> >       "lmpDataLinkVerificationFailure" is an index for a table
> >    W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
> >       specified for "lmpCcOperStatus"
> >    W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
> >       specified for "lmpTeLinkOperStatus"
> >    W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
> >       specified for "lmpDataLinkActiveOperStatus"
> >    W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
> >       specified for "lmpDataLinkPassiveOperStatus"
> >
> > smilint says:
> >    .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> >      `up(1)' illegal in sub-type
> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> >      `down(2)' illegal in sub-type
> >    .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> >      `degraded(4)' illegal in sub-type
> >    .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
> >      `InetAddress' object should have an accompanied preceding
> >      `InetAdressType' object
> >    .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
> >      `InetAddress' object should have an accompanied preceding
> >      `InetAdressType' object
> >    .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
> >      `InetAddress' objectshould have an accompanied preceding
> >      `InetAdressType' object
> >
> > Some details:
> > 1. lmpNbrNodeId OBJECT-TYPE
> >       SYNTAX        InetAddress (SIZE(4))
> >       MAX-ACCESS    not-accessible
> >       STATUS        current
> >       DESCRIPTION
> >        "This is a unique index for an entry in the LmpNbrTable.
> >         This value represents the remote Node ID. The Node ID
> >         address type must be IPv4."
> >       ::= { lmpNbrEntry 1 }
> >    You do know that MIB modules need to be IPv6 friendly, no?
> >    Is LMP itself such that it only works with IPv4? I doubt that
> >    IESG will approve new protocols that do not support IPv6.
> > 2. For these 2 objects:
> >      lmpNbrRetransmitInterval  LmpRetransmitInterval,
> >      lmpNbrRetryLimit          Unsigned32,
> >    You may want to add some text as to howyou intend to deal with
> >    congestion (RFC 2914). This over UDP if I remember well?
> >    I think it would be good to point explicitly to the text in lmp
> >    document (sect 10).
> > 3. lmpNbrRowStatus OBJECT-TYPE
> >      SYNTAX        RowStatus
> >      MAX-ACCESS    read-create
> >      STATUS        current
> >      DESCRIPTION
> >        "This variable is used to create, modify, and/or
> >         delete a row in this table. All read-create objects
> >         can only be changed when lmpNbrRowStatus is active."
> >    That sounds strange. The notInService status was specifically
> >    created to allow changes for cases where changes were not allowed
> >    while row was active. Here you say it MUST be active in order
> >    to make changes? Or did you mean "can not be changed"?
> >    This occurs in more (maybe all) RowStatus objects in this doc.
> > 4. You have some objedts that are not part of a table, yet are
> >    read-write. For example
> >        lmpAdminStatus
> >        lmpCcHelloIntervalDefault
> >        lmpCcHelloIntervalDefaultMin
> >        ... and more ...
> >    What is the persistency behaviour of these objects?
> >    In other words: is the value preserved over a reboot?
> > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
> >    lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
> >    an interface, no?
> > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
> >    In the telink MIB you have done things correctly and as 
> presscribe
> >    by RFC3291. Here you have not. Why ?
> >    Even in this doc you have done it correctly in some places.
> > 7. Mmmmmm??? 52 counters to "measure the performance" of 
> the LMP channels?
> >    Sounds overwhelming to me.
> > 8. Formally, every Counterxx object needs to include in its 
> descritpion
> >    clause which object indicates a potential discontinuity. 
> I understand
> >    that they all are covered by lmpCcCounterDiscontinuityTime in the
> >    same row. Maybe write something about that in the 
> ...Entry description
> >    clause as well if you do not want to add text to every Counter
> > 9. lmpTeLinkTable
> >    DESCRIPTION
> >        "This table contains a collection of TE link."
> >    Means what??
> > 10. lmpLinkVerificationInterval
> >     What does a value of zero mean?
> >     Any comments regarding possible congestiuon if the 
> value is set to
> >     a very small number of msecs?
> > 11. lmpLinkVerificationTable
> >     Or is it better namep lmpTeLinkLinkVerificationTable
> >     and then rename objects as well? If is correct name,
> >     Then maybe rename
> >        lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
> >        lmpTeLinkWavelength     to 
> lmpLinkVerificationTeLinkWavelength
> > 12. lmpVerifyTransportMechanism
> >     There are a few TBDs in there. Better decide before you 
> submit to AD
> > 13. lmpTeLinkBitRate
> >      DESCRIPTION
> >        "This is the bit rate at which the Test messages will be
> >         transmitted and is expressed in bytes per second."
> >     A BIT rate that gest expressed in BYTES per second?
> >     Possible of course but strange, no? Why not call it ByteRate?
> > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> >        OBJECTS       { ifIndex,
> >                        lmpDataLinkRemoteIfId }
> >     The second object already (implicitly) also contains the value
> >     of the first object (it is the index part of the OID).
> > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
> >     them. But when they are enabled, what kind of rates per second
> >     should we fear for in a worst case conidition?
> >     Pls think about both an agent (i.e. an LMP node) generating
> >     them, but also think about a SNMP management station receiving
> >     them from potentially 100s or 1000s of LMP nodes.
> > 17. On page 7 I see:
> >       lmpDataLinkAddressType          = unnumbered(1),
> >     Mm... that is not a valid value for an InetAddressType
> >
> > 18. Security COnsiderations
> >     You are not following the guidelines to describe first the
> >     SET (read-write, read-create) issues/concerns/vulnerabilities
> >     and then the read-only sensistivities. So I would not be
> >     surprised to see push back from the Security front.
> >
> > I have done a pretty serious review... but not exhaustive.
> >
> > Thanks,
> >
> > Bert
> > -----Original Message-----
> > From: Wijnen, Bert (Bert)
> > Sent: maandag 1 september 2003 20:14
> > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> > Subject: RE: LMP MIB
> >
> >
> > I have it on my todo-list. I am currently checking te-link mib.
> >
> >
> > Thanks,
> > Bert
> > -----Original Message-----
> > From: Martin Dubuc [mailto:[email-masked]]
> > Sent: maandag 1 september 2003 19:55
> > To: Bert Wijnen
> > Subject: LMP MIB
> >
> >
> > Bert,
> >
> > I know you have been quite busy with all the MPLS drafts. I 
> just wanted to
> know if you had time review the LMP MIB draft and if not, 
> when you think
> you'll get around reviewing it.
> >
> > Regards,
> >
> > Martin
> 

Delivery-date: Tue, 23 Sep 2003 20:39:47 +0000
Date: Tue, 23 Sep 2003 22:35:42 +0200
From: [email-masked]
To: Kireeti Kompella <[email-masked]>
Cc: Jonathan Sadler <[email-masked]>, [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto   Proposed Standard

hi kireeti, fine with me (i'm okay with the proposed text),
imho, the document can be sent to the iesg.

thanks,
- dimitri.

Kireeti Kompella wrote:
> Hi Dimitri,
> 
> On Tue, 23 Sep 2003 [email-masked] wrote:
> 
> 
>>-> "Attributes describing inter-layer relationships are not captured
>>by the present document. Only single layer attributes are covered."
> 
> 
> See the wording I proposed.
> 
> 
>>also, i would also suggest to replace the word "draft" by "document"
>>in the following sentence:
>>"From the factors presented above, development of layer specific GMPLS
>>  routing drafts should use the following principles for TE-link
>>  attributes."
> 
> 
> Good point.
> 
> If the above wording is okay (and there are no other comments), the
> new version of the routing document (with the above two changes) and
> the OSPF doc will be sent to the IESG.
> 
> Kireeti.
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 23 Sep 2003 15:42:37 +0000
Date: Tue, 23 Sep 2003 08:42:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: Jonathan Sadler <[email-masked]>, "" <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto   Proposed Standard

Hi Dimitri,

On Tue, 23 Sep 2003 [email-masked] wrote:

> -> "Attributes describing inter-layer relationships are not captured
> by the present document. Only single layer attributes are covered."

See the wording I proposed.

> also, i would also suggest to replace the word "draft" by "document"
> in the following sentence:
> "From the factors presented above, development of layer specific GMPLS
>   routing drafts should use the following principles for TE-link
>   attributes."

Good point.

If the above wording is okay (and there are no other comments), the
new version of the routing document (with the above two changes) and
the OSPF doc will be sent to the IESG.

Kireeti.

Delivery-date: Tue, 23 Sep 2003 15:41:43 +0000
Date: Tue, 23 Sep 2003 08:36:55 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Jonathan Sadler <[email-masked]>
cc: [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS to Proposed Standard

Hi Jonathan,

On Mon, 22 Sep 2003, Jonathan Sadler wrote:

> I was under the impression, given your email sent on 17 Jul 2003, that a new
> rev of draft-ietf-ccamp-gmpls-routing was going to be released with a statement
> added saying that the current doc is okay in a single layer network, but
> doesn't capture inter-layer relationships.

Yes, indeed.  It's sort of implicit, but you're right, I will make it
explicit.

How about adding the following to the end of section 2.1:

  The present document captures general attributes that apply to a
  single layer network, but doesn't capture inter-layer relationships
  of attributes.  This work is left to a future document.

> I thought I may have missed an announcement of the new doc on the CCAMP list,
> but cannot find it in the IETF I-D repository.  Am I missing something?

The routing doc (minus the para proposed above) is
	draft-ietf-ccamp-gmpls-routing-06.txt

If you are referring to a doc on inter-layer relationships, the
closest there is is draft-vigoureux-shiomoto-ccamp-gmpls-mrn-02.txt.
Your (and others') comments on that would be useful.

Kireeti.

Delivery-date: Tue, 23 Sep 2003 11:41:38 +0000
Date: Tue, 23 Sep 2003 13:39:10 +0200
From: [email-masked]
To: Jonathan Sadler <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto   Proposed Standard

hi jonathan, in order to address the issue raised during this
discussion, i would suggest to add the following sentences to
the following paragraphs (in section 2.1):

"2. Support of inter-layer attributes (e.g., adaptation
     relationships).  Between a client and server layer, a general
     mechanism for describing the layer relationship exists.  For
     example "4 client links of type X can be supported by this server
     layer link".  Another example is being able to identify when two
     layers share a common server layer."

-> "Attributes describing inter-layer relationships are not captured
by the present document. Only single layer attributes are covered."

also, i would also suggest to replace the word "draft" by "document"
in the following sentence:
"From the factors presented above, development of layer specific GMPLS
  routing drafts should use the following principles for TE-link
  attributes."

thanks,
- dimitri.

Jonathan Sadler wrote:
> Hi Kireeti -
> 
> I was under the impression, given your email sent on 17 Jul 2003, that a new
> rev of draft-ietf-ccamp-gmpls-routing was going to be released with a statement
> added saying that the current doc is okay in a single layer network, but
> doesn't capture inter-layer relationships.
> 
> I thought I may have missed an announcement of the new doc on the CCAMP list,
> but cannot find it in the IETF I-D repository.  Am I missing something?
> 
> Jonathan Sadler
> 
> Kireeti Kompella wrote:
> 
> 
>>Hi All,
>>
>>On Thu, 17 Jul 2003, Kireeti Kompella wrote:
>>
>>
>>>Betts, Brungard, Dotaro, Grammel, Kompella, Papadimitriou, Prattico,
>>>Sadler, Vigoureux and Zinin got together to iron out the last few
>>>issues in the document "Routing Extensions in Support of GMPLS".
>>>
>>>In the interests of progressing this document in a timely fashion,
>>>we examined these issues from two points of view:
>>>a) is the current document set fundamentally broken, and if not, what
>>>   caveats should be stated?
>>>b) how do we move forward and address these issues, whether in the
>>>   current doc set or in the future?
>>>
>>>The consensus we reached for (a) is that the current doc set is okay in a
>>>single layer network, but it doesn't capture inter-layer relationships.
>>>So, we will state that in draft-ietf-ccamp-gmpls-routing-06.txt, and
>>>then progress it.
>>>
>>>As for (b), this will be one of the charter items for the ASON Routing
>>>Reqts DT.  They will be chartered to state clearly what the requirements
>>>are, what relations should be captured in a technology/layer independent
>>>document, and what should be part of the layer-dependent documents.
>>>These will then be addressed in future documents.
>>>
>>>Many thanks to all who took part for getting together on such short
>>>notice, and for the courteous and productive discussion!
>>
>>No comments have been received on this subject.  I would like to do a
>>one week WG Last Call before sending this back to the IESG.
>>
>>Since it's been a while, I will recap:
>>a) Jonathan Sadler raised some important issues. mainly regarding
>>   layering, and some SDH-specific points.
>>b) Stephen Shew sent a write-up on layering requirements.
>>c) The group above met to make progress on these issues.
>>d) A new version of the Routing document with most of Stephen's text
>>   incorporated was posted.  (No changes were made to the OSPF doc.)
>>
>>Please respond by 5pm PDT, Monday Sept 29, 2003 with comments on the
>>changes (i.e., section 2.1); ideally, send specific text that you
>>would like to see.
>>
>>PS: A design team is being created to specificcaly address ASON
>>routing requirements; the team members and charter will be announced
>>once AD review is complete.
>>
>>Thanks,
>>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
> ============================================================
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 23 Sep 2003 06:01:32 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comparison of restoration requirements between transport and packet networks
Date: Mon, 22 Sep 2003 22:55:59 -0700

Hi Neil,

Thanks for your note. A few follow-up comments in-line.

Regards,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Friday, September 19, 2003 9:36 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Comparison of restoration requirements between transport
> and packet networks

<snip>
> > So would you agree that if one looks at the "classical" client/server
> > layer relationships, the notion of notification time bounds
> > makes sense?
> NH=> Yes in principle.....the basic rule is 'as fast as sensible, as close
> to the duct as possible;  as slow as reasonable, as close to the
> application
> as possible'.

Great. We have also been postulating that the exact time bounds would
depend on the carrier providing the transport, inter-carrier agreements,
applications supported, etc. However, the notion of providing time
bounds seems to us also to be a sound one.

> > For (ii), when a carrier has no visibility into the
> > server layer,
> NH=> very common

Thanks. I would expect though that in this situation, there
must surely be inter-carrier agreements between the carrier owning
the server layer and that having the client layer. Otherwise,
it would seem to be very difficult for carriers to plan service.
Yes?

> > it seems to me that it is perhaps _even more
> > important_ that
> > the server layer guarantee notification timing bounds (and,
> > by extension,
> > some
> > reasonable protection switching timing bounds), so that these
> > can be built
> > into the SLAs that the client-layer provider and server-layer provider
> > sign with each other.
> NH=> Nice idea in principle...and if there are only 2 parties
> involved where
> the 'server' party owns all layers to the duct it might work.  However, it
> does, as you noted previously, require some notional agreement on the
> 'allowed' X/Y client server relationships.

Actually, the idea works even if this recurses. That is, there is nothing
in principle from preventing such agreements between pairs of carriers,
owning different (adjacent) network layers.

However, there would obviously be some practical limits to how far
this can recurse.
Perhaps you (and some other carrier experts) can shed some light on
how many carriers are typically involved in such a client-server situation?
In other words, how deep does such a recursion run, on average?

> > This would allow the carrier operating the client layer to make some
> > definite assumptions about the reaction time of its server layer, and
> > build its service based on that.
> >
> > The notification work, in fact, makes no assumption that the
> > same carrier
> > has to have control of the complete layered network.
> >
> > Hope this helps to clarify a bit the thinking behind the notification
> > work.
> NH=> Yes.....but your call (with Richard) today explained a piece of the
> puzzle I had not properly appreciated until then.....and that is you are
> postulating a case where the *protection route* between 2 nodes, A and B
> say, carries 'extra' traffic that is from >=2 disjoint trails, eg extra
> traffic trail 1 say A->N->O, and extra traffic trail 2 say
> O->P->B......and
> this is why you need to inform (at least) node O of the failure on the
> working path (to co-ordinate removal of the 2 extra traffic trails).
> Clearly FDI/BDI would tell A and B from the failed working path.

Indeed. We have been postulating a shared restoration model, where the
sharing is possible all the way from 1:1 restoration to more general
M:N restoration.
The moment we allow for that, and the nature of the transport trails
(which requires that the switches en route not be cross-connected a priori),
we need a way to inform the intermediate nodes on the protection path (node
O
in your example above) of the failure on the working path, so they can
reconfigure themselves.

We will make this clearer in an applicability statement and in the
document (we're working on) that explains the expedited notification ideas
in an
implementation independent way.

> I guess providing the extra traffic once 'dumped' stays dumped the system
> ought to be stable.  I am not in favour of multiple class
> pre-emption/bumping schemes.

Thanks for the observation, glad to hear that.
Actually, the draft on the notification protocol neither
proposes(nor rules out) complex bumping/pre-emption schemes. As you observe
(and
I agree with you), it does seem practical for a carrier using extra-traffic
to
not have a pre-emption setup that is susceptible to a domino effect.

We will also call this out in the applicability statement.

Delivery-date: Mon, 22 Sep 2003 22:15:36 +0000
Subject: Re: Updated CCAMP charter (fwd)
To: [email-masked] ("Wijnen, Bert (Bert)")
Date: Mon, 22 Sep 2003 22:13:36 +0000 (GMT)
Cc: [email-masked] ([email-masked]'), [email-masked] (Kireeti Kompella), [email-masked]
From: Dimitri Papadimitriou <[email-masked]>

thanks bert for this clarification, i really hope we will be
done after this last round of comments;> 
> > 
> > hi kireeti, ccamp'ers,
> > 
> > thanks for taking care of this; some specific comments concerning
> > this revisited charter:
> > 
> > - there is no proposed deadline for the finalization of the lmp
> > base specification (acceptance of the iesg review) while we need
> > to address the mib for nov'03, is there an expected deadline for
> > this important effort produced by the wg ?
> > 
> I had an email exchange with Steve Bellovin today who is hloding the
> last IESG DISCUSS on that doc. He has promised to send in a list
> of detailed comments tomorrow. After that authors should analize and
> possibly issue another rev. After that, I think we should be done.
> 
> 
> Bert
> 
> 

Delivery-date: Mon, 22 Sep 2003 20:45:31 +0000
Date: Mon, 22 Sep 2003 15:41:44 -0500
From: Jonathan Sadler <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto   Proposed Standard

Hi Kireeti -

I was under the impression, given your email sent on 17 Jul 2003, that a new
rev of draft-ietf-ccamp-gmpls-routing was going to be released with a statement
added saying that the current doc is okay in a single layer network, but
doesn't capture inter-layer relationships.

I thought I may have missed an announcement of the new doc on the CCAMP list,
but cannot find it in the IETF I-D repository.  Am I missing something?

Jonathan Sadler

Kireeti Kompella wrote:

> Hi All,
>
> On Thu, 17 Jul 2003, Kireeti Kompella wrote:
>
> > Betts, Brungard, Dotaro, Grammel, Kompella, Papadimitriou, Prattico,
> > Sadler, Vigoureux and Zinin got together to iron out the last few
> > issues in the document "Routing Extensions in Support of GMPLS".
> >
> > In the interests of progressing this document in a timely fashion,
> > we examined these issues from two points of view:
> > a) is the current document set fundamentally broken, and if not, what
> >    caveats should be stated?
> > b) how do we move forward and address these issues, whether in the
> >    current doc set or in the future?
> >
> > The consensus we reached for (a) is that the current doc set is okay in a
> > single layer network, but it doesn't capture inter-layer relationships.
> > So, we will state that in draft-ietf-ccamp-gmpls-routing-06.txt, and
> > then progress it.
> >
> > As for (b), this will be one of the charter items for the ASON Routing
> > Reqts DT.  They will be chartered to state clearly what the requirements
> > are, what relations should be captured in a technology/layer independent
> > document, and what should be part of the layer-dependent documents.
> > These will then be addressed in future documents.
> >
> > Many thanks to all who took part for getting together on such short
> > notice, and for the courteous and productive discussion!
>
> No comments have been received on this subject.  I would like to do a
> one week WG Last Call before sending this back to the IESG.
>
> Since it's been a while, I will recap:
> a) Jonathan Sadler raised some important issues. mainly regarding
>    layering, and some SDH-specific points.
> b) Stephen Shew sent a write-up on layering requirements.
> c) The group above met to make progress on these issues.
> d) A new version of the Routing document with most of Stephen's text
>    incorporated was posted.  (No changes were made to the OSPF doc.)
>
> Please respond by 5pm PDT, Monday Sept 29, 2003 with comments on the
> changes (i.e., section 2.1); ideally, send specific text that you
> would like to see.
>
> PS: A design team is being created to specificcaly address ASON
> routing requirements; the team members and charter will be announced
> once AD review is complete.
>
> Thanks,
> 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
============================================================

Delivery-date: Mon, 22 Sep 2003 18:45:58 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-01.txt
Date: Mon, 22 Sep 2003 14:44:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS Recovery Functional Specification
	Author(s)	: J. Lang, B. Rajagopalan
	Filename	: draft-ietf-ccamp-gmpls-recovery-functional-01.txt
	Pages		: 19
	Date		: 2003-9-22
	
This document presents a functional description of the protocol 
extensions needed to support GMPLS-based recovery (i.e. protection 
and restoration). Protocol specific formats and mechanisms will be 
described in companion documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-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-recovery-functional-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 22 Sep 2003 18:32:37 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Updated CCAMP charter (fwd)
Date: Mon, 22 Sep 2003 20:29:27 +0200

> 
> hi kireeti, ccamp'ers,
> 
> thanks for taking care of this; some specific comments concerning
> this revisited charter:
> 
> - there is no proposed deadline for the finalization of the lmp
> base specification (acceptance of the iesg review) while we need
> to address the mib for nov'03, is there an expected deadline for
> this important effort produced by the wg ?
> 
I had an email exchange with Steve Bellovin today who is hloding the
last IESG DISCUSS on that doc. He has promised to send in a list
of detailed comments tomorrow. After that authors should analize and
possibly issue another rev. After that, I think we should be done.

Bert

Delivery-date: Mon, 22 Sep 2003 16:50:39 +0000
Date: Mon, 22 Sep 2003 18:47:45 +0200
From: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Updated CCAMP charter (fwd)

hi kireeti, ccamp'ers,

thanks for taking care of this; some specific comments concerning
this revisited charter:

- there is no proposed deadline for the finalization of the lmp
base specification (acceptance of the iesg review) while we need
to address the mib for nov'03, is there an expected deadline for
this important effort produced by the wg ?

- the deadlines for the ason delta reqs has been proposed resp.
for signaling and routing, however there is no specific deadline
proposed for the "delta mechanisms" submission to the iesg, does
it mean that the proposed deadlines include them ?

- i would suggest to include an item in the revisited charter
explicitly stating "refine the signaling and routing mechanisms
to make possible the creation of paths in multi-layer switching
networks" since intimately - but not restricted in its applica
bility scope - to the multi-layer path p&r item

thanks for your feedback,
- dimitri.

Kireeti Kompella wrote:

> Hi All,
> 
> The following is a revised charter for CCAMP WG.  It has been reviewed
> by the IESG, and is now undergoing external review.  Note that as has
> been mentioned before, CCAMP is moving to the Routing Area.
> 
> Please send your comments to this list.
> 
> Kireeti & Ron.
> -------------
> 
>  Common Control and Measurement Plane (ccamp)
>  --------------------------------------------
> 
>  Current Status: Active Working Group
> 
>  Chair(s):
>    Ronald Bonica <[email-masked]>
>    Kireeti Kompella <[email-masked]>
> 
>  Routing Area Director(s):
>    Bill Fenner <[email-masked]>
>    Alex Zinin <[email-masked]>
> 
>  Routing Area Advisor:
>    Alex Zinin <[email-masked]>
> 
>  Mailing Lists:
>  General Discussion: [email-masked]
>  To Subscribe: [email-masked]
>  In Body: subscribe ccamp
>  Archive: http://ops.ietf.org/lists/ccamp
> 
>  Description of Working Group:
> 
>  Organizational Overview
> 
>  The CCAMP working group coordinates the work within the IETF defining
>  a common control plane and a separate common measurement plane for
>  physical path and core tunneling technologies of Internet and telecom
>  service providers (ISPs and SPs), e.g. O-O and O-E-O optical
>  switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
>  with the MPLS WG. In this context, measurement refers to the
>  acquisition and distribution of attributes relevant to the setting up
>  of tunnels and paths.
> 
>  CCAMP WG work scope includes:
> 
>  - Definition of protocol-independent metrics and parameters
>    (measurement attributes) for describing links and paths that are
>    required for routing and signaling. These will be developed in
>    conjunction with requests and requirements from other WGs (e.g.
>    TEWG) to insure overall usefulness.
> 
>  - Definition of protocol(s) and extensions to them required for
>    link and path attribute measurement. Link Management Protocol (LMP)
>    is included here.
> 
>  - Functional specification of extensions for routing (OSPF, ISIS) and
>    signalling (RSVP-TE) required for path establishment. Protocol formats
>    and procedures that embody these extensions will be done jointly with
>    the WGs supervising those protocols.
> 
>  - Definition of the mechanisms required to determine the route and
>    properties of an established path (tunnel tracing).
> 
>  - Definition of MIB modules relevant to the protocols and extensions
>    specified within the WG.
> 
>  CCAMP WG currently works on the following tasks:
> 
>  - Define how the properties of network resources gathered by a
>    measurement protocol can be distributed in existing routing
>    protocols, such as OSPF and IS-IS. CCAMP defines the generic
>    description of the properties and how they are distributed in OSPF.
>    The specifics of distribution within IS-IS are being addressed in
>    the ISIS WG.
> 
>  - Define signaling and routing mechanisms to make possible the creation
>    of paths that span multiple IGP areas, multiple ASes, and multiple
>    providers, including techniques for crankback.
> 
>  - Define abstract link and path properties needed for link and path
>    protection. Specify signalling mechanisms for path protection,
>    diverse routing and fast path restoration. Ensure that multi-layer
>    path protection and restoration functions are achievable using the
>    defined signalling, routing, and measurement protocols, either
>    separately or in combination.
> 
>  - Identify requirements for signaling and routing for ASON not currently
>    met; based on these, define mechanisms to address these requirements.
> 
>  - Define a protocol that can determine the actual route and other
>    properties of paths set up by CCAMP signaling protocols, as well
>    as other types of tunnels (tunnel tracing).
> 
>  In doing this work, the WG will work closely with at least the following
>  other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
>  ITU-T.
> 
>  Goals and Milestones:
>  Done Post strawman WG goals and charter
>  Done Identify and document a limited set of candidate solutions for signalling
>       and for measurement. Among candidate control solutions to be considered are the
>       existing GMPLS drafts
>  Done Build appropriate design teams
>  Done Submit WG document defining path setup portions of common control plane protocol
>  Done Submit WG document defining common measurement plane protocol
>  Nov 03 Submit LMP MIB to IESG
>  Dec 03 Submit GMPLS MIBs to IESG
>  Dec 03 Submit protection & restoration documents to IESG
>  Dec 03 Submit ASON signaling requirements doc to IESG
>  Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
>  Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
>  Feb 04 Submit ASON routing requirements doc to IESG
>  Mar 04 Submit revised charter and milestones to IESG for IESG consideration of more
>         detailed deliverables and determination of usefulness of continuation of WG
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Mon, 22 Sep 2003 14:20:15 +0000
Date: Mon, 22 Sep 2003 07:13:41 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard

Hi All,

On Thu, 17 Jul 2003, Kireeti Kompella wrote:

> Betts, Brungard, Dotaro, Grammel, Kompella, Papadimitriou, Prattico,
> Sadler, Vigoureux and Zinin got together to iron out the last few
> issues in the document "Routing Extensions in Support of GMPLS".
>
> In the interests of progressing this document in a timely fashion,
> we examined these issues from two points of view:
> a) is the current document set fundamentally broken, and if not, what
>    caveats should be stated?
> b) how do we move forward and address these issues, whether in the
>    current doc set or in the future?
>
> The consensus we reached for (a) is that the current doc set is okay in a
> single layer network, but it doesn't capture inter-layer relationships.
> So, we will state that in draft-ietf-ccamp-gmpls-routing-06.txt, and
> then progress it.
>
> As for (b), this will be one of the charter items for the ASON Routing
> Reqts DT.  They will be chartered to state clearly what the requirements
> are, what relations should be captured in a technology/layer independent
> document, and what should be part of the layer-dependent documents.
> These will then be addressed in future documents.
>
> Many thanks to all who took part for getting together on such short
> notice, and for the courteous and productive discussion!

No comments have been received on this subject.  I would like to do a
one week WG Last Call before sending this back to the IESG.

Since it's been a while, I will recap:
a) Jonathan Sadler raised some important issues. mainly regarding
   layering, and some SDH-specific points.
b) Stephen Shew sent a write-up on layering requirements.
c) The group above met to make progress on these issues.
d) A new version of the Routing document with most of Stephen's text
   incorporated was posted.  (No changes were made to the OSPF doc.)

Please respond by 5pm PDT, Monday Sept 29, 2003 with comments on the
changes (i.e., section 2.1); ideally, send specific text that you
would like to see.

PS: A design team is being created to specificcaly address ASON
routing requirements; the team members and charter will be announced
once AD review is complete.

Thanks,
Kireeti.

Delivery-date: Fri, 19 Sep 2003 20:55:12 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'zafar ali'" <[email-masked]>, <[email-masked]>
Cc: "Vishal Sharma" <[email-masked]>, "'Richard Rabbat'" <[email-masked]>
Subject: RE: Time-bounded notification
Date: Fri, 19 Sep 2003 13:49:15 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C37EB4.D0EF42A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Zafar,

Please see my comments inline.

Thanks,

Richard.

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf
Of zafar ali
Sent: Tuesday, September 09, 2003 12:06 PM
To: 'Richard Rabbat'; [email-masked]
Cc: 'Vishal Sharma'
Subject: RE: Time-bounded notification

=20

Hi Richard,=20

=20

Sorry for replying late; Please see comments in-lined.=20

=20

Thanks

=20

Regards... Zafar

=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali, Ph. D.
100 South Main St. #200,
Technical Leader,                                                       =
Ann
Arbor, MI 48104, USA.
Cisco Systems.                                                         =
(734)
276-2459, [email-masked]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf
Of Richard Rabbat
Sent: Thursday, August 14, 2003 2:09 PM
To: [email-masked]
Cc: 'Vishal Sharma'
Subject: Time-bounded notification

Hello Everyone,

=20

Following some discussions prior to Vienna, and feedback and comments
received during Vienna and thereafter, we have realized that perhaps one
aspect of draft-rabbat-fault-notification-protocol-03.txt that we may =
not
have adequately highlighted is its focus on providing *time-bounded*
notification.

=20

This is because draft-rabbat focuses on recovery in optical transport
networks, where recovery of failed LSPs (fibers, lambdas, etc.) in a
*bounded time* is critical for the provider to be able to offer
guarantees/SLAs to its transport customers, and also to its L2 and L3
customers. The transport infrastructure often serves as a foundation for =
the
L2 and L3 networks built upon it, and so should be able to provide =
recovery
within some well-specified time, so that L2 and L3 recovery can be
appropriately performed based on what L1 provides.

=20

For this reason, notification via signaling or OSPF-based flooding, =
which
could work well at the packet layer, may not be directly applicable at =
the
transport layer. =20

I agree with the notion of the time-bounded recovery. However, here you
started to make assumption about possible solutions. The same confusion
arrived at the last IETF meeting when an LMP based solution was =
presented.
All I am saying is that IMO breaking the problem into two part, I.e.,
getting agreement on the requirements and then following it up with the
solution would be the right approach.=20

=20

[Richard] Agreed. Let's write a document to highlight that based on our =
ML
email exchange.

=20

I agree with the requirement part of the problem statement.=20

[Richard] Thanks.

=20

 In fact, since recovery at the packet layer may not involve the =
stringent
time constraints that are applicable at the transport layer, directly
comparing notification solutions at the packet layer with those at the
transport layer is probably not accurate. =20

What would be useful here is to quantify the differences between the two
types of networks. Such quantification will be useful in catalyzing some
email discussions at the mailing list.=20

[Richard] Yes

Rather, we need to examine (as done in draft-rabbat) the applicability =
of
signaling and flooding to notification *at the transport layer* under =
the
constraint of achieving time-bounded recovery.=20

 Agreed!=20

=20

[Richard] We will try to add examples that will help visualize the =
problem
at the transport layer and the network model assumption.

=20

So if the WG looks at draft-rabbat with this backdrop, we believe some =
of
the arguments made there will be clearer. Of course, we welcome feedback
from the list.

=20

[snipped]

------=_NextPart_000_002B_01C37EB4.D0EF42A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title>Message</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Zafar,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Please see my comments =
inline.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Richard.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>zafar ali<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
09, 2003
12:06 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Richard Rabbat';
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> 'Vishal Sharma'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Time-bounded
notification</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Richard, </span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Sorry for replying late; Please see
comments in-lined. </span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Regards... Zafar</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<br>
Zafar Ali, Ph.
D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;100
South Main St. #200,<br>
Technical
Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ann Arbor, MI 48104, USA.<br>
Cisco
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(734)
276-2459, <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span></font></=
p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>Richard Rabbat<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, August =
14, 2003
2:09 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> 'Vishal Sharma'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Time-bounded =
notification</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello Everyone,</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Following some discussions prior to Vienna, and =
feedback and
comments received during Vienna and thereafter, we have realized that =
perhaps
one aspect of draft-rabbat-fault-notification-protocol-03.txt that we =
may not
have adequately highlighted is its focus on providing *<b><span
style=3D'font-weight:bold'>time-bounded</span></b>* =
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is because draft-rabbat focuses on recovery in =
optical
transport networks, where recovery of failed LSPs (fibers, lambdas, =
etc.) in a
*<b><span style=3D'font-weight:bold'>bounded time</span></b>* is =
critical for the
provider to be able to offer guarantees/SLAs to its transport customers, =
and
also to its L2 and L3 customers. The transport infrastructure often =
serves as a
foundation for the L2 and L3 networks built upon it, and so should be =
able to
provide recovery within some well-specified time, so that L2 and L3 =
recovery
can be appropriately performed based on what L1 =
provides.</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For this reason, notification via signaling or =
OSPF-based
flooding, which could work well at the packet layer, may not be directly
applicable at the transport layer.&nbsp;<font color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I agree with the notion of the
time-bounded recovery. However, here you started to make assumption =
about possible
solutions. The same confusion arrived at the last IETF meeting when an =
LMP
based solution was presented. All I am saying is that IMO&nbsp;breaking =
the
problem into two part, I.e., getting agreement on the requirements and =
then
following it up with the solution would be the right approach. =
</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Richard] Agreed. Let&#8217;s write a document to =
highlight
that based on our ML email exchange.</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I agree with the requirement part =
of the
problem statement. </span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:5.0pt'><b><i><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy;
font-weight:bold;font-style:italic'>[Richard] =
Thanks.</span></font></i></b></p>

</blockquote>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;In fact, since recovery at the packet layer may =
not
involve the stringent time constraints that are applicable at the =
transport
layer, directly comparing notification solutions at the packet layer =
with those
at the transport layer is probably not accurate.<font color=3Dblue><span
style=3D'color:blue'>&nbsp;&nbsp;</span></font></span></font></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>What would be useful here is to =
quantify
the</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'> <font color=3Dblue><span =
style=3D'color:blue'>differences
between the two types of networks. Such quantification will be useful in
catalyzing some email discussions at the mailing list. =
</span></font></span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Richard] Yes</span></font></i></b></p>

</blockquote>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Rather, we need to examine (as done in draft-rabbat) =
the
applicability of signaling and flooding to notification *<b><span
style=3D'font-weight:bold'>at the transport layer</span></b>* under the
constraint of achieving time-bounded recovery.<font color=3Dblue><span
style=3D'color:blue'>&nbsp;</span></font></span></font></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<font color=3Dblue><span =
style=3D'color:blue'>Agreed! </span></font></span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>&nbsp;</span></font></i></b></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Richard] We will try to add examples that will help
visualize the problem at the transport layer and the network model =
assumption.</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

</blockquote>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So if the WG looks at draft-rabbat with this =
backdrop, we
believe some of the arguments made there will be clearer. Of course, we =
welcome
feedback from the list.</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>[snipped]</span></font></p>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_002B_01C37EB4.D0EF42A0--

Delivery-date: Fri, 19 Sep 2003 16:41:16 +0000
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Comparison of restoration requirements between transport and  packet networks
Date: Fri, 19 Sep 2003 17:36:12 +0100

Vishal, some remarks in-line.  regards, Neil

Vishal Sharma wrote 18 September 2003 06:31

<snipped>
> So would you agree that if one looks at the "classical" client/server
> layer relationships, the notion of notification time bounds 
> makes sense?
NH=> Yes in principle.....the basic rule is 'as fast as sensible, as close
to the duct as possible;  as slow as reasonable, as close to the application
as possible'.
> 
> For (ii), when a carrier has no visibility into the
> server layer,
NH=> very common

> it seems to me that it is perhaps _even more 
> important_ that
> the server layer guarantee notification timing bounds (and, 
> by extension,
> some
> reasonable protection switching timing bounds), so that these 
> can be built
> into the SLAs that the client-layer provider and server-layer provider
> sign with each other.
NH=> Nice idea in principle...and if there are only 2 parties involved where
the 'server' party owns all layers to the duct it might work.  However, it
does, as you noted previously, require some notional agreement on the
'allowed' X/Y client server relationships.
> 
> This would allow the carrier operating the client layer to make some
> definite assumptions about the reaction time of its server layer, and
> build its service based on that.
> 
> The notification work, in fact, makes no assumption that the 
> same carrier
> has to have control of the complete layered network.
> 
> Hope this helps to clarify a bit the thinking behind the notification
> work.
NH=> Yes.....but your call (with Richard) today explained a piece of the
puzzle I had not properly appreciated until then.....and that is you are
postulating a case where the *protection route* between 2 nodes, A and B
say, carries 'extra' traffic that is from >=2 disjoint trails, eg extra
traffic trail 1 say A->N->O, and extra traffic trail 2 say O->P->B......and
this is why you need to inform (at least) node O of the failure on the
working path (to co-ordinate removal of the 2 extra traffic trails).
Clearly FDI/BDI would tell A and B from the failed working path.

I guess providing the extra traffic once 'dumped' stays dumped the system
ought to be stable.  I am not in favour of multiple class
pre-emption/bumping schemes.  

regards, Neil

Delivery-date: Thu, 18 Sep 2003 20:37:06 +0000
Date: Thu, 18 Sep 2003 13:30:48 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Updated CCAMP charter (fwd)

Hi All,

The following is a revised charter for CCAMP WG.  It has been reviewed
by the IESG, and is now undergoing external review.  Note that as has
been mentioned before, CCAMP is moving to the Routing Area.

Please send your comments to this list.

Kireeti & Ron.
-------------

 Common Control and Measurement Plane (ccamp)
 --------------------------------------------

 Current Status: Active Working Group

 Chair(s):
   Ronald Bonica <[email-masked]>
   Kireeti Kompella <[email-masked]>

 Routing Area Director(s):
   Bill Fenner <[email-masked]>
   Alex Zinin <[email-masked]>

 Routing Area Advisor:
   Alex Zinin <[email-masked]>

 Mailing Lists:
 General Discussion: [email-masked]
 To Subscribe: [email-masked]
 In Body: subscribe ccamp
 Archive: http://ops.ietf.org/lists/ccamp

 Description of Working Group:

 Organizational Overview

 The CCAMP working group coordinates the work within the IETF defining
 a common control plane and a separate common measurement plane for
 physical path and core tunneling technologies of Internet and telecom
 service providers (ISPs and SPs), e.g. O-O and O-E-O optical
 switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
 with the MPLS WG. In this context, measurement refers to the
 acquisition and distribution of attributes relevant to the setting up
 of tunnels and paths.

 CCAMP WG work scope includes:

 - Definition of protocol-independent metrics and parameters
   (measurement attributes) for describing links and paths that are
   required for routing and signaling. These will be developed in
   conjunction with requests and requirements from other WGs (e.g.
   TEWG) to insure overall usefulness.

 - Definition of protocol(s) and extensions to them required for
   link and path attribute measurement. Link Management Protocol (LMP)
   is included here.

 - Functional specification of extensions for routing (OSPF, ISIS) and
   signalling (RSVP-TE) required for path establishment. Protocol formats
   and procedures that embody these extensions will be done jointly with
   the WGs supervising those protocols.

 - Definition of the mechanisms required to determine the route and
   properties of an established path (tunnel tracing).

 - Definition of MIB modules relevant to the protocols and extensions
   specified within the WG.

 CCAMP WG currently works on the following tasks:

 - Define how the properties of network resources gathered by a
   measurement protocol can be distributed in existing routing
   protocols, such as OSPF and IS-IS. CCAMP defines the generic
   description of the properties and how they are distributed in OSPF.
   The specifics of distribution within IS-IS are being addressed in
   the ISIS WG.

 - Define signaling and routing mechanisms to make possible the creation
   of paths that span multiple IGP areas, multiple ASes, and multiple
   providers, including techniques for crankback.

 - Define abstract link and path properties needed for link and path
   protection. Specify signalling mechanisms for path protection,
   diverse routing and fast path restoration. Ensure that multi-layer
   path protection and restoration functions are achievable using the
   defined signalling, routing, and measurement protocols, either
   separately or in combination.

 - Identify requirements for signaling and routing for ASON not currently
   met; based on these, define mechanisms to address these requirements.

 - Define a protocol that can determine the actual route and other
   properties of paths set up by CCAMP signaling protocols, as well
   as other types of tunnels (tunnel tracing).

 In doing this work, the WG will work closely with at least the following
 other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also cooperate with
 ITU-T.

 Goals and Milestones:
 Done Post strawman WG goals and charter
 Done Identify and document a limited set of candidate solutions for signalling
      and for measurement. Among candidate control solutions to be considered are the
      existing GMPLS drafts
 Done Build appropriate design teams
 Done Submit WG document defining path setup portions of common control plane protocol
 Done Submit WG document defining common measurement plane protocol
 Nov 03 Submit LMP MIB to IESG
 Dec 03 Submit GMPLS MIBs to IESG
 Dec 03 Submit protection & restoration documents to IESG
 Dec 03 Submit ASON signaling requirements doc to IESG
 Jan 04 Produce CCAMP WG document for multi-area/AS signaling and routing
 Jan 04 Produce CCAMP WG document for generic tunnel tracing protocol
 Feb 04 Submit ASON routing requirements doc to IESG
 Mar 04 Submit revised charter and milestones to IESG for IESG consideration of more
        detailed deliverables and determination of usefulness of continuation of WG

Delivery-date: Thu, 18 Sep 2003 05:36:05 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comparison of restoration requirements between transport and packet networks
Date: Wed, 17 Sep 2003 22:30:32 -0700

Neil,

Thanks for your explanation. I now understand better what you
were saying, and have some clarifications that I think may better
explain where the notification work sits.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2003 3:22 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Comparison of restoration requirements between transport
> and packet networks
>
>
> Vishal.....wrt to your question (snipped to it).  regards, Neil
>
> > > NH=> A laudable aim....but it will never be possible to set
> > hard bounds
> > > *unless* we fix the hierarchical client/server relationships for
> > > ever.  Let
> > > me give you and example for you to answer wrt to the activities
> > > in the PWE3
> > > group.  What is the protection speed requirments for
> > SDHoverMPLS in the
> > > client (SDH) and server (MPLS) case?  And now extend this to some
> > > arbitrary
> > > nested client/server stack where one operator may not own the
> > > layers below a
> > > certain point (and which he has no visibility of).......so what
> > > is there to
> > > control 'which' and 'how many' client/server transitions
> > exist below here?
> >
> > Perhaps a clarification here. Do you mean that client/server
> > relationships cannot be fixed for ever (because of structures
> > like SDHoverMPLS) or do you mean that SDHoverMPLS shouldn't be
> > defined?
> NH=> There are 3 network modes....cnls, co-ps and co-cs.  These have 9
> possible client/server permutations.  Some make far more sense
> architecturally than others.  I would *not* wish to be
> prescriptive on this
> if some people want to do 'odd things'.

Your characterization of network modes is certainly v. useful, but,
as you observed in your previous email, the focus of the notification
work is really at the transport/OTN network controlled by an IP
control plane.

Thus, how client layers recurse atop it (while an important topic), is
outside the scope of this work.
The reasonable assumption has to be that the provider (or
providers) setting up working relationships to use the transport
network would have to have thought about this during the service
planning exercise.

> However the point I was
> making was
> simply this....at some layer network one may not have
> control/sight of which
> lower layer trails support your link-connections.....and this behaviour
> recurses (ie link-connections in layer N are created by trails in
> layer N-1)
> to the duct.  So if (i) there is no control over the client/server
> relationships and (ii) one may not have control or visibilty of
> this anyway
> (ie leased capacity) then how can one set any sort of meaningful prot-sw
> timing bounds between layer networks?  The simple example I was giving was
> trying to illustrate this, eg assume SDH is designed to act
> faster than MPLS
> (because SDH is always assumed to be a lower server layer to
> MPLS) then what
> does this mean when carrying an SDH layer network over MPLS wrt to the
> prot-sw speed of the MPLS layer now?

In response to the two numbered points above:

For (i), I agree that if there is no control over client-server
relationships,
then prescribing timing bounds is difficult. However, a reasonable
assumption here would have to be, again, that the provider(s) setting up
the network and service would have (or impose) some control over what
client/server relationships they choose to allow in their network.

In that case, it seems to me that it makes a lot of sense for a client
layer to have some definite guarantees of how long its server layer will
take
to act in response to a legitimate fault (excluding self-correcting faults).

So would you agree that if one looks at the "classical" client/server
layer relationships, the notion of notification time bounds makes sense?

For (ii), when a carrier has no visibility into the
server layer, it seems to me that it is perhaps _even more important_ that
the server layer guarantee notification timing bounds (and, by extension,
some
reasonable protection switching timing bounds), so that these can be built
into the SLAs that the client-layer provider and server-layer provider
sign with each other.

This would allow the carrier operating the client layer to make some
definite assumptions about the reaction time of its server layer, and
build its service based on that.

The notification work, in fact, makes no assumption that the same carrier
has to have control of the complete layered network.

Hope this helps to clarify a bit the thinking behind the notification
work.

Delivery-date: Thu, 18 Sep 2003 04:34:28 +0000
Date: Thu, 18 Sep 2003 05:28:40 +0100 (BST)
From: =?iso-8859-1?q?sundar=20pandian?= <[email-masked]>
Subject: seeking suggestions regarding Thesis
To: [email-masked]

sir
i am student interested to take on IP over WDM
usingMP?s as part of my M.Tech thesis. can any one
give suggestions or reference for a good topic under
Ip over WDM.
thanks in advance
sundar

________________________________________________________________________
Yahoo! India Matrimony: Find your partner online.
Go to http://yahoo.shaadi.com

Delivery-date: Wed, 17 Sep 2003 22:57:41 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, CCAMP <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>, Alexey Zinin <[email-masked]>
Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Thu, 18 Sep 2003 00:56:08 +0200

> Hi Bert,
> 
> On Wed, 17 Sep 2003, Wijnen, Bert (Bert) wrote:
> 
> > WG chairs... what is the status according to you?
> 
> According to me, this document is ready for publication as an
> Informational RFC as a product of the CCAMP WG.  I'm not sure what the
> last action by the chairs was (i.e., did we send it to the IESG?),

Not that I know (or at least I do not remember).

> but we did a WG Last Call, and the comments recevied were incorporated
> by the authors.
> 
And the doc has now expired and no longer exists?

> I will formally send a request to the IESG to publish this doc.
> 
You do such by sending a request for publication (with intended status)
to your primary AD (so me in this case) and copy [email-masked]
so that they can put it into ID-tracker and so that it does not fall
through the cracks.

Bert
> Kireeti.
> 

Delivery-date: Wed, 17 Sep 2003 22:28:33 +0000
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Comparison of restoration requirements between transport and  packet networks
Date: Wed, 17 Sep 2003 23:22:01 +0100

Vishal.....wrt to your question (snipped to it).  regards, Neil

> > NH=> A laudable aim....but it will never be possible to set 
> hard bounds
> > *unless* we fix the hierarchical client/server relationships for
> > ever.  Let
> > me give you and example for you to answer wrt to the activities
> > in the PWE3
> > group.  What is the protection speed requirments for 
> SDHoverMPLS in the
> > client (SDH) and server (MPLS) case?  And now extend this to some
> > arbitrary
> > nested client/server stack where one operator may not own the
> > layers below a
> > certain point (and which he has no visibility of).......so what
> > is there to
> > control 'which' and 'how many' client/server transitions 
> exist below here?
> 
> Perhaps a clarification here. Do you mean that client/server
> relationships cannot be fixed for ever (because of structures
> like SDHoverMPLS) or do you mean that SDHoverMPLS shouldn't be
> defined?
NH=> There are 3 network modes....cnls, co-ps and co-cs.  These have 9
possible client/server permutations.  Some make far more sense
architecturally than others.  I would *not* wish to be prescriptive on this
if some people want to do 'odd things'.  However the point I was making was
simply this....at some layer network one may not have control/sight of which
lower layer trails support your link-connections.....and this behaviour
recurses (ie link-connections in layer N are created by trails in layer N-1)
to the duct.  So if (i) there is no control over the client/server
relationships and (ii) one may not have control or visibilty of this anyway
(ie leased capacity) then how can one set any sort of meaningful prot-sw
timing bounds between layer networks?  The simple example I was giving was
trying to illustrate this, eg assume SDH is designed to act faster than MPLS
(because SDH is always assumed to be a lower server layer to MPLS) then what
does this mean when carrying an SDH layer network over MPLS wrt to the
prot-sw speed of the MPLS layer now?

Delivery-date: Wed, 17 Sep 2003 18:22:07 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>
Cc: "CCAMP" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, "Alexey Zinin" <[email-masked]>
Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Wed, 17 Sep 2003 11:07:39 -0700

Hi Kireeti,

Thanks for your quick response. Since the request to resurrect
the 02 version of the draft has already been sent to the IETF
Secretariat, the document should soon show up on the IETF page.

So, we will now wait to address any last comments received
after the IESG review.

Thanks again for sending in the formal request to the IESG.

-Vishal

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2003 7:41 AM
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]'; CCAMP; Ronald P. Bonica; Greg Bernstein; Eric
> Mannie; Alexey Zinin
> Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
> 
> 
> Hi Bert,
> 
> On Wed, 17 Sep 2003, Wijnen, Bert (Bert) wrote:
> 
> > WG chairs... what is the status according to you?
> 
> According to me, this document is ready for publication as an
> Informational RFC as a product of the CCAMP WG.  I'm not sure what the
> last action by the chairs was (i.e., did we send it to the IESG?),
> but we did a WG Last Call, and the comments recevied were incorporated
> by the authors.
> 
> I will formally send a request to the IESG to publish this doc.
> 
> Kireeti.
> 

Delivery-date: Wed, 17 Sep 2003 14:45:00 +0000
Date: Wed, 17 Sep 2003 07:40:54 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, CCAMP <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>, Alexey Zinin <[email-masked]>
Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt

Hi Bert,

On Wed, 17 Sep 2003, Wijnen, Bert (Bert) wrote:

> WG chairs... what is the status according to you?

According to me, this document is ready for publication as an
Informational RFC as a product of the CCAMP WG.  I'm not sure what the
last action by the chairs was (i.e., did we send it to the IESG?),
but we did a WG Last Call, and the comments recevied were incorporated
by the authors.

I will formally send a request to the IESG to publish this doc.

Kireeti.

Delivery-date: Wed, 17 Sep 2003 09:22:37 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Cc: CCAMP <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>, Alexey Zinin <[email-masked]>
Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Wed, 17 Sep 2003 11:17:59 +0200

If you go to the I-D tracker web pages:

   https://datatracker.ietf.org/public/pidtracker.cgi

and you fill in your document name (without the revision,
i.e. just draft-ietf-ccamp-sdhsonet-control) and press the
SEARCH button, then you will see that the document is
completely unknown to the system. So the CCAMP WG (chairs)
have never requested publication of this document (or if
they did it was never entered into the system and so now 
it really got lost).

WG chairs... what is the status according to you?

Thanks,
Bert 

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: woensdag 17 september 2003 3:47
> To: Wijnen, Bert (Bert); [email-masked]
> Cc: CCAMP; Kireeti Kompella; Ronald P. Bonica; Greg Bernstein; Eric
> Mannie; Alexey Zinin
> Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
> 
> 
> Hi Bert and Dimitri,
> 
> Thanks for the clarifications.  While this helps to understand
> what happened to some documents that don't show up on the CCAMP
> web page, it still does not tell us the status of our specific
> draft.
> 
> So my question still remains I guess -- is this draft now
> with the IESG?
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, September 16, 2003 3:31 PM
> > To: [email-masked]'; [email-masked]
> > Cc: CCAMP; Kireeti Kompella; Ronald P. Bonica; Greg Bernstein; Eric
> > Mannie; Alexey Zinin
> > Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
> > 
> > 
> > .. snip ..
> > 
> > > .. but other i-d's such as the gmpls survey(*) have
> > > also been removed from this webpage (its expiration date
> > > was may'03)
> > > 
> > > (*) but the survey still appears in the protocol implementation
> > > reports page (but also not in the i-d tracker):
> > > 
> > > 
> > <http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implement
> ation.txt>
> > 
> That is because this was a "implementation report" passed to 
> IESG with the
> request to publish various docs as stds track RFCs. So 
> (although it has 
> the format of an I-D) it has been saved permanently as a 
> separate report. 
> 
> Hope this helps/explains,
> 
> Bert
> 
> 

Delivery-date: Wed, 17 Sep 2003 01:52:16 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>
Cc: "CCAMP" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, "Alexey Zinin" <[email-masked]>
Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Tue, 16 Sep 2003 18:47:28 -0700

Hi Bert and Dimitri,

Thanks for the clarifications.  While this helps to understand
what happened to some documents that don't show up on the CCAMP
web page, it still does not tell us the status of our specific
draft.

So my question still remains I guess -- is this draft now
with the IESG?

-Vishal

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, September 16, 2003 3:31 PM
> To: [email-masked]'; [email-masked]
> Cc: CCAMP; Kireeti Kompella; Ronald P. Bonica; Greg Bernstein; Eric
> Mannie; Alexey Zinin
> Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
> 
> 
> .. snip ..
> 
> > .. but other i-d's such as the gmpls survey(*) have
> > also been removed from this webpage (its expiration date
> > was may'03)
> > 
> > (*) but the survey still appears in the protocol implementation
> > reports page (but also not in the i-d tracker):
> > 
> > 
> <http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implement
ation.txt>
> 
That is because this was a "implementation report" passed to IESG with the
request to publish various docs as stds track RFCs. So (although it has 
the format of an I-D) it has been saved permanently as a separate report. 

Hope this helps/explains,

Bert

Delivery-date: Tue, 16 Sep 2003 22:34:46 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: CCAMP <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>, Alexey Zinin <[email-masked]>
Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Wed, 17 Sep 2003 00:31:22 +0200

.. snip ..

> .. but other i-d's such as the gmpls survey(*) have
> also been removed from this webpage (its expiration date
> was may'03)
> 
> (*) but the survey still appears in the protocol implementation
> reports page (but also not in the i-d tracker):
> 
> <http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implementation.txt>
> 
That is because this was a "implementation report" passed to IESG with the
request to publish various docs as stds track RFCs. So (although it has 
the format of an I-D) it has been saved permanently as a separate report. 

Hope this helps/explains,

Bert

Delivery-date: Tue, 16 Sep 2003 21:41:51 +0000
From: Michael Mandelberg <[email-masked]>
To: [email-masked]
Subject: IF_ID ERROR_SPEC allowed in any message?
Date: Tue, 16 Sep 2003 17:34:46 -0400

This object is specified in 3473 section 8.2.2 to be used, if desired, in
the PATH_ERR and RESV_ERR messages. Is it permitted as well in other
messages, such as the NOTIFY and RESV_CONF messages?

Thanks

Michael Mandelberg

Delivery-date: Tue, 16 Sep 2003 21:28:08 +0000
Date: Tue, 16 Sep 2003 23:27:18 +0200
From: [email-masked]
To: [email-masked]
Cc: CCAMP <[email-masked]>, Kireeti Kompella <[email-masked]>, "Ronald P. Bonica" <[email-masked]>, Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>, Alexey Zinin <[email-masked]>
Subject: Re: Status of draft-ietf-ccamp-sdhsonet-control-02.txt

vishal, my two (euro-)cents

fyi don't see it in the i-d status tracker (a very useful
tool btw) but other i-d's such as the gmpls survey(*) have
also been removed from this webpage (its expiration date
was may'03)

(*) but the survey still appears in the protocol implementation
reports page (but also not in the i-d tracker):

<http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implementation.txt>

thanks,
- dimitri.

Vishal Sharma wrote:
> Hi Kireeti and Ron,
> 
> The above draft was well on its way to becoming an
> informational RFC, per the WG status presented by Kireeti
> in March, and showed up in the CCAMP charter dated 05/21/03
> here:
> http://216.239.53.104/search?q=cache:PC8LauUeBg8J:www.cs-ipv6.lancs.ac.uk/ip
> v6/documents/standards/general-comms/ietf/ccamp/ccamp-charter.txt+draft-ietf
> -ccamp-sdhsonet-control-02.txt&hl=en&ie=UTF-8
> 
> However, I noticed today that it no longer appears on the
> CCAMP WG IETF page, and it also does not show up in a version
> of the charter dated 09/10/03 posted here
> http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/standards/general-comms/ietf/c
> camp/ccamp-charter.txt
> 
> So I am writing to find out the status of our document.
> We had made all the required and requested revisions in
> response to previous last calls as far back as July of last
> year, thereafter it was only a matter of it getting through
> the pipeline.
> 
> Could you please let us know the status of our document.
> Is it with the IESG now?
> 
> Thanks,
> -Vishal
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 16 Sep 2003 21:04:59 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comparison of restoration requirements between transport and packet networks
Date: Tue, 16 Sep 2003 13:59:46 -0700

Hi Neil,

Thanks for your comments.  A couple of comments and
questions in-line.

-Vishal

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Sunday, September 14, 2003 2:07 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Comparison of restoration requirements between transport and
> packet networks
>
>
> Hi Richard....please see in-line.  regards, Neil

<snip>

> [Richard] I wholeheartedly agree. 50 ms is most probably not doable in
> shared mesh networks.
> NH=> That was not my point......50ms is *not* required by applications was
> my point.  I see people doing irrational things that have little real
> prectical benefit, and this is not the worst offender.....see my brief
> remarks on 'complexity' in my prior mail, which I have snipped out below.
>
> The general rule with protection/restoration is:
> "As fast as *sensible* (ie don't trigger on error events) as close to the
> duct, and as slow as possible close to the application (and for sure don't
> trigger on error events here......noting that error events can
> get extended
> as they map upwards through layer networks)."

Point well taken. However, I think the original point merely
was that some time bounds (50 ms) may be unrealistic in some situations. But
whatever be the value of time bounds, it would be useful to have some,
so that P&R can be adequately planned. (Of course, that may
require some layering relationships, as you point out below.)

> The other point I was alluding to is that one requires all the defects for
> the mode/technology in question to have been specified in terms of
> entry/exit criteria and consequent actions......and for co modes the FDI
> consequent action is essential for the reaosn I gave previously (snipped
> here).  There are 3, and only 3, networking modes, viz cnls, co-ps and
> co-cs.....all technologies map to one of these.  All modes are
> required, as
> all provide different behaviours.  However, the functional components of
> each mode should migrate to best-of-breed......not crunched
> across all modes
> as that makes zero technical/commercial sense.  OAM and fault
> detection/handling is one key functional component.  It has a different
> specification in the cnls, co-ps and co-cs cases.  It also
> assumes that the
> functional architecture of G.805 (co modes) and G.809 (cnls) is respected.
> In the co-ps/cs case the only valid topologies are p2p and
> p2mp.......break
> the rules here (can't in co-cs mode anyway, can in co-ps mode)
> and you have
> created a difficult (and quite unecessary) OAM/fault-management problem.
> That was was other point wrt to 'can you point to where the defects are
> specified is you want this proposal to be mode/technology agnostic?'

Again, thanks for the thoughts.
I agree that there needs to be some thought given to defect definition,
and some of this will influence the notification actions. However, we'd
like to decouple defect definition from fault notification (which
really begins after a defect (appropriately defined) has been "detected").
Otherwise, the problem is too vast in scope to be handled in one draft.
As Richard pointed out, the focus of the draft is on OTN-related defects.

<snip>
>  [Richard] It may be doable in simpler configurations.  The whole point of
the draft
> is to *guarantee* a notification time.  With all the layers doing
> some kind
> of protection and restoration at different time granularities, escalation
> some layers need to wait for lower layers to recover from a fault/defect
> before starting their own process. How does one define the time
> if there is
> no time guarantee?
> NH=> A laudable aim....but it will never be possible to set hard bounds
> *unless* we fix the hierarchical client/server relationships for
> ever.  Let
> me give you and example for you to answer wrt to the activities
> in the PWE3
> group.  What is the protection speed requirments for SDHoverMPLS in the
> client (SDH) and server (MPLS) case?  And now extend this to some
> arbitrary
> nested client/server stack where one operator may not own the
> layers below a
> certain point (and which he has no visibility of).......so what
> is there to
> control 'which' and 'how many' client/server transitions exist below here?

Perhaps a clarification here. Do you mean that client/server
relationships cannot be fixed for ever (because of structures
like SDHoverMPLS) or do you mean that SDHoverMPLS shouldn't be
defined?

>   Should we assign a random value and hope for the best or should
> there be a
> time after which one is assured that the other layer did not
> accomplish its
> task and engage its own recovery mechanism. Assign 1 second or
> 200 ms or any
> time as being a hard bound, but make it hard.
> The defects that we thought about when we wrote this draft are:
> -       Fiber cut
> -       Transponder failure
> -       Node failure
> I hope this clears up the misunderstanding.
> NH=> See my remarks above.  Wrt to the defects you considered,
> yes I realise you homed in on the OTN.

Great, thanks. So we're in agreement on what the draft is focusing
on.

Delivery-date: Tue, 16 Sep 2003 07:14:11 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>
Cc: "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>, "Alexey Zinin" <[email-masked]>
Subject: Status of draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Tue, 16 Sep 2003 00:07:08 -0700

Hi Kireeti and Ron,

The above draft was well on its way to becoming an
informational RFC, per the WG status presented by Kireeti
in March, and showed up in the CCAMP charter dated 05/21/03
here:
http://216.239.53.104/search?q=cache:PC8LauUeBg8J:www.cs-ipv6.lancs.ac.uk/ip
v6/documents/standards/general-comms/ietf/ccamp/ccamp-charter.txt+draft-ietf
-ccamp-sdhsonet-control-02.txt&hl=en&ie=UTF-8

However, I noticed today that it no longer appears on the
CCAMP WG IETF page, and it also does not show up in a version
of the charter dated 09/10/03 posted here
http://www.cs-ipv6.lancs.ac.uk/ipv6/documents/standards/general-comms/ietf/c
camp/ccamp-charter.txt

So I am writing to find out the status of our document.
We had made all the required and requested revisions in
response to previous last calls as far back as July of last
year, thereafter it was only a matter of it getting through
the pipeline.

Could you please let us know the status of our document.
Is it with the IESG now?

Thanks,
-Vishal

Delivery-date: Sun, 14 Sep 2003 09:12:38 +0000
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Comparison of restoration requirements between transport and  packet networks
Date: Sun, 14 Sep 2003 10:07:12 +0100

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

------_=_NextPart_001_01C37A9F.9312921C
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Richard....please see in-line.  regards, Neil

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 13 September 2003 00:29
To: Harrison,N,Neil,IKL2 R; [email-masked]
Subject: RE: Comparison of restoration requirements between transport and
packet networks

Hi Neil,

Please see comments inline

Thanks,

Richard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, September 11, 2003 5:06 AM
To: [email-masked]; [email-masked]
Subject: RE: Comparison of restoration requirements between transport and
packet networks

Richard,

In section 1 of your paper it says:

"This document presents a fault notification protocol that is both
technology and topology agnostic, and applies to intra-domain  protection. "

[Richard] What the draft meant is that we do not described the technology
implementation of the flooding method described in it. Rather we keep the
implementation separate. I'll change to sentence to clear the
misunderstanding

That being the case, wherever it is to be used one needs all the defects
defining.  Defects should be detected in the data-plane (and not by
control-plane proxy) at the trail termination point using the OAM functions
appropriate to the mode/technology, ie cnls is different to co-ps is
different to co-cs.  If one wants to go 'fast' (and I seriously question the
sanity of those seeking to beat 50ms in SDH at higher layer networks) then
only certain defects and technologies are relevant.  Further, one should
take care not to invoke protection/restoration for error events which
self-clear.

[Richard] I wholeheartedly agree. 50 ms is most probably not doable in
shared mesh networks. 

NH=> That was not my point......50ms is *not* required by applications was
my point.  I see people doing irrational things that have little real
prectical benefit, and this is not the worst offender.....see my brief
remarks on 'complexity' in my prior mail, which I have snipped out below.

The general rule with protection/restoration is:

"As fast as *sensible* (ie don't trigger on error events) as close to the
duct, and as slow as possible close to the application (and for sure don't
trigger on error events here......noting that error events can get extended
as they map upwards through layer networks)."

The other point I was alluding to is that one requires all the defects for
the mode/technology in question to have been specified in terms of
entry/exit criteria and consequent actions......and for co modes the FDI
consequent action is essential for the reaosn I gave previously (snipped
here).  There are 3, and only 3, networking modes, viz cnls, co-ps and
co-cs.....all technologies map to one of these.  All modes are required, as
all provide different behaviours.  However, the functional components of
each mode should migrate to best-of-breed......not crunched across all modes
as that makes zero technical/commercial sense.  OAM and fault
detection/handling is one key functional component.  It has a different
specification in the cnls, co-ps and co-cs cases.  It also assumes that the
functional architecture of G.805 (co modes) and G.809 (cnls) is respected.
In the co-ps/cs case the only valid topologies are p2p and p2mp.......break
the rules here (can't in co-cs mode anyway, can in co-ps mode) and you have
created a difficult (and quite unecessary) OAM/fault-management problem.
That was was other point wrt to 'can you point to where the defects are
specified is you want this proposal to be mode/technology agnostic?'

 

 It may be doable in simpler configurations.  The whole point of the draft
is to *guarantee* a notification time.  With all the layers doing some kind
of protection and restoration at different time granularities, escalation
some layers need to wait for lower layers to recover from a fault/defect
before starting their own process. How does one define the time if there is
no time guarantee? 

NH=> A laudable aim....but it will never be possible to set hard bounds
*unless* we fix the hierarchical client/server relationships for ever.  Let
me give you and example for you to answer wrt to the activities in the PWE3
group.  What is the protection speed requirments for SDHoverMPLS in the
client (SDH) and server (MPLS) case?  And now extend this to some arbitrary
nested client/server stack where one operator may not own the layers below a
certain point (and which he has no visibility of).......so what is there to
control 'which' and 'how many' client/server transitions exist below here?

{Aside -  I have some interesting ideas how to architecturally model/control
arbitrary (and silly) client/server relationships (eg like SDHoverIP) from a
performance HRX viewpoint....but that is not for discussion here.}

  Should we assign a random value and hope for the best or should there be a
time after which one is assured that the other layer did not accomplish its
task and engage its own recovery mechanism. Assign 1 second or 200 ms or any
time as being a hard bound, but make it hard.

The defects that we thought about when we wrote this draft are:

-       Fiber cut

-       Transponder failure

-       Node failure

I hope this clears up the misunderstanding. 

NH=> See my remarks above.  Wrt to the defects you considered, yes I realise
you homed in on the OTN.

<NH snipped to end>

------_=_NextPart_001_01C37A9F.9312921C
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 5.00.3013.2600" name=3DGENERATOR>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:windowtext;}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.emailstyle19
	{font-family:Arial;
	color:navy;}
span.EmailStyle20
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US link=3Dblue vLink=3Dpurple>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D450132308-14092003>Hi Richard....please see in-line.&nbsp; =
regards,=20
Neil</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #800000 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Richard Rabbat=20
  [mailto:[email-masked]]<BR><B>Sent:</B> 13 September 2003=20
  00:29<BR><B>To:</B> Harrison,N,Neil,IKL2 R;=20
  [email-masked]<BR><B>Subject:</B> RE: Comparison of restoration=20
  requirements between transport and packet =
networks<BR><BR></DIV></FONT>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Hi=20
  Neil,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Please see =
comments=20
  inline</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: =
10pt">Thanks,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: =
10pt">Richard.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; =
BORDER-RIGHT: medium none; BORDER-TOP: medium none; PADDING-BOTTOM: =
0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; PADDING-TOP: 0in">
  <P class=3DMsoNormal><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =

  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of=20
  </SPAN></B>[email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> </SPAN></FONT><FONT =
face=3DTahoma=20
  size=3D2><SPAN style=3D"FONT-FAMILY: Tahoma; FONT-SIZE: =
10pt">Thursday, September=20
  11, 2003</SPAN></FONT><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"> </SPAN></FONT><FONT =
face=3DTahoma=20
  size=3D2><SPAN style=3D"FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">5:06=20
  AM</SPAN></FONT><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> [email-masked];=20
  [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RE: Comparison of restoration requirements between transport and =
packet=20
  networks</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal><FONT color=3Dmaroon face=3D"Comic Sans MS" =
size=3D2><SPAN=20
  style=3D"COLOR: maroon; FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
10pt">Richard,</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT color=3Dmaroon face=3D"Comic Sans MS" =
size=3D2><SPAN=20
  style=3D"COLOR: maroon; FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
10pt">In=20
  section 1 of your paper it says:</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT color=3Dmaroon face=3D"Comic Sans MS" =
size=3D2><SPAN=20
  style=3D"COLOR: maroon; FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
10pt">"This=20
  document presents a fault notification protocol that is =
both&nbsp;technology=20
  and topology agnostic, and applies to intra-domain&nbsp;=20
  protection.&nbsp;"</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P>
  <P class=3DMsoNormal><B><I><FONT color=3Dnavy face=3DArial =
size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt; =
FONT-STYLE: italic; FONT-WEIGHT: bold">[Richard]=20
  </SPAN></FONT></I></B><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">What the =
draft meant=20
  is that we do not described the technology implementation of the =
flooding=20
  method described in it. Rather we keep the implementation separate. =
I&#8217;ll=20
  change to sentence to clear the misunderstanding</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT color=3Dmaroon face=3D"Comic Sans MS" =
size=3D2><SPAN=20
  style=3D"COLOR: maroon; FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
10pt">That=20
  being the case, wherever it is to be used one needs all the defects=20
  defining.&nbsp; Defects should be detected in the data-plane (and not =
by=20
  control-plane proxy) at the trail termination point using the OAM =
functions=20
  appropriate to the mode/technology, ie cnls is different to co-ps is =
different=20
  to co-cs.&nbsp; If one wants to go 'fast' (and I seriously question =
the sanity=20
  of those seeking to beat 50ms in SDH at higher layer networks) then =
only=20
  certain defects and technologies are relevant.&nbsp; Further, one =
should take=20
  care not to invoke protection/restoration for error events which=20
  self-clear.</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><B><I><FONT color=3Dnavy face=3D"Times New =
Roman" size=3D3><SPAN=20
  style=3D"COLOR: navy; FONT-SIZE: 12pt; FONT-STYLE: italic; =
FONT-WEIGHT: bold">[Richard]=20
  </SPAN></FONT></I></B><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">I =
wholeheartedly=20
  agree. 50 ms is most probably not doable in shared mesh =
networks.<SPAN=20
  class=3D450132308-14092003><FONT color=3D#800000=20
  face=3D"Comic Sans MS">&nbsp;</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080 face=3D"Comic Sans =
MS">NH=3D&gt; That=20
  was not my point......50ms is *not* required by applications was my=20
  point.&nbsp; I see people doing irrational things that have little =
real=20
  prectical benefit, and this is not the worst offender.....see my =
brief remarks=20
  on 'complexity' in my prior mail, which I have snipped out=20
  below.</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080=20
  face=3D"Comic Sans MS"></FONT></SPAN></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080 face=3D"Comic Sans =
MS">The general=20
  rule with protection/restoration is:</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080=20
  face=3D"Comic Sans MS">"As&nbsp;fast as *sensible* (ie don't trigger =
on error=20
  events) as close to the duct, and as slow as possible close to the =
application=20
  (and for sure don't trigger on error events here......noting that =
error events=20
  can get extended as they map upwards through layer=20
  networks)."</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT=20
  face=3D"Comic Sans MS"></FONT></SPAN></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080 face=3D"Comic Sans =
MS">The other=20
  point I was alluding to is that one requires all the defects for the=20
  mode/technology in question to have been specified in terms of =
entry/exit=20
  criteria and consequent actions......and for co modes the FDI =
consequent=20
  action is essential for the reaosn I gave previously (snipped =
here).&nbsp;=20
  There are 3, and only 3, networking modes, viz cnls, co-ps and =
co-cs.....all=20
  technologies map to one of these.&nbsp; All modes are required, as =
all provide=20
  different behaviours.&nbsp; However, the functional components of =
each mode=20
  should migrate to best-of-breed......not crunched across all modes as =
that=20
  makes zero technical/commercial sense.&nbsp; OAM and fault =
detection/handling=20
  is&nbsp;one key functional component.&nbsp; It has a different =
specification=20
  in the cnls, co-ps and co-cs cases.&nbsp; It also assumes that the =
functional=20
  architecture of G.805 (co modes) and G.809 (cnls) is respected.&nbsp; =
In the=20
  co-ps/cs case the only valid topologies are p2p and p2mp.......break =
the rules=20
  here (can't in co-cs mode anyway, can in co-ps mode) and you have =
created a=20
  difficult (and quite unecessary) OAM/fault-management problem.&nbsp; =
That was=20
  was other point wrt to 'can you point to where the defects are =
specified is=20
  you want this proposal to be mode/technology=20
  agnostic?'</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal>&nbsp;</P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003></SPAN><SPAN =
class=3D450132308-14092003><FONT=20
  color=3D#800000 face=3D"Comic Sans =
MS">&nbsp;</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003>&nbsp;</SPAN>It may be doable in simpler=20
  configurations.&nbsp; The whole point of the draft is to *<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">guarantee</SPAN></B>* a notification =
time.&nbsp;=20
  With all the layers doing some kind of protection and restoration at =
different=20
  time granularities, escalation some layers need to wait for lower =
layers to=20
  recover from a fault/defect before starting their own process. How =
does one=20
  define the time if there is no time guarantee?<SPAN=20
  class=3D450132308-14092003><FONT color=3D#800000=20
  face=3D"Comic Sans MS">&nbsp;</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080 face=3D"Comic Sans =
MS">NH=3D&gt; A=20
  laudable aim....but it will never be possible to set hard bounds =
*unless* we=20
  fix the hierarchical client/server relationships for ever.&nbsp; Let =
me give=20
  you and example&nbsp;for you to answer wrt to the activities in the =
PWE3=20
  group.&nbsp; What is the protection speed requirments for SDHoverMPLS =
in the=20
  client (SDH) and server (MPLS) case?&nbsp; And now extend this to =
some=20
  arbitrary nested client/server stack where one operator may not own =
the layers=20
  below a certain point (and which he has no visibility of).......so =
what is=20
  there to control 'which' and 'how many' client/server transitions =
exist below=20
  here?</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003><FONT color=3D#800080 face=3D"Comic Sans =
MS">{Aside=20
  -&nbsp; I have some interesting ideas how to architecturally =
model/control=20
  arbitrary (and silly) client/server relationships (eg like SDHoverIP) =
from a=20
  performance HRX viewpoint....but that is not for discussion=20
  here.}</FONT></SPAN></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003></SPAN></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><SPAN=20
  class=3D450132308-14092003>&nbsp;</SPAN> Should we assign a random =
value and=20
  hope for the best or should there be a time after which one is =
assured that=20
  the other layer did not accomplish its task and engage its own =
recovery=20
  mechanism. Assign 1 second or 200 ms or any time as being a hard =
bound, but=20
  make it hard.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">The =
defects that we=20
  thought about when we wrote this draft are:</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT><FONT color=3Dnavy face=3DArial =
size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Fiber=20
  cut</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT><FONT color=3Dnavy face=3DArial =
size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: =
10pt">Transponder=20
  failure</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT=20
  color=3Dnavy face=3DArial size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">-<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT><FONT color=3Dnavy face=3DArial =
size=3D2><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Node=20
  failure</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">I hope =
this clears up=20
  the misunderstanding.<FONT color=3D#800000 face=3D"Comic Sans =
MS"><SPAN=20
  class=3D450132308-14092003>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><FONT =
color=3D#800000=20
  face=3D"Comic Sans MS"><SPAN class=3D450132308-14092003><FONT=20
  color=3D#800080>NH=3D&gt; See my remarks above.&nbsp; Wrt to the =
defects you=20
  considered, yes I realise you homed in on the=20
  OTN</FONT>.</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><FONT =
color=3D#800000=20
  face=3D"Comic Sans MS"><SPAN=20
  class=3D450132308-14092003></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial><SPAN=20
  style=3D"COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt"><FONT =
color=3D#800080=20
  face=3D"Comic Sans MS"><SPAN class=3D450132308-14092003>&lt;NH =
snipped to=20
  end&gt;</SPAN></FONT></SPAN></FONT></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: maroon 1.5pt solid; =
BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN: 5pt 0in 5pt =
3.75pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; =
PADDING-TOP: 0in">
    <DIV=20
    style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; =
BORDER-RIGHT: medium none; BORDER-TOP: medium none; PADDING-BOTTOM: =
0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; PADDING-TOP: 0in">
    <BLOCKQUOTE=20
    style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: maroon 1.5pt =
solid; BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN: 5pt =
0in 5pt 3.75pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: =
0in; PADDING-TOP: 0in">
      <P=20
class=3DMsoNormal>&nbsp;</P></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV></DIV>=
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C37A9F.9312921C--

Delivery-date: Fri, 12 Sep 2003 23:33:24 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comparison of restoration requirements between transport and packet networks
Date: Fri, 12 Sep 2003 16:29:00 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C3794A.F991F960
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Neil,

Please see comments inline

Thanks,

Richard.

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf
Of [email-masked]
Sent: Thursday, September 11, 2003 5:06 AM
To: [email-masked]; [email-masked]
Subject: RE: Comparison of restoration requirements between transport =
and
packet networks

=20

Richard,

=20

In section 1 of your paper it says:

=20

"This document presents a fault notification protocol that is both
technology and topology agnostic, and applies to intra-domain  =
protection. "

=20

[Richard] What the draft meant is that we do not described the =
technology
implementation of the flooding method described in it. Rather we keep =
the
implementation separate. I'll change to sentence to clear the
misunderstanding

=20

That being the case, wherever it is to be used one needs all the defects
defining.  Defects should be detected in the data-plane (and not by
control-plane proxy) at the trail termination point using the OAM =
functions
appropriate to the mode/technology, ie cnls is different to co-ps is
different to co-cs.  If one wants to go 'fast' (and I seriously question =
the
sanity of those seeking to beat 50ms in SDH at higher layer networks) =
then
only certain defects and technologies are relevant.  Further, one should
take care not to invoke protection/restoration for error events which
self-clear.

[Richard] I wholeheartedly agree. 50 ms is most probably not doable in
shared mesh networks. It may be doable in simpler configurations.  The =
whole
point of the draft is to *guarantee* a notification time.  With all the
layers doing some kind of protection and restoration at different time
granularities, escalation some layers need to wait for lower layers to
recover from a fault/defect before starting their own process. How does =
one
define the time if there is no time guarantee? Should we assign a random
value and hope for the best or should there be a time after which one is
assured that the other layer did not accomplish its task and engage its =
own
recovery mechanism. Assign 1 second or 200 ms or any time as being a =
hard
bound, but make it hard.

The defects that we thought about when we wrote this draft are:

-       Fiber cut

-       Transponder failure

-       Node failure

I hope this clears up the misunderstanding.

=20

Some technologies are poorly specified wrt defects.  I therefore don't
believe your proposals are truly mode/technology generic as claimed.  =
That
was really the only point I was trying to make.

=20

But here are a few further remarks on you paper if you are
interested.........

=20

I personally don't like the sound of the proposals as its a complexity =
that
I don't think is necessary.

=20

[Richard] Thanks for the interesting comments and a very good =
presentation
of the problems at hand.  I believe we are looking at a slightly =
different
problem space within the context of protection/restoration.  We're going =
to
look at these carefully and get back to you on these points you make.

=20

{Aside -  One of the major problems we operators face is the cost of
complexity.  Quite a lot of the stuff I am seeing are complexities aimed =
at
BW squeezing.......which IMO have only a 2nd/3rd order potential benefit =
at
the expense of 1st order complexity capex/opex costs.  Well, BW may have
been the right metric to conserve 10+ years ago but its not true today =
(in
most cases).  I am not pointing the finger specifically at your work =
here,
but things like 'faster, faster, faster' restoration in all layers, =
having
lots of QoS/traffic classes *per* network mode, and stuff like multiple
class pre-emption/bumping are all examples of complexities whose costs
outweigh their benefits IMO.  We should use BW wisely to reduce =
complexity.
This is a major focus point of the future network architecture views we =
are
generating in BT, and at this point I don't really want to go any =
further on
this issue on the lists.}

=20

[Richard] w/r to this, we'll describe in more detail the network model =
at
hand.

=20

A trail termination point is the only place defects can be detected in
co-ps/cs modes.  So the entity that you describe as 'per failure' vs =
'per
LSP' in section 4 is not strictly correct.  I think what you really mean =
is
the single failure of a trail in some server layer network generating
multiple failures in all the client layer network trails it supports.  =
This
is a *recursive* behaviour.......and if you drew out the G.805 =
functional
architecture I think you would quickly realise this and, in particular, =
that
its the optical trail where your focus seems to lie (which I can
understand), which creates a link-connection in the immediately above =
layer
network).

=20

Given a trail termination point is the only place defects can be =
detected,
it is vital that one consequent action of defect detection at this point =
is
the generation of a Forward Defect Indication (FDI)......sometime known =
as
AIS.  The whole purpose of this signal is to tell all the higher layer
client networks (at *their* trail termination points) not to raise
alarms....else this will casue major problems/opex-costs chasing faults =
in
the wrong layer/place (this can be across different operators in =
different
countries so its a pretty serious issue).  This itself is a 'flooding'
behaviour but it is constrained flooding only to the affected
clients.....and not the rest of the server (or client) layer network(s) =
who
don't really need to know about this.

=20

In the case of a fibre-cut then FDI would go in both directions.  By
definition this must be the fastest form of signalling to inform the =
nodes
at either end of the affected trail(s).  In the case of uni-directional
failures then FDI would go forwards and one would have to either use the =
BDI
or some dedicated backwards signalling to inform the head end.

=20

So given we *must* have FDI for client layer alarm suppression then I am =
not
at all clear what benefits your proposal is giving that targeted fault
notification will not achieve just as well.

BTW - we have done extensive testing of restoration schemes using =
signalling
with crankback and simple routing (plus route pruning) processes.....and =
it
works great.

=20

regards, Neil

=20

 -----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 September 2003 23:12
To: [email-masked]
Subject: re: Comparison of restoration requirements between transport =
and
packet networks

Hi Neil,

=20

Thanks for the email. I'd like to ask you to expand a bit on your idea =
on
the mailing list. I'm afraid I'm a bit confused about the question and =
need
more information.

=20

Do you mean by your question:

-          How do we figure out what the defect is and where it =
happened? Is
it a fiber cut? Is it a misconfiguration? How do you do fault =
localization

Or:

-          What set of defects does your solution address?

Or maybe something else.

Thanks,

Richard.

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Wednesday, September 10, 2003 1:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comparison of restoration requirements between transport =
and
packet networks

=20

Where are the defects specified (take any networking mode/layer you =
like)
wrt entry/exit criteria and consequent actions?

=20

regards, Neil

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 September 2003 20:11
To: [email-masked]; Zafar Ali
Cc: Vishal Sharma; 'Richard Rabbat'
Subject: Comparison of restoration requirements between transport and =
packet
networks

Hi Zafar, CCAMP,

=20

=20

During discussions with several colleagues within the CCAMP WG, it has
become clear that it would be useful to clarify some of the fundamental
differences between restoration in packet networks and that in transport
networks.

This is because this difference, together with the time criticality of
restoration at the transport layer, requires the development of =
techniques
for time-bounded notification. It would then be useful to discuss the
solutions proposed in draft-rabbat-fault-notification-protocol-03 for =
such
notification.

=20

We are in the process of preparing a contribution on this subject, but
thought it would be useful to highlight a few key points on the mailing
list, so that we can elicit feedback and comments from the WG.

=20

In normal packet networks (MPLS networks) one can pre-signal *and*
pre-configure a backup LSP for a working LSP. This is because selecting =
a
label at a node for a backup LSP is sufficient to be able to switch =
traffic
for that LSP when that traffic arrives. If resources are required for =
the
backup LSP (buffers and bandwidth), they too can be reserved in advance
(during the LSP signaling phase), but can still be used by low-priority =
or
extra-traffic LSPs as long as there is no failure on the working LSP.

=20

This is true even for shared mesh restoration in MPLS networks. In that
case, multiple labels would be assigned, one for each of the backup LSPs
(corresponding to link and/or node disjoint working LSPs) transiting a =
node
on the shared backup path, but only one set of resources (buffers,
bandwidth) would be reserved (if such resource reservation was needed).

=20

In transport networks, however, one can pre-signal but not pre-configure =
a
backup LSP (unless one was doing just 1+1 protection). This is because, =
in
transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP.=20

=20

For this reason, to implement shared restoration schemes in transport
networks (and allow extra-traffic) a backup LSP cannot be =
cross-connected
until *after* the specific failure for which this backup LSP was
pre-signaled has occured.

=20

Now, if signaling-based notification is used in transport networks, an
*additional phase of signaling* is required along the backup path to =
enable
nodes along that path to reconfigure themselves (this is well-described =
in
the functional specification document

of the P&R Design Team). This lengthens the time to recover from the
failure. Depending on the layer at which recovery is being performed =
this
may or may not be acceptable.

=20

In the specific case of transport networks, restoration is typically a
time-critical activity, so this round-trip signaling delay could be
unacceptable when time-bounded notification and recovery is desired.

In addition, signaling individual LSPs or individual LSP bundles may =
create
buffering problems that makes signaling time unbounded.

=20

If instead, the information about a failure is flooded to all the =
network
nodes, and the backup paths are selected intelligently (as described in
draft-rabbat-fault-notification-protocol-03.txt), this additional =
signaling
hand-shake delay can be eliminated.  This is because by flooding the
information about a fault on a working LSP, one can inform, in parallel, =
all
the nodes lying along the path of the backup LSP. Thus, the repair =
point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup =
path(s)
will have reconfigured themselves.

=20

We would also like to get feedback on a suitable protocol that could
implement time-critical flooding notification.

=20

Comments, thoughts and questions are welcome!

=20

--

Richard Rabbat, Ph.D.

Member of Research Staff, Fujitsu Labs of America

1240 E Arques Ave, MS 345, Sunnyvale, CA 94085

Phone: 408-530-4537. Fax: 408-530-4581. Cell: 650-714-7618

=20

------=_NextPart_000_0047_01C3794A.F991F960
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:windowtext;}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.emailstyle19
	{font-family:Arial;
	color:navy;}
span.EmailStyle20
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Neil,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Please see comments =
inline</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Richard.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>[email-masked]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Thursday,
 September 11, 2003</span></font><font size=3D2 face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><font
 size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>5:06 AM</span></font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked];
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comparison =
of
restoration requirements between transport and packet =
networks</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>Richard,</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>In =
section 1
of your paper it says:</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>&quot;This
document presents a fault notification protocol that is =
both&nbsp;technology
and topology agnostic, and applies to intra-domain&nbsp;
protection.&nbsp;&quot;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Richard] </span></font></i></b><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>What the
draft meant is that we do not described the technology implementation of =
the
flooding method described in it. Rather we keep the implementation =
separate.
I&#8217;ll change to sentence to clear the =
misunderstanding</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>That =
being
the case, wherever it is to be used one needs all the defects =
defining.&nbsp;
Defects should be detected in the data-plane (and not by control-plane =
proxy)
at the trail termination point using the OAM functions appropriate to =
the
mode/technology, ie cnls is different to co-ps is different to =
co-cs.&nbsp; If
one wants to go 'fast' (and I seriously question the sanity of those =
seeking to
beat 50ms in SDH at higher layer networks) then only certain defects and
technologies are relevant.&nbsp; Further, one should take care not to =
invoke
protection/restoration for error events which =
self-clear.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><i><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-weight:bold;font-style:italic'>=
[Richard]
</span></font></i></b><font size=3D2 color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I wholeheartedly =
agree.
50 ms is most probably not doable in shared mesh networks. It may be =
doable in
simpler configurations.&nbsp; The whole point of the draft is to =
*<b><span
style=3D'font-weight:bold'>guarantee</span></b>* a notification =
time.&nbsp; With
all the layers doing some kind of protection and restoration at =
different time
granularities, escalation some layers need to wait for lower layers to =
recover
from a fault/defect before starting their own process. How does one =
define the
time if there is no time guarantee? Should we assign a random value and =
hope
for the best or should there be a time after which one is assured that =
the
other layer did not accomplish its task and engage its own recovery =
mechanism.
Assign 1 second or 200 ms or any time as being a hard bound, but make it =
hard.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The defects that we thought about =
when we
wrote this draft are:</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-<font size=3D1 face=3D"Times New Roman"><span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Fiber =
cut</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-<font size=3D1 face=3D"Times New Roman"><span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Transponder =
failure</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-<font size=3D1 face=3D"Times New Roman"><span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Node =
failure</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I hope this clears up the
misunderstanding.</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>Some
technologies are poorly specified wrt defects.&nbsp; I therefore don't =
believe
your proposals are truly mode/technology generic as claimed.&nbsp; That =
was
really the only point I was trying to make.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>But =
here are
a few further remarks on you paper if you are =
interested.........</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>I =
personally
don't like the sound of the proposals as its a complexity that I don't =
think is
necessary.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Richard] Thanks for the interesting comments and a =
very
good presentation of the problems at hand.&nbsp; I believe we are =
looking at a slightly
different problem space within the context of =
protection/restoration.&nbsp; We&#8217;re
going to look at these carefully and get back to you on these points you =
make.</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>{Aside -&nbsp;
One of the major problems we operators face is the cost of =
complexity.&nbsp;
Quite a lot of the stuff I am seeing are complexities aimed at BW
squeezing.......which IMO have only a 2nd/3rd order potential benefit at =
the
expense of 1st order complexity capex/opex costs.&nbsp; Well, BW may =
have been
the right metric to conserve 10+ years ago but its not true today (in =
most
cases).&nbsp; I am not pointing the finger specifically at your work =
here, but
things like 'faster, faster, faster' restoration in all layers, having =
lots of
QoS/traffic classes *per* network mode, and stuff like multiple class
pre-emption/bumping are all examples of complexities whose costs =
outweigh their
benefits IMO.&nbsp; We should use BW wisely to reduce complexity.&nbsp; =
This is
a major focus point of the future network architecture views we are =
generating
in BT, and at this point I don't really want to go any further on this =
issue on
the lists.}</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Richard] w/r to this, we&#8217;ll describe in more =
detail the
network model at hand.</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>A =
trail
termination point is the only place defects can be detected in co-ps/cs
modes.&nbsp; So the entity that you describe as 'per failure' vs 'per =
LSP' in
section 4 is not strictly correct.&nbsp; I think what you really mean is =
the
single failure of a trail in some server layer network generating =
multiple
failures in all the client layer network trails it supports.&nbsp; This =
is a
*recursive* behaviour.......and if you drew out the G.805 functional
architecture I think you would quickly realise this and, in particular, =
that
its the optical trail where your focus seems to lie (which I can =
understand),
which creates a link-connection in the immediately above layer =
network).</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>Given a trail
termination point is the only place defects can be detected, it is vital =
that
one consequent action of defect detection at this point is the =
generation of a
Forward Defect Indication (FDI)......sometime known as AIS.&nbsp; The =
whole
purpose of this signal is to tell all the higher layer client networks =
(at
*their* trail termination points) not to raise alarms....else this will =
casue
major problems/opex-costs chasing faults in the wrong layer/place (this =
can be
across different operators in different countries so its a pretty =
serious
issue).&nbsp; This itself is a 'flooding' behaviour but it is =
constrained
flooding only to the affected clients.....and not the rest of the server =
(or
client) layer network(s) who don't really need to know about =
this.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>In =
the case
of a fibre-cut then FDI would go in both directions.&nbsp; By definition =
this
must be the fastest form of signalling to inform the nodes at either end =
of the
affected trail(s).&nbsp; In the case of uni-directional failures then =
FDI would
go forwards and one would have to either use the BDI or some dedicated
backwards signalling to inform the head end.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>So =
given we
*must* have FDI for client layer alarm suppression then I am not at all =
clear
what benefits your proposal is giving that targeted fault notification =
will not
achieve just as well.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>BTW =
- we have
done extensive testing of restoration schemes using signalling with =
crankback
and simple routing (plus route pruning) processes.....and it works =
great.</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>regards, Neil</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>&nbsp;-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Richard Rabbat
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 10 September 2003 =
23:12<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> re: Comparison =
of
restoration requirements between transport and packet =
networks</span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid maroon =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Neil,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for the email. I&#8217;d =
like to
ask you to expand a bit on your idea on the mailing list. I&#8217;m =
afraid
I&#8217;m a bit confused about the question and need more =
information.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Do you mean by your =
question:</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>How do we figure out what the defect is and where it =
happened? Is
it a fiber cut? Is it a misconfiguration? How do you do fault =
localization</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Or:</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>What set of defects does your solution =
address?</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Or maybe something =
else.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Richard.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, =
September 10,
2003 1:13 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked];
[email-masked]; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comparison =
of
restoration requirements between transport and packet =
networks</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>Where are the
defects specified (take any networking mode/layer you like) wrt =
entry/exit
criteria and consequent actions?</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>regards, Neil</span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid maroon =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Richard Rabbat
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 10 September 2003 =
20:11<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]; =
Zafar Ali<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Vishal Sharma; =
'Richard
Rabbat'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comparison of =
restoration
requirements between transport and packet networks</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi Zafar, CCAMP,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>During discussions with several colleagues within the =
CCAMP
WG, it has become clear that it would be useful to clarify some of the
fundamental differences between restoration in packet networks and that =
in
transport networks.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is because this difference, together with the =
time
criticality of restoration at the transport layer, requires the =
development of
techniques for time-bounded notification. It would then be useful to =
discuss
the solutions proposed in draft-rabbat-fault-notification-protocol-03 =
for such
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We are in the process of preparing a contribution on =
this
subject, but thought it would be useful to highlight a few key points on =
the
mailing list, so that we can elicit feedback and comments from the =
WG.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In normal packet networks (MPLS networks) one can =
pre-signal
*and* pre-configure a backup LSP for a working LSP. This is because =
selecting a
label at a node for a backup LSP is sufficient to be able to switch =
traffic for
that LSP when that traffic arrives. If resources are required for the =
backup
LSP (buffers and bandwidth), they too can be reserved in advance (during =
the
LSP signaling phase), but can still be used by low-priority or =
extra-traffic
LSPs as long as there is no failure on the working =
LSP.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is true even for shared mesh restoration in MPLS
networks. In that case, multiple labels would be assigned, one for each =
of the
backup LSPs (corresponding to link and/or node disjoint working LSPs)
transiting a node on the shared backup path, but only one set of =
resources
(buffers, bandwidth) would be reserved (if such resource reservation was
needed).</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In transport networks, however, one can pre-signal =
but not
pre-configure a backup LSP (unless one was doing just 1+1 protection). =
This is
because, in transport networks, if an LSP is established (that is, it is =
cross-connected)
then the full bandwidth of the LSP is automatically *consumed*, =
irrespective of
whether traffic actually flows on this LSP. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For this reason, to implement shared restoration =
schemes in
transport networks (and allow extra-traffic) a backup LSP cannot be
cross-connected until *after* the specific failure for which this backup =
LSP
was pre-signaled has occured.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Now, if signaling-based notification is used in =
transport
networks, an *additional phase of signaling* is required along the =
backup path
to enable nodes along that path to reconfigure themselves (this is
well-described in the functional specification =
document</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>of the P&amp;R Design Team). This lengthens the time =
to
recover from the failure. Depending on the layer at which recovery is =
being
performed this may or may not be acceptable.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the specific case of transport networks, =
restoration is
typically a time-critical activity, so this round-trip signaling delay =
could be
unacceptable when time-bounded notification and recovery is =
desired.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In addition, signaling individual LSPs or individual =
LSP
bundles may create buffering problems that makes signaling time =
unbounded.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If instead, the information about a failure is =
flooded to
all the network nodes, and the backup paths are selected intelligently =
(as
described in draft-rabbat-fault-notification-protocol-03.txt), this =
additional
signaling hand-shake delay can be eliminated.&nbsp; This is because by =
flooding
the information about a fault on a working LSP, one can inform, in =
parallel,
all the nodes lying along the path of the backup LSP. Thus, the repair =
point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup =
path(s) will
have reconfigured themselves.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We would also like to get feedback on a suitable =
protocol
that could implement time-critical flooding =
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Comments, thoughts and questions are =
welcome!</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Richard Rabbat, Ph.D.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Member of Research Staff, Fujitsu Labs of =
America</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DFR =
style=3D'font-size:10.0pt;
font-family:Arial'>1240 E Arques Ave, MS 345, Sunnyvale, CA =
94085</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Phone: 408-530-4537. Fax: 408-530-4581. Cell: =
650-714-7618</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</blockquote>

</div>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_0047_01C3794A.F991F960--

Delivery-date: Thu, 11 Sep 2003 12:09:51 +0000
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Comparison of restoration requirements between transport and  packet networks
Date: Thu, 11 Sep 2003 13:06:12 +0100

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

------_=_NextPart_001_01C3785D.155B6D9B
Content-Type: text/plain;
	charset="ISO-8859-1"

Richard,
 
In section 1 of your paper it says:
 
"This document presents a fault notification protocol that is both
technology and topology agnostic, and applies to intra-domain  protection. "
 
That being the case, wherever it is to be used one needs all the defects
defining.  Defects should be detected in the data-plane (and not by
control-plane proxy) at the trail termination point using the OAM functions
appropriate to the mode/technology, ie cnls is different to co-ps is
different to co-cs.  If one wants to go 'fast' (and I seriously question the
sanity of those seeking to beat 50ms in SDH at higher layer networks) then
only certain defects and technologies are relevant.  Further, one should
take care not to invoke protection/restoration for error events which
self-clear.
 
Some technologies are poorly specified wrt defects.  I therefore don't
believe your proposals are truly mode/technology generic as claimed.  That
was really the only point I was trying to make.
 
But here are a few further remarks on you paper if you are
interested.........
 
I personally don't like the sound of the proposals as its a complexity that
I don't think is necessary.
 
{Aside -  One of the major problems we operators face is the cost of
complexity.  Quite a lot of the stuff I am seeing are complexities aimed at
BW squeezing.......which IMO have only a 2nd/3rd order potential benefit at
the expense of 1st order complexity capex/opex costs.  Well, BW may have
been the right metric to conserve 10+ years ago but its not true today (in
most cases).  I am not pointing the finger specifically at your work here,
but things like 'faster, faster, faster' restoration in all layers, having
lots of QoS/traffic classes *per* network mode, and stuff like multiple
class pre-emption/bumping are all examples of complexities whose costs
outweigh their benefits IMO.  We should use BW wisely to reduce complexity.
This is a major focus point of the future network architecture views we are
generating in BT, and at this point I don't really want to go any further on
this issue on the lists.}
 
A trail termination point is the only place defects can be detected in
co-ps/cs modes.  So the entity that you describe as 'per failure' vs 'per
LSP' in section 4 is not strictly correct.  I think what you really mean is
the single failure of a trail in some server layer network generating
multiple failures in all the client layer network trails it supports.  This
is a *recursive* behaviour.......and if you drew out the G.805 functional
architecture I think you would quickly realise this and, in particular, that
its the optical trail where your focus seems to lie (which I can
understand), which creates a link-connection in the immediately above layer
network).
 
Given a trail termination point is the only place defects can be detected,
it is vital that one consequent action of defect detection at this point is
the generation of a Forward Defect Indication (FDI)......sometime known as
AIS.  The whole purpose of this signal is to tell all the higher layer
client networks (at *their* trail termination points) not to raise
alarms....else this will casue major problems/opex-costs chasing faults in
the wrong layer/place (this can be across different operators in different
countries so its a pretty serious issue).  This itself is a 'flooding'
behaviour but it is constrained flooding only to the affected
clients.....and not the rest of the server (or client) layer network(s) who
don't really need to know about this.
 
In the case of a fibre-cut then FDI would go in both directions.  By
definition this must be the fastest form of signalling to inform the nodes
at either end of the affected trail(s).  In the case of uni-directional
failures then FDI would go forwards and one would have to either use the BDI
or some dedicated backwards signalling to inform the head end.
 
So given we *must* have FDI for client layer alarm suppression then I am not
at all clear what benefits your proposal is giving that targeted fault
notification will not achieve just as well.
BTW - we have done extensive testing of restoration schemes using signalling
with crankback and simple routing (plus route pruning) processes.....and it
works great.
 
regards, Neil
 
 -----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 September 2003 23:12
To: [email-masked]
Subject: re: Comparison of restoration requirements between transport and
packet networks

Hi Neil,

Thanks for the email. I'd like to ask you to expand a bit on your idea on
the mailing list. I'm afraid I'm a bit confused about the question and need
more information.

Do you mean by your question:

-          How do we figure out what the defect is and where it happened? Is
it a fiber cut? Is it a misconfiguration? How do you do fault localization

Or:

-          What set of defects does your solution address?

Or maybe something else.

Thanks,

Richard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2003 1:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comparison of restoration requirements between transport and
packet networks

Where are the defects specified (take any networking mode/layer you like)
wrt entry/exit criteria and consequent actions?

regards, Neil

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 September 2003 20:11
To: [email-masked]; Zafar Ali
Cc: Vishal Sharma; 'Richard Rabbat'
Subject: Comparison of restoration requirements between transport and packet
networks

Hi Zafar, CCAMP,

 

During discussions with several colleagues within the CCAMP WG, it has
become clear that it would be useful to clarify some of the fundamental
differences between restoration in packet networks and that in transport
networks.

This is because this difference, together with the time criticality of
restoration at the transport layer, requires the development of techniques
for time-bounded notification. It would then be useful to discuss the
solutions proposed in draft-rabbat-fault-notification-protocol-03 for such
notification.

We are in the process of preparing a contribution on this subject, but
thought it would be useful to highlight a few key points on the mailing
list, so that we can elicit feedback and comments from the WG.

In normal packet networks (MPLS networks) one can pre-signal *and*
pre-configure a backup LSP for a working LSP. This is because selecting a
label at a node for a backup LSP is sufficient to be able to switch traffic
for that LSP when that traffic arrives. If resources are required for the
backup LSP (buffers and bandwidth), they too can be reserved in advance
(during the LSP signaling phase), but can still be used by low-priority or
extra-traffic LSPs as long as there is no failure on the working LSP.

This is true even for shared mesh restoration in MPLS networks. In that
case, multiple labels would be assigned, one for each of the backup LSPs
(corresponding to link and/or node disjoint working LSPs) transiting a node
on the shared backup path, but only one set of resources (buffers,
bandwidth) would be reserved (if such resource reservation was needed).

In transport networks, however, one can pre-signal but not pre-configure a
backup LSP (unless one was doing just 1+1 protection). This is because, in
transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP. 

For this reason, to implement shared restoration schemes in transport
networks (and allow extra-traffic) a backup LSP cannot be cross-connected
until *after* the specific failure for which this backup LSP was
pre-signaled has occured.

Now, if signaling-based notification is used in transport networks, an
*additional phase of signaling* is required along the backup path to enable
nodes along that path to reconfigure themselves (this is well-described in
the functional specification document

of the P&R Design Team). This lengthens the time to recover from the
failure. Depending on the layer at which recovery is being performed this
may or may not be acceptable.

In the specific case of transport networks, restoration is typically a
time-critical activity, so this round-trip signaling delay could be
unacceptable when time-bounded notification and recovery is desired.

In addition, signaling individual LSPs or individual LSP bundles may create
buffering problems that makes signaling time unbounded.

If instead, the information about a failure is flooded to all the network
nodes, and the backup paths are selected intelligently (as described in
draft-rabbat-fault-notification-protocol-03.txt), this additional signaling
hand-shake delay can be eliminated.  This is because by flooding the
information about a fault on a working LSP, one can inform, in parallel, all
the nodes lying along the path of the backup LSP. Thus, the repair point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup path(s)
will have reconfigured themselves.

We would also like to get feedback on a suitable protocol that could
implement time-critical flooding notification.

Comments, thoughts and questions are welcome!

--

Richard Rabbat, Ph.D.

Member of Research Staff, Fujitsu Labs of America

1240 E Arques Ave, MS 345, Sunnyvale, CA 94085

Phone: 408-530-4537. Fax: 408-530-4581. Cell: 650-714-7618

------_=_NextPart_001_01C3785D.155B6D9B
Content-Type: text/html;
	charset="ISO-8859-1"

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

<META content="MSHTML 5.00.3013.2600" name=GENERATOR>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:windowtext;}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=EN-US link=blue vLink=purple>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>Richard,</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>In section 1 of your paper it says:</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>"This document presents a fault notification protocol 
that is both&nbsp;technology and topology agnostic, and applies to 
intra-domain&nbsp; protection.&nbsp;"</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>That being the case, wherever it is to be used one 
needs all the defects defining.&nbsp; Defects should be detected in the 
data-plane (and not by control-plane proxy) at the trail termination point using 
the OAM functions appropriate to the mode/technology, ie cnls is different to 
co-ps is different to co-cs.&nbsp; If one wants to go 'fast' (and I seriously 
question the sanity of those seeking to beat 50ms in SDH at higher layer 
networks) then only certain defects and technologies are relevant.&nbsp; 
Further, one should take care not to invoke protection/restoration for error 
events which self-clear.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>Some technologies are poorly specified wrt 
defects.&nbsp; I therefore don't believe your proposals are truly 
mode/technology generic as claimed.&nbsp; That was really the only point I was 
trying to make.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>But here are a few further remarks on you paper if you 
are interested.........</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>I personally don't like the sound of the proposals as 
its a complexity that I don't think is necessary.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>{Aside -&nbsp; One of the major problems we operators 
face is the cost of complexity.&nbsp; Quite a lot of the stuff I am seeing are 
complexities aimed at BW squeezing.......which IMO have only a 2nd/3rd order 
potential benefit at the expense of 1st order complexity capex/opex costs.&nbsp; 
Well, BW may have been the right metric to conserve 10+ years ago but its not 
true today (in most cases).&nbsp; I am not pointing the finger specifically at 
your work here, but things like 'faster, faster, faster' restoration in all 
layers, having lots of QoS/traffic classes *per* network mode, and stuff like 
multiple class pre-emption/bumping are all examples of complexities whose costs 
outweigh their benefits IMO.&nbsp; We should use BW wisely to reduce 
complexity.&nbsp; This is a major focus point of the future network architecture 
views we are generating in BT, and at this point I don't really want to go any 
further on this issue on the lists.}</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>A trail termination point is the only place defects can 
be detected in co-ps/cs modes.&nbsp; So the entity that you describe as 'per 
failure' vs 'per LSP' in section 4 is not strictly correct.&nbsp; I think what 
you really mean is the single failure of a trail in some server layer network 
generating multiple failures in all the client layer network trails it 
supports.&nbsp; This is a *recursive* behaviour.......and if you drew out the 
G.805 functional architecture I think you would quickly realise this and, in 
particular, that its the optical trail where your focus seems to lie (which I 
can understand), which creates a link-connection in the immediately above layer 
network).</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>Given a trail termination point is the only place 
defects can be detected, it is vital that one consequent action of defect 
detection at this point is the generation of a Forward Defect Indication 
(FDI)......sometime known as AIS.&nbsp; The whole purpose of this signal is to 
tell all the higher layer client networks (at *their* trail termination points) 
not to raise alarms....else this will casue major problems/opex-costs chasing 
faults in the wrong layer/place (this can be across different operators in 
different countries so its a pretty serious issue).&nbsp; This itself is a 
'flooding' behaviour but it is constrained flooding only to the affected 
clients.....and not the rest of the server (or client) layer network(s) who 
don't really need to know about this.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>In the case of a fibre-cut then FDI would go in both 
directions.&nbsp; By definition this must be the fastest form of signalling to 
inform the nodes at either end of the affected trail(s).&nbsp; In the case of 
uni-directional failures then FDI would go forwards and one would have to either 
use the BDI or some dedicated backwards signalling to inform the head 
end.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>So given we *must* have FDI for client layer alarm 
suppression then I am not at all clear what benefits your proposal is giving 
that targeted fault notification will not achieve just as 
well.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>BTW - we have done extensive testing of restoration 
schemes using signalling with crankback and simple routing (plus route pruning) 
processes.....and it works great.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003>regards, Neil</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=340413507-11092003></SPAN></FONT><FONT face=Tahoma><FONT size=2><SPAN 
class=340413507-11092003>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Richard Rabbat [mailto:[email-masked]]<BR><B>Sent:</B> 10 September 2003 
23:12<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> re: Comparison of 
restoration requirements between transport and packet 
networks<BR><BR></DIV></FONT>
<BLOCKQUOTE 
style="BORDER-LEFT: #800000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT>
  <DIV class=Section1>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Hi 
  Neil,</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Thanks for the email. 
  I&#8217;d like to ask you to expand a bit on your idea on the mailing list. I&#8217;m 
  afraid I&#8217;m a bit confused about the question and need more 
  information.</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Do you mean by your 
  question:</SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in"><FONT 
  color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">-</SPAN></FONT><FONT 
  color=navy size=1><SPAN 
  style="COLOR: navy; FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></FONT><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">How do we figure out 
  what the defect is and where it happened? Is it a fiber cut? Is it a 
  misconfiguration? How do you do fault localization</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Or:</SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in"><FONT 
  color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">-</SPAN></FONT><FONT 
  color=navy size=1><SPAN 
  style="COLOR: navy; FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></FONT><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">What set of defects 
  does your solution address?</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Or maybe something 
  else.</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Thanks,</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">Richard.</SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy face=Arial size=2><SPAN 
  style="COLOR: navy; FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <DIV 
  style="BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; BORDER-RIGHT: medium none; BORDER-TOP: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; PADDING-TOP: 0in">
  <P class=MsoNormal><FONT face=Tahoma size=2><SPAN 
  style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">-----Original 
  Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> 
  [email-masked] [mailto:[email-masked]] <BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> </SPAN></FONT><FONT face=Tahoma 
  size=2><SPAN style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">Wednesday, September 
  10, 2003</SPAN></FONT><FONT face=Tahoma size=2><SPAN 
  style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"> </SPAN></FONT><FONT face=Tahoma 
  size=2><SPAN style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">1:13 
  PM</SPAN></FONT><FONT face=Tahoma size=2><SPAN 
  style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"><BR><B><SPAN 
  style="FONT-WEIGHT: bold">To:</SPAN></B> [email-masked]; 
  [email-masked]; [email-masked]<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Cc:</SPAN></B> [email-masked]<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Comparison of restoration 
  requirements between transport and packet networks</SPAN></FONT></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P>
  <DIV>
  <P class=MsoNormal><FONT color=maroon face="Comic Sans MS" size=2><SPAN 
  style="COLOR: maroon; FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 10pt">Where are 
  the defects specified (take any networking mode/layer you like) wrt entry/exit 
  criteria and consequent actions?</SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT color=maroon face="Comic Sans MS" size=2><SPAN 
  style="COLOR: maroon; FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 10pt">regards, 
  Neil</SPAN></FONT></P></DIV>
  <BLOCKQUOTE 
  style="BORDER-BOTTOM: medium none; BORDER-LEFT: maroon 1.5pt solid; BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN: 5pt 0in 5pt 3.75pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; PADDING-TOP: 0in">
    <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><FONT face=Tahoma 
    size=2><SPAN style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">-----Original 
    Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Richard 
    Rabbat [mailto:[email-masked]]<BR><B><SPAN 
    style="FONT-WEIGHT: bold">Sent:</SPAN></B> </SPAN></FONT><FONT face=Tahoma 
    size=2><SPAN style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">10 September 
    2003</SPAN></FONT><FONT face=Tahoma size=2><SPAN 
    style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"> </SPAN></FONT><FONT 
    face=Tahoma size=2><SPAN 
    style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt">20:11</SPAN></FONT><FONT 
    face=Tahoma size=2><SPAN 
    style="FONT-FAMILY: Tahoma; FONT-SIZE: 10pt"><BR><B><SPAN 
    style="FONT-WEIGHT: bold">To:</SPAN></B> [email-masked]; Zafar 
    Ali<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> Vishal Sharma; 
    'Richard Rabbat'<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
    Comparison of restoration requirements between transport and packet 
    networks</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Hi Zafar, 
    CCAMP,</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">During discussions with several 
    colleagues within the CCAMP WG, it has become clear that it would be useful 
    to clarify some of the fundamental differences between restoration in packet 
    networks and that in transport networks.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">This is because this difference, 
    together with the time criticality of restoration at the transport layer, 
    requires the development of techniques for time-bounded notification. It 
    would then be useful to discuss the solutions proposed in 
    draft-rabbat-fault-notification-protocol-03 for such 
    notification.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">We are in the process of 
    preparing a contribution on this subject, but thought it would be useful to 
    highlight a few key points on the mailing list, so that we can elicit 
    feedback and comments from the WG.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In normal packet networks (MPLS 
    networks) one can pre-signal *and* pre-configure a backup LSP for a working 
    LSP. This is because selecting a label at a node for a backup LSP is 
    sufficient to be able to switch traffic for that LSP when that traffic 
    arrives. If resources are required for the backup LSP (buffers and 
    bandwidth), they too can be reserved in advance (during the LSP signaling 
    phase), but can still be used by low-priority or extra-traffic LSPs as long 
    as there is no failure on the working LSP.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">This is true even for shared 
    mesh restoration in MPLS networks. In that case, multiple labels would be 
    assigned, one for each of the backup LSPs (corresponding to link and/or node 
    disjoint working LSPs) transiting a node on the shared backup path, but only 
    one set of resources (buffers, bandwidth) would be reserved (if such 
    resource reservation was needed).</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In transport networks, however, 
    one can pre-signal but not pre-configure a backup LSP (unless one was doing 
    just 1+1 protection). This is because, in transport networks, if an LSP is 
    established (that is, it is cross-connected) then the full bandwidth of the 
    LSP is automatically *consumed*, irrespective of whether traffic actually 
    flows on this LSP. </SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">For this reason, to implement 
    shared restoration schemes in transport networks (and allow extra-traffic) a 
    backup LSP cannot be cross-connected until *after* the specific failure for 
    which this backup LSP was pre-signaled has occured.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Now, if signaling-based 
    notification is used in transport networks, an *additional phase of 
    signaling* is required along the backup path to enable nodes along that path 
    to reconfigure themselves (this is well-described in the functional 
    specification document</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">of the P&amp;R Design Team). 
    This lengthens the time to recover from the failure. Depending on the layer 
    at which recovery is being performed this may or may not be 
    acceptable.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In the specific case of 
    transport networks, restoration is typically a time-critical activity, so 
    this round-trip signaling delay could be unacceptable when time-bounded 
    notification and recovery is desired.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In addition, signaling 
    individual LSPs or individual LSP bundles may create buffering problems that 
    makes signaling time unbounded.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">If instead, the information 
    about a failure is flooded to all the network nodes, and the backup paths 
    are selected intelligently (as described in 
    draft-rabbat-fault-notification-protocol-03.txt), this additional signaling 
    hand-shake delay can be eliminated.&nbsp; This is because by flooding the 
    information about a fault on a working LSP, one can inform, in parallel, all 
    the nodes lying along the path of the backup LSP. Thus, the repair point(s) 
    upon learning of the fault holds off activating the backup LSP(s) for an 
    appropriate time in which all nodes along the corresponding backup path(s) 
    will have reconfigured themselves.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">We would also like to get 
    feedback on a suitable protocol that could implement time-critical flooding 
    notification.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Comments, thoughts and questions 
    are welcome!</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">--</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Richard Rabbat, 
    Ph.D.</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Member of Research Staff, 
    Fujitsu Labs of </SPAN></FONT><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">America</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN lang=FR 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">1240 E Arques Ave, MS 345, 
    Sunnyvale, CA 94085</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Phone: 408-530-4537. Fax: 
    408-530-4581. Cell: 650-714-7618</SPAN></FONT></P>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3785D.155B6D9B--

Delivery-date: Wed, 10 Sep 2003 22:16:48 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: re: Comparison of restoration requirements between transport and packet networks
Date: Wed, 10 Sep 2003 15:11:49 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01C377AD.DBBA40D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Neil,

=20

Thanks for the email. I'd like to ask you to expand a bit on your idea =
on
the mailing list. I'm afraid I'm a bit confused about the question and =
need
more information.

=20

Do you mean by your question:

-          How do we figure out what the defect is and where it =
happened? Is
it a fiber cut? Is it a misconfiguration? How do you do fault =
localization

Or:

-          What set of defects does your solution address?

Or maybe something else.

Thanks,

Richard.

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Wednesday, September 10, 2003 1:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comparison of restoration requirements between transport =
and
packet networks

=20

Where are the defects specified (take any networking mode/layer you =
like)
wrt entry/exit criteria and consequent actions?

=20

regards, Neil

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 September 2003 20:11
To: [email-masked]; Zafar Ali
Cc: Vishal Sharma; 'Richard Rabbat'
Subject: Comparison of restoration requirements between transport and =
packet
networks

Hi Zafar, CCAMP,

=20

=20

During discussions with several colleagues within the CCAMP WG, it has
become clear that it would be useful to clarify some of the fundamental
differences between restoration in packet networks and that in transport
networks.

This is because this difference, together with the time criticality of
restoration at the transport layer, requires the development of =
techniques
for time-bounded notification. It would then be useful to discuss the
solutions proposed in draft-rabbat-fault-notification-protocol-03 for =
such
notification.

=20

We are in the process of preparing a contribution on this subject, but
thought it would be useful to highlight a few key points on the mailing
list, so that we can elicit feedback and comments from the WG.

=20

In normal packet networks (MPLS networks) one can pre-signal *and*
pre-configure a backup LSP for a working LSP. This is because selecting =
a
label at a node for a backup LSP is sufficient to be able to switch =
traffic
for that LSP when that traffic arrives. If resources are required for =
the
backup LSP (buffers and bandwidth), they too can be reserved in advance
(during the LSP signaling phase), but can still be used by low-priority =
or
extra-traffic LSPs as long as there is no failure on the working LSP.

=20

This is true even for shared mesh restoration in MPLS networks. In that
case, multiple labels would be assigned, one for each of the backup LSPs
(corresponding to link and/or node disjoint working LSPs) transiting a =
node
on the shared backup path, but only one set of resources (buffers,
bandwidth) would be reserved (if such resource reservation was needed).

=20

In transport networks, however, one can pre-signal but not pre-configure =
a
backup LSP (unless one was doing just 1+1 protection). This is because, =
in
transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP.=20

=20

For this reason, to implement shared restoration schemes in transport
networks (and allow extra-traffic) a backup LSP cannot be =
cross-connected
until *after* the specific failure for which this backup LSP was
pre-signaled has occured.

=20

Now, if signaling-based notification is used in transport networks, an
*additional phase of signaling* is required along the backup path to =
enable
nodes along that path to reconfigure themselves (this is well-described =
in
the functional specification document

of the P&R Design Team). This lengthens the time to recover from the
failure. Depending on the layer at which recovery is being performed =
this
may or may not be acceptable.

=20

In the specific case of transport networks, restoration is typically a
time-critical activity, so this round-trip signaling delay could be
unacceptable when time-bounded notification and recovery is desired.

In addition, signaling individual LSPs or individual LSP bundles may =
create
buffering problems that makes signaling time unbounded.

=20

If instead, the information about a failure is flooded to all the =
network
nodes, and the backup paths are selected intelligently (as described in
draft-rabbat-fault-notification-protocol-03.txt), this additional =
signaling
hand-shake delay can be eliminated.  This is because by flooding the
information about a fault on a working LSP, one can inform, in parallel, =
all
the nodes lying along the path of the backup LSP. Thus, the repair =
point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup =
path(s)
will have reconfigured themselves.

=20

We would also like to get feedback on a suitable protocol that could
implement time-critical flooding notification.

=20

Comments, thoughts and questions are welcome!

=20

--

Richard Rabbat, Ph.D.

Member of Research Staff, Fujitsu Labs of America

1240 E Arques Ave, MS 345, Sunnyvale, CA 94085

Phone: 408-530-4537. Fax: 408-530-4581. Cell: 650-714-7618

=20

------=_NextPart_000_008A_01C377AD.DBBA40D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:windowtext;}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Neil,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for the email. I&#8217;d =
like to
ask you to expand a bit on your idea on the mailing list. I&#8217;m =
afraid
I&#8217;m a bit confused about the question and need more =
information.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Do you mean by your =
question:</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>How do we figure out what the defect is and where it =
happened? Is
it a fiber cut? Is it a misconfiguration? How do you do fault =
localization</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Or:</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span =
style=3D'font-size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>What set of defects does your solution =
address?</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Or maybe something =
else.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Richard.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Wednesday,
 September 10, 2003</span></font><font size=3D2 face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><font
 size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>1:13 PM</span></font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked];
[email-masked]; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comparison =
of
restoration requirements between transport and packet =
networks</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>Where are the
defects specified (take any networking mode/layer you like) wrt =
entry/exit
criteria and consequent actions?</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>regards, Neil</span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid maroon =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Richard Rabbat =
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>10 September
 2003</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=3D2 face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>20:11</span></font><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]; =
Zafar Ali<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Vishal Sharma; =
'Richard
Rabbat'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comparison of =
restoration
requirements between transport and packet networks</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi Zafar, CCAMP,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>During discussions with several colleagues within the =
CCAMP
WG, it has become clear that it would be useful to clarify some of the
fundamental differences between restoration in packet networks and that =
in
transport networks.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is because this difference, together with the =
time
criticality of restoration at the transport layer, requires the =
development of
techniques for time-bounded notification. It would then be useful to =
discuss
the solutions proposed in draft-rabbat-fault-notification-protocol-03 =
for such
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We are in the process of preparing a contribution on =
this
subject, but thought it would be useful to highlight a few key points on =
the
mailing list, so that we can elicit feedback and comments from the =
WG.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In normal packet networks (MPLS networks) one can =
pre-signal
*and* pre-configure a backup LSP for a working LSP. This is because =
selecting a
label at a node for a backup LSP is sufficient to be able to switch =
traffic for
that LSP when that traffic arrives. If resources are required for the =
backup LSP
(buffers and bandwidth), they too can be reserved in advance (during the =
LSP
signaling phase), but can still be used by low-priority or extra-traffic =
LSPs
as long as there is no failure on the working LSP.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is true even for shared mesh restoration in MPLS
networks. In that case, multiple labels would be assigned, one for each =
of the
backup LSPs (corresponding to link and/or node disjoint working LSPs)
transiting a node on the shared backup path, but only one set of =
resources
(buffers, bandwidth) would be reserved (if such resource reservation was
needed).</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In transport networks, however, one can pre-signal =
but not
pre-configure a backup LSP (unless one was doing just 1+1 protection). =
This is
because, in transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP. =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For this reason, to implement shared restoration =
schemes in transport
networks (and allow extra-traffic) a backup LSP cannot be =
cross-connected until
*after* the specific failure for which this backup LSP was pre-signaled =
has
occured.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Now, if signaling-based notification is used in =
transport
networks, an *additional phase of signaling* is required along the =
backup path
to enable nodes along that path to reconfigure themselves (this is
well-described in the functional specification =
document</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>of the P&amp;R Design Team). This lengthens the time =
to
recover from the failure. Depending on the layer at which recovery is =
being
performed this may or may not be acceptable.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the specific case of transport networks, =
restoration is
typically a time-critical activity, so this round-trip signaling delay =
could be
unacceptable when time-bounded notification and recovery is =
desired.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In addition, signaling individual LSPs or individual =
LSP
bundles may create buffering problems that makes signaling time =
unbounded.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If instead, the information about a failure is =
flooded to
all the network nodes, and the backup paths are selected intelligently =
(as
described in draft-rabbat-fault-notification-protocol-03.txt), this =
additional
signaling hand-shake delay can be eliminated.&nbsp; This is because by =
flooding
the information about a fault on a working LSP, one can inform, in =
parallel,
all the nodes lying along the path of the backup LSP. Thus, the repair =
point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup =
path(s) will
have reconfigured themselves.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We would also like to get feedback on a suitable =
protocol
that could implement time-critical flooding =
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Comments, thoughts and questions are =
welcome!</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Richard Rabbat, Ph.D.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Member of Research Staff, Fujitsu Labs of =
</span></font><font
  size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>America</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DFR =
style=3D'font-size:10.0pt;
font-family:Arial'>1240 E Arques Ave, MS 345, Sunnyvale, CA =
94085</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Phone: 408-530-4537. Fax: 408-530-4581. Cell: =
650-714-7618</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_008A_01C377AD.DBBA40D0--

Delivery-date: Wed, 10 Sep 2003 20:17:07 +0000
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Comparison of restoration requirements between transport and  packet networks
Date: Wed, 10 Sep 2003 21:12:42 +0100

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

------_=_NextPart_001_01C377D7.E296674C
Content-Type: text/plain;
	charset="ISO-8859-1"

Where are the defects specified (take any networking mode/layer you like)
wrt entry/exit criteria and consequent actions?
 
regards, Neil

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 September 2003 20:11
To: [email-masked]; Zafar Ali
Cc: Vishal Sharma; 'Richard Rabbat'
Subject: Comparison of restoration requirements between transport and packet
networks

Hi Zafar, CCAMP,

 

During discussions with several colleagues within the CCAMP WG, it has
become clear that it would be useful to clarify some of the fundamental
differences between restoration in packet networks and that in transport
networks.

This is because this difference, together with the time criticality of
restoration at the transport layer, requires the development of techniques
for time-bounded notification. It would then be useful to discuss the
solutions proposed in draft-rabbat-fault-notification-protocol-03 for such
notification.

We are in the process of preparing a contribution on this subject, but
thought it would be useful to highlight a few key points on the mailing
list, so that we can elicit feedback and comments from the WG.

In normal packet networks (MPLS networks) one can pre-signal *and*
pre-configure a backup LSP for a working LSP. This is because selecting a
label at a node for a backup LSP is sufficient to be able to switch traffic
for that LSP when that traffic arrives. If resources are required for the
backup LSP (buffers and bandwidth), they too can be reserved in advance
(during the LSP signaling phase), but can still be used by low-priority or
extra-traffic LSPs as long as there is no failure on the working LSP.

This is true even for shared mesh restoration in MPLS networks. In that
case, multiple labels would be assigned, one for each of the backup LSPs
(corresponding to link and/or node disjoint working LSPs) transiting a node
on the shared backup path, but only one set of resources (buffers,
bandwidth) would be reserved (if such resource reservation was needed).

In transport networks, however, one can pre-signal but not pre-configure a
backup LSP (unless one was doing just 1+1 protection). This is because, in
transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP. 

For this reason, to implement shared restoration schemes in transport
networks (and allow extra-traffic) a backup LSP cannot be cross-connected
until *after* the specific failure for which this backup LSP was
pre-signaled has occured.

Now, if signaling-based notification is used in transport networks, an
*additional phase of signaling* is required along the backup path to enable
nodes along that path to reconfigure themselves (this is well-described in
the functional specification document

of the P&R Design Team). This lengthens the time to recover from the
failure. Depending on the layer at which recovery is being performed this
may or may not be acceptable.

In the specific case of transport networks, restoration is typically a
time-critical activity, so this round-trip signaling delay could be
unacceptable when time-bounded notification and recovery is desired.

In addition, signaling individual LSPs or individual LSP bundles may create
buffering problems that makes signaling time unbounded.

If instead, the information about a failure is flooded to all the network
nodes, and the backup paths are selected intelligently (as described in
draft-rabbat-fault-notification-protocol-03.txt), this additional signaling
hand-shake delay can be eliminated.  This is because by flooding the
information about a fault on a working LSP, one can inform, in parallel, all
the nodes lying along the path of the backup LSP. Thus, the repair point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup path(s)
will have reconfigured themselves.

We would also like to get feedback on a suitable protocol that could
implement time-critical flooding notification.

Comments, thoughts and questions are welcome!

--

Richard Rabbat, Ph.D.

Member of Research Staff, Fujitsu Labs of America

1240 E Arques Ave, MS 345, Sunnyvale, CA 94085

Phone: 408-530-4537. Fax: 408-530-4581. Cell: 650-714-7618

------_=_NextPart_001_01C377D7.E296674C
Content-Type: text/html;
	charset="ISO-8859-1"

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

<META content="MSHTML 5.00.3013.2600" name=GENERATOR>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=EN-US link=blue vLink=purple>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=790510520-10092003>Where are the defects specified (take any networking 
mode/layer you like) wrt entry/exit criteria and consequent 
actions?</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=790510520-10092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=790510520-10092003>regards, Neil</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #800000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Richard Rabbat 
  [mailto:[email-masked]]<BR><B>Sent:</B> 10 September 2003 
  20:11<BR><B>To:</B> [email-masked]; Zafar Ali<BR><B>Cc:</B> Vishal Sharma; 
  'Richard Rabbat'<BR><B>Subject:</B> Comparison of restoration requirements 
  between transport and packet networks<BR><BR></DIV></FONT>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Hi Zafar, CCAMP,</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">During discussions with several 
  colleagues within the CCAMP WG, it has become clear that it would be useful to 
  clarify some of the fundamental differences between restoration in packet 
  networks and that in transport networks.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">This is because this difference, 
  together with the time criticality of restoration at the transport layer, 
  requires the development of techniques for time-bounded notification. It would 
  then be useful to discuss the solutions proposed in 
  draft-rabbat-fault-notification-protocol-03 for such 
  notification.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">We are in the process of preparing 
  a contribution on this subject, but thought it would be useful to highlight a 
  few key points on the mailing list, so that we can elicit feedback and 
  comments from the WG.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In normal packet networks (MPLS 
  networks) one can pre-signal *and* pre-configure a backup LSP for a working 
  LSP. This is because selecting a label at a node for a backup LSP is 
  sufficient to be able to switch traffic for that LSP when that traffic 
  arrives. If resources are required for the backup LSP (buffers and bandwidth), 
  they too can be reserved in advance (during the LSP signaling phase), but can 
  still be used by low-priority or extra-traffic LSPs as long as there is no 
  failure on the working LSP.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">This is true even for shared mesh 
  restoration in MPLS networks. In that case, multiple labels would be assigned, 
  one for each of the backup LSPs (corresponding to link and/or node disjoint 
  working LSPs) transiting a node on the shared backup path, but only one set of 
  resources (buffers, bandwidth) would be reserved (if such resource reservation 
  was needed).</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In transport networks, however, 
  one can pre-signal but not pre-configure a backup LSP (unless one was doing 
  just 1+1 protection). This is because, in transport networks, if an LSP is 
  established (that is, it is cross-connected) then the full bandwidth of the 
  LSP is automatically *consumed*, irrespective of whether traffic actually 
  flows on this LSP. </SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">For this reason, to implement 
  shared restoration schemes in transport networks (and allow extra-traffic) a 
  backup LSP cannot be cross-connected until *after* the specific failure for 
  which this backup LSP was pre-signaled has occured.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Now, if signaling-based 
  notification is used in transport networks, an *additional phase of signaling* 
  is required along the backup path to enable nodes along that path to 
  reconfigure themselves (this is well-described in the functional specification 
  document</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">of the P&amp;R Design Team). This 
  lengthens the time to recover from the failure. Depending on the layer at 
  which recovery is being performed this may or may not be 
  acceptable.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In the specific case of transport 
  networks, restoration is typically a time-critical activity, so this 
  round-trip signaling delay could be unacceptable when time-bounded 
  notification and recovery is desired.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">In addition, signaling individual 
  LSPs or individual LSP bundles may create buffering problems that makes 
  signaling time unbounded.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">If instead, the information about 
  a failure is flooded to all the network nodes, and the backup paths are 
  selected intelligently (as described in 
  draft-rabbat-fault-notification-protocol-03.txt), this additional signaling 
  hand-shake delay can be eliminated.&nbsp; This is because by flooding the 
  information about a fault on a working LSP, one can inform, in parallel, all 
  the nodes lying along the path of the backup LSP. Thus, the repair point(s) 
  upon learning of the fault holds off activating the backup LSP(s) for an 
  appropriate time in which all nodes along the corresponding backup path(s) 
  will have reconfigured themselves.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">We would also like to get feedback 
  on a suitable protocol that could implement time-critical flooding 
  notification.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Comments, thoughts and questions 
  are welcome!</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">&nbsp;</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">--</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Richard Rabbat</SPAN></FONT><FONT 
  face=Arial size=2><SPAN style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">, 
  Ph.D.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Member of Research Staff, Fujitsu 
  Labs of </SPAN></FONT><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">America</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN lang=FR 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">1240 E Arques Ave, MS 345, 
  Sunnyvale, CA 94085</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Phone: 408-530-4537. Fax: 
  408-530-4581. Cell: 650-714-7618</SPAN></FONT></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;</SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C377D7.E296674C--

Delivery-date: Wed, 10 Sep 2003 19:17:49 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>, "Zafar Ali" <[email-masked]>
Cc: "Vishal Sharma" <[email-masked]>, "'Richard Rabbat'" <[email-masked]>
Subject: Comparison of restoration requirements between transport and packet networks
Date: Wed, 10 Sep 2003 12:11:02 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C37794.9B2EB320
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Zafar, CCAMP,

=20

=20

During discussions with several colleagues within the CCAMP WG, it has
become clear that it would be useful to clarify some of the fundamental
differences between restoration in packet networks and that in transport
networks.

This is because this difference, together with the time criticality of
restoration at the transport layer, requires the development of =
techniques
for time-bounded notification. It would then be useful to discuss the
solutions proposed in draft-rabbat-fault-notification-protocol-03 for =
such
notification.

=20

We are in the process of preparing a contribution on this subject, but
thought it would be useful to highlight a few key points on the mailing
list, so that we can elicit feedback and comments from the WG.

=20

In normal packet networks (MPLS networks) one can pre-signal *and*
pre-configure a backup LSP for a working LSP. This is because selecting =
a
label at a node for a backup LSP is sufficient to be able to switch =
traffic
for that LSP when that traffic arrives. If resources are required for =
the
backup LSP (buffers and bandwidth), they too can be reserved in advance
(during the LSP signaling phase), but can still be used by low-priority =
or
extra-traffic LSPs as long as there is no failure on the working LSP.

=20

This is true even for shared mesh restoration in MPLS networks. In that
case, multiple labels would be assigned, one for each of the backup LSPs
(corresponding to link and/or node disjoint working LSPs) transiting a =
node
on the shared backup path, but only one set of resources (buffers,
bandwidth) would be reserved (if such resource reservation was needed).

=20

In transport networks, however, one can pre-signal but not pre-configure =
a
backup LSP (unless one was doing just 1+1 protection). This is because, =
in
transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP.=20

=20

For this reason, to implement shared restoration schemes in transport
networks (and allow extra-traffic) a backup LSP cannot be =
cross-connected
until *after* the specific failure for which this backup LSP was
pre-signaled has occured.

=20

Now, if signaling-based notification is used in transport networks, an
*additional phase of signaling* is required along the backup path to =
enable
nodes along that path to reconfigure themselves (this is well-described =
in
the functional specification document

of the P&R Design Team). This lengthens the time to recover from the
failure. Depending on the layer at which recovery is being performed =
this
may or may not be acceptable.

=20

In the specific case of transport networks, restoration is typically a
time-critical activity, so this round-trip signaling delay could be
unacceptable when time-bounded notification and recovery is desired.

In addition, signaling individual LSPs or individual LSP bundles may =
create
buffering problems that makes signaling time unbounded.

=20

If instead, the information about a failure is flooded to all the =
network
nodes, and the backup paths are selected intelligently (as described in
draft-rabbat-fault-notification-protocol-03.txt), this additional =
signaling
hand-shake delay can be eliminated.  This is because by flooding the
information about a fault on a working LSP, one can inform, in parallel, =
all
the nodes lying along the path of the backup LSP. Thus, the repair =
point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup =
path(s)
will have reconfigured themselves.

=20

We would also like to get feedback on a suitable protocol that could
implement time-critical flooding notification.

=20

Comments, thoughts and questions are welcome!

=20

--

Richard Rabbat, Ph.D.

Member of Research Staff, Fujitsu Labs of America

1240 E Arques Ave, MS 345, Sunnyvale, CA 94085

Phone: 408-530-4537. Fax: 408-530-4581. Cell: 650-714-7618

=20

------=_NextPart_000_0024_01C37794.9B2EB320
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi Zafar, CCAMP,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>During discussions with several colleagues within the =
CCAMP
WG, it has become clear that it would be useful to clarify some of the
fundamental differences between restoration in packet networks and that =
in
transport networks.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is because this difference, together with the =
time
criticality of restoration at the transport layer, requires the =
development of
techniques for time-bounded notification. It would then be useful to =
discuss
the solutions proposed in draft-rabbat-fault-notification-protocol-03 =
for such
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We are in the process of preparing a contribution on =
this
subject, but thought it would be useful to highlight a few key points on =
the
mailing list, so that we can elicit feedback and comments from the =
WG.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In normal packet networks (MPLS networks) one can =
pre-signal
*and* pre-configure a backup LSP for a working LSP. This is because =
selecting a
label at a node for a backup LSP is sufficient to be able to switch =
traffic for
that LSP when that traffic arrives. If resources are required for the =
backup
LSP (buffers and bandwidth), they too can be reserved in advance (during =
the
LSP signaling phase), but can still be used by low-priority or =
extra-traffic LSPs
as long as there is no failure on the working LSP.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is true even for shared mesh restoration in MPLS
networks. In that case, multiple labels would be assigned, one for each =
of the
backup LSPs (corresponding to link and/or node disjoint working LSPs)
transiting a node on the shared backup path, but only one set of =
resources
(buffers, bandwidth) would be reserved (if such resource reservation was
needed).</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In transport networks, however, one can pre-signal =
but not
pre-configure a backup LSP (unless one was doing just 1+1 protection). =
This is
because, in transport networks, if an LSP is established (that is, it is
cross-connected) then the full bandwidth of the LSP is automatically
*consumed*, irrespective of whether traffic actually flows on this LSP. =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For this reason, to implement shared restoration =
schemes in
transport networks (and allow extra-traffic) a backup LSP cannot be
cross-connected until *after* the specific failure for which this backup =
LSP
was pre-signaled has occured.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Now, if signaling-based notification is used in =
transport
networks, an *additional phase of signaling* is required along the =
backup path
to enable nodes along that path to reconfigure themselves (this is
well-described in the functional specification =
document</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>of the P&amp;R Design Team). This lengthens the time =
to
recover from the failure. Depending on the layer at which recovery is =
being
performed this may or may not be acceptable.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the specific case of transport networks, =
restoration is
typically a time-critical activity, so this round-trip signaling delay =
could be
unacceptable when time-bounded notification and recovery is =
desired.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In addition, signaling individual LSPs or individual =
LSP
bundles may create buffering problems that makes signaling time =
unbounded.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If instead, the information about a failure is =
flooded to
all the network nodes, and the backup paths are selected intelligently =
(as
described in draft-rabbat-fault-notification-protocol-03.txt), this =
additional
signaling hand-shake delay can be eliminated.&nbsp; This is because by =
flooding
the information about a fault on a working LSP, one can inform, in =
parallel,
all the nodes lying along the path of the backup LSP. Thus, the repair =
point(s)
upon learning of the fault holds off activating the backup LSP(s) for an
appropriate time in which all nodes along the corresponding backup =
path(s) will
have reconfigured themselves.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We would also like to get feedback on a suitable =
protocol
that could implement time-critical flooding =
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Comments, thoughts and questions are =
welcome!</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
 font-family:Arial'>Richard Rabbat</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>, Ph.D.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Member of Research Staff, Fujitsu Labs of =
</span></font><font
  size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>America</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DFR =
style=3D'font-size:10.0pt;
font-family:Arial'>1240 E Arques Ave, MS 345, Sunnyvale, CA =
94085</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Phone: 408-530-4537. Fax: 408-530-4581. Cell: =
650-714-7618</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0024_01C37794.9B2EB320--

Delivery-date: Tue, 09 Sep 2003 21:55:15 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "zafar ali" <[email-masked]>, "'Richard Rabbat'" <[email-masked]>, <[email-masked]>
Subject: RE: Time-bounded notification
Date: Tue, 9 Sep 2003 14:51:15 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C376E1.D1918540
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

MessageHi Zafar,

Thanks very much for your comments and observations.

It is very helpful to know what was causing the confusion at the last couple
IETF's.
And, your point about splitting up the problem to first explain the need for
a solution and
an approach to it, and then explaining specific details is well taken. (It
does appear that the
FNP solution proposed in draft-rabbat has often been interpreted as being
equivalent to
it's LMP specific implemenation, even though that's not the case. So a
clearer split
of the problem and specifics should help.)

In fact, based on additional off-line feedback and conversations with people
interested
in the problem, we have already been thinking of providing a more detailed
explanation on the list,
and perhaps following that up with an explanatory draft. We think these will
be helpful in
further WG email discussions.

Regards,
-Vishal
  -----Original Message-----
  From: zafar ali [mailto:[email-masked]]
  Sent: Tuesday, September 09, 2003 12:06 PM
  To: 'Richard Rabbat'; [email-masked]
  Cc: 'Vishal Sharma'
  Subject: RE: Time-bounded notification

  Hi Richard,

  Sorry for replying late; Please see comments in-lined.

  Thanks

  Regards... Zafar

  =====================================================================
  Zafar Ali, Ph. D.
100 South Main St. #200,
  Technical Leader,
Ann Arbor, MI 48104, USA.
  Cisco Systems.
(734) 276-2459, [email-masked]
  =====================================================================

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Rabbat
    Sent: Thursday, August 14, 2003 2:09 PM
    To: [email-masked]
    Cc: 'Vishal Sharma'
    Subject: Time-bounded notification

    Hello Everyone,

    Following some discussions prior to Vienna, and feedback and comments
received during Vienna and thereafter, we have realized that perhaps one
aspect of draft-rabbat-fault-notification-protocol-03.txt that we may not
have adequately highlighted is its focus on providing *time-bounded*
notification.

    This is because draft-rabbat focuses on recovery in optical transport
networks, where recovery of failed LSPs (fibers, lambdas, etc.) in a
*bounded time* is critical for the provider to be able to offer
guarantees/SLAs to its transport customers, and also to its L2 and L3
customers. The transport infrastructure often serves as a foundation for the
L2 and L3 networks built upon it, and so should be able to provide recovery
within some well-specified time, so that L2 and L3 recovery can be
appropriately performed based on what L1 provides.

    For this reason, notification via signaling or OSPF-based flooding,
which could work well at the packet layer, may not be directly applicable at
the transport layer.

      I agree with the notion of the time-bounded recovery. However, here
you started to make assumption about possible solutions. The same confusion
arrived at the last IETF meeting when an LMP based solution was presented.
All I am saying is that IMO breaking the problem into two part, I.e.,
getting agreement on the requirements and then following it up with the
solution would be the right approach.

      I agree with the requirement part of the problem statement.

     In fact, since recovery at the packet layer may not involve the
stringent time constraints that are applicable at the transport layer,
directly comparing notification solutions at the packet layer with those at
the transport layer is probably not accurate.

      What would be useful here is to quantify the differences between the
two types of networks. Such quantification will be useful in catalyzing some
email discussions at the mailing list.

    Rather, we need to examine (as done in draft-rabbat) the applicability
of signaling and flooding to notification *at the transport layer* under the
constraint of achieving time-bounded recovery.

       Agreed!

    So if the WG looks at draft-rabbat with this backdrop, we believe some
of the arguments made there will be clearer. Of course, we welcome feedback
from the list.

    Thanks,

    -Richard and Vishal

    PS: The need for time-bounded recovery is not new, and has been
recognized in several recent IETF RFCs. Notably,

    RFC3272

    http://www.ietf.org/rfc/rfc3272.txt

    page 52:

    --

       -  Failure notification throughout the network should be timely and
reliable.

    --

    Note that there is a list of requirements on this page, some of which
are similar to those in draft-rabbat-optical-recovery-reqs-00.txt.

    RFC3386

    http://www.ietf.org/rfc/rfc3386.txt, which is also relevant to the whole
discussion.

    Page 15 discusses the following:

    --

       Proposed timing bounds for different survivability mechanisms are as
follows (all bounds are exclusive of signal propagation):

       1:1 path protection with pre-established capacity:  100-500 ms

       1:1 path protection with pre-planned capacity:      100-750 ms

       Local restoration:                                  50 ms

       Path restoration:                                   1-5 seconds

    --

    Note that RFC3386 discusses horizontal hierarchy in data networks, and
so the bounds above apply primarily to the packet layer. Similar numbers for
the transport layer will likely be significantly stricter (Any operator
inputs on this?).

------=_NextPart_000_000E_01C376E1.D1918540
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Zafar,</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
very much for your comments and observations.</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>It is=20
very helpful to know what was causing the confusion at the last couple=20
IETF's.</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>And,=20
your point about splitting up the problem to first explain the need for =
a=20
solution and</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>an=20
approach to it, and then explaining specific details is well taken. (It =
does=20
appear that the</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>FNP=20
solution proposed in draft-rabbat has often been interpreted as being =
equivalent=20
to</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>it's=20
LMP specific implemenation, even though that's not the case. So a =
clearer=20
split</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>of the=20
problem and specifics should help.)</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
fact, based on&nbsp;additional off-line feedback and conversations=20
with&nbsp;people interested</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>in the=20
problem, we have already been thinking of providing a more detailed =
explanation=20
on the list,</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>and=20
perhaps following that up with an explanatory&nbsp;draft. We think these =
will be=20
helpful in</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2>further WG email discussions.</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D315563621-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2>-Vishal</FONT></SPAN></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> zafar ali=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, September 09, 2003 =
12:06=20
  PM<BR><B>To:</B> 'Richard Rabbat'; [email-masked]<BR><B>Cc:</B> =
'Vishal=20
  Sharma'<BR><B>Subject:</B> RE: Time-bounded =
notification<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D764565018-09092003><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
  Richard, </FONT></SPAN></DIV>
  <DIV><SPAN class=3D764565018-09092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D764565018-09092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Sorry for replying late; Please see comments in-lined.=20
  </FONT></SPAN></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Thanks</FONT></DIV>
  <DIV align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
  <DIV align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2>Regards...=20
  Zafar</FONT></DIV>
  <DIV align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
  <DIV align=3Dleft><FONT face=3DArial color=3D#0000ff=20
  =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Zaf=
ar=20
  Ali, Ph. D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  =
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
  class=3D764565018-09092003>&nbsp;&nbsp;</SPAN>100 South Main St.=20
  #200,<BR>Technical =
Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  =
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</SPAN><SPAN=20
  =
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>Ann Arbor, MI 48104, USA.<BR>Cisco=20
  Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  =
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>(734)=20
  276-2459<SPAN class=3D764565018-09092003>, <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></SPAN><BR>=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
    </B>Richard Rabbat<BR><B>Sent:</B> Thursday, August 14, 2003 2:09=20
    PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> 'Vishal=20
    Sharma'<BR><B>Subject:</B> Time-bounded =
notification<BR><BR></FONT></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hello=20
Everyone,</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Following some =
discussions prior=20
    to Vienna, and feedback and comments received during Vienna and =
thereafter,=20
    we have realized that perhaps one aspect of=20
    draft-rabbat-fault-notification-protocol-03.txt that we may not have =

    adequately highlighted is its focus on providing *<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">time-bounded</SPAN></B>*=20
    notification.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This is because =
draft-rabbat=20
    focuses on recovery in optical transport networks, where recovery of =
failed=20
    LSPs (fibers, lambdas, etc.) in a *<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">bounded time</SPAN></B>* is critical for =
the=20
    provider to be able to offer guarantees/SLAs to its transport =
customers, and=20
    also to its L2 and L3 customers. The transport infrastructure often =
serves=20
    as a foundation for the L2 and L3 networks built upon it, and so =
should be=20
    able to provide recovery within some well-specified time, so that L2 =
and L3=20
    recovery can be appropriately performed based on what L1=20
    provides.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">For=20
    this reason, notification via signaling or OSPF-based flooding, =
which could=20
    work well at the packet layer, may not be directly applicable at the =

    transport layer.&nbsp;<SPAN class=3D764565018-09092003><FONT=20
    color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></P>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003><FONT color=3D#0000ff>I agree with the =
notion of=20
      the time-bounded recovery. However, here you started to make =
assumption=20
      about possible solutions. The same confusion arrived at the last =
IETF=20
      meeting when an LMP based solution was presented. All I am saying =
is that=20
      IMO&nbsp;breaking the problem into two part, I.e., getting =
agreement on=20
      the requirements and then following it up with the solution would =
be the=20
      right approach.&nbsp;<SPAN=20
      class=3D315563621-09092003>&nbsp;</SPAN></FONT></SPAN></SPAN></P>
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003><FONT color=3D#0000ff><SPAN=20
      class=3D315563621-09092003></SPAN></FONT></SPAN></SPAN>&nbsp;</P>
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003><FONT color=3D#0000ff><SPAN=20
      class=3D315563621-09092003></SPAN></FONT></SPAN></SPAN>&nbsp;</P>
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003><FONT color=3D#0000ff><SPAN=20
      class=3D315563621-09092003>&nbsp;</SPAN></FONT></SPAN></SPAN></P>
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003><FONT color=3D#0000ff>I agree with the =
requirement=20
      part of the problem statement. =
</FONT></SPAN></SPAN></P></BLOCKQUOTE>
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
    class=3D764565018-09092003>&nbsp;</SPAN>In fact, since recovery at =
the packet=20
    layer may not involve the stringent time constraints that are =
applicable at=20
    the transport layer, directly comparing notification solutions at =
the packet=20
    layer with those at the transport layer is probably not =
accurate.<SPAN=20
    class=3D764565018-09092003><FONT=20
    color=3D#0000ff>&nbsp;&nbsp;</FONT></SPAN></SPAN></P>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003></SPAN></SPAN><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20
      class=3D764565018-09092003><FONT color=3D#0000ff>What would be =
useful here is=20
      to quantify the</FONT> <FONT color=3D#0000ff>differences between =
the two=20
      types of networks. Such quantification will be useful in =
catalyzing some=20
      email discussions at the mailing list.=20
</FONT></SPAN></SPAN></P></BLOCKQUOTE>
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Rather,=20
    we need to examine (as done in draft-rabbat) the applicability of =
signaling=20
    and flooding to notification *<B><SPAN style=3D"FONT-WEIGHT: =
bold">at the=20
    transport layer</SPAN></B>* under the constraint of achieving =
time-bounded=20
    recovery.<SPAN class=3D764565018-09092003><FONT=20
    color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></P>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
      class=3D764565018-09092003>&nbsp;<FONT color=3D#0000ff>Agreed!=20
      </FONT></SPAN></SPAN></P></BLOCKQUOTE>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">So if the WG looks at=20
    draft-rabbat with this backdrop, we believe some of the arguments =
made there=20
    will be clearer. Of course, we welcome feedback from the=20
    list.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">-Richard and=20
    Vishal</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">PS: The need for =
time-bounded=20
    recovery is not new, and has been recognized in several recent IETF =
RFCs.=20
    Notably,</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">RFC3272</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.ietf.org/rfc/rfc3272.txt=20
    </SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">page =
52:</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; -&nbsp; =
Failure=20
    notification throughout the network should be timely and=20
    reliable.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Note that there is a =
list of=20
    requirements on this page, some of which are similar to those in=20
    draft-rabbat-optical-recovery-reqs-00.txt.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">RFC3386</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.ietf.org/rfc/rfc3386.txt,=20
    which is also relevant to the whole discussion.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Page 15 discusses the=20
    following:</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; Proposed =
timing=20
    bounds for different survivability mechanisms are as follows (all =
bounds are=20
    exclusive of signal propagation):</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; 1:1 path =
protection=20
    with pre-established capacity:&nbsp; 100-500 ms</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; 1:1 path =
protection=20
    with pre-planned capacity:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100-750=20
    ms</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; Local=20
    =
restoration:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    50 ms</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; Path=20
    =
restoration:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    1-5 seconds</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Note that RFC3386 =
discusses=20
    horizontal hierarchy in data networks, and so the bounds above apply =

    primarily to the packet layer. Similar numbers for the transport =
layer will=20
    likely be significantly stricter (Any operator inputs on=20
    this?).</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></H=
TML>

------=_NextPart_000_000E_01C376E1.D1918540--

Delivery-date: Tue, 09 Sep 2003 19:14:14 +0000
From: "zafar ali" <[email-masked]>
To: "'Richard Rabbat'" <[email-masked]>, <[email-masked]>
Cc: "'Vishal Sharma'" <[email-masked]>
Subject: RE: Time-bounded notification
Date: Tue, 9 Sep 2003 15:05:34 -0400
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_0160_01C376E3.DB7864A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Richard, 
 
Sorry for replying late; Please see comments in-lined. 
 
Thanks
 
Regards... Zafar
 
=====================================================================
Zafar Ali, Ph. D.
100 South Main St. #200,
Technical Leader,
Ann Arbor, MI 48104, USA.
Cisco Systems.
(734) 276-2459, [email-masked]
=====================================================================

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Rabbat
Sent: Thursday, August 14, 2003 2:09 PM
To: [email-masked]
Cc: 'Vishal Sharma'
Subject: Time-bounded notification

Hello Everyone,

Following some discussions prior to Vienna, and feedback and comments
received during Vienna and thereafter, we have realized that perhaps one
aspect of draft-rabbat-fault-notification-protocol-03.txt that we may
not have adequately highlighted is its focus on providing *time-bounded*
notification.

This is because draft-rabbat focuses on recovery in optical transport
networks, where recovery of failed LSPs (fibers, lambdas, etc.) in a
*bounded time* is critical for the provider to be able to offer
guarantees/SLAs to its transport customers, and also to its L2 and L3
customers. The transport infrastructure often serves as a foundation for
the L2 and L3 networks built upon it, and so should be able to provide
recovery within some well-specified time, so that L2 and L3 recovery can
be appropriately performed based on what L1 provides.

For this reason, notification via signaling or OSPF-based flooding,
which could work well at the packet layer, may not be directly
applicable at the transport layer.  

I agree with the notion of the time-bounded recovery. However, here you
started to make assumption about possible solutions. The same confusion
arrived at the last IETF meeting when an LMP based solution was
presented. All I am saying is that IMO breaking the problem into two
part, I.e., getting agreement on the requirements and then following it
up with the solution would be the right approach. 

I agree with the requirement part of the problem statement. 

 In fact, since recovery at the packet layer may not involve the
stringent time constraints that are applicable at the transport layer,
directly comparing notification solutions at the packet layer with those
at the transport layer is probably not accurate.  

What would be useful here is to quantify the differences between the two
types of networks. Such quantification will be useful in catalyzing some
email discussions at the mailing list. 

Rather, we need to examine (as done in draft-rabbat) the applicability
of signaling and flooding to notification *at the transport layer* under
the constraint of achieving time-bounded recovery. 

 Agreed! 

So if the WG looks at draft-rabbat with this backdrop, we believe some
of the arguments made there will be clearer. Of course, we welcome
feedback from the list.

Thanks,

-Richard and Vishal

PS: The need for time-bounded recovery is not new, and has been
recognized in several recent IETF RFCs. Notably,

RFC3272

http://www.ietf.org/rfc/rfc3272.txt 

page 52:

--

   -  Failure notification throughout the network should be timely and
reliable.

--

Note that there is a list of requirements on this page, some of which
are similar to those in draft-rabbat-optical-recovery-reqs-00.txt.

 

RFC3386

http://www.ietf.org/rfc/rfc3386.txt, which is also relevant to the whole
discussion.

Page 15 discusses the following:

--

   Proposed timing bounds for different survivability mechanisms are as
follows (all bounds are exclusive of signal propagation):

   1:1 path protection with pre-established capacity:  100-500 ms

   1:1 path protection with pre-planned capacity:      100-750 ms

   Local restoration:                                  50 ms

   Path restoration:                                   1-5 seconds

--

Note that RFC3386 discusses horizontal hierarchy in data networks, and
so the bounds above apply primarily to the packet layer. Similar numbers
for the transport layer will likely be significantly stricter (Any
operator inputs on this?).

 

------=_NextPart_000_0160_01C376E3.DB7864A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D764565018-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Richard, </FONT></SPAN></DIV>
<DIV><SPAN class=3D764565018-09092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D764565018-09092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry=20
for replying late; Please see comments in-lined. </FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Thanks</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2>Regards... =

Zafar</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Zaf=
ar=20
Ali, Ph. D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
class=3D764565018-09092003>&nbsp;&nbsp;</SPAN>100 South Main St.=20
#200,<BR>Technical =
Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</SPAN><SPAN=20
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>Ann Arbor, MI 48104, USA.<BR>Cisco=20
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D764565018-09092003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>(734)=20
276-2459<SPAN class=3D764565018-09092003>, <A=20
href=3D"mailto:[email-masked]">[email-masked]</A></SPAN><BR>=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Richard Rabbat<BR><B>Sent:</B> Thursday, August 14, 2003 2:09=20
  PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> 'Vishal=20
  Sharma'<BR><B>Subject:</B> Time-bounded =
notification<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hello =
Everyone,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Following some =
discussions prior=20
  to Vienna, and feedback and comments received during Vienna and =
thereafter, we=20
  have realized that perhaps one aspect of=20
  draft-rabbat-fault-notification-protocol-03.txt that we may not have=20
  adequately highlighted is its focus on providing *<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">time-bounded</SPAN></B>*=20
  notification.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This is because =
draft-rabbat=20
  focuses on recovery in optical transport networks, where recovery of =
failed=20
  LSPs (fibers, lambdas, etc.) in a *<B><SPAN style=3D"FONT-WEIGHT: =
bold">bounded=20
  time</SPAN></B>* is critical for the provider to be able to offer=20
  guarantees/SLAs to its transport customers, and also to its L2 and L3=20
  customers. The transport infrastructure often serves as a foundation =
for the=20
  L2 and L3 networks built upon it, and so should be able to provide =
recovery=20
  within some well-specified time, so that L2 and L3 recovery can be=20
  appropriately performed based on what L1 provides.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">For this=20
  reason, notification via signaling or OSPF-based flooding, which could =
work=20
  well at the packet layer, may not be directly applicable at the =
transport=20
  layer.&nbsp;<SPAN class=3D764565018-09092003><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></P>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
    class=3D764565018-09092003><FONT color=3D#0000ff>I agree with the =
notion of the=20
    time-bounded recovery. However, here you started to make assumption =
about=20
    possible solutions. The same confusion arrived at the last IETF =
meeting when=20
    an LMP based solution was presented. All I am saying is that=20
    IMO&nbsp;breaking the problem into two part, I.e., getting agreement =
on the=20
    requirements and then following it up with the solution would be the =
right=20
    approach. </FONT></SPAN></SPAN></P>
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
    class=3D764565018-09092003><FONT =
color=3D#0000ff></FONT></SPAN></SPAN>&nbsp;</P>
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
    class=3D764565018-09092003><FONT color=3D#0000ff>I agree with the =
requirement=20
    part of the problem statement. =
</FONT></SPAN></SPAN></P></BLOCKQUOTE>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
  class=3D764565018-09092003>&nbsp;</SPAN>In fact, since recovery at the =
packet=20
  layer may not involve the stringent time constraints that are =
applicable at=20
  the transport layer, directly comparing notification solutions at the =
packet=20
  layer with those at the transport layer is probably not accurate.<SPAN =

  class=3D764565018-09092003><FONT=20
  color=3D#0000ff>&nbsp;&nbsp;</FONT></SPAN></SPAN></P>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
    class=3D764565018-09092003></SPAN></SPAN><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20
    class=3D764565018-09092003><FONT color=3D#0000ff>What would be =
useful here is to=20
    quantify the</FONT> <FONT color=3D#0000ff>differences between the =
two types of=20
    networks. Such quantification will be useful in catalyzing some =
email=20
    discussions at the mailing list. =
</FONT></SPAN></SPAN></P></BLOCKQUOTE>
  <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Rather,=20
  we need to examine (as done in draft-rabbat) the applicability of =
signaling=20
  and flooding to notification *<B><SPAN style=3D"FONT-WEIGHT: bold">at =
the=20
  transport layer</SPAN></B>* under the constraint of achieving =
time-bounded=20
  recovery.<SPAN class=3D764565018-09092003><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></P>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
    class=3D764565018-09092003>&nbsp;<FONT color=3D#0000ff>Agreed!=20
    </FONT></SPAN></SPAN></P></BLOCKQUOTE>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">So if the WG looks at =
draft-rabbat=20
  with this backdrop, we believe some of the arguments made there will =
be=20
  clearer. Of course, we welcome feedback from the =
list.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">-Richard and=20
  Vishal</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">PS: The need for =
time-bounded=20
  recovery is not new, and has been recognized in several recent IETF =
RFCs.=20
  Notably,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">RFC3272</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.ietf.org/rfc/rfc3272.txt=20
  </SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">page =
52:</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; -&nbsp; =
Failure=20
  notification throughout the network should be timely and=20
  reliable.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Note that there is a =
list of=20
  requirements on this page, some of which are similar to those in=20
  draft-rabbat-optical-recovery-reqs-00.txt.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">RFC3386</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.ietf.org/rfc/rfc3386.txt,=20
  which is also relevant to the whole discussion.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Page 15 discusses the=20
  following:</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; Proposed =
timing=20
  bounds for different survivability mechanisms are as follows (all =
bounds are=20
  exclusive of signal propagation):</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; 1:1 path =
protection=20
  with pre-established capacity:&nbsp; 100-500 ms</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; 1:1 path =
protection=20
  with pre-planned capacity:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100-750=20
  ms</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; Local=20
  =
restoration:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  50 ms</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;&nbsp; Path=20
  =
restoration:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  1-5 seconds</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Note that RFC3386 =
discusses=20
  horizontal hierarchy in data networks, and so the bounds above apply =
primarily=20
  to the packet layer. Similar numbers for the transport layer will =
likely be=20
  significantly stricter (Any operator inputs on =
this?).</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0160_01C376E3.DB7864A0--

Delivery-date: Fri, 05 Sep 2003 16:30:20 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Len Nieman" <[email-masked]>
Cc: <[email-masked]>, "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>, "Edward Harrison" <[email-masked]>
Subject: Re: GMPLS MIBs
Date: Fri, 5 Sep 2003 17:21:41 +0100

Thanks Len,

Much appreciated.

Adrian
----- Original Message ----- 
From: "Len Nieman" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "Tim Hall" <[email-masked]>; "Thomas D. Nadeau"
<[email-masked]>; "Cheenu Srinivasan" <[email-masked]>; "Edward Harrison"
<[email-masked]>
Sent: Friday, September 05, 2003 2:07 AM
Subject: Re: GMPLS MIBs

>
> >All I have just posted an update to the GMPLS MIB modules.
> >The model followed is to extend the MPLS MIB modules.
> >
> >At the moment the drafts are VERY rough, but we wanted to publish
> >them so that the WG can see the direction we are taking and
> >comment accordingly. In particular:
> >
> >- no attempt at compilation has yet been made
>
> I ran compiles on the drafts listed using the MG-SOFT MIB
> Compiler (MS Windows Edition) Version 5.0 RC1, Build 110.
>
> Prior to attempting this I compiled the appropriate MPLS MIB
> modules from the most recent mpls drafts. It wasn't included in
> your list, but I also compiled the LMP-MIB module from
> draft-ietf-ccamp-lmp-mib-06.txt while I was at it.
>
> The results were:
>
> draft-ietf-ccamp-gmpls-tc-mib-01.txt
>
> - GMPLS-TC-MIB module: Compiled okay after substituting the ifType
> value of "166" for the "xxx" here:
>
>    gmplsStdMIB OBJECT IDENTIFIER
>      -- This object identifier needs to be assigned by IANA.
>      -- Since mpls has been assigned an ifType of 166 we recommend
>      -- that this OID be 166 as well, i.e.
>    -- ::= { transmission XXX }
>    ::= { transmission 166 }
>
> ========================================
>
> draft-ietf-ccamp-gmpls-lsr-mib-01.txt
>
> - GMPLS-LABEL-STD-MIB module: Compiled okay after adding a second
> dash in front of the "The MPLS LSR MIB" comment here:
>
>      MODULE MPLS-LSR-STD-MIB - The MPLS LSR MIB
>
> - GMPLS-LSR-STD-MIB module: Compiled okay after correcting three
> instances of "SYNTAX Uunsigned32" to "SYNTAX Unsigned32" at these
> locations:
>
>    gmplsLabelWavebandId OBJECT-TYPE
>      SYNTAX        Uunsigned32
>
>    gmplsLabelWavebandStart OBJECT-TYPE
>      SYNTAX        Uunsigned32
>
>    gmplsLabelWavebandEnd OBJECT-TYPE
>      SYNTAX        Uunsigned32
>
> ===========================================
>
> draft-ietf-ccamp-gmpls-te-mib-01.txt
>
> - GMPLS-TE-MIB module:
>
> Error "Item 'MplsTunnelARHopEntry' is not defined or imported"
> at:
>
>    gmplsTunnelARHopEntry  OBJECT-TYPE
>      SYNTAX  MplsTunnelARHopEntry
>
> Error "Item 'DisplayString' is not defined or imported at:
>
>    GmplsTunnelErrorEntry ::= SEQUENCE {
>      gmplsTunnelErrorHelpString         DisplayString
>
> Error "Missing 'ACCESS or MAX-ACCESS" being created by an extraneous
> comma at the end of the SYNTAX line at:
>
>    gmplsTunnelErrorReporterIpv6Addr OBJECT-TYPE
>      SYNTAX  InetAddressIPv6,
>      MAX-ACCESS read-only
>
> ===============================================
>
> draft-ietf-ccamp-lmp-mib-06.txt
>
> - LMP-MIB module: Compiled okay after substituting the
> experimental value of "113" for the "xxx" here:
>
>    DESCRIPTION
>        "Initial version published as RFC xxxx (to be assigned by RFC
>         Editor)"
>    ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can
>                      -- be used in the interim)
>
> =================================================
>
> Len Nieman
>
>

Envelope-to: [email-masked]
Delivery-date: Fri, 05 Sep 2003 01:11:41 +0000
Date: Thu, 04 Sep 2003 21:07 -0400 (EDT)
From: Len Nieman <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
CC: <[email-masked]>, "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>, "Edward Harrison" <[email-masked]>
Subject: Re: GMPLS MIBs
Message-Id: <20030905010511.TFQJ24929.imf19aec.mail.bellsouth.net@localHost>

>All I have just posted an update to the GMPLS MIB modules.
>The model followed is to extend the MPLS MIB modules.
>
>At the moment the drafts are VERY rough, but we wanted to publish
>them so that the WG can see the direction we are taking and
>comment accordingly. In particular:
>
>- no attempt at compilation has yet been made

I ran compiles on the drafts listed using the MG-SOFT MIB
Compiler (MS Windows Edition) Version 5.0 RC1, Build 110.

Prior to attempting this I compiled the appropriate MPLS MIB
modules from the most recent mpls drafts. It wasn't included in
your list, but I also compiled the LMP-MIB module from
draft-ietf-ccamp-lmp-mib-06.txt while I was at it.

The results were:

draft-ietf-ccamp-gmpls-tc-mib-01.txt

- GMPLS-TC-MIB module: Compiled okay after substituting the ifType
value of "166" for the "xxx" here:

   gmplsStdMIB OBJECT IDENTIFIER
     -- This object identifier needs to be assigned by IANA.
     -- Since mpls has been assigned an ifType of 166 we recommend
     -- that this OID be 166 as well, i.e.
   -- ::= { transmission XXX }
   ::= { transmission 166 }

========================================

draft-ietf-ccamp-gmpls-lsr-mib-01.txt

- GMPLS-LABEL-STD-MIB module: Compiled okay after adding a second
dash in front of the "The MPLS LSR MIB" comment here:

     MODULE MPLS-LSR-STD-MIB - The MPLS LSR MIB

- GMPLS-LSR-STD-MIB module: Compiled okay after correcting three
instances of "SYNTAX Uunsigned32" to "SYNTAX Unsigned32" at these
locations:

   gmplsLabelWavebandId OBJECT-TYPE
     SYNTAX        Uunsigned32

   gmplsLabelWavebandStart OBJECT-TYPE
     SYNTAX        Uunsigned32

   gmplsLabelWavebandEnd OBJECT-TYPE
     SYNTAX        Uunsigned32

===========================================

draft-ietf-ccamp-gmpls-te-mib-01.txt

- GMPLS-TE-MIB module:

Error "Item 'MplsTunnelARHopEntry' is not defined or imported"
at:

   gmplsTunnelARHopEntry  OBJECT-TYPE
     SYNTAX  MplsTunnelARHopEntry

Error "Item 'DisplayString' is not defined or imported at:

   GmplsTunnelErrorEntry ::= SEQUENCE {
     gmplsTunnelErrorHelpString         DisplayString

Error "Missing 'ACCESS or MAX-ACCESS" being created by an extraneous
comma at the end of the SYNTAX line at:

   gmplsTunnelErrorReporterIpv6Addr OBJECT-TYPE
     SYNTAX  InetAddressIPv6,
     MAX-ACCESS read-only

===============================================

draft-ietf-ccamp-lmp-mib-06.txt

- LMP-MIB module: Compiled okay after substituting the
experimental value of "113" for the "xxx" here:

   DESCRIPTION
       "Initial version published as RFC xxxx (to be assigned by RFC
        Editor)"
   ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can
                     -- be used in the interim)

=================================================

Len Nieman

Envelope-to: [email-masked]
Delivery-date: Fri, 05 Sep 2003 01:11:10 +0000
Date: Thu, 04 Sep 2003 21:07 -0400 (EDT)
From: Len Nieman <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
CC: <[email-masked]>, "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>, "Edward Harrison" <[email-masked]>
Subject: Re: GMPLS MIBs
Message-Id: <20030905010322.TESY24929.imf19aec.mail.bellsouth.net@localHost>

>All I have just posted an update to the GMPLS MIB modules.
>The model followed is to extend the MPLS MIB modules.
>
>At the moment the drafts are VERY rough, but we wanted to publish
>them so that the WG can see the direction we are taking and
>comment accordingly. In particular:
>
>- no attempt at compilation has yet been made

I ran compiles on the drafts listed using the MG-SOFT MIB
Compiler (MS Windows Edition) Version 5.0 RC1, Build 110.

Prior to attempting this I compiled the appropriate MPLS MIB
modules from the most recent mpls drafts. It wasn't included in
your list, but I also compiled the LMP-MIB module from
draft-ietf-ccamp-lmp-mib-06.txt while I was at it.

The results were:

draft-ietf-ccamp-gmpls-tc-mib-01.txt

- GMPLS-TC-MIB module: Compiled okay after substituting the ifType
value of "166" for the "xxx" here:

   gmplsStdMIB OBJECT IDENTIFIER
     -- This object identifier needs to be assigned by IANA.
     -- Since mpls has been assigned an ifType of 166 we recommend
     -- that this OID be 166 as well, i.e.
   -- ::= { transmission XXX }
   ::= { transmission 166 }

========================================

draft-ietf-ccamp-gmpls-lsr-mib-01.txt

- GMPLS-LABEL-STD-MIB module: Compiled okay after adding a second
dash in front of the "The MPLS LSR MIB" comment here:

     MODULE MPLS-LSR-STD-MIB - The MPLS LSR MIB

- GMPLS-LSR-STD-MIB module: Compiled okay after correcting three
instances of "SYNTAX Uunsigned32" to "SYNTAX Unsigned32" at these
locations:

   gmplsLabelWavebandId OBJECT-TYPE
     SYNTAX        Uunsigned32

   gmplsLabelWavebandStart OBJECT-TYPE
     SYNTAX        Uunsigned32

   gmplsLabelWavebandEnd OBJECT-TYPE
     SYNTAX        Uunsigned32

===========================================

draft-ietf-ccamp-gmpls-te-mib-01.txt

- GMPLS-TE-MIB module:

Error "Item 'MplsTunnelARHopEntry' is not defined or imported"
at:

   gmplsTunnelARHopEntry  OBJECT-TYPE
     SYNTAX  MplsTunnelARHopEntry

Error "Item 'DisplayString' is not defined or imported at:

   GmplsTunnelErrorEntry ::= SEQUENCE {
     gmplsTunnelErrorHelpString         DisplayString

Error "Missing 'ACCESS or MAX-ACCESS" being created by an extraneous
comma at the end of the SYNTAX line at:

   gmplsTunnelErrorReporterIpv6Addr OBJECT-TYPE
     SYNTAX  InetAddressIPv6,
     MAX-ACCESS read-only

===============================================

draft-ietf-ccamp-lmp-mib-06.txt

- LMP-MIB module: Compiled okay after substituting the
experimental value of "113" for the "xxx" here:

   DESCRIPTION
       "Initial version published as RFC xxxx (to be assigned by RFC
        Editor)"
   ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can
                     -- be used in the interim)

=================================================

Len Nieman

Delivery-date: Tue, 02 Sep 2003 17:37:34 +0000
Reply-To: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Cc: "'Tim Hall'" <[email-masked]>, "'Cheenu Srinivasan'" <[email-masked]>, "'Edward Harrison'" <[email-masked]>
Subject: RE: GMPLS MIBs
Date: Tue, 2 Sep 2003 11:29:56 -0400
Organization: Cisco Systems, inc.

> All I have just posted an update to the GMPLS MIB modules.
> The model followed is to extend the MPLS MIB modules.

	You should also note that the current group of drafts 
is based on the latest group of base MPLS MIBs, so it is
fairly up-to-date.

	--Tom

> At the moment the drafts are VERY rough, but we wanted to 
> publish them so that the WG can see the direction we are 
> taking and comment accordingly. In particular:
> - no attempt at compilation has yet been made
> - the introductory text and examples lags behind the actual ASN.1
> - there is a list of work items at the end of the LSR and TE 
> documents.
> 
> We would welcome all thoughts great and small (although there 
> is little point in telling us about nits at this stage).
> 
> The drafts are:
> 
> draft-ietf-ccamp-gmpls-tc-mib-01.txt  containing textual conventions
> 
> draft-ietf-ccamp-gmpls-lsr-mib-01.txt containing extensions 
> to the MPLS LSR MIB module and defining a GMPLS Label Table
> 
> draft-ietf-ccamp-gmpls-te-mib-01.txt containing extensions to 
> the MPLS TE MIB.
> 
> 
> Our plans are to consolidate these drafts considerably in the 
> next month, hopefully completing all of the work items.
> 
> Thanks,
> Adrian
> 
> 

Delivery-date: Mon, 01 Sep 2003 20:46:47 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "'Martin Dubuc'" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: LMP MIB revision 6
Date: Mon, 1 Sep 2003 22:42:57 +0200 

Well well...

SMICng says:
   W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification 
      "lmpDataLinkPropertyMismatch" is an index for a table
   W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
      "lmpTeLinkDegraded" is an index for a table
   W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
      "lmpTeLinkNotDegraded" is an index for a table
   W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
      "lmpDataLinkVerificationFailure" is an index for a table
   W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
      specified for "lmpCcOperStatus"
   W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
      specified for "lmpTeLinkOperStatus"
   W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
      specified for "lmpDataLinkActiveOperStatus"
   W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
      specified for "lmpDataLinkPassiveOperStatus"

smilint says:
   .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
     `degraded(4)' illegal in sub-type
   .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
     `up(1)' illegal in sub-type
   .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
     `down(2)' illegal in sub-type
   .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
     `degraded(4)' illegal in sub-type
   .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
     `up(1)' illegal in sub-type
   .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
     `down(2)' illegal in sub-type
   .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
     `degraded(4)' illegal in sub-type
   .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
     `degraded(4)' illegal in sub-type
   .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
     `up(1)' illegal in sub-type
   .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
     `down(2)' illegal in sub-type
   .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
     `degraded(4)' illegal in sub-type
   .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
     `up(1)' illegal in sub-type
   .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
     `down(2)' illegal in sub-type
   .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
     `degraded(4)' illegal in sub-type
   .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
     `InetAddress' object should have an accompanied preceding
     `InetAdressType' object
   .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
     `InetAddress' object should have an accompanied preceding
     `InetAdressType' object
   .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
     `InetAddress' objectshould have an accompanied preceding
     `InetAdressType' object

Some details:
1. lmpNbrNodeId OBJECT-TYPE
      SYNTAX        InetAddress (SIZE(4))
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
       "This is a unique index for an entry in the LmpNbrTable.
        This value represents the remote Node ID. The Node ID
        address type must be IPv4."
      ::= { lmpNbrEntry 1 }
   You do know that MIB modules need to be IPv6 friendly, no?
   Is LMP itself such that it only works with IPv4? I doubt that
   IESG will approve new protocols that do not support IPv6.
2. For these 2 objects:
     lmpNbrRetransmitInterval  LmpRetransmitInterval,
     lmpNbrRetryLimit          Unsigned32,
   You may want to add some text as to howyou intend to deal with
   congestion (RFC 2914). This over UDP if I remember well?
   I think it would be good to point explicitly to the text in lmp
   document (sect 10).
3. lmpNbrRowStatus OBJECT-TYPE
     SYNTAX        RowStatus
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable is used to create, modify, and/or
        delete a row in this table. All read-create objects
        can only be changed when lmpNbrRowStatus is active."
   That sounds strange. The notInService status was specifically
   created to allow changes for cases where changes were not allowed
   while row was active. Here you say it MUST be active in order
   to make changes? Or did you mean "can not be changed"?
   This occurs in more (maybe all) RowStatus objects in this doc.
4. You have some objedts that are not part of a table, yet are
   read-write. For example
       lmpAdminStatus
       lmpCcHelloIntervalDefault
       lmpCcHelloIntervalDefaultMin
       ... and more ...
   What is the persistency behaviour of these objects?
   In other words: is the value preserved over a reboot?
5. Is lmpCcIsIf not redundant? The way I read it, then if the
   lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
   an interface, no?
6. lmpRemoteCcAddressType and lmpRemoteCcAddress
   In the telink MIB you have done things correctly and as presscribe
   by RFC3291. Here you have not. Why ?
   Even in this doc you have done it correctly in some places.
7. Mmmmmm??? 52 counters to "measure the performance" of the LMP channels?
   Sounds overwhelming to me.
8. Formally, every Counterxx object needs to include in its descritpion
   clause which object indicates a potential discontinuity. I understand
   that they all are covered by lmpCcCounterDiscontinuityTime in the
   same row. Maybe write something about that in the ...Entry description
   clause as well if you do not want to add text to every Counter
9. lmpTeLinkTable
   DESCRIPTION
       "This table contains a collection of TE link."
   Means what??
10. lmpLinkVerificationInterval
    What does a value of zero mean?
    Any comments regarding possible congestiuon if the value is set to
    a very small number of msecs?
11. lmpLinkVerificationTable
    Or is it better namep lmpTeLinkLinkVerificationTable
    and then rename objects as well? If is correct name,
    Then maybe rename
       lmpTeLinkBitRate        to lmpLinkVerificationTeLinkBitRate
       lmpTeLinkWavelength     to lmpLinkVerificationTeLinkWavelength
12. lmpVerifyTransportMechanism
    There are a few TBDs in there. Better decide before you submit to AD
13. lmpTeLinkBitRate
     DESCRIPTION
       "This is the bit rate at which the Test messages will be
        transmitted and is expressed in bytes per second."
    A BIT rate that gest expressed in BYTES per second?
    Possible of course but strange, no? Why not call it ByteRate?
14. Another 40 or so counters for lmpTeLinkPerfTable ???
15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
       OBJECTS       { ifIndex,
                       lmpDataLinkRemoteIfId }
    The second object already (implicitly) also contains the value
    of the first object (it is the index part of the OID).
16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
    them. But when they are enabled, what kind of rates per second
    should we fear for in a worst case conidition?
    Pls think about both an agent (i.e. an LMP node) generating
    them, but also think about a SNMP management station receiving
    them from potentially 100s or 1000s of LMP nodes.
17. On page 7 I see:
      lmpDataLinkAddressType          = unnumbered(1),
    Mm... that is not a valid value for an InetAddressType

18. Security COnsiderations
    You are not following the guidelines to describe first the
    SET (read-write, read-create) issues/concerns/vulnerabilities
    and then the read-only sensistivities. So I would not be
    surprised to see push back from the Security front.

I have done a pretty serious review... but not exhaustive.

Thanks,

Bert 
-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: maandag 1 september 2003 20:14
To: 'Martin Dubuc'; Wijnen, Bert (Bert)
Subject: RE: LMP MIB

I have it on my todo-list. I am currently checking te-link mib.

Thanks,
Bert 
-----Original Message-----
From: Martin Dubuc [mailto:[email-masked]]
Sent: maandag 1 september 2003 19:55
To: Bert Wijnen
Subject: LMP MIB

Bert,

I know you have been quite busy with all the MPLS drafts. I just wanted to know if you had time review the LMP MIB draft and if not, when you think you'll get around reviewing it.

Regards,

Martin