Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 22:23:11 +0000 Message-ID: <3F7A01C2.2070503@lucent.com> Date: Tue, 30 Sep 2003 16:20:50 -0600 From: Stephen J Trowbridge Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: iesg@ietf.org, Ronald Bonica , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: WG Review: Recharter of Common Control and Measurement Plane (ccamp) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:sjtrowbridge@lucent.com] >>Sent: dinsdag 30 september 2003 23:36 >>To: iesg@ietf.org >>Cc: Ronald Bonica; Kireeti Kompella; ccamp@ops.ietf.org >>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 >> >>(iesg@ietf.org) by September 30. >> >>> Common Control and Measurement Plane (ccamp) >>> -------------------------------------------- >>> >>> Current Status: Active Working Group >>> >>> Chair(s): >>> Ronald Bonica >>> Kireeti Kompella >>> >>> Routing Area Director(s): >>> Bill Fenner >>> Alex Zinin >>> >>> Routing Area Advisor: >>> Alex Zinin >>> >>> Mailing Lists: >>> General Discussion: ccamp@ops.ietf.org >>> To Subscribe: majordomo@ops.ietf.org >>> 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 >> >>> >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 21:52:52 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3A9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Stephen J Trowbridge'" , iesg@ietf.org Cc: Ronald Bonica , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: WG Review: Recharter of Common Control and Measurement Plane (ccamp) Date: Tue, 30 Sep 2003 23:51:01 +0200 MIME-Version: 1.0 Content-Type: text/plain 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:sjtrowbridge@lucent.com] > Sent: dinsdag 30 september 2003 23:36 > To: iesg@ietf.org > Cc: Ronald Bonica; Kireeti Kompella; ccamp@ops.ietf.org > 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 > (iesg@ietf.org) by September 30. > > > > Common Control and Measurement Plane (ccamp) > > -------------------------------------------- > > > > Current Status: Active Working Group > > > > Chair(s): > > Ronald Bonica > > Kireeti Kompella > > > > Routing Area Director(s): > > Bill Fenner > > Alex Zinin > > > > Routing Area Advisor: > > Alex Zinin > > > > Mailing Lists: > > General Discussion: ccamp@ops.ietf.org > > To Subscribe: majordomo@ops.ietf.org > > 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 > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 21:52:01 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3A8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Stephen J Trowbridge'" , iesg@ietf.org Cc: Ronald Bonica , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: WG Review: Recharter of Common Control and Measurement Plane (ccamp) Date: Tue, 30 Sep 2003 23:49:16 +0200 MIME-Version: 1.0 Content-Type: text/plain Steve, do you not think that this is covered by: Thanks, Bert > -----Original Message----- > From: Stephen J Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: dinsdag 30 september 2003 23:36 > To: iesg@ietf.org > Cc: Ronald Bonica; Kireeti Kompella; ccamp@ops.ietf.org > 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 > (iesg@ietf.org) by September 30. > > > > Common Control and Measurement Plane (ccamp) > > -------------------------------------------- > > > > Current Status: Active Working Group > > > > Chair(s): > > Ronald Bonica > > Kireeti Kompella > > > > Routing Area Director(s): > > Bill Fenner > > Alex Zinin > > > > Routing Area Advisor: > > Alex Zinin > > > > Mailing Lists: > > General Discussion: ccamp@ops.ietf.org > > To Subscribe: majordomo@ops.ietf.org > > 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 > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 21:39:33 +0000 Message-ID: <3F79F751.4030509@lucent.com> Date: Tue, 30 Sep 2003 15:36:17 -0600 From: Stephen J Trowbridge Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) MIME-Version: 1.0 To: iesg@ietf.org CC: Ronald Bonica , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: WG Review: Recharter of Common Control and Measurement Plane (ccamp) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 (iesg@ietf.org) by September 30. > > Common Control and Measurement Plane (ccamp) > -------------------------------------------- > > Current Status: Active Working Group > > Chair(s): > Ronald Bonica > Kireeti Kompella > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: ccamp@ops.ietf.org > To Subscribe: majordomo@ops.ietf.org > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 17:38:45 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: draft-ietf-ccamp-lmp Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Sep 2003 10:35:23 -0700 Message-ID: <23F5FB9E8B1C734F9633D9E1D336E8850214CE@sb-exchange1.rinconnetworks.com> Thread-Topic: FW: draft-ietf-ccamp-lmp Thread-Index: AcOHRFThDeAklFZ9S2qL0HglX5ccBQAM04PQ From: "Jonathan Lang" To: , "Wijnen, Bert (Bert)" Cc: "Ccamp-wg (E-mail)" , "Steve Bellovin (E-mail)" 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: Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=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: Dimitri.Papadimitriou@alcatel.be=20 > >>[mailto:Dimitri.Papadimitriou@alcatel.be] > >>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:smb@research.att.com] > >>>Sent: maandag 29 september 2003 20:26 > >>>To: Wijnen, Bert (Bert) > >>>Cc: 'Jonathan Lang' > >>>Subject: Re: draft-ietf-ccamp-lmp > >>> > >>> > >>>In message > >> > >><7D5D48D2CAA3D84C813F5B154F43B15502331618@nl0006exch001u.nl.lucent.c > >> > >>>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 : dimitri.papadimitriou@alcatel.be > >>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > >>E-mail : dpapadimitriou@psg.com > >>Public : http://psg.com/~dpapadimitriou/ > >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > >>Phone : +32 3 240-8491 > >> > >> >=20 > --=20 > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 11:18:23 +0000 Message-ID: <3F79666C.5070702@alcatel.be> Date: Tue, 30 Sep 2003 13:18:04 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Ccamp-wg (E-mail)" , Jonathan Lang , "Steve Bellovin (E-mail)" Subject: Re: FW: draft-ietf-ccamp-lmp Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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: Dimitri.Papadimitriou@alcatel.be >>[mailto:Dimitri.Papadimitriou@alcatel.be] >>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:smb@research.att.com] >>>Sent: maandag 29 september 2003 20:26 >>>To: Wijnen, Bert (Bert) >>>Cc: 'Jonathan Lang' >>>Subject: Re: draft-ietf-ccamp-lmp >>> >>> >>>In message >> >><7D5D48D2CAA3D84C813F5B154F43B15502331618@nl0006exch001u.nl.lucent.c >> >>>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 : dimitri.papadimitriou@alcatel.be >>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html >>E-mail : dpapadimitriou@psg.com >>Public : http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>Phone : +32 3 240-8491 >> >> -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 10:44:12 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC37A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Ccamp-wg (E-mail)" Cc: Jonathan Lang , "Steve Bellovin (E-mail)" Subject: RE: FW: draft-ietf-ccamp-lmp Date: Tue, 30 Sep 2003 12:39:58 +0200 MIME-Version: 1.0 Content-Type: text/plain [ 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: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > 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:smb@research.att.com] > > Sent: maandag 29 september 2003 20:26 > > To: Wijnen, Bert (Bert) > > Cc: 'Jonathan Lang' > > Subject: Re: draft-ietf-ccamp-lmp > > > > > > In message > <7D5D48D2CAA3D84C813F5B154F43B15502331618@nl0006exch001u.nl.lucent.c > > 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 : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 09:03:53 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC373@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Cc: "Steve Bellovin (E-mail)" Subject: FW: draft-ietf-ccamp-lmp Date: Tue, 30 Sep 2003 11:01:12 +0200 MIME-Version: 1.0 Content-Type: text/plain 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:smb@research.att.com] Sent: maandag 29 september 2003 20:26 To: Wijnen, Bert (Bert) Cc: 'Jonathan Lang' Subject: Re: draft-ietf-ccamp-lmp In message <7D5D48D2CAA3D84C813F5B154F43B15502331618@nl0006exch001u.nl.lucent.c 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Sep 2003 07:23:54 +0000 Sensitivity: Subject: Upgrade of a classical Transport network to a GMPLS one To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Tue, 30 Sep 2003 09:18:33 +0200 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Sep 2003 17:27:23 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'Martin Dubuc'" Cc: "'Ccamp-wg \(E-mail\)'" Subject: RE: LMP MIB revision 6 Date: Mon, 29 Sep 2003 13:20:58 -0400 Organization: Cisco Systems, inc. Message-ID: <005e01c386ae$0c84b100$9b472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] 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:m.dubuc@rogers.com] >> 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)" >> To: "'Martin Dubuc'" >> Cc: "Ccamp-wg (E-mail)" >> 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:m.dubuc@rogers.com] >> > 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 >> > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 28 Sep 2003 09:04:42 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC335@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Martin Dubuc'" , "Wijnen, Bert (Bert)" Cc: "Ccamp-wg (E-mail)" Subject: RE: LMP MIB revision 6 Date: Sun, 28 Sep 2003 11:01:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:m.dubuc@rogers.com] > 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)" > To: "'Martin Dubuc'" > Cc: "Ccamp-wg (E-mail)" > 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:m.dubuc@rogers.com] > > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 28 Sep 2003 00:46:25 +0000 From: "ramasamy ramanathan" To: Subject: doubts Date: Sat, 27 Sep 2003 17:55:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 27 Sep 2003 13:53:18 +0000 Subject: Re: SONET/SDH Encoding for LMP Test messages To: Sidney.SHIBA@fnc.fujitsu.com (Shiba, Sidney) Date: Sat, 27 Sep 2003 13:48:08 +0000 (GMT) Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou 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:dpapadimitriou@psg.com] > Sent: Friday, September 26, 2003 3:01 PM > To: Sidney.SHIBA@fnc.fujitsu.com > Cc: ccamp@ops.ietf.org > 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 > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Sep 2003 21:24:40 +0000 Message-ID: From: "Shiba, Sidney" To: "'Dimitri Papadimitriou'" Cc: ccamp@ops.ietf.org Subject: RE: SONET/SDH Encoding for LMP Test messages Date: Fri, 26 Sep 2003 16:20:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:dpapadimitriou@psg.com] Sent: Friday, September 26, 2003 3:01 PM To: Sidney.SHIBA@fnc.fujitsu.com Cc: ccamp@ops.ietf.org 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 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Sep 2003 20:02:27 +0000 Subject: Re: SONET/SDH Encoding for LMP Test messages To: Sidney.SHIBA@fnc.fujitsu.com (Shiba, Sidney) Date: Fri, 26 Sep 2003 20:00:45 +0000 (GMT) Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou 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 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Sep 2003 18:57:55 +0000 Message-ID: From: "Shiba, Sidney" To: "'Dimitri Papadimitriou'" Cc: ccamp@ops.ietf.org Subject: SONET/SDH Encoding for LMP Test messages Date: Fri, 26 Sep 2003 13:51:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Sep 2003 16:11:44 +0000 Message-Id: <200309251607.MAA02587@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-25104759.I-D@ietf.org> 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: <2003-9-25104759.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Sep 2003 19:36:50 +0000 Message-Id: <200309241929.PAA03454@ietf.org> From: The IESG To: IETF-Announce: ; Cc: new-work@ietf.org, Ronald Bonica , Kireeti Kompella , ccamp@ops.ietf.org 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 (iesg@ietf.org) by September 30. Common Control and Measurement Plane (ccamp) -------------------------------------------- Current Status: Active Working Group Chair(s): Ronald Bonica Kireeti Kompella Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion: ccamp@ops.ietf.org To Subscribe: majordomo@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Sep 2003 13:37:30 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC2B4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Martin Dubuc'" Cc: "Ccamp-wg (E-mail)" Subject: RE: LMP MIB revision 6 Date: Wed, 24 Sep 2003 15:34:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Inline Thanks, Bert > -----Original Message----- > From: Martin Dubuc [mailto:m.dubuc@rogers.com] > 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)" > To: "'Martin Dubuc'" > Cc: "Ccamp-wg (E-mail)" > 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:m.dubuc@rogers.com] > > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Sep 2003 20:39:47 +0000 Message-ID: <3F70AE9E.2060209@alcatel.be> Date: Tue, 23 Sep 2003 22:35:42 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Kireeti Kompella Cc: Jonathan Sadler , ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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 Dimitri.Papadimitriou@alcatel.be 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 : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Sep 2003 15:42:37 +0000 Date: Tue, 23 Sep 2003 08:42:10 -0700 (PDT) From: Kireeti Kompella To: Dimitri.Papadimitriou@alcatel.be cc: Jonathan Sadler , "" Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Message-ID: <20030923083839.L25821@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Dimitri, On Tue, 23 Sep 2003 Dimitri.Papadimitriou@alcatel.be 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Sep 2003 15:41:43 +0000 Date: Tue, 23 Sep 2003 08:36:55 -0700 (PDT) From: Kireeti Kompella To: Jonathan Sadler cc: ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS to Proposed Standard Message-ID: <20030923082056.G25821@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Sep 2003 11:41:38 +0000 Message-ID: <3F7030DE.7030906@alcatel.be> Date: Tue, 23 Sep 2003 13:39:10 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Jonathan Sadler Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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 : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Sep 2003 06:01:32 +0000 Reply-To: From: "Vishal Sharma" To: , , Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Mon, 22 Sep 2003 22:55:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Neil, Thanks for your note. A few follow-up comments in-line. Regards, -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of neil.2.harrison@bt.com > Sent: Friday, September 19, 2003 9:36 AM > To: v.sharma@ieee.org; rabbat@fla.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: Comparison of restoration requirements between transport > and packet networks > > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Sep 2003 22:15:36 +0000 Subject: Re: Updated CCAMP charter (fwd) To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Mon, 22 Sep 2003 22:13:36 +0000 (GMT) Cc: Dimitri.Papadimitriou@alcatel.be ('Dimitri.Papadimitriou@alcatel.be'), kireeti@juniper.net (Kireeti Kompella), ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Sep 2003 20:45:31 +0000 Message-ID: <3F6F5E88.CA9C508E@tellabs.com> Date: Mon, 22 Sep 2003 15:41:44 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Sep 2003 18:45:58 +0000 Message-Id: <200309221844.OAA29469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132531.I-D@ietf.org> 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: <2003-9-22132531.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Sep 2003 18:32:37 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331627@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Dimitri.Papadimitriou@alcatel.be'" , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Updated CCAMP charter (fwd) Date: Mon, 22 Sep 2003 20:29:27 +0200 MIME-Version: 1.0 Content-Type: text/plain > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Sep 2003 16:50:39 +0000 Message-ID: <3F6F27B1.6080003@alcatel.be> Date: Mon, 22 Sep 2003 18:47:45 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Updated CCAMP charter (fwd) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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 > Kireeti Kompella > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: ccamp@ops.ietf.org > To Subscribe: majordomo@ops.ietf.org > 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 : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Sep 2003 14:20:15 +0000 Date: Mon, 22 Sep 2003 07:13:41 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Message-ID: <20030922064029.J20754@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Sep 2003 20:55:12 +0000 From: "Richard Rabbat" To: "'zafar ali'" , Cc: "Vishal Sharma" , "'Richard Rabbat'" Subject: RE: Time-bounded notification Date: Fri, 19 Sep 2003 13:49:15 -0700 Message-ID: <002a01c37eef$7d4e1aa0$3b3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C37EB4.D0EF42A0" 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of zafar ali Sent: Tuesday, September 09, 2003 12:06 PM To: 'Richard Rabbat'; ccamp@ops.ietf.org 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, zali@cisco.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Richard Rabbat Sent: Thursday, August 14, 2003 2:09 PM To: ccamp@ops.ietf.org 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 Message

Hi Zafar,

Please see my comments = inline.

Thanks,

Richard.

 

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

 

Hi Richard,

 

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

 

Thanks

 

Regards... Zafar

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=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.            = ;            =             &= nbsp;           &n= bsp;        100 South Main St. #200,
Technical Leader,           =             &= nbsp;           &n= bsp;           &nb= sp;       Ann Arbor, MI 48104, USA.
Cisco Systems.           = ;            =             &= nbsp;           &n= bsp;         (734) 276-2459, zali@cisco.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Richard Rabbat
Sent: Thursday, August = 14, 2003 2:09 PM
To: = ccamp@ops.ietf.org
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. =

 

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

 

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

[Richard] = Thanks.

 

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

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

 Agreed!

 

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

 

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.

 

[snipped]

------=_NextPart_000_002B_01C37EB4.D0EF42A0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Sep 2003 16:41:16 +0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2B32@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: v.sharma@ieee.org, rabbat@fla.fujitsu.com, ccamp@ops.ietf.org Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Fri, 19 Sep 2003 17:36:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vishal, some remarks in-line. regards, Neil Vishal Sharma wrote 18 September 2003 06:31 > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Sep 2003 20:37:06 +0000 Date: Thu, 18 Sep 2003 13:30:48 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Updated CCAMP charter (fwd) Message-ID: <20030918132525.C4477@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Kireeti Kompella Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion: ccamp@ops.ietf.org To Subscribe: majordomo@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Sep 2003 05:36:05 +0000 Reply-To: From: "Vishal Sharma" To: , , Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Wed, 17 Sep 2003 22:30:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Wednesday, September 17, 2003 3:22 PM > To: v.sharma@ieee.org; rabbat@fla.fujitsu.com; ccamp@ops.ietf.org > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Sep 2003 04:34:28 +0000 Message-ID: <20030918042840.23958.qmail@web8106.mail.in.yahoo.com> Date: Thu, 18 Sep 2003 05:28:40 +0100 (BST) From: =?iso-8859-1?q?sundar=20pandian?= Subject: seeking suggestions regarding Thesis To: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Sep 2003 22:57:41 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023315AB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Kireeti Kompella'" , "Wijnen, Bert (Bert)" Cc: "'v.sharma@ieee.org'" , CCAMP , "Ronald P. Bonica" , Greg Bernstein , Eric Mannie , Alexey Zinin Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Date: Thu, 18 Sep 2003 00:56:08 +0200 MIME-Version: 1.0 Content-Type: text/plain > 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 iesg-secreytary@ietf.org so that they can put it into ID-tracker and so that it does not fall through the cracks. Bert > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Sep 2003 22:28:33 +0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2B13@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: v.sharma@ieee.org, rabbat@fla.fujitsu.com, ccamp@ops.ietf.org Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Wed, 17 Sep 2003 23:22:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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? Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Sep 2003 18:22:07 +0000 Reply-To: From: "Vishal Sharma" To: "Kireeti Kompella" , "Wijnen, Bert \(Bert\)" Cc: "CCAMP" , "Ronald P. Bonica" , "Greg Bernstein" , "Eric Mannie" , "Alexey Zinin" Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Date: Wed, 17 Sep 2003 11:07:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:kireeti@juniper.net] > Sent: Wednesday, September 17, 2003 7:41 AM > To: Wijnen, Bert (Bert) > Cc: 'v.sharma@ieee.org'; 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Sep 2003 14:45:00 +0000 Date: Wed, 17 Sep 2003 07:40:54 -0700 (PDT) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: "'v.sharma@ieee.org'" , CCAMP , "Ronald P. Bonica" , Greg Bernstein , Eric Mannie , Alexey Zinin Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Message-ID: <20030917073731.X97581@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Sep 2003 09:22:37 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550233159A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'v.sharma@ieee.org'" , "Wijnen, Bert (Bert)" , Dimitri.Papadimitriou@alcatel.be Cc: CCAMP , Kireeti Kompella , "Ronald P. Bonica" , Greg Bernstein , Eric Mannie , Alexey Zinin Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Date: Wed, 17 Sep 2003 11:17:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:v.sharma@ieee.org] > Sent: woensdag 17 september 2003 3:47 > To: Wijnen, Bert (Bert); Dimitri.Papadimitriou@alcatel.be > 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:bwijnen@lucent.com] > > Sent: Tuesday, September 16, 2003 3:31 PM > > To: 'Dimitri.Papadimitriou@alcatel.be'; v.sharma@ieee.org > > 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): > > > > > > > > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Sep 2003 01:52:16 +0000 Reply-To: From: "Vishal Sharma" To: "Wijnen, Bert \(Bert\)" , Cc: "CCAMP" , "Kireeti Kompella" , "Ronald P. Bonica" , "Greg Bernstein" , "Eric Mannie" , "Alexey Zinin" Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Date: Tue, 16 Sep 2003 18:47:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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:bwijnen@lucent.com] > Sent: Tuesday, September 16, 2003 3:31 PM > To: 'Dimitri.Papadimitriou@alcatel.be'; v.sharma@ieee.org > 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): > > > > > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Sep 2003 22:34:46 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550233158D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Dimitri.Papadimitriou@alcatel.be'" , v.sharma@ieee.org Cc: CCAMP , Kireeti Kompella , "Ronald P. Bonica" , Greg Bernstein , Eric Mannie , Alexey Zinin Subject: RE: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Date: Wed, 17 Sep 2003 00:31:22 +0200 MIME-Version: 1.0 Content-Type: text/plain .. 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): > > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Sep 2003 21:41:51 +0000 Message-ID: <35800AB26A91D711A75D00B0D07935F3038A35@mailsrv01.vasw> From: Michael Mandelberg To: ccamp@ops.ietf.org Subject: IF_ID ERROR_SPEC allowed in any message? Date: Tue, 16 Sep 2003 17:34:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Sep 2003 21:28:08 +0000 Message-ID: <3F678036.3060406@alcatel.be> Date: Tue, 16 Sep 2003 23:27:18 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: v.sharma@ieee.org Cc: CCAMP , Kireeti Kompella , "Ronald P. Bonica" , Greg Bernstein , Eric Mannie , Alexey Zinin Subject: Re: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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): 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 : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Sep 2003 21:04:59 +0000 Reply-To: From: "Vishal Sharma" To: , , Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Tue, 16 Sep 2003 13:59:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Neil, Thanks for your comments. A couple of comments and questions in-line. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > neil.2.harrison@bt.com > Sent: Sunday, September 14, 2003 2:07 AM > To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org > Subject: RE: Comparison of restoration requirements between transport and > packet networks > > > Hi Richard....please see in-line. regards, Neil > [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. > [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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Sep 2003 07:14:11 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" , "Kireeti Kompella" , "Ronald P. Bonica" Cc: "Greg Bernstein" , "Eric Mannie" , "Alexey Zinin" Subject: Status of draft-ietf-ccamp-sdhsonet-control-02.txt Date: Tue, 16 Sep 2003 00:07:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 14 Sep 2003 09:12:38 +0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2AD9@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: rabbat@fla.fujitsu.com, ccamp@ops.ietf.org Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Sun, 14 Sep 2003 10:07:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37A9F.9312921C" 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:rabbat@fla.fujitsu.com] Sent: 13 September 2003 00:29 To: Harrison,N,Neil,IKL2 R; ccamp@ops.ietf.org Subject: RE: Comparison of restoration requirements between transport and packet networks Hi Neil, Please see comments inline Thanks, Richard. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: Thursday, September 11, 2003 5:06 AM To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org 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. ------_=_NextPart_001_01C37A9F.9312921C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Richard....please see in-line.  = regards,=20 Neil
-----Original Message-----
From: Richard Rabbat=20 [mailto:rabbat@fla.fujitsu.com]
Sent: 13 September 2003=20 00:29
To: Harrison,N,Neil,IKL2 R;=20 ccamp@ops.ietf.org
Subject: RE: Comparison of restoration=20 requirements between transport and packet = networks

Hi=20 Neil,

Please see = comments=20 inline

Thanks,

Richard.

 

-----Original=20 Message-----
From: = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 neil.2.harrison@bt.com
Sent: Thursday, September=20 11, 2003 5:06=20 AM
To: rabbat@fla.fujitsu.com;=20 ccamp@ops.ietf.org
Subject:=20 RE: Comparison of restoration requirements between transport and = packet=20 networks

 

Richard,

 

In=20 section 1 of your paper it says:

 

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

 

[Richard]=20 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’ll=20 change to sentence to clear the misunderstanding

 

That=20 being the case, wherever it is to be used one needs all the defects=20 defining.  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.  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.  Further, one = should take=20 care not to invoke protection/restoration for error events which=20 self-clear.

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

NH=3D> That=20 was not my point......50ms is *not* required by applications was my=20 point.  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.

 

The general=20 rule with protection/restoration is:

"As 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)."

 

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). =20 There are 3, and only 3, networking modes, viz cnls, co-ps and = co-cs.....all=20 technologies map to one of these.  All modes are required, as = all provide=20 different behaviours.  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.  OAM and fault = detection/handling=20 is one key functional component.  It has a different = specification=20 in the cnls, co-ps and co-cs cases.  It also assumes that the = functional=20 architecture of G.805 (co modes) and G.809 (cnls) is respected.  = 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.  = 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?'

 

 

 It may be doable in simpler=20 configurations.  The whole point of the draft is to *guarantee* a notification = time. =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? 

NH=3D> 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.  Let = me give=20 you and example for you to answer wrt to the activities in the = PWE3=20 group.  What is the protection speed requirments for SDHoverMPLS = in the=20 client (SDH) and server (MPLS) case?  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?

{Aside=20 -  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.}

 

  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.

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

-      =20 Fiber=20 cut

-      =20 Transponder=20 failure

-      =20 Node=20 failure

I hope = this clears up=20 the misunderstanding. 

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

 

<NH = snipped to=20 end>

 

= ------_=_NextPart_001_01C37A9F.9312921C-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Sep 2003 23:33:24 +0000 From: "Richard Rabbat" To: , Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Fri, 12 Sep 2003 16:29:00 -0700 Message-ID: <004601c37985$a5f0d160$533ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C3794A.F991F960" 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of neil.2.harrison@bt.com Sent: Thursday, September 11, 2003 5:06 AM To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org 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:rabbat@fla.fujitsu.com] Sent: 10 September 2003 23:12 To: ccamp@ops.ietf.org 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Wednesday, September 10, 2003 1:13 PM To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org; zali@cisco.com Cc: v.sharma@ieee.org 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:rabbat@fla.fujitsu.com] Sent: 10 September 2003 20:11 To: ccamp@ops.ietf.org; 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

Hi Neil,

Please see comments = inline

Thanks,

Richard.

 

-----Original Message-----
From: = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of neil.2.harrison@bt.com
Sent: Thursday, September 11, 2003 5:06 AM
To: = rabbat@fla.fujitsu.com; ccamp@ops.ietf.org
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. 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.

 

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.

 

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

 

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

 

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

 

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:rabbat@fla.fujitsu.com]
Sent: 10 September 2003 = 23:12
To: = ccamp@ops.ietf.org
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: = neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Wednesday, = September 10, 2003 1:13 PM
To: = rabbat@fla.fujitsu.com; ccamp@ops.ietf.org; zali@cisco.com
Cc: v.sharma@ieee.org
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:rabbat@fla.fujitsu.com]
Sent: 10 September 2003 = 20:11
To: ccamp@ops.ietf.org; = 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_000_0047_01C3794A.F991F960-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Sep 2003 12:09:51 +0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6D84@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: rabbat@fla.fujitsu.com, ccamp@ops.ietf.org Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Thu, 11 Sep 2003 13:06:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3785D.155B6D9B" 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:rabbat@fla.fujitsu.com] Sent: 10 September 2003 23:12 To: ccamp@ops.ietf.org 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, September 10, 2003 1:13 PM To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org; zali@cisco.com Cc: v.sharma@ieee.org 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:rabbat@fla.fujitsu.com] Sent: 10 September 2003 20:11 To: ccamp@ops.ietf.org; 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"
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:rabbat@fla.fujitsu.com]
Sent: 10 September 2003 23:12
To: ccamp@ops.ietf.org
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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Wednesday, September 10, 2003 1:13 PM
To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org; zali@cisco.com
Cc: v.sharma@ieee.org
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:rabbat@fla.fujitsu.com]
Sent: 10 September 2003 20:11
To: ccamp@ops.ietf.org; 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Sep 2003 22:16:48 +0000 From: "Richard Rabbat" To: Subject: re: Comparison of restoration requirements between transport and packet networks Date: Wed, 10 Sep 2003 15:11:49 -0700 Message-ID: <008901c377e8$881918d0$3d3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01C377AD.DBBA40D0" 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Wednesday, September 10, 2003 1:13 PM To: rabbat@fla.fujitsu.com; ccamp@ops.ietf.org; zali@cisco.com Cc: v.sharma@ieee.org 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:rabbat@fla.fujitsu.com] Sent: 10 September 2003 20:11 To: ccamp@ops.ietf.org; 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

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: = neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Wednesday, September 10, 2003 1:13 PM
To: = rabbat@fla.fujitsu.com; ccamp@ops.ietf.org; zali@cisco.com
Cc: v.sharma@ieee.org
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:rabbat@fla.fujitsu.com]
Sent: 10 September 2003 20:11
To: ccamp@ops.ietf.org; = 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_000_008A_01C377AD.DBBA40D0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Sep 2003 20:17:07 +0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6D81@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: rabbat@fla.fujitsu.com, ccamp@ops.ietf.org, zali@cisco.com Cc: v.sharma@ieee.org Subject: RE: Comparison of restoration requirements between transport and packet networks Date: Wed, 10 Sep 2003 21:12:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C377D7.E296674C" 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:rabbat@fla.fujitsu.com] Sent: 10 September 2003 20:11 To: ccamp@ops.ietf.org; 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"
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:rabbat@fla.fujitsu.com]
Sent: 10 September 2003 20:11
To: ccamp@ops.ietf.org; 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Sep 2003 19:17:49 +0000 From: "Richard Rabbat" To: , "Zafar Ali" Cc: "Vishal Sharma" , "'Richard Rabbat'" Subject: Comparison of restoration requirements between transport and packet networks Date: Wed, 10 Sep 2003 12:11:02 -0700 Message-ID: <002301c377cf$478d8b20$3d3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C37794.9B2EB320" 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

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_000_0024_01C37794.9B2EB320-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Sep 2003 21:55:15 +0000 Reply-To: From: "Vishal Sharma" To: "zafar ali" , "'Richard Rabbat'" , Subject: RE: Time-bounded notification Date: Tue, 9 Sep 2003 14:51:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C376E1.D1918540" 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:zali@cisco.com] Sent: Tuesday, September 09, 2003 12:06 PM To: 'Richard Rabbat'; ccamp@ops.ietf.org 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, zali@cisco.com ===================================================================== -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat Sent: Thursday, August 14, 2003 2:09 PM To: ccamp@ops.ietf.org 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 Message
Hi=20 Zafar,
 
Thanks=20 very much for your comments and observations.
 
It is=20 very helpful to know what was causing the confusion at the last couple=20 IETF's.
And,=20 your point about splitting up the problem to first explain the need for = a=20 solution and
an=20 approach to it, and then explaining specific details is well taken. (It = does=20 appear that the
FNP=20 solution proposed in draft-rabbat has often been interpreted as being = equivalent=20 to
it's=20 LMP specific implemenation, even though that's not the case. So a = clearer=20 split
of the=20 problem and specifics should help.)
 
In=20 fact, based on additional off-line feedback and conversations=20 with people interested
in the=20 problem, we have already been thinking of providing a more detailed = explanation=20 on the list,
and=20 perhaps following that up with an explanatory draft. We think these = will be=20 helpful in
further WG email discussions.
 
Regards,
-Vishal
-----Original Message-----
From: zafar ali=20 [mailto:zali@cisco.com]
Sent: Tuesday, September 09, 2003 = 12:06=20 PM
To: 'Richard Rabbat'; ccamp@ops.ietf.org
Cc: = 'Vishal=20 Sharma'
Subject: RE: Time-bounded = notification

Hi=20 Richard,
 
Sorry for replying late; Please see comments in-lined.=20
 
Thanks
 
Regards...=20 Zafar
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zaf= ar=20 Ali, Ph. D.              &nbs= p;            = ;            =             &= nbsp;     100 South Main St.=20 #200,
Technical = Leader,              &nbs= p;            = ;       &nbs= p;            = ;       =20 Ann Arbor, MI 48104, USA.
Cisco=20 Systems.              &nbs= p;            = ;            =             &= nbsp;     (734)=20 276-2459, zali@cisco.com
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Richard Rabbat
Sent: Thursday, August 14, 2003 2:09=20 PM
To: ccamp@ops.ietf.org
Cc: 'Vishal=20 Sharma'
Subject: Time-bounded = notification

Hello=20 Everyone,

 

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 *time-bounded*=20 notification.

 

This is because = draft-rabbat=20 focuses on recovery in optical transport networks, where recovery of = failed=20 LSPs (fibers, lambdas, etc.) in a *bounded time* 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.

 

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.  

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

 

 

 

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

 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.  

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

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

 Agreed!=20

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.

 

Thanks,

 

-Richard and=20 Vishal

 

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

 

RFC3272

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

page = 52:

--

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

--

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.

 

 

RFC3386

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

Page 15 discusses the=20 following:

--

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

 

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

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

   Local=20 = restoration:          &= nbsp;           &n= bsp;          =20 50 ms

   Path=20 = restoration:          &= nbsp;           &n= bsp;           =20 1-5 seconds

--

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

 

 

------=_NextPart_000_000E_01C376E1.D1918540-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Sep 2003 19:14:14 +0000 From: "zafar ali" To: "'Richard Rabbat'" , Cc: "'Vishal Sharma'" Subject: RE: Time-bounded notification Date: Tue, 9 Sep 2003 15:05:34 -0400 Organization: Cisco Systems Message-ID: <015f01c37705$628a04a0$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01C376E3.DB7864A0" 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, zali@cisco.com ===================================================================== -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat Sent: Thursday, August 14, 2003 2:09 PM To: ccamp@ops.ietf.org 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 Message
Hi=20 Richard,
 
Sorry=20 for replying late; Please see comments in-lined.
 
Thanks
 
Regards... = Zafar
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zaf= ar=20 Ali, Ph. D.              &nbs= p;            = ;            =             &= nbsp;     100 South Main St.=20 #200,
Technical = Leader,              &nbs= p;            = ;       &nbs= p;            = ;       =20 Ann Arbor, MI 48104, USA.
Cisco=20 Systems.              &nbs= p;            = ;            =             &= nbsp;     (734)=20 276-2459, zali@cisco.com
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Richard Rabbat
Sent: Thursday, August 14, 2003 2:09=20 PM
To: ccamp@ops.ietf.org
Cc: 'Vishal=20 Sharma'
Subject: Time-bounded = notification

Hello = Everyone,

 

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 *time-bounded*=20 notification.

 

This is because = draft-rabbat=20 focuses on recovery in optical transport networks, where recovery of = failed=20 LSPs (fibers, lambdas, etc.) in a *bounded=20 time* 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.

 

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.  

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

 

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

 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.  

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

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

 Agreed!=20

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.

 

Thanks,

 

-Richard and=20 Vishal

 

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

 

RFC3272

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

page = 52:

--

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

--

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.

 

 

RFC3386

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

Page 15 discusses the=20 following:

--

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

 

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

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

   Local=20 = restoration:          &= nbsp;           &n= bsp;          =20 50 ms

   Path=20 = restoration:          &= nbsp;           &n= bsp;           =20 1-5 seconds

--

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

 

 

------=_NextPart_000_0160_01C376E3.DB7864A0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 05 Sep 2003 16:30:20 +0000 Message-ID: <003201c373ca$629780f0$1eaa9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Len Nieman" Cc: , "Tim Hall" , "Thomas D. Nadeau" , "Cheenu Srinivasan" , "Edward Harrison" Subject: Re: GMPLS MIBs Date: Fri, 5 Sep 2003 17:21:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Len, Much appreciated. Adrian ----- Original Message ----- From: "Len Nieman" To: "Adrian Farrel" Cc: ; "Tim Hall" ; "Thomas D. Nadeau" ; "Cheenu Srinivasan" ; "Edward Harrison" 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: ccamp-data@psg.com Delivery-date: Fri, 05 Sep 2003 01:11:41 +0000 Date: Thu, 04 Sep 2003 21:07 -0400 (EDT) From: Len Nieman To: "Adrian Farrel" CC: , "Tim Hall" , "Thomas D. Nadeau" , "Cheenu Srinivasan" , "Edward Harrison" 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: ccamp-data@psg.com Delivery-date: Fri, 05 Sep 2003 01:11:10 +0000 Date: Thu, 04 Sep 2003 21:07 -0400 (EDT) From: Len Nieman To: "Adrian Farrel" CC: , "Tim Hall" , "Thomas D. Nadeau" , "Cheenu Srinivasan" , "Edward Harrison" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Sep 2003 17:37:34 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , Cc: "'Tim Hall'" , "'Cheenu Srinivasan'" , "'Edward Harrison'" Subject: RE: GMPLS MIBs Date: Tue, 2 Sep 2003 11:29:56 -0400 Organization: Cisco Systems, inc. Message-ID: <000301c37167$10a42970$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Sep 2003 20:46:47 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331469@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Martin Dubuc'" Cc: "Ccamp-wg (E-mail)" Subject: RE: LMP MIB revision 6 Date: Mon, 1 Sep 2003 22:42:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:m.dubuc@rogers.com] 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